From WICSA Conference Wiki

Contents 1 BoF session: Relations between views (BRBV) 1.1 Organizers 1.2 Participants 1.2.1 Participant action plan 1.3 Overview of key literature 1.3.1 Goal 1.3.2 Brief notes on literature 1.4 BOF Notes 1.4.1 Introduction and summary presenation 1.4.2 Notes Rich 1.4.2.1 Use cases for relations 1.4.2.2 Discussion 1.4.3 Notes Danny 1.4.3.1 Use cases 1.4.3.2 Types of relations 1.4.3.3 Issues 1.4.3.4 Key challenges 1.5 References

BoF session: Relations between views (BRBV)

Tuesday, 19 February 2008, 17:30 - 19:00

Abstract on WICSA site

Organizers

1. Danny Weyns, Katholieke Universiteit Leuven, Belgium
2. Nelis Boucke, Katholieke Universiteit Leuven, Belgium
3. Rich Hilliard, independent consultant

Participants

Participant action plan

1. Add yourself to participants list
2. If this is not yet the case, get familiar with IEEE terminology on viewpoints, views and models. This will serve as a framework for the discussion. (isodraft1, while reading focus on terminology of viewpoints, views, models, view correspondence and viepoint correspondence rule).
3. Read the summary on key literature on relations between views and possible suggest additional papers or add notes to the descriptions.

Please add yourself to this list by selecting the edit link to the right. You may want to select the watch tab above so you will be notified of changes to this page.

1. [[User:<wiki id>|<add your name here>]]

1. Rich Hilliard
2. Nelis Boucke
3. Danny Weyns
4. Christina von Flach
5. Peter Eeles
6. Bedir Tekinerdogan
7. Hasan Sozer
8. Tomi Männistö
9. Thorsten Keuler

Overview of key literature

Goal

The goal of this section is to collect references and key literature on the subject of relations between views. Feel free to add additional references or to comment on the description of the papers (please tag comments with your name, so that we can find back who contributed).

Brief notes on literature

The authors of "Software Systems Architecture" [RW05] emphasize the importance of consistency between views in architectural descriptions. The authors provide a checklist of possible relations between the different types of views defined in the book (chapter 22). The checklist can be used by software architects during design and by reviewers during evaluation as a heuristic to check whether the architectural description is consistent.

In "Documenting Software Architectures" [CBB+03], the authors state that managing relations between views is an important part of the architect's job. In the approach proposed by the authors, documenting view relations is part of the documentation that applies beyond views. The authors provide three different ways of describing relations views: (1) view packets can refer to sibling, child or parent view packets, e.g. one view introduces a module and another view zooms in on the internals of the module; (2) the architect can define a mapping between elements in different views by listing the mappings in a table (one-to many, many-to-many, many-to-one); (3) the architect can create an overlay view or hybrid style, combining elements of two views in one integrated view.

The conceptual model of IEEE Recommended Practice for Architectural Description of Software-Intensive Systems [IEE00] establishes terms and concepts pertaining to the content and use of architectural descriptions, but has no concepts of relations between or compositions of views. The recommended practice briefly mentions that inconsistencies between views should be documented, but leaves open how this should be done. A new ISO standard [ISO] that is currently under development starting from the old recommended practice has initial concepts to model relations called 'view correspondences' and 'viewpoint correspondence rules'. A view correspondence may be used to capture a consistency relation, a traceability relation, a constraint or obligation of one view imposed upon another, or other relations relevant to the architecture being described. A viewpoint correspondence rule makes a contract between two architectural viewpoints. This contract is enforced on their respective views within an architectural description in terms of relations on the elements of the two views.

The work around xlinkit ([NCEF02, NEFE03, DSF07]) provides rule-based link generation and checks semantic consistency between in XML documents. The authors state this is essential for an approach where there is decentralized development and where inconsistencies are inevitable. The consistency constraints are expressed as logical rules and serve as input for a tool that generates consistency and inconsistency links between elements. It is left to the architect to possibly resolve the inconsistencies. xlinkit is not specifically tailored for finding inconsistencies between architectural views, but have been applied on distributed product catalogs, databases, requirement specifications, UML diagrams, composition of web services, etc. [NKF03] points that it is clear that there is still a lack of more diverse relationships in order to reason, structure and configure collections of viewpoints.

Architectural Stratification [AK03] tries to combine the strength of separation of concerns and aspect-orientation with component-based frameworks and model-driven architecture. The goal of architecture stratification is to relate different architectural strata (architectural models) so that they best represent a system's crosscutting concerns. Each stratum represents the architecture on a certain level of abstraction and the authors use stepwise refinement to relate the strata. In each step, a refinement transformation is applied that refines connectors introducing a particular concern. Relations are thus defined as refinement transformations.

