Architecture Modeling Notations Software Architecture Copyright Richard N

Architecture Modeling Notations Software Architecture Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.

Software Architecture: Foundations, Theory, and Practice Continuing Our Survey l l Generic approaches u Natural language u Power. Point-style modeling u UML, the Unified Modeling Language Early architecture description languages u Darwin u Rapide u Wright Domain- and style-specific languages u Koala u Weaves u AADL Extensible architecture description languages u Acme u ADML u x. ADL 2

Software Architecture: Foundations, Theory, and Practice Continuing Our Survey l l Generic approaches u Natural language u Power. Point-style modeling u UML, the Unified Modeling Language Early architecture description languages u Darwin u Rapide u Wright Domain- and style-specific languages u Koala u Weaves u AADL Extensible architecture description languages u Acme u ADML u x. ADL 3

Software Architecture: Foundations, Theory, and Practice Early Architecture Description Languages l Early ADLs proliferated in the 1990 s and explored ways to model different aspects of software architecture u Many emerged from academia u Focus on structure: components, connectors, interfaces, configurations u Focus on formal analysis u None used actively in practice today, tool support has waned l Ideas influenced many later systems, though 4

Software Architecture: Foundations, Theory, and Practice Darwin l l l General purpose language with graphical and textual visualizations focused on structural modeling of systems Advantages u Simple, straightforward mechanism for modeling structural dependencies u Interesting way to specify repeated elements through programmatic constructs u Can be modeled in pi-calculus formal analysis u Can specify hierarchical (i. e. , composite) structures Disadvantages u Limited usefulness beyond simple structural modeling u No notion of explicit connectors l Although components can act as connectors 5

Software Architecture: Foundations, Theory, and Practice Darwin Example component Data. Store{ provide lander. Values; } component Calculation{ require lander. Values; provide calculation. Service; } component User. Interface{ require calculation. Service; require lander. Values; } component Lunar. Lander{ inst U: User. Interface; C: Calculation; D: Data. Store; bind C. lander. Values -- D. lander. Values; U. calculation. Service -- C. calculation. Service; } Canonical Textual Visualization Graphical Visualization Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission. 6

Software Architecture: Foundations, Theory, and Practice Programmatic Darwin Constructs component Web. Server{ provide http. Service; } component Web. Client{ require http. Service; } component Web. Application(int num. Clients){ inst S: Web. Server; array C[num. Clients]: Web. Client; forall k: 0. . num. Clients-1{ inst C[k] @ k; bind C[k]. http. Service -- S. http. Service; } } 7 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Darwin Evaluation l Scope and purpose u l Mostly static structure; some additional support for dynamic aspects through lazy and dynamic instantiation/binding l l Ambiguity u Rigorous, but structural elements can be interpreted in many ways Accuracy u Pi-calculus analysis Precision u Modelers choose appropriate level of detail through hierarchy Viewpoints u Structural viewpoints View consistency u N/A Dynamic Models u l Limited support through programmatic constructs Static & Dynamic Aspects u l Components, interfaces, configurations, hierarchy Style u l Modeling software structure Basic elements u l l N/A Non-Functional Aspects u N/A 8

Software Architecture: Foundations, Theory, and Practice Rapide l l l Language and tool-set for exploring dynamic properties of systems of components that communicate through events Advantages u Unique and expressive language for describing asynchronously communicating components u Tool-set supports simulation of models and graphical visualization of event traces Disadvantages u No natural or explicit mapping to implemented systems u High learning curve u Important tool support is difficult to run on modern machines 9

