lOMoARcPSD|23216638

Summary - complete

Software Architectures and Design (Swinburne University of Technology)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])
 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

1. Issues in Software Design

Business Goals
▸ Software helps to solve business goals:
- Reduce costs
- Improve quality
- Improve capabilities/functionality
- Improve organisation’s market position
- Improve external confidence
▸ Ultimately: Improve Business Value
- We choose projects that will improve value by the most
- Software vendors will build products that maximise their profits
▸ Different stakeholders have different views and priorities
- Can even lead to conflicting goals between different stakeholders
- Development much cater for all stakeholders
▸ Priority of Goals
- Some goals are nice to have vs. some goals are absolutely critical
- Sometimes, we need to push back goals or make trade offs
▸ Source of Goals
- Some goals are inherent/essential to the a system
- Some goals result from market analysis
- Some goals are arbitrary and can cause problems
▸ Business goals become software requirements

Software Requirements
▸ Functional Requirements
- Services or functions of a system
▪ Qualitative metrics of the system
▪ A system that records compute sales tax
- Interactions between the system and environment, independent of implementation
- DOCUMENT: The user's expectations of functions in the new system
▸ Nonfunctional/Quality Requirements
- Constraints on the functional requirements OR on the development process
▪ Quantitative metrics of the system
▪ Functional Constraints: Responds in < 1 second; Accuracy of 100m
▪ Development Constraints: Must be in COBOL; Do it in 3 months
▸ DOCUMENT your requirements so that can be Validated & Verified objectively

1 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▸ Constraints (Pseudo-Requirements)
- Imposed by the client or environment in which the system will operate
▪ Must be in COBOL
- DOCUMENT: These user/environment-specified constraints under which the new
system is going to be built upon

Verification and Validation

▸ Validation
- Whether you have built the right
product
- Does it meet what the user
expect?
Conforms to the specification?
- User-side: Users are involved in
the checking process
▸ Verification
- Whether you are building the product right: Is it being built in the right way?
- Developer/Process-side: Developers checking code against User's supposed
requirements
- Software conforms to the specification
▸ When do V&V?
- All the way through the SDLC
- Why?
▪ Costs more later on in the stages
▸ Requirements Verifiability
- When documenting your requirements for verifiability, you want to be precise
- E.g., it should take two hours of training to use, users should make 1 error/day
- Use numerics so that it can be validated and verified objectively

2 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Software Design
▸ Software design is both an activity and an artefact:
- Activity: creative process that transforms a problem to a solution
- Artefact: a set of components and their interfaces that satisfy the requirements
▸ The following forces are considered in a software design:
- Requirements Specification (Functional Requirements)
- Designer’s Decisions
- Development Constraints

Requirements
specification

Constraints:
resources, Design Designer’s
experience, process decisions
deadlines etc.

Design
documentation
Source: David Budgen,
Software Design, Addison-
Wesley, 1994

▸ Use functional decomposition to break down the complexity of a system

▸ Models help us decompose a system
- A model is a simplification/abstraction of reality
▪ Class Diagram, Architect Blueprint, Schematics
- It helps us better:
▪ understand the problem
▪ understand the domain
▪ build the system
▸ Models are static and dynamic
- Static = structure (Class Diagram)
- Dynamic = behaviour (Sequence Diagram)
▸ Quality-Driven Design is when nonfunctional requirements (quality requirements)
drive the design process

3 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

2. Role of Requirements

Overall view of SDLE

Stakeholders Tacit
Demands
demands
Elicitation
& reqs

Analysis
Contract
Reqspec

Design
Tracing:
Forwards . . . Program
Backwards . . .
Requirements management: Test
Changing requirements
Op &
maint

Requirements Activities
▸ Feasibility study
- Can the user’s needs actually be satisfied? (Make us 1 million dollars!)
- Is there technology available to actually achieve this? (Take us to Mars tomorrow!)
- Is there enough in the budget to do it?
▸ Requirements elicitation/discovery
- Grab as much of the requirements from multiple stakeholders
- Determines the:
▪ domain
▪ services of the system (functional/non-functional reqs)
▪ constraints
▸ Requirements analysis
- Define and document the requirements
- Collaboration between:
▪ Users with domain knowledge
▪ Developers with implementation knowledge

4 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

- Analyse the requirements to see if any of them conflict with each other
- Resolve all the conflicts with the stakeholders, otherwise prioritise them
- Once complete and consistent requirements, these will help produce our models
▪ Scenarios
▪ Use cases
▪ User tasks
▪ Workflows
▸ Requirements specification
- Define each of the requirements in detail
- This will define a contract between the client and developers

Types of Requirements
▸ Data Requirements
- System State and Common States
- I/O Formats
▸ Functional Requirements
- Record, compute, transform, transmit
- Pseudo code
- Activity diagrams
- Screen prototypes
▸ Quality Requirements
- Performance
- Usability
- Maintainability etc.
▸ Other Deliverables
- Documentations
- Installation
- Convert from old to new
- Training documents
▸ Managerial Requirements
- Delivery times
- Legal documents
- Development processes
▸ Helping the reader
- Business goals
- Definitions
- Diagrams

5 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Traditional Requirements
▸ Traditional requirements are poor
- They talk too much about the system
- They don't talk enough about user input
- They usually are not verbose:
▪ What defines an error?
▪ What defines how something is possible?
▸ Fix this by focusing on a user’s perceptive

