Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Architecture F. Gielen

Similar presentations

Presentation on theme: "Software Architecture F. Gielen"— Presentation transcript:

1 Software Architecture 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

Download ppt "Software Architecture F. Gielen"

Similar presentations

Ads by Google