|4.20 Elementary Method "Interaction Modeling" (IAM)|
The methods are used for the object-oriented system development. The objective is to describe interactions between objects and their sequence in interaction models. By means of interactions it is possible to express the occurrence of events and the exchange of messages.
The method can be used for the formalization of scenarios (sequences of events and the related system behavior) and for the modeling of the dynamic sequence of operations. Thus sequence diagrams are used to modellize and visualize the sequence-oriented order of the interactions between the objects. Predominantly collaboration diagrams are used to model the interaction relationships in a more detailed way and to stress the software structure.
The time required for the communication is not directly considered in the interaction modeling. However, it is possible to model time limitations. Multithreading can be modeled.
By modeling signatures, synchronous and asynchronous sequences, time-, sequence- and synchronization conditions, branchings, iterations, recurrences and generations of object deletions, it is possible, to improve development results.
Means of Representation
In the Unified Modeling Language (UML) /Booch, 1997/, sequence diagrams and collaboration diagrams are used for the representation of interaction modeling; they may be expanded with descriptions in specifications and with data-dictionaries.
In sequence diagrams, the used objects are represented by vertical lines, they represent the life duration of the objects. The identification of the objects is inserted above these lines. Events or messages between sender and receiver objects can be represented by horizontal arrows between the lines. Events or messages are named. In this connection, the names of the operations they are to be realized with, can be used. The chronological sequence of events or messages is listed from top to bottom. The distances between the arrows are without any meaning and do not represent a certain period of time.
Together with the sequence diagrams, the sequence diagram versions previously used by Booch ("Interaction Diagrams" /Booch, 1994/, Rumbaugh ("Event Trace Diagrams" /Rumbaugh, 1991/) and Jacobson ("Interaction Diagrams" /Jacobson, 1992/) were adjusted and updated. The notation was improved in such a way that the signatures, synchronous and asynchronous sequences, time-, sequence- and synchronization conditions, branchings, iterations, recurrences and generations of object deletions can be modeled. These modeling possibilities also offer the collaboration diagrams described next. One particularity only offered by the sequence diagrams is the bar symbol representation of times, during which objects are active.
The collaboration diagrams must be considered as a special form of the object models. The object models are described in the elementary method COM - Class/Object Modeling. Apart from the relevant static structure of the objects connected with relationship lines, the graphs represent collaborations (interactions) between objects as directed edges running parallelly to the relationship lines. The results or messages are specified in the description of the directed edges. In addition, a sequence is allocated to these collaborations by means of a sequence number. Parallel collaborations can also be expressed by means of the sequence number.
In addition to the modeling possibilities already described in the sequence diagrams, the notation of the collaboration diagrams allows the representation of the structure of composite objects and the representation of implementation information.
Together with the collaboration diagrams, the sequence diagram versions previously used by Booch ("Object Diagrams" /Booch, 1994/), and Rumbaugh ("Object Interaction Graphs" /Rumbaugh, 1995b/) were adjusted and updated. Another special version was introduced for the complex method "Fusion" ("Object Interaction Graphs" /Coleman, 1994/).
Sequence diagrams are predominantly used in the analysis, while collaboration diagrams are applied for detailed modeling.
Interaction modeling is realized iteratively, whereby detailed, improved or even new or changed models are generated during each run. Basically, the following steps are required:
|4.1||SD1.1 - Recording of Actual Status and Analysis||
With the help of the method the actual state of the old system can be collected by means of the representation of significant scenarios and dynamic sequences in complex operations. The specification must always be delimited since only essential sequence-oriented aspects are to be collected.
The method covers the subproduct User Requirements.Actual Status and Current Analysis from a sequence-oriented point of view.
|4.2||SD1.2 - Description of Application System||
With the help of this method, significant scenarios can be described within the scope of the preliminary system description. External system objects can be included.
The method covers subproduct User Requirements.Preliminary System Description from a sequence-oriented point of view.
|4.3||SD1.4 - Definition of Marginal Conditions||
With the help of this method the sequence-oriented requirements resulting from technical, organizational and other marginal conditions can be specified.
The method covers subproduct User Requirements.Marginal Conditions from a sequence-oriented point of view.
|4.4||SD1.5 - User-Level System Structure||
With the help of this method the professionally justified scenarios and sequences in complex system functions can be specified in interaction models, up to segment level.
The method covers subproduct User Requirements.Description
|4.5||SD2.1 - Technical System Design||
With the help of this method, technical sequences can be specified as interactions between defined architecture elements. The architecture elements must be handled as objects.
The method covers subproduct System Architecture.Explanation of the Cooperation of Technical Elements from a sequence-oriented point of view.
|4.6||SD2.5 - Interface Description||
With the help of this method, sequence-oriented requirements can be specified to the system interfaces. Interactions between system-external and system-internal objects can be modeled to represent communication protocols.
The method covers subproduct Interface Description.Description of the interfaces from a sequence-oriented point of view.
|4.7||SD3.2 - Specification of Requirements for External Interfaces of SW/HW Unit||
Sequence-oriented requirements to SW interfaces can be specified with the help of this method. To represent communication protocols, interactions between external and internal objects can be modeled.
The method covers subproduct Technical Requirements.Technical Requirements for the Interfaces from a sequence-oriented point of view.
|4.8||SD3.3 - Definition of Requirements for the Functionality||
With regard to sequences in the SW unit, interaction models can be improved or newly generated.
The method covers subproduct Technical Requirements.Overall Function of Element with regard to the SW unit, from a sequence-oriented point of view.
|4.9||SD4.1 - SW Architecture Design||
With the help of this method, dynamic sequence models can be specified for process ensembles.
The method covers subproduct SW Architecture.Dynamic Sequence Model.
|4.10||SD4.2 - Design of Internal and External SW Interfaces||
With the help of this method, sequence-oriented aspects can be specified to SW interfaces. In order to represent communication protocols, interactions between external and internal objects can be modeled.
The method covers subproduct Interface Description.Description of the Interfaces from a sequence-oriented point of view.
|4.11||SD5.1 - Description of SW Component/Module/Database||
Dynamic sequences in complex operations can, if required, be specified in detailed interaction models.
The method covers subproduct SW Design (Module).SW Component/SW Module Description from a sequence-oriented point of view.
|No.||Interface||Observation||Information in Annex 1|
Modeling of interactions in method IAM has to be agreed, i. e. adjusted with the modeling of class operations in method COM - Class/Object Modeling. If no complex operations are defined in method COM it is possible to model their dynamic sequences in method IAM. The modeling of objects in method COM has to be adjusted with the modeling of objects in method IAM.
While the static structure of interfaces can be specified with method COM, sequence oriented requirements to communication protocols can be represented with method IAM.
The use cases defined with method UCM - Use Case Modeling can be realized with method IAM in form of sequence diagrams or collaboration diagrams.
Defined scenarios can be used as a starting point for the definitions of state models by means of method IAM.
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|