Software Architecture: A quick journey

Transcription

1 Software Architecture: A quick journey Session 6 Course ICT Entrepreneurship Prof. dr. Sjaak Brinkkemper Dr. Slinger Jansen

2 Motivation Software systems are rapidly and continously growing in size and complexity Techniques and tools for developing and maintaining such systems typically play catch-up To deal with this problem, many approaches exploit abstraction Ignore all but the details of the system most relevant to a task (e.g., developing the user interface or system-level testing This greatly simplifies the model of the system Apply techniques and tools on the simplified model Incrementally reintroduce information to complete the picture Software architecture is such an approach Applicable to the task of software design

3 What is Architecture? A high-level model of a thing Describes critical aspects of the thing Understandable to many stakeholders architects, engineers, workers, managers, customers Allows evaluation of the thing s properties before it is built Provides well understood tools and techniques for constructing the thing from its blueprint Which aspects of a software system are architecturally relevant? How should they be represented most effectively to enable stakeholders to understand, reason, and communicate about a system before it is built? What tools and techniques are useful for implementing an architecture in a manner that preserves its properties?

4 What is Software Architecture? A software system s blueprint Its components Their interactions Their interconnections Informal descriptions Boxes and lines Informal prose A shared, semantically rich vocabulary Remote procedure calls (RPCs) Client-Server Pipe and Filer Layered Distributed Object-Oriented Service Oriented

5 From Requirements to Architecture From problem definition to requirements specification Determine exactly what the customer and user want Specifies what the software product is to do From requirements specification to architecture Decompose software into modules with interfaces Specify high-level behavior, interactions, and non-functional properties Consider key tradeoffs Schedule vs. Budget Cost vs. Robustness Fault Tolerance vs. Size Security vs. Speed Maintain a record of design decisions and traceability Specifies how the software product is to do its tasks

6 Focus of Software Architectures Two primary foci System Structure Correspondence between requirements and implementation A framework for understanding system-level concerns Global rates of flow Communication patterns Execution Control Structure Scalability Paths of System Evolution Capacity Throughput Consistency Component Compatibility

7 Why Software Architecture? A key to reducing development costs Component-based development philosophy Explicit system structure A natural evolution of design abstractions Structure and interaction details overshadow the choice of algorithms and data structures in large/complex systems Benefits of explicit architectures A framework for satisfying requirements Technical basis for design Managerial basis for cost estimation & process management Effective basis for reuse Basis for consistency, dependency, and tradeoff analysis Avoidance of architectural erosion

8 Why software architecture in ICT Entrepreneurship? Show technical feasibility and expertise Build evolvable systems Communicate with stakeholders Use in your architecture deliverable (deadline 15th of January, about 50% of the doc)?

9 Exercise: Who are your stakeholders? Define a list of stakeholders who will benefit from a clear architecture Define a list of different views required for each stakeholder Tell us about it!

10 Even Simple Software is Complex Source code level view of an application

11 Definitions of Software Architecture Perry and Wolf Software Architecture = {Elements, Form, Rationale} Shaw and Garlan Software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on those patterns Kruchten Architecture deals with abstraction, decomposition, composition, style and aesthetics. Canonical Building Blocks What How Why Components, Connectors, Configurations

12 Components A component is a unit of computation or a data store. Components are loci of computation and state. Clients Servers Databases Filters Layers Abstract Data Types (ADTs) A component may be simple or composite. Composite components describe a system.

13 Connectors A connector is an architectural element that models: Interactions among components Rules that govern those interactions Simple interactions Procedure calls Shared variable access Complex and semantically rich interactions Client-Server Protocols Database Access Protocols Asynchronous Event Multicast Piped Data Streams

14 Scope of Software Architectures Every system has an architecture Details of the architecture are a reflection of system requirements and tradeoffs made to satisfy them Possible decision factors Performance Compatibility with legacy software Planning for reuse Distribution profile Current and Future Safety, Security, Fault tolerance requirements Evolvability Needs Changes to processing algorithms Changes to data representation Modifications to the structure/functionality

15 Compiler Architecture Sequential Parallel

16 Compiler Architecture Pros and Cons Sequential + Conceptual Simplicity + Architecture reflects control flow - Performance Parallel + Performance + Adaptability - Synchronization - Coordination Analysis and testing + = Pro, - = Con

17 Sources of Architecture (1) Architecture comes from black magic, people having architectural visions main sources of architecture Intuition Method Theft (i.e., reuse) Blind luck Their ratio varies according to: Architect s experience System s novelty

18 Sources of Architecture (2) Theft From previous similar systems From literature Method Systematic and conscious Possibly documented Architecture is derived from requirements via transformations and heuristics Intuition The ability to conceive without conscious reasoning. Increased reliance on intuition increases the risk

19 Routine Design Method is critical An architecture built with 50% theft and 50% intuition is doomed to fail. Standardized methods Similarity to previous solutions Theft Cheaper, but not optimal Can be done by merely good designers Use architectural patterns Potential pitfall Over-reusing

20 Innovative Design Raw invention Intuition Derivation from abstract principles More optimal More expensive Must be done by great designers Potential pitfall Reinventing the wheel Single point of failure in staffing

21 Software Architecting The architecting problem lies in: Decomposition of a system into constituent elements Composition of (existing) elements into a system Two idealized approaches Top-Down Decompose the large problem into sub-problems Implement or reuse components that solve the sub-problems Bottom-Up Implement new or reuse existing stand-alone components Compose (a subset of) the components into a system A realistic approach will require both.

22 Issues in Decomposition (1) How do we arrive at: Components? Connectors? Their Configuration? What is the adequate component granularity level? What constraints on components are imposed by: Functional requirements Non-functional requirements Envisioned evolution patterns System Scale Computing Environment Customers/Users What assumptions can components make about one another?

23 Issues in Decomposition (2) How do components interact? What are the connectors in the system? What is the role of the connectors? Mediation Coordination Communication What is the nature of the connectors? Type of interaction Degree of concurrency Degree of information exchange

24 Issues in Composition Where does one locate existing: Components? Connectors? Configurations? How do we determine which elements are needed? Both at development time and at reuse time What is the adequate element granularity level? How do we ensure effective composition of heterogeneous elements? How do we know that we have the needed system?

25 Client Server

26 Service Oriented Services Monoliths Structured Client/Server 3-Tier N-Tier Distributed Objects Components Services Source: IBM

27 Peer 2 Peer Peer 1 Peer 2

28 Platform Architecture

29 iphone Architecture

30 UML diagram types

31 UML

32 Non Standard - Block Diagrams Rich UI Web UI Controls Signing Authentication Authorization Service Interface Activity Business Rules Human Workflow Workflow Service Agents DAL Monitoring Log & Trace Exception Management Configuration E-Publish EAI ECM DW OLTP

33 Reusing Other Components You will reuse other components If future of component isn t secure: Wrap it! Build a standard interface for it Buy it Reuse carefully: integration code is on average 3 times harder to write than normal code For example: Tafeltjesavond.nl

34

35 Pragmatic and Opportunistic Reuse in Two Start-up Companies SJ, SB, IvS, CD IEEE Software

36 An Example Software Product Pheme: a product for software knowledge distribution What does it do? Software knowledge distribution from developer to customer Including: system management, tweaking, control Target groups: Software Developing Organizations

37 Pheme serves well in a Software Supply Network Software Developer Cust. 1. Cust. m Software Developer Cust 1. Cust n Operational Environment 1. Operational Environment n. Operational Environment m Slinger Jansen and Wilfried Rijsemus: Balancing Total Cost of Ownership and Cost of Maintenance Within a Software Supply Network, proceedings of the IEEE International Conference on Software Maintenance (ICSM2006, Industrial track), Philadelphia, PA, USA, September, Accepted for publication 37

38 PDFWriter PDFWriter WinAmp Powerpoint MetaEnv Automatically install any incoming updates Store commercial msgs in PDFWriter database automatically Automatically renew license Request user permission for updates (new updates are ready to install) Automatically update if not running PDFWriter Check for new updates every 4 weeks :80 PDFWriter Check for commercial msgs every 3 weeks :81 WinAmp Refresh License every two weeks :80 Powerpoint Send crash reports whenever they appear :80 WinWord Store crash reports in outbox, send when > # :80 MetaEnv Check for new updates twice a day :80 Policies Deployment Policies Push/Pull policies iprovide Pheme 0.1 Architecture MetaEnv151.tar WinWord.zip Licenses to Metaenv To all To vdstorm To all irequire Any new MetaEnvUpdates Any new PDFWriter updates Communication Center Push/Pull Stack Inbox :28 PDFWriter Download any new updates : :35 PDFWriter Download any new commercial msgs : :00 WinAmp Refresh license : :00 WinAmp Refresh license : :30 Powerpoint Send crash report :80 Outbox Pheme Powerpoint Update received PPTUpdate xml MetaEnv Update received MetaEnvBuild141.xml WinWord Bug report WinWordBugReport12455.xml Microsoft Error Server MetaEnv Commercial msg MetaEnvComMSG453.xml All users WinWord Bug report WinWordBugReport12456.xml Microsoft Error Server WinWord Bug report WinWordBugReport12457.xml Microsoft Error Server MetaEnv Commercial msg MetaEnvComMSG452.xml All users with Emacs editor

39 Pheme in Action

40 Current Data model Service 1:n Remote Packages 1:1 1:n 1:1 Channel 1:n downloads Action Action Sequence 1:1 1:n 1:1 1:1 1:1 Policy 1:1 1:1 Vendor Side Customer Side Event executes generates affects Local Packages Pheme Todo Item 40

41 Pheme 1.0 Architecture Web Interface Windows Interface Linux Interface Pheme2Pheme Interface U R M Pheme Server Activity Centre Service Management Package Management Services Packages Policy Management Policies Action Management Actions Users Execution Center User System

42 Pheme 2.0 concept architecture

43 Feature Models Especially relevant for those teams building components

44 Feature Models (2)

45 Architectures are always Outdated Solution: model driven engineering Round trip engineering

46 Why Software Architecture? Software architecture has proven to be a key to: Controlling system development costs Ensuring critical system properties Highlighting major tradeoffs in development Enabling effective deployment, operation, and evolution

47 Summary To effectively leverage architecture, know your: Requirements Constraints Domain Components Connectors Legacy and off-the-shelf Customers/Users Management Developers

48 Checklist for your architecture Sufficient level of detail Sufficient overview Look out for common mistakes Wrapping the wrapper Security flaws Know your users Model your system in its context Feel free to use tools such as Visual Paradigm ArgoUML Etc. Have you considered round-trip software architectures? Architectural patterns Most important: Rationale

49 Note Today we will send out your product definitions at 16:15 to the BoGs. Please send your final version to us before 14:30