Users’ Perspective
▸ Users think about a system in terms of its features
▸ Get the user’s stories to provide the context on how the user can potentially use the
system
- Scenarios + Use cases => Complete and Consistent
▸ Scenarios
- Examples of user interaction to complete task/goal
- Verbose—a paragraph describing a specific example user (case study)
- Ideal interaction of the user and the system
▪ This is the ideal/key scenario
- Adds alternative scenarios
▪ These are the alternative scenarios
▸ Use Cases
- Structured scenarios that represent the scenarios from user’s viewpoint
- Sequence of actions, with variants
- The use case is general—generalise the scenario with actors:
▪ Actors perform a role in a use case:
▹ An actor can perform many use cases
▹ One use case may have many actors
▪ Actors aren’t always humans: they can be external systems or a device

6 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Domain and Product Levels

“Business” domain Inner Domain Actors?

Platform

Clients Product

User Control
computers
activities
Domain
I/O Elevators
Product
I/O

▸ Domain level focuses on the domain’s requirements (the ‘business domain’)

- Product shall support the user’s activities:
▪ Hotel booking software should support receptionists to:
▹ book in guests
▹ checkout guests
▹ pay for guests with credit cards
- Boundary between the user and the domain — Domain I/O
▸ Product level focuses on the product’s requirements (the ‘inner/core domain’)
- Specific interactions between users and the system
- The product shall accept input from:
▪ Hotel booking software should accept input:
▹ guest’s name, phone, address
▹ checkin time (ISO format)
▹ credit card details
- Boundary between the user and the system — Product I/O

7 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Goal Design Scale

R1 Our profits shall increase by 5% using our calculations Goal level

R2 Product shall support cost recording and quotation with Domain level
experience data
How do we support calculations in R1?
R3 Product shall have recording an retrieval functions for Product level
experience data
How do we support recording data in R2?
R4 System shall have screen pictures as shown in figure X Design level
How do we support retrieval functions in R4?
▸ The deeper we go, the greater the detail we get
▸ Goal level requirements
- Specifies the business’ goals — benefits it will deliver to business
- improve our guest’s experience
- gain us more guests and thus more money
- improve hotel operation efficiency
▸ Domain level requirements — how the system fits into the business
- Activities that go on outside the product (i.e., inside the domain)
- this hotel checks in guests
- this hotel is kept clean by cleaners
▸ Product level requirements — how the system is used by actors
- Specifies requirements that go in and out of the product
- guests name, check in and out times
▸ Design level requirements — how the system is constructed
- Specifiers UI details and internals of the system
▸ Depending the developer, you may choose different requirements:
- Vendor of business applications? Then domain level
▪ We want something that helps us checks in our guests
- Software house? Then design level
▪ We need to code a way that records hotel data
- PriceWaterhouse Coopers? The goal level
▪ We want to improve the business’ profits

8 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Requirements Phase Artefacts

Entity Relationship Diagrams

The system shall store the following domain entities: The system shall store the following domain entities:
name,
address1,
address2, Guest
Guest address3, name, price
passport

Service Service
Stay Service Stay Service
Type Type
stay#,
paymethod, date, count
Room employee Room
State State

❌
date, #persons,

✅
state (booked|occupied|repair)

Room room#, Room

Notation used? #beds, type
price1, price2

▸ Use this to model out the domain—higher level abstraction of the system
▸ The RHS is TOO SPECIFIC for the implementation details (only in detail design phase)
Task Descriptions

Task: 1.1 Booking

Work area: 1. Reception Purpose: Reserve room for a guest.
Service guests - small and
large issues. Normally Task: 1.2 Checkin
standing. Frequent Purpose: Give guest a room. Mark it as
interrupts. Often alone, e.g. occupied. Start account.
during night. Trigger/
Users: Reception experience, IT Precondition: A guest arrives
novice. Frequency: Average 0.5 checkins/room/day
Critical: Group tour with 50 guests.
R1: The product shall support
tasks 1.1 to 1.5 Sub-tasks:
1. Find room
2. Record guest as checked in
3. Deliver key
Missing Variants:
sub-task? 1a. Guest has booked in advance
1b. No suitable room
2a. Guest recorded at booking
2b. Regular customer
Task: 1.3 Checkout
Purpose: Release room, invoice guest.
From: Soren Lauesen: Software Requirements
... 26
© Pearson / Addison-Wesley 2002

▸ Work areas:
- Provides the context of the users
- The work area (domain requirement) is supported by tasks (product requirements)
▸ Tasks descriptions:
- Provide the way in which work areas are satisfied
- The product requirements that satisfy the domain requirements

9 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Supporting tasks
Task: 1.2 Checkin
Purpose: Give guest a room. Mark it . . .
Frequency: . . .
Sub-tasks: Example solution:
1. Find room. System shows free rooms on floor
Problem: Guest wants neighbour maps. System shows bargain prices,
rooms; price bargain. time and day dependent.
2. Record guest as checked in. (Standard data entry)
3. Deliver key. System prints electronic keys. New
Problem: Guest forgets to return the key for each customer.
key; guest wants two keys.
Variants:
1a. Guest has booked in advance. System uses closest match
Problem: Guest identification fuzzy. algorithm.

Past: Domain Future:

Problems level Computer part
27

Task Task Name

Purpose Purpose of the task
Trigger Trigger which starts the task; once off occurrence
A customer is ready to order
Precondition Preconditional state that can occur beforehand
Can be true if there is no precondition
A customer is sitting at the table
Frequency Average frequency
30/hr
Critical Extreme frequency that can cause problems to system
100/hr - peak period
Subtasks Example Solutions
1. Foo - Way to implement foo
- Another way to implement foo
2. Bar - Way to implement bar
- Another way to implement bar
Problem: Bar is broken - A way to handle a broken bar (handle problem)
3. Qux - Way to implement foo
- Another way to implement bar
Variants Example Solutions
1a. Fooy - A way to implement fooy
1b. Fooa - Way to implement fooa
- A way to handle a broken fooa (handle problem)
Problem: Fooa is broken
3a. Quxie - Way to implement quxie
10 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▸ Provide possible example solutions for exceptional problem circumstances

