Introduktion till Software Engineering - IDATDDD36/TDDD36 - Software... · 2010-08-31 ·...

2010-08-31

Linköpings universitet 1

Introduktion till Software Engineering

Why are we here?

It’s harder to build solid software than it is to build a solid bridge

Size and complexity makes it harder Size and complexity makes it harder

Teams make it harder (and easier)

Customers make it harder

Your project is hard

Software engineering is an answer

2

Software engineering is an answer

Methods for tackling the problem

2010-08-31


What is software engineering?

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the p papplication of engineering to software.

– IEEE Software Engineering Body of Knowledge

Engineering is:

The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same

3

utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.

– Engineers Council for Professional Development


It’s about communication and managing risk

What the customer describedHow the project leader

understood it How the analyst designed itWhat the customer

really needed

4

www.projectcartoon.com

2010-08-31



It’s about communication and managing expectations

What the customer describedHow the business consultant

described it What marketing advertisedWhat the customer

really needed

5



It’s about being professional and delivering quality

How it was documented How it was supported When it was delivered How the customer was billed

6


2010-08-31


Agenda

Processes

Process models

Irrelevant image just to fill the empty space

Process models

Process frameworks

Modeling

The Unified Modeling Language

Activities

7

Requirements

Architecture

Design

Process

Organization of activities to achieve a certain objective

Estimate cost and benefit of mitigations

Management decideswhich to implementbased on cost/benefit analysis

Estimate cost and benefit of mitigations

Management decideswhich to implementbased on cost/benefit analysis

Identify commonproblem causes

Prioritize causes in order of problem priority; commoncauses are given

Identify commonproblem causes

Prioritize causes in order of problem priority; commoncauses are given

Perform analysis in order of priority

Create Ishikawadiagrams based on standard template

Perform analysis in order of priority

Create Ishikawadiagrams based on standard template

Showstoppers havetop priority

Perform AHP on remaining reports

Showstoppers havetop priority

Perform AHP on remaining reports

Prioritize problem reports

Perform causeanalysis

Identifymitigations

Prioritizemitigations

Defect Causal Analysis: Preventing Problems

8

cost/benefit analysiscost/benefit analysiscauses are given extra priority

Identify actions in each category and attach to cause reports

causes are given extra priority

Identify actions in each category and attach to cause reports

Attach diagrams to the cause reports Attach diagrams to

the cause reports

Create prioritized list of reports Create prioritized list

of reports

2010-08-31


Lincoln Laboratory Process (1956)

9H. Bennington. Production of Large Computer Programs.

Proceedings of the ONS Symposiym on Advanced Programming Methods for Digital Computers, June 1956.

Processes model

Group of processes of the same character

10

2010-08-31


The V model

Concept of Operations andConcept of operations

Requirements

System design

Program designIntegration

testing

System testing

Acceptancetesting

Operations and maintenance

Validate requirements, verify specification

Verify system design

Verify module design

Validate concepts

11

Implementation and unit testing

The waterfall model

System Requirementsq

SoftwareRequirements

Analysis

Program Design

Coding

12

Testing

Operations

W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, August 1970.

2010-08-31


The waterfall model

System Requirementsq

SoftwareRequirements

PreliminaryProgram Design

Analysis

Program Design

PreliminaryDesign

Analysis

13

Coding

Testing

Operations

W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, August 1970.

Program Design

Coding

Testing

Usage

Iterative development

PlanningPlanning

RequirementsRequirements

AnalysisAnalysisTestingTesting

EvaluationEvaluation

14

DesignDesignImplementationImplementation

2010-08-31


Spiral model

15

B. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer 21(5):61-72, 1988.

Process frameworks

Somewhere between process models and processes

InceptionInception

ElaborationElaborationTransitionTransition

Unified Process

Scrum

IterativeDevelopment

16

ConstructionConstruction

Rational Unified Process

Open Unified Process

Essential Unified Process

Scrum @ Medius

Scrum @ Ericsson

Scrum @ LiU-IT

2010-08-31


Processes – conclusions

Process terminology

