Architecture Description Languages ADL

8109103 Ohjelmistotuotannon teoria 18.2.2004 Jukka Harkki

What is an ADL?
It is a language describing software architecture, which in turn is: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them Software Architecture in Practice (Bass, Clements, Kazman, 2003 An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behaviour as specified in the collaborations among those elements, the composition of these structural and behavioural elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition (The UML Modelling Language User Guide, Addison-Wesley, 1999). ...an abstract system specification consisting primarily of functional components described in terms of their behaviours and interfaces and component-component interconnections (Hayes-Roth, 1994)
2

Why an ADL?
To enable developers to abstract away unnecessary details and focus on the big picture: system structure, high level communication protocols, assignment of software components, development process etc. To support and control the development process from the very beginning; the earlier you have it under control, the better. Evolution of the system Architecture of a software system should drive the implementation. Architecture should not be an end result of implementation Shifting focus from lines-of-code to software components and their overall interconnection structure Reducing cost, recycling models, more flexiblility and interoperability
3

What is understood by an ADL?

It is not clear what level of support an ADL should provide to developers At minimum role of architectural descriptions is to aid understanding and communication about a software system: an ADL must have simple, understandable, and possibly graphical syntax, well understood, but not necessarily formally defined semantics, and the kinds of tools that aid visualization, understanding, and simple analyses of architectural descriptions More comprehensive approach has been to provide formal syntax and semantics of ADLs, powerful analysis tools, model checkers, parsers, compilers, code synthesis tools, runtime support tools While both perspectives can be justified, ADL researchers have generally adopted one or the other extreme view
4

Common understanding?
An ADL must explicitly model components, connectors and their configurations To be truly usable and useful, and ADL must provide tool support for architecture-based development and evolution ADL is not - A programming language - High-level design notation - Module Interconnection Language (MIL) - Object-oriented modelling notation - Formal specification language
5

ADL Classification Framework

ADL Architecture Modelling Features Components Interface Types Semantics Constraints Evolution Non-functional properties Connectors Interface Types Semantics Constraints Evolution Non-functional properties ... ADL Architecture Modelling Features Architectural Configurations Understandability Compositionality Refinement and traceability Heterogeneity Scalability Evolution Dynamism Constraints Non-functional properties Tool Support Active Specification Multiple Views Analysis Refinement Implementation Generation Dynamism 6

ADL Overview
ACME Aesop C2 Darwin MetaH Rapide SADL UniCon Weaves Wright xADL Architectural interchange, predominantly at the structural level Specification of architectures in specific styles Architectures of highly-distributed, evolvable, and dynamic systems Architectures of highly-distributed systems whose dynamism is guided by strict formal underpinnings Architectures in the guidance, navigation, and control (GN&C) domain Modelling and simulation of the dynamic behaviour described by an architecture Formal refinement of architectures across levels of detail Glue code generation for interconnecting existing components using common interaction protocols Data-flow architectures, characterized by high volume of data and real-time requirements on its processing Modelling and analysis (specifically, deadlock analysis) of the dynamic behaviour of concurrent systems Extensible XML-based ADL based on xArch
7

10

ADL TOOL SUPPORT

11

Acme
Acme started back in 1995 as an ADL interchange language but has evolved to an ADL itself Three fundamental capabilities: 1) Architectural interchange 2) Extensible foundation for new design and analysis tools 3) Architecture description Acme language definition and tool developer library (java and C++) available for download. AcmeStudio IDE and HTML documentation generator also available

12

Acme Code Example

// Describe a simple pipe-filter family. This family definition demonstrates Acme's ability to specify a family of // architectures as well as individual architectural instances. An Acme family includes a set of component, connector, port and // role types that define the design vocabulary provided by the family. Family PipeFilterFam = { // Declare component types Component Type FilterT = { // All filters define at least two ports Ports { stdin; stdout; }; Property throughput : int; }; // Extend the basic filter type with a subclass (inheritance) Component Type UnixFilterT extends FilterT with { Port stderr; Property implementationFile : String; }; // Declare the pipe connector type. Like component types, a connector type also describes required structure. Connector Type PipeT = { Roles { source; sink; }; Property bufferSize : int; }; // Declare some property types that can be used by systems designed for the PipeFilterFam family Property Type StringMsgFormatT = Record [ size:int; msg:String; ]; Property Type TasksT = enum {sort, transform, split, merge}; };

13

AcmeStudio
Graphical editor for architectural designs Edit designs in existing families (styles), or create new families and types Create new diagram styles based on visualization conventions you define Integrated Armani constraint checker to check architectural design rules Implemented as Eclipse plug-in for portability and extensibility Available for Windows, Linux, and (soon) MacOS X

