Sommerville, Mejia-Alvarez, 2009Software Engineering, Slide 1 Software Design u Deriving a solution...

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 1

Software Design

Deriving a solution which satisfies software requirements

Objectives

To introduce the process of software design To describe the different stages in this design

process To show how object-oriented and functional

design strategies are complementary To discuss some design quality attributes

Programmer’s Approach to Software Engineering

Skip requirements engineering and design phases; start writing code

Why this programmer’s approach?

Design is a waste of time

We need to show something to the customer real quick

We are judged by the amount of LOC/month

We expect or know that the schedule is too tight

Design of small and large systems

aTruck aShip aAirplane theWarehouseCo llecti on

theVehicleCollection

UML-A Generated Dependency Class:theRouter Dependency (1.0)

theStorage

aVehicle

availableVehicleCollection

UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Genera ted As socia tion C lass: theVehicleC ollec tion Genera lization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML- A Generated Ass ociati on Cl ass:theVehi cleCo llection Generali zation (1.0 )UML-A Generated Association Class:theVehicleCollection Generalization (1.0)

availableGoods

aPortC ollec tion

aSurp lus aDifficiency

theTimeNeeded

theGoods

UML-A Generated Association Class:aWarehouse Association (0.5)

UML-A Generated Association Class:availableGoods Association (0.5)

aRouteCollection

UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)

UML-A Generated Dependency Class:theRouter Dependency (0.5)UML-A Generated Dependency Class:theRouter Dependency (1.0)

theAWT

aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog

aWarehouse

UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)

UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency Associ ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency Associ ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Genera ted Associ ation C lass:aSurp lus Associ ation (1.0)UML-A Generated Association Class:aSurplus Association (0.5)

UML-A Generated Associ ation Class:aRoute Association (0.5)

aLocation

UML-A Generated Association Class:aNavPoint Association (1.0)

UML-A Generated Association Class:aNavPoint Association (0.5)UML-A Generated Association Class:aNavPoint Association (0.5)

UML-A Generated Association Class:aWarehouse Association (0.5)aNavPoint

UML-A Generated Association Class:aWarehouse Association (0.5)UML-A Generated Association Class:aWarehouse Association (0.5)

UML-A Generated Association Class:aRoute Association (0.5)

aRoute

UML-A Genera ted Dependency C lass :aRou teCol lection Ass ociation (0.25)

UML-A Generated Dependency Class:aRouteCollection Association (0.5)

UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)

UML-A Generated Dependency Class:theRouter Association (0.25)

theCargoRouter

UML-A Generated Association Class:theRouter Association (0.25)

UML-A Genera ted As socia tion C lass: theWarehouseCo llection Dependency ( 0.25)

UML-A Generated Association Class:theRouter Association (0.25)

t heRou ter

UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)

UML-A Genera ted Dependency Class :aRouteCollection Ass ociation (0.5)UML-A Generated Association Clas s:theWarehouseCollec tion Dependency (0.5)

UML-A Generated Association Class:theVehicleCollection Dependency (0.5)UML-A Generated Association Class:availableVehicleCollection Dependency (0.5)UML- A Generated Generaliz ation Class :avail ableVehicleCollection Dependenc y (1.0 )

UML-A Generated Dependency Class:theRouter Association (0.5)UML-A Generated Dependency Class:theRouter Association (1.0)

UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)

UML-A Generated Dependency Class:theRouter Association (1.0)UML-A Generated Dependency Class:theRouter Association (1.0)

What is the Problem?This is a simple

software system!

aTruck aShipaAirplane

availableVehicleCollection

theAWT

aVehiceDialogaWarehouseDialog

aPortDialog

aRouterDialog

aRouteCollection

aVehicle

theVehicleCollection

theCargoRouter

theRouter

theTim eNeeded

aRoute

aDeficiency

theWarehouseCollection

aNavPoint

theStorage

RefrigeratedStorage

RegularStorage

availableGoods

aPortCollection

aLocation

theGoods

aWarehouse

aSurplus

The Usual Tool: Design Abstraction

We have to do better!

VehicleDel iveryPort

CargoRouter

RouterConn

GraphicsBinding : GraphicsBinding

GraphicsConn

Warehouse

ClockConn

Clock : Clock

10: notification9: notification

5: request

3: request4: request

2: notification

1: request

7: request

6: notification

8: request

Architectural Abstraction

What is not Design Design is not programming. Design is not modeling. Modeling is part of the architectural

design. Design is not part of requirements. Where requirements finishes and where design starts ?. Requirements = What the system is supposed to do. Design = How the system is built.

What is Design (or Architecture?) A high-level model of a software system

