Architecture Description Languages

1. Architecture Description Languages Mohamed Soliman(msoliman@bcr6.uwaterloo.ca) Basem Shihada(bshihada@bbcr.uwaterloo.ca) Andreas Grau(agrau@elora.math.uwaterloo.ca)

2. Goals • Introduce Architecture Description Languages • Present three different classes of ADLs and their application • Show modeling in ADLs with components

3. Introduction • Software can have high complexity • Coarse grain elements help to abstract • Formal architecture is needed • Model System • Test System • Avoid wrong decisions on architectural (early!) • Reusability • Reduce development costs => ADL

4. Introduction Nenad Medvidovic (neno@usc.edu)

5. Introduction Many ADLs have been proposed ACME Aesop ArTek C2 CODE Darwin Demeter FR Gestalt LILEANNA MetaH ModeChart ObjectTime Rapide RESOLVE SADL UML UniCon Weaves Wright

6. Introduction What is an architecture? “Software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns.” --Shaw and Garlan Mary.Shaw@cs.cmu.edu, Garlan@cs.cmu.edu

7. Introduction What is an ADL then? • An ADL is a language that provides features for modeling a software system’s conceptual architecture. • Essential features: explicit specification of • components • interfaces • connectors • configurations • Desirable features • specific aspects of components, connectors, and configurations • tool support

8. Mohamed Soliman

9. Rapide: An Event Based Architecture Description Language

10. Outline • Background • Rapide Design goals • ADL Requirements in Rapide • Architecture components • The Event Model and Posets • Connecting Components – The Architecture • More Rapide Features • Discussion • Conclusion

11. Background • Created in Stanford for DARPA – early 90’s • Based on work by Prof. D. Luckham • Logician • Worked in concurrent Ada • Co-founder of Rational Software, Inc. • By then, and still, describing Software Architecture needed more attention • Hardware Description was more mature (VHDL) • Now, it is widely accepted ADL

12. Rapide goals • To be an Executable Architecture Description Language (EADL) that • Provides constructs for defining executable prototypes of architectures • Adopts an execution model in which the concurrency, synchronization, data flow and timing properties of the prototype are explicitly represented

13. Architecture Specification 1. Interfaces (External component behavior) 2. Connections – wires 3. Constraints (on interface & conn.)  Architecture

14. ADL requirements in Rapide

15. Component Abstraction • Description of rich interfaces is needed – must go beyond traditional information hiding • Why? • Interface type allows two methods of communication: • Synchronous: by function calls (provides, requires) • Provides: declared functions in module • Requires: invoked functions by the module • Asynchronous: by events (in, out) • In: what actions the component will do on observing an event • Out: what events the component will generate to the parent architecture (other components) • In, Out actions are glued by connectors

16. Component Example

17. Events in Rapide • Events: tuples of information containing: • What generated the event - What activity was done • Data values - Time ,… etc • Causality between events: Components reactive behavior • E.g. component X reacted to event EV1 by generating event EV2 • Poset: Partially Ordered Set of Events • Dependencies and independencies of events (ordering) • Architecture Execution generates posets as well • Event Patterns: Expressions on events used for : • Defining behavior of components and connections • Mapping between architectures • Imposing constraints on posets Constraining behavior • Generate behavior (by generating posets) • E.g. A(?I) Where ?I > 4

18. Connecting Components • An interface connection is a set of - Interfaces - Connections - Constraints • Connections: • Connection Rules - Creation Rules • Creation Rules: event conditions leading to creation of new components (for Dynamic architectures) • Connection Rules: • Implementation independent relationship between events or functions • Uses event pattern matching • Static and dynamic architectures

19. Connection Rules • ‘Wire up’ components • Provide communication abstraction • Two patterns separated by (to, =>, ||>) • Syntax: [Trigger op Right] • Functions or Events • Connects (in, out) - Synchronous (requires, provides) – Asynch.

20. Example Connections

21. Constraints • Example: Component uses a particular communication protocol • Generated events in interfaces and connections must match the constraints (Constraint section) • Along with connection rules, they provide communication integrity

22. ADL requirements in Rapide

23. Dynamic Architectures • Static Architectures: declare the components in object declarations • Dynamic Architectures (Evolution): • Number of components is not known • Declare the interface types of components • By using component creation rules

24. Hierarchy • Hierarchical composition is an important feature of ADLs • Connecting components should result in a new component • Done in Rapide by binding architectures to interfaces using connections • The Architecture is a component -> [Interconnection of Architectures – ACME]

25. Relativity of Architectures • Comparing the behavior of one Architecture (connected components) to another architecture • Idea: Study how events of one system correspond to the other • Different levels of abstraction • E.g.: Many events in one system map to just one • Done by MAPPINGS • Map from one name to another - Mapping rules • Several advantages: • Comparing different versions - Refinement • Evaluate proposed architectures vs. reference architecture