Process model – the character of a process

Less concrete

Process model – the character of a process

Process framework – a model that can be instantiated

Process – a concrete organization of activities

More terminology

Method a concrete way of doing something

17

Method – a concrete way of doing something

Tool – a device that supports a given method

More concrete

18

AGILE AND LEAN

2010-08-31


Agile software development

Reaction to traditional heavyweight methods

Iterati e ith emphasis on reacting to change Iterative with emphasis on reacting to change

Rapid iteration, evolving requirements, emergent design

Emphasis on collaboration in small cross-functional teams

Examples

Extreme Programming

19

g g

Feature-Driven Development

Open Unified Process

The Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come toand helping others do it. Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items on the right, we value the

20

, g ,items on the left more.

2010-08-31


Lean software development

Complement to agile development methods

Agile is abo t doing lean adds a thinking dimension Agile is about doing; lean adds a thinking dimension

Lean eliminates waste – a little thinking can prevent redoing

Lean brings decisions forward – but only the right ones

Lean organizes teams – agile individuals within teams

21

Lean is about high throughput (agile about low latency)

Lean is about maximizing long-term business value

The Toyota WaySome principles applied to software

Eliminate waste through continuous improvement

Excess inventory waiting incorrect processing defectsExcess inventory, waiting, incorrect processing, defects

Make decisions slowly, implement decisions rapidly

Go-and-see, determine cause, consider alternatives, consensus

Build a culture of stopping to fix problems, to get quality right

Use visual control to expose problems

Sort, straighten, shine, standardize, sustain

22

, g , , ,

Grow leaders who understand the work and live the philosophy

Develop exceptional people and teams who follow the philosophy

J. Liker. The Toyota Way: 14 Management Principles from the Worl’ds Greatest Manufacturer. McGraw-Hill, 2004.

2010-08-31


23

REQUIREMENTS

Requirements engineering

Domain understanding Requirements elicitationDomain understanding

Requirements elicitationRequirements elicitationRequirements elicitation

Requirements evaluationRequirements evaluationRequirements quality assurance

Requirements quality assurance

24

Requirements specification and documentation


2010-08-31


Requirements

What is the problem to be solved

Why does the problem need to be solved

Requirements

Why does the problem need to be solved

Who should be involved in solving it

25

How should the problem be solved

Architecture

Design

Implementation

Domain understanding andrequirements elicitation

Objectives

Understand the current situation


Requirements elicitation

Understand the current situation

Identify problems and opportunities

Discover stakeholder needs

Explore alternatives

Knowlege acquisition

Organization: structure objectives policies roles responsibilities

Requirements evaluation






26

Organization: structure, objectives, policies, roles, responsibilities

Domain: concepts, objectives, regulations, processes

Current system: actors, tasks, workflows, problems, opportunities

2010-08-31


Some methods

Background study

Talking to stakeholders


Requirements elicitation

Talking to stakeholders

Observation

Questionnaires

Storyboards

Scenarios

Mock-ups







27

Scenarios

Early-stage requirements validation/elicitation technique

Narrative of how things work or how they should work Narrative of how things work or how they should work

Passive: stakeholders are told story – for validation

Active: stakeholders contribute to story – for elicitation

Positive

Desirable behavior innormal circumstances

Desirsable behavior inabnormal circumstances

28

Abnormal Normal

Negative

Undesirable behavior innormal circumstances

Undesirsable behavior inabnormal circumstances

2010-08-31


Scenario structure

Who are the players

What happens to them

What if some event occurs

What could go wrong What happens to them

Why this happens

What could go wrong

A rescue worker reports an obstacle on a major road to the incident command system. The report

is logged for postmortem analysis, and the obstacle is added to the overall situation report.

Since a new obstacle impacts operations, the operations section chief and liaison is notified of the

29

new obstacle. Since it is a potential safety hazard, the safety officer is notified. Since the road is

open to the public, the public information officer is notified of the new obstacle. Rescue workers

known to be headed for the obstacle (based on their last known route and/or position) are also

