conceptual architecture - tu graz

Conceptual Architecture

So�ware Architecture VO (706.706)

Roman Kern

Version 2.3

Institute for Interactive Systems and Data Science, TU Graz

1

Outline

Definition

Designing Conceptual Architecture

Behaviour Model

Data Models & Component Stereotypes

Design Guidelines

2

Simplified Workflow Recap

Exemplary, simplified step-by-step guide to start the conceptual architecture

1. Identify actors with the systems (e.g. external system, users)

2. Identify data flow

3. Identify functional requirements

4. Identify non functional requirements

5. Prioritise requirements

6. Define use-cases

7. Define data items

3

In real life one would be more flexible See The Process of So�ware Architect-ing by Eeles and Cripps, page 145, 147

Definition

Conceptual Architecture

• Focuses on domain-level responsibilities

• Initial architectural design

• First response to stakeholder needs

• Design by analysing requirements

• Contains components and connectors (box and line diagram)

→ Provides an at a glance overview of the structure of a system in terms of itsfunctionality

4

Components in conceptual architecture

Components

• Set of related domain-level responsibilities

• Initially, responsibilities arise from functional requirements

ProcessDesign is an iterative process→ further iterations to take into account non-functionalrequirements

5

Connectors in conceptual architecture

Connectors

• Connectors indicate that connected components exchange information

• Arrows indicate information flow

• Labels describe kind of information

• In some cases two-directional connectors• Labels should be put near arrows

6

Connectors in conceptual architecture

Practical aspects

• Conceptual components o�en have no direct counterpart in the final so�ware• … no need to care about physical location

7

Simple example

Figure 1: Model-car control system from So�ware Architecture Primer8

• Supervisory

– Receive commands and decode them– Send command data to real-time components– Send selected data to remote interface

• Braking

– Apply braking force in percentage amount– Generate thro�le inhibit signal

• Steering

– Set steering gear to selected angle

• EFI

– Control spark and injection timing– Control amount of fuel injected

Designing Conceptual Architecture

Design process

1. Create the initial conceptual architecture from requirements

2. Elaborate focusing on functionality

3. Elaborate focusing on quality a�ributes (non-functional requirements, contextualrequirements)

4. Iterate over 2 and 3

9

Design process

Initial steps

1. Identify key concepts• Within requirements• Within narratives, …

2. Assign key concepts to categories:• Data, Function, Stakeholder, System, Abstract Concept

10

The first step

Practical exercise

1. Underline the key concepts in the requirements• Does this concept relates to the functionality?

2. Copy key concepts onto a sheet• Consider each one to see if it is a viable component

3. Draw the components and add connectors• Add arrows and labels

11

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

12


• 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

13


• 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

• …

14

The second step

• Assign every possible concept from the requirements to a category

• The goal is to arrive at a list of candidates for components

15

The second step

Data

• Information that is stored, processed, etc.

→ Not directly a component but you might need components for data management

16

The goal of the second step it to arrive at a list of candidates for components

The second step

Function

• Something done by something

→ typically components

17

The second step

Stakeholder

• Users, organizations, …

→ never components

18

The second step

System

• External systems

→ sometimes one needs an interface component

19

The second step

Hardware→ Physical components

20

The second step

Abstract concept

• Explanation of something

→ rarely components

21

Key Concepts

• navigation tool Abstract concept

• calculate Function

• optimal route Abstract concept

• shortest path Abstract concept

• fastest route Abstract concept

• most economical Abstract concept

• cheapest Abstract concept

• pleasant Abstract concept

22

Key Concepts

• places Data

• database Data

• connections Data

• transportation mode Data

• administrator Stakeholder

• add/remove (places) Function

• user Stakeholder

• search Function

23

Key Concepts

• external services System• buy (ticket) Function• ticket Data• tramway Data• draw Function• route Data• interactive map Abstract concept• user management Function• register Function• users Data• log-in / log-out Function• user preference Data• credentials Data• purchase Function

24

Categorisation

Data Function Stakeholder System Abs.concept

places calculate administrator external services navigation tooldatabase add/remove (places) user optimal routeconnections search shortest pathtransp. mode buy (ticket) fastest routetramway draw most economicalroute user management cheapestusers register pleasantuser preference log-in / log-out interactive mapcredentials purchaseticket download

register

25

Conceptual Architecture: Best Practice

• Start with stakeholders and external systems

• Think about the data, data exchange and data storage

• Think about active components, that trigger events

• Combine the functions into groups of related functionality

• Optionally, use narratives as guide how to group the components

First Iteration→ draw a first iteration & validate the first iteration

26

Conceptual Architecture: Iteration 1

27

Component responsibilities

• AppUI• ShowPlaces• DisplayMap• DrawRoute• DisplayTicket

• AdminPanel• ListPlaces• ListConnections

• NavigationService• StartCalculation• BuyTicket• RouteComputed• TicketPurchased

• AdminService• AddPlace• RemovePlace

28


• RouteFinder• ComputeRoute

• Tickets• ListPrices• StartPurchase

• UserManager• RegisterUser• LoginUser• GetSeasonalTickets

• GeoinformationManager• AddPlace• RemovePlace• SearchPlace

29

Iterations

Iterate over functional and non-functional requirements:

• Functional seems to be OK

• Non-functional: performance as a quality a�ribute• → Factor out the search functionality (e.g. search for places, …)

• Also, design for change• → Abstract external systems through interface (e.g. new public transportation system)

