SA Analysis and Design

Transcription

1 SA Analysis and Design Software Architecture VO ( ) Roman Kern Institute for Interactive Systems and Data Science, TU Graz Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

2 Outline 1 Terminology 2 Development Process 3 Requirements 4 Requirements Analysis: Example 5 Architectural Analysis & Design 6 Architectural Views Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

3 Terminology Most important terms in relation to software architecture Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

4 Questions What is software architecture? What is software? What is architecture? What is a software system? What is a system? Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

5 Definition Latin word systema meaning a whole consisting of several parts or a complex whole A system is a set of elements (components) that are connected to each other to form a whole The components composition is called system structure Mostly, systems perform a certain function or serve a particular purpose E.g. an operating system The structure of a system might be quite complex Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

6 Additional Definitions [A system is] an integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. IEEE [A system is] a set of resources that provide services that are used by an enterprise to carry out a business purpose or mission. System components typically consist of hardware, software, data and workers. Cantor, 2003 Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

7 Components interaction To serve their purpose the system components interact with each other E.g. CPU, memory, I/O devices These complex interactions are called system behaviour Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

8 System boundaries Typically, there are boundaries between the system and its surroundings E.g. computer, humans The environment provide input to the system, and the system answers with output E.g. a search query as input to Google, a list of search result as output The dependencies of outputs on the system inputs are typically complex Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

9 Definition summary Systems serve a purpose Systems have a structure Systems have behaviour Systems take input(s) from their environment and produce output(s) Systems and their properties are very often complex Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

10 Types of systems Natural systems, e.g. biological, astronomical, etc. Man-made systems, e.g. engineering system Hybrid systems, e.g. a mix between man-made and natural phenomena Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

11 Software systems Software is collection of programs, related data, and related documentation. Software is a conceptual entity, whereas hardware is a collection of physical entities (devices). A software system is a system in which all of its components, their connections and interactions are software entities. A software system runs on a specific hardware. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

12 Models of a system Mostly, systems are complex, e.g. huge number of components Sometimes, complex interactions, e.g. the Web To study complex natural systems we create models of systems Model is a simplified view of the system that focuses on a single aspect of a system Typically, multiple (interdependent) views to study multiple aspects Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

13 Models of man-made systems We create models of natural systems to understand them better We create models of engineering systems to be able to build them Planing model, requirements model, structural model, behaviour model, implementation model, etc. More models specific for software: run-time model, software design model, usability model, etc. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

14 Models Definition Models provide a specific description, or content, of an architecture. For example, a structural view might consist of a set of models of the system structure. The elements of such models might include identifiable system components and their interfaces, and interconnections between those components. IEEE Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

15 Model abstraction and granularity level Models can be created at varying levels of abstraction and details E.g., an object-oriented model of a car At the lowest detail level: spark plug, brake disk, etc. At the intermediate detail level: car has engine, wheels, brakes, etc. At the highest detail level: car objects with variables, interacting with other objects OO programming model abstracts assembly, operating system, hardware, Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

16 Model abstraction and granularity level Figure: Car Components, image source: Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

17 Model abstraction and granularity level Figure: Car components at a very fine level of granularity, image source: Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

18 Benefits of Models Advantages of using models Detecting errors and omissions early in the life cycle Examining the relative merits of different options (e.g. debate with colleagues) Understanding the impact of change Assisting with project planning Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

19 Definition A system architecture is an integral collection of related system models at different levels of abstraction and granularity. An initial system architecture is designed before the actual development of the system. This architecture governs the system development. Mostly, the initial system architecture is iteratively updated during the system development. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

20 Definition A software architecture is a collection of models of a software system at various abstraction and detail levels. The models describe: the system as a whole system components component connections how component interact to fulfill the system purpose. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

21 When do we need a software architecture? Only complex systems Complexity can be (sometimes) estimated Large number of users, large amounts of data, large number of interacting components, complex functions, etc. Sometimes you do not know this beforehand, e.g. system for a start-up company Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

