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)