notified. If there is an area commander assigned to the location, that area commander is notified.

Mock-ups

Functional prototypes

Not fully functional Not fully functional

For validating functionality

User interface prototype

Low or high fidelty possible

To validate user interface

30

2010-08-31



Requirements issues

InconsistenciesIncident commander: all personal details of all potential

i ti h ld b il bl t ll t ff t Inconsistencies

Conflicts

Exposure to risk

Prioritization

Feasibility

Important techniques

victims should be available to all staff upon request.

Conflict: this is illegal Risk: exposure of

information to outsiders

Feasibility: a lot of

information is unavailable

31

Important techniques

Conflict resolution

Risk analysis (e.g. CORAS)

Cost/value analysis (e.g. AHP)

Prioritization by cost/value

Estimate (relative) cost

Estimate (relative) values Estimate (relative) values

40

50

60

70

80

90

100

High

Medium

32

0

10

20

30

40

0 20 40 60 80 100

Low

2010-08-31


Requirements specification

Users need tomake audio calls

Users need tomake audio calls

Communicationsshould be secureCommunicationsshould be secure

R3.2: EncryptionR3.2: Encryption

R8.1 Audio calls

The user interface shall have a facility for initiating audio calls.

R8 6 Destination selection

R8.1 Audio calls

The user interface shall have a facility for initiating audio calls.

R8 6 Destination selection

33

yp

All network communications shall be encrypted with an AES128 session key.

R3.3: Session keys

Session keys shall be random and negotiatedusing a secure key exchange protocol.

yp

All network communications shall be encrypted with an AES128 session key.

R3.3: Session keys

Session keys shall be random and negotiatedusing a secure key exchange protocol.

R8.6 Destination selection

When selecting a destination, common and important destinations shall be selectable with no more than two clicks.

R8.33 Voice encoding

Audio calls shall use G.729 encoding at 8kbit/s.

R8.6 Destination selection

When selecting a destination, common and important destinations shall be selectable with no more than two clicks.

R8.33 Voice encoding

Audio calls shall use G.729 encoding at 8kbit/s.

Requirements specification

Natural language

Easy to write and read

S M A R T

Specific Easy to write and read

Need good guidelines

Risk of ambiguities

Specification language

Precise and unambiguous

Difficult to learn

Specific

Measurable

Attainable

Realizable

Time-bounded or Traceable

Functional vs non functional

34

Difficult to learn

Good tool support

Modeling – a bit of both

Functional vs. non-functional

2010-08-31


S.M.A.R.T.

Specific

Specific means

There is no ambiguity

Consider

The map should be shown in a There is no ambiguity

Terminology is consistent

Requirements are simple

Appropriate level of detail

The map should be shown in a 640x480 window and obviously show most of the surrounding area includingrelevant map objects. Icons should be used to display map elements.

The map shall be shown in a 640px by 480px window.

The map shall show a user-selected

35

e ap s a s o a use se ectedarea surrounding the user’s currentposition.

Relevant map objects (defined in R32) shall be displayed using icons (seeR61) on the map.

S.M.A.R.T.

Measurable

Measurable means

It is possible to verify that this

Consider

The program shall use as little memory It is possible to verify that this requirement has been met

Non-measurable means

You never know if you’re done

Opportunity for conflict

The program shall use as little memoryas possible.

The program shall output the optimum route with respect to driving time.

The program shall never consumemore than 48MB of memory.

36

2010-08-31


S.M.A.R.T.

Attainable

Attainable means

It is physically possible to meet

Consider

The system shall be 100% reliable and It is physically possible to meetthe requirement under the given conditions

Ask

Is there a theoretical solution

Are there physical constraints

The system shall be 100% reliable and 100% available.

The system shall operate for at least 20 hours between charges.

For any input, the system shallcompute an optimal schedule in no more than one hour

37

Are there environmentalconstraints

more than one hour.

S.M.A.R.T.

Realizable

Realizable means

It is possible to achieve this

Consider

I have no good examples It is possible to achieve this requirements given the constraints under which it is developed

Ask questions like

Can we do it?