▸ Provided for each of the subtasks and variants of the task
Use Cases vs. User Tasks
Human and computer separated: Task descriptions. Split postponed:

Hotel system Hotel system

Booking Booking Account

Transfer
... ... system

28
▸ In use cases, the system and actor are considered separately
▸ In user tasks, we don't split these actors—consider them as one

11 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

3. Software Quality
▸ Software quality conforms to:
…
- explicit functional and
Availability
performance requirements Quality attribute
Modifiability
- explicit development standards may be further
Software Performance refined into
Quality
- implicit characteristics expected Security
sub-attributes
of all software Testability

▸ Problems: Usability

- Tension between customer quality

requirements and developer quality requirements
▪ Efficiency vs maintainability / reliability vs reusability etc.
- Hard to specify some requirements
▪ Directly: errors/LOC
▪ Indirectly: usability, user
engagement „

Quality Models „

▸ Hierarchical quality model

„
- Quality attributes
- Some attributes are refined „
into sub-attributes
▸ McCall’s model „

- Split over the areas of

„
▪ Product revision
▪ Product transition

12 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▪ Product operations

Quality Attributes
▸ Types of quality attributes:
- Availability: system provide’s its functional requirements when expected?
▪ ReliabilityRR
- Modifiability: can make reasonable changes at reasonable costs?
▪ Maintainability: how easily the system can be modified to amend bugs?
▪ Portability: how easily the system can run on differing hardware/OS?
▪ Scalability: how easily the system can capacity more information/users?
- Performance: system responds to user input quickly?
- Security: user handles user authentication for specific system services?
▪ Integrity: data of the system cannot be changed in an unauthorised manner?
- Testability: can the system be exercised to ensure confidence in correctness?
- Usability: how easy is it for users to perform user tasks?
▪ Operability: system is easy to use and learn?
▸ These apply to both the product and process
- product = delivered to user
- process = produces the product
- resources = product and process require resources
▸ An underlying assumption is quality process is likely to lead to quality software
- i.e., quality-driven design
▸ Quality attributes can be internal or external
- External
▪ Derived between relationship between the environment and the system
▪ Reliability, Usability
- Internal
▪ Deprived immediately from the product or process description
▪ “Internal quality leads to external quality”
▪ Efficiency, Operability
▸ Tools that help identity quality attributes:
- QAS (Quality Attribute Scenarios)
▪ Systematic approach to deal with quality aspects
▪ Prone to being inadequate; may need extension
- Hypotheses
▪ Identify 3-5 quality attributes from the domain

13 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▹ We assume that quality aspects of domain are applicable for system

▪ Systematically go through all user tasks
▹ Identity if some user tasks make explicit mention of quality attributes
▹ Critical user tasks generally imply some quality attributes
▹ Must be in a verifiable form

Requirements V&V
▸ Validation
- Building the right product?
- Meeting stakeholders expectations?
- Requirements realistic, achievable, prioritised?
- Requirements tradable to business goals?
▸ Verification
- Building the product right?
- Requirements implemented correctly?
- Come up with some objective, measurable testing scenario?
▸ Traceability
- Forward and backward direction
▪ Where did the requirement come from?
▪ Does it originate from a business goal?
- What priority does it have?
- Where in the design/implementation is it being addressed?
- What are the implications on the design/implementation if changed?
▸ SRS has its own quality criteria:
- Correct - each requirement reflects a need
- Traceable - to goals/purpose and design/implementation
▪ Traceability checks above
- Complete - all necessary requirements included
▪ CRUD checks
▪ User scenarios/stories
▹ Each scenario can be covered by Create, Read, Update, Delete + Overview
one or many user tasks
ServiceType

Entity
RoomState

- Consistent - all SRS parts match and are

Service
Room
Guest

Stay

consistent Task

- Verifiable - possible to see whether SRS Book C U O C O U O

CheckinBooked RU U O O U O
can be met/tested
CheckinNonbkd C U O C O U O
Checkout U U O R U
ChangeRoom R R O U O
RecordService O C 14R / 45
PriceChange C UDO C UDO
Missing? D D C?UD? UD
Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])
 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

- Unambiguous - all stakeholders agree on meaning

- Ranked for importance - priorities
- Modifiable - easy to change
- Understandable by customer and developers
▸ SRS is checked for content - evidence of validation
- Introduction/Context
- System/Business Goals
- Data Requirements (Domain Model)
- Functional Requirements (including Special Cases)
- Quality Attributes
- More? (based on problem domain and experienced problem)
▸ SRS is checked for structure
- Verifiable requirements
- Each requirement has a purpose
- Sample solutions for requirements are given
- Explanations of graphical illustrations (figure one means…)
- Importance/stability of each requirement (priorities)
- Cross-references

15 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

4. Abstraction
▸ Abstraction stack in software development:
- HIGH
▪ Subsystems
▪ Components
▪ Packages
▪ Interfaces
▪ Objects
▪ ADTs (lists, trees)
▪ Functional abstractions (procedures, methods)
▪ Primitive data types
▪ Simple arithmetic expressions and control sequences
▪ Macros
▪ Symbol names
▪ Machine instructions
- LOW
▸ Abstraction between the problem domain are the relationships between domain entities
▸ Growing a new language
- a large vocabulary of design elements
- based on small set of well understood principles
- experience when and how to use vocabulary
▸ Abstraction and modelling are used at every phase of SDLC
▸ Benefit of a particular abstraction depends on its purpose
▸ Abstraction is key to mastering complexity — helps with functional decomposition

