Design CS 524 – Software Engineering I Fall I 2007 – Sheldon X. Liang, PH.D. Jeff Nogy

Overview  Introduction  Design and Abstraction  Cohesion  Coupling  Operation-Oriented Design  Data-Oriented Design  Object-Oriented Design

Overview  The Design Workflow  The Test Workflow: Design  Real-Time Design Techniques  CASE Tools for Design  Metrics for Design  Challenges of the Design Workflow  Conclusion

Introduction  The two basic ways of designing a product are operation-oriented design and data-oriented design. In operation-oriented design, the emphasis is on the operations. In data-oriented design, the data are considered first.

Introduction  A weakness of operation-oriented design techniques is that they concentrate on the operations; the data are of only secondary importance.  Data-oriented design techniques similarly emphasize the data, to the detriment of the operations.  The solution is to use object-oriented techniques, which give equal weight to operations and data.

Introduction  A basic understanding of operation- oriented and data-oriented design is needed to get a full understanding of object-oriented design. An object incorporates both operation and data. Object-oriented design combines features of operation-oriented design and data-oriented design.

Design and Abstraction  The classical design phase consists of three activities: Architectural design Detailed design Design testing

Design and Abstraction  Architectural design A modular decomposition of the product is developed. The output from this activity is a list of the modules and a description of how they are to be interconnected. When the object-oriented paradigm is used, the architectural design activity is performed during the object-oriented analysis workflow.

Design and Abstraction  Detailed design Each module (or class) is designed in detail.  Design testing In object-oriented design, the test workflow is performed concurrently with the design workflow.

Cohesion  Cohesion is the degree of interaction within a module  Myers defined seven categories or levels of cohesion.  This is not a linear scale, but merely a relative ranking.

Cohesion  High cohesion is good.  Low cohesion is bad.

Cohesion: Informational  A module has informational cohesion if it performs a number of operations: Each operation with its own entry/exit point. With independent code for each operation. All performed on the same data structure.  This does not violate the tenets of structured programming.

Cohesion: Informational  An abstract Data type.

Coupling  Coupling is the degree of interaction between two modules.  There are five categories or levels of coupling (non-linear scale).

Coupling: Data  Two modules are data coupled if all arguments are uniform data items. Every argument is either a simple argument or a data structure in which all elements are used by the called module. If a product exhibits data coupling exclusively, then the difficulties of content, common, control, and stamp coupling are not present.

Operation-Oriented Design  Two practical classical techniques for achieving design objective. Data flow analysis. Transaction analysis.  Data flow analysis can be applied whenever the specifications can be represented by a data flow diagram.  Transaction analysis is a good way of decomposing transaction-processing products into modules.  The objective of the decomposition is to achieve HIGH Cohesion and LOW coupling.

Operation-Oriented Design: Data Flow Analysis  Data flow analysis (DFA) is a classical design technique. It is used for achieving modules with high cohesion. The input to the technique is a data flow diagram (DFD). The DFD gives the software designer precise and complete information regarding the input to and output from the product.

Operation-Oriented Design: Data Flow Analysis  At some point in the DFD transforms input into output. The input ceases to be input and becomes some sort of internal data. The internal data then take on the quality of output.

Operation-Oriented Design: Data Flow Analysis  The point at which the input loses the quality of being input and simply becomes internal data operated on by the product is termed the point of highest abstraction of input.  The point of highest abstraction of output is similarly the first point in the flow of data at which the output can be identified as such.

Operation-Oriented Design: Data Flow Analysis  Using the points of highest abstraction of input and output, the product is decomposed into three modules: input_module transform_module output_module

Operation-Oriented Design: Data Flow Analysis  Each module is then taken in turn to find its points of highest abstraction found and the module decomposed again.  This continues until each module performs a single operation, with high cohesion.  Minor modifications might have to be made to the decomposition to achieve the lowest possible coupling.