Software Architecture: Foundations, Theory, and Practice Rapide Example type Data. Store is interface action in Set. Values(); out Notify. New. Values(); behavior begin Set. Values => Notify. New. Values(); ; end Data. Store; type Calculation is interface action in Set. Burn. Rate(); out Do. Set. Values(); behavior action Calc. New. State(); begin Set. Burn. Rate => Calc. New. State(); Do. Set. Values(); ; end Calculation; type Player is interface action out Do. Set. Burn. Rate(); in Notify. New. Values(); behavior Turns. Remaining : var integer : = 1; action Update. Status. Display(); action Done(); 10 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Rapide Example (cont’d) type Data. Store is interface action in Set. Values(); out Notify. New. Values(); behavior begin (start or Update. Status. Display) where Set. Values => Notify. New. Values(); ; ($Turns. Remaining > 0) => end Data. Store; if ( $Turns. Remaining > 0 ) then Turns. Remaining : = $Turns. Remaining - 1; type Calculation is interface Do. Set. Burn. Rate(); action in Set. Burn. Rate(); end if; ; out Do. Set. Values(); Notify. New. Values => Update. Status. Display(); ; behavior Update. Status. Display where $Turns. Remaining == 0 action Calc. New. State(); => Done(); ; begin end User. Interface; Set. Burn. Rate => Calc. New. State(); Do. Set. Values(); ; end Calculation; architecture lander() is P 1, P 2 : Player; type Player is interface C : Calculation; action out Do. Set. Burn. Rate(); D : Data. Store; in Notify. New. Values(); connect behavior P 1. Do. Set. Burn. Rate to C. Set. Burn. Rate; Turns. Remaining : var integer : = 1; P 2. Do. Set. Burn. Rate to C. Set. Burn. Rate; action Update. Status. Display(); C. Do. Set. Values to D. Set. Values; action Done(); D. Notify. New. Values to P 1. Notify. New. Values(); D. Notify. New. Values to P 2. Notify. New. Values(); end Lunar. Lander; Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission. 11

Software Architecture: Foundations, Theory, and Practice Simulation Output 1 -player 2 -player 12 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Rapide Evaluation l Scope and purpose u l Static structure and dynamic behavior co-modeled l Some tools provide limited animation capabilities l Dynamic Models u l N/A Static & Dynamic Aspects u l Structures, components/ interfaces, behaviors Style u l l Basic elements u l Interactions between components communicating with events l Non-Functional Aspects u N/A l Ambiguity u Well-defined semantics limit ambiguity Accuracy u Compilers check syntax, simulators can be used to check semantics although simulation results are nondeterministic and nonexhaustive Precision u Detailed behavioral modeling possible Viewpoints u Single structural/behavioral viewpoint View consistency u N/A 13

Software Architecture: Foundations, Theory, and Practice Wright l l l An ADL that specifies structure and formal behavioral specifications for interfaces between components and connectors Advantages u Structural specification similar to Darwin or Rapide u Formal interface specifications can be translated automatically into CSP and analyzed with tools l Can detect subtle problems e. g. , deadlock Disadvantages u High learning curve u No direct mapping to implemented systems u Addresses a small number of system properties relative 14 to cost of use

Software Architecture: Foundations, Theory, and Practice Wright Example Component Data. Store Port get. Values (behavior specification) Port store. Values (behavior specification) Computation (behavior specification) Component Calculation Port get. Values (behavior specification) Port store. Values (behavior specification) Port calculate (behavior specification) Computation (behavior specification) Component User. Interface Port get. Values (behavior specification) Port calculate (behavior specification) Computation (behavior specification) Connector Call Role Caller = Role Callee = Glue = 15 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Wright Example 16 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Wright Evaluation l Scope and purpose u l Basic elements u l Supported through predicates over instance models l Static structural models annotated with behavioral specifications l Dynamic Models u l l Static & Dynamic Aspects u l Components, connectors, interfaces, attachments, styles Style u l Structures, behaviors, and l Ambiguity styles of systems composed u Well-defined semantics limit of components & connectors N/A Non-Functional Aspects u N/A l ambiguity Accuracy u Wright models can be translated into CSP for automated analysis Precision u Detailed behavioral modeling possible Viewpoints u Single structural/behavioral viewpoint plus styles View consistency u Style checking can be done automatically 17

Software Architecture: Foundations, Theory, and Practice Domain- and Style-Specific ADLs l l Notations we have surveyed thus far have been generically applicable to many types of software systems If you restrict the target domain, you can provide more advanced features and/or reduce complexity u We’ll talk a lot more about domain-specific software engineering later in the course 18

Software Architecture: Foundations, Theory, and Practice Koala l l l Darwin-inspired notation for specifying product lines of embedded consumer-electronics devices Advantages u Advanced product-line features let you specify many systems in a single model u Direct mapping to implemented systems promotes design and code reuse Disadvantages u Limited to structural specification with additional focus on interfaces 19