14

xADL
Based on xArch: standard, extensible XML-based representation for software architectures Features: 1) Highly extensible 2) Tool support 3) Clear distinction between architecture prescription and description (design and runtime) General set of extensions JavaAPI for DOM based access. Tool to generate API using the schema
15

xADL Example
Component: At circuit structural level, components are NMOS/PMOS Connector: connectors are wire, Interface: input/output ports Link:

16

17

C2
C2 is a software architectural style for user interface intensive systems: Connectors transmit messages between components Components maintain state and perform operations Components exchange messages with other components via two interfaces named top and bottom Each interface consists of a set of messages that may be sent and a set of messages that may be received Inter-component messages are either requests or notifications Components may not directly exchange messages; they may only do so via connectors Each component interface may be attached to at most one connector A connector may be attached to any number of other components and connectors Request messages may only be sent upward through the architecture Notification messages may only be sent downward
18

Meeting Scheduler in C2

19

C2 Component
component Attendee is interface top_domain is out null; in null; bottom_domain is out PrefSet (p : date_rng); ExclSet (e : date_rng); EquipReqts (eq : equip_type); Witdrawn (); in GetPrefSet (); GetExclSet (); GetEquipReqts (); RemoveExclSet (); RequestWithdrawal (); AddPrefDates (); MarkMtg (d : date; l : loc_type); parameters null; methods procedure Start (); procedure Finish (); procedure NoteMtg (d : date; l : loc_type); function DeterminePrefSet () return date_rng; function DetermineExclSet () return date_rng; function AddPrefDates () return date_rng; function RemoveExclSet () return date_rng; procedure DetermineEquipReqts (eq : equip_type); behavior startup invoke_methods Start; always_generate null; cleanup invoke_methods Finish; always_generate null; received_messages GetPrefSet; invoke_methods DeterminePrefSet; always_generate PrefSet; received_messages AddPrefDates; invoke_methods AddPrefDates; always_generate PrefSet; received_messages GetExclSet; invoke_methods DetermineExclSet; always_generate ExclSet; received_messages GetEquipReqts; invoke_methods DetermineEquipReqts; always_generate EquipReqts; received_messages RemoveExclSet; invoke_methods RemoveExclSet; always_generate ExclSet; received_messages RequestWithdrawal; invoke_methods Finish; always_generate Withdrawn; received_messages MarkMtg; invoke_methods NoteMtg; always_generate null; context top_most computational_unit; end Attendee;

20

C2 Conceptual Component
architecture MeetingScheduler is conceptual_components top_most Attendee; ImportantAttendee; internal null bottom_most MeetingInitiator; connectors connector MainConn is message_filter no_filtering; end MainConn; connector AttConn is message_filter no_filtering; end AttConn; connector ImportantAttConn is message_filter no_filtering; end ImportantAttConn; architectural_topology connector AttConn connections top_ports Attendee; bottom_ports MainConn; connector ImportantAttConn connections top_ports ImportantAttendee; bottom_ports MainConn; connector MainConn connections top_ports AttConn; ImportantAttConn; bottom_ports MeetingInitiator; end MeetingScheduler;

21

Meeting Scheduler in UML

22

UML as an ADL
UML has lot of supporting diagrams to describe ADL Use of UML is highly desired because of tool support, skills and processes Some ways to do ADL with UML: - Extended UML via MOF - lack of tool support - Use UML with extensions - OCL not always supported by tools - Use basic UML - too loose UML Profile for Software Architecture has been proposed - no progress seen In the previous C2-to-UML example the basic strategy was to first choose an existing meta-class from the UML meta-model that is semantically close to an ADL construct, and then define a stereotype that can be applied to instances of that meta-class to constrain its semantics to that of the ADL Experience of the example indicated that adapting UML to model ADL requires reasonable effort, has the potential to be a useful complement to ADLs and their analysis tools, and may be a practical step toward mainstream architectural modelling. It may also aid in the comparison of ADLs because it forces some implicit assumptions to be explicitly stated in common terms UML abstractions do not necessarily match architects mental model of the system thus making the job of designing the architecture more difficult compared to using ADL of architects choice

23

Summary
The field is very much open. There is concensus of the domain (architecture) but not of what should be covered and how ADL now is more an academic research issue and it needs to have deliverables Timestamp-analysis shows that most of the ADL material is from 1994-1998, most of the sites last updated between 1998-2002 Will ADL ever emerge as a widely acknowledged language or will for example UML swallow it? Given the industry acceptance for UML, the ADL of choice needs at least to be integrated with UML Standard IEEE 1471-2000 establishes a conceptual framework and vocabulary for architectural issues. Architectural practices and evolution of them. Standard only recommends practices

24