Download
architecture description languages and architecture viewpoints n.
Skip this Video
Loading SlideShow in 5 Seconds..
Architecture Description Languages and Architecture Viewpoints PowerPoint Presentation
Download Presentation
Architecture Description Languages and Architecture Viewpoints

Architecture Description Languages and Architecture Viewpoints

152 Views Download Presentation
Download Presentation

Architecture Description Languages and Architecture Viewpoints

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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

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

  8. 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

  9. ArchC Example

  10. Existing ADLs are far from perfect

  11. 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.

  12. UML as an ADL

  13. 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

  14. Krutchen’s Architecture Model

  15. 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

  16. Logical Architecture

  17. Process Architecture

  18. Development Architecture

  19. Physical Architecture

  20. Why Krutchen’s Model?

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

  22. 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

  23. 4+1, UML, and OCL

  24. Questions?