Download - 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
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
13
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
• …
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
Component responsibilities
• 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
Component responsibilities
• 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
Behavioural exploration
34
Behavioural exploration
35
Behavioural exploration
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.
Behavioural exploration
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
Component stereotypes
Figure 2: Source: So�ware Architecture Primer
40
Component stereotypes
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
Conceptual arch. design rules
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
Conceptual arch. design rules
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
Conceptual arch. design rules
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