ADML: A Building Block Description Language

1
ADML A Building Block Description Language
Tw Cook 1-512-338-3522 tw_at_mcc.com

• SSEP Project
• Architecture
• SSEP ADL Decision
• ACME
• ACME ? ADML
• ADML vs. Building Blocks
• TOGAF Appendix J Example
• Summary
• More Info

2
MCCs SSEP Project

• Software and Systems Engineering Productivity is
  a three year project at MCC focused on supporting
  a product line approach to software the
  premise is that with proper tool and process
  support, each product in the product line can
  achieve dramatic levels of reuse.
• A product line is a group of products sharing a
  common, managed set of features that satisfy
  needs of a selected market or mission.
  
• Product lines amortize the investment in these
  and other assets
  
• requirements and requirements analysis
• domain model
• software architecture and design
• performance engineering
• documentation
• test plans, test cases, and data
• people their knowledge and skills
• processes, methods, tools, and estimates
• software implementation

3
Architecture is Key

• A software architecture describes the structural
  properties of the software, typically the
  components and their interrelationships and
  guidelines about their use.
• Architecture is the foundation for the product
  line.
  
• Architecture forms the organizational plan for
  component development.
  
• Architecture is the root of system qualities.
• Architecture ensures that variability across
  products can be accomplished by changes confined
  to one or a select set of components.
  
• SSEP addresses these Product Line Issues
  identified by SEI
  
• Architecture representation
• Architecture evaluation
• Tool support

Source SEI http//www.sei.cmu.edu/plp/essential
s_slides/index.html
4
Architecture-Based Product Line Development
Domainrequirements
Unsatisfied constraints, errors
Domain Modeling
Product Line Ref Arch Spec
Changes,Unsatisfied constraints,Errors,Adaptati
ons
Reusable Component Acquisition
ReferenceArchitecture
Product Reqt Defn
ProductRequirements
ImportedComponents
ProductSpec
Reuse Library and Generator
Product Design
Components Glueware
Executable Model
ProductConstraints
Product Implemen-tation
ProductArchitecture
ApplicationSystem
Unsatisfied constraints, errors, adaptations
Source Frank Belz TRW
5
SSEP ADL Decision

• ACME would meet our needs well, except for these
  key requirements
  
• Extensibility other than via properties
• Ability to use standardized parsers, editors,
  other tools
  
• Ability to link architectural components, etc. to
  other lifecycle artifacts
  
• We chose to design an XML implementation of ACME
  which would give us all the advantages of ACME,
  plus these additional features. We called this
  the Architecture Description Markup Language,
  or ADML
• We are in the process of constructing a graphical
  tool, called VisualADML which allows us to more
  easily construct ADML, and to manage links with
  other tools

6
Advantages of XML Adoption

• Industry standard
• Microsoft, Netscape, IBM, Oracle, Sun, Rational
• Leverage existing or announced collaborative
  technologies
  
• Web browsers
• MS Office 2000
• Other commercial tools
• Analysis
• common format
• common (commercial) parsers
• Views
• codify info. needed for differing views

• Adaptable format
• Architecture model
• Document
• Presentation
• Gaining acceptance as repository standard
• Microsoft
• Oracle
• Poet
• Flexible and extensible
• Accommodate evolution of ADL
• Traceability
• directly associate artifacts (bi-directional)
• rationale capture, etc

7
ACME

• The Acme Architectural Description Language
• Acme is a simple, generic software architecture
  description language (ADL) that can be used as a
  common interchange format for architecture design
  tools and/or as a foundation for developing new
  architectural design and analysis tools.
• Overview of the Acme Project
• The Acme project began in 1995 with the goal of
  providing a common language that could be used to
  support the interchange of architectural
  descriptions between a variety of architectural
  design tools.
• Although it is still useful as an architectural
  interchange language, since the project's
  inception the Acme language and its supporting
  toolkit have grown into a solid foundation upon
  which new software architecture design and
  analysis tools can be built without the need to
  rebuild standard infrastructure.

8
ACME Language/Toolkit Capabilities

• Architectural Interchange.
• Acmes generic interchange format allows
  architectural tool developers to readily
  integrate their tools with other complementary
  tools. Likewise, architects using Acme-compliant
  tools have a broader array of analysis and design
  tools available at their disposal than architects
  locked into a single ADL.
• Foundation for New Architecture Design Analysis
  Tools.
  
• Acme provides a solid, extensible foundation and
  infrastructure that allows tool builders to avoid
  needlessly rebuilding standard tooling
  infrastructure.
• Architecture Description.
• Acme has emerged as a useful architecture
  description language in its own right. It
  provides a straightforward set of language
  constructs for describing architectural
  structure, architectural types and styles, and
  annotated properties of the architectural
  elements.

9
ACME Language Features

• The Acme language provides the following key
  features
  
• an architectural ontology consisting of seven
  basic architectural design elements
  
