Download presentation
Presentation is loading. Please wait.
Published byKory Hood Modified over 8 years ago
1
Architecture Description Languages State of the Art on Object- Oriented Software Architecture
2
2 Overview What is an ADL ADL Survey ADL Classification and Comparison Framework ACME Conclusion
3
3 Before ADL Informal Architecture Descriptions fail to answer : What are components? What do components do? How do they behave? What other components do they rely on? What do connections mean? What mechanisms are used to fulfill these relations? A formal approach : ADL
4
4 What is an ADL? Informal definition A formal language to represent the architecture of a software-intensive system Architecture Components that comprise a system Behavioral specifications for those components Patterns and mechanisms of interactions between components
5
5 Advantages of a Formal Architecture Representation Maintenance Consulting Authorative Transfer to other projects
6
6 ADL’s different from other languages? Requirements Languages Programming Languages Modeling Languages
7
7 ADL vs Requirement Language Differ RL describes problem spaces ADL is rooted in solution space RL as ADL Requirements divided into behavioral chunks for ease of presentation Languages for representing requirements are well suited for representing architectural components Drawback Easy to produce artifacts that not correspond to an architectural view of the system
8
8 ADL vs Programming Language Differ PL binds all architectural abstractions to specific point solutions ADL suppress or vary such binding PL as ADL PL’s provide architecture-level views of the system Drawback No architecture-level analytic capabilities No insight in how components are linked together
9
9 ADL vs Modeling Language Differ ML more concerned with behavior of the whole (vs parts) ADL concentrates on representation of components ML as ADL Allows representation of cooperating components Represents architectures reasonably well
10
10 ADL requirements Shaw vs Luckham Represent components, with property assertions, interfaces, implementations Represent connectors, with protocols, property assertions, implementations Abstraction en encapsulation Types and type checking Accommodate analysis tools openly Component abstraction Communication abstraction Communication integrity Ability to model dynamic architectures Ability to reason about causality and time Hierarchical refinement support Mapping behaviors to architectures
11
11 ADL requirements Conclusion Shaw and Luckman have different points of view No clear line between ADLs and non-ADLs Discriminating ADLs on basis of how much architectural information they represent
12
12 Overview What is ADL ADL Survey ADL Classification and Comparison Framework ACME Conclusion Clements, A Survey of Architecture Description Languages, Proceedings of the 8 th International Workshop on Software Specification and Design, March 1996
13
13 Clements Survey Form Clements created a feature analysis It catalogues user-visible system features in a structured fashion Domain : set of languages considered as ADL User-visible : to user of the language
14
14 Three types of Features System-oriented features Related to application system Derived from architecture description Language-oriented features As found in a language reference manual Process-oriented features Using ADL to create, validate, analyze and refine an architecture description and building an application system from it
15
15 System-Oriented Questions Applicability : how suitable is the ADL for representing a particular type of system? What broad classes of systems can have their architectures represented with the ADL? What application domains is the ADL designed specifically to support? …
16
16 Language-Oriented Questions (1) Language Definition Quality How formally are the ADL’s syntax and sematics defined? How does the ADL treat an incomplete architecture description? Scope of Language How much non-architecture information can the ADL represent?
17
17 Language-Oriented Questions (2) Design History Recording architectural design information? Views : support different views for different aspects? Syntactic, semantic, inter-view cross reference, architectural content of views? Readability …
18
18 Process-Oriented Questions Architecture creation support : textual, graphical editor, import tool? Architecture validation support : syntax, semantics, completeness, consistency checker Architecture refinement support : browser, search tool, version control, … Architecture analysis support : analyzing time & resource economy, functionality, maintainability, portability, reliability, usability Application building Process support User manual, training course, …
19
19 Survey Result
20
20 Survey Result Commonalities among ADLs (1) Abstractions (to the user) are architectural in nature, and represent components and connections Views contain predominantly architectural information Analysis relies on architecture-level information (e.g. behavioral and performance information)
21
21 Survey Result Commonalities among ADLs (2) Graphical syntax and textual form Ability to model distributed systems Not much support for capturing design rationale and/or history Handling data flow and control flow as interconnection mechanisms Help with creation and validation and refinement of architectures
22
22 Survey Result Commonalities among ADLs (3) Ability to represent hierarchical levels of detail Support the application and domain engineer, and mostly also the system analyst Lack of in-depth experience and real-world application
23
23 Survey Result Differences among ADLs (1) Ability to handle real-time constructs at the architectural level Ability to support specification of particular architectural levels Ability to allow definition of new types of components and connectors, new statements and represent non-architectural information
24
24 Survey Result Differences among ADLs (2) Dealing with consistency between artifacts Ability to support analysis (e.g. for many different quality attributes) Ability to handle variability and different instantiations of the same architecture Ability to translate among different views
25
25 Survey Conclusion Requirements for an ADL Support tasks of architecture creation, refinement and validation Represent most of the common architectural styles (e.g. pipeline, real-time, event-based style) Provide views of the system that express architectural information, and suppress implementation and non-architectural information
26
26 Survey Conclusion Requirements for an ADL Capable of matching more than one implementation to the architecture-level views of the system Support analytical capability based on architecture level information, or capability for generating prototype implementations
27
27 Overview What is ADL ADL Survey ADL Classification and Comparison Framework ACME Conclusion Medvidovic N., Taylor R., A Framework for Classifying and Comparing Architecture Description Languages, Proceedings of ESEC/FSE 1997, November 1997
28
28 Survey -> Framework Survey answers to “What an ADL should be able to do” (lists commonalities, differences and requirements) “What is an ADL” remains unanswered Surveys as a guide in formulating the framework for ADL Classification and Comparison
29
29 ADL Classification and Comparison Framework ADL needs building blocks : components, connectors, architectural configurations ADL desires features : Components : types, semantics, constraints, evolution Connectors : interfaces, types, semantics, constraints, evolution Configurations : understandability, heterogeneity, compositionality, constraints, refinement, traceability, scalability, evolution, dynamism ADL desires tools for : active specification, multiple views, analysis, refinement, code generation, dynamism Medvidovic and Taylor
30
30 ADL Classification and Comparison Framework Components A unit of computation or data store Interface Set of interaction points between it and the external world Specifies services required of other components in the architecture Types To model abstract components and be able to instantiate them multiple times
31
31 ADL Classification and Comparison Framework Components Semantics Enables analysis, constraint enforcement, mappings of architectures across levels of abstraction Constraints Property of or assertion about a system or one of its parts Evolution Support component evolution trhough subtyping and refinement
32
32 ADL Classification and Comparison Framework Connectors Architectural building blocks to model interactions among components and rules that govern those interactions Interface The services expected Types In order to abstract away communication protocols and make them reusable
33
33 ADL Classification and Comparison Framework Connectors Semantics Perform analyses of component interactions, consistent refinements across levels of abstraction, enforcement of interconnection and communication constraints Constraints Ensure adherence to interaction protocols, establish intra-connector dependencies, enforce usage boundaries
34
34 ADL Classification and Comparison Framework Connectors Evolution Allowing reuse by modifying and refining existing connectors
35
35 ADL Classification and Comparison Framework Configurations Connected graphs of components and connectors that describe architectural structure Understandable Specifications Modeling structural information with simple and understandable syntax Graphical and/or textual
36
36 ADL Classification and Comparison Framework Configurations Compositionality Hierarchical composition in order to achieve different levels of detail Heterogeneity In order to use ADL for systems with components and connectors of varying granularity, different developers, different programming languages, and varying OS requirements
37
37 ADL Classification and Comparison Framework Configurations Constraints Depicting desired dependencies among components and connectors Refinement and Traceability Enable correct and consistent refinement of architectures to executable systems and traceability of changes across levels of refinement
38
38 ADL Classification and Comparison Framework Configurations Scalability Support specification and development of systems that may grow in size Evolution Allowing architectures to evolve into families of related systems through features for incremental development and support for system families
39
39 ADL Classification and Comparison Framework Configurations Dynamism Allowing evolution of long-running systems, and thus allowing evolution during execution (e.g. insertion, removal and reconnection of architectural elements or sub architectures)
40
40 ADL Classification and Comparison Framework Tool Support Directly related to the ADL’s usefulness Active Specification Preventing/detecting errors Inform the architect, or force him to correct before moving on Multiple Views
41
41 ADL Classification and Comparison Framework Tool Support Analysis Depends on underlying semantic model Enforcement of constraints Language parsers and compilers Refinement Code generation Converting the architectural model into a running application
42
42 ADL Classification and Comparison Framework Comparision of languages Medvidovic and Taylor
43
43 Overview What is ADL ADL Survey ADL Classification and Comparison Framework ACME Conclusion ACME Website (and ACME Studio Manual) http://www.cs.cmu.edu/~acme Garlan D., Monroe R., Wile D., Acme : An architecture Description Interchange Language, Proceedings of CASCON’97, November 1997
44
44 Framework -> Acme Goal : achieving an ADL conform to the Framework? Currently : ADL’s with each some good features, but also lacking others Solution : 1. Create a new ADL from scratch Might still lack new (future) features Loss of very good qualities of existing ADL’s 2. Combine ADL’s through an Interchange Language Acme
45
45 Acme Interchange Language Permit integration of different tools by providing a common form for interchanging architectural descriptions Allows to combine facilities of one ADL with those of another Sharing architectural information that is jointly understood, and tolerating presence of information that falls outside common vocabulary
46
46 Features Architectural ontology consisting of seven basic architectural design elements Flexible annotation mechanism supporting association of non-structural information using externally defined sub-languages Type mechanism for abstracting common, reusable architectural idioms and styles Open semantic framework for reasoning about architectural descriptions
47
47 Design Elements Components Primary computational elements and data stores Connectors Interactions among components Systems Configurations of components and connectors Ports Components’ interfaces
48
48 Design Elements Roles Connectors’ interfaces Representation Lower-level description representing a component or connector Multiple representations = multiple views Rep-map (Representation Map) Correspondence between internal system representation and external interface of the component or connector
49
49 Acme Properties Supports annotation of architectural structure with lists of properties Property : name – optional type – value Property = uninterpreted value Only useful when a tool makes use of them for analysis, translation and manipulation
50
50 Example Simple Client-Server System simple_cs = { Component client = { Port send-request; }; Component server = { Port receive-request; }; Connector rpc = { Roles { caller, callee}}; Attachments { client.send-request to rpc.caller; server.receive-request to rpc.callee;} }
51
51 Description Elements
52
52 Representations & Properties
53
53 Client-Server System Properties (1) System simple_cs = { Component client = { Port send-request; Properties { Aesop-style : style-id = client-server; UniCon-style : style-id = cs; source-code : external = “CODE-LIB/client.c”}} …
54
54 Client-Server System Properties (2) Component server = { Port receive-request; Properties { idempotence : boolean = true; max-concurrent-clients : integer = 1; source-code : external = “CODE_LIG/server.c”}} …
55
55 Client-Server System Properties (3) Connector rpc = { Roles {caller, callee} Properties { synchronous : boolean = true; max-roles : integer = 2; protocol : Wright = “…”}} Attachments { client.send-request to rpc.caller; server.receive-request to rpc.callee} }
56
56 Templates and Style Definition A template is a typed, parameterized macro facility for specification of recurring patterns An architectural style is a set of related templates that make up the common vocabulary of a family of systems
57
57 Client-Server System Templates and Style (1) Style client-server = { Component Template client (rpc-call-ports : Ports) = { Port rpc-call-ports; Properties { Aesop-style : style-id = client-server; UniCon-style : style-id = cs; source-code : external = “CODE-LIB/client.c”}} Component Template server (rpc-receive-ports : Ports) = { Port rpc-receive-ports; Properties { idempotence : boolean = true; … }} …
58
58 Client-Server System Templates and Style (2) Template rpc(caller-port, callee-port : Port) defining (conn : Connector) = { conn = Connector { Roles {caller, callee} Properties { synchronous : boolean = true; max-roles : integer = 2; Attachments { conn.caller to caller_port; conn.callee to callee_port;}} } … A unique identifier conn needs to be generated each time
59
59 Client-Server System Templates and Style (3) System complex_cs : client-server = { c1 = client(send-request); c2 = client(send-request); c3 = client(send-request); s1 = server(receive-request); s2 = server(receive-request); rpc(c1.send-request, s1.receive-request); rpc(c2.send-request, s1.receive-request); rpc(c3.send-request, s2.receive-request); }
60
60 Acme Families A family provides a way of describing a family of architectures as a set of element types that make up the vocabulary family and a set of rules encoded as properties
61
61 Client-Server System Families Family ClientServerFam = { Component Type ClientT = {}; Component Type ServerT = {}; Connector Type ConnectorT = {}; }; System ClientServerSystem :ClientServerFam = { Component client : ClientT = new ClientT; Component server : ServerT = new ServerT; Connector conn : ConnectorT = new ConnectorT; …. };
62
62 Client-Server System Element Types Component Type ClientT = { Property Aesop-style ; Property source-code ; }; Connector Type ConnectorT = { Role caller : Role callee; Property synchronous ; Property max-roles ; };
63
63 Client-Server System Property Types Property Type source-code = String; Property Type synchronous = Boolean; Property Type max-roles = Integer;
64
64 Defining an Acme Family 1.Define model vocabulary : define a family of component and connector types includes both a description in Acme, as well as a description of the assumptions made about components and connectors under this model 2.Define set of property types : to encode properties needed by the model includes the ACME description, as well as a description of the meaning of the properties under the model 3.Define constraints : define what it means for a description to be "well-formed" under this model include constraints on individual properties (e.g., a probability must be between 1 and 0), as well as design constraints
65
65 Open Semantic Framework Provides mapping of the structural aspects of the language into a logical formalism based on relations and constraints An Acme specification represents a derived predicate, called its prescription
66
66 Client-Server System prescription exists client, server, rpc | component(client) ^ component(server) ^ connector(rpc) ^ attached(client.send-request, rpc.caller) ^ attached(server.receive-request, rpc.callee)
67
67 Additions to Prescription Closed world assumption : all components, connectors, ports and roles have been identified by the existential variables, all attachments are specified, and no more exist Existential variables must refer to distinct entities
68
68 Client-Server System Prescription additions exists client, server, rpc | component(client) ^ component(server) ^ connector(rpc) ^ attached(client.send-request, rpc.caller) ^ attached(server.receive-request, rpc.callee) ^ client != server ^ server != rpc ^ client != rpc ^ (for all y:component (y) => y = client | y = server) ^ (for all y:connector (y) => y = rpc) ^ (for all p,q: attached(p,q) => (p=client.send-request ^ q=rpc.caller) | (p=server.receive-request ^ q=rpc.callee))
69
69 Client-Server System Properties in Prescription Aesop-style(client) = client-server ^ Unicon-style(client) = cs Component client = { Port send-request; Properties { Aesop-style : style-id = client-server; UniCon-style : style-id = cs} }
70
70 Overview What is an ADL ADL Survey ADL Classification and Comparison Framework ACME Conclusion
71
71 Conclusion ADL’s are an interesting means to describe architectures in a more formal way A lot of different ADL’s available Acme : as an interchange format between ADL’s (allows to use the best of each ADL)
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.