I th h ti

I have no good examples.

Do you?

38

Is there enough time

Are there enough people

Is there enough money

2010-08-31


S.M.A.R.T.

Traceable

Traceable means

We can trace each requirement

Consider

The program shall display time and We can trace each requirementfrom analysis through design and implementation

We can understand the reasonfor each requirement

We can verify that each has been implemented

Modifications are easy to make

The program shall display time and date and the latest notificationsand battery status and networkstatus in the status bar.

R23 The program shall display time and date in the status bar

R24 The program shall display

39

Modifications are easy to make R24 The program shall display battery status in the status bar

R25 The program shall display network status in the status bar

Discuss

The map should display the geographical location of the user.

The system shall never lose any data.

The user shall be able to make a voice call with good audio quality.

The system shall have a response time of one second.

40

The map display shall be 1024x768 pixels large.

2010-08-31


Conclusions

On elicitation

Crucial to understand the problem and solution domains Crucial to understand the problem and solution domains

Crucial to identify and communicate with all stakeholders

On evaluation

Lots of techniques and tools exist for evaluation

Don’t discart requirements – just defer them

41

On documentation

If in doubt, write S.M.A.R.T. requirements

42

MODELING

2010-08-31


Models in software engineering

Documentation

Concise and precise language

Verification

Represent expected behavior Concise and precise language

Visual models easy to read

Communication

Models focus on key issues

Exploration

Represent expected behavior

Test behavior against model

Development

Formal specification

Stepwise refinement

MDD/MDA

43

Exploration

Test modifications on models

MDD/MDA

Model criteria

Mapping criterion

There is an original object that

ModeledAttributes

Mapping There is an original object that is mapped to a model

Reduction criterion

Not all properties of the original are mapped, but some are

Original

Mapped

Mapping

44

Pragmatic criterion

The model can replace the original for some purpose

Model

Attributes

2010-08-31


The Unified Modeling Language (UML)

Unified Modeling Language

Visual modeling language in

Model

Concepts in the system Visual modeling language in software engineering

Multiple levels of abstraction

Well-defined metamodel

Support for extensions

Concepts in the system

Objects in the system

Structures in the system

Diagram

Visual representation of model

45

UML Diagrams class Diagrams

Diagram

Structure Diagram

Profile Diagram Class Diagram Deployment Diagram Package Diagram

Behavior Diagram

Activ ity Diagram Interaction Diagram Use Case Diagram State Machine Diagram

46

Composite Structure Diagram

Component Diagram Object Diagram

Sequence Diagram Communication Diagram

Interaction Overv iew Diagram

Timing Diagram

2010-08-31


Class diagrams

Static structure

Classes and their attributesConcrete Class

+ static attribute: type

Abstract Class

+ abstract method() Classes and their attributes

Relationships between classes

Common elements

Class and interface

Attribute and operation

Association and dependency

_ yp- private_attribute: type

# protected_operation(type1, type2) : type+ public_operation(type1, type2) : type

+ abstract_method()+ concrete_method()

A BComposition: B is a part of A

Aggregation: A contains but does not own B

1Association: Every B has a reference to one or more A

1..*

C is a specialization of A B implements Interface

47

Association and dependency

Generalization and realization

Note and constraint

C «interface»Interface

Class diagram example

«interface»Queue

+ enqueue(Object) : void+ dequeue() : Object

Object

+ clear() : void+ i terator() : Iterator+ size() : int

«interface»QueueDiscipline

+ enqueue(PriorityQueue, Object) : void+ dequeue(PriorityQueue) : Object

PriorityQueue

+ enqueue(Object) : void+ dequeue() : Object+ clear() : void+ iterator() : Iterator+ size() : int

FIFOQueue

+ enqueue(Object) : void+ dequeue() : Object+ clear() : void+ iterator() : Iterator+ size() : int

+strategy

11

1

48

WRR


WFQ


DRR

+ enqueue(Priori tyQueue, Object) : void+ dequeue(Priori tyQueue) : Object

WeightedQueue

- weight: float = 1.0