• a flexible annotation mechanism supporting
  association of non-structural information using
  externally defined sublanguages
  
• a type mechanism for abstracting common, reusable
  architectural idioms and styles and
  
• an open semantic framework for reasoning about
  architectural descriptions.

10
Acme Design Element Types

• Acme is built on a core ontology of seven types
  of entities for architectural representation
  components, connectors, systems, ports, roles,
  representations, and rep-maps. The most basic
  elements of architectural description are
  components, connectors, and systems.
• Components
• the primary computational elements and data
  stores of a system. Intuitively, they correspond
  to the boxes in box-and-line descriptions of
  software architectures.
• Connectors
• represent interactions among components.
  Computationally speaking, connectors mediate the
  communication and coordination activities among
  components. Informally they provide the ''glue''
  for architectural designs, and intuitively, they
  correspond to the lines in box-and-line
  descriptions.
• Systems
• represent configurations of components and
  connectors.

11
Ports and Roles

• Ports
• Components interfaces are defined by a set of
  ports. Each port identifies a point of
  interaction between the component and its
  environment. A component may provide multiple
  interfaces by using different types of ports. A
  port can represent an interface as simple as a
  single procedure signature, or more complex
  interfaces, such as a collection of procedure
  calls that must be invoked in certain specified
  orders, or an event multi-cast interface point.
• Roles
• Connectors also have interfaces that are defined
  by a set of roles. Each role of a connector
  defines a participant of the interaction
  represented by the connector. Binary connectors
  have two roles such as the caller and callee
  roles of an RPC connector, the reading and
  writing roles of a pipe, or the sender and
  receiver roles of a message passing connector.
  Other kinds of connectors may have more than two
  roles. For example an event broadcast connector
  might have a single event-announcer role and an
  arbitrary number of event-receiver roles.

12
A Simple Example
System simple_cs Component client Port sen
d-request Component server Port receive-reque
st Connector rpc Roles caller, callee Att
achments client.send-request to rpc.caller
server.receive-request to rpc.callee
The client component is declared to have a single
send-request port, and the server has a single
receive-request port. The connector has two roles
designated caller and callee. The topology of
this system is declared by listing a set of
attachments.
13
Rep-map

• When a component or connector has an
  architectural representation there must be some
  way to indicate the correspondence between the
  internal system representation and the external
  interface of the component or connector that is
  being represented. A rep-map (short for
  representation map) defines this
  correspondence.
• In the simplest case a rep-map provides only an
  association between internal ports and external
  ports (or, for connectors, internal roles and
  external roles). In other cases the map may be
  considerably more complex. For those cases the
  rep-map is essentially a tool-interpretable
  placeholdersimilar to the use of properties
  described next.

14
Acme Properties

• The design elements define the structure of an
  architecture as a hierarchical graph of
  components and connectors.
  
• There is a need for more auxiliary information
  that determines such things as the run-time
  semantics of the system, detailed typing
  information (such as types of data communicated
  between components), protocols of interaction,
  scheduling constraints, and information about
  resource consumption.
• Acme supports annotation of architectural
  structure with lists of properties. Each property
  has a name, an optional type, and a value. Any of
  the seven kinds of Acme architectural design
  entities can be annotated.
• The properties are uninterpreted values.
  Properties become useful only when a tool makes
  use of them for analysis, translation, and
  manipulation. In Acme the type of a property
  indicates a sublanguage with which the property
  is specified.
• Several property sublanguages are currently being
  developed.

15
ACME ? ADML Example

• System simple_cs
• Component client
• Port send-request
• Properties request-ratefloat 17.0
• source-codeexternal-file Code-Lib/client.c
  
  
• Component server
• Port send-request
• Properties idempotenceboolean true
• max-concurrent-clientsinteger 1
• source-codeexternal-file Code-Lib/server.c
  
  
• Connector rpc
• Role caller
• Role callee
• Properties synchronousboolean true
• max-rolesinteger 2
• protocolWright
• Attachments client.send-request to rpc.caller
• server.receive-request to rpc.callee

• type float
• 17.0
• type external-file
• Code-Lib/client.c

16
ACME ? ADML Example, Continued

• System simple_cs
• Component client
• Port send-request
• Properties request-ratefloat 17.0
• source-codeexternal-file Code-Lib/client.c
  
  
• Component server
• Port send-request
• Properties idempotenceboolean true
• max-concurrent-clientsinteger 1
• source-codeexternal-file Code-Lib/server.c
  
  
• Connector rpc
• Role caller
• Role callee
• Properties synchronousboolean true
• max-rolesinteger 2
• protocolWright
• Attachments client.send-request to rpc.caller
• server.receive-request to rpc.callee

• type boolean
• true
• ents
  
• type integer
• 1
• type external-file
• Code-Lib/server.c

17
ACME ? ADML Example, Continued

