Expressing the relationships between multiple views in requirements specification

Abstract

Composite systems generally comprise heterogeneous components whose specifications are developed by many development participants. The requirements of such systems are invariably elicited from multiple perspectives which will overlap, complement and contradict each other. If these requirements are developed and specified using multiple methods and notations respectively, then it is necessary to express and check the relationships between the resultant specification fragments.In this paper we deploy multiple "ViewPoints" that hold partial requirements specifications, described and developed using different representation schemes and development strategies. We discuss the notion of inter -ViewPoint communication in the context of this ViewPoints framework, and propose a general model for such communication. We elaborate on some of the requirements for expressing and enacting inter-ViewPoint relationships, and use fragments of the requirements specification method CORE to illustrate our model. * Since CORE uses the term "viewpoint" as part of its terminology, we substitute the term "agent" in its place to avoid the clash in nomenclature.

Structural Considerations in Defining Executable Process Models

“…It is also interesting to note that scientific workflow systems such as Kepler [14] are more in the style of the narrative form of description, but it has been noted that this form is increasingly inadequate as the scientific processes that it describes are to be used to support process execution [8]. Finally, we note that work on Viewpoints [15] also recognizes the value of representing a system as a collection of the different views of the system by the different participants and observers of the system. Thus the observations described in this paper are not inconsistent with work that has been done previously in the area of software systems.…”

Aspect-Oriented Software Development based Solution for Intervention Concerns Problems: Case Study

“…So we can conclude that Intervention Concern can be considered as a use case member that to come into the system at component level is involved with several classes that cause system complications and misunderstandings of that Concern Intervention. By using Aspect-oriented software development and with a new attitude towards this issue by using a new method of Aspect-oriented Modularization Concerns for Intervention and also reach to improve the modeling of use case [6,8]. One can use the Aspect-oriented software development identify as the Concerns Intervention before detecting the Implementation phase and wrap them in measured action That it needs-based development as a foundation member of based on our work, we get the desired result [8].…”

“…The Requirements which have such a feature called Interference Concerns. By Using Object-oriented Programming, Intervention Concerns are scattered throughout the code and prevent the achievement of this method by producing software is useless because we need to enter codes related to Concern Intervention in various parts of the System Components to reach to related Requirements of this Concerns and communicated between them [6]. When the System Developer needs to Implement a component in the system May require in one part of it to an additional requirement, which it is Implemented before.…”

Decentralised process modelling

“…Each ViewPoint thus captures a partial specification, the notation in which it is described, and the process deployed to develop it. Communication, consistency checking and information transfers between ViewPoints is done via one-to-one inter-ViewPoint rules [11].…”