SA Analysis and Design - TU Graz

SA Analysis and Design

So�ware Architecture VO (706.706)

Roman Kern

Version 2.1.1

Institute for Interactive Systems and Data Science, TU Graz

1

Motivation:Weo�en use certain terminology, without clear definition, whichmight leadto misunderstanding.The same goes for the role so�ware architecture plays during the develop-ment process.Goals:Learn the main terms and understand the role of so�ware architecture

Outline

Terminology

Development Process

Requirements

Architectural Analysis & Design

Architectural Views

2

Terminology

�estions

1. What is so�ware architecture?

2. What is so�ware?

3. What is architecture?

4. What is a so�ware system?

5. What is a system?

3

# First, we need to define the main terminology!

Definition

• Latin word systema meaning a whole consisting of several parts or a complexwhole

• A system is a set of elements (components) that are connected to each other to form awhole

• The components composition is called system structure• Mostly, systems perform a certain function and serve a particular purpose

• e.g., an operating system

• The structure of a system might be quite complex

4

# A system# … has a structure (several parts)# … has a purpose# … performs functions# … is o�en complex

Additional Definitions

System Definition #1… an integrated composite that consists of one or more of the processes, hardware,so�ware, facilities and people, that provides a capability to satisfy a stated need orobjective.– IEEE 12207 1995

System Definition #2.. a set of resources that provide services that are used by an enterprise to carry out abusiness purpose or mission. System components typically consist of hardware,so�ware, data and workers.– Cantor, 2003

5

# Cantor 2003, Rational Unified Process for System Engineering.

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

6

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 withoutput

• 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

7

# These surroundings are already a good starting point for designing a sys-tem, e.g. start with the user interactions.

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 o�en complex

8

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

9

# For example the solar system, the nervous system, …

So�ware systems

So�ware… is collection of programs, related data, and related documentation.

So�ware… is a conceptual entity, whereas hardware is a collection of physical entities (devices).

A so�ware system… is a system in which all of its components, their connections and interactions areso�ware entities.

A so�ware system… runs on a specific hardware.

10

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 createmodels of systems

• Model is a simplified view of the system that focuses on a single aspect of asystem

• Typically, multiple (interdependent) views to study multiple aspects

11

# The amount of components is just one aspect of complexity.

Models of man-made systems

• We create models of natural systems to understand them be�er

• We create models of engineering systems to be able to build them• e.g., planing model, requirements model, structural model, behaviour model,implementation model, etc.

• More models specific for so�ware: e.g., run-time model, so�ware design model,usability model, etc.

12

Models Definition

Models… provide a specific description, or content, of an architecture. For example, astructural view might consist of a set of models of the system structure. The elementsof such models might include identifiable system components and their interfaces,and interconnections between those components.– IEEE 1471 2000

13

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: e.g., spark plug, brake disk, etc.

• At the intermediate detail level: e.g., car has engine, wheels, brakes, etc.

• At the highest detail level: e.g., car objects with variables, interacting with otherobjects

• OO programming model abstracts assembly, operating system, hardware, …

14


Figure 1: Car Components, image source: http://www.bestcarsguide.com/

15

# Just the main components of car, intermediate detail level.


Figure 2: Car components at a very fine level of granularity, image source:http://www.flickr.com/photos/rizzato/2610112430/

16

# More detailed components of car, low detail level.

Benefits of Models

Advantages of using models

• Detecting errors and omissions early in the life cycle

• Examining the relative merits of di�erent options (e.g., debate with colleagues)

• Understanding the impact of change

• Assisting with project planning

17

# Noteworthy disadvantage: Our model might be too simple (and does notcapture the relevant aspects).

Definition

A system architecture… is an integral collection of related system models at di�erent levels of abstractionand granularity.

An initial system architecture… is designed before the actual development of the system. This architecture governsthe system development.

Lifetime of system architectureMostly, the initial system architecture is iteratively updated during the systemdevelopment.

18

Definition

A so�ware architecture is a collection of models of a so�ware system at variousabstraction and detail levels. The models describe:

• the system as a whole

• system components

• component connections

• how component interact to fulfil the system purpose

# Note: The first three points concern the structure, while the last point concerns thebehaviour.

19

When do we need a so�ware architecture?

• Only complex systems

• Complexity can be (sometimes) estimated

• Large number of users, large amounts of data, large number of interactingcomponents, complex functions, etc.

• Sometimes you do not know this beforehand, e.g., system for a start-up company

20

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?

21


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?

22


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?

23


Facebook, Google, Twi�er

• Combine all of the complexities discussed above

• Large number of users, huge amount of data, complex interactions, quick updates

• Complex connections: networks, social networks, etc.

24

# Note: for enterprise applications the complexities are di�erent, but notnecessarily easier.

When a so�ware 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 adatabase

• We need the experience in developing this particular kind of a system, i.e. wedeveloped many such systems

• We need experience to make the distinction

25

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 aregood it is not necessary

• Building a skyscraper: you definitely need an architectural design

26

Development Process

Methodology

Common method for so�ware architecture

• A�ribute Driven Design (ADD)• �ality a�ributes 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 so�ware

