1

What is Software Design?• Software design sits at the technical kernel of

software engineering and is applied regardless of the software process model that is used.

• Beginning once the software requirements have been analyzed and modeled.

• This is the last software engineering action within the modeling activity and sets the stage for construction(code generation and testing)

2

Design...• Explaining the idea/concept of something

• Usually with graphical diagrams

• The design is a representation of a product or a system with sufficient detail for implementation

3

Design...• From our understanding of the problem, we start

building the software• Translate the analysis model into the design

model• Map the information from the analysis model to

the design representations - data design, architectural design, interface design, procedural design

4

5

6

Data/Class design

• Transforms the analysis-class models into design class realizations and the requisite data structures required to implement the software.

• Makes use of Class-based elements.

Analysis Design...Architectural design

• Framework of a computer-based system• Defines the relationships between major

structural elements of the software.• Makes use of Class-based and Flow-

oriented elements.

7

Analysis Design...Interface Design

• Describes how the software communicates with systems that interoperate with it, and with humans who use it.

• An interface implies a flow of information (data and control) and a specific type of behavior.

• Makes use of Scenario-based, Behavioral, and Flow-oriented elements.

8

Analysis Design...Component-level design

• Transforms the structural elements of the software architecture into a procedural description of software components.

• Makes use of Class-based, Flow-oriented and Behavioral elements.

9

Design principlesPrinciple #1: Design should be traceable to the

analysis model.Principle #2: Always consider the architecture of

the system to be built.Principle #3: Design of data is as important as

design of processing functions.Principle #4: Interfaces(both internal and

external) must be designedPrinciple #5: User interface design should be

tuned to the needs of the end-user10

Design principles...Principle #6: Component-level design should be

functionally independent.Principle #7: Components should be loosely

coupled to one another and to external environment.

Principle #8: Design representations(models) should be easily understandable.

Principle #9: The design should be developed iteratively. With each iteration the designer should strive for greater simplicity.

11

Design quality• The importance of software design can be

stated with a single word- quality.• Design is the place where quality is

fostered in software engineering.• Design is the only way that we can

accurately translate a customer’s requirements into a finished software product or system.

12

Design and qualityThree characteristics that serve as a guide for the evaluation of a good design

• The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.

13

Design and quality....• The design must be a readable,

understandable guide for those who generate code and for those who test and subsequently support the software.

• The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

14

Quality guidelines• A design should exhibit an architecture that (1) has been created using recognizable architectural

styles or patterns, (2) is composed of components that exhibit good design

characteristics and (3) can be implemented in an evolutionary fashion• A design should be modular; that is, the software should be

logically partitioned into elements or subsystems• A design should contain distinct representations of data,

architecture, interfaces, and components.• A design should lead to data structures that are appropriate

for the classes to be implemented and are drawn from recognizable data patterns.

15

Quality guidelines...• A design should lead to components that exhibit

independent functional characteristics.• A design should lead to interfaces that reduce

the complexity of connections between components and with the external environment.

• A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

• A design should be represented using a notation that effectively communicates its meaning.

16

Quality attributesAcronym FURPSFunctionality is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that

are delivered, and the security of the overall system.Usability is assessed by considering human factors, overall aesthetics, consistency and documentation.Reliability is evaluated by measuring the frequency and severity

of failure, the accuracy of output results, the mean-time-to- failure(MTTF), the ability to recover from failure, and the predictability of the program.

17

Quality attributes...Performance is measured by processing speed, response

time, resource consumption, throughput, and efficiency.Supportability combines extensibility, adaptability,

serviceability- these 3 attributes represent a more common term,

maintainability, the ease with which a system can be installed, and the

ease with which problems can be localized.

18

Design Concepts

Abstraction — data, procedure, controlArchitecture — the overall structure of the softwarePatterns — “conveys the essence” of a proven design

solutionModularity — compartmentalization of data and function Information hiding — controlled interfacesFunctional independence — high cohesion and low couplingRefinement — elaboration of detail for all abstractionsRefactoring — improve design without effecting behavior

19

AbstractionAbstraction

process – extracting essential details

Information hidingthe suppression of inessential information

20

Data Abstraction

21

doordoor

implemented as a data structure

manufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights typetype numbernumberweightweightopening mechanismopening mechanism

Procedural Abstraction

22

openopen

implemented with a "knowledge" of the object that is associated with enter

