DISIM

Dept. of Information Engineering, Computer Science and Mathematics

University of L’Aquila, Italy

Software Architecture Activities

Henry Muccini

henry.muccini@univaq.it

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