16 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design

„ Alex Cummaudo
SWE30003 6 March 2016

5. Object Design
▸ Real world: An object is a representation of a model
- Abstract model of a real world entity
- An object knows and can do things
- Can talk to other objects
▸ Processing world: You can view an object as a processing element

knows performs
information Processing computations

Object
Interaction Composition

maintains connections can be composed

(to other objects) (as part of other objects)

contains performs
information computations

Processing
Element

maintains connections can be composed

(to other processing elements) (as part of other PEs)

▸ Classes are the blueprint for all instances of objects

- Data attributes
- Operations
- Relationships
- Semantics
▸ OO Design is about Don’t worry
identifying blueprints about visibility
too early!
of objects—identify
classes
▸ A class instantiates
an object
- Instance’s internal ฀

states differ 13

17 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▸ An instantiated object has an underline

- A name or type is required
- :Polygon, triangle:Polygon, triangle

Decomposition
▸ OO Decomposition is done using OO
Design
▸ Notation for capturing the detail characteristics under a system’s design
- View the system as interaction of multiple objects
▸ Need to find the right object-oriented abstractions:
- ( 1 ) Model the real world
- ( 2 ) Make sure you’re using the right abstraction
▸ Questions to ask when doing OO Design:
- How can we identify objects or classes?
- How do objects interact?
- What roles and responsibilities do objects perform?
▸ We use functional decomposition to decompose a large-scale system into smaller
subcomponents
- However!
▪ Modern systems perform more than one function
▪ Modern systems need to be evolvable and maintainable
▹ This would cause a redesign the whole system
▪ Modern systems need to interoperate with other systems
- Use Object-Oriented Decomposition instead!
▪ Decompose according to the objects a system is meant to manipulate
▪ This is better for complex and evolving systems

Iteration in OO Design
▸ Result of design is not a final product
- Design must be revisited even after implementation
- It is not algorithmic—no one size fits all approach
▸ Design method provides guidelines, and not fixed rules
▸ You need a good sense of style that helps produce clean and elegant designs
▸ Responsibility-driven design

18 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Design Steps
▸ Initial Exploration:
- ( 1 ) find the classes in your system
- ( 2 ) determine the responsibilities of each class
- ( 3 ) determine how objects collaborate with each other to fulfil their responsibilities

( 1 ) Finding Your Classes

▸ Look for noun phrases in your requirements
- Separate into
▪ obvious classes
▪ uncertain candidates
▪ nonsense
- Similar to the development of your Domain Model
▸ Class Selection Rationale (CSR); Refine your candidate classes
- Physical Objects: disks, printers
▪ Be careful though; a mouse button click is actually Input Event
- Conceptual Entities: windows, files
- Categories of Classes: inheritance
- Interfaces to the system: user interface, APIs
- Model attribute values, not attributes: Point vs Centre
▪ Height of Shape, Width of Shape, Position of Shape, Corner Radius
▪ These won’t be classes—these will be attributes to classes
- Consolidate your vocabulary
▪ Nominate one word for a concept
▪ Same concept can be described by multiple worlds
▹ Drawing Editor == Graphics Editor == Editor
▹ Shape == Drawing Element
- Adjectives are worrisome—an adjective isn’t usually a class
▪ Ellipse Creation Tool, Line Creation Tool, Rectangle Creation Tool
▹ These are all Creation Tools—they just draw it in the same way!
▪ Start Point, Midpoint, End Point
▹ These are all Points
▪ Associated corner, diagonally opposite corner
▹ These are still just corners with no new behaviour
- Misleading subjects—rephrase in the active voice!
▪ The current selection is indicated visually by displaying the control points of element
▹ Assume that this is a drawing editor

19 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▸ Class Responsibility Collaboration (CRC)

-
- Record the candidate Class Name and Superclass
▪ We don’t know the actual name, but just use the candidate name
- Record each Responsibility and its Collaborating Class

- Record each Responsibility and its Collaborating Class

▪ If a responsibility needs a collaborating class to produce output, write the
collaborating class beside it
▪ This is optional
- CRC cards are a design tool to explore possible designs
▪ Get the team together
▪ Distribute the cards around
▪ Walkthrough the scenarios
▪ The exercise will uncover: unneeded/missing classes + responsibilities

( 2 ) Determine the responsibilities of each class

▸ Responsibilities are States and Operations
- things the object knows (state)
- actions the object performs (operations)
▸ Responsibilities represent the public services
- What not how
- Conceptual responsibilities—don’t describe the interface yet
▸ Analyse the SRS:
- Highlight verbs
- Perform a walkthrough
- Explore as many scenarios as possible
▸ Analyse the Candidate Classes: class names/CRC cards -> roles -> responsibilities
20 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▸ Be sure to evenly distribute system intelligence

- Let someone else do something if it can be done
- Reduce strong coupling (inter-dependency)
▸ Avoid procedural centralisation
- Let there be distinct boundaries between objects
- Reduce weak cohesion (intra-dependency)
- We want STRONG COHESION
▸ Keep responsibilities close to objects rather than their clients
- But this may not always be possible or desirable
- Let them do it
▸ State the responsibilities as generally as possible
- “Draw yourself” vs “Draw a line”
▸ Encapsulate related behaviour with state together
- But reduce coupling!
- If information about one thing needs to be shared across classes consider:
▪ ( 1 ) a new manager object can be introduced to manage the information
▹ avoid classes that purely hold data
▪ ( 2 ) one of the objects may be the obvious “maintainer”
▪ ( 3 ) the multiple objects may need to be merged into one object
▸ Additional responsibilities may come out of examining relationships
▸ Kinds of relationships:
- “Is a kind of”: superclasses, generics
▪ Classes share a common attribute
▪ Common super-classes suggest common responsibilities
- “Is analogous to”: ??
- “Is part of”: Compositional

