software architecture: introduction
DESCRIPTION
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)TRANSCRIPT
![Page 1: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/1.jpg)
L01: Intro to Software Architecture
Vittorio Cortellessa & Henry Muccini
DISIM Department, University of L’Aquila
![Page 2: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/2.jpg)
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
preserved.
![Page 3: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/3.jpg)
Intro to Software Testing
Structural Testing
Model-based Testing
Architecture-based Testing
Lab
Intro to SA
Lab
SA style
ADLs
Design Decisions
Views/Viewpoints
SEA Group
Non Functional S.E.
Performance modeling
Performance analysis
UML
UML Profiling
Lab
Views/Viewpoints
![Page 4: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/4.jpg)
SEA Group
![Page 5: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/5.jpg)
SEA Group
![Page 6: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/6.jpg)
SEA Group
![Page 7: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/7.jpg)
SEA Group
![Page 8: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/8.jpg)
SEA Group
![Page 9: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/9.jpg)
Software Architecture
The Software Architecture is the earliest modelof the whole software system created along the software lifecycle
“Traditional” definition:
A set of components and connectors communicating through
SEA Group
→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
![Page 10: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/10.jpg)
Software Architecture definitionsPerry 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
SEA Group
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.
![Page 11: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/11.jpg)
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
SEA Group
→ The vote is stored locally and automatically sent to other
computers.
→ The citizen identity must be validated by the system
→ …”
![Page 12: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/12.jpg)
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
SEA Group
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
![Page 13: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/13.jpg)
Example
SEA Group
![Page 14: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/14.jpg)
A modeling language
(e.g. UML)
Software
modeled in
Process
Requirements
Drives
SEA Group
Software
Architecture
Implementation
modeled in
Traceability
Analysis
![Page 15: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/15.jpg)
Advantages of explicit architecture
System analysis
→Analysis of 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.
SEA Group
range of systems.
Stakeholder communication
→Architecture may be used as a focus of discussion by system stakeholders.
![Page 16: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/16.jpg)
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:
SEA Group
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
![Page 17: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/17.jpg)
Civil Architecture vs Software Architecture�
Civil :
BricksRoofChimney top
» Software :
- Three types of components
- Multiple instances of the type “brick”
SEA Group
» Civil :
- Concrete
- Construction Rules
» Software :
- Connectors
- Assembly constraints
![Page 18: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/18.jpg)
In general terms…
SA describes (in a more or less “formal” notation) how a system is
structured into components and connectors…
→Components
→Connectors
→Channels and Ports
SA Structure (topology)
SEA Group
… and how these components interact
→ Scenarios
→State Diagrams
→…
SA Dynamics (behavior)
![Page 19: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/19.jpg)
General workflow
SEA Group
![Page 20: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/20.jpg)
Static Description
→Components
→Connectors
→Interfaces
SEA Group
![Page 21: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/21.jpg)
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
SEA Group
→A unit of reuse
─ e.g., client, server, database, filters, ...
C1S1S2S3
S’xS’Y
provided services
required services
![Page 22: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/22.jpg)
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)
SEA Group
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
![Page 23: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/23.jpg)
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)
SEA Group
→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
![Page 24: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/24.jpg)
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
SEA Group
context in which it is used to connect components
Connectors sometimes are modeled as special kinds of components
![Page 25: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/25.jpg)
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
SEA Group
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)
![Page 26: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/26.jpg)
Architecting: example
GUI
FeedServiceFeedServiceCommon
Action
NewsFeeder
Action
Admin
Action
Transfer
Object DATABASE
Trasformation
SEA Group
Factory
FeedDelegate
POJOs
NewsFeeder
DAO
FeedDAO
NewsFeederDAO
FeedDAO
FeedDelegate
ValidatorService
NewsFeeder
DelegatePOJOs
NewsFeederDelegate
Browser(html
javascript)
Web
Services
Trasformation
Validation
BusinessFactory
Validation
Service
![Page 27: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/27.jpg)
Architecting: example
SEA Group
![Page 28: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/28.jpg)
Dynamic Description Behavioral models
SEA Group
![Page 29: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/29.jpg)
SA dynamics
The SA dynamics is expressed in terms of component interactions via connectors
•Labeled Transition Systems
•Automata
SEA Group
•Automata
•UML StateCharts, Sequence Diagrams, Activity Diagrams
•State Diagrams
•Message Sequence Charts
•…
![Page 30: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/30.jpg)
Customer Interface
Customer Process
Web Server
Cart Server
AN EXAMPLE : E-COMMERCE SYSTEM
SEA Group
Customer Server
Order Server
Catalog ServerDelivery Order
Process
SA Static Description
![Page 31: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/31.jpg)
CustomerInterface
Registered Customer
CustomerProcess CatalogServer
Catalog DB
BrowseCatalog
BrowseCatalog
ReadStatus
AN EXAMPLE : E-COMMERCE SYSTEM
SEA Group
SA Dynamic Description : Browse Catalogue Sequence Diagram
Catalog DBInvolved
Catalog Page
Output Page
Catalog Info
![Page 32: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/32.jpg)
AN EXAMPLE : E-COMMERCE SYSTEM
SEA Group
SA Dynamic Description : Place Order Sequence Diagram (success)
![Page 33: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/33.jpg)
AN EXAMPLE : E-COMMERCE SYSTEM
SEA Group
SA Dynamic Description : Place Order Sequence Diagram (empty cart)
![Page 34: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/34.jpg)
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
SEA Group
“Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data typesneeded to support the architecture and to satisfy the requirements.”
(Perry & Wolf 92)
![Page 35: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/35.jpg)
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
SEA Group
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)
![Page 36: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/36.jpg)
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.
SEA Group
→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.
![Page 37: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/37.jpg)
… 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
SEA Group
Localising safety-related features usually means more
communication so degraded performance.
![Page 38: Software Architecture: Introduction](https://reader034.vdocuments.us/reader034/viewer/2022052522/554d2c92b4c905ab268b506a/html5/thumbnails/38.jpg)
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
SEA Group
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.