Software Architecture: Foundations, Theory, and Practice Koala Example interface IData. Store{ void set. Altitude(int altitude. In. Meters); int get. Altitude(); void set. Burn. Rate(int new. Burn. Rate); int get. Burn. Rate(); . . . } Single system Product line of two systems 20 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Koala Evaluation l Scope and purpose u l Basic elements u l l Static structure only Dynamic Models u l l Product lines might be seen as very narrow styles Static & Dynamic Aspects u l Components, interfaces, elements for variation points: switches, diversity interfaces, etc. l Style u l Structures and interfaces of product lines of componentbased systems l N/A Non-Functional Aspects u N/A l Ambiguity u Close mappings to implementation limit ambiguity Accuracy u Close mappings to implementations should reveal problems Precision u Structural decisions are fully enumerated but other aspects left out Viewpoints u Structural viewpoint with explicit points of variation View consistency u N/A 21

Software Architecture: Foundations, Theory, and Practice Weaves l l l An architectural style and notation for modeling systems of small-grain tool fragments that communicate through data flows of objects Advantages u Extremely optimized notation l Even simpler than Darwin diagrams u Close mapping to implemented systems Disadvantages u Addresses structure and data flows only 22

Software Architecture: Foundations, Theory, and Practice Weaves Example Generic Weaves System Lunar Lander in Weaves 23 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Weaves Evaluation l Scope and purpose u l Static structure only l Dynamic Models u l Weaves style implicit Static & Dynamic Aspects u l Components, queues, directed interconnections l Style u l Structures of components and connectors in the Weaves style Basic elements u l l N/A, although there is a 1 -1 correspondence between model and implementation elements Non-Functional Aspects u N/A l l Ambiguity u Meanings of Weaves elements are well-defined although important elements (e. g. , protocols) are subject to interpretation Accuracy u Syntactic (e. g. , structural) errors easy to identify Precision u Structural decisions are fully enumerated but other aspects left out Viewpoints u Structural viewpoint View consistency u N/A 24

Software Architecture: Foundations, Theory, and Practice AADL: The Architecture Analysis & Design Language l l l Notation and tool-set for modeling hardware/software systems, particularly embedded and real-time systems Advantages u Allows detailed specification of both hardware and software aspects of a system u Automated analysis tools check interesting end-to-end properties of system Disadvantages u Verbose; large amount of detail required to capture even simple systems u Emerging tool support and UML profile support 25

Software Architecture: Foundations, Theory, and Practice AADL (Partial) Example data lander_state_data end lander_state_data; bus lan_bus_type end lan_bus_type; bus implementation lan_bus_type. ethernet properties Transmission_Time => 1 ms. . 5 ms; Allowed_Message_Size => 1 b. . 1 kb; end lan_bus_type. ethernet; system calculation_type features network : requires bus access lan_bus. calculation_to_datastore; request_get : out event port; response_get : in event data port lander_state_data; request_store : out event port lander_state_data; response_store : in event port; end calculation_type; system implementation calculation_type. calculation subcomponents the_calculation_processor : processor calculation_processor_type; the_calculation_process : process calculation_process_type. one_thread; 26 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice AADL (Partial) Example data lander_state_dataconnections end lander_state_data; bus access network -> the_calculation_processor. network; bus lan_bus_type event data port response_get -> end lan_bus_type; the_calculation_process. response_get; event port the_calculation_process. request_get -> bus implementation lan_bus_type. ethernet request_get; properties event data port response_store -> Transmission_Time => 1 ms. . 5 ms; the_calculation_process. response_store; Allowed_Message_Sizeproperties => 1 b. . 1 kb; end lan_bus_type. ethernet; Actual_Processor_Binding => reference system calculation_type the_calculation_processor applies to features the_calculation_process; network : requires bus end access calculation_type. calculation; lan_bus. calculation_to_datastore; request_get : outprocessor event port; calculation_processor_type response_get : in features event data port lander_state_data; request_store : out event network port : requires lander_state_data; bus access response_store : in event port; lan_bus. calculation_to_datastore; end calculation_type; end calculation_processor_type; system implementation process calculation_type. calculation_process_type subcomponents features the_calculation_processor request_get : : out event port; processor response_get calculation_processor_type; : in event data port lander_state_data; the_calculation_process request_store : process : out event data port lander_state_data; calculation_process_type. one_thread; response_store : in event port; end calculation_process_type; Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. 27