( 3 ) Determine the relationships between classes

▸ In doing a process, you will need a collaboration between another object
▸ They can reveal:
- missing responsibilities,
- control and information flow
▸ To find collaborators:
- For each responsibility:
▪ Can I do it by myself?

21 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▪ If not, what other classes do I know can obtain this information?

- For each class:
▪ What do I know and what can I do?
▪ What other classes need my state or operations?
- Summary:
▪ Application = set of interacting objects
▪ Object = implementation of one or more roles
▪ Role = set of related responsibilities
▪ Responsibility = an obligation to know things or do operations
▪ Collaboration = interaction of objects or roles

Protocols and Roles

▸ Object collaborations are described using protocols
- Interfaces and interaction sequences/dependences
- Each participant in a collection plays a given role
▸ Collaboration protocol
- Sequence of method invocations where multiple classes interact with each other

Associations and Aggregation Relationships

▸ Association—non-ownership relationship
- From time to time, one class needs to associate to another class
- Makes reference to that class then forgets about it
▸ Aggregation—ownership relationship
- Part-of me—dependent on the aggregated object
- If I get deleted, you get deleted
- Fields in the class
- Lifetime associated to the ‘owning’ class

Collections
▸ Only need enumeration—Choose the most general
▸ Avoid duplicates—Choose a unique element collection (Set)
▸ Indexable Elements—Choose indexable collection (Array/List/Hash)
▸ Specific Order—Choose collection that allows ordering (Array/List not Set)

Heuristics
▸ System Classes
- ( 1 ) A class should only capture one key abstraction
▪ increase cohesion
- ( 2 ) Keep related data and behaviour in one place

22 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▪ defines unnecessary accessor methods

▪ data-only classes
▪ increased coupling is implied
- ( 3 ) Distribute system intelligence horizontally as uniformly as possible
▪ need to think where system objects are created
▪ top-level classes of the system should uniformly share their work
- ( 4 ) Do not create god classes/objects in your system
▪ too much responsibilities in one class
▪ too much complexity
▸ Inheritance
- ( 5 ) Inheritance should be used to model a specialisation
- ( 6 ) Subclasses should not know anything about their superclass
▪ A fruit shouldn’t know anything about an apple
- ( 7 ) Inheritance hierarchies should be deep
- ( 8 ) Inheritance hierarchies should be no deeper than an average developer can keep in
memory
▪ No deeper than 5 to 7 as a maximum depth
- ( 9 ) Explicit case analysis on the type is wrong; designer should use polymorphism
- ( 10 ) It should be illegal for a deprived class to override a base class method that does
nothing
▪ Declaring a NOP method implies that the classes not have a particular responsibility
-
▸ Abstract class
- ( 11 ) All abstract classes must be base classes
- ( 12 ) All base classes should be abstract classes
▪ In inheritance trees, only lead nodes should be abstract classes
▪ Other nodes are abstract
▸ Base class
- ( 13 ) Factor the commonality of data, behaviour and interface as high as possible
▪ Reduce the amount of classes where specific information is kept
- ( 14 ) Make sure abstract classes do not inherit from base classes
- ( 15 ) Eliminate classes that do not add functionality
▪ Revise inheritance relationships
▹ Introduce abstract superclasses to encapsulate common responsibilities
▸ Interaction
- ( 16 ) Minimise the number of classes with which another class collaborates
- ( 17 ) Minimise the amount of collaboration between a class and its collaborators
23 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▪ Reduce the number of messages sent

▪ A collaboration protocol should have few methods
- ( 18 ) Do not turn an operation into a class
▪ Be caution when the name of a class is derived from a verb
▪ However, applicable in some cases: Strategy, Command
▸ Aggregation
- ( 19 ) Choose a aggregation relationship over an association relationship
▪ Reduces exposure to class internals
▪ Be careful though—life of objects rule (are you sure you want to delete it)
Design by Contracts
▸ Abstract vs Concrete State
- External representations of state is abstract state — what client sees
▪ Clients rely on the object’s abstract state
▪ Object equality should be defined by abstract state
- Internal representations of state is concrete state — how I implement it
▸ Command/Query Separation
- Divide methods into queries and commands
- Queries
▪ Return a result
▪ Do not mutate the abstract state
▪ May mutate the concrete stack (such as caching)

24 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

- Commands
▪ Will change the abstract state
▪ Do not return a value
▸ Design by contracts
- Formal Agreements or Contract:
▪ The interface between the object (service provider) and the client (service
consumer)
- Pre-conditions
▪ Before you do the operation, service consumer ensures the condition must be true
▪ If not, then the service provider is not obligated to perform its operation
- Post-conditions
▪ After you do the operation, service provider ensures the condition must be true
▪ Errors must be flagged to the consumer
- Invariants of the service provider must hold after successful execution
- Benefits?
▪ Enforces separation of concerns
▪ Explicit notation of contextualised correctness
▪ Facilities testing and debugging
▪ Enhances documentation—facilities reuse

