This chapter describes the techniques that the SOMT method is based on. It also gives a first brief description of the method and the activities it consists of.
Last in the chapter is a list of references, which are referred to throughout this volume.
Object-oriented analysis is a well-known and popular technique for understanding a problem and analyzing a system. There are many different versions of object-oriented analysis published as different methods in various books. The Object Management Group (OMG) has agreed upon a standard language for object-oriented methods and tools - the Unified Modeling Language (UML) and its notation ( [20], [21]).
SDL [7] and MSC [9], on the other hand, are standardized notations used for specification and design of systems. They have a solid foundation in terms of support for design, formal verification and code generation. Especially for distributed, reactive, real-time applications SDL and MSC has a successful track record.
The scope of this volume is to present a method that integrates object-oriented analysis and SDL design with a special focus on application areas where SDL is known to be suitable. The intention is of course to provide developers with the best of both worlds: The strength of the object oriented analysis in the early phases together with the strong back-end provided by SDL and SDL tools.
The method has been given the name SOMT (short for SDL-oriented Object Modeling Technique). As the name indicates the method is essentially an adaptation of OMT to the requirements given by the special application area of distributed, reactive, real-time systems together with the usage of SDL for the design.
Another object-oriented analysis method that has provided input to SOMT is the Objectory method by Jacobsson [2]. In particular, the idea of use cases that originated from this method has been incorporated into SOMT.
A special focus of SOMT is to provide solutions that can be directly applied in a development project. For instance, it provides guidelines about how to apply OMT in a way that enables a smooth transition between analysis and design.
The volume is focused on how to use the different notations and concepts of object-oriented analysis and SDL and does not provide a detailed description on the specific notations. It is therefore recommended that you are at least reasonably familiar with both the general concepts of object-oriented analysis, the OMT notation and SDL before reading this report. [4] is a good introduction to the OMT notation and there exist several text books on SDL, for example [10].
The rest of this document is structured as follows:
The SOMT method provides a framework that shows how to use object-oriented analysis and SDL-based design together in a coherent way. The framework is based on describing the analysis and design of a system as a number of activities. Each activity deals with some specific aspects of the development process. The work done in the activities is centered around a number of models, that document the result of the activities. As an integral part of the SOMT method, guidelines are given for the transition between the different models. The activities and the main models used in SOMT are illustrated in Figure 1.
Figure 1 : SOMT activities and main models
|
|
As can be seen in Figure 1, SOMT consists of five major activities:
As seen above, SOMT uses a number of different models to describe different aspects of the system. In many cases there are relations between objects in the different models. One especially important relation is that in some cases one object can be seen as an implementation of another object. In SOMT this type of relation is called implink (short for implementation link) and corresponds to a design decision taken during the development. The creation and maintenance of implinks forms an important part of the SOMT method. Two points can be made:
Note that the Paste As functionality can be seen as an implementation of transformation rules between the different models, e.g. from object models to SDL design models.
Another important aspect of implinks is that they facilitate consistency checks between the different models.
It is important to note that even though the description in SOMT of the different activities is a sequential description, this does not mean that in practice these activities can or should be carried out in sequential order. On the contrary, depending on the size and complexity of the application, the different activities can be organized in a number of different ways. This is the topic of the SOMT Projects.
The primary focus of the SOMT method is on system development using object oriented analysis and SDL design, with extra support for interface definitions in other notations like IDL [14] and ASN.1 [6]. Nevertheless, an important issue in SOMT is the possibility to use the analysis part of SOMT together with design using other notations. Some examples:
The scope of the support given by SOMT when using a design notation other than SDL is, as can be seen in Figure 2, basically:
Figure 2 :
Using SOMT analysis and design together with
design using other methods/notations
|
|
One way to manage the interfaces between components of a distributed system--where one or several of those components are SDL systems--is to make use of CORBA, and the language that has been defined specifically for specifying interfaces, IDL. Each participating component of the system is provided with a formalized interface specification that describes the defined objects that are accessible. This approach is particularly useful in a client/server environment.
CORBA and IDL are optional in the SOMT method, which means that all sections relating to them are specifically marked "CORBA:" to facilitate omission of those parts if CORBA is not used.
|
Note: CORBA support in SDT is only available on UNIX. |
How much of the system design part that is supported by SOMT is of course very much depending on the "XYZ" method used (see Figure 2). However, the support given by SOMT when using "external" components is at least the definition of the interface of the "external" components. This includes definitions of both static and dynamic aspects as will be seen in System Design.
The requirements analysis is the first activity in the SOMT method. The purpose of the activity is, as stated above, to capture and analyze the problem domain and the user requirements on the system to be built. For this purpose the system is viewed as a black-box and only the objects and concepts visible on the system boundary and outside the system are modeled.
There are five major models used in this phase:
The textual requirement model is a conventional textual requirements specification. This may come from the customers as input to the development project or it may be created as part of the requirements analysis as a complement to the other models.
The use case model consists of a set of use cases, each described using structured text and/or using MSCs and HMSCs. The purpose of this model is to capture and validate requirements from a user's point of view to make sure that the system will solve the right problem.
The requirements object model is a conventional object model, i.e. one or more diagrams illustrating a number of objects and their relations (including inheritance and aggregation relations). State charts may also be included in the object model to provide high level descriptions of the behavior of important objects. The purpose of the model is two-fold:
The system operation model is a description of the atomic transactions the system must be able to perform. The system operations can be viewed as more detailed specifications of the events that are part of the use cases.
During the requirements phase a data dictionary is also created. The data dictionary is a list of the concepts identified in this phase together with brief explanations of the concepts. It is used and refined throughout all the development phases.
In the system analysis phase the system to be built is analyzed using an object-oriented method. The purpose of the phase is to describe the architecture of the system and identify the objects that are needed to implement the required functionality. The models used in this phase are:
The analysis object model is a conventional object model, consisting of class diagrams and possibly state charts, that forms the input to the object design phase. The analysts should in this model be concerned with identifying the objects that must be present in the system. These objects may come from the requirements object model produced in the requirements analysis, or they may be added in this phase for different reasons. For example, objects may be needed to represent the control logic described by the use cases from the requirements analysis. The differences between the object model in the system analysis phase and the object model in the requirements analysis phase are:
The purpose of the system design is to define the implementation structure of the system and to identify overall design strategies. The models used in this activity are mainly:
The designer of the system will have several different aspects to cover within the system design activity:
The purpose of the object design is to create a complete and formally verified description of the behavior of the system. The models used in this phase are essentially SDL diagrams, in particular SDL process graphs that are used to define the behavior of active objects.
One very important aspect of this phase is usage of the Paste As concept that will take a user from object models to SDL diagrams. Essentially the designer of the system will in this phase have to consider two major aspects when creating the design model:
The object design also includes a testing/verification task. The purpose of this is to verify that the requirements on the system, expressed e.g. in the design use cases from system design, are correctly implemented in the design.
The implementation and testing activities are aimed at producing the final application, i.e. executable software and hardware. The activities in this phase are very much depending on the execution environment of the application but may include:
SOMT is a method specially designed to suit the development of distributed, reactive, real-time systems. It is based on well-established and industrial-strength techniques:
SOMT recognizes not only a number of models to be made, but also the importance of having a glue between these models. Therefore, SOMT introduces the Paste As concept to provide a smooth and well-defined transition between the different models, e.g. between the analysis and design, enabling traceability using implinks.
The benefit for a development project is that the analysts and developers all can use the notations best suited for each phase of a development project. The object oriented analysis strength when analyzing requirements and creating conceptual analysis models is combined with the strong back-end given by SDL tools for design, verification and code generation.
[1] I. Jacobson, S. Bylund, P. Jonsson, S. Ehnebom, Using contracts and use cases to build plugable architectures, JOOP, May 1995.
[2] I. Jacobson et al, "Object-Oriented Software Engineering", Addison-Wesley, 1992.
[3] J. Rumbaugh, Getting Started, using use cases to capture requirements, JOOP, September 1994.
[4] J. Rumbaugh et al, "Object-Oriented Modeling and Design", Prentice Hall, Englewood Cliffs, NJ, 1991.
[5] J. Rumbaugh, OMT: The Development Process, JOOP, May 1995.
[6] ITU Recommendation X.680-683, Abstract Syntax Notation One (ASN.1), 1994.
[7] ITU Recommendation Z.100, Specification and Description Language (SDL), 1994.
[8] ITU Recommendation Z.105, SDL Combined with ASN.1 (SDL/ASN.1), 1995.
[9] ITU Recommendation Z.120, Message Sequence Charts (MSC).
[10] J. Ellsberger, D. Hogrefe, A. Sarma, "SDL -- Formal Object-oriented Language for Communicating Systems", Prentice Hall Europe, 1997, ISBN 0-13-632886-5.
[11] A. Olsen, O. Færgemand, B. Møller-Pedersen, R. Reed, J.R.W. Smith, "Systems Engineering using SDL-92", North-Holland, 1994, ISBN 0-444-89872-7.
[12] F. Belina, D. Hogrefe, A. Sarma, "SDL with Applications from Protocol Specification", Carl Hansiger Verlag and Prentice Hall International, 1991, ISBN 0-13-785890-6.
[13] D. Coleman et al, "Object-oriented Development - The Fusion Method", Prentice-Hall, 1994.
[14] OMG, Common Object Request Broker: Architecture and Specification, Revision 2.0, Object Management Group, July 1995.
[15] Telelogic AB: Telelogic Tau 3.5 User's Manual, 1999.
[16] G. Booch, "Object Solutions - Managing the Object Oriented Project", Addison-Wesley, 1996.
[17] ISO Tree and Tabular Combined Notation ISO/IEC 9646-3 1992
[18] Unified Modeling Language, UML Notation Guide version 1.0, (document ad/97-01-09), Object Management Group, January 1997.
[19] David Harel, "Statecharts: a visual formalism for complex systems", Science of Computer programming (8), 1987.
[20] Unified Modeling Language, UML Notation Guide version 1.1 (document ad/97-08-05), Object Management Group, September 1997.
[21] Unified Modeling Language, UML Semantics version 1.1 (document ad/97-08-04), Object Management Group, September 1997.