Software Architecture: Foundations, Theory, and Practice AADL (Partial) Example data lander_state_dataconnections end lander_state_data; bus access network -> the_calculation_processor. network; thread bus lan_bus_type event data portcalculation_thread_type response_get -> features end lan_bus_type; the_calculation_process. response_get; : out event port; event portrequest_get the_calculation_process. request_get -> response_get : in event data port lander_state_data; bus implementation lan_bus_type. ethernet request_get; : out -> event data port lander_state_data; properties event datarequest_store port response_store : in event port; Transmission_Time => 1 ms. . 5 ms; the_calculation_process. response_store; properties Allowed_Message_Sizeproperties => 1 b. . 1 kb; Dispatch_Protocol => periodic; end lan_bus_type. ethernet; Actual_Processor_Binding => reference end calculation_thread_type; system calculation_type the_calculation_processor applies to process implementation calculation_process_type. one_thread features the_calculation_process; subcomponents network : requires bus end access calculation_type. calculation; calculation_thread : thread client_thread_type; lan_bus. calculation_to_datastore; connections request_get : outprocessor event port; calculation_processor_type eventlander_state_data; data port response_get -> response_get : in features event data port request_store : out event network port : requires lander_state_data; buscalculation_thread. response_get; access event port calculation_thread. request_get -> request_get; response_store : in event port; lan_bus. calculation_to_datastore; event port response_store -> end calculation_type; end calculation_processor_type; calculation_thread. response_store; event data port request_store -> request_store; system implementation process calculation_type. calculation_process_type subcomponents features properties Dispatch_Protocol => Periodic; the_calculation_processor request_get : : out event port; Period => 20 ms; processor response_get calculation_processor_type; : in event data port lander_state_data; end calculation_process_type. one_thread; the_calculation_process request_store : process : out event data port lander_state_data; calculation_process_type. one_thread; response_store : in event port; end calculation_process_type; Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission. 28

Software Architecture: Foundations, Theory, and Practice AADL Example Explained a Bit l l l Note the level of detail at which the system is specified u A component (calculation_type. calculation) runs on… u a physical processor (the_calculation_processor), which runs… u a process (calculation_process_type. one_thread), which in turn contains… u a single thread of control (calculation_thread), all of which can make two kinds of request-response calls through… u ports (request_get/response_get, request_store/response_store) over… u an Ethernet bus (lan_bus_type. Ethernet). All connected through composition, port-mapping, and so on This detail is what gives AADL its power and analyzability 29

Software Architecture: Foundations, Theory, and Practice AADL Evaluation l Scope and purpose u l l N/A l Primarily static structure but additional properties specify dynamic aspects l N/A l Dynamic Models u l l Static & Dynamic Aspects u l Multitude – components, threads, hardware elements, configurations, mappings… Style u l Interconnected multi-level systems architectures Basic elements u l Non-Functional Aspects u N/A Ambiguity u Most elements have concrete counterparts with well-known semantics Accuracy u Structural as well as other interesting properties can be automatically analyzed Precision u Many complex interconnected levels of abstraction and concerns Viewpoints u Many viewpoints addressing different aspects of the system View consistency u Mappings and refinement can generally be automatically checked or do not overlap 30

Software Architecture: Foundations, Theory, and Practice Extensible ADLs l l l There is a tension between u The expressiveness of general-purpose ADLs and u The optimization and customization of more specialized ADLs How do we get the best of both worlds? u Use multiple notations in tandem l (Difficult to keep consistent, often means excessive redundancy) u Overload an existing notation or ADL (e. g. , UML profiles) l Increases confusion, doesn’t work well if the custom features don’t map naturally onto existing features u Add additional features we want to an existing ADL l But existing ADLs provide little or no guidance for this Extensible ADLs attempt to provide such guidance 31

Software Architecture: Foundations, Theory, and Practice Acme l l l Early general purpose ADL with support for extensibility through properties Advantages u Structural specification capabilities similar to Darwin u Simple property structure allows for arbitrary decoration of existing elements u Tool support with Acme. Studio Disadvantages u No way to add new views u Property specifications can become extremely complex and have entirely separate syntax/semantics of their own 32

Software Architecture: Foundations, Theory, and Practice Acme Example //Global Types Property Type returns. Value. Type = bool; Connector Type Call. Type = { Roles { caller. Role; callee. Role; }; Property returns. Value : returns. Value. Type; }; System Lunar. Lander = { //Components Component Data. Store = { Ports { get. Values; store. Values; } }; Component Calculation = { Ports { calculate; get. Values; store. Values; } }; Component User. Interface = { Ports { get. Values; calculate; } }; // Connectors Connector User. Interface. To. Calculation : Call. Type { Roles { caller. Role; callee. Role; }; Property returns. Value : returns. Value. Type = true; } Connector User. Interface. To. Data. Store : Call. Type { Roles { caller. Role; callee. Role; }; Property returns. Value : returns. Value. Type = true; } Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission. 33

