On ADLs and tool support for documenting view-based architectural descriptions

Transcription

1 On ADLs and tool support for documenting view-based architectural descriptions Danny Weyns Alexander Helleboogh SATURN 2008, Software Engineering Institute, CMU DistriNet Dept.Computer Science K.U.Leuven +60 researchers Advanced open and distributed software Decentralized software architectures

2 Outline Case Problems with view-based architectural documentation First step towards a solution Reflection & conclusions Case: Control s s Control

3 <<Raw <<Raw << << Runtime Provided Required Computing Node Runtime Provided Required Computing Node << Processing << Processing <<Raw <<Validated <<Raw <<Validated << << << << << << << << << << << << << << View-Based Documentation of Architecture Top Level Module : Module Top Level Module <<Raw << s - Module contain the modules from the : Context Diagram Decision NOTATION External entity X Y flows from X to Y << Location << Configuration << Location management To << of To << of <<Location << << << << Configuration Location << << << << Device 1 Device 2 : Device 3 Device 4 : : Fusion : : : : : : : Device 1 Device 2 : Device 3 Application Server Device 4 : : base Server : Module View-Based Documentation of Architecture << Location << Configuration << Location Top Level Module To << of <<Location << << Configuration - - << - s - << Location Module contain the modules from the management : Context Diagram Decision NOTATION X Y External entity flows from X to Y : Module To << of To << of << Location To << <<Location <<Static of Input << << << Configuration << Configuration << << << Location << << Location management << << << Device 2 Device 3 Device 1 : Device 4 : : << : Fusion : : : : << : : Device 1 Device 2 : Device 3 Application Server Device 4 : base Server :

4 <<Raw <<Raw << << Runtime Provided Required Computing Node Runtime Provided Required Computing Node << Processing << Processing <<Raw <<Validated <<Raw <<Validated << << << << << << << << << << << << << << View-Based Documentation of Architecture Top Level Module : Context Diagram s - Module contain the modules from the Decision NOTATION External entity X Y flows from X to Y : Module << Location << Configuration << Location management <<Location To << of << To << << of << << Configuration Location << << << << Device 2 Device 3 Device 1 : : : - Device 4 - Application Server - s - Module : Fusion : contain the modules : : : : from the : base Server : : Device 1 Device 2 : Device 3 Device 4 View-Based Documentation of Architecture Top Level Module : Module To << of To << of << << Location <<Location << : Context Diagram << Configuration << << Configuration Location Decision << << << Location management << << Device 2 Device 3 Device 1 : Device s - : : Application Server Module contain the modules from the : Fusion : : : : Context Diagram Decision : NOTATION : : X Y External entity flows from X to Y Device 1 Device 2 : Device 3 Device 4 NOTATION External entity base Server : : X Y flows from X to Y

5 <<Raw << Runtime Provided Required Computing Node << Processing <<Raw <<Validated << << << << << << << View-Based Documentation of Architecture Top Level Module Device 1 : Context Diagram Device 1 << Device 2 Decision : Module Device 2 << Processing contain the modules - from the : - : Fusion - s << - NOTATION External entity : : X Y flows from <<Raw X to Y Device 3 : : Module << : : : : Device 3 : << << << Location Configuration Location << management Device <<Location 4 << << Device 1 Configuration Application Server Location Device 1 Device 4 To << of << Device 2 << : Device 2 << << << : <<Validated : Fusion : : << Device 3 : << << : To << << hird : Party : : : : of Device 3 : Runtime Device 4 base Server Application Server Device 4 Provided Required : : Computing Node base Server Outline Case Problems with view-based architectural documentation First step towards a solution Reflection & conclusions

6 <<Raw << Runtime Runtime of of type type T Provided Provided Required Required Computing Computing Node Node << Processing <<Raw <<Validated <<Validated << << << << << << << << << << Update View-Based Documentation Top Level Module : Context Diagram The elements Module from the Decomposition Module View contain Decomposition the modules View - from contain the the modules from - the - s - - Media Decision Decision Media NOTATION NOTATION External External entity entity Entity under X X Y Y flows flows from from X X to to Y Y : Module << Location << Configuration << Location management To << of To << of <<Location << << << << Configuration Location << << << Media <<Media Interaction << Device 1 Device 2 : Device 3 Device 4 : : Fusion : : Application Server : : : :Media : : Device 1 Device 2 Device 3 : Device 4 <<Media Interaction : base Server : Add module: Media Applying Views & Beyond can be hard Maintaining consistency among! Views!! Related view packets (parent/child; sibling)! Context diagrams! Overlays! Elements directory! Glossary! But also analysis & verification, traceability, etc.

7 The Underlying Problem Common agreement: software architecture should be documented with multiple views Gap Lack of ADLs and Tools with explicit support for views & view relations Our experience: documenting view-based descriptions is hard Outline Case Problems with view-based architectural documentation First step towards a solution Reflection & conclusions

8 First Step Towards a Extending existing ADL/Tool with support for! Views! View relations Current focus! xadl and ArchStudio! Structural views + basic relations! Formal foundation Cases! Prototype applications! Projects with industry! Logistics! control (Flexsys project) Demo

9 Outline Case Problems with view-based architectural documentation First step towards a solution Reflection & conclusions Reflection Large body of work on views & view relations! Need for promoting views & view relations as firstclass citizens in ADLs ADLs & Tools amplify the power of views & view relations! Automated consistency checking! On-the-fly composition of views Supporting views & view relations is complex! Relating views " relating stakeholder perspectives! Heterogeneity of multi-view specifications! Formalizing the specification

10 Conclusion Paper published in IEEE Software 12 (6) November 1995, pp Architectural Blueprints The 4+1 View of Software Architecture Philippe Kruchten Rational Software Corp. 1 Abstract This article presents a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views. This use of multiple views allows to address separately the concerns of the various stakeholders of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenariodriven, iterative development process. Keywords: software architecture, view, object-oriented design, software development process Introduction 4+ We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely logical groupings of functionality? Are the arrows representing compilation dependencies? Or control flows? Or data flows? Usually it is a bit of everything. Does an architecture need a single architectural style? Sometimes the architecture of the software suffers scars from a system design that went too far into prematurely partitioning the software, or from an over-emphasis on one aspect of software development: data engineering, or run-time efficiency, or development strategy and team organization. Often also the architecture does not address the concerns of all its customers (or stakeholders as they are called at USC). This problem has been noted by several authors: Garlan & Shaw1, Abowd & Allen at CMU, Clements at the SEI. As a remedy, we propose to organize the description of a software architecture using several concurrent views, each one addressing one specific set of concerns. An Architectural Software architecture deals with the design and implementation of the high-level structure of the software. It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance requirements of the system, as well as some other, non-functional requirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely in this formula2, modified by Boehm: Software architecture = {Elements, Forms, Rationale/Constraints} Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. To describe a software architecture, we use a model composed of multiple views or perspectives. In order to eventually address large and challenging architectures, the model we propose is made up of five main views (cf. fig. 1): The logical view, which is the object model of the design (when an object-oriented design method is used), the process view, which captures the concurrency and synchronization aspects of the design, the physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect, Bridging the gap