• System simple_cs
• Component client
• Port send-request
• Properties request-ratefloat 17.0
• source-codeexternal-file Code-Lib/client.c
  
  
• Component server
• Port send-request
• Properties idempotenceboolean true
• max-concurrent-clientsinteger 1
• source-codeexternal-file Code-Lib/server.c
  
  
• Connector rpc
• Role caller
• Role callee
• Properties synchronousboolean true
• max-rolesinteger 2
• protocolWright
• Attachments client.send-request to rpc.caller
• server.receive-request to rpc.callee

• type boolean
• true
• type integer
• 2
• type Wright

18
ACME ? ADML Example, Continued

• System simple_cs
• Component client
• Port send-request
• Properties request-ratefloat 17.0
• source-codeexternal-file Code-Lib/client.c
  
  
• Component server
• Port send-request
• Properties idempotenceboolean true
• max-concurrent-clientsinteger 1
• source-codeexternal-file Code-Lib/server.c
  
  
• Connector rpc
• Role caller
• Role callee
• Properties synchronousboolean true
• max-rolesinteger 2
• protocolWright ...
• Attachments client.send-request to rpc.caller
• server.receive-request to rpc.callee

• rh rpc.caller
• rh rpc.callee

19
ADML vs. Building Blocks

• Building Block
• Corresponds to ADML component
• BB Description
• Represented as ADML identifier and properties
  attached to component
  
• BB Port
• Represented as ADML port
• BB Properties
• Represented as additional ADML properties
• BB Dependencies
• Dependencies such as authentication service, SSO,
  mgmt. protocol, directory service can all be
  represented as ADML connectors

20
Validating Example TOGAF Appendix J

• ADML interpretation of the architecture used as
  an example in Appendix J of The Open Group
  Architectural Framework - Version 4
  
• http//www.opengroup.org/public/arch/appxj.htm
• Method use VisualADML to construct the
  architecture
  
• Presented here partial ADML screen view of the
  visualization

21
Top Level (Partial System)
22
Configuration Ordering System
23
Communication System
24
Appendix J ADML

•   Example.lvml? id"203620442243435" name"Configuration
  Ordering System" id"203620497883499" name"SOAP 2 client" 
  name"remote access I/F" /   ation " name"communication system" 
   
  name"CIS I/F" /   id"203620513874295" name"SOAP 1 I/F" /  
  name"PCS I/F" /   id"203620519379323" name"Product IS I/F" /  
  name"Price IS I/F" /   id"203620524032383" name"Order IS I/F" /  
  id"203620499587437" name"SOAP 1 server" 
   
  id"203620501225838" name"Customer Information
  System"  " /   name"DBMS I/F" /  
  name"Product Configuration System" 
   
  

25
Appendix J ADML, Continued

• name"Product Information System" 
   
  name"DBMS I/F" /  
  name"Price Information System" 
   
  name"DBMS I/F" /  
  name"Order Information System" 
   
  name"DBMS I/F" /  
  name"DBMS"  id"203620530454915" /   id"203620535173509" /   id"203620537008519" /   id"203620539105673" /   n  id"203620442440044" name"Communication
  System" id"203620453646703" name"SOAP2 client" 
  name"RAS" /   onentDeclaration id"203620453908848"
  name"RAS"  id"203620461904246" /   id"203620462166391" name"network protocol" /  
  

26
Appendix J ADML, Continued

• name"internal network"  id"203620462428536" /   id"203620462690681" name"network protocol" /  
  name"network protocol" /   tion name"application comm. package" 
   
  id"203620459413875" name"Network Adaptor" 
   
  name"application interface" /  
  id"203620460462452" name"application" 
   
  id"203620595269995" name"RAS" 
   
  name"remote request receiver" /  
    tion id"203620596580718" portID"203620461642101"
  roleID"203620596056428" /   aration id"203620597236079" portID"2036205963185
  73" roleID"203620461904246" /

27
Appendix J ADML, Continued

• name"network protocol"  id"203620610933105" /   id"203620611195250" name"network request
  receiver" /    
  portID"203620462166391" roleID"203620610933105"
  /   " portID"203620611195250" roleID"203620462428536
  " /    

28
Summary

• ADML is a superset of TOGAFs proposed building
  block notation, and thus is an excellent
  candidate for use in describing building blocks
  and their assembly into systems
• ADML builds on ACME, and makes it possible to
  take advantage of ACME analysis tools, as well as
  other ADL related tools that take advantage of
  ACMEs interchange language status
• ADML is extensible via standard XML mechanisms,
  so can evolve to meet future needs
  
• ADML can be parsed, edited, and viewed by
  standard XML tools

29
For More Information

• ACME http//www.cs.cmu.edu/acme
• SSEP http//www.mcc.com/projects/ssepp
• ADML http//www.mcc.com/projects/ssepp/adml
• A possibly more current version of this
  presentation and the TOGAF example can be found
  at http//www.mcc.com/projects/ssepp/adml/tog