+ setWeight(float) : void+ getWeight() : float

+queues

1..*

2010-08-31


Component diagrams

Static structure

Components and interfaces

cmp Component Diagram

Composite Component

Components and interfaces

Relationships

Elements

Components and ports

Interfaces and collaborations

Dependencies

PortPort

A

Required

B

Provided

ProvidedRequired

Collaboration

«delegate» «delegate»

49

Dependencies

Notes and constraints

Component diagram example

PlayerInput

Codec

AudioDecoderAudioSource

AudioSourceAudioDecoder

«delegate»

«delegate»

Output

PlayerControl

Source

AudioSource

SourceControl

Decoder

Sink

Data

Buffer Queue

AudioSink

AudioCodec

AudioDecoder

AudioEncoder

«interface»Controller

PlayerControlSourceControl

Playlists

AudioSink

AudioSink

«delegate»

«delegate»

50

ControlSink::AudioSinkAudioSink

Control

Sink::IceCastSinkSink::AlsaSink

Playlist

Control

SinkControlPlaylist

GUI

Control

WebUI

Control

SinkControl

«delegate»

2010-08-31


Deployment diagrams

Run-time architecture

Maps software elements to deployment Deployment Diagram

Maps software elements to hardware elements (nodes)

Elements

Nodes (various types)

Artifacts and components

Associations

Node

Component

Artifact

«client»Client Node

«device»Physical Dev ice

«execution environ...Execution Env ironment

Association

51

Deployment diagram example

deployment Deployment Diagram

«device»S

«device»M di C t

«device»W k t ti Server

tagsDistribution = Debian EtchOS = Linux

Media Center

tagsDistribution = Ubuntu 9.10OS = Linux

«arti fact»XBMC

«arti fact»MPD

HTTP Serv erNFS Serv er

«artifact»Jinzora

MPDJukebox

Workstation

tagsDesktop = KDEDistribution = Ubuntu 10.04OS = Linux

Web Browser

«artifact»MPD Controller

{protocol=MPD}

{protocol=NFS}

{protocol=MPD}

{protocol=HTTP}

{protocol=CIFS}

52

«artifact»Database

tagsvendor = MySQL

2010-08-31


Activity diagram example

act Activ ity Diagram

Se

lle

rC

us

tom

er

Receiv e order

Order

Place Order

Order

Notify Customer

Fill Order

Ship Order

Send Inv oice

Invoice

Make Payment

Invoice

Accept Payment

Close Order

[order rejected]

[order accepted]

53

p

Use case diagrams

uc Use Case Diagram

ATM System

Employee

B k T ll

Withdraw Cash from ATM

Withdraw Money

Check Balance at ATMATM Transaction

Bad PINServ ice ATM

Technician

«extend»

«extend»

54

Customer

Bank Teller

Transfer Money at ATM

Deposit Money «include»

«include»

2010-08-31


Conclusions

On modeling

Models are not necessarily lean: what value do they contribute Models are not necessarily lean: what value do they contribute

Models can support effective and efficient communications

There are development methods that rely on models

On modeling languages

The Unified Modeling Language is the most well-known language

There are many others (not all are graphical)

55

There are many others (not all are graphical)

56

ARCHITECTURE

2010-08-31


Architecture

Architecture is design

Not all design is architectureNot all design is architecture

Software architecture

Concentrates on issues that would be hard to change after the system is built

Addresses non-functional and lit i t

57

quality requirements

Is a compressed view of a design

Architecture

Software architecture goes beyond the algorithms and data structures of the computation; designing and specifying the overall system p g g p y g ystructure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.

Garlan and Shaw: An Introduction to Software Architecture (1993)

58

2010-08-31


Architecture

Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, g y ptheir relationships to each other and the environment, and the principles governing its design and evolution.

ANSI/IEEE Std 1471-2000 (2000)

The software architecture of a program or a computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the

59

relationships amond them.

Bass, Clements, Kazman: Software Architecture in Practice (2003)

Architecture (simplified)

Defines structure

System partitioning

Defines communication

