WICSA 2009 WS7 -- Architectural Description
From WICSA Conference Wiki
Session Chairs: Rich Hilliard and Patricia Lago
Wednesday, 16th September, 13:30 - 15:30
Contents |
Participants (Tentative)
- Please sign your name here if you are thinking of attending this BoF. (Click the signature button in the editor). Tell us something about your background. Add a few sentences about the working session topic such as your position, questions you would like to see discussed, etc.
- (example) --Bob Schwanke, Siemens Corporate Research. Decisions and Rationale should be testable, early and often.
- Sorana Cimpan, Université de Savoie (France).
- Nelis, DistriNet, KULeuven, Belgium.
- Alexander Helleboogh, DistriNet, KULeuven, Belgium.
Papers
- "Reviewing Architecture Documents Using Question Sets", by Robert L. Nord, Paul C. Clements, David Emery and Rich Hilliard
- This paper proposes a structured approach for reviewing architecture documents using question sets. Given the critical importance of architecture to software project success, it follows that the architecture cannot be effective unless it is captured in documentation that allows the stakeholders to understand and use the architecture in the way it was intended. The approach does not assume a particular architecture methodology or documentation approach, although it was conceived in the context of ISO/IEC 42010 and the SEI Views and Beyond approach to documenting software architectures. Like both of them, our approach is centered on the stakeholders of the artifact, utilizing them in a focused, guided way to assure that the documentation carries sufficient quality to enable them to do their jobs. Our approach is not intended as a complete framework for architecture evaluation; rather it is meant to be used within such a framework, when one is available.
- "Multiple Viewpoints Architecture Extraction", by Azadeh Razavizadeh, Herve Verjus, Sorana Cîmpan and Stéphane Ducasse
- A software system's architecture, its elements and the way they interact, constitute valuable assets for comprehending the system. Many approaches have been developed to help comprehending software systems in different manners. Most of them focus on structural aspects. We believe offering multiple views of the same system, using domain knowledge helps understanding a software system as whole. To correlate domain information and existing software systems, different viewpoints are considered and modelled. Viewpoints guide the extraction of architectural views, the later representing different system facets. We propose a recursive framework, an approach that expresses domain knowledge as viewpoints to guide the extraction process. It provides multiple architectural views according to multiple given viewpoints. ppt
- "The System Context Architectural Viewpoint", by Eoin Woods and Nick Rozanski
- A common requirement when describing the architecture of a software system is the ability to define the environment of a system, in terms of its external dependencies. In a view-based architectural description approach this need is met by adding a Context view to the architectural description and ideally defining a corresponding Context viewpoint to guide and standardise such views. This short paper explains the benefits of adding such a view to an architectural description and provides an outline definition of a corresponding viewpoint to explain the content of these views.
- "Modeling Architectural Change: Architectural Scripting and its Applications to Reconfiguration", by Mads Ingstrup and Klaus Marius Hansen
- We detail the notion of architectural scripting (ASL) as a way to model the dynamic aspects of runtime and deployment-time software architecture. This is complementary to the ability of architecture description languages to model architectures statically in that we define scripting operations to modify architectures at runtime. The scripting operations have as verification of the approach been implemented in an interpreter bundle on the OSGi platform. This implementation is used in our self-management system for generating correct reconfiguration plans in a self-managed system.
Contributions
If you have relevant materials or references, please add here:
- Top 10 Tips for Presenting Architecture Information (who knew there was a top 10 list for architecture descriptions?! :-)
Notes during presentation
[Please add your own thoughts]
- How to know that architectural documentation "is ready"? (i.e. it fulfills its intended purpose/s)
- any other 'tactics' than question sets?
- what are the "typical uses" of architectural descriptions? (e.g. planning, training)
- role of documentation in software development life cycle (e.g. how does fit in e.g. SCRUM?)
- metrics for software architecture (e.g. function points and code sizing rather than architecture relevant requirements, architecture sizing, risk tracking)
- View extraction can help, :
- ensuring compliance backward to the implementation (view)
- providing system understanding
- creating a domain/organization specific catalog of viewpoints
- Context Viewpoint (CVP)
- fulfills the need to involve architects in early stages of development
- how to relate a CVP to other views (e.g. ensuring consistency)
- how to cope with the assumptions about the external systems?
- constraints work both ways
- does it make any sense to speak of domain-specific CVP's
- Modeling architectural change
- how to model dynamic aspects of runtime architecture change? e.g. adaptation or deployment
- how to enforce a predefined ADL-compliance in dynamic systems (e.g. self-managing/healing)?
Discussion
[Add here below discussion topics]
- uses of architectural descriptions?
- how to make arch reviews useful to developers? can we use question sets to 'reverse define' VP's?
- design vs. documentation
- content vs. methods
- do we have a common "view of views"?
- backward vs.forward architecting?
- forward looking
- extraction
- hybrid: what can the architect do (in the forward phase) to help/enable extraction?
- challenging can be static code versus dynamic code (wrt. static vs. dynamic views)
- in describing architectures we define abstractions: how to do that? for e.g. portability, maintenability, sustainability
- when to generate views on a relevant stage of development (not always! not every step)? and how to reckon (in time) when we need to detect critical inconsistencies?
- worth looking at the reverse engineering community
- reconstruct the architecture by looking at social dynamics of development teams (see results in the field of Socio-Technical Congruence)
- how to determine 'a priori' what information extracted in architecturally relevant? and what should be constrained?
- tools exist to visualize lots of relationships, support manipulation, reasoning, etc.
- lack in showing run-time dependencies (some results are emerging in that direction in the service computing community, in the area of monitoring)
- open question is, should we really document an architecture that does not change? how often to illustrate change? is this architectural significant? how is this defined?
- how to cope with highly dynamic architectures? does architecture automatically become dynamic?
- we could imagine the "analogy with city-planner".
- relations among VP's
- how to reconcile them? need for sufficient rigor in the definition of the VP
- requirements view versus context view
- ...
Collecting input for a Catalog of Viewpoints
If you want to upload, propose, discuss viewpoints, visit the Viewpoints BoF