22 Examples for complex systems Wikipedia Example: Huge amount of documents E.g. managing tens of millions of documents How to store documents, how to search in documents? How to create, edit documents? User access rights? How to display documents? How to print documents? Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

23 Examples for complex systems Massively multiplayer online role-playing games (MMORPGs) Example: Large number of users Large amount of players interacting with each other (e.g. millions of users) How to distribute the load? How to optimise the latency? How to detect cheaters? Are there banned users? Integrate billing (in game purchases), etc? Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

24 Examples for complex systems Amazon Example: Complex interactions Product recommendation system Which users have similar interests to other users? What should be tracked? Clicks? Purchases? Comments? Are there privacy issues? Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

25 Facebook, Google, Twitter Combine all of the complexities discussed above Large number of users, huge amount of data, complex interactions Complex connections: networks, social networks, etc. Underlying all of these is the Web Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

26 When a software architecture is not needed? Simpler systems E.g., less command line tool in Unix When there are proven designs and we know about them, e.g. a frontend for a database We need the experience in developing this particular kind of a system, i.e. we developed many such systems We need experience to make the distinction Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

27 Analogy with classical architecture Making buildings by G. Booch Building a dog kennel: no architectural design is needed Building a house: you might need an architectural design but if the builders are good it is not necessary Building a skyscraper: you definitely need an architectural design Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

28 Development Process When does software architecture take place? Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

29 Methodology Common method for software architecture Attribute Driven Design (ADD) Quality attributes as starting point Tactics to derive the architecture Siemens 4 Views (S4V) Identify key architectural challenges Iterate using views: conceptual, execution, module, and code Rational Unified Process (RUP) Driven by use-cases, non-functional requirements and risks Iterations, which lead to executable software Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

30 Methodology Different software development processes have software architecture as a part of the process Rational unified process Spiral development method Agile development method Evolutionary rapid development Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

31 Place of SA in SDP - An Example Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

32 Methodology After the initial requirements analysis but before software design The first architecture is also a communication basis with the customer Inputs for the development of the architecture: 1 Requirements 2 Context (technical, organizational, business, ) Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

33 Methodology Initial phase is critical for all following phases Early decisions are cheaper than later ones Keep the architecture conceptually simple e.g. avoid too many features to creep in (gold plating) Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

34 Simplified Workflow Exemplary, simplified step-by-step guide to start the conceptual architecture 1 Identify actors with the systems (e.g. external system, users) 2 Define use-cases 3 Identify functional requirements 4 Identify non functional requirements 5 Prioritise requirements 6 Identify data flow 7 Define data items Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

35 Requirements Types of requirements. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

36 Analysis At the beginning there is always a customer who wants a specific software system Customer wishes are always informal Approaches: Interviews, some documents, some Excel tables, We need to analyse such informal records and structure it Requirements engineering is a huge field but we just illustrate here one possibility Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

37 Analysis The results of the requirements analysis: 1 Functional requirements 2 Non-functional requirements (a) Runtime qualities (b) Non-runtime qualities 3 Contextual requirements Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

38 Functional requirements A technical expression of what a system will do Arise from stakeholder needs Approaches (a) Structured languages: software requirements specification (b) Formal models: e.g. state-charts (c) Use cases: structured description of user interactions with the system (d) User stories, e.g. narratives and personas (e) Mock-ups, e.g. sketches of the UI Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

39 Non-functional requirements Other needs than directly functional or business related Generally expressed in the form of quality attributes (x-abilities) Runtime quality attributes e.g. performance, usability, reliability, security Non-runtime quality attributes e.g. maintainability, evolvability, testability, reusability, integrability, configurability, scalability Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

40 Contextual requirements What technologies are available? Existing internal components Existing off the shelf components, e.g. databases, middleware Expertise of the development team (and availability of resources) Organisation of teams, e.g. geographically dispersed Previous experience of users/customers Technical, business, market, legal, ethical, Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

