This is an introductory lecture to Software Architecture, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)

1. L01: Intro to Software Architecture
Vittorio Cortellessa & Henry Muccini
DISIM Department, University of L’Aquila
vittorio.cortellessa@univaq.it;henry.muccini@univaq.it

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 Intro to Software Testing
Lab Structural Testing
SA style Model-based Testing
ADLs Architecture-based Testing
Design Decisions
Lab
Views/Viewpoints
UML Non Functional S.E.
UML Profiling Performance modeling
Lab Performance analysis
SEA Group

4. SEA Group

5. SEA Group

6. SEA Group

7. SEA Group

8. SEA Group

9. Software Architecture
The Software Architecture is the earliest model
of the whole software system created along the
software lifecycle
“Traditional” definition:
→A set of components and connectors communicating through
interfaces
“Recent/Future” understanding:
→A set of architecture design decisions taken to generate the
architecture artifact
→Focus on set of Views and Viewpoints, looking at
stakeholders and their concern
SEA Group

10. Software Architecture definitions
Perry and Wolf, ’92 (aspects):
→“Architecture is concerned with the selection of architectural elements, their
interactions, and the constraints on those elements and their interactions necessary
to provide a framework in which to satisfy the requirements and serve as a basis for
the design.”
→Elements are divided into processing elements, data elements and connection
elements
Garlan and Shaw, ’93 (elements):
→ Architecture for a specific system may be captured as “a collection of
computational components - or simply components - together with a description of
the interactions between these components - the connectors -”
Sommerville, 7th edition, ’04 (process):
→ The design process for identifying the sub-systems making up a system and the
framework for sub-system control and communication is architectural design. The output
of this design process is a description of the SA.
SEA Group

11. Application Example
“We want to build a software system that allows
people to vote electronically.
→ The citizen goes to the electoral place, and she votes using
a hw/sw device.
→ The vote is stored locally and automatically sent to other
computers.
→ The citizen identity must be validated by the system
→ …”
SEA Group

12. Basic Requirement Example
The voting system must satisfy the following
requirements:
→ One voter – one vote (no more than one vote for voter)
→ The voter can vote in only one previous designated voting
place
→ The voter must be identified by the election officials at the
voting place
─ The citizen identity must be validated by the system
→ It is not possible to trace the votes back to the voters
→ The election officials can’t read the results, guarantying that
the results are unknown until the end of the voting process
SEA Group

13. Example
SEA Group

14. Process
Requirements
A modeling language
Drives modeled in (e.g. UML)
Software
Architecture modeled in
Analysis
Implementation
Traceability
SEA Group

15. Advantages of explicit architecture
System analysis
→Analysisof whether the system can meet its functional and
non-functional requirements is possible.
Large-scale reuse
→The architecture (or part of it) may be reusable across a
range of systems.
Stakeholder communication
→Architecture may be used as a focus of discussion by system
stakeholders.
SEA Group

16. SA History
1992 and 1993: SA is recognized as an independent area of research;
→ What is SA
1993-1995: SA described through box and line (i.e. informal) diagrams;
1995-1997: Architectural Description Languages (ADLs) are introduced to formally
describe SA;
→ SA and Specification (with ADLs)
1997-2003:
→ more interest on dynamic aspects of SA;
→ SA recognized as a valid tool to deal with various aspects of complex,
concurrent, real systems;
→ SA and UML
→ SA and Analysis
2003-today:
→ SA vs CBSE, AOP, SOA, etc…
→ Design Decisions, Viewpoints
SEA Group

17. Civil Architecture vs Software
Architecture
Civil : » Software :
Bricks - Three types of
Roof components
Chimney top - Multiple instances
of the type “brick”
» Civil : » Software :
- Concrete - Connectors
- Construction Rules - Assembly constraints
SEA Group

18. In general terms…
SA describes (in a more or less “formal” notation) how a system is
structured into components and connectors…
→Components
→Connectors SA Structure (topology)
→Channels and Ports
… and how these components interact
→Scenarios
→State Diagrams SA Dynamics (behavior)
→…
SEA Group

19. General workflow
SEA Group

20. Static Description
→Components
→Connectors
→Interfaces
SEA Group

21. Components
A component is a building block that is …
→A unit of computation or a data store, with an interface
specifying the services it provides and requires
→A unit of deployment
→A unit of reuse
─ e.g., client, server, database, filters, ...
required S’x S1 provided
services S’Y C1 S2
S3 services
SEA Group