30

Conceptual Architecture: Iteration 2

31


• Search• SearchPlaces

• PublicTransportAPI• ListPrices• BuyTicket

32

Behaviour Model

Behavioural exploration

• Until now only structural architecture

• We need to take into account behaviour of the system

• Typically accomplished through usage narratives

• We can take two/three use case scenarios and draw use-case maps

33


34


35


Validate found components and connectors

• Identify missing components• e.g., unclear, how to continue the use-case map

• Identify potential split-up components• e.g., Repetition in small cycles

• Identify potential bo�lenecks• e.g., all use-case maps pass through same component

• Identify ill-defined responsibilities• e.g., each use-case map looks the same for all use cases

36

# In the conceptual architecture, the facade pa�ern might not be as relevantas in the implementation.


Validate information flow

• At each step in the use-case map• Identify the required functionality• Identify the information need of the component

• If information is missing• Continue use-case map for data retrieval

37

# Performance bo�lenecks due to data retrieval can be identified early on.

Data Models & ComponentStereotypes

Data Models

• Data models capture the nature of information in the domain

• If data exchanged between components is complex• → we might need to create data models

• Need to define a format

38

# In our case: datasets and calculations, e.g., UML as a format

Component stereotypes

• Adding semantics to components through stereotypes

• Tagging components to indicate certain properties

• Presentation component: interactions with users

• Persistent storage: persistent data or data from external systems

• Real-time components: components that handle requests “quickly”

39


Figure 2: Source: So�ware Architecture Primer

40


41

Design Guidelines

Conceptual arch. design rules

Guidelines for defining components

• Granularity

• Cohesion

• Coupling

42

# See The Process of So�ware Architecting by Eeles and Cripps, page 215


Granularity of components

• Amount of functionality assigned to a single component• Depends on the context of the component

• Granularity should be consistent for all components

43

See The Process of So�ware Architecting by Eeles and Cripps, page 215


Avoid Blobs

• Components that have too many responsibilities

• Recognized by: one component has all the responsibility, others have singleresponsibilities

• Reason 1: too much details in responsibilities

• Reason 2: too lazy too divide responsibilities

→ Put more e�ort in dividing responsibilities

44


Avoid command clusters

• Couple of components all with a single responsibility but all interconnected

• Recognized by: too many connectors between a set of components

• Reason: responsibilities are in fact related

→ Combine components into a single component

45

Cohesion

Increase Cohesion

• How well are the responsibilities of a component related to each other

• If the relationship is high, then the cohesion is high as well

• High cohesion is considered to be good• e.g., makes the architecture easier to understand

• Will help to maintain the system

• Will help to design components that will be reused

46

# See The Process of So�ware Architecting by Eeles and Cripps, page 215

Coupling

Reduce Coupling

• Degree to which so�ware components depend on each other

• The degree is influenced on a couple of aspects (more than in OO languages)

• e.g., how generic is the protocol?

47

Degree of Coupling

• Loose coupling vs. tight coupling

• These are the both extremes

• In existing systems this is o�en a continuum

• Components might be tightly in one aspect and loosely coupled in another

48

Aspects of Coupling

Level Loose Coupling Tight CouplingPhysical coupling Physic intermediary Direct physical link re-

quiredCommunication style Asynchronous SynchronousType system Data-centric, self-

contained messagesOO-Style, complex objecttrees

Control of process logic Distributed logic compo-nents

Central control

Platform dependencies OS- and programminglanguage independent

Strong OS and pro-gramming languagedependencies

49

See Enterprise SOA by Dirk Krafzig, Karl Banke, Dirk Slama.

Coupling

In practice o�en tight coupling

• API/protocol specific to the needed requirements

• O�en enforced by cross-cu�ing concerns

• Typically it is easier (less e�ort) to create

• Loose coupling will typically require more e�ort and be�er design/planning

50

Consequences of Tight Coupling

• If one so�ware component changes• … the other (dependant) components need to be changed as well

• Lot of information exchange between components

• Tendency to result in blob components

51

Consequences of Loose Coupling

• Components can be easily exchanged

• Components will be be�er suited to be reused

• Components are required to be more generic• e.g., use standard protocols instead of custom ones

52

Type of Coupling in Regard to �ality A�ributes

Impact on quality a�ributes

• Loose coupling will typically improve maintainability, evolvability, reusability• e.g., easier to add new functionality, fix bugs, …

• Tight coupling will typically improve the achievable performance (and traceability)• e.g., easier to understand architecture

• For some a�ributes it is not clear, e.g., testability

⇒ Therefore slight preference to loose coupling

53

Examples of Coupling

54

• Tight coupling between Service and the RouteFinder

– Due to callback (both need to know each other, there mighteven be a temporal coupling here)

• Loose coupling between Tickets and External System

• The external system does not need to know the Ticket component

• The external system might use a standard protocol

• ⇒ Easy to exchange the external system

Script of Conceptual Architecture

Steps of developing the conceptual architecture

1. Clarify components & responsibilities• e.g., by identifying key concepts

2. Clarify connectors• e.g., by labelling information flow

3. Evaluate static model• e.g., granularity, cohesion, coupling• e.g., blob, command clusters

4. Evaluate behaviour (against expected scenarios)• e.g., use-case maps

5. Identify stereotypes & structures6. Define the data structure & models7. Simplify architecture

55

# It is an iterative process

The EndThank You for Your A�ention!

56

conceptual architecture - tu graz

Documents