1. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Chapter 9 Class will start momentarily. Please Stand By … CS 8532: Advanced Software Engineering Dr. Hisham Haddad

2. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Engineering Highlights of Software Design Concepts and Principles Chapter 9

3. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad What is Software Design? Design is a technical activity during which customer requirements are transformed into architectural elements (blue print for the software to be built). - It is a representation form of a computer software - It answers the “how” question: How to realize the requirements? - It is iterative (refinement) process - Its representation can be assessed for quality (FTRs, Walkthroughs, informal meetings, etc…) - It is the basis for system flexibility, extensibility, portability, and reusability - It consists of process (sequence of steps) and a model (presentations of design elements)

4. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Software Design Challenges - Complexity: complexity factors, > nature of the system (having many states during execution) > complexity is arbitrary as it is dependent on the design rather than the problem - Conformity: must conform to standards forced by other elements such as HW, existing software, external entities - Invisibility: being invisible, > limits our ability to form a visual links with software system > limits our ability to conceptualize its characteristics - Changeability: Software tends to have constant need for changes.

5. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad The Big Picture - Process & Model Specs Prototype modeling Design Process Design Model (SDD) Design’s decisions Constraints (resources, organizational, reuse, experience, etc..)

6. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Another view* Specs Architectural design decisions Logical design details Physical design details Detailed design decisions * Source: Software Engineering, 2nd ed., by David Budgen

7. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Elements of Structured Design Data Design: Creating data structures. (use data dictionary and ERD information) Architectural Design: Creating the software framework, that is processing components that transform inputs to outputs. (use high-level DFD information and design patterns) Interface Design: Creating elements (interfaces) that glue the pieces of the architecture. (use DFD, CFD and STD information) Component Design: Creating algorithmic details for individual components of the architecture. (use DFD, CDF and STD information)

8. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Generic Components of OOD - Problem Domain Component: The subsystems that are responsible for implementing customer requirements directly. - Human Interaction Component: The subsystems that implement the user interface (this included reusable GUI subsystems). - Task Management Component: The subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems. - Data Management Component: The subsystem that is responsible for the storage and retrieval of objects.

9. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Mapping Structured Analysis to Design Data Dictionary STD ERD DFD interf a ce design architectural design data design Component design

10. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad OOA and OOD - 1 OO Analysis OO Design Implementation OO Testing Deployment Object Relationship Modeling Class Modeling Object Behavior Modeling OO Analysis OO Design Implementation OO Testing Deployment Class Design Sub-System Design Message Design Responsibilities Design

11. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad OOA and OOD - 2 Another mapping view: Classes Attributes Methods Relationships Behavior Analysis Model Objects Data Structures Algorithms Messaging Control Design Model

12. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Mapping OO Analysis to OO Design Design Patterns (domain Objects) Responsibilities Design Subsystem Design Class/Object Design Message Design Use Cases Object Behavior Model Class Model Object Relatio- nships Attributes Operations Collaborators

13. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad OOD Layers - 1 - Design Patterns: Deals with reusable designs (domain objects). (repeated (reusable) classes and objects that found to solve specific design problems, e.g., user login and authentication, integrated circuit, car air-condition system, shopping cart, etc…) - Subsystem Design: Deals with subsystems that form the overall system architecture. (detailed design of self-contained and highly-independent groups of classes that define specific requirements (major functions of the system))

14. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad OOD Layers - 2 - Class/Object Design: Deals with relationships among classes that define each subsystem. (detailed design of inheritance hierarchies for subsystems) - Message Design: Deals with internal and external interface design. (detailed design of messages exchanged among objects and interactions between system objects and external entities) - Responsibilities Design: Deals with data structures and algorithm design. (internal detailed design of each class - its attributes and operations)

15. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Good Design Guidelines - 1 A good design is based on design principles and employs design concepts throughout the design elements. - It should be iterative in nature (follow the design process) and is derived from requirements (traceable to requirements). - It should exhibit distinct representation for data, structure, interfaces, and components (present design components). - It should exhibit architectural structure with good design characteristics (reusable design patterns and easy to implement). - It should be modular (logical functional partitioning).

16. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Good Design Guidelines - 2 - It should lead to relevant data structures. - It should lead to functionally independent components (minimize coupling among modules). - It should lead to effective interfacing with external entities (minimize system complexity). - It should lead to flexible software (refinement and updates). - It should lead to portable software architecture (facilitate different platforms and future migrations) - It should lead to reusable systems (support evolution of domain applications)

17. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design and Quality The design must implement all explicit requirements of the analysis model, and must accommodate all implicit requirements desired by the customer. The design must be a readable and understandable “guide” for the construction team (development and testing people). The design should provide a complete picture of the software., That is, modeling the data, functional, and behavioral from implementation perspective.

18. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Principles - 1 Software design consists of a process and a model. - The design process should not suffer from ‘tunnel vision’ (explore your options) - The design should be traceable to the analysis model (addressing all customer requirements,explicit and implicit) - The design should not reinvent the wheel (use existing solution structures - design patterns) - The design should mimic the structure of the problem (completeness, quality assessment, testing, etc…) - The design should exhibit uniformity in style and format (i.e., it appears to be done by one person!)

19. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Principles - 2 - The design should exhibit well defined interfaces for components and external entities (ease of integration) - The design should be structured to accommodate change (ease of re-organization and additions) and to degrade gently (graceful termination of software) - Design is not coding, coding is not design (abstraction levels) - The design should be assessed for quality as it is being created, not after the fact. - The design should be reviewed to minimize conceptual errors (that is, semantic errors rather than syntax)

20. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Concepts Essential design concepts include: - Abstraction: data, procedure, control - Refinement: elaboration of detail for all abstractions - Modularity: compartmentalization of data and function - Software Architecture: overall structure of software components - Data Structures: logical relationships among data elements - Information Hiding: controlled interfaces/access - Functional Independence: high cohesion and low coupling - Patterns: ”conveys the essence” of a proven design solution - Refactoring: reorganization technique that simplifies the design

21. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Abstraction Mutli-level details of the software design. Each level is a refinement of the previous level (data and procedures). At the highest level --> general description of the system At the lowest level --> creating source code Door Data Manufacturer Model number Material type Swing direction Color Weight etc… Door Procedures Open Door Close Door Lock Door

22. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Refinement Stepwise top-down elaboration of abstractions to reveal their detailed as design progresses. Refinement prevents omissions of details and facilitates design review. Refinement complements abstraction. Walk to door; Reach for knob; Open door; Walk through; Close door; repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

23. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Modularity - 1 easier to build, easier to change, easier to fix...

24. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Modularity - 2 Dividing the system into manageable functional components. A modular design is easier to build, to change, and to fix. Effective modular design is depended on the design method. Guidelines for method evaluation include: - Modular decomposability (support for sub-problems) - Modular compensability (allow reuse) - modular understandability (can a module stand on its own?) - Modular continuity (change impact contained to individual modules, not the entire system) - Modular protection (error impact is contained within the module where it occurred)

25. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Modularity - 3 What is the right number of modules for a specific design? desired number of modules cost of software number of modules module integration cost module development cost

26. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Software Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] Organization (structure) of components representing elements of the software and their interactions (Ch-10). Properties of an architectural design include: - Structural properties (components and interactions) - Extra-structural properties (performance/reliability/security…) - Families of related systems (reusable architectural building blocks - reusable subsystems and patterns)

27. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Data Structures Data structure is a representation of the logical relationship among data elements of a a data object. The logical relationship dictates the data structure complexity. - scalar structure: one data item structure - sequential (linear) structures: vectors (arrays) of data items - multi-dimension (non-linear) structure: array of data items The implementation view is the organization of data items in the computer memory during software execution. - contiguous storage - linked storage (linked lists)

28. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Information Hiding - 1 It calls for hiding maximum information (procedures and data) from other modules to provide controlled access. specific design decisions Module Controlled Interface "secrets" clients algorithm data structure details of external interface resource allocation policy

29. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Information Hiding - 2 Some benefits: - Reduces the likelihood of “side effects” - Limits the global impact of local design decisions - Emphasizes communication through controlled interfaces - Discourages the use of global data - Leads to encapsulation - an attribute of high quality design - Results in higher quality software - Facilitates maintainability

30. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Functional Independence Functional independence is the outcome of abstraction, modularity, and information hiding. An independent function is one that performs (implements) a well- defined function (sub-function) of the software with high cohesion and low coupling. Cohesion measures the degree to which a module performs one and only one function/task with little interactions with other modules. Coupling measures the degree to which a module is connected to (dependent on) other modules in the system.

31. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Patterns Design Pattern Template (handout and slides are posted) Pattern name: Describes the essence of the pattern in a expressive name Intent: describes the pattern and what it does Also-known-as: lists any synonyms for the pattern Motivation: provides an example of the problem Applicability: notes specific design situations in which the pattern is applicable Structure: describes the classes that are required to implement the pattern Participants: describes the responsibilities of the classes that are required to implement the pattern Collaborations: describes how the participants collaborate to carry out their responsibilities Consequences: describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is implemented Related patterns: cross-references related design patterns.

32. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Refactoring Fowler [FOW99] defines Refactoring in the following manner: "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.” During refactoring, the design is examined for : - Redundancy - Unused design elements - Inefficient or unnecessary algorithms - Poorly constructed or inappropriate data structures - Any other design failure that can be corrected to yield a better design.

33. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad OO Design Concepts Design classes –Entity classes –Boundary classes –Controller classes Inheritance: All responsibilities of a superclass is immediately inherited by all subclasses Messages: Stimulate some behavior to occur in the receiving object Polymorphism: A characteristic that greatly reduces the effort required to extend the design

34. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Classes Analysis classes are refined during design to become entity classes. Boundary classes are developed during design to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. - Boundary classes are designed with the responsibility of managing the way entity objects are represented to users. Controller classes are designed to manage -The creation or update of entity objects; -The instantiation of boundary objects as they obtain information from entity objects; -Complex communication between sets of objects; -Validation of data communicated between objects or between the user and the application.

35. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Inheritance Design options: - The class can be designed and built from scratch. That is, inheritance is not used. - The class hierarchy can be searched to determine if a class higher in the hierarchy (a superclass) contains most of the required attributes and operations. The new class inherits from the superclass and additions may then be added, as required. - The class hierarchy can be restructured so that the required attributes and operations can be inherited by the new class. - Characteristics of an existing class can be overridden and different versions of attributes or operations are implemented for the new class.

36. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Messages : :SenderObject : :ReceiverObject message ( )

37. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Polymorphism Conventional approach … case of graphtype: if graphtype = linegraph then DrawLineGraph (data); if graphtype = piechart then DrawPieChart (data); if graphtype = histogram then DrawHisto (data); if graphtype = kiviat then DrawKiviat (data); end case; With polymorphism, all of the graphs become subclasses of a general class called graph. Using overloading, each subclass defines an operation called draw. An object can send a draw message to any one of the objects instantiated from any one of the subclasses. The receiving object invokes its own draw operation to create the appropriate graph.

38. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Model Elements - 1 Data element –Data model  data structures (at component level) –Data model  database architecture (at application level) –Data model  data warehouse (at business level) –Data structures influence the software architectural Architectural element (floor plan) An architecture is derived from: –Application domain –Analysis model (classes, their relationships, collaborations and behaviors) –Patterns and “architectural styles” (Chapter 10)

39. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Model Elements - 2 Interface design element It is the design of interactions with the system, including: –the user interface (GUI elements) (Chapter 12) –external interfaces to other systems, devices, networks, … –internal interfaces between various design components. Component elements It’s the design of internal data and algorithms details of classes. Deployment elements It’s the design of the physical environment where the system will be hosted and supported (networks, servers, users, locations, etc…) (see figure 9.7, page 247)

40. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Patterns - 1 A good designers has the ability to identify “patterns” that characterize a problem and corresponding patterns that can be combined to create a solution. A description of a design pattern may include design forces. –Design forces describe non-functional requirements (environment and conditions) needed to apply design patterns. (e.g., ease of maintainability, portability, usability) The pattern characteristics (classes, responsibilities, and their collaborations) indicate attributes that may be adjusted to enable the pattern to accommodate different problems.

41. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Design Patterns - 2 Reusable patterns include: –Architectural patterns: ways (styles) to structure elements (components) of a software system. –Design Patterns: ways to solve design-specific issues. (see posted design pattern handout and slides) – Coding patterns (idioms): language-specific patterns to address coding-specific issues

42. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Frameworks A framework is not an architectural pattern, but rather a “code skeleton with a collection of “plug points” (also called hooks and slots) that allows designers/developers to adapt it to a specific domain of applications. They are applied without changes. Gamma et al note that: –Design patterns are more abstract than frameworks. –Design patterns are smaller architectural elements than frameworks. –Design patterns are less specialized than frameworks.

43. CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Suggested Problems Consider working the following problems from the end of chapter 9, page 251, for practice purpose: 9.1, 9.2, 9.3, 9.5, 9.7, 9.8, 9.9, 9.10, and 9.11 No submission is required. Think about these problems and work them for yourself!