T Software Architecture

Transkriptio

1 T Software Architecture Introduction Tomi Männistö

2 Overview Motivation for software architectures Dealing with increasing complexity What is software architecture? Providing overall structure big picture Making and communicating crucial design decisions Ensuring quality requirements will be met by the system Main architectural activities Architecture design process in very general Software product families Becoming more and more common Emphasis importance of software architectures Conclusions 2

3 Motivation

4 Building a doghouse build and fix? OR 4

5 SoberIT Bricks & mortar fi cathedral?? 5

6 Rough layers of SW design Architectural design SA design decisions, Stakeholder concerns Overall system qualities Architectural programming J2EE,.NET Programming Java, C#, C++, Fortran 6

7 Dealing with complexity Software development has been, is, and will likely remain fundamentally hard Entire history of software engineering is one of rising levels of abstraction At the highest level of abstraction, every system has an architecture [ 7

8 Sample sources of complexity in software development Size Size in terms of LOC, distribution, amount of data, Critical qualities Performance (competitive advantage, hard constraints), security, physical resources (memory, bandwidth, battery life, weight), Tough domain requirements Medical, military, banking, aviation, space, 8

9 General definition for software architecture Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Every system has an architecture, whether known or not. However, it may lack an architectural description [IEEE Standard ] 9

10 10

11 Roles of software architecture Provide overall structure Big picture Abstraction, high level architecture Document early design decisions and their rationale Enable communication Between stakeholders about architecturally significant decisions and trade-offs From architecture design to implementation Support for reuse within company Software product family architectures 11

12 Architecturally significant (design) decisions (ASD) Difficult to fix or change if turn out to be wrong Changing ASD is not a simple matter of programming Cross-cutting Affect many or all components Cannot be fixed in one component Preclude or enable qualities of the system 12

13 Imaginary example: Distribution of functionality between client and server Application that involves demanding pre-processing of collected data before storing it for later analyses Server and clients Server stores data permanently for later analyses Clients collect data, may cost max 100 apiece Server and client having different programming environment Overall performance and scalability (in terms of adding clients) would be better if clients were able to handle the calculations Can clients do the pre-processing? Answer may be No way / Yes / Well hard to tell Changing decision later may practically be close to impossible In the third case, we may need to call a time-out and do some prototyping to get more information 13

14 Architecture design

15 From Problem Domain to Solution Domain Problem domain Solution domain Needs Requirements Business value Features SA System Context 15

16 Software architectures are Artefact about early design decisions Making, reasoning, communicating Abstraction of details, architecturally significant Concerning e.g. Overall structure and behaviour Constraints Concepts 16

17 Mommy, where do software architectures come from? (adapted from Kruchten 1995 and later discussions) User needs Business case Regs Architecture Innovations Existing systems Existing stuff 17

18 Mommy, (Kruchten 1995) 18 [Kruchten 1995]

19 Mommy other input stuff Existing general knowledge Styles Tactics Checklists Existing general or company-specific knowledge Viewpoint library Principles Constraints Business, technical, time, legacy sw and environment 19

20 Stakeholders Stakeholders are people for whom the system is being built Sample stakeholders Customer, user Architect, designer, usability engineer, tester, installer General management, product manager, project manager Marketing, sales, Maintenance, customer support 20

21 Sample views and purposes p1 p2 p3 p4 c11 c1 c12 c2 c3 process view How fast system reacts to exception e9? How many parallel request it can handle? SW system release view When will functionality f1 be available? Who will fix bug326? 21 module view Where is functionality f1 implemented? How to abstract variety in X? [Adapted from Ran 1996 ISAW-2

22 Complexity of making SW Organisation Market Customers Users System / product Processes 22 Architecture # Read metadata from stdin... if ($ARGV[0] eq "-s") { while ($input = <STDIN>) { $metadata.= $input; } } # Find the script directory if ($0 =~ m ^(.*)/[^/]+$ ) { $scriptdir = $1; } else { $scriptdir = "."; } Implementation

23 Architecturally significant (design) decisions (ASD) Difficult to fix or change if turn out to be wrong Changing ASD is not a simple matter of programming Cross-cutting Affect many or all components Cannot be fixed in one component Preclude or enable qualities of the system Externally visible behaviour What system does vs. Quality properties How system does it 23

24 Software quality attributes Safety Security Reliability Usability Learnability Robustness Scalability Performance Portability Reusability Efficiency Extendibility Testability Modularity Modifiability Complexity 24

25 Quality Triangle Expensive, high quality, longer time to market High Quality More expensive, moderate quality, moderate time to market Low Cost Inexpensive, lower quality, longer time to market Short Time to Market [Rozanski, Woods 2005] 25

26 It is the responsibility of the architect to decide what is architecturally significant 26

27 Utility SoberIT Sample utility tree Performance Modifiability Availability Data latency Transaction throughput Change COTS New product categories H/W failure COTS SW failure Importance to the success of the system (M,L) Minimise storage latency on customer DB to 200 ms (H,M) Deliver video in real time (L,H) add CORBA middleware in < 20 person-months (H,L) Change web UI in < 4 person-weeks Risk in achieving (L,H) Power outage at Site 1, re-direct traffic to Site 2 in <3 s (M,M) Restart after disk failure in < 5 min (H,M) Network failure is detected and recovered in < 1,5 min Security Data integrity Data confidentiality 27 (L,H) Credit card transactions are secure 99,999% of time (L,H) Customer DB authorisation works 99,999% of time [Kazman et al. 2000]

28 Architectural activities

29 Architectural activities and issues Business issues Design and analysis Representation / documentation Assessment / evaluation Realisation Recovery and reconstruction People and organisations 29

30 General architecture design process Create business case for the system / product / family Domain analysis Scoping Understand the requirements Architectural drivers, concerns Functional, scenarios, quality attributes Design the architecture Main decomposition; views; iterate Represent and communicate the architecture Assess (analyse and evaluate) the architecture Architecture trade-off analysis, quality attribute prediction Iterate Architecture transformations Implement the system Ensure the implementation conforms to the architecture 30

31 Ways to start with architecture design Functionality-based architectural design First system functions then iterate for qualities Scenario-based software architecture design Prioritised set of scenarios, architecture draft, iterate Problem domain modelling Analyse problem domain and construct domain model Particular constraint or quality attribute as strong architectural driver E.g., memory consumption or (hard to achieve) availability 31

32 Architecture assessment Assess the consequences of architecture decisions in light of quality attribute requirements to see how good the (proposed) architecture is and evaluate possible choices 32

33 Architecture assessment Assess the consequences of architecture decisions in light of quality attribute requirements Quality attribute prediction (e.g., modifiability, performance, security, ) to see how good the (proposed) architecture is and evaluate possible choices 33

34 Architecture trade-off analysis (ATAM) Architectures are complex and involve many design tradeoffs Architecture is key to achieving or failing to achieve goals of a system Without formal analysis process, organisation cannot ensure that architectural decisions are good The purpose of the ATAM is to assess the consequences of architecture decisions in light of quality attribute requirements ATAM is a method for detecting potential risks of a complex software intensive system [Kazman et al. 2000] 34

35 Scenario: S12 (detect and recover from HW failure of main switch) Attribute: Availability Environment: normal operations Stimulus: CPU failure Response: 0,99999 availability switch Architectural decisions Risk Sensitivity Tradeoff Backup CPU(s) R8 S2 Reasoning: - ensures no common mode failure by using different hw and OS - worst-case rollover is accomplished as computing state takes - guaranteed to detect failure within 2s based on rates of heartbeat and watchdog - watchdog is simple and proven reliable Architecture diagram: Primary CPU (OS1) Backup CPU w/watchdog (OS2) heartbeat (1s) 35 Switch CPU (OS1) [Kazman et al. 2000]

36 Software product family fundamentals

37 Software product family / line definitions Set of similar software-intensive systems sharing a common, managed set of features that satisfy the specific market needs and that are developed from a common set of core assets in a prescribed way [Clements & Northrop 2001] A software product family consists of an architecture and assets that are used for producing individuals of the family 37

38 Product family engineering Idea: Pre-design the family (architecture, platform, assets) Support reuse Allow routine or automatic creation of variants (individuals, deliveries, customer products) Similar approach is well known in configuration of traditional (mechanical and electronic) products 38

39 Software product family Product family architecture Shared assets PF development Product individuals deployment 39

40 Product family architecture Software architecture By definition supports variation High level of abstraction multiple implementations Product family architecture Explicitly allowed variations Identifying the allowed variation is part of product family architectures responsibility Different variability implementation mechanism exits Build-time parameters, selection of components or subsystems, specialisation, plug-in components, interfaces, middleware,... 40

41 Conclusions

42 What are SAs all about? Ensuring that main requirements, qualities in particular, will be achieved before the system is built Making development of complex software systems routine Representing and documenting the architecture Communication between stakeholders =sharing knowledge =making right decisions (trade-offs) early enough Management Complexity Variability = Product families Evolution 42