Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written
•
Perceived system.•
Set of abstractions to be used in conceptualizing the system.•
Notation to be used to represent the conceptual system.Collaborative modeling will be more difficult the more these conditions are altered. Serious misunderstandings are possible if the participants have significantly different mindsets.
The discussion here is concerned with how the participants will communicate during the negotiation about the system specification. In Sykes and Gupta (2001) two participant roles named “Client” and “Analyst” were used. These roles are replaced here by “Environment Designer” and “System Designer,” respectively. This has been done to make the discussion more general, to emphasize that the essential nature of the activity is design, and as a reminder that the system under development is an open, interactive system (i.e., interaction with its environment is important).
It is assumed that the mindset of the Environment Designer comprises:
•
Detailed knowledge about the environment in which the system will operate.•
A preference for a structural, mental model of the environment.•
A preference for functional, mental models of systems of the kind being developed. It is assumed that the mindset of the System Designer comprises:•
Detailed knowledge of systems of the kind being developed.•
Some general knowledge of the environment.•
A preference for structural, mental models of systems.The System Designer could also be expected to know about techniques and tools for building systems and the availability and characteristics of components that could be used.
For example, if the system under development is a software application that will operate as part of a business process, a business analyst/systems analyst could fill the role of Environment Designer and a software developer such as an analyst/programmer could fill the role of System Designer. If the system under development is a subsystem forming part of a software application, a system architect could fill the role of Environment Designer and a programmer could fill the role of System Designer.
Negotiating Early Reuse
Figure 6, which is based on two modeling triangles joined via two common symbolic systems, shows the modeling transitions and communications that occur as the Environ- ment Designer and the System Designer collaborate in the preparation of a symbolic system. They need to agree that the symbolic system “stands for” the perceived system, and in this case, specifies it.
To examine more closely the process via which the participants negotiate the preparation of a specification for a system that will reuse existing components, Figure 6 has to be related to Figure 5(a). This can be done as follows.
The perceived system in Figure 5(a) does not yet exist, even though it is shown as an input model in the figure. It is depicted this way because the participants must imagine
76 Sykes
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
the system at this early stage. It thus corresponds to both views of the perceived system shown in Figure 6 (i.e., the Environment Designer’s perceived system and the System Designer’s perceived system).
The system specification in Figure 5(a) corresponds to the formal model (symbolic system 2) shown in Figure 6.
Interactions between the Environment Designer and the System Designer are aimed at accomplishing the following tasks:
1. Bringing their respective, perceived systems into alignment.
2. Preparing a specification (model) of the behavior of the perceived system. 3. Deciding what parts of that behavior will be implemented by means of existing
components (which also requires an understanding of the behaviors of those components).
The validity of any agreement that the Environment Designer and System Designer might reach about the correctness of the formal model in Figure 6 is likely to be in doubt unless it can be established that the formal model “stands for” the same perceived system. The participants need some way of discovering that the other perceives the “same” system. The process via which participants bring their respective perceptions of the two imagined systems into alignment is therefore of interest.
Environment Designer's conceptual system System Designer's conceptual system Environment Designer's perceived system System Designer's perceived system conceptualization
Natural language model (symbolic system 1) application application conceptualization realization representation representation realization
alignment is the goal
Formal model (symbolic system 2)
Figure 6: Transitions between perceived, conceptual and symbolic systems, and communication between Environment Designer and System Designer, during a system specification modeling activity
Negotiating Early Reuse of Components – A Model-Based Analysis 77
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written This process will normally comprise a number of iterations, each consisting of model creation by one participant followed by model interpretation by the other participant. It is assumed that either the Environment Designer or the System Designer can originate a model.
Essentially what is being sought is agreement about correspondence between elements in the symbolic model of the perceived system and elements in the perceived system itself (i.e., the meaning of elements in the symbolic model in terms of the proposed system).
As the meaning triangle shows, the association between sign and referent is comprised of two associations. The association between referent and concept results from the observer’s scheme of abstraction. The association between concept and sign results from the observer’s scheme of notation.
Thus, the alignment between perceived systems being sought by the Environment Designer and the System Designer can be achieved only if they concur with their respective schemes of abstraction and notation.
Assuming that the model is to be expressed formally, the Environment Designer and System Designer have to make explicit (a) their agreed upon scheme of abstraction, and (b) their agreed upon scheme of formal notation that will link model elements to system elements.
It is, therefore, necessary to consider the abstractions and notations that are likely to be familiar to both the Environment Designer and the System Designer. Is it assumed that each of the designers is familiar with abstractions about the real world, and that they have a natural language in common that will provide the notational scheme for commu- nicating about those abstractions.
Beyond that, it must be considered what kind of abstractions will be used for:
•
Discussing the environment.•
Specifying components.•
Expressing the formal system specification (symbolic system 2 in Figure 6).•
Composing components.For genuine collaboration and negotiation to be possible, at least one of these sets of abstractions must be familiar to both the participants.
Two of the many possible collaboration scenarios will now be described.