details of enter details of enter algorithmalgorithm

Architecture

23

““ The overall structure of the software and the ways in The overall structure of the software and the ways in which that structure provides conceptual integrity for a which that structure provides conceptual integrity for a system.” system.”

Structural modules. Structural modules. Represent the architecture as an organized Represent the architecture as an organized collection of program components collection of program components . . Dynamic models. Address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of external events.

Process models. Focus on the design of the business or technical process that the system must accommodate.

Functional models. Represent the functional hierarchy of the system.

24

PatternsA pattern design conveys the essence of a proven solution to a recurring problem within a certain context.Each design pattern should provide the foll• Whether the pattern is applicable to the current problem• Whether the pattern can be reused• Whether the pattern can be used as a guide to develop

similar different pattern

25

Patterns

26

Design Pattern TemplateDesign Pattern TemplatePattern namePattern name—describes the essence of the pattern in a short but —describes the essence of the pattern in a short but expressive name expressive name IntentIntent—describes the pattern and what it does—describes the pattern and what it doesAlso-known-asAlso-known-as—lists any synonyms for the pattern—lists any synonyms for the patternMotivationMotivation—provides an example of the problem —provides an example of the problem ApplicabilityApplicability—notes specific design situations in which the pattern is —notes specific design situations in which the pattern is applicableapplicableStructureStructure—describes the classes that are required to implement the —describes the classes that are required to implement the patternpatternParticipantsParticipants—describes the responsibilities of the classes that are —describes the responsibilities of the classes that are required to implement the patternrequired to implement the patternCollaborationsCollaborations—describes how the participants collaborate to carry —describes how the participants collaborate to carry out their responsibilitiesout their responsibilitiesConsequencesConsequences—describes the “design forces” that affect the pattern —describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the and the potential trade-offs that must be considered when the pattern is implementedpattern is implementedRelated patternsRelated patterns—cross-references related design patterns—cross-references related design patterns

Modular Design

27

easier to build, easier to change, easier to fix ...

Modularity: Trade-offs

28

What is the "right" number of modules What is the "right" number of modules for a specific software design?for a specific software design?

optimal numberoptimal number of modulesof modules

cost ofcost of softwaresoftware

number of modulesnumber of modules

modulemoduleintegrationintegration

costcost

module development cost module development cost

Information Hiding

29

modulemodulecontrolledcontrolledinterfaceinterface

"" secret"secret"

• • algorithmalgorithm

• • data structuredata structure

• • details of external interfacedetails of external interface

• • resource allocation policyresource allocation policy

clientsclients

a specific design decisiona specific design decision

Why Information Hiding?

• 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

30

Functional Independence

31

COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

Stepwise Refinement

32

open

walk to door;reach for knob;

open door;

walk through;close door.

repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat

RefactoringFowler [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.”

When software is refactored, the existing design is examined for

redundancyunused design elements inefficient or unnecessary algorithmspoorly constructed or inappropriate data structuresor any other design failure that can be corrected to yield a better design.

33

Design Classes

User interface classes – define abstractions necessary for HCI.

Business domain classes – refinements of analysis classes.

Process classes – lower-level business abstractions that manage business domain classes.

Persistent classes – data stores (databases) that persist beyond execution of the software.

System classes – management and control functions that enable the system to operate and communicate within its computing environment and with the outside world. 34

Well-formed Design ClassComplete and sufficient – class should be a

complete and sufficient encapsulation of reasonable attributes and methods.

Primitiveness – each method should be focused on one thing.

High cohesion – class should be focused on one kind of thing.

Low coupling – collaboration should be kept to an acceptable minimum.

35

CASE STUDY

CAFETERIA MANAGEMENT SYSTEM

36

37

CMS

Meal Order Meal Delivery Payroll System

Place Order Cancel Order Receive Meal Order

Prepare Meal

System Architecture Level 1

Deliver Meal

38

Meal Order

Place Order Cancel Order

Read Menu Select Delivery Option

Select Order ID

Meal Cancel

System Architecture Level 2

39

Meal Delivery

Receive Meal Order

Prepare Meal Deliver Meal

Check Inventory

Status

Update the Menu

Send Delivery request

Print Request

System Architecture Level 2

40

Payment Request

Check Inventory

Status

Payroll deduction

Generate BillSelect Pay Method

System Architecture Level 2

41

42

43