Software Architecture - Modeling and Notations

ADML

- Effort to standardize the concepts in ACME and leverage XML as a syntactic base - advantages: -- XML parsers and tools readily available -- added some ability to reason about types of properties with meta-properties - disadvantages: -- properties are still name-value pairs -- did not take advantage of XML extension mechanisms

Unified Modeling Language

- 13 loosely-interconnected notations called diagrams that capture static and dynamic aspects of software-intensive programs - advantages -- support for a diverse array of viewpoints focused on many common software engineering concerns - ubiquity improves comprehensibility - extensive documentation and tool support form many vendors - disadvantages -- needs customization through profiles to reduce ambiguity -- difficult to assess consistency among views -- difficult to capture foreign concepts or views

Wright

- An adl that specifies structure and formal behavioral specifications for interfaces between components and connectors - advantages -- structural specification similar to Darwin or Rapide -- formal interface specifications can be translated automatically into CSP and analyzed with tools - disadvantages - High learning curve - no direct mapping to implemented systems - addresses a small number of system properties relative to cost of use

Darwin

- General purpose language with graphical and textual visualizations focused on structural modeling of systems - advantages -- simple, straightforward mechanism for modeling structural dependencies -- interesting way to specify repeated elements through programmatic constructs -- can be modeled in pi-calculus for formal analysis -- can specify hierarchical structures - disadvantages -- limited usefulness beyond simple structural modeling -- no notion of explicit connectors

Modeling Approaches

- Generic Approaches -- Natural Language -- powerpoint-style modeling -- UML (Unified Language Modeling) - Early Architecture description languages -- Darwin -- Rapide -- Wright - Domain- and style-specific languages -- koala -- weaves -- AADL - Extensible architecture description languages -- ACME -- ADML -- xADL

xADL

- Modular XML-based ABL intended to maximize extensibility both in notation and tools - advantages: -- growing set of generically useful modules available already -- tool support in ArchStudio environment -- users can add their own modules via well-defined extensibility mechanisms - disadvantages -- extensibility mechanisms can be complex and increase learning curve -- heavy reliance on tools

Caveat 2

- Some systems are difficult to model in traditional ways -- Agile systems - large, comlex, or dynamic systems

Weaves

- an architectural style and notation for modeling systems of small-grain tool fragments that communicate through data flow of objects - advantages -- extremely optimized notation (even simpler than Darwin diagrams) -- close mapping to implemented systems - disadvantages -- addresses structure and data flows only

Koala

- darwin inspired notation for specifying product lines of embedded consumer-electronics devices - advantages -- advanced product-line features let you specify many systems in a single model -- direct mapping to implemented systems promotes design and code reuse - disadvantages -- limited to structural specification with additional focus on interfaces

ACME

- early general purpose ADL with support for extensibility through properties - advantages: -- structural specification capabilities similar to Darwin -- simple property structure allows for arbitrary decoration of existing elements -- tool support with AcmeStudio - disadvantages: -- no way to add new views -- property specifications can become extremely complex and have entirely separate syntax/semantics of their own

Informal graphical modeling

- general diagrams produced in tools like powerpoint and omnigraffle - advantages -- can be aesthetically pleasing -- size limitations constrain complex diagrams (multiple slides) -- extremely flexible due to large symbolic vocabulary - disadvantages -- ambiguous, non rigorous, non formal -- cannot be effectively processed or analyzed by software or machines

Rapide

- language and tool-set for exploring dynamic properties of systems of components that communicate through events - advantages -- unique and expressive language for describing asynchronously communicating components -- tool-set supports simulation of models and graphical visualization of event traces - disadvantages -- no natural or explicit mapping to implemented systems -- high learning curve - important tool support is difficult to run on modern machines

Early architecture Description languages

- many emerged from academia - focus on structure: components, connectors, interfaces, configurations - focus on formal analysis - none used in practice today

AADL

- notation and tool-set for modeling hardware/software systems, particularly embedded and real-time systems - advantages -- allows detailed specification of both hardware and software aspects of a system -- automated analysis tools check interesting end-to-end properties of a system - disadvantages -- verbose; large amount of detail required to capture even simple systems -- emerging tool support and UML profile support

