Software Architecture: A quick journey Session 6 Course ICT Entrepreneurship Prof. dr. Sjaak Brinkkemper Dr. Slinger Jansen
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
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?
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
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
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
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
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)?
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!
Even Simple Software is Complex Source code level view of an application
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
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.
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
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
Compiler Architecture Sequential Parallel
Compiler Architecture Pros and Cons Sequential + Conceptual Simplicity + Architecture reflects control flow - Performance Parallel + Performance + Adaptability - Synchronization - Coordination Analysis and testing + = Pro, - = Con
Sources of Architecture (1) Architecture comes from black magic, people having architectural visions 3 + 1 main sources of architecture Intuition Method Theft (i.e., reuse) Blind luck Their ratio varies according to: Architect s experience System s novelty
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
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
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
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.
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?
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
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?
Client Server
Service Oriented Services Monoliths Structured Client/Server 3-Tier N-Tier Distributed Objects Components Services Source: IBM
Peer 2 Peer Peer 1 Peer 2
Platform Architecture
iphone Architecture
UML 2.0 13 diagram types
UML
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
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
Pragmatic and Opportunistic Reuse in Two Start-up Companies SJ, SB, IvS, CD IEEE Software
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
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, 2006. Accepted for publication 37
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 198.132.21.23:80 PDFWriter Check for commercial msgs every 3 weeks 198.132.21.23:81 WinAmp Refresh License every two weeks 19.321.22.123:80 Powerpoint Send crash reports whenever they appear 145.12.12.145:80 WinWord Store crash reports in outbox, send when > #10 145.12.12.145:80 MetaEnv Check for new updates twice a day 12.134.145.12: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 05-05-2006 13:28 PDFWriter Download any new updates 198.123.21.23:80 05-05-2006 13:35 PDFWriter Download any new commercial msgs 198.123.21.23:81 05-05-2006 14:00 WinAmp Refresh license 19.321.22.123:80 12-05-2006 14:00 WinAmp Refresh license 19.321.22.123:80 05-05-2006 14:30 Powerpoint Send crash report 145.12.12.145:80 Outbox Pheme Powerpoint Update received 01-05-2006 PPTUpdate01052006.xml MetaEnv Update received 05-05-2006 MetaEnvBuild141.xml WinWord Bug report 12455 WinWordBugReport12455.xml Microsoft Error Server MetaEnv Commercial msg MetaEnvComMSG453.xml All 1.5.1 users WinWord Bug report 12456 WinWordBugReport12456.xml Microsoft Error Server WinWord Bug report 12457 WinWordBugReport12457.xml Microsoft Error Server MetaEnv Commercial msg MetaEnvComMSG452.xml All 1.5.0 users with Emacs editor
Pheme in Action
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
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
Pheme 2.0 concept architecture
Feature Models Especially relevant for those teams building components
Feature Models (2)
Architectures are always Outdated Solution: model driven engineering Round trip engineering
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
Summary To effectively leverage architecture, know your: Requirements Constraints Domain Components Connectors Legacy and off-the-shelf Customers/Users Management Developers
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
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