Software Architecture: Introduction
-
Upload
henry-muccini -
Category
Documents
-
view
1.369 -
download
0
description
Transcript of Software Architecture: Introduction
L01: Intro to Software Architecture
Vittorio Cortellessa & Henry Muccini
DISIM Department, University of L’Aquila
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.
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
SEA Group
SEA Group
SEA Group
SEA Group
SEA Group
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
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.
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
→ …”
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
Example
SEA Group
A modeling language
(e.g. UML)
Software
modeled in
Process
Requirements
Drives
SEA Group
Software
Architecture
Implementation
modeled in
Traceability
Analysis
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.
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
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
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)
General workflow
SEA Group
Static Description
→Components
→Connectors
→Interfaces
SEA Group
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
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
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
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
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)
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
Architecting: example
SEA Group
Dynamic Description Behavioral models
SEA Group
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
•…
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
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
AN EXAMPLE : E-COMMERCE SYSTEM
SEA Group
SA Dynamic Description : Place Order Sequence Diagram (success)
AN EXAMPLE : E-COMMERCE SYSTEM
SEA Group
SA Dynamic Description : Place Order Sequence Diagram (empty cart)
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)
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)
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.
… 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.
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.