Domain- and Style-Specific ADLs

- notations we have surveyed thus far have been limited generically applicable to many types of software systems - if you restrict the target domain, you can provide more advanced features and/or reduce complexity

Informal graphical modeling evaluation

- scope and purpose -- arbitrary diagrams consisting of symbols and text - basic elements -- geometric shapes, splines, clip-art, text segments - style -- in general, no support - static and dynamic aspects -- any aspect can be modeled, but no semantics behind modeling - dynamic modeling -- rare, although APIs to manipulate graphics exist - non functional aspects -- with natural language annotations - ambiguity -- can be reduced through the use of rigorous symbolic vocabulary/dictionaries - accuracy -- manual reviews and inspection - precision -- up to modeler; generally canvas is limited in size - viewpoints -- any viewpoint - viewpoint consistency -- manual reviews and inspection

Natural Language Evaluation

- scope and purpose -- capture design decisions in prose form - basic elements -- any concepts required - style -- can be described by using more general language - static and dynamic aspects -- any aspect can be modeled - dynamic modeling -- no direct tie to implemented/running system - non functional aspects -- expressive vocabulary available - ambiguity -- plain natural language tends to be ambiguous; statement template and dictionaries help - accuracy -- manual reviews and inspection - precision -- can add text to describe any level of detail - viewpoints -- any viewpoint - viewpoint consistency -- manual reviews and inspection

UML evaluation

- scope and purpose -- diverse array of design decisions in 13 viewpoints - basic elements -- multitude (states, classes, objects, etc) - style -- through OCL constraints - static and dynamic aspects -- some static diagrams - dynamic modeling -- rare; depends on the environment - non functional aspects -- no direct support, natural language annotations - ambiguity -- many symbols are interpreted differently depending on context; profiles reduce ambiguity - accuracy -- well-formedness checks, automatic constraint checking - precision -- up to modeler; wide flexibility - viewpoints -- each diagram type represents a viewpoint - viewpoint consistency -- constraint checking, manual

Rapide Evaluation

- scope and purpose -- interactions between components communicating with events - basic elements -- structures, components/interfaces, behaviors - style -- N/A - static and dynamic aspects -- static structure and dynamic behavior is co-modeled - dynamic modeling -- some of the tools provide limited animation capabilities - non functional aspects -- N/A - ambiguity -- well-defined semantics limit ambiguity - accuracy -- compilers check syntax, simulators can be used to check semantics although simulation results are non-deterministic and non-exhaustive - precision -- detailed behavioral modeling possible - viewpoints -- single structural/behavioral viewpoint - viewpoint consistency -- N/A

AADL Evaluation

- scope and purpose -- interconnected multi-level systems architectures - basic elements -- multitude - components, threads, hardware elements, configurations, mappings - style -- N/A - static and dynamic aspects -- primarily static structure but additional properties specify dynamic aspects - dynamic modeling -- N/A - non functional aspects -- N/A - ambiguity -- most elements have concrete counterparts with well-known semantics - accuracy -- structural as well as other interesting properties can be automatically analyzed - precision -- many complex interconnected levels of abstraction and concerns - viewpoints -- many viewpoints addressing different aspects of the system - viewpoint consistency -- mappings and refinement can generally be automatically checked or do not overlap

Darwin evaluation

- scope and purpose -- modeling software structure - basic elements -- components, interfaces, configurations, hierarchy - style -- limited support through programmatic constructs - static and dynamic aspects -- mostly static structure; some dynamic aspects through lazy and dynamic instantiation/binding - dynamic modeling -- N/A - non functional aspects -- N/A - ambiguity -- rigorous, but structural elements can be interpreted in many ways - accuracy -- pi-calculus analysis - precision -- modelers choose appropriate level of detail through hierarchy - viewpoints -- structural viewpoints - viewpoint consistency -- N/A

xADL Evaluation

