![]() |
![]() |
![]() |
![]() |
![]() |
SOMT Projects
A development project that uses an object oriented approach like the SOMT method is not very different from any other development project. The project has a starting point, the project members work hard and finally the project is finished, hopefully successfully accomplishing the goals of the project in terms of quality, functionality and delivery time. The skill of planning, managing and executing a successful development effort has been studied and described in many books and it is outside of the scope of this document to give a complete treatment of this topic. A recent book that treats management and planning issues for object oriented projects is "Object Solutions" [33] which is recommended for further reading.
Nevertheless, this section is intended to give some indications on how to organize the activities and models of the SOMT method into a project. The description is intended to be suitable for a medium sized project where the effort is big enough to force the development to be divided into several development teams. A smaller project would most likely need less formalism in the development process and a bigger one more control.
Project Phases
From an external point of view (like a manager's point of view) it is useful to organize a project into a number of phases, where each phase represents work performed during a limited period of time resulting in a set of artifacts, deliverables that summarizes the state of the work after the phase is finished. There is a fundamental difference between the phases of a project and the activities as used in this document to describe the SOMT method:
- The phases are used to organize the calendar time of a project.
- The activities represent a categorization of different kinds of tasks by their nature, not by their relative time in a project.
Nevertheless there is a strong relation between the phases of a project and the activities that has to be performed. There is a dependency between the activities of the SOMT method that indicates an ordering in time between the activities. There is no reason to start the system/object design before a substantial amount of work has been done on the system analysis. Likewise there is no reason to start the system analysis before there is a common understanding of the requirements elaborated in the requirements analysis. On the other hand it would be a waste of time and even dangerous for the project to get bogged down with the details of the requirements for a substantial amount of time without considering their consequences in terms of architecture and design.
The dependency between the activities indicates that a fruitful way to organize a SOMT project is to consider it as a sequence of iterations of the activities. The phases are introduced as a means to get a visibility of important milestones and deliverables from the project. One way to define the phases of a SOMT project is as follows:
Each of these phases has a section of its own in this chapter.
Multi-User Support
There is often a need to facilitate multi-user support when working with an SDL system managed by SDL Suite. That is, we want to have a development environment capable of handling parallel development. One way to get support for the development process is through using Configuration Management (CM). With CM is usually meant the check in and check out control of sources and binaries, and the ability to perform builds of these entities.
If CM is to be used within a project it has to be planned for. This planning is not something that is carried out in isolation. It is a part of the overall project planning process and is implemented throughout the life cycle of the project. The plan should cover activities to be performed, the schedule for the activities, the assigned responsibilities and the resources needed (including staff, tools and computer facilities). A key task is to decide exactly which items that are to be controlled and define the engineers responsible for these items. During the development process the code is usually stored in a database based on a revision control system. The developers checkout a copy of it to their own personal workspace. Changes are then made locally and checked in when completed and tested. The developer is responsible for making sure that the module works before he checks in the changed files.
When several users work on an SDL system, the management of the system file may be difficult to synchronize. This problem is solved if every user or group has control over their own part of the system file. The multi-user support in SDL Suite is based on letting the users split the system file into several files, called control unit files. Where to split the system is an active action taken by the user, but the idea is to partition the system according to work responsibilities and to assign a control unit to each partition. Apart from supporting parallel development, the control unit files also facilitate merging of the individual results to one common system file. An example is a large SDL system where there are several blocks on system level developed in parallel by different developers. Each block could then be associated with a control unit file. Now, the blocks can be updated independently and the changes are shaping the local control unit files. Also, there is no need to manually merge changes into the system file when the work has been done. This is because the management of control unit files, performed by the Organizer, includes the merge.
Another way to get support for parallel development is through using the object oriented concepts of SDL, i.e. types and packages. Instead of introducing a block reference symbol for every subsystem we introduce a block type. The block types are placed in packages together with the signal and data type definitions that are needed within that particular block. If two blocks need the same signals and data types then these definitions are placed in a package of their own. Other packages can then use this package. In the same way as we define block types we can also define process types instead of process reference symbols. The different packages containing the types can be analyzed independently. We can also create instances of the types to simulate, verify and validate the behavior of a particular part of the system. When all parts of the system have been designed and tested we put them together, i.e. we create instances of the types and test and verify the overall system behavior.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |