Domains of Concern in Software Architectures and Architecture Description Languages

1
Domains of Concern in Software Architectures and
Architecture Description Languages

• Nenad Medvidovic and David S. Rosenblum
• Proceedings of the 1997 USENIX Conference on
  Domain-Specific Languages
• 2003. 1. 29
• Presented by Cheol-Ho, Kim

2
Contents

• Introduction
• Overview of ADLs
• Architectural Domains
• ADL Support for Architectural Domains
• Architectural vs. Application Domains
• Conclusion

3
Introduction (1/2)

• Software Architecture
• A level of design that goes beyond the algorithms
  and data structures of the computation designing
  and specifying the overall system structure
• To obtain the benefits of an architectural focus,
  it needs its own body of specification languages
• Lacks of consensus in the research community
• What is an ADL?
• What should aspects of an architecture be modeled
  by ADL?
• What should be interchanged in an interchange
  language?

ADL
Wide variation of approaches in first generation
ADL
4
Introduction (2/2)

• Architectural Domain
• Problems or areas of concern that need to be
  address by ADLs
• Framework of architectural domains
• Presents important concerns to be modeled by ADLs
• Helps to understand existing ADLs from the view
  of their concerns to be expressed
• Gives a sound foundation for selecting an ADL and
  developing a new ADL

5
Overview of ADLs (1/3)

• Definition of ADLs
• An ADL focuses on the high-level structure of the
  overall application rather than the
  implementation details
• Building blocks of ADLs
• components
• units of computation or data stores
• connectors
• units used to model interactions among components
  and rules that govern those interaction
• architectural configurations
• connected graph of components and connectors that
  describe architectural structure

6
Overview of ADLs (2/3)

• Formal semantic theory
• Underlying framework for characterizing
  architectures
• Petri nets, Statecharts, partially-ordered sets,
  CSP, etc.
• Categorizing ADLs
• implicit configuration languages
• Interconnection information is distributed across
  definitions of individual components and
  connectors
• in-line configuration languages
• Specify connector information only as part of
  configuration, in line
• explicit configuration languages
• model both components and connectors separately
  from configurations

7
Overview of ADLs (3/3)

• Application of ADLs
• Wright
• RunTime Infrastructure of DoD High-Level
  Architecture for Simulations
• Condense the specification and reveal several
  inconsistencies and weakness in it
• SADL
• Operational power-control system of Tokyo
  Electric Power Company
• Formalize the systems reference architecture and
  ensure its consistency with the implementation
  architecture
• Rapide
• X/Open Distributed Transaction Processing (DTP)
  standards
• Reference architecture is specified and simulated
  by Rapide

8
Architectural Domains

• ADL developer focus on a specific aspect of
  architectures or an architectural domain
• A framework for classifying the problems on which
  architectural models focus

9
ADL Support for Architectural Domains(1/10)

• Explain each architectural domain and Show some
  ADLs as examples
• Understand the kinds of language facilities
  needed in each architectural domain
• Classify architecture modeling language in terms
  of architectural domains

10
ADL Support for Architectural Domains(2/10)

• Representation
• To communicate with stakeholders, ADL needs to be
  simple, understandable, and possibly graphical
  and support multiple perspectives
• Support graphical notation
• Aesop, C2, Darwin, MetaH, Rapide and UniCon
• Support multiple views
• C2 development process view
• Darwin hierarchical view
• Rapide behavior visualization with simulation

11
ADL Support for Architectural Domains(3/10)

• Design Process Support
• To support the design process, ADL tool needs to
  reduce the cognitive load on architects
• Proactive
• UniCons graphical editor prevents errors during
  design
• Reactive
• Non-intrusive
• C2s design environment informs the architect of
  the error
• Intrusive
• MetaHs graphical editor forces the architect to
  correct it before moving on

12
ADL Support for Architectural Domains(4/10)

