Transcript SA_008_ADD

Software Architecture
Prof.Dr.ir. F. Gielen
Attribute Driven Design
Vakgroep Informatietechnologie – IBCN
Successful Software Systems
“We have observed two traits common to
virtually all of the successful OO systems we
have encountered, and noticeably absent
from the ones that we count as failures:


The existence of a strong architectural vision and
The application of a well-managed iterative and
incremental development cycle.”
- Grady Booch
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 2
Where are we ?
Previously we have examined:




Architecture views
Quality attributes
Documenting Software Architectures
Architectural tactics and patterns for achieving quality attributes
Now Focus on Design of an Architecture




Architecture in the software life cycle
Designing the architecture
Teams and their relationship to the architecture
Creating a skeletal system
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 3
Software Life Cycle
Software



Life Cycle Models
Waterfall model
Spiral model
Others?
Where
does the architecture fit in?
What is the place for the software architecture?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 4
Evolutionary Delivery Life Cycle
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 5
When do we start developing the SA?
Requirements come first

But not all requirements are necessary to get started
Architecture shaped by (remember the ABC)




Functional requirements
Quality requirements
Business requirements
Expertise and experience of architects
We call these : Architectural Drivers


The architecture of of an Air Traffic Control system is driven
by high availability.
A Flight simulator is driven by hard real time response times.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 6
Determining Architectural Drivers
Identify the Architectural Drivers:

Identify the highest priority Business Goals



Only a few of these
Turn these into scenarios or use cases
Choose the ones that have the most impact on
the architecture


These are the architectural drivers
There should be less than 10 of these
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 7
Attribute Driven Design: ADD
Design an architecture that supports both functional
requirements and quality requirements.



ADD: architecture design using a decomposition process that is
based on the quality attributes of the the system
ADD input: architectural drivers
ADD output: levels of module decomposition and related
architectural views
Relation to Rational Unified Process (RUP) ?

RUP includes the full life cycle. ADD can be part of the high level
design steps in RUP.
Hybrid: ADD for SA then following RUP for the rest of
the design
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 8
ADD Overview
1. Choose the module to decompose
a. Start with entire system
b. Inputs for this module need to be available

Constraints, functional and quality requirements
2. Refine the module
a. Choose architectural drivers relevant to this decomposition
b. Choose the architectural patterns that satisfies these drivers
c. Instantiate modules and allocate functionality from use cases
representing using multiple views.
d. Define interfaces of child modules.
e. Verify and refine use cases and quality scenarios.
3. Repeat for every module that needs further
decomposition
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 9
ADD : Mobile Internet eXtentions - MobiX
Input to ADD: a set of requirements



Functional requirements as use cases
Constraints
Quality requirements expressed as system-specific
quality scenarios
Apply this to the Mobile Internet Case
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 10
Case study: Mobile Internet Trends



Higher speed mobile service (HSDPA) to be launched in in the
next 12 months
GPS enabled handset reach mass market in 18 months
Web 2.0:




The web as a platform : i.e for building mobile applications
User generated content (Blogs, photo sharing etc.)
PC as a personal - cache
Technology:



Browser based applications: Opera, Pocket Explorer, Minimo
…
– vs. downloaded & installed applications
AJAX standard enables better user experience in the browser
– Googel calendar
Mobile widgets to allow easy application development:
– E.g. Event Calendar
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 11
Need – Problem to solve

Mobile internet is not getting momentum due to


A lack of mobile web content and applications
Bad user experience





Cumbersome
Costly
Download times
Users don’t want to pay a premium for mobile content
Mobile search:



Google, Yahoo have mobile search portals but …
They lead to websites that are not MobileOK
Smartphone Show & Symbian Ltd. Tradeshow - Oct 2006 :

“Server side infrastructure to render applications and services
usable on mobile devices is still lacking”
 Alan Eustace, Google Sr.VP of engineering
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 12
Approach

Create content and mobile applications based on existing
webcontent

Mobile Web




User focused , not technology focused
No automatic transformation but intelligent adaptation


Usability factors – Entering a hyperlink on a phone can be showstopper
Content selection : Mobile web is different from the “desktop” web