The authors of [DD04] use four architectural viewpoints for web service composition. By formally capturing the interrelationship between these viewpoints, the proposal enables verification of a composite web service. Another approach from the same author [DQPvS03] focuses on relating models and viewpoints to each other by translating the models to one basic modeling language (ISDL), and describe relations on the level of this common model (leading to relations between the original viewpoints). Relations are identified on the level of language constructs (meta-level, called model relation), implying certain relations between elements of views. The authors show an example of such basic language and how it is used to relate two behavioral views, and they used two concrete relations (refines and complements) as a basis for consistency checking between these behavioral views.

In [BH08] the authors identify a lack of relations and composition between multiple views, hampering changeability and consistency. The authors introduce three types of relations (unification, refinement and composition) in structural views and demonstrate how these relations allow (automatic) composition of views. As a proof of concept, the relations are integrated in xADL [DvdHT05] and applied to the architectural design of an industrial Automatic Guided Vehicle Transportation System. The authors show improved changeability of the systems software architecture.

The authors of [THA07] propose to explicitly document the relationship between architectural concerns and the view elements that cover this concern, by using a simple trace relation. In case of evolution of the software, the authors believe that one can follow the trace links to update and synchronize architectural views to keep the architecture itself consistent.

[RW05] defines a number of architectural viewpoints (Functional, Information, Concurrency, Development, Deployment, Operational); chapter 22 defines a number of heuristics for determining consistency between pairs of (resulting) views.

Any general solution to capturing relations between views will need to support a variety of paradigms. Here are a few references to some of these paradigms:

• [MG97] argues for composition via unification in a components-and-connectors viewpoint;
• [DBS95] is a pointer into a large literature using Z as the underlying formalism to tackle issues of inter-view consistency in the RM-ODP framework;
• [MBC05] shows how relational calculus can be very powerful means for cross-view analysis;
• [FMP99] shows algorithms for consistency checking based on constraints on graphs;
• [KK03] demonstrates aspectual composition via superposition.

BOF Notes

Introduction and summary presenation

The presentation used as introduction can be found here.

The summary for the plenary session can be found here.

Notes Rich

These are my notes, please add, react or correct User:Rh

Use cases for relations

• checking consistency or completeness
• presentation, exposition: temporary overlays
• deriving or analysing qualities
• traceability
• composition
• propagation of design decisions, impact analysis
• cross-cutting concerns, perspectives: security function view, security deployment view
• levels of realization: e.g. logical data model to physical data model

Discussion

• relation types: consistency, realizability, ...
• traceability is never an end goal in itself (e.g., For every use case, there is a component that has that name.)
• Are relations binary, n-ary?
  • can be represented in an ERA graph. Recovery relates to Functional, Deployment fred.java = fred.jar = fred.exe Hyperspace model
• can relations be parameterized (e.g., over time)?
• relations between views or between their elements?
• what about dynamic relations that you can’t enumerate statically? Need algorithms vs extensional relations
• ADLs don’t support multiple views
• What can be learned from aspect (composition) mechanisms?
• common language: “rules language;” does 42010 need a core relations language?
• Terminology: "correspondence", "constraint," "rule", ...
• Tool support for navigating and visualizing relations between views

Notes Danny

Feel free to react or correct User:danny.weyns

Use cases

• Relations for tracebility of concerns in architectural views (views as an approach for separation of concerns in ADs > next step is obviously: compose the views)
• Relations between views for documenting crosscutting concerns (e.g. expressing security in terms of relationship between views)
• Relations for concerns composition
• Relations for consistency checking
• Other use cases: deriving quality properties, propagation of design, analysis of system properties, understandability (e.g. overlays for better understanding)

Types of relations

• Express everything in terms of binary relations? Tools vs understandability (relations can be translated automatically)
• Hyperspace > n-dimensional
• What language(s) do we need to express relations between views?
• Terminology: View correspondence – view(point) correspondence (rule)
• Rule vs. constraints vs. law

Issues

• There is a gap between existing ADLs (lack of support for explicit views) and state of the art architecture documentation with multiple views.
• Gap between ADs with viewpoints/views/perspectives/.. and (language-based) tool support
• Completeness of AD vs consistency/relations
• What can we learn/reuse from relations between multiple diagrams in OO designs?
• Relation can be implied (vs. explicit model element) : “make explicit as little as possible”
• What about models over different view?
• (In)consistency in time: e.g. early design phase doing some analysis independently of final deployment

Key challenges

• What is already there > we need a clear view on it
• Classification use cases
• Terminology <> standard
• We need a better understanding of relationship between stakeholder concerns <> architectural descriptions
• What is the connection with MDA?

References