25 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Design Patterns
▸ Helps us solve recurring problems in programming
- Identify the problem
▪ BUT: Hard to recognise the applicability of the pattern to use with the problem
- While we can't change the language itself, we can introduce standard patterns to use
▸ Proven and good solutions to these problems
- Same solution approach to these problems
- Don't have to reinvent the wheel
- Use best practises which knowingly work
- BUT: Only just generalised 'blueprints'—not actual code abstractions
▪ Think Housing Codes—different houses, but same follow the same Housing Code
- They are:
▪ Widely re-usable in many contexts
▪ Improve communication within teams
▪ Capture knowledge of experienced developers
▪ Arise practical experience
▪ Facilitate training of new developers
▸ Reduces maintenance overhead
▸ Design Patterns aren't about Design
- They describe the iteration, communication and aggregation of entities in programs
- It's all about managing complexity of these entities
- They do not tell you about application-specific abstractions
▸ Design patterns are not algorithms
- Algorithms solve computational problems
- merge sort is an algorithm
- divide and conquer is a pattern
▸ Deigns patterns are not software components or frameworks
- Design patterns document ways to implement components or frameworks
- Frameworks or components may be implementations of design patterns
- Frameworks implement generic software architecture
- They platform independent and are by no means concrete
▪ Instantiation of a pattern means that the template provided becomes specialised
▪ Pattern realisation can really be seen when you hide the specifics of your program

26 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Idioms are common programming techniques and

Idioms
conventions. They are often language-specific.
Patterns document common solutions to design
Patterns
problems. They are language-independent.
Libraries are collections of functions, procedures or
Libraries other software abstractions that can be used in
many applications.
Frameworks are open libraries that define the
Frameworks generic architecture of an application, and can be
extended by adding or deriving new classes.

Libraries
▸ Application makes use of libraries
▸ Library code is used in functions or
User Application
procedures Library classes
main()
▸ Think Node package which helps extend
your code for a specific purpose

Frameworks
▸ Application code is called by the
Framework classes
framework ฀
User classes
main()
▸ Inverse relationship of a library
฀
▸ Provide generic functionality and application architecture
▸ Think [Link] framework; your code is called by Node in it’s main

Idioms
▸ Idioms are low-level patterns
▸ How to implement particular aspects of components or relationships
▸ They are language specific

27 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Idiom: Delegation
▸ Delegation allows us to share object behaviour without inheritance
- Inheritance is good to extend object behaviour; more flexible and less structured
- If you're not extending behaviour and just want to combine features, then delegate
▸ You delegate some of your behaviour and pass it to another object
- Reinforces encapsulation
- Ensures responsibilities and roles remain distinct
▸ Example:
- ChessBoard needs to undo its move
- It will delegate that behaviour to its corresponding Move object
public class ChessBoard {
...
public void undoMove() {
if (!([Link]())) {
Move lastMove = [Link]();
[Link] (this);
[Link](lastMove);
}
}
}

Undoes the last move that was in this object

Idiom: Interfaces
▸ Keeping a service independent to the class that provides the service
- A contract between the client and the service
▸ The client uses that service through an interface
- If you provide a service as a concrete class, then people who want to use that interface
can only be subclassed from that interface 😞

- Instead, any class can be a client of that interface by implementing the interface
methods 😊

▸ Example:
- Player interface
▪ Any class that wants to be a chess player client implements the interface Player
- Sortable interface
▪ Any class that wants to be a sortable client implements the interface Sortable
▸ Reduces class coupling BUT adds complexity by having indirection in your code

28 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Patterns
▸ Four aspects to patterns
- ( 1 ) Pattern Name
▪ Patterns have names to improve communication between programmers
▪ The essence of what the pattern does
▪ Programmers abide by these names to know how a program's application of
patterns
▪ My program applies Factory in XYZ… my program has MVC in ABC…
- ( 2 ) Problem Forces
▪ Describes when to use the pattern if the problem can be identified in your program
▪ An iterator patterns helps us with Traversal problems
- ( 3 ) Solution
▪ Describes the elements that constitute the design
▪ Remember, these are general guidelines only
▹ An iterator pattern is but a basic guide
▹ It is not application specific—need to implement for it to work in your own code
- ( 4 ) Consequences
▪ The results and trade offs when using and applying the pattern to your code
▪ Known uses
▪ Competing patterns
Pattern: Template Method
▸ Provide a skeleton of an algorithm in operation
- Subclasses redefine parts of algorithm without changing the algorithm’s structure

- Useful for frameworks where you should subclass particular superclasses

▪ XCTestCase for the XCTest framework for unit testing etc.
▪ UIViewController for the UIKit framework; override viewDidLoad:
▪ Subclasses override to implement concrete behaviour and correct logic
29 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▸ The ConcreteClass relies on the AbstractClass to implement non-varying logic

▸ Consequences:
- Factoring out common behaviour in the class libraries
- Inverted control structure; the parent class calls the child methods
Pattern: Factory Method
▸ Delegation of instantiating a specific concrete subclass in this method
- Encapsulates the way in which instantiation should occur for a base class
public abstract class ChessPiece {
...
protected Collection<Behaviour> behaviours = null;
// Constructor
protected ChessPiece(...) {
...
[Link] = new HashSet<Behaviour>();
// call a deferred method
[Link]();
}
}
...
// Instantiations of concrete behaviors is left to subclasses
protected abstract void setBehaviours();
}

Pattern: Strategy
▸ Delegation of a family of algorithms that can be utilised interchangeably by any client
- Used in conjunction with Template Methods

ChessPiece * Behaviour

HorizontalBehav. DiagonalBehav.

VerticalBehav.

Bishop Queen Rook

public abstract class ChessPiece {

...
public boolean isValid (Move aMove) {
boolean isValid = false;

ChessPiece destPiece = [Link] ([Link]());

„ if ((destPiece == null) ||
(!([Link]().equals([Link])))) {

for (Behaviour aBehaviour : [Link]) {

if ([Link] (aMove, [Link])) {
isValid = true;
break;
}
}
}

return isValid;
}
...
}