Communications mechanisms System partitioning

Component interfaces

Component functionality

Communications mechanisms

Control flow

cmp Architecture

Visualization RecorderController

«use»

60

Simulator

Mediator Database

2010-08-31


Architecture example

cmp Architecture

ClientSSL Frontend «SSL,HTTP»

Cache Load Balancer

Server 1

Server 2«HTTP»

«HTTP»

«HTTP»

«HTTP»

«ODBC»

«HTTP»

«HTTP»

«HTTP»

61

Static Server Database Cluster

Database 1 Database 2

«ODBC»

Some techniques for lean architecture

1. Separate components according to their rates of change

2 Partition the system so that each part can be managed autonomously2. Partition the system so that each part can be managed autonomously

3. Let human considerations drive the partitioning

4. Don’t split a domain across architectural units or geographic locations

5. Module partitioning follows domain knowledge, if possible

6. Module partitioning follows end user cognitive model of the domain

7. Don’t forget system artifacts and other constraints

8 If you have a pattern language then use it

62

8. If you have a pattern language, then use it

2010-08-31


Pushing my friends’ books

63

Patterns

Patterns

A recurring solution to a

A good pattern

It solves a problem A recurring solution to a recurring problem in context

Pattern Language

A system of patterns for a particular domain

It solves a problem

It is a proven concept

The solution isn't obvious

It describes a relationship

The pattern has a significant human component

James Coplien

64

The relationships and interactions between the patterns

p

2010-08-31


Patterns

The pattern is, in short, at the same time a thing, which happens in the

Each pattern is a three-part rule, which expresses a relation between a certain

world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.

– Christopher AlexanderThe Timeless Way of Building

context, a problem, and a solution.

As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.

As an element of language, a pattern is

65

As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

133 Staircase as a stage

If the entrances are in position – Main Entrance (110); and the pattern of

Therefore:

Place the main stair in a key position, movement through the building is established – The Flow Through Rooms (131), Short Passages (132), the main stairs must be put in and given an appropriate social character.

A staircase is not just a way of getting

ace t e a sta a ey pos t o ,central and visible. Treat the whole staircase as a room (or if it is outside, as a courtyard). Arrange it so that the stair and the room are one, with the stair coming down around one or two walls of the room. Flare out the bottom

of the stair with open windows or balustrades and with wide-steps so that the people coming

from one floor to another. The stair is itself a space, a volume, a part of the building;

66

down the stair become part of the action in the room while they are on the stair, and so that people below will naturally use the stair for seats.

and unless this space is made to live, it will be a dead spot, and work to disconnect the building and to tear its processes apart.

Christopher Alexander. A Pattern Language. Oxford University Press, 1977.

2010-08-31


Architectural patterns in software

High-level patterns

Layers Layers

Pipes and filters

Blackboard

Distributed systems

Microkernel

Broker

Interactive systems

67

Interactive systems

Model-View-Controller (MVC)

Presentation-Abstraction-Control

Layers

Context: A large system that requires decomposition cmp Architectureq p

Problem: A mix of low- and high-level issues where high-levelissues rely on the lower-level one.

Forces: Late source codechanges, stable interfaces, exchangeable parts, subdivision of work

Layer 1

Layer 2

Layer 3Component 3.1 Component 3.2

Component 2.1 Component 2.2

Component 1 1Component 1 2

68

Solution: Structure the system in layers and place them on top of each other

Component 1.1Component 1.2

2010-08-31


Pipes and filters

Context: Processing data streams

Problem: Developing a monolithic

cmp Architecture

Input filter SourceProblem: Developing a monolithicmodule for processing may be infeasible due to complexity and inability to divide work.

Forces: Reuse of modules, reconfigurability, flexibility, variedinput, output, data, parallelism.

Solution: Divide the system into

Filter

p

Filter

«interface»AbstractFilter

69

several sequential processingsteps.

Output Filter Sink

Broker

Context: Distributed and possiblyheterogeneous system with

cmp Architecture

Client Client-side proxy

independent cooperating components.

