SA Analysis and Design Goals: Sofware Architecture VO (706.706) - - PDF document

SA Analysis and Design

Sofware Architecture VO (706.706)

Roman Kern Version 2.1.1

Institute for Interactive Systems and Data Science, TU Graz 1

Motivation: We ofen use certain terminology, without clear definition, which might lead to misunderstanding. The same goes for the role sofware architecture plays during the develop- ment process. Goals: Learn the main terms and understand the role of sofware architecture

Outline

Terminology Development Process Requirements Architectural Analysis & Design Architectural Views

2

Terminology

Qestions

• 1. What is sofware architecture?
• 2. What is sofware?
• 3. What is architecture?
• 4. What is a sofware 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 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 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 ofen complex

Additional Definitions

System Definition #1 … an integrated composite that consists of one or more of the processes, hardware, sofware, facilities and people, that provides a capability to satisfy a stated need or

• bjective.

– IEEE 12207 1995 System Definition #2 .. 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, sofware, 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 with
• utput
• 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 ofen 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, …

Sofware systems

Sofware … is collection of programs, related data, and related documentation. Sofware … is a conceptual entity, whereas hardware is a collection of physical entities (devices). A sofware system … is a system in which all of its components, their connections and interactions are sofware entities. A sofware 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 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

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 beter
• 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 sofware: e.g., run-time model, sofware design model,

usability model, etc.

12

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

• f 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 other
• bjects
• OO programming model abstracts assembly, operating system, hardware, …

14

Model abstraction and granularity level

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

15

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

Model abstraction and granularity 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 different 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 not capture the relevant aspects).

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. Lifetime of system architecture Mostly, the initial system architecture is iteratively updated during the system development.

18

Definition

A sofware architecture is a collection of models of a sofware system at various abstraction 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 the behaviour.

19

When do we need a sofware 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

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

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?

22

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?

23

Examples for complex systems

Facebook, Google, Twiter

• 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 different, but not necessarily easier.

When a sofware 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

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 are

good it is not necessary

• Building a skyscraper: you definitely need an architectural design

26

Development Process

Methodology

Common method for sofware architecture

• Atribute Driven Design (ADD)
• Qality atributes 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 sofware

27

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

Methodology

Different sofware development processes have sofware architecture as a part

• f the process
• Rational unified process
• Spiral development method
• Agile development method
• Evolutionary rapid development

28

Place of SA in SDP - An Example

29

Source: Sofware Architecture Primer by Reekie, McAdam

Methodology

• Afer the initial requirements analysis but before sofware 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, …)

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 integrating too 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 sofware 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

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: sofware 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 atributes (x-abilities)
• Runtime quality atributes
• e.g., performance, usability, reliability, security
• Non-runtime quality atributes
• e.g., maintainability, evolvability, testability, reusability, integrability, configurability,

scalability

36

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, …

37

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

38

Requirements Definitions

Definition Constraints

A constraint is a restriction on the degree of freedom we have in providing a solution – Leffingwell, 2000

Definition Qality

[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

39

# Malan, 2001, Defining non-functional requirements (PDF) # Leffingwell, 2000, Managing sofware 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 an

engineer

41

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.

42

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

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

• perate 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 buton 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.

43

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.

44

Example Application - Tasks

Tasks of the sofware 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 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

46

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

47

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

48

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.

49

Example Application - Mockup Web

50

# There is dedicated sofware to create mockups. # But there is not a strict need to use such tools, in many cases just concept draf (pen and paper) are sufficients. # 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 following
• ptimal 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: Qietest
• UR1.5.2: Most sightseeing spots
• UR1.5.3: Along rivers and through parks

52

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

53

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
• …

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. 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

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

Ofen 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 ofen not understand requirements
• → demonstrate the benefit (or the consequences)
• Ofen 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
• Ofen 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 (draf 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 sofware 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 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.

62

Architectural structure

• 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

Architectural structure

Figure 3: Example of an architectural structure

64

# This is just an initial architecture sketch, it is not considered the final version. # We use initial drafs to gain a beter understanding (of its shortcomings). # e.g., in this example we observe an central components that is connected to 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?

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?

65

# These decisions are the job of the sofware architect.

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, …

66

Architectural structure

• 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

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

Behaviour A particular behaviour is an event plus a response in the form of a sequence of component responsibilities

69

Architectural behaviour

• 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

Architectural behaviour

Figure 4: Types of traces in use-case maps

71

Architectural behaviour

(a) Single trace - all responsibilities exercised sequentially (b) Two traces are consecutive: Equivalent to single trace but shows that continuation is triggered by another event (c) And-Fork: The traces afer the line are potentially concurrent (run in parallel)

72

Architectural behaviour

Figure 5: Types of traces in use-case maps

73

Architectural behaviour

(a) N-Way And-Fork: the trace afer the fork may be replicated an arbitrary number of times (b) Or-Fork: The trace is split and activity proceeds along one or another path (c) Seq-Fork: The traces afer the line are followed in the order indicated by the arrow

74

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

75

Architectural behaviour

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

76

Architectural Views

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.

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

# We will mention them but we will investigate only the previous three mod- els.

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 sofware

architecture

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 End

Thank you for your atention!

81