22. Components vs Objects
The level of abstraction is usually different
Size
→Objects tend to be small
→Components can be small (one object) or large (a library of
objects or a complete application)
An architectural component may be implemented by
several objects
Lifecycle
→Objects
are created and destroyed constantly
→Components are created and destroyed infrequently
SEA Group

23. Connectors
A connector is a building block that enables interaction among
components
→Events
→Client/server middleware
→Messages and message buses
→Shared variables
→Procedure calls (local or remote)
→Pipes
Connectors may be implicit or explicit
→Connectors sometimes are just channels
→Connectors sometimes have their own logic and complexity
Connectors may be endogenous or exogenous
SEA Group

24. Components and Connectors
A component is (or should be) independent of the
context in which it is used to provide services
A connector is (or should be) dependent on the
context in which it is used to connect components
Connectors sometimes are modeled as special kinds of
components
SEA Group

25. Interfaces
An interface is the external connection of a
component (or connector) that describes how to
interact with it
Provided and required interfaces are important
Spectrum of interface specification
→ Loosely specified (events go in, events go out)
→ API style (list of functions)
→ Very highly specified (event protocols across the interface
in CSP)
SEA Group

26. Architecting: example
GUI
Admin
NewsFeeder Action
Action
Transfer
Object DATABASE
FeedService
Common FeedService
Trasformation Action
Validation
ValidatorService
Browser Validation
(html Service
javascript)
NewsFeederDelegate
FeedDelegate
NewsFeeder FeedDelegate
DelegatePOJOs POJOs NewsFeederDAO
NewsFeeder
Web DAO
Services
BusinessFactory Factory FeedDAO
FeedDAO
SEA Group

27. Architecting: example
SEA Group

28. Dynamic Description
Behavioral models
SEA Group

29. SA dynamics
The SA dynamics is expressed in terms of component
interactions via connectors
•Labeled Transition Systems
•Automata
•UML StateCharts, Sequence Diagrams, Activity Diagrams
•State Diagrams
•Message Sequence Charts
•…
SEA Group

30. AN EXAMPLE : E-COMMERCE SYSTEM
Customer Interface
Web Server
Cart Server Customer Process
Delivery Order
Catalog Server
Process
Customer Server
Order Server
SA Static Description
SEA Group

31. AN EXAMPLE : E-COMMERCE SYSTEM
CustomerInterface CustomerProcess CatalogServer
Registered Customer
BrowseCatalog
BrowseCatalog
ReadStatus
Catalog DB
Catalog Info Involved
Catalog Page
Output Page
SA Dynamic Description :
Browse Catalogue Sequence Diagram
SEA Group

32. AN EXAMPLE : E-COMMERCE SYSTEM
SA Dynamic Description :
Place Order Sequence Diagram (success)
SEA Group

33. AN EXAMPLE : E-COMMERCE SYSTEM
SA Dynamic Description :
Place Order Sequence Diagram (empty cart)
SEA Group

34. Architectural Elements vs Design Elements
“Architecture is concerned with the selection of
architectural elements, their interactions, and the
constraints on those elements and their interactions
necessary to provide a framework in which to satisfy
the requirements and serve as a basis for the
design.”
“Design is concerned with the modularization and
detailed interfaces of the design elements, their
algorithms and procedures, and the data types
needed to support the architecture and to satisfy the
requirements.”
(Perry & Wolf 92)
SEA Group

35. Architectural Elements vs Design Elements
“The architecture of a software system defines that
system in terms of computational components and
interactions among those components. … In addition
to specifying the structure and topology of the
system, the architecture shows the correspondence
between the requirements and elements of the
constructed system, thereby providing some
rationale for the design decisions.”
(Shaw & Garlan 96)
SEA Group

36. Architecture and NF characteristics…
Performance
→Localise critical operations and minimise communications.
Security
→Use a layered architecture with critical assets in the inner layers.
Safety
→Localise safety-critical features in a small number of sub-systems.
Availability
→Include redundant components and mechanisms for fault tolerance.
Maintainability
→Use fine-grain, replaceable components.
SEA Group

37. … may originate architectural conflicts
Using large-grain components improves performance
but reduces maintainability.
Introducing redundant data improves availability but
makes security more difficult.
Localising safety-related features usually means more
communication so degraded performance.
SEA Group

38. Architectural styles
The architectural model of a system may conform to a
generic architectural model or style.
The awareness of these styles can simplify the problem
of defining system architectures.
There is a strict relation between the ADLs and the
style adopted.
However, most large systems are heterogeneous and
do not follow a single architectural style.
SEA Group