27

# In this course, a mixture of these processes will be presented.

Methodology

Di�erent so�ware development processes have so�ware architecture as a partof the process

• Rational unified process

• Spiral development method

• Agile development method

• Evolutionary rapid development

28

Place of SA in SDP - An Example

29

Source: So�ware Architecture Primer by Reekie, McAdam

Methodology

• A�er the initial requirements analysis but before so�ware design

• The first architecture is also a communication basis with the customer

• Inputs for the development of the architecture:1. Requirements2. Context (technical, organizational, business, …)

30

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

31

# The term gold plating is being used to express the notion of integratingtoo much functionality into a system.

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

32

# In “real life” one would be more flexible - so this is a guideline.

Requirements

Analysis

• At the beginning there is e.g. a customer who wants a specific so�ware 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 onepossibility

33

Analysis

The results of the requirements analysis

1. Functional requirements

2. Non-functional requirements(a) Runtime qualities(b) Non-runtime qualities

3. Contextual requirements

34

Functional requirements

• A technical expression of what a system will do• Arise from stakeholder needs

• Approaches(a) Structured languages: so�ware 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

35

Non-functional requirements

• Other needs than directly functional or business related

• Generally expressed in the form of quality a�ributes (x-abilities)• Runtime quality a�ributes

• e.g., performance, usability, reliability, security

• Non-runtime quality a�ributes• e.g., maintainability, evolvability, testability, reusability, integrability, configurability,scalability

36

Contextual requirements

• What technologies are available?• Existing internal components• Existing o� 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, …

37

Requirements Definitions

Definition Functional RequirementsFunctional requirements describe the behaviour (functions or services) of the IT system that supportsthe users goals, tasks or activities– Malan, 2001

Definition Non-Functional RequirementsNon-functional requirements include constrains and qualities.– Malan, 2001

38

Requirements Definitions

Definition ConstraintsA constraint is a restriction on the degree of freedom we have in providing a solution– Le�ingwell, 2000

Definition�ality[System] qualities are properties or characteristics of the system that its stakeholders care about andhence will a�ect their degree of satisfaction with the system– Malan, 2001

39

# Malan, 2001, Defining non-functional requirements (PDF)# Le�ingwell, 2000, Managing so�ware requirements: an unified approach

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

40

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 anengineer

41

Example Application - System description I

Web-based Navigation Application: WNAPA simple and highly usable system for navigation is needed. It has to allow to navigateto the nearest store (e.g. Billa, Spar, Bipa), the next gas station or the best hotel, usingthe optimal route. Where there are multiple ways how the quality of the route can bedefined: shortest, quickest, most economical, cheapest, pleasant (e.g. quietest). In thefuture there should be more options on what an optimal route looks like. Theapplication 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 publictransport is selected it should indicate, which tram or bus line to take. The applicationshould allow in place purchase of tickets. The route should be shown on a map todemonstrate how it looks like. The estimated travel time should be displayed.

42

# Example of a system description to illustrate one possible way of require-ments engineering.

Example Application - System description II

Web-based Navigation Application: WNAPIf there are multiple about equally good routes, the user can choose which one shewants to take. The system is a Web-based system and the users should be able tooperate the system by using a standard Web browser. The users need not install anyadditional plug-ins to operate the system. In particular, browser back bu�on must beworking at all times and it should be possible to bookmark places at all times. Eachpage and each important application state needs to have a unique andhuman-readable URL.

43

Example Application - System description III

Web-based Navigation Application: WNAPThe application should be intuitive to use and aesthetically pleasing, the user shouldnot wait longer than a few seconds for each request. The colour scheme of the designcan be selected by every user individually. The language of the system can be freelychosen. When the user enters a new trip, a list of popular places should help the userto quickly create routes. It is expected that the application will be used by about1,000,000 users and about 1,000 users will concurrently search for routes.

44

Example Application - Tasks

Tasks of the so�ware 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

45

In the following slides, a number of (not exhaustive) examples use cases,personas, mock-ups and requirements are given.

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 search2. 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 criteria2. User orders tickets for public transport

46


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 usercredentials)

2. Public transport service issues a order3. User confirms order4. System delegates the confirmation and displays the ticket numbers

47


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 them2. Creates a ranked list of popular places3. Sysadmin uploads the new lists and triggers the system to use the

new list

48

Example Application - Persona

Example PersonaMarina, 17 years old, pupil

She regularly needs to navigate from her school to a public library to rent books for herhome work. When it is raining she cannot take her bike and the system should routeher via the public transport network (e.g. bus). The system should be aware of that shehas a seasonal ticket.

For all her navigation she uses her mobile phone, which is equipped with the latestversion of the Firefox web browser.

49

Example Application - Mockup Web

50

# There is dedicated so�ware to create mockups.# But there is not a strict need to use such tools, in many cases just conceptdra� (pen and paper) are su�icients.

# In later stages, one may even create click dummies to

Example Application - Mockup Mobile

51

Example Application - Functional requirements

• UR1: The system is a navigation tool. The system can calculate the followingoptimal 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: �ietest• UR1.5.2: Most sightseeing spots• UR1.5.3: Along rivers and through parks