26. Architecture Execution • To test consistency of the interfaces and connections • To discover various aspects of the architecture’s behavior • To test that communication complies with constraints

27. Discussion • Rapide provides only one single view of a system – graphical tools support may help • Components are first-class entities while connectors are not first-class entities as in Unicon, for example • In Rapide, connectors are defined in the architecture entity • Rapide is powerful but complex … • Rapide and coordination models!

28. Conclusion • Rapide is an Executable Architecture Description Language (EADL) that is capable of: • Modeling and describing architectures by connecting components • Modeling and simulation of the dynamic behaviors by using Posets • Components, Connectors and Constraints are the basic entities • The Poset execution model is a powerful tool for analyzing system behavior – Not in other ADLs • Dynamic Architectures, relativity, and hierarchical refinement are achieved with Rapide

29. Questions?! Basem Shihada Break!

30. ACME: Architecture Description Interchange Language http://bbcr.uwaterloo.ca/~bshihada/cs854/acme.pdf

31. Background Motivation ACME ACME Goals ACME Capabilities ACME Features ACME Kernel ACME Kernel Extensions ACME Properties Interchange History ACME Infrastructure Wright to Rapide Ongoing Work Conclusion Presentation Outline

32. Background • Started early 1995 • By D. Garlan, R. Monroe, & D. Wile, from Garnegie Mellon Univ. & USC/Inf. Sciences Institute • Categorized under the architecture interchange languages • Support the interchange of architectural description between variety of architectural design tools. • A new design & analysis tools can be built without rebuild standard infrastructure.

33. Motivations • Different ADL’s provides certain distinctive capabilities • Each operates in stand-alone fashion • Many common aspects already implemented in each ADL • Adopting certain ADL requires high-learning curve

34. ACME • Acme is simple, generic software architectural description language that provide generic, extensible infrastructure for describing , representing, generating, and analyzing software architecture descriptions • Consist of Acme Language and Acme Tool Developer

35. ACME Goals • Interchange format for architectural development tools and environments • Underlying representation for developing new tolls for analyzing and visualizing architectures • Foundation for developing new, domain-specific ADLs

36. ACME Goals cont. • Vehicle for creating conventions: consensus building • Semantic foundations • Refinement • Event-based • Temporal logic • Architecture families • Architecture evolution • Dynamic architectures • Expressive descriptions that are easy for humans to read and write.

37. ACME Capabilities • Architectural Interchange • Extensible foundation for new architecture design & analysis tools • Architectural Description

38. ACME Features • An architecture ontology consisting of seven basic architectural design elements • A flexible annotation mechanism sporting association of non-structure information using externally defined sub languages • A type mechanism for abstracting common, reusable architecture phrase and styles • An open semantic framework for analysis about architectural descriptions

39. ACME Kernel • Components (box): Primary computations elements and data stores. • Connectors (Arrow): Interaction among components • Systems: configuration of components and connectors • Ports: components interfaces • Roles: connectors interfaces • Representations • Rep-maps: maps the internal and external (interfaces, ports, ..etc)

40. ACME Kernel

41. ACME Kernel Extensions • Need to extend kernel to as large a language as is acceptable by the community • Templates • Typed macros • With typed arguments • Families: Styles and other constrained aggregates • Specification as a set of templates and types • Declaration of restriction to family enforces template usage

42. ACME Properties Architectural Integration properties Annotation Properties list

43. ACME Properties

44. Interchange History • Wright -> Rapide Translation • Initial translation technology developed • One-way translation (not round trip) • Aesop <-> ACME <-> UniCon • Aesop <-> ACME 1.0 works • Aesop <-> ACME 3.0 underway • Aesop <-> ACME 3.0 underway • Aesop <-> ACME <-> UniCon works

45. ACME Infrastructure • ACME-Lib infrastructure • Extensible ACME parser & unparsed • Extensible ACME Translation tools • Native-ADL embeddable support • Support for design traversal, manipulation, and type-checking in ACME-native tools ADL Converter ACME ACME Description Access ACME Description Target ADL Methods Parser

46. Wright to Rapide

47. Ongoing Work • Prototypes for several ACME tools to be provided to the architecture and generation EDCS cluster • Prototypes for tools that allow others to provide domain-specific analyzers • Promised, type checker, visualization tools

48. Conclusion • Architectural description Integration Language • Capable of • Architectural integration toolkit • Extendable foundation for new tools • Architecture Description. • Consist of several elements • Elements supported with properties • Open semantic framework

49. Questions? Break!

50. Andreas Grau