Upload
henry-muccini
View
548
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Advanced Software Engineering course (http://lore.com/Advanced-Software-Engineering-Univaq/) This lecture is about software architecture styles
Citation preview
1
Advanced Software EngineeringURL: http://lore.com/Advanced-Software-Engineering-Univaq/
DISIMDep.nt of Information Engineering, Computer Science and MathematicsUniversity of L’Aquila, Italy
SA Styles, Patterns, and Tactics
Henry Muccini DISIM, University of L’Aquila [email protected],
@muccinihenry
SEA Group
Copyright Notice
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
A brief summary
SEA Group
SA STYLES
SEA Group
Prescriptive vs descriptive
Prescriptive vs descriptive use of an architectural language
Descriptive = unconstraintPrescriptive = constraint
SEA Group
Architectural Styles
“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 properties from your software architecture.
Constraints may be:TopologicalBehavioralCommunication-orientedetc. etc.
IMP
SEA Group
Architectural Style properties
Architectural styles typically determine four kinds of properties [AAG93]:1. They provide a vocabulary of design elements – component and connector
types such as pipes, filters, clients, servers, parsers, databases etc.2. They define a set of configuration rules – or topological constraints – that
determine the permitted compositions of those elements. 3. They define a semantic interpretation, whereby compositions of design
elements, suitably constrained by the configuration rules, have well-defined meanings.
4. They define analyses that can be performed on systems built in that style. Examples include schedulability analysis for a style oriented toward real-time processing [Ves94] and deadlock detection for client-server message passing [JC94].
IMP
SEA Group
The Classical Style
The Gothic Style
The Californian Style
SEA Group
Architectural Styles vs. Design Patterns
Many similarities between patterns and stylesGoal: packaged engineering experienceFormulation: organization and interaction among “key” components
But they have come from different communitiesMany architectural styles have been well known for a long time in the
software engineering communityPatterns are a relatively recent development in OO design
Differences
Architectural Styles Design Patterns
Few Many
Large-scale system organization
Localized, small-scale design solutions
SEA Group
The C2 style Composition Rules
1. The top of a component may be connected to the bottom of a single connector.
2. The bottom of a component may be connected to the top of a single connector.
3. There is no bound on the number of components or connectors that may be attached to a single connector.
4. When two connectors are attached to each other, it must be from the bottom of one to the top of the other.
5. Components can communicate only through connectors
SEA Group
The C2 style Communication Rules
The communication between components and connectors is achieved solely exchanging messagesThe communication is based on notifications and requestsBoth component top domain and bottom domain can notify or request messages
Comp1
Comp2
Top
Top
Bottom
Bottom Comp1 receives a request
Comp1 sends a request
Comp2 receives a request Comp2 sends a notification
Comp1 receives a notification
Comp1 sends a notification
Requests Notifications
SEA Group
Example: Elevator System in the C2 style
ElevatorADT1
ElevatorPanel1
Scheduler
BuildingPanel
ElevatorADT2
ElevatorPanel2
ElevatorSynchronizer
ElevatorADT1
ElevatorPanel1
Scheduler
BuildingPanel
ElevatorADT2
ElevatorPanel2
ElevatorSynchronizer
C2 connector
C2 component
request
notification
comm. channel
SEA Group
MORE ABOUT THE C2 STYLE
SEA Group
The C2 style Composition Rule 1
1. The top of a component may be connected to the bottom of
a single connector.
Comp1 NOT Permitted
Comp1
Connector Bottom
Connector Top
SEA Group
The C2 style Composition Rule 2
2. The bottom of a component may be connected to the top of a single connector.
Comp1
NOT PermittedComp1
Connector Bottom
Connector Top
SEA Group
The C2 style Composition Rule 3
3. There is no bound on the number of components or connectors that may be attached to a single connector.
Comp1 Comp2 Comp3
Permitted
SEA Group
The C2 style Composition Rule 4
4. When two connectors are attached to each other, it must be from the bottom of one to the top of the other.
Connector Bottom
Connector Top
Connector Bottom
Connector Top
Connector Bottom
Connector Top
Permitted
Connector Bottom
Connector Top
Connector Bottom
Connector Top
NOT Permitted
SEA Group
The C2 style Composition Rule 5
5. Components can communicate only through connectors
Comp1
Comp2
NOT PermittedPermitted:
Following rule 4
SEA Group
ADL and stylesADL TOOLS DATE SUPPORT FOR ARCHITECTURAL STYLES
AADL Osate 2001
Descrizione di proprietà ed interfacce relative a componenti
+
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 WorkBench
2002 Linguaggio che si rispecchia negli stili UNITY ed IP
DARWIN LTSA-WS + SAA 1991 Architetture di sistemi distribuiti il cui dinamismo è guidato da un supporto severo e formale
EAST-ADL AutoFocus22001/200
4 La descrizione degli elementi del linguaggio è suddivisa in sei parti (domini)
Ménage/xADL
ArchStudio+Ménage 2000 Introduce la distinzione tra prescription e description della SA
PRISMA PrismaCase 2002 Definizione di elementi architetturali a due diversi livelli di astrazione
xArch/xAcme Acme Studio 2001
Versione recente del linguaggio Acme che ne mantiene le caratteristiche di base, specificate però in XML
xArch/xADL ArchStudio+Apigen 2000 Introduce la distinzione tra prescription e description della SA
SEA Group
SOME OF THE MOST KNOWN STYLES
SEA Group
Common Software Architectural Styles (Shaw & Garlan 96) + SA In
PracticeC2 StylePipes and filtersLayered systemsBlackboard styleImplicit InvocationIdealized FT Component ModelPeer to peer
Client ServerThree tierThird Generation Peer to peer
Hypertext style (!)MVCRUP
SEA Group
Styles by Example
For each style, we will identify:ComponentsConnectors
and
AdvantagesDisadvantages
SEA Group
Layered Style (Virtual Machine Example)
Java Virtual Machine
Processor
Operating
System
Java
Virtual Machine
Java
Application
(Virtual Machine Style)
SEA Group
The Layered System Style
A layered system is organized hierarchically, each layer providing service to the layer above and below
ComponentsPrograms or subprograms deployed in a layer
ConnectorsProtocols
Procedure calls or system calls
Stylistic invariantsEach layer provides a service only to the immediate layer “above” (at the
next higher level of abstraction) and uses the service only of the immediate layer “below” (at the next lower level of abstraction)
SEA Group
Layered System Example: OSI Protocol Stack
Application
Presentation
Session
Transport
Network
Data Link
Physical
Application
Presentation
Session
Transport
Network
Data Link
Physical
Network
Data Link
Physical
Network
Data Link
Physical
SEA Group
POPEYE Project
SEA Group
Layered System Advantages and Disadvantages
AdvantagesDecomposability: Effective separation of concerns and different level of
abstractionsMaintainability: Changes that do not affect layer interfaces are easy to makeAdaptability/Portability: Can replace inner layers as long as interfaces remain
the same Understandability: Strict set of dependencies allow you to ignore outer layers
DisadvantagesNot all systems are easily structured in a layered fashionPerformance degrades with too many layersCan be difficult to cleanly assign functionality to the “right” layer
SEA Group
Example
1..11..1
1..11..1
1..1
1..1
1..1
1..11..11..1
1..11..1
1..21..1
1..21..1
XCONN1
XCONN
…
GLOBAL
SHELF
PERIPHERAL
XCONN2
XCONN3
1..11..1
1..11..1
1..1
1..1
1..1
1..11..11..1
1..11..1
1..21..1
1..21..1
XCONN1
XCONN
…
XCONN2
XCONN3
SEA Group
The Blackboard Style
Blackboad style
1..*
Blackboard1..*
KS
Controller
SEA Group
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):
the knowledge sources (KS), which are independent modules that contain the knowledge needed to solve the problem,
the blackboard, which is a global repository containing input data and partial solutions, and
the controller, which is responsible for managing the course of problem solving (e.g. coordinating the different KS).
ConnectorBlackboard: shared data repository, possibly with finite capacityPropertydifferent KSs may not communicate directly
SEA Group
Blackboard Advantages and Disadvantages
AdvantagesSimplicity: Only one connector (the blackboard) that
everyone usesEvolvability: New types of components can be added easily
DisadvantagesBlackboard becomes a bottleneck with too many clients
SEA Group
Example: Facebook, GoogleDocs, …
SEA Group
Distributed Peer-to-Peer Systems
ComponentsIndependently developed objects and programs offering public operations or
services
ConnectorsRemote procedure call (RPC) over computer networks
ConfigurationsTransient or persistent connections between cooperating components
Computational modelSynchronous or asynchronous invocation of operations or services
SEA Group
Client/Server Style (Example: The World Wide Web)
HTTP(asynchronous RPC)
www.website.com
NetscapeNavigator
MicrosoftIE
Browser Clients
WebServers
• Load balancing • Cooperative caching• Use of geographic distribution of the server machines.
www.sitoweb.it
www.laudaweb.it
SEA Group
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
Single interface point with physically distributed implementationDynamic, transparent selection from among multiple interface points
SEA Group
3-Tier Client/Server Systems (example)
SEA Group
3-Tier Client/Server Systems
3-Tier Client/Server systems are a common class of distributed business systems
Increasing competition requires business to find new ways of exploiting legacy information assets
First tier: Client (user interface) tierPresentation logic
Second (middle, “business logic”) tier: Servers acting as “business objects”, encapsulating abstract, integrated models of multiple, disparate data sources
Computation
Third (back-end, database) tier: Legacy business applications providing data services
Database
SEA Group
WHAT IS P2P?
There are 3 types of P2P System:
1st: Napster
SEA Group
WHAT IS P2P?
2nd: Gnutella
SEA Group
Gnutella P2P (from the SAInPractice book)
SEA Group
WHAT IS P2P?
3rd: SKYPE
SEA Group
Peer-to-Peer Advantages and Disadvantages
AdvantagesInteroperability A natural high-level architectural style for heterogeneous
distributed systemsReusability: Especially with regard to legacy applicationsScalability: Powerful enough server tiers can accommodate many clientsDistributability: Components communicate over a network, generally
DisadvantagesVisibility, Maintainability: Difficult to analyze and debug
Distributed statePotential for deadlock, starvation, race conditions, service outages
Simplicity: Require sophisticated interoperability mechanismsData marshalling and unmarshallingProxies and stubs for RPCLegacy wrappers
SEA Group
SOA Style
image from Google Images
SEA Group
Normal Processing
Idealized FT Component Model
Error Processing
Local Exception
Return to normal
Service Request
Service Request Reply
Reply
Interface Exception Failure Exception
Failure ExceptionInterface Exception
Program unit (object, process, block, module, method, class, component, etc.)
SEA Group
Idealized FT Component Model
• 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.
SEA Group
Idealized FT Component Model
Example
SEA Group
Model View Controller
MVC:Model: data and business logicView: content Controller: applications coordinator
Input --> Processing --> OutputController --> Model --> View
SEA Group
Model, View and Controller
Model The model represents enterprise data and the business rules that govern access to and updates of this
data.This is the domain-specific representation of the information on which the application operates. It maps requests coming from clients into operations over the model
View The view renders the contents of a model. It accesses enterprise data through the model and specifies
how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. MVC is often seen in web applications, where the view is the HTML page and the code which gathers
dynamic data for the page.
Controller The controller translates interactions with the view into actions to be performed by the model.This responds to events, typically user actions, and invokes changes on the model and perhaps the view. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web
application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
SEA Group
MVCFig 13.7, SA in Practice book
1..*
1
1..*
SEA Group
System usage scenario 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
Styles by Example
SEA Group
Tactics
Patterns are constructed from different tactics
A tactic promotes a specific quality attribute
Tactics can be used to enhance existing patterns
SEA Group
What you shall have learned
You shall:Know at least those styles discussed during this lecture
Layered systemsBlackboard stylePeer to peer…
Be able to apply the style to your architectural designBe able to understand pros and cons of styles
SEA Group
Readings
Software Architecture in Practice, chapter 13
[SC97] A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems, M. Shaw and P. Clements, In Proc. COMPSAC97, 21st Int'l Computer Software and Applications Conference, August 1997, pp. 6-13.