introduktion till software engineeringtddd82/slides/software... · 2014-02-18 · introduktion till...
TRANSCRIPT
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
Linköpings universitet 2
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
What is software engineering?
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
Linköpings universitet 3
What is software engineering?
It’s about communication and managing expectations
What the customer describedHow the business consultant
described it What marketing advertisedWhat the customer
really needed
5
www.projectcartoon.com
What is software engineering?
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
www.projectcartoon.com
2010-08-31
Linköpings universitet 4
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
Linköpings universitet 5
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
Linköpings universitet 6
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
Linköpings universitet 7
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
Linköpings universitet 8
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
Linköpings universitet 9
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
Linköpings universitet 10
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
Linköpings universitet 11
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
Linköpings universitet 12
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
Requirements specification and documentation
2010-08-31
Linköpings universitet 13
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
Domain understanding Requirements elicitationDomain understanding
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
Requirements evaluation
Requirements specification and documentation
Requirements specification and documentation
Requirements quality assurance
Requirements quality assurance
26
Organization: structure, objectives, policies, roles, responsibilities
Domain: concepts, objectives, regulations, processes
Current system: actors, tasks, workflows, problems, opportunities
2010-08-31
Linköpings universitet 14
Some methods
Background study
Talking to stakeholders
Domain understanding Requirements elicitationDomain understanding
Requirements elicitation
Talking to stakeholders
Observation
Questionnaires
Storyboards
Scenarios
Mock-ups
Requirements evaluation
Requirements evaluation
Requirements specification and documentation
Requirements specification and documentation
Requirements quality assurance
Requirements quality assurance
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
Linköpings universitet 15
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
Linköpings universitet 16
Requirements evaluation
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
Linköpings universitet 17
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
Linköpings universitet 18
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
Linköpings universitet 19
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
Linköpings universitet 20
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
Linköpings universitet 21
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
Linköpings universitet 22
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
Linköpings universitet 23
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
Linköpings universitet 24
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
+ enqueue(PriorityQueue, Object) : void+ dequeue(PriorityQueue) : Object
WFQ
+ enqueue(PriorityQueue, Object) : void+ dequeue(PriorityQueue) : Object
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
Linköpings universitet 25
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
Linköpings universitet 26
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
Linköpings universitet 27
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
Linköpings universitet 28
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
Linköpings universitet 29
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
Linköpings universitet 30
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
Linköpings universitet 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
Linköpings universitet 32
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
Linköpings universitet 33
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
Linköpings universitet 34
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
Linköpings universitet 35
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
Linköpings universitet 36
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
Linköpings universitet 37
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
Linköpings universitet 38
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
Linköpings universitet 39
Coupling
Loose (low) coupling
Software easier to understand
class Coupling-Cohesion
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 Coupling-Cohesion
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
class Coupling-Cohesion
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
Linköpings universitet 40
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
Linköpings universitet 41
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
Linköpings universitet 42
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
Linköpings universitet 43
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
Linköpings universitet 44
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
Linköpings universitet 45
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
Linköpings universitet 46
www.liu.se