The document discusses software architecture activities including: 1. Identifying requirements and architecturally significant requirements 2. Designing subsystems and identifying main components and connectors 3. Modeling the software architecture and performing analysis, verification, and validation activities to ensure the implementation conforms to the architecture.

1. DISIM
Dept. of Information Engineering, Computer Science and Mathematics
University of L’Aquila, Italy
Software Architecture Activities
Henry Muccini
henry.muccini@univaq.it

2. SEA Group
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.
Henry Muccini

3. SEA Group

4. SEA Group
There are four dominant software development
processes:
• Waterfall
• Iterative
• Agile
• Model-driven
development

5. SEA Group
• No matter the software development
process, there are activities…
role
Seen
abovespecification
manual
report

6. SEA Group
Requirements/User
stories
Software Design
Implementation
Testing
Maintenance

7. SEA Group

8. SEA Group
SA
Design
Decisions
Components and Connectors
SA Modeling
Subsystems
AS Requirements with Quality
attributes
SA Verification and Validation
SA-based coding

9. SEA Group
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.

10. SEA Group
Let us identify the system
requirements
Let us identify the
ARCHITECTURALLY SIGNIFICANT
requirements

11. SEA Group
Communications between sensors and server
Track system
Compatibility with other systems
Sw running on the firefighters
Extensibility
Data analytcs
Where to send fire fighters in case of multiple fires
Fault tolerance

12. SEA Group
Let us identify subsystems

13. SEA Group
Let us identify the main
components and connectors

14. SEA Group
SA box&line informal
Modeling
Incremental design
AND/OR SA Formal Modeling

15. SEA Group
SA-based functional and
non functional analysis
SA-conformance to
requirements
Predictive analysis
Code-to-SA conformance
analysis
Do you
remember
what V&V is?

16. SEA Group
SA-based functional and
non functional analysis
SA-conformance to
requirements
Predictive analysis
Code-to-SA conformance
analysis
Patrizio Pelliccione, Paola Inverardi, Henry Muccini: CHARMY: A Framework for
Designing and Verifying Architectural Specifications. IEEE Trans. Software Eng.
35(3): 325-346 (2009)
Vittorio Cortellessa, Antinisca Di Marco, Paola Inverardi
Model-Based Software Performance Analysis.
First Edition, Springer, 2011.
Henry Muccini, Antonia Bertolino, Paola Inverardi: Using Software Architecture for
Code Testing. IEEE Trans. Software Eng. 30(3): 160-171 (2004)
inputs

17. SEA Group
Coding based on the
defined SA
Systematic skeleton «code
generation»
SA as a reference artifact for
coding
inputs
C2SADL,
ArchJava, JavaA

18. SEA Group
SA
Design
Decisions
Components and Connectors
SA Modeling
Subsystems
AS Requirements with Quality
attributes
SA Verification and Validation
SA-based coding

19. SEA Group
– 1. Making a business case for the system
– 2. Understanding the architecturally significant
requirements
– 3. Creating or selecting the architecture
– 4. Documenting and communicating the architecture
– 5. Analyzing or evaluating the architecture
– 6. Implementing and testing the system based on the
architecture
– 7. Ensuring that the implementation conforms to the
architecture

20. SEA Group

21. SEA Group
Architects need more than just technical skills.
– Architects need to explain to one stakeholder or another
the chosen priorities of different properties, and why
particular stakeholders are not having all of their
expectations fulfilled.
– Architects need diplomatic, negotiation, and
communication skills.
– Architects need the ability to communicate ideas clearly
– You will need to manage a diverse workload and be able
to switch contexts frequently.
– You will need to be a leader in the eyes of developers and
management.

22. SEA Group

23. SEA Group
Technical. The technical context includes the
achievement of quality attribute requirements.
Project life cycle. Regardless of the software
development methodology you use, you must perform
specific activities.
Business. The system created from the architecture
must satisfy the business goals of a wide variety of
stakeholders.
Professional. You must have certain skills and
knowledge to be an architect, and there are certain
duties that you must perform as an architect.

24. SEA Group

25. SEA Group
«Software Architecture in Practice»,
Chapter 3

26. SEA Group
Decomposition
Designing to Architecturally Significant Requirements
What happens to the other requirements?
Do I design for one ASR at a time or all at once?
Generate and Test
Hypothesis
Existing systems
Frameworks
Patterns and tactics
Domain decomposition
Design checklists

27. SEA Group
Attribute-Driven Design
Iterative method
«workable»
architecture
early and quickly
boundaries
Inputs:
correct set of ASRs
External systems, devices, users
Output:
Sketches of Architectural views
Agile
Step1:
Decomposition tree
you want or won’t pick «whole»
system as the starting point
breadth or depth first
Step3:
Generate and test
Patterns, tactics, checklists

28. SEA Group
http://agilemanifesto.org/

29. SEA Group
While it may not work for complex systems:
The principles reflect a process employed for small-to
medium-sized project
Co-location or high level of communication
Little attention to cross-cutting concerns
agility code-first
architecting
Up-front
design

30. SEA Group
Adding time for up-front
work reduces later rework
But, how much?
Sweet spots:
.10ksloc -> no up-front
. …
.1000ksloc -> ~40%
Risk reduction
Boehm and Turner

31. SEA Group
“If information isn’t needed, don’t spend the resources
to document it. All documentation should have an
intended use and audience in mind, and be produced in
a way that serves both.”
“We document the portions of the architecture that we
need to teach to newcomers, that embody significant
potential risks if not properly managed, and that we
need to change frequently. We document what we
need to convey to readers so they can do their job.”
[SAinPractice]
YAGNI = You ain’t gonna need it

32. SEA Group
Web-based Video Conferencing
Process:
Initial software and system architecture
Incremental implementation
Starting with critical functionalities
Architecture refactoring based on new requirements
Continuous experimentation, empirical evaluation,
architectural analysis