• Analysis
• To lessen the number of errors passed downstream,
  ADL need to be able to evaluate the properties of
  target system at architectural level
• Static Analysis
• Before execution, for example, internal
  consistency check
• Static analysis tool like parser and compiler
• Darwin, MetaH, Rapide, UniCon
• Dynamic Analysis
• At run time, for example, testing, assertion
  checking
• Depends on the ADLs ability to model its dynmaic
  behavior
• Rapide facilitates dynamic analysis through
  simulation and constraint checker

13
ADL Support for Architectural Domains(5/10)

• Evolution
• Architectural evolution is a key aspect of
  support for software evolution
• Specification-Time Evolution
• Support for incremental development
• Accommodate addition of new components to the
  architecture
• explicit configuration ADLs
• Support for incomplete architectural descriptions
• Wright focuses its analyses on a single connector
• Support for system families
• ACME a language construct that allows to
  specify the family of the architecture

14
ADL Support for Architectural Domains(6/10)

• Evolution (Continued)
• Execution-Time Evolution
• Constrained dynamism
• Rapid a form of architectural rewriting at
  runtime
• Darwin runtime replication of components
• Pure dynamism
• Darwin deletion and rebinding of components by
  interpreting Darwin scripts
• C2 a set of operations for insertion, removal,
  and rewriting of elements in an architecture at
  runtime

15
ADL Support for Architectural Domains(7/10)

• Refinement
• ADL needs to support correct and consistent
  refinement of architectures from high to low
  level of abstraction
• Provides patterns or maps, that , when applied to
  an architecture, result in a related architecture
  at a lewer level of abstraction
• SADL maps to enable correct architecture
  refinements across styles
• Rapide comparative simulations of architectures
  at different abstraction levels
• Implementation constraining languages
• MetaH, UniCon

16
ADL Support for Architectural Domains(8/10)

• Traceability
• An architecture must be consistent with other
  architectures of multiple views and multiple
  levels of abstraction and requirements
• Most ADLs are lacking this aspect except tracing
  changes between textual and graphical views

17
ADL Support for Architectural Domains(9/10)

• Simulation/Executability
• For dynamic properties like shedulability or
  reliability, ADL tools need to support simulation
• Rapide
• An architectural model is of limited value,
  unless it can be converted into a running
  application
• Aesop, C2, Darwin, MetaH, Rapide, UniCon

18
ADL Support for Architectural Domains(10/10)
19
Architectural vs. Application Domains

• Application domain characteristics by Jackson
• static vs. dynamic domains
• one-dimensional vs. multi-dimensional domains
• tangible vs. intangible domains
• inert vs. reactive vs. active dynamic domains
• autonomous vs. programmable vs. biddable active
  dynamic domains
• Examples of relationship
• Dynamic domain evolution, executability,
  dynamic analysis
• Reactive domain representation

20
Conclusion

• A first step towards a solution to following
  problem
• What problems should architectures solve?
• Defines architectural domains and classifies
  selected ADLs
• Future Works
• New technique to support the needs of particular
  architectural domains
• More research on relationships between
  architectural and application domains

21
Foci of ADLs (1/2)

• ACME
• Architectural interchange, predominantly at the
  structural level
• Aesop
• Specification of architectures in specific styles
• C2
• Modeling architectures in the multi-level
  notify/request C2 style
• Darwin
• Architectures of highly-distributed systems whose
  dynamism is guided by strict formal underpinnings
• MetaH
• Architectures in the guidance, navigation, and
  control(GNC) domain(ex. embedded systems)

22
Foci of ADLs (2/2)

• Rapide
• Modeling and simulation of the event-based
  architectures
• SADL
• Formal refinement of architectures across levels
  of detail
• UniCon
• Glue code generation for interconnecting existing
  components using common interaction protocols
• Wright
• Modeling and analysis (specifically, deadlock
  analysis) of the dynamic behavior of concurrent
  systems