• Describes the structure, functionality and characteristics of the software system.

• Understandable to many stakeholders

• Allows evaluation of the system’s properties before it is built

• Provides well understood tools and techniques for constructing the thing from its blueprint

A software system’s blueprint• Its components• Their interactions• Their interconnections

Which aspects of a software system are architecturally relevant?

What is Design (or Architecture?)

How should they be represented most effectively to enable stakeholders to understand, reason, and communicate about a system before it is built?

What tools and techniques are useful for implementing an architecture in a manner that preserves its properties?

We design the software but we must consider the hardware (and the environment).

Design must reflect requirements, and we must be able to relate each requirements with parts of the design.

How can we include non-functional requirements into the design?

Stages of design Problem understanding

• Look at the problem from different angles to discover the design requirements

Identify one or more solutions• Evaluate possible solutions and choose the most

appropriate depending on the designer's experience and available resources

Describe solution abstractions• Use graphical, formal or other descriptive notations to

describe the components of the design

Repeat process for each identified abstraction until the design is expressed in primitive terms

From informal to formal design

Informaldesignoutline

Informaldesign

Moreformaldesign

Finisheddesign

The design process

The system should be described at several different levels of abstraction

Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary

Phases in the design process

Architecturaldesign

Abstractspecificatio

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

Design phases Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system interfaces Component design Decompose sub-systems

into components Data structure design Design data structures to

hold problem data Algorithm design Design algorithms for problem

functions

From Requirements to Architecture From problem definition to requirements specification

• Determine exactly what the customer and user want

• Specifies what the software product is to do

From requirements specification to architecture• How do we plan to build (design) the system ?

• Decompose software into modules with interfaces

• Specify high-level behavior, interactions, and non-functional properties

• Consider key tradeoffs» Schedule vs. Budget» Cost vs. Robustness» Fault Tolerance vs. Size» Security vs. Speed

• Maintain a record of design decisions and traceability

• Specifies how the software product is to do its tasks (from design to programming).

Architectural design An early stage of the system design process. Represents the link between specification and design

processes. Where do we finish requirements and start design ?. Often carried out in parallel with some specification

activities. It involves identifying major system components and

their communications.

Advantages of explicit architecture

From Requirements to Design Stakeholder communication

• Architecture may be used as a focus of discussion by system stakeholders.

System analysis• Means that analysis of whether the system can meet its non-

functional requirements is possible.

Large-scale reuse• The architecture may be reusable across a range of systems.

From Design to Programming ,Testing & Mantenaince.

Architecture and system characteristics

How the system must be designed to achieve:

Performance Security Safety Reliability Availability Maintainability Quality

Architectural design process

System structuring• The system is decomposed into several principal sub-systems

and communications between these sub-systems are identified

Control modelling• A model of the control relationships between the different parts

of the system is established

Modular decomposition• The identified sub-systems are decomposed into modules

Design quality

Design quality is an elusive concept. Quality depends on specific organisational priorities

A 'good' design may be the most efficient, the cheapest, the most maintainable, the most reliable, etc.

The attributes discussed here are concerned with the maintainability of the design

Quality characteristics are equally applicable to function-oriented and object-oriented designs

Design principles

Abstraction Modularity, coupling and cohesion Information hiding Limit complexity Hierarchical structure Understandability Adaptability

Abstraction

procedural abstraction: natural consequence of stepwise refinement: name of procedure denotes sequence of actions

abstraction subproblems

Abstraction

data abstraction: aimed at finding a hierarchy in the data

application-orienteddata structures

simpler datastructuregeneral

data structures

Modularity structural criteria which tell us something about

individual modules and their interconnections

cohesion and coupling

cohesion: the glue that keeps a module together

coupling: the strength of the connection between modules

Cohesion

A measure of how well a component 'fits together'

A component should implement a single logical entity or function

Cohesion is a desirable design component attribute as when a change has to be made, it is localised in a single cohesive component

Various levels of cohesion have been identified

Cohesion levels

Coincidental cohesion (weak)• Parts of a component are simply bundled together

Logical association (weak)• Components which perform similar functions are grouped

Temporal cohesion (weak)• Components which are activated at the same time are grouped

Procedural cohesion (weak)• The elements in a component make up a single control

sequence

Cohesion levels Communicational cohesion (medium)

• All the elements of a component operate on the same input or produce the same output

Sequential cohesion (medium)• The output for one part of a component is the input to another part

Functional cohesion (strong)• Each part of a component is necessary for the execution of a single

function

Object cohesion (strong)• Each operation provides functionality which allows object attributes

to be modified or inspected