It is not the web on a mobile device
… but is an extension of the web to mobile applications
What does the mobile user wants “to go”
Mobile application platform: add applications to web content
Increase the user experience with mobile features:



Location based
Context aware
Personal
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 13
Mobix Idea Description
Existing
Websites
Extract
Video
Text
Structure
Pictures
Figures
Add
Interaction
Audio
Location Info
Context Info
Personalization
Mobile Application Widgets
Mobile
Applications
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 14
1. Choose the Module to Decompose
System  subsystem  module 
submodule

Steps in example



Start with the entire system as the module
Refine the module
Repeats for every module that needs further
refining
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 15
Mobix System View
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 16
2a: Choose Architectural Drivers
2a. Choose the architectural drivers from the
quality scenarios and functional requirements:


The drivers will be among the top priority requirements for the
module.
In the Mobix system, the 5 top level requirements are
architectural drivers, lots more are not given (e.g., testability)
NOTE: Requirements are not treated as equals:


Less important requirements are satisfied within constraints
obtained by satisfying more important requirements
This is a difference of ADD from other SA design methods
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 17
MobiX Quality Attributes
Usability


Content conversion must take into account usability rules that are specific
to the mobile device allowing for example simple and user-friendly
navigation and interaction.
The user does not need to install any software on the mobile device or
perform complex actions to use the service.
Modifiability



The system must be easily adapted to new devices and changing network
capabilities.
The system must quickly adapt to new mobile technologies such as location
based services, context aware applications, user profiling & behavioral
based content.
The platform must support different mobile applications such as gaming ,
mobile advertising that require content conversion.
Performance & Scalability


During normal conditions, the system should transcode a mobile web page
such that the page starts loading on the users screen in less than 2
seconds.
The target user group is very large, most network operators have multiple
millions of customers. While these users don’t use their device all at the
same time, certain events can cause a high peak usage. The system
should respond gracefully to peak loads
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 18
2b: Choose Architectural Patterns
An architectural pattern is determined by:




A set of elements
A topological layout of the elements indicating relationships
A set of semantic constraints
A set of interaction mechanisms
For each quality requirement there are identifiable
tactics and then identifiable patterns that implement
these tactics.
Patterns have an impact of several quality attributes.


How do we balance?
What are the trade-offs ?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 19
2b: Choose Architectural Patterns
The goal of this step is to establish an overall
architectural pattern consisting of module types .


The pattern needs to satisfy the architectural drivers
It is built by composing the tactics selected to satisfy the drivers
Two factors involved in selecting tactics:


Architectural drivers themselves of course
Side effects of the pattern implementing the tactic on other requirements
Example: to achieve Modifiability Quality Attribute


use “Prevention of Ripple Effect” Tactic
yielding “Layers” and “Intermediary” pattern
Layers & Intermediaries adversely affect performance
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 20
Microkernel Pattern
The Microkernel Pattern Context:


Applies to systems that must adapt to rapid changing system
requirements
Has a minimal functional core used in different ways:



E.g.: Real time operating systems
With specific functional extensions and customer specific parts
Typical Solution for application platforms:



Cope with continuous technology change
Portable, extensible & adaptable system
Acts as a plug in and a coordinator for the interactions between
the modules.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 21
Microkernel Pattern
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 22
Example : Mach & Mac OSX
Based on the need to move away from the
monolithic Unix kernel.
 CMU’s Mach project redesigned a
component based kernel that could:




Mach intended to replace the old BSD kernel with
a new, component based kernel with an emphasis
on multiprocessing.
Mach 3.0 was intended to be a true microkernel
system that could support an external operating
system (like BSD) living outside the kernel space
Apple & NeXT use Mach as the basis for their OS
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 23
Microkernel module

Main component


Central Services





Core functionality
Communication
Resource Management
Interfaces for external services
Encapsulate system dependencies
Performance trade-off:


Functional core with minimal memory size &
services that consume as little processing power
as possible
Offers atomic services
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 24
Internal Servers or Subsystems

Extends the kernel


Encapsulation


