Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Attribute Driven Design."— Presentation transcript:

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

2 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

3 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3 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

4 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4 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?

5 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5 Evolutionary Delivery Life Cycle

6 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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.

7 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

8 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

9 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9 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

10 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

11 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

12 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

13 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

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

15 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p 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

16 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16 Mobix System View

17 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

18 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

19 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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 ?

20 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

21 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21 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.

22 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22 Microkernel Pattern

23 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

24 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24 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

25 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

26 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

27 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

28 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

29 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p 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 Architectural Pattern: Mircokernel

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

31 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

32 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

33 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33 Module Identification and Function Allocation CRC-cards = Class - Responsibility - Collaboration card = Container for responsibilities Responsibilities :Collaborations : Class name : Class characteristic : Class type : Describe the functionality of the module List other modules needed to achieve this functionality …

34 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

35 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 35 Case : Mobix Responsibilities :Collaborations : Class name : Device Context Manager

36 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 36 Case :Mobix Services system Responsibilities :Collaborations : Class name : Transcoder

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

38 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 38 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

39 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

40 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

41 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

42 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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

43 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 43 Architectural Pattern: Pipes and Filters ContextProblemsSolution 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

44 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 44 Pipe&Filter Components

45 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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 -  Performance 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

46 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p 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 Architectural Pattern: Pipes and Filters Syntax Analyzer Lexical Analyzer SemanticOptimizer Code Generator Token streamAbstract syntax treeIntermediate code

47 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 47 Mobix Transcoder subsystem

48 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 48 Refine Module 2e: Quality Scenarios Quality Scenarios also need to be verified and assignedto 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

49 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 49 Creating a Skeletal System 1. Develop a skeletal system for the incremental cycle. 2. 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

50 Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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


Download ppt "Vakgroep Informatietechnologie – IBCN Software Architecture Prof.Dr.ir. F. Gielen Attribute Driven Design."

Similar presentations


Ads by Google