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

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

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

Evolutionary Delivery Life Cycle Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

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

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

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

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

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

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

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

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

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

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

Mobix System View Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

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

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

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

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

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

Microkernel Pattern Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Top level scenario based on CRC Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

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

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

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

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

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

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

Pipe&Filter Components Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

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

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

Mobix Transcoder subsystem Vakgroep Informatietechnologie – Onderzoeksgroep IBCN

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

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

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