HW dependencies
Invocation via service requests


Additional functions
Communciation protocol design !
Only accessed via the microkernel
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 25
External Servers or Personalities

Uses atomic services


To implement policies
Only interacts with the microkernel
Offer application interfaces
 Runs in separate processes



Linux server
Windows server
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 26
ADD 2c: Instantiate & Allocate Functions
1. Choose the module to decompose
a. Start with entire system
b. Inputs for this module need to be available

Constraints, functional and quality requirements
2. Refine the module
a. Choose architectural drivers relevant to this decomposition
b. Choose the architectural patterns that satisfies these drivers
c. Instantiate modules and allocate functionality from use
cases representing using multiple views.
d. Define interfaces of child modules.
e. Verify and refine use cases and quality scenarios.
3. Repeat for every module that needs further
decomposition
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 27
2c: Instantiate Modules
In step (2b) we established the module types of the
decomposition:




Microkernel
Internal servers
External servers
Client applications
In this step we instantiate these module types:




Device context management
Content Fetcher
Transcoder
User Management, Location Mangement ..etc.
The criterion we use for allocating functionality is similar
to that used in traditional OO designs
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 28
Architectural Pattern: Mircokernel
1. Analyze the application domain and identify the core
functionality necessary for implementing the external
services
2. Analyze the external services to find the policies that they
have to provide to clients
3. Categorize the services into semantically independent
categories (candidates for internal servers)
4. Partition the categories between the microkernel & the
servers
5. Determine the communication strategies
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 29
Step 2c.: Mobix Subsystem structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 30
Functional Allocation






The Microkernel acts as web platform operating
system that allows easy application building
the Content Fetcher combines existing web
content with new –typically- mobile web content
and to extend the web with mobile features.
The Device Context Manager takes care of device
and network diversity
The Transcoding Subsystem is responsible for
the real-time translation of web content and
layout
The User manager handles personalization, user
profiling, individual preferences and presence
information
The Location manager handles location based
information
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 31
Refine Module 2c: Allocate Functionality
Next Step: Verify if the module decomposition
achieves the desired functionality.
Allocate functionality:





Applying use cases may modify decomposition
In the end every use case of the parent module must be
implemented by a sequence of responsibilities of the children.
Assigning these responsibilities to the children will also determine
communications: producer/consumer relationship
How the information is exchanged is not critical at this point.
Some tactics will introduce specific patterns of interaction:

E.g. use of a “publish-subscribe” intermediary introduces
pattern “publish” for one module “subscribe” for the other
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 32
Module Identification and Function Allocation
CRC-cards
= Class - Responsibility - Collaboration card
= Container for responsibilities
Class name :
Class type :
<system> <subsystem> <module> …
Class characteristic :
Responsibilities :
Describe the functionality
of the module
Collaborations :
List other modules needed
to achieve this functionality
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 33
Child module identification
CRC cards:


Show collaborations between the child modules
Find new responsibilities based on role play


Driven by scenarios and sequence diagrams.
Identify new child modules based
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 34
Case : Mobix
Class name :
Responsibilities :
Device Context Manager <module>
Collaborations :
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 35
Case :Mobix Services system
Class name :
Responsibilities :
Transcoder
<module>
Collaborations :
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 36
Top level scenario based on CRC
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 37
Represent the Architecture with Multiple Views
Multiple Views:
Module decomposition view (Static)


Provide containers for functionality
Shows relations between modules
Concurrency view (Dynamic)

Parallel activities such as resource contention, deadlock

Likely will lead to the discovery of new responsibilities

Possibly new modules – e.g. a resource manager

Use cases:



One user performs multiple activities
Two users doing similar things
Synchronization: “starts,” “stops,” “synchronizes with,”
“cancels,” “communicates with”
Deployment
view
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 38
Refine Module 2d: Define interfaces of child modules
At this level by “Interface to module” we mean
document the services and properties provided, not
the more detailed “signature” of a method.

It documents what this module provides to others.
Analyzing the decomposition into the three views
provides interaction information for the interface



Module view
Concurrency view
Deployment view
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 39
Refine Module 2d: Defining interfaces
The three views provide:
Module view

