This is a lecture about Software Architecture Styles, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
1. Università degli Studi dell’Aquila
L04: SA Styles
Henry Muccini
Dipartimento di Ingegneria, Scienze dell’Informazione e
Matematica, University of L’Aquila
henry.muccini@univaq.it, @henrymuccini
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.
Henry Muccini
3. Intro to SA Intro to Software Testing
SA Case study 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
5. “A set of design rules that identify the kinds of components
and connectors that may be used to compose a system
or subsystem, together with local or global constraints on
the way the composition is done” (Shaw & Clements, 1996)
A set of constraints you put on your development to elicit desirable
IMP properties from your software architecture.
Topological
Behavioral
Communication-oriented
etc. etc.
8. Many similarities between patterns and styles
But they have come from different communities
Differences
Architectural Styles Design Patterns
Few Many
Large-scale system Localized, small-scale
organization design solutions
9.
10. 1. The top of a component may be connected to the bottom
of a single connector.
Comp1 NOT Permitted
Connector Top
Connector Bottom
Comp1
11. 2. The bottom of a component may be connected to the top
of a single connector.
Comp1
Comp1
NOT Permitted
Connector Top
Connector Bottom
12. 3. There is no bound on the number of components or
connectors that may be attached to a single connector.
Permitted
Comp1 Comp2 Comp3
13. 4. When two connectors are attached to each other, it must
be from the bottom of one to the top of the other.
Connector Top
Connector Bottom Permitted
Connector Top
Connector Top
Connector Bottom
Connector Bottom
Connector Top Connector Top
Connector Bottom Connector Bottom
NOT Permitted
14. 5. Components can communicate only through
connectors
Comp1
Permitted:
NOT Permitted
Following rule 4
Comp2
15. The communication between components and connectors is
achieved solely exchanging messages
The communication is based on notifications and requests
Both component top domain and bottom domain can notify or
request messages
Requests Notifications
Top
Comp2
Bottom Comp2 receives a request Comp2 sends a notification
Top Comp1 sends a request Comp1 receives a notification
Comp1
Bottom Comp1 receives a request Comp1 sends a notification
16. ADL TOOLS DATE SUPPORT FOR ARCHITECTURAL STYLES
Descrizione di proprietà ed interfacce relative a componenti
AADL Osate 2001 +
configurazioni di intercambio XML/XMI
ACME Acme Studio+Armani 1995 Interscambio architetturale prevalentemente a livello strutturale
ArchiTrio Trident 1990 Unisce lo stile delle notazioni standard UML 2.0 ai formalismi logico-temporali di TRIO
ArchJava AcmeArchJava 2002 Supporta uno stile di programmazione flessibile orientato agli oggetti
CommUnity
CommUnity 2002 Linguaggio che si rispecchia negli stili UNITY ed IP
WorkBench
DARWIN LTSA-WS + SAA 1991 Architetture di sistemi distribuiti il cui dinamismo è guidato da un supporto severo e formale
EAST-ADL AutoFocus2 2001/2004 La descrizione degli elementi del linguaggio è suddivisa in sei parti (domini)
Ménage/xAD
ArchStudio+Ménage 2000 Introduce la distinzione tra prescription e description della SA
L
PRISMA PrismaCase 2002 Definizione di elementi architetturali a due diversi livelli di astrazione
xArch/xAcm Versione recente del linguaggio Acme che ne mantiene le caratteristiche di base, specificate
Acme Studio 2001
e però in XML
xArch/xADL ArchStudio+Apigen 2000 Introduce la distinzione tra prescription e description della SA
17. C2 Style
Pipes and filters
Layered systems
Blackboard style
Implicit Invocation
Idealized FT Component Model
_________________________________________________
Peer to peer
Hypertext style (!)
MVC
RUP
20. The Layered System Style
A layered system is organized hierarchically, each layer providing service
to the layer above and below
Components
Connectors
Procedure calls or system calls
Stylistic invariants
21. Application Application
Presentation Presentation
Session Session
Transport Transport
Network Network Network Network
Data Link Data Link Data Link Data Link
Physical Physical Physical Physical
26. The Blackboard Style
This style is characterized by a central data structure and a collection of components
operating on the central data store
The Blackboard is characterized by three main types of components
(Corkill, 1991):
Connector
Property
30. Web
Servers
Browser Clients
www.sitoweb.it
Netscape
Navigator
HTTP
www.website.com
(asynchronous RPC)
Microsoft
IE
www.laudaweb.it
• Load balancing
• Cooperative caching
• Use of geographic distribution of the server machines.
31. Client/Server Systems
Client/Server systems are the most common specialization (restriction) of
the peer-to-peer style
One component is a server offering a service
The other components are clients using the service
Server implementation is transparent but can be centralized or distributed,
single-threaded or multi-threaded
33. 3-Tier Client/Server Systems
3-Tier Client/Server systems are a common class of distributed business
systems
First tier: Client (user interface) tier
Second (middle, “business logic”) tier: Servers acting as “business objects”,
encapsulating abstract, integrated models of multiple, disparate data
sources
Third (back-end, database) tier: Legacy business applications providing data
services
37. Advantages
Disadvantages
Distributed state
Potential for deadlock, starvation, race conditions, service outages
Data marshalling and unmarshalling
Proxies and stubs for RPC
Legacy wrappers
38. Program unit (object, process, block, module, method,
class, component, etc.)
Service Request Reply Interface Exception Failure Exception
Local Exception
Normal Processing Error Processing
Return to normal
Service Request Reply Interface Exception Failure Exception
39. •The normal part implements the component’s normal services
•The exceptional part implements the responses of the component to exceptional
situations, by means of exception-handling techniques.
•When the normal behavior of a component raises an exception (local exception) its
exception handling part is automatically invoked. If the exception is successfully
handled the component resumes its normal behavior, otherwise an external
exception is signalled.
•External exceptions are signalled to the enclosing context when the component
realizes that is not able to provide the service.