Chapter 6 - Modeling

Chapter 6 - ModelingEduardo Felipe Zecca da CruzDomain- and Style Specific ADLsSome ADLs are domain-specific or style-specific, or at least optimized for describing architectures in a particular domain or styleImportanceScope is better tailored to stakeholder needsUnnecessary details could be left because there is little need for genericityComprisesA reference architecture, which describes a general computational framework for a significant domain of applications;A component library, which contains reusable chunks of domain expertise; andAn application configuration method for selecting and configuring components within the architecture to meet particular application requirements.

KoalaDeveloped by Philips ElectronicsSpecially designed for modeling embedded software for consumer electronicsInherits from DarwinSemantically and syntacticallyUses Darwins structural concepts of input and output portsExpands them through the addition of constructs to support product-line architecturesMultiple products can be described with a single model, with differences between the products encoded as variation points

Evaluation Rubric for KoalaScope and PurposeStructures and interfaces of product lines of component-based systemsBasic ElementsComponents, interfaces, and constructs for variation points: diversify interfaces, switches, etc.StyleProduct lines might be seen as very narrow stylesStatic and Dynamic AspectsStatic structure and interfacesDynamic ModelingN/ANon-Functional AspectsN/AAmbiguityConcrete and closely mapped to implementations. Ambiguity is limitedAccuracyClose mappings to implementations. It is easy to identify problemsPrecisionConfiguration is well defined but other aspects are nor specifiedViewpointsStructural viewpoint with explicit points of variationView ConsistencyN/AWeavesArchitectural style and accompanying notation.Used for modeling systems of small-grain tool fragments that process objects of dataAdvantagesExtremely optimized notationEven simpler than Darwin diagramsClose mapping to implemented systemsDisadvantagesAddresses structure and data flows only

Lunar LanderComponents do not communicate by request-response procedure call. They communicate by streams of objectsBasic flows of data are similar to the other modelsExplicit presence of return channels for dataA request that travels from a way does not imply that a response comes back along the same wayThe response way must be specifiedInformation about structural connections but does not capture aspects of how those connections are usedCould be included with an additional model like natural language

Evaluation Rubric for WeavesScope and PurposeStructures and configuration of components in the Weave styleBasic ElementsComponents, connectors (queues), and directed interconnectionsStyleWeaves style implicitStatic and Dynamic AspectsOnly static structure is modeledDynamic ModelingN/A. Although there is a close correspondence between model and implementation componentsNon-Functional AspectsN/AAmbiguityWell defined and not ambiguousAccuracySyntactic errors are easy to identifyPrecisionComponents and connectors are well defined, but other aspects are not specifiedViewpointsStructural viewpointView ConsistencyN/AAADLIt 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 dataCan capture non-functional aspects of components such as timing, safety, and reliability attributes

AADL ComponentsComponents are defined in two partsComponent typeDefines the interfaces to a componentComponent implementationAn instance of a particular component typeComponents category (additional element that affects components)Can be hardware, software, or composite

More AADLAdvantagesAllows detailed specification of both hardware and software aspects of a systemAutomated analysis tools check interesting end-to-end properties of systemDisadvantagesVerbose; large amount of detail required to capture even simple systems

Lunar LanderJust one part is modelingThe Calculation component and its connection to the Data Store component.The components are connected by a physical Ethernet busReal-time versionActivities are done at regular intervals

Evaluation Rubric for AADLScope and PurposeMultilevel models of interconnected hardware and software elementsBasic ElementsMyriad hardware and software elements: networks, buses, ports, etc.StyleN/AStatic and Dynamic AspectsPrimarily static aspects, but properties can capture some dynamic aspectsDynamic ModelingN/ANon-Functional AspectsN/AAmbiguityMuch of elements have well-understood semantics.Properties add detail about behavior to reduce ambiguityAccuracyStructural and properties can be automatically analyzedPrecisionProperties specify characteristics of each elementViewpointsInterconnected hardware and software viewpointsView ConsistencyOSATE includes several plug-ins for various consistency checksExtensible ADLsCan 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 concernsInclude supportBasic approach to employing an extensible ADL is as followsDetermine which concerns can be modeled using the existing (baseline) capabilities of the ADLFor 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

ACMEHas a base set of seven constructsComponentsConnectorsPortsRolesAttachmentsSystemsRepresentationsPropertiesDecorations that can be applied to any of the basic seven kinds of elements

