ivica crnkovic mälardalen university department of computer engineering [email protected]

, 04/19/23SE course, Software DesignMdh/IDt, Ivica Crnkovic ©

Ivica Crnkovic

Mälardalen University

Department of Computer Engineering

[email protected]


Software DesignSoftware Design

Deriving a solution which satisfies software requirements

Several levels iteration process

conceptual design

technical design

“The user will be able to route messages to any other user on any other network computer.”

“The user will be able to route messages to any other user on any other network computer.”

Network topologyProtocol usedPrescribed bps rate. . .

Conceptual designTechnical design


Stages of designStages 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


Decomposition of a system into modules (components).

A good system:

Modular - each well defined activity executed by a separate component

Well - defined - all inputs are essential for the function and all the outputs are produced by the component’s functions

Toplevel

First level ofdecomposition(sub-systems)

Second level ofdecomposition(modules)

Decomposition and ModularityDecomposition and Modularity


The Design ProcessThe Design Process

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

Architecturaldesign

Abstractspecificatio

n

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products


Architectural DesignArchitectural Design

Establishing the overall structure of a software system

No general process model for the architectural design.

Usual activities in the process:

System structuring - The system is decomposed into several principal sub-systems and communications between these sub-systems are identified

Control modeling - 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

Different architectural styles/strategies may be used for these activities


Design strategiesDesign strategies

Functional/structural design

The system is designed from a functional viewpoint. The system state is centralized and shared between the functions operating on that state

Object-oriented design

The system is viewed as a collection of interacting objects. The system state is de-centralized and each object manages its own state. Objects may be instances of an object class and communicate by exchanging methods

Although it is sometimes suggested that one approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary

Good software engineers should select the most appropriate approach for whatever sub-system is being designed


System structuring models (Architectural Styles)System structuring models (Architectural Styles)

Repository model

Pipes and Filters

Client-server

Layering model

N-tiers model


Repository(shared data)

Knowledgesource 1

Knowledgesource 2

Knowledgesource 3

Knowledgesource 4

Knowledgesource 5

Knowledgesource 6

The repository modelThe repository model


Filter - a component

Pipe - a stream of data

Pipes and FiltersPipes and Filters


Client-server architectureClient-server architecture

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network


Two-Tiers Architecture Two-Tiers Architecture

DatabaseDatabase

Tier Boundary

BusinessLogic

BusinessLogic

DatabaseDriver

DatabaseDriver

BusinessLogic

BusinessLogic

BusinessLogic

BusinessLogic

PresentationLogic

PresentationLogic

Data Layer

Presentation / Business Layer


Users

Cryptography

File interfaceKey management

Authentication

LayeringLayering


N-Tiers Architecture N-Tiers Architecture

DatabaseDatabase

Tier Boundary

BusinessLogic

BusinessLogic

DatabaseDriver

DatabaseDriver

BusinessLogic

BusinessLogic

BusinessLogic

BusinessLogic

PresentationLogic

PresentationLogic

Data Layer

Business Layer

Tier BoundaryPresentation Layer


Microsoft Application Server TechnologiesMicrosoft Application Server Technologies

COMApplications

COMApplications

MTS

IISIIS

Windows NT

DBMSDBMS

DBMSDBMS

DBMSDBMS

ASPApplications

ASPApplications

ADOADO

ADOADO

BrowserClient

BrowserClient

RichClient Rich

Client

HTTP

DCOM

VBVC++VJ++

VBVC++VJ++

VisualInterDevVisual

InterDev


Control modelsControl models

Are concerned with the control flow between sub-systems. Distinct from the system decomposition model

Centralized control

One sub-system has overall responsibility for control and starts and stops other sub-systems

Event-based control

Each sub-system can respond to externally generated events from other sub-systems or the system’s environment


Centralized controlCentralized control

A control sub-system takes responsibility for managing the execution of other sub-systems

Call-return model

Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards. Applicable to sequential systems

Manager model

Applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes. Can be implemented in sequential systems as a case statement


Call-return modelCall-return model

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram


Real-time system controlReal-time system control

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses


Event-driven systemsEvent-driven systems