Software Architecture: Foundations, Theory, and Practice Connector Calculation. To. Data. Store. S : Call. Type { Roles { caller. Role; callee. Role; }; Property returns. Value : returns. Value. Type = false; } //Global Types Connector Calculation. To. Data. Store. G : Call. Type { Property Type returns. Value. Type = bool; Roles { caller. Role; callee. Role; }; Connector Type Call. Type = { Property returns. Value : returns. Value. Type = true; Roles { caller. Role; callee. Role; }; } Property returns. Value : returns. Value. Type; Attachments { }; User. Interface. get. Values to User. Interface. To. Data. Store. caller. Role; System Lunar. Lander = { User. Interface. To. Data. Store. callee. Role to //Components Data. Store. get. Values; Component Data. Store = { User. Interface. get. Values to Ports { get. Values; store. Values; } User. Interface. To. Data. Store. caller. Role; }; User. Interface. To. Data. Store. callee. Role to Component Calculation = { Data. Store. get. Values; Ports { calculate; get. Values; store. Values; } User. Interface. calculate to }; User. Interface. To. Calculation. caller. Role; Component User. Interface = { User. Interface. To. Calculation. callee. Role to Ports { get. Values; calculate; } Calculation. calculate; }; Calculation. store. Values to Calculation. To. Data. Store. S. caller. Role; // Connectors Calculation. To. Data. Store. S. callee. Role to Connector User. Interface. To. Calculation : Call. Type { Data. Store. store. Values; Roles { caller. Role; callee. Role; }; Calculation. get. Values to Property returns. Value : returns. Value. Type Calculation. To. Data. Store. G. caller. Role; = true; } Calculation. To. Data. Store. G. callee. Role to Connector User. Interface. To. Data. Store : Call. Type { Data. Store. get. Values; Roles { caller. Role; callee. Role; }; }; Property returns. Value : returns. Value. Type = true; } 34 } Acme Example Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Connector Calculation. To. Data. Store. S : Call. Type { Roles { caller. Role; callee. Role; }; //Global Types Property returns. Value : returns. Value. Type = false; Property Type returns. Value. Type = bool; } Connector Type Call. Type = { Connector Calculation. To. Data. Store. G : Call. Type { Roles { caller. Role; callee. Role; }; Property returns. Value : returns. Value. Type; Roles { caller. Role; callee. Role; }; Property returns. Value : returns. Value. Type = true; }; } Attachments { System Lunar. Lander = { Property Type Store. Type = enum { file, User. Interface. get. Values to //Components relational. Database, User. Interface. To. Data. Store. caller. Role; object. Database }; Component Data. Store = { User. Interface. To. Data. Store. callee. Role to Ports { get. Values; store. Values; } Component Data. Store = Data. Store. get. Values; { }; Ports { User. Interface. get. Values to Component Calculation = { get. Values; store. Values; User. Interface. To. Data. Store. caller. Role; Ports { calculate; get. Values; store. Values; } } User. Interface. To. Data. Store. callee. Role to }; Property store. Type : Data. Store. get. Values; Store. Type = Component User. Interface = { relational. Database; User. Interface. calculate to Ports { get. Values; calculate; } Property table. Name : User. Interface. To. Calculation. caller. Role; String = “Lander. Table”; }; Property num. Replicas: int = 0; User. Interface. To. Calculation. callee. Role to }; Calculation. calculate; // Connectors Calculation. store. Values to Connector User. Interface. To. Calculation : Call. Type { Calculation. To. Data. Store. S. caller. Role; Roles { caller. Role; callee. Role; }; Calculation. To. Data. Store. S. callee. Role to Property returns. Value : returns. Value. Type = true; Data. Store. store. Values; } Calculation. get. Values to Connector User. Interface. To. Data. Store : Call. Type { Calculation. To. Data. Store. G. caller. Role; Roles { caller. Role; callee. Role; }; Calculation. To. Data. Store. G. callee. Role to Property returns. Value : returns. Value. Type = true; Data. Store. get. Values; } }; } 35 Acme Extensions Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Acme Evaluation l Scope and purpose u l l l Through type system l u l Acme. Lib allows programmatic model manipulation l Non-Functional Aspects u Through properties Checkable syntactically, via type system, and properties by external tools Precision u Static structure is modeled natively, dynamic aspects in properties Meanings of elements subject to some interpretation, properties may have arbitrary level of rigor/formality Accuracy Properties can increase precision but cannot add new elements Viewpoints u Dynamic Models u l l Static & Dynamic Aspects u Ambiguity u Components, connectors, interfaces, hierarchy, properties Style u l Structures of components and connectors with extensible properties Basic elements u l Structural viewpoint is native, properties might provide additional viewpoints View consistency u Via external tools that must be developed 36

