1. Software Design Concepts and Principles COP 4331 and EEL4884 OO Processes for Software Development © Dr. David A. Workman School of EE and Computer Science February 23, 2010

2. COP 4331 (C) Dr. David A. Workman2 References Software Engineering: A Practioner’s Approach, 5 th ed. By Roger Pressman, McGraw-Hill, 2004, ISBN = 0-07-365578-3 Software Design By David Budgen, Addision-Wesley, 2003 ISBN = 0-201-72219-4 Program Development in Java By Barbara Liskov with John Guttag, Addision-Wesley, 2001 ISBN = 0-201-65768-6 Object-Oriented Software Engineering (using UML and Java) By Tim Lethbridge and Robert Lagani’ere, McGraw-Hill, 2001 ISBN = 0-07-709761-0

3. February 23, 2010COP 4331 (C) Dr. David A. Workman3 The Design Process [Belady’81] There are two major phases to any design process: 1.Diversification: acquiring a repertoire of alternatives, the raw material of design: component specifications, component solutions, and knowledge – all contained in catalogs, textbooks, and the mind. 2.Convergence: choosing and combining appropriate elements from the repertoire to meet design objectives, as stated in the requirements document and agreed to by the customer. This phase is a gradual iterative process resulting in the elimination of all but one particular configuration of components necessary to create the final product. Areas of Concern and Focus: System architecture design (modularity and organization) Data structure Interfaces and their representation Components and their detail (algorithm design)

4. February 23, 2010COP 4331 (C) Dr. David A. Workman4 Design Focus Areas Architectural Design An enumeration of all the relevant modules (logical organizational units) and components (processing units), their functionality and data processing responsibilities, their inter-dependencies, connectivity and/or communication relationships with other architectural units. Decomposition criteria: functional or object-oriented are the most common approaches to architectural design. Data Design An enumeration of all relevant information (data) elements that must be handled by the system together with specifying the relationships that must be defined, created and maintained among these elements. Examples: composition, aggregation, association, specialization, generalization, and multiplicity are relationships used in object-oriented design methods. Interface Design An interface is defined when two or more architectural units must exchange data with each other or interact in some way. An interface design must specify the data content exchanged, the direction of flow, timing constraints, interaction protocols, and mechanism for communication (e.g., hardware signal, hardware registers, shared variables, data file, database record or relation, gui).

5. February 23, 2010COP 4331 (C) Dr. David A. Workman5 Design Focus Areas Component and Module Design This design specifies the internal data structures and algorithms required for a given architectural unit to satisfy all its interface, functional, and non-functional requirements within a given operation context.

6. February 23, 2010COP 4331 (C) Dr. David A. Workman6 Flow of Design Decisions System Concept 1: Customer and users develop a vague and incomplete notion of what the system should/could do to solve their problem. System Boundary 2. Developer and Client capture and formalize system requirements defining precisely what the system will do, and what it will NOT do. Data Function Use Case Model Data Function Data Function Data Function Analysis Model Design Model 3: Developer and users define what data and functions the system must manipulate – these are organized into use cases. 4: Developer decomposes system into modules and their interface relationships – this is architectural design 5: Developer designs the internal structure of modules selecting data structures and algorithms to realize module requirements.

7. February 23, 2010COP 4331 (C) Dr. David A. Workman7 Design Models Invoice Mgmt Internal Component Module Interface: The features that are “visible” to client code - only these can be used to exercise the capabilities of the component/module. Example. Header files (.h) are used in C to declare types, constants, and function prototypes that are needed to access system objects such as files. In C++, header files declare namespaces and their classes. Data Control Data External Component IO UML notation for a “package” – packages can denote subsystems or any other type of “module” the designer wishes to represent. UML notation for a “analysis objects/classes” – Module Implementation: Detailed design activities specify how a module is organized internally to provide the capabilities offered via the module interface. Example. Implementation files in C (.c) or C++ (.cpp) encapsulate the bodies of functions.

8. February 23, 2010COP 4331 (C) Dr. David A. Workman8 Design Principles A good designer should consider alternative approaches. –Each alternative should be judged with respect to stated requirements. –Each alternative should be judged with respect to resources required for the solution and resources available to do the job. –Each alternative should be judged with respect to the design properties that affect design quality (presented later). A good design is traceable to the Analysis Model and to Software Requirements (Use Case Coverage Table & Traceability Matrix) A good designer will not “re-invent the wheel” If a good design exists and can be reused from some other source, then do not re- design the solution. Time and money are always in short supply. A good software engineer will always look for a ready-made solution before developing a new one. A good design should minimize “intellectual distance” between the software and the real world problem it is designed to solve. This is one of the most important benefits of the object-oriented approach to design. We will be emphasizing this point throughout the course.

9. February 23, 2010COP 4331 (C) Dr. David A. Workman9 Design Principles The design should exhibit uniformity and integration. –It should appear as if “one person” developed the entire system. There should be a well-defined set of coherent principles and rationale that guide design decisions throughout the system development. The description of the system uniformly should follow certain defined standards for style, format, and organization everywhere they could apply. –Interfaces between components should be documented completely and clearly using a consistent style and presentation format. The design should be structured to accommodate change. Again, the object-oriented approach tends to yield designs that satisfy this principle. A good design should be resilient to errors and handle them “gracefully” when they do occur. Design should be assessed for quality as it is being constructed, not after the fact. A design should be reviewed to minimize conceptual errors. Focus on omissions, ambiguity, and inconsistency before worrying about the syntax of the design model.