Producers/consumers relations; patterns of
communication
Concurrency


Interactions among threads
Synchronization information
Deployment



view
view
Hardware requirements
Timing requirements
Communication requirements
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 40
Refine Module 2e: Verify and Refine Scenarios
We now have a “proposal” for the decomposition of
the module.
The next step is to analyze it and see how well it fits.
This involves :


Verifying the decomposition by “running” the parent’s use cases
- iterative design
Preparing children for their own decomposition by inheriting use
cases/constraints from the parent.
We will examine this by looking at:



Functional requirements
Constraints
Quality Scenarios
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 41
Refine Module 2e: Functional requirements
Using Functional requirements to verify and refine


Decomposing functional requirements assigns responsibilities to
child modules.
We can use these responsibilities to generate scenarios for the
child module.
E.g. Mobix Transcoder subsystem responsibilities




Analyze the content of the requested webpage.
Optionally Fix the HTML
Transcode HTML, multimedia elements, Javascripts ..etc.
Generate XHTML-MP based on device characteristics.
The responsibilities can be assigned to the child
modules
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 42
Architectural Pattern: Pipes and Filters
Context
•
•
Processing
data
streams
Problems
•
Solution
Future system enhancements should be
possible
• Small processing steps
Motion of
data
• Non-adjacent processing
through the
information
system
steps do not share
•
Different sources of input data exist
•
Present or store final results in various ways
•
Explicit storage of intermediate results for
further processing
•
You may not want to rule out multi-processing
the steps
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
•
Apply the Pipes
and Filters
architectural
pattern: the tasks
of a system are
divided into
several sequential
processing steps,
connected by the
data flow through
the system
p. 43
Pipe&Filter Components
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 44
Pipes and Filters: pro’s & con’s
+

Modifiability
Reuse of filter components
• Flexibility by filter exchange
• Flexibility by recombination
•

Performance
Efficiency by parallel processing
• No intermediate files necessary
•
Rapid
prototyping of
pipelines

Performance
• Sharing state information is
expensive or inflexible
• Efficiency gain by parallel
processing is often an illusion (e.g.
cost for transferring data, contextswitching is expensive,,
synchronization,…)
 Data transformation overhead

•
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
Testing
Error handling
p. 45
Architectural Pattern: Pipes and Filters
1.
Divide the system’s task into a sequence of processing stages
2.
Define the data format to be passed along each pipe
3.
Decide how to implement each pipe connection
4.
Design and implement the filters
5.
Design the error handling
6.
Set up the processing pipeline
Lexical
Analyzer
Token stream
Syntax
Analyzer
Semantic
Abstract syntax tree
Optimizer
Code
Generator
Intermediate code
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 46
Mobix Transcoder subsystem
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 47
Refine Module 2e: Quality Scenarios
Quality Scenarios also need to be verified and
assigned to child modules. A quality scenario
may be :



Satisfied by the decomposition itself, i.e., no additional
impact on child modules
Satisfied by the decomposition but generating
constraints for the children
The decomposition may be “neutral” to a quality
scenario


The scenario needs to be assigned to one of the children
Not be satisfied by the decomposition


How important is this one?
Real important  redo the decomposition
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 48
Creating a Skeletal System
1.
2.
Develop a skeletal system for the incremental cycle.
Classical software engineering practice  “stubbing
out”
Use the architecture as a guide for the implementation
sequence:

First handle interaction of architectural components



Communication between components
Sometimes this is just installing third-party middleware
Then add functionality



By risk-lowering (attack problematic areas first)
By availability of staff
Following goal of getting “something” (minimally functional system)
delivered as quickly as possible
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 49
Summary: Designing a Software Architecture
Requirements  Architectural Drivers  Architecture
Requirements  Architectural Drivers



Use most important
Less than 10
Iteration possible to get agreement amongst stakeholders
Architectural Drivers  Architecture

Attribute Driven Design (ADD) top down design process


Quality requirements determine the architectural pattern
Functional requirements instantiate modules for that pattern
Influences of Architecture on organizational
structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN
p. 50