This document provides an overview of a lab on software architecture. It includes slides on introductory concepts of software architecture, architectural styles, analysis methods, and modeling notations. It also presents a case study on designing an architecture for a fire detection and response system and discusses views, decisions, requirements, and quality attributes to consider.

1. LAB on Software Architecture
Vittorio Cortellessa and Henry Muccini
vittorio.cortellessa@univaq.it;henry.muccini@univaq.it
DISIM
Dep.nt of Information Engineering, Computer Science and Mathematics
University of L’Aquila, Italy

2. The material in these slides may be freely reproduced
and distributed, partially or totally, as far as an explicit
reference or acknowledge to the material author is
preserved.
SEA Group

3. Intro to SA
SA Case study
SA style
ADLs
Design Decisions
Views/Viewpoints
SEA Group
Non Functional S.E.
Performance modeling
Performance analysis
UML
UML Profiling
Lab

4. I need a system that:
SEA Group
 Can detect and predict fire in a building
 Can communicate to the fire fighters
 Can communicate to the fire trucks
 Can route fire trucks towards different fires
 Can monitor the state of a fire

5. There is some smoke on the first apartment in the 4th floor, on Avenue de Fortune
26. A smoke sensor detects the smoke, potential source of a fire, and informs a local
server. The local server posts the information on-line, and this information is
accessible from the fire station. The fire station has a view on all the alarms and
warnings happening at the all time. The system monitors the status of alarms and
informs the fire fighters about the entity of the fire, the time it started, the area
covered by it, and other sensitive information. Based on such information, the
system decides where to send the fire trucks (in case only a limited set of fires can
be managed in parallel). The fire fighters jump into the fire truck, turn in their
onboard computing system, and get information about the fastest way to get to
destination. During the trip, they get all possible updates about the state of the fire.
Based on this information, they may decide that a second truck is needed, or one is
closer to Avenue de Fortune, or that their service is not needed anymore. When the
fire fighters arrive to Avenue de Fortune 26, the entire 4th floor is on fire. By using
other sensors, they may know how many people is trapped inside the building: this
information is displayed on their devices. Fortunately, nobody is inside the building
at this time. Before starting extinguishing the fire, the system discovers that there
are some gas cylinders on the 6th floor. They first start securing those devices, and in
parallel extinguishing the fire on the 4th floor.
SEA Group

6. Overall Architecting Process
SEA Group
Architectural constraints
and requirements
Ideas
Constraints
Req1:..
Req2:..
Req3:..
………
Architectural
requirements
C2
C3
C1
C4
Software
Architecture
Software
Architecture
synthesis
C2
C3
C1
Software C4
Architecture
Evaluation and prototype
Decisions making

7. Features:
SEA Group
• Those are related factors to be used to prevent a fire

8. SEA Group
- The system has to enable quick but effective decisions on how
to fight the fire (in order to plan an Intelligent scheduling and
resource allocation)
Non Functional Requirements:

9. SEA Group
Class Work

10. SEA Group
Draw your
architecture
Chapter 1

11. Main Design Decisions to be taken
What to Model?
How to Model?
Multiple Views
Is the produced one a Good architecture?
How to use such an architecture?
SEA Group

12. HW/SW/Deployment
Component Types and Instances
Structural and behavioral
Components’ Nesting and sub-systems
What can I model, what I cannot ?
Requirements and qualities
Styles
SEA Group

13. What to model?
What are the architectural-specific decisions?
How do they affect the architecture? How the final
product?
SEA Group

14. Define an architecture from different viewpoints:
SEA Group

15. There are three different options:
component ElevatorPanel is {
state {
vport : ViewportType;
sub_vports : set ViewportIDType;
}
invariant {
#sub_vports eqgreater 0;
}
interface {
prov ip_newvpt: createViewport() : ViewportType;
SEA Group
...
req ir_selshp: selectShipment(port : PortID; shp : ShipmentID);
}
operations {
prov op_subvpt: {
let vpt : ViewportIDType;
pre vpt not_in sub_vports;
post (#~sub_vports = #sub_vports + 1) and
(vpt in sub_vports);
}
...
User1
AlarmUR AlarmRS (c)
Router Server
Timer
Check1
Nofunc
Clock
AckSR (c)
AckRU1
User2
AlarmUR1
AlarmUR2
Check2
Check
AckRU2
C1
C3
C4
C2
C5
C4'

16. Drawing
Formal languages
Model-based Notation
SEA Group

17. SEA Group
The quality of a SA depends on how well it
satisfies functional and non functional
requirements

18. Assessment:
SEA Group
Is my architecture really compliant to certain given requirements?
Conformance:
Is my implementation really compliant to my architectural specification?
The SA specification, when assessed, acts as an oracle, describing what expected
Analysis can start even before the code is available

19. Much has been done for SA-level Analysis:
SEA Group

20. The goal is to generate a skeleton code, reflecting
architectural elements and decisions
The main approaches so far:
SEA Group
Ada, C, Java
MDA approaches and model transformation
Extension to Java
The ACME ADL concepts are automatically mapped into ArchJava concepts