- scope and purpose -- modeling various architectural concerns with explicit focus on extensibility - basic elements -- components, connectors, interfaces, links, options, variants, versions, ..., plus extensions - style -- limited, through type system - static and dynamic aspects -- mostly static views with behavior and dynamic aspects provided through extensions - dynamic modeling -- models can be manipulated programmatically - non functional aspects -- Through extensions - ambiguity -- base schemas are permissive; extensions add rigor or formality if needed - accuracy -- correctness checkers included in ArchStudio and users can add additional tools through well-defined mechanisms - precision -- base schemas are abstract, precision added in extensions - viewpoints -- several viewpoints provided natively, new viewpoints through extensions - viewpoint consistency -- checkable through external tools and additional consistency rules

Koala Evaluation

- scope and purpose -- structures and interfaces of product lines of component based systems - basic elements -- components, interfaces, elements for variation points: switches, diversity, interfaces, etc - style -- product lines might be seen as very narrow styles - static and dynamic aspects -- static structure only - dynamic modeling -- N/A - non functional aspects -- N/A - ambiguity -- close mappings to implementation limit ambiguity - accuracy -- close mappings to implementations should reveal problems - precision -- structural decisions are fully enumerated but other aspects are left out - viewpoints -- structural viewpoint with explicit points of variation - viewpoint consistency -- N/A

Weaves Evaluation

- scope and purpose -- structures of components and connectors in the weaves style - basic elements -- components, queues, directed interconnections - style -- weaves style implicit - static and dynamic aspects -- static structure only - dynamic modeling -- N/A, although there is a 1 to 1 mapping between model and implementation elements - non functional aspects -- N/A - ambiguity -- meanings of weaves elements are well defined although important elements (protocols) are subject to interpretation - accuracy -- syntactic errors are easy to identify - precision -- structural decisions are fully enumerated but other aspects left out - viewpoints -- structural viewpoint - viewpoint consistency -- N/A

ACME Evaluation

- scope and purpose -- structures of components and connectors with extensible properties - basic elements -- components, connectors, interfaces, hierarchy, properties - style -- through type system - static and dynamic aspects -- static structure is modeled natively, dynamic aspects in properties - dynamic modeling -- AcmeLib allows for programmatic model manipulation - non functional aspects -- Through properties - ambiguity -- meanings of elements subject to some interpretation, properties may have arbitrary level of rigor/formality - accuracy -- checkable syntactically, via type system, and properties by external tools - precision -- properties can increase precision but cannot add new elements - viewpoints -- structural viewpoint is native, properties might provide additional viewpoints - viewpoint consistency -- via external tools that must be developed

Wright Evaluation

- scope and purpose -- structures, behaviors, and styles of systems composed of components and connectors - basic elements -- components, connectors, interfaces, attachments, styles - style -- supported through predicates over instance models - static and dynamic aspects -- static structural models annotated with behavioral specification - dynamic modeling -- N/A - non functional aspects -- N/A - ambiguity -- well-defined semantics limit ambiguity - accuracy -- wright models can be translated into CSP for automated analysis - precision -- detailed behavioral modeling possible - viewpoints -- single structural/behavioral viewpoint plus styles - viewpoint consistency -- style checking can be done automatically

Natural Language

- spoken/written languages such as english - Advantages -- highly expressive -- accessible to stakeholders -- plentiful tools available -- good for capturing non-rigorous or informal architectural elements (non-functional requirements) - Disadvantages -- ambiguous, non-rigorous, non formal -- often verbose (expressed in more words than needed -- cannot be effectively processed or analyzed by software or machines - ambiguity can be reduced and rigor increased by using statement templates

Caveat 1

- the preceding overview for breadth rather than depth -- semantics and capabilities of many of these notations quite deep and subtle -- you are encouraged to investigate individual notations more deeply

Extensible ADLs

- there is tension between the expressiveness of general-purpose ADLs and the optimization and customization of more specialized ADLs - How do we get the best of both worlds? -- use multiple notations in tandem -- overload an existing notation or ADL -- add additional features we want to an existing ADL - extensible ADLs attempt to provide such guidance

ADML Evaluation

SAME AS ACME BUT IN XML