Upload
henry-muccini
View
428
Download
0
Embed Size (px)
Citation preview
DISIM
Dept. of Information Engineering, Computer Science and Mathematics
University of L’Aquila, Italy
Software Architecture Activities
Henry Muccini
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
SEA Group
SEA Group
There are four dominant software development
processes:
• Waterfall
• Iterative
• Agile
• Model-driven
development
SEA Group
• No matter the software development
process, there are activities…
role
Seen
abovespecification
manual
report
SEA Group
Requirements/User
stories
Software Design
Implementation
Testing
Maintenance
SEA Group
SEA Group
SA
Design
Decisions
Components and Connectors
SA Modeling
Subsystems
AS Requirements with Quality
attributes
SA Verification and Validation
SA-based coding
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.
SEA Group
Let us identify the system
requirements
Let us identify the
ARCHITECTURALLY SIGNIFICANT
requirements
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
SEA Group
Let us identify subsystems
SEA Group
Let us identify the main
components and connectors
SEA Group
SA box&line informal
Modeling
Incremental design
AND/OR SA Formal Modeling
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?
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 InverardiModel-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
SEA Group
Coding based on the
defined SA
Systematic skeleton «code
generation»
SA as a reference artifact for
coding
inputs
C2SADL,
ArchJava, JavaA
SEA Group
SA
Design
Decisions
Components and Connectors
SA Modeling
Subsystems
AS Requirements with Quality
attributes
SA Verification and Validation
SA-based coding
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
SEA Group
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.
SEA Group
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.
SEA Group
SEA Group
«Software Architecture in Practice»,
Chapter 3
SEA Group
Decomposition
Designing to Architecturally Significant RequirementsWhat happens to the other requirements? Do I design for one ASR at a time or all at once?
Generate and TestHypothesis
Existing systemsFrameworksPatterns and tacticsDomain decompositionDesign checklists
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 firstStep3:Generate and test
Patterns, tactics, checklists
SEA Group
http://agilemanifesto.org/
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
architectingUp-front design
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
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
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