Operation-Oriented Design: Data Flow Analysis  Data flow analysis is a way of achieving high cohesion. DFA does not take coupling into account.  Composite/structured design is a way of achieving high cohesion AND low coupling. Sometimes it is necessary to make minor modifications to the design to achieve low coupling. By simply modifying the two modules involved so that data, and not control, are passed between them.

Operation-Oriented Design: Data Flow Analysis Extensions  For multiple input and output streams. Find the point of highest abstraction of input for each input stream. Find the point of highest abstraction of output for each output stream. Use these points for further decomposition - modules with fewer input/output streams. Continue until each resulting module has high cohesion. Finally, determine the coupling between each pair of modules and make any necessary adjustments.

Operation-Oriented Design: Transaction Analysis  A transaction is an operation from the viewpoint of the user. Process a request. Print a list of today's orders.

Operation-Oriented Design: Transaction Analysis  Data flow analysis is inappropriate when transaction-processing must be performed.  A good way to design such a product is to break it into two pieces. Analyzer - the analyzer determines the transaction type. Dispatcher - dispatcher, which performs the transaction.  The resulting design has high cohesion and low coupling.

Data-Oriented Design  The basic principle behind data-oriented design is to design the product according to the structure of the data on which it is to operate. First, the structure of the data is determined. Second, each procedure is given the same structure as the data on which it operates.  Data-oriented design was never as popular as operation-oriented design and has largely fallen out of fashion.

Object-Oriented Design  The goal of OOD is to design the product in terms of objects.  The objects are the instantiations of the classes and subclasses extracted during object-oriented analysis. A class is an abstract data type with inheritance and an object is an instance of a class.

Object-Oriented Design  The two key steps of OOD are: Complete the class diagram  The formats of the attributes need to be determined.  The methods need to be assigned to the relevant classes. Perform the detailed design.  Any suitable technique may be used.  For example, stepwise refinement.

Object-Oriented Design  Principle that can be employed to assist in deciding how to assign an operation: Information hiding. Have a single copy of an operation implemented as a method of the object. Responsibility-driven design.

Object-Oriented Design  Responsibility-driven design is a key aspect of the object-oriented paradigm. An object is responsible for every aspect of carrying out a request. The client does not know how the request will be carried out and is not permitted to know. Once the request has been carried out, control returns to the client.

The Design Workflow  The input to the design workflow is the analysis workflow artifacts (Chapter 12). These artifacts are iterated and incremented until they are in a format that can be utilized by the programmers.

The Design Workflow  These two steps constitute the object-oriented design component of the design workflow. One aspect of this iteration and incrementation is the identification of methods and their allocation to the appropriate classes. Another aspect is performing the detailed design.

The Design Workflow  Decisions that have to be made as part of the design workflow. The selection of the programming language in which the software product will be implemented (Chapter 14). How much of the existing software products to reuse in the new software product to be developed (Chapter 8). Portability is another important design decision (Chapter 8). Will the product be implemented on a network of computers. The allocation of the hardware component on which it is to run.

The Design Workflow  The major motivation behind the development of the Unified Process was to present a methodology that could be used to develop large-scale software products. 500,000 lines of code or more, typically.  An important part of the analysis workflow is to partition the software product into analysis packages.  Each package consists of a set of related classes.

The Design Workflow  It is much easier to develop smaller software products than larger ones, the underlying concept of the analysis package.  There are two reasons why larger workflows are broken into subsystems: It is easier to implement a number of smaller subsystems than one large system. If the subsystems to be implemented are indeed relatively independent, then they can be implemented by programming teams working in parallel. This results in the software product as a whole being delivered sooner.

The Design Workflow  The architecture of a software product includes the various components and how they fit together.  Deciding on the architecture of a software product is by no means easy and is performed by a specialist, the software architect.

The Design Workflow  The architecture of a software product is a vital factor as to whether the delivered product is a success or a failure.  The critical decisions regarding the architecture have to be made while performing the design workflow.

The Design Workflow  If the requirements workflow is bad, it is possible to recover. Provided additional time and money are spent on the analysis workflow.  If the analysis workflow is bad, it is possible to recover. Provided additional time and money are spent on the design workflow.