Driven by externally generated events where the timing of the event is outwith the control of the sub-systems which process the event

Two principal event-driven models

Broadcast models. An event is broadcast to all sub-systems. Any sub-system which can handle the event may do so

Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing


Broadcast modelBroadcast model

Effective in integrating sub-systems on different computers in a network

Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event

Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them

However, sub-systems don’t know if or when an event will be handled

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4


Interrupt-driven systemsInterrupt-driven systems

Used in real-time systems where fast response to an event is essential

There are known interrupt types with a handler defined for each type

Each type is associated with a memory location and a hardware switch causes transfer to its handler

Allows fast response but complex to program and difficult to validate

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector


Modular decompositionModular decomposition

Another structural level where sub-systems are decomposed into modules

Two modular decomposition models covered

An object model where the system is decomposed into interacting objects

A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model

If possible, decisions about concurrency should be delayed until modules are implemented


Characteristics of good designCharacteristics of good design

Easy to understand

easy to implement

easy to test

easy to maintain

easy to adapt

requirements easy traceable

Attributes of a good designed product

Components coupling

Components cohesion

Exception handling

Fault prevention and fault tolerance


Shared data

Component Independence - coupling between modulesComponent Independence - coupling between modules

Module A

A’s data

Module A

A’s data

Module B

B’s data

Module B

B’s data

Module C

C’s data

Module C

C’s data

Module A Module B

Module C

Tight coupling

Loose coupling


HIGH COUPLING

LOW

LOOSE

Data coupling

Stamp coupling

Uncoupled

Control coupling

Common couplingContent coupling

The range of coupling measuresThe range of coupling measures


A

B C

D EComponent B

Go to D1 Component D

Go to D1

D1:

Example of a content couplingExample of a content coupling


Global:A1A2A3

Variables:V1V2

Common data areaand variable names

Component X Component Y Component Z

Change V1 to zero Increment V1 V1 = V2 + A1

Example of common couplingExample of common coupling


CouplingCoupling

Control coupling

A component passes parameters to another components to control its activity

Stamp coupling

Passing data structures

Data coupling

only data passes

-----------------------------------------------------

Messaging coupling


CohesionCohesion

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 localized in a single cohesive component

Various levels of cohesion have been identified


HIGH COHESION

LOW

Logical

Temporal

Coincidental

Procedural

Communicational

Sequential

Functional


COINCIDENTALParts unrelated

LOGICALSimilar functions

TEMPORALRelated by time

PROCEDURALRelated by order of

functions

COMMUNICATIONALAccess same data

SEQUENTIALOutput of one part is input to next

FUNCTIONALSequential with

complete, related functions

DATA

FUNCTION A

FUNCTIONB

FUNCTION D

FUNCTION C

FUNCTION E

FUNCTION A

FUNCTION A’

FUNCTION A”

logic

TIME T0

TIME T0 + X

TIME T0 + 2X

FUNCTION A

FUNCTION B

FUNCTION C

FUNCTION A

FUNCTION B

FUNCTION C

FUNCTION A

FUNCTION B

FUNCTION C

FUNCTION A - part 1

FUNCTION A - part 2

FUNCTION A - part 3

Cohesion levelCohesion level


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

32

UnderstandabilityUnderstandability


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)

33

AdaptabilityAdaptability


Design traceabilityDesign traceability

P O R

D

A

B

F

C

D Object interactionlevel

Object decompositionlevel


Exception Identification and HandlingException Identification and Handling

Usually the requirements tell us what to do, not what not to do

How to define what to do but no more?

Identify exceptions - cases not allowed in the system

Typical exceptions

failure to provide a service

providing the wrong service or data

corrupting data

How to handle exceptions?

Retrying - restore the system to its previous state and try again

Correct - restore the system to its previous state, correct the errors and try again

Report - restore the system state to its previous state, report the problem, do not provide the service


Fault Prevention and Fault ToleranceFault Prevention and Fault Tolerance

Difference between fault and failure

?!human fault error

failure

can lead to can lead to


Special systems require special designSpecial systems require special design

Safety-critical real-time embedded systems

Safety - “Absence of catastrophic consequences on the users and the environment”

Property depends onEnvironment

