Ben Kaizi-Lutu
CSE 584 Software Engineering
Design Readings
Beyond The Black Box: Open Implementation
Gregor Kiczales, 1996
Black box implementations have been used for a long time as a fundamental means to provide portability, reuse and
even simplicity in software systems. However a closed implementation as is provided by the black box method may
not offer the flexibility and in some cases the level of performance required for a commercial software systems. Open
implementations are proposed as the means to retain the positive aspects of black box abstraction while allowing for
client flexibility and enabling great perfomance.
I guess what needs to be be understood is why black box implementations been so successful. A good example of
groundbreaking blackbox implementations that I am familiar with is application object model programming using
Visual Basic (Microsoft Tm). What visual basic has done for many corporate developers is allow them to implement
customs solutions for their specific environment very very quickly. A developer need not know the intricacies of the
application they are dealing with, rather they spend their time learning the published interfaces and using them to meet
their specific needs. What black box implementations do very very well is increase simplicity and because of that they
reduce the time required for a product cycle. This is priceless in industry where competition requires that products be
turned around in the shortest amount of time possible. So whatever we do with open implemenation we want to
especially preserve the inherent simplicity of black box implementation.
Open implementation must therefore address the weakness of black box implementation. The greatest of these in my
opinion is inflexibility.The inability of a client to know what goes on in the implementation it is using may lead to
really bad perfomance. Now PERFOMANCE is one of those terms that gets everyone excited or upset in the industry.
From the point of view of the user, they really don't care how easy it was to get your product out the door. They want
short response times, high thruput. They want good perfomance. So Open implemenations are going to open the box just
a little to allow the client to make informed decisions of what interfaces they should use in order to acquire the
perfomance levels they need. This is very desirable.
As a system grows and migrates thru several versions what would tend to happen is that more and more details of the
implementations may become open to clients. In order for such implementations not to break down and completely lose
the good evolutionary qualities of black box implementations, there must be a commitment in the implementation to
continue to support any secrets that have been shared with the clients. This will enable the clients to not have to go thru
progressive rewrites which would be the case if the secrets they had fine tuned to were no longer available in newer
versions of an open implementation
An Introduction To Software Architecture
David Garlan and Mary Shaw, 1994
A study of the popular software archictures known to man. For a computer science major, there wasn't much new
information shared in the discusion on the architectures themselves but it was good to find them comparatively
discussed in one place. The best part of the paper is the case studies. I read this section with considerable unease
because there was a lot of self revelation going on. I realized that as a developer who predominantly uses C++, an
object oriented language, I have succumbed to the notion that all my design problems are best solved in an object
oriented way. Object orientedness does provide a great initial understanding of what data types should be involved in
the design but it may not be the best design strategy suited for the problem at hand.
Realistically however a commercial developer may not have the benefit of time in order to go through two or more
mock designs before they arrive at the one that really works. In many cases it may be very tempting to just stick to your
own guns. To do just what you are used to doing. Intuitevely, I am bound to say that an object oriented design may be
the safest bet in mapping designs to problems. In that on the average it may provide the most benefits in enabling the
designer to understand the design problem before they embark on a full fledged design.
One aspect of design that is of considerable consequence in commercial software is space representaton. The general
idea that I picked up is that no matter where the design effort starts, it should migrate to a design where data
duplication is greatly minimized. The ideal of this is to have a single repository of data and have the various stages or
components of the system reading and writing to the same repository.
Experience Assessing an Architectural Approach to Large-Scale Systematic Reuse
Kevin J. Sullivan, John C. Knight
Microsoft OLE a component integration architecture was used to integrate VISIO a graphical rendering system with
ACCESS a database system in order to implement a fault-tree analysis tool. Architectural mismatch tends to happen
whenever attempts are made to integrate large software.systems. OLE seems to have addressed a lot of the tradional
architectural mismatch problems.
All of the software applications I have worked on have been built to support OLE. The one comment I could make is
that it takes a significant amount of effort and thus investment to make an application fully OLE compliant. I am not at
all surprised that the original design of the project was eventually compromised due to application limitations. What
tends to happen is that in the beginning of development for an OLE compliant application, the intention is to build
something that is fully OLE capable but as the development cycles spin, the compliance gets scaled down. Then it
becomes a guessing game as program designers try to decide what functionality system integrators cannot do without.
As the need for integrated custom solutions increases, it is going to become more and more neccesary for application
developers to be honest and committed to delivering applications that strictly conform to the integration frameworks
they subscribe to.
Design Patterns: Abstraction and Reuse of Object-Oriented Design
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 1993
Design patterns bring several qualities that enhance object oriented software design. They provide a language of
communication for software designers.They act as a basis for reusable elements and may even reduce the learning time
for a class library.
As I started to read this paper, it was hard not to just write everything off as the latest fad. It is as if object orientedness
is now an idea that folks have gotten used to so we do need another buzz word. It does appear that even though patterns
are a new concept, it is really a restatement in a formal way of the tenents of object oriented design. The patterns
themselves are structural concepts that are widely used in object oriented design and are not the invention of the
authors. For novice designers the strategies appear to be very valuable and well worth the ammount of time it would
take to learn them. For experienced designers, I think a cursory glance at the material would be sufficient to help
recognize the formalization of familiar concepts.
Since the paper only deals with patterns as a concept that relates to object oriented programming, I wonder if there are
mirrors of patterns in other design paradigms e.g in a pipeline architecture?
Reconciling Environment Integration and Component Independence
(Kevin J. Sullivan, David Notkin)
1990
Integrated software systems are so much a part of our lives as software engineers and that makes this paper very relevant. The paper deals with design strategies that facilitate the managing of complexity in such systems especially how to deal with the ever changing requirements that we in the software field are so accustomed to facing. First off the issue of separation of components and relationships is introduced. This idea is not at all different from that of separation of policy and mechanism that has been greatly used in Operating system design for some time.
Essentially an integrated system is one that is built up using different components where each component participates in one or more clearly defined relationship with other components. A good design of an integrated system would lead to fewer changes whenever requirements change. In order to minimize the need for change, it is important to separate the idea of component from that of relationship very early on in the design process.
Integration by encapsulation doesn't produce well integrated systems because it reduces component independence. Integration by hardwiring also reduces component independence and also complicates evolution making it hard to modify existing relationships and to add new ones. The design strategy of choice is a combination of events and mediators. Events provide component communication where components invoke each other on update calls. Mediators are firs-class components whose call in life is to maintain relationships among other components. They increase component independence and lead to quicker and smoother evolution.
It is however pointed out that it is still a challenge to consider tradeoffs between independence such as is provided by events and mediators versus atomic transactions such as is required in some applications. Similarly the same argument is made for concurrency needed on some platforms.
Components, Frameworks, Patterns
(Ralph E. Johnson)
1997
Frameworks can be defined as a reusable design of all or part of a system that is represented by a set of abstract classes and the way their interfaces interact. I guess I have used frameworks for a long time without really knowing it. It was also striking to me to observe that the examples of commercial frameworks given are huge bodies of software whose development has been the undertaking of major software companies that employing lots of developers to do the work. The framework concept also embodies the idea of ease of customization.
At the foundation of a framework are abstract classes. These are classes that have no instances and thus act as superclasses or as templates for creating subclasses. Frameworks utilize three good facets of object oriented programming; data abstraction, polymorphism and inheritance. Although frameworks are components and a developer could build a product from multiple frameworks, frameworks are generally more customizable than components. Frameworks differ from templates and schemas in the way they are expressed that being that frameworks are expressed in a programming language whereas schemas and templates usually require special purpose notation. This makes frameworks easier to use. Frameworks can be looked at as a pattern since some of them have been implemented several times. Unlike patterns however, frameworks are not just ideas they are code.
In order to use a framework, the developer must go through a learning process. This is also one of the problems with frameworks, they are not easy to learn. Development of a framework may take multiple iterations and cost a lot because frameworks are generally complex systems.
On The Criteria To Be Used in Decomposing Systems into Modules
(D.L. Parnas)
1972
Modularization is a well known concept within the programming community. What is not so known though is what advantages it brings to program design. A module is regarded as an integral part of the system that has an assigned responsibility. Modularization leads to shortened development time because separate groups can work in parallel on different modules with little need for communication. It provides flexibility because changes in one module need not affect other modules internally. It also provides comprehensibility because it is easier to study and understand individual modules.
The main point I got from this paper is to stop thinking about modularization in terms of the logical sequence of program flow but rather in terms of information hiding. The former works fine for smaller systems but for large commercial programs that must respond quickly to market changes and constraints the latter is mandatory. Modularization therefore requires the determination of what design decisions are likely to change and to make these the targets of information hiding. A module is then designed to hide such a decision from other modules
Designing Software for Ease of Extension and Contraction
(David L. Parnas)
1978
Another title for this could have been "Designing Software for Change". Software programs should not be viewed in isolation but rather as families. Doing this will enable the design of programs that can be customized to meet a broad set of users. . It is better to have flexible software rather than general software.
General software will meet a variety of needs but not more whereas flexible software can be easily modified to meet more needs.
The design process must involve at an early stage, the identification of reusable subsets. It is pointed out that software design can be done as a set of virtual machines rather than the conventional flowchart method. This is because virtual machines are easily extensible . The "USES" relation is introduced to enable identification of program dependence which in turn helps to define a program family. The usage idea must be restrained however otherwise it might result in a reduction in independence. This is done by using a hierarchical view of programs and establishing usage rules based on a program's level in the hierarchy.