41 Requirements Definitions Definition Functional Requirements Functional requirements describe the behaviour (functions or services) of the IT system that supports the users goals, tasks or activities Malan, 2001 Definition Non-Functional Requirements Non-functional requirements include constrains and qualities. Malan, 2001 Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

42 Requirements Definitions Definition Constraints A constraint is a restriction on the degree of freedom we have in providing a solution Leffingwell, 2000 Definition Quality [System] qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system Malan, 2001 Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

43 Approach: Narratives A narrative is a concrete description of a user s interaction with the system Build up a collection of short narratives Together they paint a picture of the system Serve as distillation of the expectations of end-users Iterative process involving both, end-users and analysis/architects System narrative: informal narrative, which describes the system itself Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

44 Approach: Personas A persona is a fictional character with certain characteristics Each persona has its own goals and expectations Description of the persona, e.g. age, job, background Interaction of the persona with a system need practice to come up with the right personas Example: one persona representing a manager, one persona representing an engineer Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

45 Requirements Analysis: Example WNAP Simple example on how to tackle requirements. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

46 Example Application - System description I Web-based Navigation Application: WNAP A simple and highly usable system for navigation is needed. It has to allow to navigate to the nearest store (e.g. Billa, Spar, Bipa), the next gas station or the best hotel, using the optimal route. Where there are multiple ways how the quality of the route can be defined: shortest, quickest, most economical, cheapest, pleasant (e.g. quietest). In the future there should be more options on what an optimal route looks like. The application has to consider which means of transportation the person should use (e.g. car, bike, foot), taking into account the current weather conditions. If a public transport is selected it should indicate, which tram or bus line to take. The application should allow in place purchase of tickets. The route should be shown on a map to demonstrate how it looks like. The estimated travel time should be displayed. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

47 Example Application - System description II Web-based Navigation Application: WNAP If there are multiple about equally good routes, the user can choose which one she wants to take. The system is a Web-based system and the users should be able to operate the system by using a standard Web browser. The users need not install any additional plug-ins to operate the system. In particular, browser back button must be working at all times and it should be possible to bookmark places at all times. Each page and each important application state needs to have a unique and human-readable URL. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

48 Example Application - System description III Web-based Navigation Application: WNAP The application should be intuitive to use and aesthetically pleasing, the user should not wait longer than a few seconds for each request. The colour scheme of the design can be selected by every user individually. The language of the system can be freely chosen. When the user enters a new trip, a list of popular places should help the user to quickly create routes. It is expected that the application will be used by about 1,000,000 users and about 1,000 users will concurrently search for routes. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

49 Example Application - Tasks Tasks of the software architect Identify and document use cases Create aids for communication Narratives Personas Mock-ups Iterate with customer (and other stakeholders) Extract requirements Weight requirements (an importance) Design of architecture and system core development cycle begins In the following slides, a number of (not exhaustive) examples use cases, personas, mock-ups and requirements are given. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

50 Example Application - Use Cases Example Use Case 1 Name Search route Aim User is searching the optimal route from A to B Actors User, System Precondition Logged on user Trigger Users trigger a new search Includes 1 User starts a new search 2 System shows options to choose from (e.g. mode of transportation) 3 User specifies the preferred choice Extensions 1 User starts an expert search and specifies criteria 2 User orders tickets for public transport Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

51 Example Application - Use Cases Example Use Case 2 Name Buy ticket Aim User buys tickets for all the public transport on the route Actors User, System, External Service Precondition Logged on user, selected route Trigger Users confirms a route Includes 1 System connects to service of public transport (using the user credentials) 2 Public transport service issues a order 3 User confirms order 4 System delegates the confirmation and displays the ticket numbers Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