Problem: When distributedcomponents handle communicationthemselves, dependencies and limitations arise. Services for communication are also needed.

Forces: Transparent remote access, run-time reconfiguration, hide system details from users

Broker Bridge

uses API

uses API«use»

«communicates»

«calls»

70

details from users

Solution: Introduce a brokercomponent and have services register with the broker.

Server-side proxyServer

uses API

«calls»

«communicates»

2010-08-31


Model-View-Controller (MVC)

Context: Interactive applications with a flexible human-computer interface

cmp M...

View

Problem: Interfaces are prone to change and can be very complex.

Forces: Same information presented in multiple ways, display must reflectchanges immediately, user interface should be easy to change.

Solution: Divide application into threeareas: processing (model), output (view) and input (controller) Model

Controller

Observ er

notify on change

manipulate display

create

get data

71

(view) and input (controller). Modelnotifies views of changes.

Model Observ able

manipulate

Architecture example redux

cmp Architecture

ClientSSL Frontend «SSL,HTTP»

Cache Load Balancer

Server 1

Server 2«HTTP»

«HTTP»

«HTTP»

«HTTP»

«ODBC»

«HTTP»

«HTTP»

«HTTP»

72

Static Server Database Cluster

Database 1 Database 2

«ODBC»

What pattern does this (mostly) conform to?

2010-08-31


Conclusions

On architecture

Architecture is the bridge from requirements to design Architecture is the bridge from requirements to design

Architecture defines the overall shape of the program

Architecture determines many of its properties

With emergent design, architecture is even more important

There is no clear line between architecture and design

73

On patterns

Don’t reinvent the wheel – if a pattern will do the job, use it

If a pattern doesn’t do the job, invent something that will

74

DESIGN

2010-08-31


Design

Continues from architecture

Decomposition of the system Decomposition of the system

Specification of interactions

Decomposition of components

Agile development and design

Design is emergent

Architecture is critical

75

Architecture is critical

Traditional software design

Coupling

Measure of interconnection

class Coupling-Cohesion

Class 1 Class 2

«flow» Measure of interconnectionamong components

Cohesion

Measure of how focused a single component is

Class 4 Class 3

«use»

«use»

«call»

«call»

«flow» «use»

«call»

«use»

«flow»

76

Goals

Low coupling

High cohesion

2010-08-31


Coupling

Loose (low) coupling

Software easier to understand


Class BClass A

Software easier to understand

Easier to maintain, change, test

Types of coupling (low to high)

Data coupling

Stamp coupling

Control coupling


Class A Class B

Class 2Class 1 Class 3

77

Control coupling

External coupling

Common coupling

Content couplingClass 1 Class 2 Class 3

Class M

Cohesion

Types of (low-medium) cohesion

Logical cohesion

High (tight) cohesion

Reduces coupling Logical cohesion

Temporal cohesion

Procedural cohesion

Communicational cohesion

Reduces coupling

Easier to maintain, understand class Coupling-Cohesion

DataSource

+ read()

DataFormat

+ parse()

Reader

+ create(DataFormat, DataSource) : Reader


DataOutput

+ read_xml_from_file()+ read csv from file()

Utilities

+ decode_xml_entity()+ unquote csv item()

78

FileSource NetworkSource XMLFormat

+ decode_entity()

CSVFormat

+ unquote_csv_item()

FileIO Socket SAXParser

«use» «use» «use»

+ read_csv_from_file()+ read_xml_from_network()+ read_csv_from_network()

+ unquote_csv_item()+ current_timestamp()

SAXParserSocket FileIO

«use»«use» «use»

2010-08-31


Design patterns

A definition

A recurring solution to a

Don’t rely just on this book

A recurring solution to a recurring design problem in context

Discovered, not designed

Design patterns and agile

Support emergent design

79

Pattern language helps

Singleton (creation)

Problem: Need a single instanceand don’t want to use global class Singletongvariables (or can’t)

Solution: Control creation of objects through static method

Problems:

Similar to global variables

E t i l t

Singleton

- instance: Singleton

- Singleton()+ get_instance() : Singleton