ACMEAdvantagesStructural specification capabilities similar to DarwinSimple property structure allows for arbitrary decoration of existing elementsTool support with AcmeStudioDisadvantagesNo way to add new viewsProperty specifications can become extremely complex and have entirely separate syntax/semantics of their own

Lunar LanderLargely structural and includes components, connectors, ports, roles and attachmentsVerbosityUse of propertiesAdditional properties could be added using ACME to model Lunar Lander

Evaluation Rubric for ACMEScope and PurposeStructural aspects of a software architecture, with the extensible propertiesBasic ElementsComponents, connectors, ports and roles, attachments, representations and propertiesStyleThrough type systemStatic and Dynamic AspectsStatic structure is modeled natively, dynamic aspects in propertiesDynamic ModelingAcmeLib allows models to be manipulated programmaticallyNon-Functional AspectsThrough propertiesAmbiguityElements are well defined, but external mean is not definedProperties need being accompanied by tools or documentationOtherwise ambiguity could be introducedAccuracyTyping can check elements and properties are checked by external toolsPrecisionProperties can increase precision but is not possible to define new elementsViewpointsStructural viewpoint is native, properties can be used to provide additional viewpointsView ConsistencyVia external tools that must be developedADMLXML-based architectureSyntax derived from ACMEADML is supported by meta-propertiesAdvantagesXML parsers and tools readily availableAdded some ability to reason about types of properties with meta-propertiesDisadvantagesProperties are still name-value pairsDid not take advantage of XML extension mechanisms

Lunar LanderSimilar to ACMEUse of XML opens this specification up to a wider array of toolsVerbose is denser than in ACME

xADLXML-based languageAn 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 entitiesOn the other languages they are added as extensions to other entities

xADLAdvantagesGrowing set of generically useful modules available alreadyTool support in ArchStudio environmentUsers can add their own modules via well-defined extensibility mechanismsDisadvantagesExtensibility mechanisms can be complex and increase learning curveHeavy reliance on tools

xADL Data Binding LibraryIt is a software library that provides an API for parsing, reading, writing, and serializing documents in a particular languageIn xADL it is a set of Java classes that correspond to xADL data typesData Binding Library provides a simple interface to make these operations (read, write, query, manipulate)ApigenIt is a xADLs data binding library generatorGiven a set of XML schemas, the Apigen can generate the complete data binding library with support for those schemasFor any changes or adds, Apigen will generate a new data binding library by rerunning

Lunar LanderSimilar to ADML and ACMEHas an associated graphical visualization provided by an editor called ArchipelagoApplication can be extended using new schemas and these schemas can be reused in another projects

Evaluation Rubric for xADLScope and PurposeModeling different architectural concerns with support for extensibilityBasic ElementsComponents, connectors, interfaces, links, options, variants, versions, plus any basic elements defined in extensionsStyleThrough the use of types and type librariesStatic and Dynamic AspectsStatic structure is modeled natively, dynamic properties can be captured through extensions.Dynamic ModelingxADL data binding library allows models to be manipulated programmaticallyNon-Functional AspectsThrough extensionsAmbiguityBase schemas are permissiveExtensions add rigor or formality if neededAccuracyTools check the correctness of xADL documentsUsers can add additional constraints into these tools to handle extensionsPrecisionBase schemas are abstract; Extensions can be used to add precisionViewpointsStructural viewpoints are natively supportedExtensions can be used to provide additional viewpointsView ConsistencyExternal tools can check the consistencyWhen Systems Become too Complex to ModelCertain applications cannot be modeled using the techniques that were used on the Lunar Lander exampleGigantic and diverse applications like the Web or GnutellaImpossible to generate a model of these systems in the traditional components-connectors-and-configuration senseThere are some strategies to consider to model these systems

StrategiesModel Limited Aspects of the ArchitectureUse CasesInteraction PatternsMore limited and easier to be modeledModel an InstanceConsider if a complete model is neededModeling only the relevant portion of the system

StrategiesExploit RegularityLarge systems have low heterogeneityThese large portions can be modeled once and repeated automaticallyModel the StyleInstead of modeling as an application, consider modeling the REST style insteadWEB is based on the REST architectureModel the ProtocolModel protocol detailsHTTP example on the Web

ReferencesTaylor, R. N., & Medvidovic, N. (2010).Software architecture: foundations, theory, and practice. Hoboken, N.J.: Wiley.Modeling and Notations - http://www.softwarearchitecturebook.com/svn/main/slides/ppt/10_Modeling_and_Notations.pptDomain-Specific Software Architecture and Product Lines http://www.csse.usc.edu/classes/cs578_2013/DSSE.ppt