30 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Pattern: Composite
▸ Management of a whole-part hierarchy in a consistent way
- Composite (superclass) implements behaviour as well as parts (subclasses)
- Delegation of whole behaviour to its part

„
Pattern: Observer
▸ Notifications of any clients to inform of state change
- Clients implement a common Observable interface
- The subject notifies each of its observers
„ (of differing concrete classes) of state changes
when its states change
- Problems? It can be slow if there are a lot of notifiers to notify
▸ Observer pattern can be useful to keep different layers of the application as separate as
possible

GUI layer click

GUI
notify
update

update
notify
Business layer
31 / 45
Business object

Change state
Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])
 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Pattern: Null Objects

▸ Avoid cluttering your code with null references
▸ Implement a NullObject interface that does nothing
▸ The NullObject implements the interface you expect, although it implements those
methods by doing nothing
- E.g., NullOutputStream extends OutputStream, except it overrides write to do nothing
Pattern: Singleton
▸ Ensuring a class has a single instance to it
- Keeps track of a static reference to the instance which is referenced to statically
▸ Controlled access to specific resources
- [Link], NSNotifi[Link]
- There only ever needs to be one board

public class Singleton {

...
private static Singleton myInstance = null;
protected Singleton() {...}
...
public static Singleton getSingleton() {
if (myInstance == null) {
myInstance = new Singleton();
} class Singleton {
return myInstance; let sharedInstance = Singleton()
}
}
}

Pattern: Command
▸ Command decouples an operation that needs to be invoked
▸ Decoupled from the specific way the operation needs to be performed
▸ You can pass the command object around; encapsulate behaviour of the command in the
object itself

32 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

33 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Architectures
▸ Subsystems is a system in its own right can be deployed by itself
- Can be deployed and run
▸ Module is a component of a system to provide services to other components
- Not functionally independent; cannot be deployed
- Helpful for development
- Use modules to help form a system/subsystem
▸ Component is a unit of software that encapsulates design and implementation
- Offers an interface to outside components
▸ Architectures
- structure of high-level processing elements
- externally-visible properties of elements
- relationships and constraints between elements
▸ Layered Architectures
- Organise subsystems, modules and components into a set of layers
- Lower layer provides services to layer above
▪ The higher layers utilise the lower layers to perform their functionalities
- Pros:
▪ Each layer can be componentised
▪ Each layer acts independently of the other layers
▪ Development can be incremental—work on the lower layers to the higher ones
- Cons:
▪ You need to design your layers right
▹ Need to get the layer design right from the get go
▹ If not, it means you may need to redesign the whole layer structure
▪ Need a clear division of layers, which can be hard
▹ Difficult to do without the right mindset at the start!
▪ When showing clients your progress, they usually only are about higher layers
▹ Thus, if you show them lower layers, they mightn’t get to see desired product
functionalities
▹ This is because presentation layers usually are a the top layers
▹ Usually no demonstrable outcomes with each layer

34 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

- Example: OSI Reference Model:

- Example: Enterprise system

▪ Presentation Layer
▹ Exposes data and behaviour to users Presentation Layer
▹ Event-based
▪ Domain Layer
▹ Business logic: rules, goals, workflows Domain Layer
▹ OO often used
▪ Data Source Layer
▹ Data of the system
Data Source Layer
▹ CRUD operations
▹ Declarative language like SQL

35 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Architecture styles
Data-flow
▸ Focuses on functional transformation of input to output
- Data source(s) — where the input(s) comes from
- Data sink(s) — where the output(s) go
▸ Usually no cycles unless a feedback loop is introduced
▸ Not suitable for interactive systems
▸ Examples:
- Batch sequences
- Pipes and filter
▪ Each filter (processing element) processes one type of data transformation
▪ Data flows (pipes) from one filter to the next:

cat [Link] | grep -c Banana | echo You have $1 bananas

Call and return UI Mgt, A&A

▸ Layered Architectures (see
above)
User Interface

- One layer calls services from

the layer below and returns
information back
▸ Client/Sever Model
▸ Tiered architectures
Tiered architectures combine
layering with physical distribution 36 / 45
Database Support 31

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016
„
Repositories
▸ All data in a system„is managed in a central repository, or blackboard
- Maintains a single source of truth
- Processing components surround the data
▸ All components can access the blackboard
- A blackboard differs from a sole repository architecture in that it is event-driven control
- Changes to data are only triggered by events which other components react to
▸ Components do not directly communicate
- All communication happens indirectly through the repository
- Dependency only lies between the data and each component
- E.g., diagram below, all surrounding components communicate via the project repo

▸ Pros
- Efficiently allows large amount of data to be stored
- Components needn’t worry about how data is created, backed up etc.
- Sharing model can be published as a schema
▪ Means easy coordination between components
▸ Cons
- Components must agree on a schema
- Data evolution is difficult and expensive
▪ Migrating lots of data means translating it to a new schema!
- No scope for management policies
- Difficult to distribute efficiently
▸ Examples:
- GitHub/Git
Client/Server Architecture
▸ Distribute application logic and services to a number of clients and servers
- Advantages:
▪ Distribution of data is straightforward
▪ Effective use of networked systems
37 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▪ Easy to add or upgrade severs

- Disadvantages:
▪ No shared data model
▹ Subsystems may use different data organisation
▪ Data interchanging can be inefficient
▪ Redundancy management in each sever

Inter-component Communication Medium

Client/Server Architecture
P2P Architecture
▸ Peer to peer is decentralised
- Peers are independent and act as both data suppliers and consumers
▸ Efforts shared amongst interconnected peers
▸ Make a peer makes their resources available to other peers
- Peers are dynamic; they come and go randomly
▸ No centralised coordination

