Architecture Description Languages and Architecture Viewpoints

1. Architecture Description Languages and Architecture Viewpoints Kellan Hilscher

2. Software Architecture Descriptions • Definition • Different perspectives on the components, behavioral specifications, and interactions that make up a software system • Importance of Formalized Architecture • Architectural decisions have a very long lifespan • Very valuable tool in developer and stakeholder understanding of a system at a high level • Increased potential for commonality across architectures. • Reduces time spent in maintenance and evolution phases

3. Architecture Description Languages (ADLs) • Formal languages that can be used to represent the architecture of software-intensive systems. • Evolved from Module Interconnection Languages • Allow for very high level views of a system even before design work begins • Allow for early analysis and feasibility testing of architectural possibilities • How ADLs Work • Decompose a system into multiple components, connections, and configurations • Standardization through the use of styles • Provide different views of a system’s architecture

4. Architectural Viewpoints • Definition • Diverse representations of a system’s architecture for distinct audiences and uses • Ex. Structural, behavioral, physical • Viewpoints address concerns identified by particular stakeholders • Ex. A process viewpoint might address concurrency, distribution, scalability, and integration

5. Some ADLs

6. Acme – Carnegie Mellon University • First version released in 1997 • Similar to IBM Rational for UML • Two components: • Acme ADL • AcmeStudio • Can act as a vehicle for standardizing elements used across multiple ADLs

8. AADL – TELECOM ParisTech • Architecture (formerly Avionics) Analysis & Design Language • Describes DRE architectures with software and hardware components • Dissuades “build then test” mentality

10. ArchC • Specialized for processor architecture description. • Allows users to generate assemblers and simulators for processors from: • Architecture Resources: User provides processor resource info from programmer’s manual • Instruction Set Architecture: User enters information about each instruction such as format and syntax, behavior, and info for decoding • Tailors the modeling environment to your processor

11. ArchC Example

12. Existing ADLs are far from perfect

13. ADL Shortcomings • No clear consensus on what is required of architecture modeling (or ADLs) • Can be very convoluted • Many lack explicit mechanisms for multiple architecture views.

15. UML as an ADL

16. UML Shortcomings as an ADL • “[A]n ADL for software application focuses on the high-level structure of the overall application rather than the implementation details of any specific source module” • Less formalized than ADLs • No notion of entity restriction (styles) • Largely a documenting language

17. Krutchen’s Architecture Model

18. Krutchen’s 4+1 View Model • Idea: • One view cannot capture an entire complex architecture • Concurrent views: • 4: • Logical View – Object Model • Process View – Concurrency Model • Physical View – Mapping and distribution of software to hardware • Development View – Development environment view • +1: • Use Cases/Scenarios

19. Logical Architecture

20. Process Architecture

21. Development Architecture

22. Physical Architecture

23. Why Krutchen’s Model?

24. It can be approximated with UML! • Logical Model -> Class Diagram • Process Model -> Activity Diagram • Development Model -> Package Diagram • Physical Model -> Deployment Diagram

25. Object Constraint Language • Wraps the notion of component standardization around design languages: • Contexts (styles) • Properties (style conformant attributes) • Operations (define property behavior) • Provides additions to graph navigations • Less ambiguity • OCL tools parse UML diagrams to provide further analysis

26. 4+1, UML, and OCL

27. Questions?