Upload
ivano-malavolta
View
523
Download
0
Embed Size (px)
Citation preview
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 makessense if we can run some
automatedanalysis (and more)!academia
“Aside from providing clear and precisedocumentation, the primary purpose ofspecifications is to provide automatedanalysis of the document and to exposevarious kinds of problems that wouldotherwise go undetected” (PW1992)
“Fourth, an architectural systemrepresentation is often essentialto the analysis and description ofthe highl-level properties of acomplex system” (GS1994)
Historical View
core concerns
Comp&Con
SpecInterconnectio
n
Composition
Abstraction
Reusability
Configuration
Heterogeneity
Analysis
Components and connectorsDistribution and configurationExpected behaviourPatterns, stylesHW/SW Deployment
1st generation ALs
Darwin FSP
ACME
Rapide Wright
ACME
1st generation ALsSupport 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
C2 composition rules
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
C2 composition rules
2. The bottom of a component may be connected to the top of a single connector.
Comp1
NOT PermittedComp1
Connector Bottom
Connector Top
Permitted
C2 composition rules
3. There is no bound on the number of components or connectors that may be attached to a single connector.
Comp1 Comp2 Comp3
Permitted
C2 composition rules
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
C2 composition rules
5. Components can communicate only through connectors
Comp1
Comp2
NOT PermittedPermitted:
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
• Inadequate tool support • UML
– Video killed the radio star...
Historical View
core concerns
Config. managem
ent
Distribution
Product lines
StylesDifferent domains
…
…
2nd generation ALs
UML 2.0AADL
Koala xADL 2.0
ACME
2nd generation ALsModeling 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
• 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 – real-time embedded 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
Koalamodel
provides interface
required interface
Component type definition
Component instances
subcomponent
module switch
interface
From a different perspective…
FormalPro:.formal semantics.computable
Cons:.difficult to learn.general lack of industry-ready tools
UML-basedPro:.trained people.same notation for SA and design modeling
Cons:.not a 100% fit.complexity
InformalPro:.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)
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
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
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 artifactsvs
First prototype…
Software architects
continuousalignment
Wiki-basedknowledge
base
m1 m2 mn
access and record AKs
reason on the architecture design
create, access, and tunemodels
...
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
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 (http://www.flyaq.it)
What this lecture means to you?
Software Architecturewhat 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 propertiesscalability, performance, testability, security
Modern software architecture
Focus on views and viewpoints
looking at stakeholders and their concerns
Suggested readings1. Patricia Lago, Ivano Malavolta, Henry Muccini, Patrizio Pelliccione,
Antony Tang (2013). What Industry Needs from ArchitecturalLanguages: A Survey. IEEE Transactions on Software Engineering,39(6), pp. 869-891.
2. ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and softwareengineering -- 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
ContactIvano Malavolta |
Post-doc researcherGran Sasso Science Institute
iivanoo
www.ivanomalavolta.com