Report on Assigned Reading1 – Design

By - Anju Gupta

University of Washington, CSE584 – Software Engineering

10/19/98

While reading this article I had my TV On and it occurred to me, the engineers while designing a TV would have come across the similar problems and questions. After so many years of improvements on TV we accept it as an Black Box although it comes with the input and output jacks which gets us controls like audio output to stereo system, input from the VCR etc. Comparing this analogy helped me understand current Open implementation more clearly.

Large-scale systematic software reuse not only saves time but also saves lots money. To verify this theory an application is developed as a research tool, which support a technique called fault-tree analysis. The goal of the software development project was to produce a tool that would make techniques for the fault trees available quickly and in a form with features and performance characteristics that would be similar to commercial products. The paper then discusses the specifics of the tools and how the Ideal Mediator-Based Design has to be modified to compromised Design. But overall the results of the tool are very positive and a tool is build quickly and at low cost and promises the potential for component integration architectures for large-scale systematic reuse.

It was about four years ago that I developed a tool in Visual Basic 3.0 called it Scheduler as it performed all the functions of scheduling a software task. It was used for the scheduling reports in the middle of the night and emailing them to customers/vendors/employees. Since then I have used this tool for almost all my applications which require scheduling the latest being sending out birthday wishes to my friends at the middle of the night! Although I have millions of problems whenever I have to move this tool to the next release of Visual Basic I still couldn't agree more with ease of code reuse.

Designing a huge and complex system with many modules are raising lots of new kind design problems these days. For the success of a software design, first, we need to study old systems designs, second, we need to get the right architecture, third, understand the software architecture in detail and fourth, should be able to represent the high-level properties correctly. We have come long way from machine programming language to understand the importance of Software architecture. Some of the wells know software Architectures discussed are Pipes and Filters, Data Abstraction and Object Oriented Organization, Event based Implicit Invocations, Repositories, and Tables driven Interpreters. Some of the other familiar architectures are Distributed processes, Main program, and Domain-specific software architectures, State transaction systems and Processes control systems. Heterogeneous – This style involve combinations of several styles.

Being an application programmer in the fields of databases the architectures I am familiar with Distributed Processes - Client - Server. Last year, I worked on an application where three databases, with almost similar kind of data needed to be in sync with each other. We considered various architectures to resolve this problem, the simplest being the Repositories. The solution we finally applied was using real time SQL replication. This paper was a good learning of other kinds of architectures. The Case Studies covered were pretty helpful in understanding the concepts.

Requirements for integrated environment commonly change in several ways. Design techniques must account for these changes. This can be achieved by designing separate components and the components should be independent of relationships in three ways: they should be able to execute without dependence, their source should be defined without reference to relationships and the participation into relationship should not prevent other components from accessing them. First class components called Mediators can achieve this relationship independence among other components. The paper then discusses three systems constructed which present typical and useful ways of using events and mediators. The first covers using the events and mediators in typical way, the second system uses mediators and events in a slightly different way and the third system uses parallel programming.

In the above paper I agree with the concept of Mediators to allow relationship independence among other components. Although the paper failed to discusses the consequences on the mediators as the project ages. With the size of the system the overhead of the maintenance of mediator would be huge.

Design patterns provide a common vocabulary for designers to communicate, document, explore design alternatives, build reusable software, reduce the learning time for a class library and provide a target for the reorganization. Design patterns can be categorized into two orthogonal criteria, Jurisdiction and characterization. Jurisdiction is the domain over which the pattern applies. Characterization reflects what a pattern does. The paper then summarizes the observations of two of the project that uses Design patterns to the design and construction. The main observations are: Design patterns motivate developers to go beyond concrete objects, choosing intuitive class names is important, often design patterns are applied after the first implementation, design patterns are suited to reuse and they also reduce the effort to learn class library. The paper briefly discusses other related work

I haven't got a chance to work on a Object-Oriented technology, but from this paper I could get the advantages of design patterns applicable in many stages of the design process – initial design and reuse.

On criteria to be used in decomposing systems into modules

In this paper, D.L. Parnas discusses the Criteria to be used in dividing the system into modules - "Modularization", to improve the flexibility and comprehensibility of a system while reducing the development time. The paper then discusses a system design problem in conventional decomposition and an unconventional decomposition. Comparing the two with the goals: changeability, independent development and comprehensibility. Unconventional decomposition has distinct advantage. The criteria used in conventional decomposition were to make each major step in the processing a module. The criteria used in unconventional decomposition were "information hiding". The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases whereas conventional decomposition is unlikely to suffer from this problem. An alternate approach to implementation, which does not have this effect, is sketched. The paper concludes explaining the way to achieve efficiency would be to allow subroutines and programs to be assembled collections of code from various modules.

I agree it is very difficult to set up criteria while splitting the system into modules. Often there is a trade off between ease of designing and maintaining a module with the achieving the optimum efficiency.

In this paper, D.L Parnas discusses that designing software for extension and contraction is requiring special planning and designing. The reasons which prevent the extension and contractions in the current system are: Excessive Information Distribution, A chain of data transforming components, components that perform more than one function and Loops in the "Uses" relation. Four steps that would help build better systems are 1. Requirement definition - Identifying the Subsets first, 2. Information Hiding- Interface and module definition, 3. The virtual Machine(VM) concept, 4. Designing the "Uses" structure. The most critical is the fourth step. The paper then concludes emphasizing the points, they are: The requirements Include subsets and extensions, Advantages of virtual machine approach, difference between software generality and software flexibility, distinction between modules, subprograms and levels, avoiding duplication, designing the subsets and extensions can reduce the need for support software and On Value of a Model.

One of the projects I worked on, the development cycle went backwards, meaning we started with the coding and then completed the technical specifications. We did know that this project will require to localized in two more language but under the time pressure we continued coding. In the end we have to pay it big time, it was impossible to accommodate new features. Learning the lesson with my experience, I agree while designing the system the extensions and contractions should be considered for the over all success of the project.

A framework is a large-scale design that describes how a program is decomposed into a set of interacting objects. Frameworks take advantage of all three of the distinguishing characteristics of object-oriented programming languages; data abstraction, polymorphism and inheritance. A framework describes the architecture of an object-oriented system, the kinds of objects in it and how they interact. A framework reuses code, design and analysis. Comparing the framework with other reuse techniques, it lies between abstract and flexible components but easier to reuse than a raw design. They are most comparable to reuse techniques that reuse both design and code, such as application generators and templates. There are several ways to use a framework. Some are: to connect existing components, to define new concrete subclasses and to use them to implement an application, by changing the abstract classes that form the core of the framework, if black-box- by instantiating existing classes and connecting them together. The best way to learn framework is by examples and it is easy to learn if they have good documentation. Some of the suggested ways evaluate a framework are by making a feature checklist, by making a prototype, by hiring a consultant. The approach that should be used in framework design is – iteration. Some of the problems with framework are – they are hard to learn, they are represented by object oriented programming language, which restricts the system using the same language.

This paper provided me with good information on the Frameworks and components. It was interesting to learn, that in reuse technique components more flexible than the framework design.