CS 3610 Software Engineering Spring 2009 Dr Hisham

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 9 Design Engineering Highlights of Software Design Concepts and Principles

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. The Big Picture - Process & Model modeling Specs Design Process Design’s decisions Prototype Design Model (SDD) Constraints (resources, organizational, reuse, experience, etc. . )

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Another view* Specs Architectural design decisions Logical design details * Source: Software Engineering, 2 nd ed. , by David Budgen Detailed design decisions Physical design details

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Mapping Structured Analysis to Design DFD ERD Data Dictionary STD Component design interface design architectural design data design

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. OOA and OOD - 1 OO Analysis OO Design Implementation OO Testing Deployment Class Modeling Object Relationship Modeling Object Behavior Modeling OO Analysis OO Design Implementation OO Testing Deployment Sub-System Design Message Design Class Design Responsibilities Design

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. OOA and OOD - 2 Another mapping view: Analysis Model Classes Design Model Objects Attributes Data Structures Methods Algorithms Relationships Messaging Behavior Control

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Mapping OO Analysis to OO Design Attributes Operations Collaborators Class Model Object Relationships Use Cases Object Behavior Model Responsibilities Design Message Design Class/Object Design Subsystem Design Patterns (domain Objects)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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))

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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).

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Design and Quality What makes a good design? • 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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!)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Modularity - 1 easier to build, easier to change, easier to fix. . .

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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 design 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Modularity - 3 What is the right number of modules for a specific design? module development cost of software module integration cost number of modules desired number of modules

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Software Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system. ” [SHA 95 a] 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Data Structures Data structure is a representation of the logical relationship among data elements of 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)

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

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Functional Independence Functional independence is the outcome of abstraction, modularity, and information hiding. An independent function is one that performs (implements) a welldefined 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Refactoring Fowler [FOW 99] 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Messages : : Sender. Object message (<parameters>) : : Receiver. Object

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Polymorphism Conventional approach … case of graphtype: if graphtype = linegraph then Draw. Line. Graph (data); if graphtype = piechart then Draw. Pie. Chart (data); if graphtype = histogram then Draw. Histo (data); if graphtype = kiviat then Draw. Kiviat (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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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)

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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.

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. 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!

CS 3610: Software Engineering – Spring 2009 Dr. Hisham Haddad – CSIS Dept. Last Slide End of Chapter 9