[AK03] C. Atkinson and T. Kuhne. Aspect-oriented development with stratified frameworks. IEEE Software, 20(1):81-89, 2003.

[BH08] Nelis Boucke and Tom Holvoet. View composition in multi-agent architectures. Special issue on Multiagent systems and software architecture, International Journal of Agent-Oriented Software Engineering (IJAOSE), 2(2):3-33, 2008.

[CBB+03] Paul Clements, Feliz Bachman, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Stafford. Documenting Software Architectures, Views and Beyond. Addison Wesley, 2003.

[CS07] Rogelio Limon Cordero, and Isidro Ramos Salavert. Relating software architecture views by using MDA. Computational Science and Its Applications ICCSA 2007Lecture Notes in Computer Science, 4707/2007:104-114, 2007.

[DBS95] John Derrick, Howard Bowman, and Maarten Steen. Viewpoints and objects. In J. P. Bowen and M. G. Hinchey, editors, Ninth Annual Z User Workshop, volume 967 of Lecture Notes in Computer Science, pages 449-468, Limerick, September 1995. Springer-Verlag.

[DD04] Remco Dijkman and Marlon Dumas. Service-oriented design: A multi-viewpoint approach. International Journal of Cooperative Information Systems, 13(4):337-378, 2004.

[DQPvS03] R.M. Dijkman, D.A.C. Quartel, L.F. Pires, and M.J. van Sinderen. An approach to relate viewpoints and modeling languages. In Proceedings. Seventh IEEE International Enterprise Distributed Object Computing Conference, pages 14-27, 2003.

+ Consistency in Multi-Viewpoint architecture design of enterprise information systems

[DSF07] Andrew Dingwall-Smith and Anthony Finkelstein. Checking complex compositions of web services against policy constraints. In Juan Carlos Augusto, Joseph Barjis, and Ulrich Ultes-Nitsche, editors, MSVVEIS, pages 94-103. INSTICC PRESS, 2007.

[DvdHT05] Eric M. Dashofy, Andre van der Hoek, and Richard N. Taylor. A comprehensive approach for the development of modular software architecture description languages. ACM Transactions on Software Engineering and Methodology (TOSEM), 14(2):199{245, 2005.

[FMP99] Pascal Fradet, Daniel Le Metayer, and Michael Perin. Consistency checking for multiple view software architectures. In Proceedings ESEC/FSE’99. Springer, 1999.

[GMT99] Michael Goedicke, Torsten Meyer, and Gabriele Taentzer. Viewpoint oriented software development by distributed graph transformation: Towards a basis for living with inconsistencies. In RE, pages 92-99. IEEE Computer Society, 1999.

[GV06] Holger Giese and Alexander Vilbig. Separation of non-orthogonal concerns in software architecture and design. Software and Systems Modeling, 5(2):136-169, June 2006.

[IEE00] IEEE. Recommended practice for architectural description of software-intensive systems (ANSI/IEEE-Std-1471), September 2000.

[ISO] ISO. Systems and software engineering architectural description. Working document: ISO/IEC JTC 1/SC 7 N 000.

[KK03] Mika Katara and Shmuel Katz. Architectural Views of Aspects. In Proceedings of the 2nd International Conference on Aspect-Oriented Software Development, Boston, MA, USA, March 2003, pages 1-10. ACM.

[MBC05] J. Muskens, R. J. Bril, and M. R. V. Chaudron. Generalizing consistency checking between software views. In WICSA ’05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05), pages 169-180, Washington, DC, USA, 2005. IEEE Computer Society.

[MG97] Ralph Melton and David Garlan. Architectural unification. In Proceedings of CASCON ’97, November 1997.

[NCEF02] Christian Nentwich, Licia Capra, Wolfgang Emmerich, and Anthony Finkelstein. xlinkit: a consistency checking and smart link generation service. ACM Trans. Inter. Tech., 2(2):151-185, 2002.

[NEFE03] Christian Nentwich, Wolfgang Emmerich, Anthony Finkelstein, and Ernst Ellmer. Flexible consistency checking. ACM Trans. Softw. Eng. Methodol., 12(1):28-63, 2003.

[NKF03] Bashar Nuseibeh, Jeff Kramer, and Anthony Finkelstein. Viewpoints: meaningful relationships are difficult! In ICSE '03: Proceedings of the 25th International Conference on Software Engineering, pages 676-681, Washington, DC, USA, 2003. IEEE Computer Society.

[RW05] Nick Rozanski and Eoin Woods. Software Systems Architecture. Addison Wesley, 2005.

[THA07] Bedir Tekinerdogan, Christian Hofmann, and Mehmet Aksit. Modeling traceability of concerns for synchronizing architectural views. Journal of Object Technology, 6(7):725, 2007.