The Design Workflow  If the architecture is bad, there is no way to recover. The architecture must immediately be redesigned.  It is, therefore, essential that the development team include an architect with the necessary technical expertise and people skills.

The Test Workflow: Design  The goal of testing the design is to verify: Specifications have been accurately and completely incorporated. To ensure the correctness of the design itself. The design must have no logic faults. All interfaces are correctly defined.  Design faults can be detected by: By performing a design inspections and a design walk-throughs.

The Test Workflow: Design  It is not adequate to schedule design inspections that are just transaction driven.  Specification-driven inspections are essential to ensure that no statement in the specification document has been either overlooked or misinterpreted.

Formal Techniques for Detailed Design  Implementing a complete product and then proving it correct is hard.  Formal techniques during detailed design can help. Correctness proving can be applied to module- sized pieces. The design should have fewer faults if it is developed in parallel with a correctness proof. If the same programmer does the detailed design and implementation.  The programmer will have a positive attitude toward the detailed design.  This should lead to fewer faults.

Real-Time Design Techniques  Real-time software is characterized by hard time constraints. If a constraint is not met, information is lost. Each input must be processed before the next input arrives.

Real-Time Design Techniques  A characteristic of many real-time systems is that they are implemented on distributed hardware. For example, software controlling a fighter aircraft may be implemented on five computers:  Navigation system.  Weapons system.  Electronic countermeasures.  Flight hardware system (wing flaps and engines).  Tactical combat system.

Real-Time Design Techniques  A difficulty with real-time systems is the problem of synchronization. Deadlock (or deadly embrace).  When two operations each have exclusive use of a data item.  Each requesting exclusive use of the other's data item. Race conditions.

Real-Time Design Techniques  Although the hardware exists to handle real-time systems, software design technology has lagged behind considerably.  Major progress has been made in some areas of real-time software engineering. Many of the analysis techniques of Chapters 11 and 12 can be used to specify real-time systems.

Real-Time Design Techniques  Older real-time design techniques are extensions of non-real-time techniques to the real-time domain. Structured development for real-time systems (SDRTS)  Essentially is an extension of: Structured systems analysis (Section 11.3) Data flow analysis (Section 13.3) Transaction analysis (Section 13.4)

CASE Tools for Design  A critical aspect of design is testing that the design artifacts accurately incorporate all aspects of the analysis. What is needed is a CASE tool that can be used both for the analysis artifacts and the design artifacts.  A front-end or upperCASE tool.

CASE Tools for Design  UpperCASE tools. Are built around a data dictionary. Incorporate a consistency checker. Incorporate screen and report generators. May also included Management tools.  Estimating  Planning

CASE Tools for Design  Object-oriented design tools. Commercial tools.  Software through Pictures.  Rose.  Together. Open-source tool.  ArgoUML.

Metrics for Design  A variety of metrics can be used to describe aspects of the design. The number of modules, or classes, as measure of size. Cohesion, coupling, and fault statistics as measures of the quality.

Metrics for Design  Cyclomatic complexity M The number of binary decisions in the code artifact. It has been suggested that cyclomatic complexity is a metric of design quality. The lower the value of M, the better. Cyclomatic complexity is a measure purely of the control complexity. The data complexity is ignored.

Challenges of the Design Workflow  It is important not to do too much in the analysis workflow. The analysis team must not prematurely start parts of the design workflow.  In the design workflow, the design team can go wrong in two ways: Doing too much. Doing too little.

Conclusion  The design workflow was introduced.  There are three basic approaches to design: Operation-oriented design. Data-oriented design. Object-oriented design.  Two instances of operation-oriented design are described Data flow analysis. transaction analysis.

Conclusion  The design aspects of the test workflow were described.  Formal techniques for detailed design were discussed.  Real-time system design was described.  CASE tools and metrics for the design workflow were presented.  The chapter concludes with a discussion of the challenges of the design workflow.