Heterogeneous styles
▸ Systems don’t conform to one architectural model/style
- They incorporate different styles at different levels of abstraction
„
▸ Locationally heterogeneous:
- Different architecture styles at different areas
- The branches of a main-program-and-subroutine system have a shared data repository
„
▸ Hierarchically heterogeneous:
- A component is used in one style, but is composed using a different style
- A pipe and filter element is structured in a layered style in itself
▸ Simultaneously heterogeneous:
- A system is described using multiple architectures at once
- A compiler is both a data flow and/or repository system, depending on the viewpoint

38 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Reference Models & Reference Architecture

▸ Reference model is a division of functionality together with data flow
- A standard decomposition of a known problem into parts that solve the problem
▸ Reference architectures are reference models mapped onto software components
- Mapping of system functionality onto a system decomposition
- Reference architecture = reference model + architectural style.

Architectural Tactics
▸ Transformations on an architecture or system input
▸ Improves upon an existing architecture’s quality attributes
▸ Examples:
- Availability
▪ Detects faults in the system
▪ Masks the faults or repairs the system from fault
- Modifiability
▪ Detect new changes to the system
▪ Localise each change and ripple changes to system
- Performance
▪ Events arrive
▪ Alter resource demands as requests increase
▪ Scale resources
▪ Response generated within constraints
- Security
▪ Attacks posed
▪ Resist attacks through authentication
▪ Detect that the attack occurred
▪ Recover from an attack
▸ Tactics are not design patterns
- Any pattern implements several tactics
- Implementation of the patterns make choices about the tactics made

39 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Documenting Architectures
▸ Designs help us bridge the gap between requirements and implementation
- Assist software engineers to develop software given a set of requirements
- Help to verify the software built
- Help to produce a blueprint for the implementation
▸ Architectures help express:
- system and its evolution
- communication amongst stakeholders
- planning, management and executing system development
- verify the implementation compliance with architectural descriptions

Purpose of Documentation
▸ Communicate
- Discussing possible solutions to different stakeholders
- Describing the solution in a way they understand (e.g., UML)
- Focusing on big-picture
▸ Specify
- Blueprints for the implementation
- Detailed design specification for developers
- Avoid ambiguity; focus on specifics
▸ Different stakeholders have different interests and needs for documentation:
- Client
- End-user
- Developer
▪ System maintainers
▪ System administrator
- Business manager
- Business analyst
▸ Views
- Focus on aspects of a system using appropriate abstractions
▪ Components: Runtime computational entities
▪ Connectors: Means of communication in which components interact
▪ Allocation: Physical environment of components
▪ Module: Code units and responsibilities (packages)

40 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

- There are different concrete implementations of views

▪ Kruchen’s 4+1 is a good starting point for documenting architectural designs:

▹ Problem:
▫ Not standardised
▫ Developers are dumb apparently (well most of them are)
▪ Standardised version is IEEE Conceptual Framework:
▹ A meta-model of software architectures
▹ Addresses specific stakeholder concerns
▹ Separates viewpoints from view
▫ Viewpoint identifies the set of concerns and modelling to address them
▫ Provides a rationale for inconsistencies and unresolved issues
▹ Establish the terms for architectural thinking
▹ Each view corresponds to one viewpoint

41 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

▸ Notations
- Can be graphical
▪ Must be used systematically; else leads to ambiguity
▪ Primary use for communication, not specification
▪ Why UML?
▹ Reduce risks by documenting assumptions
▹ Represents industry standard (lel nah it doesn’t)
▹ Is well-defined and open
▪ Examples of UML architecture diagrams on next page
- Can be a DSL
▪ high-level programming languages
▪ basic building blocks are architectural elements (components, connectors)
▪ Primarily outlining specification of architecture (i.e., detailed)

42 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

UML architecture notation

Package Diagram
Decompose the system into
packages

Deployment Diagrams
Runtime components on hardware

43 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Software Design Evaluation

▸ Why do it?
- To detect early flaws
- Improve the quality of our designs
- Opportunity to fix design flaws before code is written
▸ Early verification of architecture
- Opportunity to validate requirements
- Resolve any conflicting goals
- Improve rationale for architecture
▸ Pros
- Improve articulation and verification of critical architecture
- Forces clear explanation of design
- Enhance communication between stakeholders
▸ Cons
- Take time
- Money is spent
- Frustrating when stakeholders cannot agree
- Tradeoffs…
▸ METHOD: ATAM (architecture tradeoff analysis method)
- Systematic way to analyse architecture
- Very comprehensive

▪ 😞 Takes weeks to complete

▪ 😞 Involves every stakeholder to be involved

▪ 😊 Proven that many design deficiencies can be uncovered

▪ 😊 Comprehensive risk analysis

▪ 😊 Cannot hide behind “fluff” documentation

▸ METHOD: Quality Utility Tree
- Checklist driven approach since ATAM is too heavyweight
- Building a utility tree
▪ Top-down approach to the driving architectural drivers:
▹ ( 1 ) Important quality attributes are at the top-level
▹ ( 2 ) Drill down into quality requirements
▹ ( 3 ) Scenarios are the leaves
▹ ( 4 ) Assess leaves based on important and difficulty

44 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])

 lOMoARcPSD|23216638

Software Architectures And Design Alex Cummaudo

SWE30003 6 March 2016

Quality Attribute

Scenario

Quality
Requirement

Low importance
High difficulty 53

Data utility tree

45 / 45

Downloaded by PHAN HUY QUANG (huyquangph2004@[Link])