1. Design CS 470 – Software Engineering I Sheldon X. Liang, PH.D.

2. Overview  Introduction  Design and Abstraction  Cohesion & Coupling  Operation-Oriented Design  Data-Oriented Design  Object-Oriented Design  The Design Workflow

3. 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.

4. 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.

5. 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.

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

7. 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.

8. 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.

9. 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.

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

11. 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.

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

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. Object-Oriented Design OOA & OOD

22. 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. How much of the existing software products to reuse in the new software product to be developed. Portability is another important design decision. Will the product be implemented on a network of computers. The allocation of the hardware component on which it is to run.

23. 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.

24. 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.

25. The Design Workflow  If the requirements workflow is bad, it is possible to recover.  If the analysis workflow is bad, it is possible to recover.  If the architecture is bad, there is no way to recover. The architecture must immediately be redesigned.

26. 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.