Chapter 6 - Modeling
Eduardo Felipe Zecca da Cruz
Domain- and Style – Specific ADLs
• Some ADLs are domain-specific or style-specific, or at least optimized for describing architectures in a
particular domain or style
• Importance
•
•
Scope is better tailored to stakeholder needs
Unnecessary details could be left because there is little need for genericity
• Comprises
•
•
•
A reference architecture, which describes a general computational framework for a significant domain of applications;
A component library, which contains reusable chunks of domain expertise; and
An application configuration method for selecting and configuring components within the architecture to meet particular
application requirements.
Koala
• Developed by Philips Electronics
• Specially designed for modeling embedded software for consumer electronics
• Inherits from Darwin
•
•
•
•
Semantically and syntactically
Uses Darwin’s structural concepts of input and output ports
Expands them through the addition of constructs to support product-line architectures
Multiple products can be described with a single model, with differences between the
products encoded as variation points
Evaluation Rubric for Koala
Scope and Purpose
Structures and interfaces of product lines of component-based systems
Basic Elements
Components, interfaces, and constructs for variation points: diversify interfaces, switches, etc.
Style
Static and Dynamic
Aspects
Dynamic Modeling
Product lines might be seen as very narrow styles
Static structure and interfaces
Non-Functional
Aspects
Ambiguity
N/A
Accuracy
Precision
Viewpoints
View Consistency
N/A
Concrete and closely mapped to implementations.
Ambiguity is limited
Close mappings to implementations.
It is easy to identify problems
Configuration is well defined but other aspects are nor specified
Structural viewpoint with explicit points of variation
N/A
Weaves
• Architectural style and accompanying notation.
• Used for modeling systems of small-grain tool fragments that process objects of data
• Advantages
• Extremely optimized notation
• Even simpler than Darwin diagrams
• Close mapping to implemented systems
• Disadvantages
• Addresses structure and data flows only
Lunar Lander
• Components do not communicate by request-
response procedure call. They communicate by
streams of objects
• Basic flows of data are similar to the other
models
• Explicit presence of return channels for data
•
A request that travels from a way does not imply
that a response comes back along the same way
•
The response way must be specified
• Information about structural connections but
does not capture aspects of how those
connections are used
• Could be included with an additional model like
natural language
Evaluation Rubric for Weaves
Scope and Purpose
Structures and configuration of components in the Weave style
Basic Elements
Style
Static and Dynamic
Aspects
Components, connectors (queues), and directed interconnections
Weaves style implicit
Only static structure is modeled
Dynamic Modeling
N/A.
Although there is a close correspondence between model and implementation components
Non-Functional Aspects N/A
Ambiguity
Accuracy
Precision
Viewpoints
View Consistency
Well defined and not ambiguous
Syntactic errors are easy to identify
Components and connectors are well defined, but other aspects are not specified
Structural viewpoint
N/A
AADL
• It contains useful constructs and capabilities for modeling a wide variety of
embedded and real-time systems such as automotive and medical systems.
• Can describe interfaces to components for both the flow of control and data
• Can capture non-functional aspects of components such as timing, safety,
and reliability attributes
AADL Components
• Components are defined in two parts
• Component type
• Defines the interfaces to a component
• Component implementation
• An instance of a particular component type
• Component’s category (additional element that affects components)
• Can be hardware, software, or composite
More AADL
• Advantages
• Allows detailed specification of both hardware and software aspects of a system
• Automated analysis tools check interesting end-to-end properties of system
• Disadvantages
• Verbose; large amount of detail required to capture even simple systems
Lunar Lander
• Just one part is modeling
• The Calculation component and its connection to the Data Store component.
• The components are connected by a physical Ethernet bus
• Real-time version
• Activities are done at regular intervals
Evaluation Rubric for AADL
Scope and Purpose
Basic Elements
Style
Static and Dynamic
Aspects
Multilevel models of interconnected hardware and software elements
Myriad hardware and software elements: networks, buses, ports, etc.
N/A
Primarily static aspects, but properties can capture some dynamic aspects
Dynamic Modeling
Non-Functional
Aspects
N/A
N/A
Ambiguity
Much of elements have well-understood semantics.
Properties add detail about behavior to reduce ambiguity
Accuracy
Precision
Viewpoints
View Consistency
Structural and properties can be automatically analyzed
Properties specify characteristics of each element
Interconnected hardware and software viewpoints
OSATE includes several plug-ins for various consistency checks
Extensible ADLs
• Can be used to combine the flexibility of generic languages with the analyzability and
precision of semantically rich languages.
• Provide a basic set of constructs for describing certain common architectural concerns
• Include support
• Basic approach to employing an extensible ADL is as follows
• Determine which concerns can be modeled using the existing (baseline) capabilities of the ADL
• For those concerns that cannot be modeled using the baseline capabilities, choose how to extend the
ADL to support their modeling (or reuse an extension developed by another user)
• Extend the ADL and its supporting tools as necessary to support the modeling of the unique features
ACME
• Has a base set of seven constructs
•
•
•
•
•
Components
Connectors
Ports
Roles
Attachments
• Systems
• Representations
• Properties
• Decorations that can be applied to any of the basic seven kinds of elements
ACME
• 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
Lunar Lander
• Largely structural and includes components, connectors, ports, roles and
attachments
• Verbosity
• Use of properties
• Additional properties could be added using ACME to model Lunar Lander
Evaluation Rubric for ACME
Scope and Purpose
Basic Elements
Style
Static and Dynamic
Aspects
Structural aspects of a software architecture, with the extensible properties
Components, connectors, ports and roles, attachments, representations and properties
Through type system
Static structure is modeled natively, dynamic aspects in properties
Dynamic Modeling
AcmeLib allows models to be manipulated programmatically
Non-Functional Aspects Through properties
Ambiguity
Elements are well defined, but external mean is not defined
Properties need being accompanied by tools or documentation
Otherwise ambiguity could be introduced
Accuracy
Precision
Viewpoints
View Consistency
Typing can check elements and properties are checked by external tools
Properties can increase precision but is not possible to define new elements
Structural viewpoint is native, properties can be used to provide additional viewpoints
Via external tools that must be developed
ADML
•
•
•
•
XML-based architecture
Syntax derived from ACME
ADML is supported by meta-properties
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
Lunar Lander
• Similar to ACME
• Use of XML opens this specification up to a wider array of tools
• Verbose is denser than in ACME
xADL
• XML-based language
• An attempt to provide a platform upon which common modeling features
can be reused from domain to domain and new features can be created and
added to the language as first-class entities
• On the other languages they are added as extensions to other entities
xADL
• 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
xADL Data Binding Library
• It is a software library that provides an API for parsing, reading, writing, and
serializing documents in a particular language
• In xADL it is a set of Java classes that correspond to xADL data types
• Data Binding Library provides a simple interface to make these operations
(read, write, query, manipulate)
Apigen
• It is a xADL’s data binding library generator
• Given a set of XML schemas, the Apigen can generate the complete data
binding library with support for those schemas
• For any changes or adds, Apigen will generate a new data binding library by
rerunning
Lunar Lander
• Similar to ADML and ACME
• Has an associated graphical
visualization provided by an editor
called Archipelago
• Application can be extended using
new schemas and these schemas can
be reused in another projects
Evaluation Rubric for xADL
Scope and Purpose
Basic Elements
Style
Static and Dynamic
Aspects
Dynamic Modeling
Non-Functional Aspects
Ambiguity
Accuracy
Precision
Viewpoints
View Consistency
Modeling different architectural concerns with support for extensibility
Components, connectors, interfaces, links, options, variants, versions, plus any basic elements defined in
extensions
Through the use of types and type libraries
Static structure is modeled natively, dynamic properties can be captured through extensions.
xADL data binding library allows models to be manipulated programmatically
Through extensions
Base schemas are permissive
Extensions add rigor or formality if needed
Tools check the correctness of xADL documents
Users can add additional constraints into these tools to handle extensions
Base schemas are abstract; Extensions can be used to add precision
Structural viewpoints are natively supported
Extensions can be used to provide additional viewpoints
External tools can check the consistency
When Systems Become too Complex to Model
• Certain applications cannot be modeled using the techniques that were used
on the Lunar Lander example
• Gigantic and diverse applications like the Web or Gnutella
• Impossible to generate a model of these systems in the traditional
components-connectors-and-configuration sense
• There are some strategies to consider to model these systems
Strategies
• Model Limited Aspects of the Architecture
• Use Cases
• Interaction Patterns
• More limited and easier to be modeled
• Model an Instance
• Consider if a complete model is needed
• Modeling only the relevant portion of the system
Strategies
• Exploit Regularity
• Large systems have low heterogeneity
• These large portions can be modeled once and repeated automatically
• Model the Style
• Instead of modeling as an application, consider modeling the REST style instead
• WEB is based on the REST architecture
• Model the Protocol
• Model protocol details
• HTTP example on the Web
References
• Taylor, R. N., & Medvidović, N. (2010).Software architecture: foundations, theory,
and practice. Hoboken, N.J.: Wiley.
• Modeling and Notations http://www.softwarearchitecturebook.com/svn/main/slides/ppt/10_Model
ing_and_Notations.ppt
• Domain-Specific Software Architecture and Product Lines –
http://www.csse.usc.edu/classes/cs578_2013/DSSE.ppt