KEMBAR78
Software Architecture Lab | PPTX
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
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
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
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
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
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
Features: 
SEA Group 
• Those are related factors to be used to prevent a fire
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:
SEA Group 
Class Work
SEA Group 
Draw your 
architecture 
Chapter 1
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
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
What to model? 
What are the architectural-specific decisions? 
How do they affect the architecture? How the final 
product? 
SEA Group
Define an architecture from different viewpoints: 
SEA Group
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'
Drawing 
Formal languages 
Model-based Notation 
SEA Group
SEA Group 
The quality of a SA depends on how well it 
satisfies functional and non functional 
requirements
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
Much has been done for SA-level Analysis: 
SEA Group
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

Software Architecture Lab

  • 1.
    LAB on SoftwareArchitecture 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 inthese 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 asystem 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 somesmoke 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.
  • 10.
    SEA Group Drawyour architecture Chapter 1
  • 11.
    Main Design Decisionsto 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 Typesand 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 architecturefrom different viewpoints: SEA Group
  • 15.
    There are threedifferent 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 Thequality 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 beendone for SA-level Analysis: SEA Group
  • 20.
    The goal isto 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