Date post: | 03-Jul-2015 |
Category: |
Technology |
Upload: | gran-sasso-science-institute |
View: | 615 times |
Download: | 2 times |
Ivano Malavolta
ARCHITECTURAL
LANGUAGES
Roadmap
Architectural languages
Multi-views architecting
Open research challenges
Some contents of this part of lecture extracted from Henry Muccini’s lecture on architectural languages at the University of L’Aquila (Italy)
Architectural languages
Historical View
25+ years back
I have to share with architects the architecture
solution I have in mind.
What shall I use?
software architect
Historical View
But architecting makes sense if we can run some automated analysis (and more)! academia
“Aside from providing clear and precise documentation, the primary purpose of specifications is to provide automated analysis of the document and to expose various kinds of problems that would otherwise go undetected” (PW1992)
“Fourth, an architectural system representation is often essential to the analysis and description of the highl-level properties of a complex system” (GS1994)
Historical View
core concerns
Comp&Con Spec
Interconnectio
n
Composition
Abstraction
Reusability
Configuration
Heterogeneity
Analysis
Components and connectors Distribution and configuration Expected behaviour Patterns, styles HW/SW Deployment
1st generation ALs
Darwin FSP
ACME
Rapide Wright
ACME
1st generation ALs Support components and connectors specification, their overall interconnection, composition, abstraction, reusability, configuration, heterogeneity, and analysis.
Examples of 1st generation ALs
Nenad Medvidovic, Eric M. Dashofy, Richard N. Taylor: Moving architectural description from under the technology lamppost. Information & Software Technology 49(1): 12-31 (2007)
Basic example: C2
Designed for systems that have a GUI • component-based
– written in any programming language – easily reused and substituted
• scalability – no assumption about how components communicate – components may be running in a distributed, heterogeneous
environment
• flexibility – architectures may be changed dynamically
The C2 communication rules • 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
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
The C2 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
The C2 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
Permitted
The C2 composition rule 2
2. The bottom of a component may be connected to the top of a single connector.
Comp1
NOT Permitted Comp1
Connector Bottom
Connector Top
Permitted
The C2 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
The C2composition 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
The C2 composition rule 5
5. Components can communicate only through connectors
Comp1
Comp2
NOT Permitted Permitted:
Following rule 4
Example: elevator system
ElevatorADT1
ElevatorPanel1
Scheduler
BuildingPanel
ElevatorADT2
ElevatorPanel2
ElevatorSynchronizer
ElevatorADT1
ElevatorPanel1
Scheduler
BuildingPanel
ElevatorADT2
ElevatorPanel2
ElevatorSynchronizer
C2 connector
C2 component
request
notification
comm. channel
Issues of 1st generation ALs
• Focus exclusively on technology • The broader context was completely missing
– Relation to system requirements – Constraints imposed by implementation platforms – Characteristics of application domains – Organizational structure and politics
• Often targeted at research environments – Awkward syntax and/or semantics – Modeling rigidity
• Limited and idiosyncratic analysis support • Inadequate tool support • UML
– Video killed the radio star...
Historical View
core concerns
Config. manage
ment
Distribution
Product lines
Styles Different domains
…
…
2nd generation ALs
UML 2.0 AADL
Koala xADL 2.0
ACME
2nd generation Als Modeling support for: configuration management, distribution, and product lines. Structural specifications integrated with behavior with the introduction of many formalisms such as pre- and post-conditions, process algebras, statecharts, POSets, CSP, π-calculus
Examples of 2nd generation ALs
Nenad Medvidovic, Eric M. Dashofy, Richard N. Taylor: Moving architectural description from under the technology lamppost. Information & Software Technology 49(1): 12-31 (2007)
• UML 2.0 ß UML 1.x • AADL ß MetaH
– we will have a dedicated lecture about it
• Koala ß Darwin ß Conic
UML 2.0
• De facto standard software design language – Developed by OMG
• A “Swiss Army Knife” of notations • Has a number of architectural constructs
UML 2.0
Reasonably applicable to software architectures…
https://code.google.com/p/staff/wiki/SoaApplicationStruct
But…
• Meaningful Modeling: What’s the Semantics of “Semantics”? http://goo.gl/mbTloA [HarelRumpe04]
“In its current form, the Object Management Group’s documents do not offer a rigorous definition of UML’s true semantics, not even of the semantic domain. Rather, they concentrate on the abstract syntax, intermixed with informal natural language discussions of what the semantics should be. These discussions certainly contain much interesting information on the semantics, but they are a far cry from what developers, as well as tool vendors, really need. As recent research shows, they still lack many clarifying details and contain many inconsistencies. ”
• The State of Practice in Model-Driven Engineering http://goo.gl/h5YRtv [WHR14]
“UML 2.0, for example, a major revision of the UML standard, didn’t reflect the literature on
empirical studies of software modeling or software design studies. Consequently, current approaches force developers and organizations to operate in a way that fits the approach instead of making the approach fit the people. ”
Less formal and much more ambiguous than existing ALs
AADL
• Architecture Analysis and Design Language – initially stood for “Avionics ADL”
• Primarily textual • Very detailed
– An AADL component runs on a processor, which runs one or more processes, each of which contains one or more threads of control, all of which can receive instructions through in ports and send data through out ports over a bus...
• Primary focus – embedded, real-time, hybrid systems
AADL model
Ivano Malavolta, Henry Muccini, Patrizio Pelliccione: Integrating AADL within a Multi-domain Modeling Framework. ICECCS 2009: 341-346
Koala
• Developed at Philips – in collaboration with Imperial College London
• Used in the consumer electronics domain – allows to specify hierarchical architectures – makes a distinction between component types and instances – allows to construct configurations by instantiating components and
connectors and explicitly models optional interfaces
• Both graphical and textual • Primary focus – management of product populations
– Modeling – Analysis – Implementation generation – Deployment
Koala model
provides interface
required interface
Component type definition
Component instances
subcomponent
module switch
interface
Real Koala model
From a different perspective…
Pro: .formal semantics .computable
Cons: .difficult to learn .general lack of industrial tools .prolifetarion
Pro: .not too difficult .same notation for SA and design modeling
Cons: .not a 100% fit .tool investment
Pro: .of immediate use .perfect for sketching .communicative
Cons: .Ambiguous .not automated
Today
AL Name
AADL
ABC/ADL
ACME
ADAGE
ADLARS
ADML
AESOP
ArchJava
ArchWare
ArchiTRIO
ARTECH
C2
C2 AML
C2 SADEL
CommUnity
DAOP ADL
DARWIN
DICAM
EAST ADL
EXPRESSION
GEN VOCA
HMDES
ISDL
JACAL
KOALA
LILEANNA
AL Name
LISA
LITTLE JIL
MAE
MADL
MAFIIA
MAUDE
M(énage / xADL
META H
MIMOLA
MODE CHART
PALANTIR
PRISMA
RADL
RAPIDE
RESOLVE
SADL
SATURN
SKWYRL
UDL/i
UNICON
WEAVES
WRIGHT
WSDL
xArch / xAcme
xArch / xADL
xC2
100+ ALs
(better to say, languages that consider themselves to be ALs)
100+ ALs? http://www.di.univaq.it/malavolta/al/
Why So Many ALs?
There are many reasons for having many ALs:
• Different ALs for different “stakeholder concerns” – Different domains – Different analysis – Different viewpoints
• Some of them are really similar, with just small semantic or syntactic differences
– Many are just prototipal languages, research-specific
Issues (1/2)
Proliferation of languages for (SA) description § without a clear understanding of their merits and limitations
Tens of ALs, characterized by slightly different conceptual architectural elements, different syntax, or semantics
§ Focussing on a generic or a specific operational domain
Some support automated analysis
Issues (2/2)
An IDEAL and general purpose AL is NOT likely to exist
§ Stakeholder concerns are various, ever evolving, and adapting to changing system requirements
§ Difficult to capture all such concerns with a single, narrowly focused notation.
Architectural languages must be able to focus on what is needed by the stakeholders involved in the architecting
process.
Two examples of modern ALs
• Diasuite
– https://dl.dropboxusercontent.com/u/3558185/11_DIASUITE.pdf
• Evolve – https://dl.dropboxusercontent.com/u/3558185/05_EVOLVE.pdf
Multi-views architecting
Some contents of this part of lecture extracted from Henry Muccini’s lecture on architectural views at the University of L’Aquila (Italy)
Views and Viewpoints
Architectural views
Typically, two different views are used:
User1
Router Server
Timer
AlarmUR AlarmRS (c)Check1
Nofunc
Clock
AckSR (c)
AckRU1
User2
AlarmUR1
AlarmUR2
Check2
Check
AckRU2
0 1 2
3
4
5
Structural Spec. Behavioral Spec.
- Component-based languages - UML notations
- Posets, pre-post conditions - Process algebras - Labeled transition systems, IO Automata, Buchi automata - Statechart, UML state machines
Stakeholder concerns à multiple views Using multiple views has become standard practice in industry
– IEEE Std 1471 (2000) -> … -> ISO/IEC/IEEE 42010 (2011) – Based on a survey we conducted with 48 practitioners about
the usage of architectural languages in industry – 85% uses multiple views
ISO/IEC/IEEE 42010: 2011
Architecture description
Architecture Description is the practice of expressing architectures (ISO/IEC 42010) “The practices of recording software, system and enterprise architectures so that architectures can be understood, documented, analysed and realized.” “Architecture descriptions are created by architects and used by architects and other stakeholders throughout all stages of a system’s life cycle, from development through operation and maintenance.”
Architecture description mechanisms
Architecture Viewpoints • define the contents of each architecture view
Architecture Description Languages (ADLs) • any mode of expression used in an architecture description. • ADL provides model kinds selected to frame one or more
concerns
Architecture Frameworks • coordinated set of viewpoints for use within a particular
stakeholder community or domain of application (e.g., Kruchten’s 4+1, GERAM, TOGAF, MODAF)
ISO/IEC/IEEE 42010: 2011 Concerns functionality, feasibility, usage,
structure, behavior, performance, resource utilization, security, cost,
data accessibility, privacy, compliance to regulation,
business goals and strategies
Stakeholders Developer Architect End-user
Tester Project manager
Stakeholder concerns
• the nature of the system • project-specific constraints • organizational constraints • the application domain • …
Stakeholders concerns can vary tremendously (and change over time), depending on:
Example: BusOnAir
BusOnAir stakeholders and concerns
ISO/IEC/IEEE 42010: 2011
Views and viewpoints […] “a viewpoint is a way of looking at a system; a view is what you see” “A viewpoint defines the conventions (such as notations, languages and types of models) for constructing a certain kind of view” ”viewpoint refers to the conventions for representing an architecture relative to one set of concerns.” “A view is the result of applying a viewpoint to a particular system of interest” “viewpoints as first-class entities of architecture descriptions.”
view : viewpoint = program : programming language
BusOnAir viewpoints
BusOnAir architectural languages
BusOnAir architectural languages: DiaSpec
Declarative language for describing applications that orchestrate entities interacting with an environment Supports code generation and interactive simulation
BusOnAir architectural languages: UML
UML is a good starting point for defining the behaviour of the system More commonky known à used for sharing architectural knowledge among stakeholders Focus on: • component diagrams • state machine diagrams
BusOnAir architectural languages: FSP
FSP = Finite State Process Formal language Focus on the behaviour of concurrent systems Allows us to perform property checks and deadlock freedom analysis
BusOnAir architectural languages: REST
Domain-specific language for specifying services according to the REST architectural style Deliberate choice: interface between the Bus+mobile app to the central server as a set of RESTful web service
ISO/IEC/IEEE 42010: 2011
BusOnAir correspondence rules • COMP_REST
– each resource defined in a REST model in the WebServices view must be associated to at least a UML component in the System view
• UML_UML – in the System view, each UML component must contain a UML
state machine describing its behaviour
• UML_FSP – in the Behaviour view, for each UML state machine in the System
view there must be a process definition with the same name in the FSP model
• DIASUITECOMP_UML – in the System view, for each generic component in the DiaSpec
model there must be a UML component with the same name
Architecture Framework (AF)
Coordinated set of viewpoints for use within a particular stakeholder
community or domain of application (e.g., GERAM, TOGAF, MODAF);
BusOnAir architectural framework
BusOnAir views
BusOnAir Diaspec model
BusOnAir UML component diagram
BusOnAir UML state diagram (Trip Manager)
BusOnAir FSP (Trip Manager)
BusOnAir FSP (in the tool)
BusOnAir REST model
BusOnAir summary 1
Definition of Stakeholders and
Concerns
Definition of Viewpoints
Import of the needed ADLs
Definition of Correspondence
Rules
Definition of Architecture Views
Architecture Description
Architecture Framework
Conformance checks with respect to the
framework
BusOnAir summary 2
Model the Bus System with DiaSpec
Get a UMLCC model of the
BusOnAir system
Define behaviour of the BusOnAir system in UMLCC
Get an FSP model of the
BusOnAir system
Analyse the FSP model
Define a RESTLANG model of the BusOnAir services
System view Behaviour view
WebServices view
1
4
5
6
7
8
Manual step
Automatic step
Logical View
End-user
Functionality
Implementation (Development) View
Programmers Software management
Process View
Performance Scalability Throughput
System integrators
Deployment View
Conceptual Physical
Use Case View
Object Model of Design
Static Organization of the Software
Concurrency and Synchronization
Software Mapping To Hw System engineering
System topology Delivery, installation Communication
Kruchten’s 4+1 views
Open research challenges on software architecture
Refresh 1
Example: SA research questions
FEASIBILITY
CHARACTERIZATION
METHOD/MEANS
GENERALIZATION
DISCRIMINATION
Is it possible to automatically generate code from an architectural specification?
What are the important concepts for modeling software architectures?
How can we exploit domain knowledge to improve software development?
What patterns capture and explain a significant set of architectural constructs?
How can a designer make tradeoff choices among architectural alternatives?
Refresh 2
Example: SA research results QUALITATIVE & DESCRIPTIVE MODELS
TECHNIQUES
SYSTEM EMPIRICAL MODELS ANALYTIC MODELS
Early architectural models Architectural patterns Domain-specific software architectures UML to support object-oriented design
Architectural languages Communication metrics as indicator of impact on project complexity Formal specification of higher-level architecture for simulation
Refresh 3
Example: SA research validation PERSUASION
IMPLEMENTATION
EVALUATION ANALYSIS
Formal model Empirical model
EXPERIENCE
Qualitative model Decision criteria Empirical model
Early architectural models
Early architectural languages
Taxonomies, performance improvement
Formal schedulability analysis User interface structure
Architectural patterns Domain-specific architectures Communication and project complexity
Open research challenges
• Reconciling SA for analysis and communication – how to manage formal specifications that can be also used for
communication?
Documents for communications Analytic artefacts vs
First prototype…
Software architects
continuous alignment
Wiki-based knowledge
base
m1 m2 mn
access and record AKs
reason on the architecture design
create, access, and tune models
...
Open research challenges • Support for multiple views
– consistency and completeness checking
Open research challenges
• Flexible architectural frameworks – support for combining different views, viewpoints, languages, etc.
Architectural Assets Repository
Viewpoints
Stakeholders
Model Kinds System Concerns Architectural languages
Correspondences
Architecture Description
B
Architecture Description
C
Architecture Description
A
Architecture Framework
Open research challenges
• Traceability between requirements, design decisions, and architecture
Other main research challenges
• Fluid architectures • for example, think about robot teams working together
– support (self-) adaptation and changes – trade-off with qualities (e.g., safety and performance)
• End-user architecting – in the future end-users will assemble components at wish – which architectural environment to show them?
• Example: Yahoo! Pipes
– Task oriented interfaces? • Example: FLYAQ
• Architectural languages for cyber-physical systems – Must include physical elements
and manage large-scale networks
What this lecture means to you?
Software Architecture
what is essential about the system w.r.t. some specific concern
Why software architecture?
Components and connectors Distribution and configuration Expected behaviour Patterns, styles HW/SW Deployment Extra-functional properties
scalability, performance, testability, security
Modern software architecture
Focus on views and viewpoints looking at stakeholders and their concerns
Suggested readings 1. Patricia Lago, Ivano Malavolta, Henry Muccini, Patrizio Pelliccione,
Antony Tang (2013). What Industry Needs from Architectural Languages: A Survey. IEEE Transactions on Software Engineering, 39(6), pp. 869-891.
2. ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering -- Architecture description". Retrieved 2012-09-12.
3. Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
4. Ivano Malavolta (2012). Software Architecture Modeling by Reuse, Composition and Customization. PhD Thesis. University of L'Aquila, Computer Science Department. http://goo.gl/iZEVbH
References
Contact Ivano Malavolta |
Post-doc researcher Gran Sasso Science Institute
iivanoo
www.ivanomalavolta.com