52 Example Application - Use Cases Example Use Case 3 Name Assemble popular places Aim Collect a list of places, ranked by their popularity Actors Sysadmin, System Includes 1 Sysadmin collects the log files and analyses them 2 Creates a ranked list of popular places 3 Sysadmin uploads the new lists and triggers the system to use the new list Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

53 Example Application - Persona Example Persona Marina, 17 years old, pupil She regularly needs to navigate from her school to a public library to rent books for her home work. When it is raining she cannot take her bike and the system should route her via the public transport network (e.g. bus). The system should be aware of that she has a seasonal ticket. For all her navigation she uses her mobile phone, which is equipped with the latest version of the Firefox web browser. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

54 Example Application - Mockup Web Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

55 Example Application - Mockup Mobile Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

56 Example Application - Functional requirements UR1: The system is a navigation tool. The system can calculate the following optimal routes. UR1.1: Shortest path UR1.2: Fastest route UR1.3: Most economical (lowest CO2 emissions) UR1.4: Cheapest UR1.5: Pleasant UR1.5.1: Quietest UR1.5.2: Most sightseeing spots UR1.5.3: Along rivers and through parks Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

57 Example Application - Functional requirements UR2: The places are stored in a database UR3: The connections between the places are stored in the database UR4: The connections need to contain the transportation mode and provider UR5: The administrator can add/remove new places and connections UR6: The user can search for places Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

58 Example Application - Functional requirements UR7: The system needs to interact with external services UR7.1: The system needs to buy tickets for the tramway UR8: The system needs to draw the route on a interactive map UR9: The system needs to provide user management UR9.1: Register new users UR9.2: Log-in / Log-out UR9.3: Store user preferences UR9.4: Store credentials for purchase Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

59 Example Application - Non-functional requirements UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported. Security UR4: User-perceived performance must be acceptable Performance and Usability How many seconds at max users can wait? UR5: Web-based system should be available at all times. Reliability Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

60 Example Application - Non-functional requirements UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability UR7: Extending the system with new optimal routes algorithms. Evolvability, reusability, maintainability, testability, integrability, configurability UR8: Reliability of a Web-based system. Testability UR9: Multiple users. Scalability Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

61 Example Application - Contextual requirements UR1: Web browser. UR2: Valid (X)HTML, at least (X)HTML Transitional. UR3: No browser plugins are allowed. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

62 Practical Guidelines Often a client (or other stakeholder) requests certain functionality/qualities/etc. Request requirement Shopping cart mentality by clients Typically a client wants all possible functionality Business oriented vs. technical Clients will often not understand requirements demonstrate the benefit (or the consequences) Often requests are too general (to be transformed into requirements) Requests should be measurable Clear to state whether the request has been fulfilled (or not) E.g. the system will have a state-of-the-art user interface Often requests are issued by the wrong people E.g. usability should be judged by the real target group (end users) Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

63 Architectural Analysis & Design Analyse structure and behaviour. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

64 Analysis We analyse the requirements and try to identify so-called key concepts Understanding of the domain Static part of the domain We also try to identify key process and activities Dynamic part of the domain Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

65 Design Design is the process of creating models (recollect the definition of SA) Two basic types of architectural models Structure and behaviour Architectural structure is a static model of a system (i.e. how the system is divided into components) Architectural behaviour is a dynamic model of a system (i.e. how the components interact with each other to perform some useful work) Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

66 Design Diagrams as the main tool for design Learn while doing (draft sketches) Create a shared understanding (e.g. in the organisation) They support collaboration They help explain the architecture Serve as (permanent) documentation of the architecture Deepen the understanding of the architecture There is not a standard for software architecture (UML might be to structured) Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

67 Architectural structure The first part is the architectural structure The division of a system into components (e.g. modules) and connectors To represent the model: box-and-lines diagrams (to see at a glance important concepts) It is important to remember that diagrams are only representations of the model Diagrams must always be accompanied by additional material such as text, data models, mathematical models, etc. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