Software Architecture: Foundations, Theory, and Practice ADML l l l Effort to standardize the concepts in Acme and leverage XML as a syntactic base Advantages u XML parsers and tools readily available u Added some ability to reason about types of properties with meta-properties Disadvantages u Properties are still name-value pairs u Did not take advantage of XML extension mechanisms 37

Software Architecture: Foundations, Theory, and Practice ADML Example l Similar to Acme, except in an XML format <Component ID=”datastore” name=”Data Store”> <Component. Description> <Component. Body> <Port ID=”get. Values” name=”get. Values”/> <Port ID=”store. Values” name=”store. Values”/> </Component. Body> </Component. Description> </Component> 38 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice x. ADL l l l Modular XML-based ADL intended to maximize extensibility both in notation and tools Advantages u Growing set of generically useful modules available already u Tool support in Arch. Studio environment u Users can add their own modules via well-defined extensibility mechanisms Disadvantages u Extensibility mechanisms can be complex and increase learning curve u Heavy reliance on tools 39

Software Architecture: Foundations, Theory, and Practice x. ADL Example <types: component xsi: type="types: Component" types: id="my. Comp"> <types: description xsi: type="instance: Description"> My. Component </types: description> <types: interface xsi: type="types: Interface" types: id="iface 1"> <types: description xsi: type="instance: Description"> Interface 1 </types: description> <types: direction xsi: type="instance: Direction"> inout </types: direction> </types: interface> </types: component> 40 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice x. ADL Example <types: component xsi: type="types: Component" types: id="my. Comp"> <types: description xsi: type="instance: Description"> My. Component </types: description> <types: interface xsi: type="types: Interface" types: id="iface 1"> <types: description xsi: type="instance: Description"> Interface 1 component{ </types: description> id = "my. Comp"; <types: direction xsi: type="instance: Direction"> description = "My. Component"; inout interface{ </types: direction> id = "iface 1"; </types: interface> description = "Interface 1"; </types: component> direction = "inout"; } } 41 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice x. ADL Example <types: component xsi: type="types: Component" types: id="my. Comp"> <types: description xsi: type="instance: Description"> My. Component </types: description> <types: interface xsi: type="types: Interface" types: id="iface 1"> <types: description xsi: type="instance: Description"> Interface 1 component{ </types: description> id = "my. Comp"; <types: direction xsi: type="instance: Direction"> description = "My. Component"; inout interface{ </types: direction> id = "iface 1"; </types: interface> description = "Interface 1"; </types: component> direction = "inout"; } } 42 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice x. ADL Tools 43 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice Arch. Studio Environment 44 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2010 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice x. ADL Schemas (Modules) 45 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture: Foundations, Theory, and Practice x. ADL Evaluation l Scope and purpose u l l Mostly static views with behavior and dynamic aspects provided through extensions Dynamic Models u Models can be manipulated programmatically Non-Functional Aspects u l l Through extensions Base schemas are abstract, precision added in extensions Viewpoints u l Correctness checkers included in Arch. Studio and users can additional tools through welldefined mechanisms Precision u l Base schemas are permissive; extensions add rigor or formality if needed Accuracy u Limited, through type system Static & Dynamic Aspects Ambiguity u Components, connectors, interfaces, links, options, variants, versions, …, plus extensions Style u l Modeling various architectural concerns with explicit focus on extensibility Basic elements u l Several viewpoints provided natively, new viewpoints through extensions View consistency u Checkable through external tools and additional consistency rules 46

Software Architecture: Foundations, Theory, and Practice Caveat 1 l The preceding overview optimized for breadth rather than depth u Semantics and capabilities of many of these notations quite deep and subtle l Some even have entire books written about them u You are encouraged to investigate individual notations more deeply 47

Software Architecture: Foundations, Theory, and Practice Caveat 2 l Some systems are difficult to model in traditional ways u ‘Agile’ systems that are not explicitly designed above the level of code modules u Extremely large, complex, or dynamic systems (e. g. , the Web) l Can model limited or less complex aspects l Can model one instance of the system (e. g. , one Web application) l Exploit regularity l Model the style l Model the protocols 48