software architecture styles families_research_gssi_nov2013
DESCRIPTION
This seminar lecture, provided at the Gran Sasso Science Institute, provides an overview on software architecture styles, product lines, and my researchTRANSCRIPT
Università degli Studi dell’Aquila
1
Software Architecture: styles, families, and research
Henry Muccini DISIM, University of L’Aquila
[email protected], @muccinihenry, henrymuccini.com
@Gran Sasso Science Instutitue (GSSI) – Nov. 2013
The Software Architecture is the earliest model of the whole software system created along the software lifecycle
A set of components and connectors communicating through interfacesA set of architecture design decisionsFocus on set of views and viewpointsWritten according to architectural styles
Soft
war
e A
rchi
tect
ure
Prescriptive vs descriptive
Prescriptive vs descriptive use of an architectural language
Descriptive = unconstraintPrescriptive = constraint
The Classical Style
The Gothic Style
The Californian Style
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
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
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
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
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
Let us take a look to some Architectural Styles…
10
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
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
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
The Blackboard Style
Blackboad style
1..*
Blackboard1..*
KS
Controller
The Blackboard StyleThis 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 capacity
Propertydifferent KSs may not communicate directly
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
Example: Facebook, GoogleDocs, …
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
3-Tier Client/Server Systems (example)
WHAT IS P2P?
3rd: SKYPE
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
Some References
[Garlan94] Exploiting Style in Architectural Design Environments, David Garlan, Robert Allen and John Ockerbloom. Proceedings of SIGSOFT '94 Symposium on the Foundations of Software Engineering, December 1994. [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.[Shaw96] Some Patterns for Software Architectures, M. Shaw, In John Viissides, James O. Coplien, and Norman L. Kerth, editors,
Pattern Languages of Program Design 2. Addison-Wesley, 1996.
22
The Software Architecture is the earliest model of the whole software system created along the software lifecycle
A brief Introduction to Product Lines (i.e., families of products)
Soft
war
e A
rchi
tect
ure
Product Lines and Product Families
Product Line:→ This term was introduced by the US community
Product Family:→ This term originated within a series of European
industrial-cooperation projects
Product LineDefinition:A software product line is a set of software intensivesystems sharing a common, managed set of features thatsatisfy the specific needs of a particular market segment or mission and that are developed from a common set ofcore assets in a prescribed way.
[P. Clements - L. M. Northrop, 2001]
(Software Engineering Institute, CMU)
The general idea…
The idea behind a system-family approach is to:
→ build a new system or application from a common set of assets…
─ A software asset might be a component, known requirements or design elements, models, artifacts that an engineer uses to build or modify a software product…
→ in the same line (i.e., domain)…─ pertaining to a general production line of a company
An example27
An example
• Car product line
Keywords > 1/3Variability:
→ Variability is the ability to change or customize a software system [Jan Bosch, 2002]
Variation point:→ A variation point refers to a delayed design decision, i.e., it
indicates a specific point in the development or deployment phase of a software system
→ The intention of designing a variation point into a system is to insert a variant (alternative) at a later phase in the lifecycle
Keywords > 2/3
Features: → Underlying def: a feature groups related requirements→ Features are an abstraction mechanism to express variability→ Cross-cutting features→ FODA: Feature Oriented Domain Analysis
Keywords > 3/3Levels:
→ Domain→ Application
Why Product Lines?
Feature Model33
Product Lines and Reuse
SPLC Conference35
The Software Architecture is the earliest model of the whole software system created along the software lifecycle
Our current research on Architecture Description Languages and Frameworks
Soft
war
e A
rchi
tect
ure
37
My
Rese
arch
ADL (according to ISO/IEC/IEEE 42010)
ADL = Architecture Description Language = any mode of expression used in an architecture description
38
Informal FormalUML-based
FormalPro: formal semantics computable
Cons: difficult to learn general lack of tools prolifetarion
UML-basedPro: not too difficult same notation for SA and design modeling
Cons: not a 100% fit tool investment
Informal Pro: of immediate use perfect for sketching communicative
Cons: ambiguous non automated
39
Main Finding: Introvert versus extrovert nature of architects role ADLs should combine features supporting both communication and
disciplined development.
But.. What Industry needs from Architectural Languages?I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang. IEEE TSE 2012 (pre-print)
But, what industry needs from ALs?
41
Industrial needs on ALs
Medvidovic et al. [12]
Woods and Hilliard [17]
Woods [18]
Pandey [19]
Hilliard and Rice [20]
Clements [21]
42
The study population
Participants = 48─ 25 interviews─ 23 on-line questionnaires
Localization: 15 countries→ USA (9), Sweden (6), Germany (5), Netherlands (5), Canada (4), Australia
(4), France (4), Argentina (2), UK (2), Austria (1), Belgium (1), Chile (1), Croatia (1), India (1), Switzerland (1), unknown (1)
Number of employees
18%
34%23%
25%A(0-99)
B(100-999)
C(1000-4999)
D(5000-above)
usefulness of ADL features in past and future projects
Challenges and Opportunities in ALs
C1: need of models interoperability multiple languages are used to describe the architecture of a
software system
C2: need of extending existing ALs
C3: need of creating, storing, re-using, views and Architecture Frameworks
C4: need of communicative and analytic AL
47
Our solutions
S1. DUALLY (dually.di.univaq.it)→An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012]
S2.ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]
S3.MEGAF (megaf.di.univaq.it)→A repository and a framework for creating your architecture description based on different viewpoints/views/concerns [ASE2010, WICSA/ECSA2012]
S4.WIKI & AL
48 DUALLY supports interoperability among ADLs. One model written in an ADL, can be then automatically transformed into another model conforming to a different ADL. Moreover, if a change is applied to one model in the transformation network, it is propagated to all the models.
C1. Need of models interoperability
•Use of different ALs to model or analyze different architectural aspects of a system
• Ongoing work we surveyed more than 120 Architecture Description Languages
49
Bridging the different descriptions to be kept consistent and coherent is of paramount relevance
DUALLY Motivating Example
Performance Model PM
Security Model
System
Performance analysis
Security analysis
?
?
Tech Foundation: Model Transformations and Weaving
Model 2 Model From design to analysis models From one view to another
Model 2 Code: Executable code Simulation code
53
Transformation
ADLa
ADLb
How to relate the notations?
1)Full-mesh topology:
n notations n (n-1)/2 weaving models
2)Star topology:
n notations n weav. modelsConsistency of models may be
verified in A0
Darwin/LTSA
ACME
AADL
SA UMLprofiles
OtherADLs
A0 Profile
Darwin/LTSA
ACME
AADLSA UMLprofiles
OtherADLs
Our solutions
S1. DUALLY (dually.di.univaq.it)→An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012]
S2. ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]
MEGAF (megaf.di.univaq.it)→A repository and a framework for creating your architecture description based on different viewpoints/views/concerns [ASE2010, WICSA/ECSA2012]
→S4.WIKI & AL
ByADL is Eclipse-based solution for extending and customizing architecture description languages (or, more in general, domain specific modeling languages) to adapt an ADL to better fit stakeholders’ concerns.
Extending ALs
ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]
current ADLs mostly fail to capture multiple (and varying) stakeholders concerns
extending and customizing existing ADLs w.r.t. to domain- & organization- specific concerns
PROBLEM
SOLUTION
Tech Foundation: Metamodel Composition59
Metamodels (and models) can be “composed” so to generate a new metamodel (model)
MMMMext
composition model
MMcomp
transformations
Our solutions
S1.DUALLY (dually.di.univaq.it)→An MDE interoperability framework for existing ADLs [TSE2010,SOSYM2012]
S2.ByADL (byadl.di.univaq.it)→An MDE framework for customizing existing ADLs [ICSE2010, ECSA2010]
S3.MEGAF (megaf.di.univaq.it)→A repository and a framework for creating your architecture description based on different viewpoints/views/concerns [ASE2010, WICSA/ECSA2012]
S4.WIKI & AL
MEGAF allows software architects to create new and re-usable architecture frameworks
Goal of this work
MEGAF is an MDE approach to create new architecture frameworks by means of mechanisms:i. to store, retrieve, and combine existing viewpoints, by properly
selecting and reusing models previously defined and resident in MEGAF;
ii. to define correspondences among views, viewpoints, stakeholders, system concerns and their elements;
iii. to enforce consistency and completeness checks based on defined architectural relationships and rules among elements.
To provide an infrastructure that enables to build reusable architecture frameworks
by treating views, viewpoints, concerns as first-class entities.
Tech. Foundation: Megamodeling
A megamodel is a kind of model in which elements could represent and/or refer to models or metamodels [Bézivin et al., OOPSLA/GPCE 2004]
A megamodel specifies properties and rules governing model construction, including multiple models and metamodels
→Models and metamodels are first-class entities→It offers also the possibility to specify relationships between them and to navigate them.
A megamodel can be seen as a map to find and link together all the involved models
Our solution
Darwin/FSP
ACME
AADL
xADL
SA UML profiles
other ADLs
pivotmetamodel
(A0)
Extended/customized ADL generated in byADL
BPMN
FTVP1
VP2St1
MK1
Composed AF generated in MEGAF
MEGAF: a model-driven infrastructure for building reusable and extensible architecture frameworks
DUALLy: an automated approach for ADLs interoperability
byADL: an approach to adapt and customize existing ADLs
Tool Support
MEGAFDUALLy
EMF
AM3 AMW ATL
AMMA
byADL other engines
MEGAF
megaf.di.univaq.it•Preliminary prototype in Eclipse, using megamodeling techniques
dually.di.univaq.it•Prototype in Eclipse, using model-driven engineering techniques
byadl.di.univaq.it•Prototype in Eclipse, using model-driven engineering techniques
Automation