68 Architectural structure What is a component? What is a connector? Components might be subsystems, separate processes, source code packages, Connectors might be network protocols, method invocations, associations, No clear language for diagrams The combination of diagrams and additional material is an architectural model Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

69 Architectural structure Figure: Example of an architectural structure Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

70 Architectural structure In the diagram we have one user-interface and one database component But what is the criteria for deciding what is a component? Separate program modules? Separate threads or processes? Conceptual or functional division? And what about connectors? Network protocols? Callbacks? Request/response cycles? Method invocations? Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

71 Architectural structure What is the level of granularity of a diagram? E.g. for a Web-based system, components are servers and browsers and connector is HTTP But, components of a server are HTTP parser, file I/O, cache, plug-ins, Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

72 Architectural structure Comparison with OO: a component is an object and a connector is a message sent between two objects Because models in OO are very well defined Therefore, we need additional information that accompanies diagrams To describe criteria for decomposition and provide explanations on granularity Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

73 Architectural behaviour Complementing structure is architectural behaviour Interaction of system elements to perform some useful work Functionality vs. behaviour Functionality is what the system can do and behaviour is the activity sequence Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

74 Architectural behaviour Each component has a set of responsibilities Behaviour is the way how these responsibilities are exercised to respond to some event An event may be an action of the user, an event from an external system, or an internal trigger A particular behaviour is an event plus a response in the form of a sequence of component responsibilities Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

75 Architectural behaviour To represent behavioural models we use use-case maps [Buhr 98] It is a graphical notation A use-case map consists of a trace drawn through a structural diagram of the system The path of the trace through a structural diagram shows the sequence of activities The sequence is initiated by an event Each crossing of a component by the trace indicates exercising of a responsibility Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

76 Architectural behaviour Figure: Types of traces in use-case maps Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

77 Architectural behaviour (a) (b) (c) Single trace - all responsibilities exercised sequentially Two traces are consecutive: Equivalent to single trace but shows that continuation is triggered by another event And-Fork: The traces after the line are potentially concurrent (run in parallel) Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

78 Architectural behaviour Figure: Types of traces in use-case maps Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

79 Architectural behaviour (a) (b) (c) N-Way And-Fork: the trace after the fork may be replicated an arbitrary number of times Or-Fork: The trace is split and activity proceeds along one or another path Seq-Fork: The traces after the line are followed in the order indicated by the arrow Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

80 Architectural behaviour Example: Display a selected route Request is sent to the Web presentation layer That layer forwards the request to the application logic, e.g. WNAP business logic WNAP business logic contacts WNAP map renderer to draw the route, then retrieves the data from the database wraps it into an HTML response and sends the response to the Web UI Functionality allows me to display a map with a route Behaviour is the sequence of activities that makes it happen Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

81 Architectural behaviour Figure: Example of architectural behaviour for the use case: display route Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

82 Architectural Views Multiple views on the architecture. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

83 Architectural views We can examine a system from different points of view Different kinds of views Conceptual: components are set of responsibilities and connectors are flow of information Execution: components are execution units (processes) and connectors are messages between processes Implementation: components are libraries, source code, files, etc and connectors are protocols, api calls, etc. Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

84 Architectural views There are other models as well We will mention them but we will investigate only the previous three models Data/information model describes the data Physical model describes servers, firewalls, workstations, Deployment model describes the packaging of components Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

85 Architectural views Each view provides different information about the structure of the system Each view addresses a specific set of concerns All views taken together is the primary means of documenting software architecture Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

86 Architectural views The conceptual architecture considers the structure of the system in terms of its domain-level functionality The execution architecture considers the system in terms of its runtime structure The implementation architecture considers the system in terms of its build-time structure Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87

87 The End Next: Conceptual Architecture Roman Kern (ISDS, TU Graz) SA Analysis and Design / 87