Use of the system

Consequently, software is only hazardous in a context

It is a system behavior

Safety is an attribute of a more general property: Dependability


DependabilityDependability

1. Ability of a system to deliver service that can justifiably be trusted

2. Ability of a system to avoid failures that are more frequent or more severe than is acceptable to user(s)

Related to

1. Trustworthiness (assurance that a system will perform as expected)


Dependability

Availability Reliability Safety Confidentiality Integrity Maintainability

Readinessfor usage

Continuity of services

Absence ofcatastrophic consequences

Absence ofunauthorized disclosure ofinformation

Absence of impropersystemalternations

Ability toUndergorepairs andevolutions

Attributes of Dependability


Dependability (Extension definition)Dependability (Extension definition)

Dependability

Safety-critical systems Mission-critical systems Business-critical systems

AirplanesCars

Nuclear power stations……

Traffic control systemsEnergy supply and distribution systems??

Telecommunication systems???

NASAArianne

Industrial systemsInformation systems

Traffic control systems


Dependability

Attributes

Threats

Means

AvailabilityReliabilitySafetyConfidentialityIntegrityMaintainability

Fault PreventionFault ToleranceFault RemovalFault Forecasting

FaultsErrorsFailures


The means to attain the dependability The means to attain the dependability

Fault PreventionHow to prevent occurrence or introduction of faults

Fault ToleranceHow to deliver correct service in the presence of faults

Fault RemovalHow to reduce the number of severity of faults

Fault ForecastingHow to estimate the present number, the future incidents, the probability of different consequences


Fault ToleranceFault Tolerance

Error detectionconcurrent error detectionpreemptive error detection

Recoveryerror handling (rollback, rollforward)

Fault handlingfault diagnosisFault isolationSystem reconfigurationsystem re-initialization

Fault masking (redundancy)


Fault detection and Fault managementFault detection and Fault management

Passive fault detection - when we design the system and do some actions when a failure occurs during the code execution

Active fault detection - we periodically check for symptoms of faults

mutual suspicion - each component assumes that the other components contain faults

Avoid faults by using redundancy n-version programming - different teams design and implement the

same system /space shuttle)

Fault correction

Fix the problems - design the system to fix the faults (wrong data - checksum,…)

Fault tolerance

Correcting a fault is to expensive and risky - we minimize the damage


isTriangle(X1,X2,X3)

{Xi, Xj ,Xk} : Xi+Xj >Xk i,j,k {1,2,3}, i ≠k ≠j, Xi R+


Fault-tree analysisFault-tree analysis

Look for situations where a failure can occur (wrong name fault-tree!)

Build fault trees that display the logical path from effect to cause

Steps

identify possible failures (guidewords can be used)

Build a graph whose nodes are failures

Create a tree designated as “cut-set” tree to find single points of failure


Guidewords for identifying possible failuresGuidewords for identifying possible failures

Guideword Interpretation

no No data or signal was sent or received

more The volume of data is too much or too fast

less The volume of data is too low or too slow

part of The data or signal is incomplete

other then The data or signal has another component

early The signal arrives too early

late The signal arrives too late

…

….


Failure graphsFailure graphs

Cooling systemOverflow Failure

OR Either event can occur

Fill mode remains on

AND

Timeoutcontrol

fails

Sensor fails

Valve stuck in

open position

Basic events

Both events must occur


Cut-set graphsCut-set graphs

G1

G3

G4 G5 A5

A1

A2

A3

A4

G2

G1

G3

G4,G5

G2

A4,A5

A1,A3 A1,A4 A2, A3 A2, A4

Ai, Aj

A1,G5 A2,G5

Cut-set is the set of leaf nodes of the cut-set tree, with duplicates removed

Happens only when both Ai and Aj occur

or

and


Controldevice

motorsensor

bar

Powersupply

Powersupply


What happens if the bar is broken?What happens if the bar is broken?

Controldevice

motorsensor

bar

Powersupply

Powersupply


The measures:The measures:

Controldevice

motorsensor

bar

Powersupply

Powersupply

S1S2

S3

TL4

ivica crnkovic mälardalen university department of computer engineering [email protected]

Documents