def get_instance(): Singleton.instance = Singleton() return instance

80

Easy to overuse singletons

2010-08-31


AbstractFactory (creation)

Problem: Select concrete types to create at run-time or easily class AbstractFactoryychange concrete types created.

Solution: Define an interface for creating instances, and createdifferent implementations for different families of objects.

y

AbstractFactory

+ create_product() : AbstractProduct

AbstractProduct

ConcreteFactory

+ create_product() : Product

Product

«instantiate»

81

Composite (structural)

Problem: Want to represent part-whole relationships with a

class Composite

pconsistent interface.

Solution: Define a commoncomponent type and have bothinterior nodes and leavesimplement the same interface. Dispatch operations from the composite to its components

Component

+ add(Component) : void+ remove(Component) : void+ get_child(int) : Component+ operation()

Composite

+ add(Component) : void+ remove(Component) : void+ get_child(int) : Component+ operation()

Leaf

+ operation()

82

composite to its components.

def operation(self): for c in self.children: c.operation()

2010-08-31


Chain of responsibility (behavior)

Problem: Not sure what willhandle a given event/command

class ChainOfResponsibility

gbut know their relationships.

Solution: Create a chain of handlers, and just call the headof the chain with the command.

Note: Often used with composite

Client Handler

+ handle_request()

ConcreteHandler

def handle_request(self): self.successor.handle_request()

def handle request():

successor

83

Note: Often used with compositeand/or command patterns; the chain can be a tree if handlersdispatch to multiple objects or other chains.

+ handle_request()_ q ()

i f self.can_handle(): # Handle request else: super.handle_request()

Observer (behavior)

Problem: Keeping track of state

Solution: Automatically update

class Observ ...

def notify(self):f i l f bSolution: Automatically update

depdents when object statechanges

Problems:

Garbage collection

Infinite notify loops

Subject

+ attach(Observer) : void+ detach(Observer) : void+ notify() : void

Observer

+ update() : void

ConcreteSubject

- state: State

+ t t t () St t

ConcreteObserver

+ update() : void

for o in self.observers: o.notify()

+observers

*

+subject

1

84

Error handling+ get_state() : State+ set_state(State) : void

def set_state(self, state): self.state = state self.notify()

1

2010-08-31


Command (behavior)

Problem: Want to do undo, scripting, record commands,

class Command

p gdefer execution …

Solution: Encapsulate all stateneeded to perform command(or undo) in a command object, and invoke it using an invoker.

Inv oker Command

+ execute()

ConcreteCommand

- state: State

+ execute()

Receiv er

+ action()receiver

«instantiate»

85

def execute(self): receiver.action()

Client

«instantiate»

Conclusions

On design

Design defines the detailed shape of the program Design defines the detailed shape of the program

Design determines many functional properties of the program

Agile processes often omit the design phase

On patterns

Don’t reinvent the wheel – if a pattern will do the job, use it

If a pattern doesn’t do the job invent something that will

86

If a pattern doesn t do the job, invent something that will

Beware of the design pattern hype!

2010-08-31


87

WRAP-UP

Topics covered

Processes and modeling

Processes models and frameworks Processes models and frameworks

Agile and lean development philosophies

The Unified Modeling Language

Key software engineering activities

Requirements

Architecture and architectural patterns

88

Architecture and architectural patterns

Design and design patterns

2010-08-31


Other important topics

Software engineering activities

More about requirements design architecture More about requirements, design, architecture

Coding and other implementation

Testing, verification and validation

Delivery, deployment and maintenance

Support activities

Configuration management

89

Configuration management

Documentation

In your project

Requirements – current step

Determines the course of the project Determines the course of the project

Read more about it – techniques for elicitation, analysis …

Architecture – next step

Crucial – you are depending on emergent design

Need architecture to support non-functional requirements

90

Design

Emergent design – no up-front design needed

2010-08-31


www.liu.se

Date post:	15-Aug-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Introduktion till Software Engineering - IDATDDD36/TDDD36 - Software... · 2010-08-31 ·...

Documents