CS 451 Software Engineering Introduction to Software DesignAbout DesignAbout Design (cont’d)Elements of the Design ProblemDesign SolutionsSoftware DesignSoftware DesignSoftware DesignArchitectural Design Sample DiagramArchitectural Design Sample DiagramArchitectural Design Sample DiagramLow-level Design Class DiagramLow-level Design Class SpecificationLow-level Design Sequence DiagramSoftware Design in the Life CycleSoftware Design GoalsSoftware Design Goals (cont’d)Software Design Goals (cont’d)We Deal With Complexity!Very Useful ToolsImportant Design QualitiesModularity (cont’d)Information HidingCohesionCouplingCoupling (cont’d)Hierarchical StructuresQuestionModularityCS 451Software EngineeringIntroductionto Software Design 1About Design•Design is ubiquitous in practical affairs–Architecture–Engineering (Automotive, Industrial, etc.)–…–Computing•Design involves making something (where“making” is not from an existing plan). •Different kinds of problems pose different demands. 2About Design (cont’d)“There are two ways of constructing a software design:one way is to make it so simple that thereare obviously no deficiencies;the other is to make it so complicated thatthere are no obvious deficiencies.”C.A.R. Hoare (1985)3Elements of the Design Problem•Five elements of design problems:–Goals–Constraints–Alternatives–Representations–Solutions4Design Solutions•Characteristics of solutions:–The solution to a design problem is a description enabling system construction.–Design solutions are complex.–Most design problems have many acceptable solutions.–It is difficult to validate design solutions (consequence of complexity).5Software Design•Software Architectural Design•Software Detailed Design6Software Design•Software Architectural Design–The top-level structure and organization of the system is described and the various components are identified.•Software Detailed Design–Each component is sufficiently designed to allow for its coding.7Software Design•Software Architectural Design–The top-level structure and organization of the system is described and the various components are identified.•Software Detailed Design–Each component is sufficiently designed to allow for its coding.•UI design and Real-time design are “specialized” areas of Software Design.8Architectural Design Sample Diagram9Architectural Design Sample Diagram10Architectural Design Sample Diagram11Low-level Design Class Diagram12Low-level Design Class Specification13- from: int- amount: Money+ Withdrawal(atm: ATM, session: Session, card: Card, pin: int)# getSpecificsFromCustomer(): Message throws Cancelled# completeTransaction(): Receipt- from: int- amount: Money+ Withdrawal(atm: ATM, session: Session, card: Card, pin: int)# getSpecificsFromCustomer(): Message throws Cancelled# completeTransaction(): ReceiptWithdrawalWithdrawal- from: int- to: int- amount: Money+ Transfer(atm: ATM, session: Session, card: Card, pin: int)# getSpecificsFromCustomer(): Message throws Cancelled# completeTransaction(): Receipt- from: int- to: int- amount: Money+ Transfer(atm: ATM, session: Session, card: Card, pin: int)# getSpecificsFromCustomer(): Message throws Cancelled# completeTransaction(): ReceiptTransferTransferLow-level Design Sequence Diagram14Software Design in the Life Cycle•Software requirements analysis•System Architecture•Software Design•System Verification & Validation15Software Design Goals•Correctness–Ensure that the code does what’s intended to do.•Robustness–Handle miscellaneous and unusual conditions, such as bad data, user error, programmer error, and environmental conditions.•Flexibility –The requirements will change… many times (e.g., handle more kinds of (bank) accounts without needing to change the existing design or code.)16Software Design Goals (cont’d)•Efficiency –Program execution should be as fast as required (using available resources, such as memory, disk, network bandwidth, etc). •Quality / Reliability–”Clean” designs facilitate the implementation of error-free code. •Usability–Users should find the product easy to use.17Software Design Goals (cont’d)•Reusability–Be able to easily modify [the design / implementation] so that it can be reused.•Maintainability–Experienced developers (unfamiliar with the code) should be able to easily figure out the organization of the code, how things work, and be able to safely modify the code.Good code is not necessarily good design. 18We Deal With Complexity!•Problem domain complexity:–Functional requirements•functionality, users, etc. –Non-functional requirements•performance•usability•reliability•cost–Interfacing with the outside world (e.g., other evolving s/w systems)F•Unstable requirements.•Immature specification, design, and development methods. 19Very Useful Tools•Decomposition (divide-and-conquer)–We decompose complex problems into smaller and smaller parts, each of which we then refine independently.•Abstraction–We concentrate on a problem at some generalized level without regard to irrelevant low-level details.•Hierarchy–We group objects with common properties and use their relationships to create easy-to-deal-with organizational structures. 20Important Design Qualities•These tools apply to software design very well, and over time they have given rise to some important software design qualities, such as:–Modularity–Information hiding –Strong Cohesion–Weak coupling–Hierarchical organizational structures.21Modularity (cont’d)•Abstraction is an extremely powerful mechanism for dealing with complexity and understanding large systems.•A good programmer knows how to:–find the abstractions in a large program.–express a large program’s abstraction via its modularity."Everything should be made as simple as possible, but not simpler.”A. Einstein22Information Hiding•Ability to prevent certain aspects of a module from being accessible by its clients.•Why is this important?•How is that implemented in Java?23Cohesion•A well-designed module has strong cohesion–A module’s functions should be strongly related to each other.–Strong cohesion facilitates abstraction•Example ???24Coupling•A well-designed module has weak coupling.–A module should be weakly connected to to other modules in the program–Interaction within modules should be more intense than interaction among