52


• 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

53


• 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

• …

54

Example Application - Non-functional requirements

• UR1: The system is simple, usable and didactically sound. Usability

• UR2: The system needs to support multiple users simultaneously. PerformanceHow many users?

• UR3: Authentication should be supported. Security

• UR4: User-perceived performance must be acceptable Performance andUsability How many seconds at max users can wait?

• UR5: Web-based system should be available at all times. Reliability

55

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

56

Example Application - Contextual requirements

• UR1: Web browser.

• UR2: Valid (X)HTML, at least (X)HTML Transitional.

• UR3: No browser plugins are allowed.

57

Practical Guidelines

O�en a client (or other stakeholder) requests certain functionality/qualities/etc.

• Request 6= requirement• “Shopping cart mentality” by clients

• Typically a client wants all possible functionality• Business oriented vs. technical

• Clients will o�en not understand requirements• → demonstrate the benefit (or the consequences)

• O�en 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

• O�en requests are issued by the wrong people• e.g., usability should be judged by the real target group (end users)

58

Architectural Analysis & Design

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

59

Design

• Design is the process of creating models (recollect the definition of SA)

• Two basic types of architectural models• (i) Structure, and (ii) 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

60

Design

• Diagrams as the main tool for design

• Learn while doing (dra� 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

61

# There is not a standard for so�ware architecture (UML might be to struc-tured).

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 importantconcepts)

• It is important to remember that diagrams are only representations of the model

• Diagrams must always be accompanied by additional material such as text, datamodels, mathematical models, etc.

62


• What is a component?• … might be subsystems, separate processes, source code packages, …

• What is a connector?• … might be network protocols, method invocations, associations, …

• The combination of diagrams and additional material is an architectural model

63

# No clear “language” for diagrams.

• Is a component a sub-system, a thread, …?

• What is the role of a connector (and the arrow)?

• → Add responsibilities to components


Figure 3: Example of an architectural structure64

# This is just an initial architecture sketch, it is not considered the finalversion.# We use initial dra�s to gain a be�er understanding (of its shortcomings).# e.g., in this example we observe an central components that is connectedto every other component, this is typically not desired (see blob).# Furthermore, the connections are not clear, there is (with one exception)a bi-directional connection, can we be more specific?


• 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 orfunctional division?

• And what about connectors?

• Network protocols? Callbacks? Request/response cycles? Method invocations?

65

# These decisions are the job of the so�ware architect.


• What is the level of granularity of a diagram?

• e.g., for a Web-based system, components are servers and browsers and connectoris HTTP

• But, components of a server are HTTP parser, file I/O, cache, plug-ins, …

66


• Comparison with OO• A component is an object and a connector is a message sent between two objects

• We need additional information that accompanies diagrams

• To describe criteria for decomposition and provide explanations on granularity

67

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

68


• Each component has a set of responsibilities• Behaviour is the way how these responsibilities are exercised to respond to someevent

• An event may be an action of the user, an event from an external system, or aninternal trigger

BehaviourA particular behaviour is an event plus a response in the form of a sequence ofcomponent responsibilities

69


• To represent behavioural models we use use-case maps• It is a graphical notation• A use-case map consists of a trace drawn through a structural diagram of the system

• The sequence is initiated by an event

• The path of the trace through a structural diagram shows the sequence of activities

• Each crossing of a component by the trace indicates exercising of a responsibility

70

# [Buhr 98] - use case maps.# Connection from circle to bar.

# Crossing b/w use case map and component is a responsibility point


Figure 4: Types of traces in use-case maps

71


(a) Single trace - all responsibilities exercised sequentially

(b) Two traces are consecutive: Equivalent to single trace but shows that continuationis triggered by another event

(c) And-Fork: The traces a�er the line are potentially concurrent (run in parallel)

72


Figure 5: Types of traces in use-case maps

73


(a) N-Way And-Fork: the trace a�er the fork may be replicated an arbitrary number oftimes

(b) Or-Fork: The trace is split and activity proceeds along one or another path

(c) Seq-Fork: The traces a�er the line are followed in the order indicated by the arrow

74


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, thenretrieves the data from the database wraps it into an HTML response and sends theresponse to the Web UI

• Functionality allows me to display a map with a route

• → Behaviour is the sequence of activities that makes it happen

75


Figure 6: Example of architectural behaviour for the use case: display route

76

Architectural Views

Architectural views

• We can examine a system from di�erent points of view

• Di�erent kinds of views

• Conceptual: components are set of responsibilities and connectors are flow ofinformation

• Execution: components are execution units (processes) and connectors aremessages between processes

• Implementation: components are libraries, source code, files, etc and connectorsare protocols, api calls, etc.

77

Architectural views

• There are other models as well

• Data/information model describes the data

• Physical model describes servers, firewalls, workstations, …

• Deployment model describes the packaging of components

78

#Wewill mention them but wewill investigate only the previous threemod-els.

Architectural views

• Each view provides di�erent 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 so�warearchitecture

79

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

80

The EndThank you for your a�ention!

81

Documents

SA Analysis and Design - TU Graz