10. February 23, 2010COP 4331 (C) Dr. David A. Workman10 Design Principles Design is not coding and coding is not design! –The level of abstraction in the design model is well above that of the code. A good designer thinks at an abstract level, not in terms of how the code will look. –Design decisions that are appropriate during coding should only effect the choice of local data and algorithms used to implement a module and its interface – they should not impact the modularity of the system, nor impact their interface design.

11. February 23, 2010COP 4331 (C) Dr. David A. Workman11 Design Styles Increasingly Object Oriented Increasingly Functional Oriented Functional- (Monolithic) Functional+ OO- OO+ The progression from pure functional decomposition to pure object-oriented decomposition depends on increasing the following properties: the degree of abstraction (procedural and data) the degree of data encapsulation the degree of information hiding the degree of distributed control the degree of reusability

12. February 23, 2010COP 4331 (C) Dr. David A. Workman12 Functional Decomposition F1 F2 F3 F4 F5 F6 System modules are defined around system functions. Data is passed as parameters and returned as results. Persistent data is shared by defining global storage areas either in memory or on some external medium. Data types are limited to those provided by the implementation language and are typically are primitive. Data A Data B Data C Data D Data E Data A Data B Data D Data E Data C

13. February 23, 2010COP 4331 (C) Dr. David A. Workman13 Object-Oriented Decomposition A B C E D System modules are defined around problem data encapsulated with the operations that are specific to that data. All data encapsulated by an object persists beyond the operations that manipulate it. Objects may define new types. Methd f3 Methd f1 Methd f6 Methd f1 Methd f1 Methd f2 Methd f5 Methd f5 Methd f6 Methd f2 Methd f4

14. February 23, 2010COP 4331 (C) Dr. David A. Workman14 Design Properties Abstraction The frame of mind and set of concepts that permit the designer to reason about the problem and its solution at some level of generalization that disregards irrelevant details – it organizes the problem and its solution into a hierarchy of concepts, entities and their logical relationships. Problem Domain Solution Domain Concept Highest Level Lowest Level Level 1 2 3 4 5 Requirements Architectural design Algorithm design Analysis Code

15. February 23, 2010COP 4331 (C) Dr. David A. Workman15 Design Properties Abstraction (continued) Procedural abstraction: assigning a name, perhaps with defined parameters, to a well-defined and reusable computational process or algorithm. This allows the designer to reason in terms of inputs and results of the named computation without having to think about the details of how the computation will be accomplished or implemented. Example. “Functions in C” and “macros in C” can be used to implement procedural abstractions of design; “methods in Java”. Data abstraction: assigning a name (new type) to a collection of similar data values and a set of operations for manipulating those values. This allows the designer to treat as one conceptual unit a data structure and the procedural abstractions that manipulate that structure without having to worry about the details of how the data structure and its operations will eventually be implemented. Example. “Dialog Box” = { frame, title, label, button, text field } + { open, close, insert character, delete character, append character, display field, erase field }. “Classes and Interfaces in Java”

16. February 23, 2010COP 4331 (C) Dr. David A. Workman16 Design Properties Modularity A “module” is a separately named and addressable software unit that encapsulates and abstracts a set of related software capabilities and features. A module consists of an interface – for access by other modules – and an implementation – that specifies how the capabilities and features are realized in the implementation. –Modules permit programs to be designed, implemented and tested in an incremental fashion. –They provide a mechanism for managing software complexity and shortening the “conceptual distance” between the problem and its solution. –They provide a mechanism for creating layers of reusable software abstractions that build on one another enabling the designer to compose and configure them in different ways to create solutions to a broad family of problems. –They provide a mechanism for managing and localizing changes to software when new requirements become known or errors are discovered.

17. February 23, 2010COP 4331 (C) Dr. David A. Workman17 Design Properties Data Encapsulation Organizing and modularizing the program around distinct, program-defined data types or structures; that is, encapsulating a data type or structure by defining a separate module that contains the declarations necessary to define the type or data structure together with all the program operations (functions) that manipulate the type. Data Capsules ought to contain all and only those operations for which knowledge of the representation is necessary to perform their function. Information Hiding Exploiting language mechanisms and encapsulation techniques to hide details about the representation of data structures and types for the purpose of making it increasingly difficult, if not impossible, for clients of a data type or structure to directly access and manipulate the internal content or composition of that type or structure. A “client” is any program component that has no need to know or directly use the internal representation of a type or structure. Distribution of Control Computation control, like the internal representation of data types and structures, should be distributed among components to promote maintainability and performance of individual system components, as well as of the system as a whole. This also promotes reusability.

18. February 23, 2010COP 4331 (C) Dr. David A. Workman18 Design Properties Reusability Organizing the modular design around components that have a high potential for reuse in other applications. Reusability is generally achieved by designing components that have one or more of the following properties or characteristics: –Well-defined interface: making public all and only those component features that are necessary for its use. –Generality: parameterizing the component’s design to broaden to the contexts in which the component will function correctly, without greatly sacrificing other qualities of good design (e.g performance). –Portability: designing a component to be function correctly on a variety of hardware platforms and operating environments. –Interoperability: designing a component to interact through a uniform interface with a variety of external programs that may have been written in different languages and may be running in different operational environments.