1. Software Architecture Prof.Dr.ir. F. Gielen
Attribute Driven Design
Vakgroep Informatietechnologie – IBCN

2. 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

3. Previously we have examined:
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

4. 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

5. Evolutionary Delivery Life Cycle
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

6. 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

7. 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

8. 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

9. 1. Choose the module to decompose
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

10. 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

11. 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

12. 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

13. Approach
Create content and mobile applications based on existing webcontent
Mobile Web
It is not the web on a mobile device
… but is an extension of the web to mobile applications
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
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

14. Mobix Idea Description
Existing
Websites
Text
Video
Audio
Interaction
Extract
Structure
Figures
Pictures
Add
Location Info
Context Info
Personalization
Mobile Application Widgets
Mobile
Applications
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

15. 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

16. Mobix System View
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

17. 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

18. 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

19. 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

20. 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

21. 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

22. Microkernel Pattern
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

23. Based on the need to move away from the monolithic Unix kernel.
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

24. Performance trade-off:
Microkernel module
Main component
Core functionality
Central Services
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

25. Internal Servers or Subsystems
Extends the kernel
Additional functions
Encapsulation
HW dependencies
Invocation via service requests
Communciation protocol design !
Only accessed via the microkernel
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

26. 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

27. 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

28. 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

29. Architectural Pattern: Mircokernel
Analyze the application domain and identify the core functionality necessary for implementing the external services
Analyze the external services to find the policies that they have to provide to clients
Categorize the services into semantically independent categories (candidates for internal servers)
Partition the categories between the microkernel & the servers
Determine the communication strategies
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

30. Step 2c.: Mobix Subsystem structure
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

31. 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

32. 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

33. Module Identification and Function Allocation
CRC-cards
= Class - Responsibility - Collaboration card
= Container for responsibilities
Class name :
Class type :
<system> <subsystem> <module> …
Class characteristic :
Responsibilities :
Collaborations :
The next step in class modeling consists of identifying the basic functionality of each class. An often used technique is the use of CRC-cards (standing for “Class-Responsibility-Collaboration”-cards).
For each candidate class, a CRC-card is made, featuring :
the class name (as identified during noun extraction)
the class type (e.g. external entity, role, event, …) [optional]
the class characteristic (e.g. persistent, tangible, …) [optional]
responsibilities : which functionality does the class perform ? (list attributes and methods)
collaborations : which other classes are needed to realize this functionality ?
Describe the functionality
of the module
List other modules needed
to achieve this functionality
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

34. 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
Once CRC-cards have been drawn up for each candidate class, collaborations can be shown in a diagram (often, CRC-cards are put on a whiteboard, and are grouped according to the level of collaboration).
A technique to check whether all classes, responsibilities and collaborations are identified, consists of assigning each member of the group a set of CRC-cards, and to “play” the scenarios. Each time an operation is needed, the team member holding the CRC-card of the class involved, checks whether the functionality is listed, which other classes are needed (and which functionality of these collaborating classes is required). If functionality, attributes or an entire class is missing, the CRC-model is updated, and the role play starts all over again ...
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

35. Device Context Manager <module>
Case : Mobix
Class name :
Device Context Manager <module>
Responsibilities :
Collaborations :
Case III : Courses
A sample CRC-card for the Course class (only first iteration result).
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

36. Case :Mobix Services system
Class name :
Transcoder <module>
Responsibilities :
Collaborations :
Case III : Courses
A sample CRC-card for the Student class (only first iteration result).
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

37. Top level scenario based on CRC
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

38. Represent the Architecture with 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

39. 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

40. Refine Module 2d: Defining interfaces
The three views provide:
Module view
Producers/consumers relations; patterns of communication
Concurrency view
Interactions among threads
Synchronization information
Deployment view
Hardware requirements
Timing requirements
Communication requirements
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

41. 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

42. 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

43. Architectural Pattern: Pipes and Filters
Context
Problems
Solution
Processing data streams
Motion of data through the system
Future system enhancements should be possible
Small processing steps
Non-adjacent processing steps do not share information
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
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
Advantages:
First, they allow the designer to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters.
Second, they support reuse: any two filters can be hooked together, provided they agree on the data that is being transmitted between them.
Third, systems can be easily maintained and enhanced: new filters can be added to existing systems and old filters can be replaced by improved ones.
Fourth, they permit certain kinds of specialized analysis, such as throughput and deadlock analysis.
Finally, they naturally support concurrent execution. Each filter can be implemented as a separate task and potentially executed in parallel with other filters.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

44. Pipe&Filter Components
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

45. 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 -
Sharing state information is expensive or inflexible
Efficiency gain by parallel processing is often an illusion (e.g. cost for transferring data, context-switching is expensive,, synchronization,…)
Data transformation overhead
Testing
Error handling
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

46. Architectural Pattern: Pipes and Filters
Divide the system’s task into a sequence of processing stages
Define the data format to be passed along each pipe
Decide how to implement each pipe connection
Design and implement the filters
Design the error handling
Set up the processing pipeline
Lexical
Analyzer
Syntax
Analyzer
Code
Generator
Semantic
Optimizer
Token stream
Abstract syntax tree
Intermediate code
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

47. Mobix Transcoder subsystem
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

48. 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

49. Creating a Skeletal System
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

50. 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