The term viewpoint is interpreted in many different ways [Kot96]. A viewpoint may bc identified with a stakeholder a person or group having a legitimate . interest in the system to be built; with any knowIedge soume about the application domain; with a participant in the development process; with a domain (by which we mean the machine, or a human or other part of the environment that interacts with the machine); with a projection of the properties of any part of the system and the associated descriptions, notations and methods; or with almost any combination of these Whichever intepretation is adopted, software developers who use more than one viewpoint must certainly consider how different viewpoints are related, and whether they are consistent pas96]. The central theme of this paper is that relationships among diierent viewpoints can be understood in terms of shawdphenomena. This applies in particular to viewpoints regarded as: l separate descriptions of distinct domains; l separate descriptions of distinct properties of one domain; or l separate descriptions of distinct system requirements.
[1]
Michael Jackson,et al.
Problem decomposition for reuse
,
1996,
Softw. Eng. J..
[2]
Michael Jackson,et al.
Where Do Operations Come From: A Multiparadigm Specification Technique
,
1996,
IEEE Trans. Software Eng..
[3]
Pamela Zave,et al.
Deriving Specifications from Requirements: an Example
,
1995,
1995 17th International Conference on Software Engineering.
[4]
Steve M. Easterbrook,et al.
Using ViewPoints for inconsistency management
,
1996,
Softw. Eng. J..
[5]
Michael A. Jackson,et al.
Software requirements and specifications - a lexicon of practice, principles and prejudices
,
1995
.
[6]
Michael Jackson,et al.
Conjunction as composition
,
1993,
TSEM.
[7]
C. A. R. Hoare,et al.
Communicating Sequential Processes (Reprint)
,
1983,
Commun. ACM.
[8]
Daniel Jackson,et al.
Structuring Z specifications with views
,
1995,
TSEM.
[9]
Ian Sommerville,et al.
Requirements engineering with viewpoints
,
1996,
Softw. Eng. J..