Cohesion as a design attribute

Not well-defined. Often difficult to classify cohesion

Inheriting attributes from super-classes weakens cohesion

To understand a component, the super-classes as well as the component class must be examined

Object class browsers assist with this process

Coupling A measure of the strength of the inter-connections

between system components Loose coupling means component changes are

unlikely to affect other components Shared variables or control information

exchange lead to tight coupling Loose coupling can be achieved by state

decentralisation (as in objects) and component communication via parameters or message passing

Tight coupling

Module A Module B

Module C Module D

Shared dataarea

Loose coupling

Module A

A’s data

Module B

B’s data

Module D

D’s data

Module C

C’s data

Coupling and inheritance

Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing

However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Such changes must be carefully controlled

Information hiding

each module has a secret design involves a series of decision: for each such

decision, wonder who needs to know and who can be kept in the dark

information hiding is strongly related to• abstraction: if you hide something, the user may abstract from that

• coupling: the secret decreases coupling between a module and its environment

• cohesion: the secret is what binds the parts of the module together

Complexity

measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …)

use these numbers as a criterion to assess a design, or to guide the design

interpretation: higher value higher complexity more effort required (= worse design)

two kinds:• intra-modular: inside one module

• inter-modular: between modules

Top-down design

In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level

In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process

Hierarchical design structureSystem level

Sub-systemlevel

Understandability Related to several component characteristics

• Cohesion. Can the component be understood on its own?

• Naming. Are meaningful names used?

• Documentation. Is the design well-documented?

• Complexity. Are complex algorithms used?

Informally, high complexity means many relationships between different parts of the design. hence it is hard to understand

Most design quality metrics are oriented towards complexity measurement. They are of limited use

Adaptability

A design is adaptable if:• Its components are loosely coupled

• It is well-documented and the documentation is up to date

• There is an obvious correspondence between design levels (design visibility)

• Each component is a self-contained entity (tightly cohesive)

To adapt a design, it must be possible to trace the links between design components so that change consequences can be analysed

Design traceability

D Object interactionlevel

Object decompositionlevel

Key points

Design is a creative process Design activities include architectural design,

system specification, component design, data structure design and algorithm design

Sommerville, Mejia-Alvarez, 2009Software Engineering, Slide 1 Software Design u Deriving a solution...

Documents

Transcript of Sommerville, Mejia-Alvarez, 2009Software Engineering, Slide 1 Software Design u Deriving a solution...

Sommerville - Software Engineering 8e

Ian Sommerville - SOFTWARE ENGINEERING Chapter 7poincare.matf.bg.ac.rs/~vladaf/Courses/Matf RS2/Prezentacije/SE 07... · Ian Sommerville - SOFTWARE ENGINEERING – Chapter 7 * Uvod

Ian Sommerville, Software Engineering, 9th Edition Ch1

Ingenieria del Software 7ma. Ed. - Ian Sommerville (1).pdf

Software Requirements Software Requirements - adopted & adapted from I. Sommerville, 2004.

Advanced Software Engineering Prof. Ian Sommerville

An Introduction to Software Engineeringdcs.gla.ac.uk/~simon/teaching/MechEngSE3/Sommerville-ch1.pdf · An Introduction to Software Engineering ©Ian Sommerville 2004 Software Engineering,

Ingenieria Del Software 7ma. Ed. - Ian Sommerville

©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.

Ingenieria De Software - Ian Sommerville 7ma Edicion.pdf

©Ian Sommerville MSc module: Advanced Software Engineering Slide 1 Software Reuse Prof. Ian Sommerville.

Aspect-oriented Software Development - Ian Sommerville

Ian Sommerville, Software Engineering, 9th Edition Ch 4

Ingeniería Del Software - 7ma Edición - Iam Sommerville by Villa

Software Processes Software and Its Engineering - adopted & adapted from I. Sommerville, 2004.

Sommerville, Ammann-Offutt, Mejia, 2009 Software Engineering Slide 1 Verification and Validation.

From: Sommerville, I. Software Engineering, 5th edition ...sheldon/cs532/algspec.pdf · From: Sommerville, I. Software Engineering, 5th edition (Chap 10) Addison Wesley, 1995 Slide

Ian Sommerville, Software Engineering, 9th Edition Ch2

1 Pedro Mejia Curso de Ingeniería de Software, CINVESTAV-IPN Modelado de Software Orientado a Objetos usando UML Dr. Pedro Mejia Alvarez Departamento de.

©Sommerville 2000, Medvidovic 2006, Mejia 2009,Introduction to Software Engineering Slide 1 Ingeniería de Software l Diseño, construcción y mantenimiento.