 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
OMTROLL is an object-oriented modeling idea that has been formulated by combining the (object-modeling technique) and the formal specifications of the TROLL language. OMTROLL was created to exploit the practical analysis of object-modeling technique, eliminate its ambiguity and vagueness, and to exploit the formal system specifications provided by TROLL.
Brief history
There has been considerable research going on, over the past years in the areas of object oriented analysis and object oriented formal specifications. Object-modeling technique life cycle analysis concentrates mainly in software development practice whereas TROLL, oblog, FOOPS etc. are formal languages developed mainly with a mathematical background, having their roots in logic, algebra, and set theory. The need to combine these two areas of object oriented approaches into a single formalism is because the OO analysis methods do not reach the level of ordering achieved by the formal specification languages. These formal languages are being used research and applied in various software development projects.
TROLL vs object modelling approaches
 | This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2021) (Learn how and when to remove this message) |
TROLL is a formal language used to specify an object system. It is more concerned with the dynamic behaviour of an object over time. In TROLL, an object can change in a discrete manner due to certain events. The object can be created by the occurrence of certain events (birth event) and ended by certain other events (death events). The current state of an object is specified by it attributes. A role is the part played by an object temporarily and a specialization is the role played by it permanently. Objects can also be components of other objects-composite objects, or may be connected by means of some interaction. Also views can be defined that contain only certain information of the current state of the object. The central idea of TROLL is to interpret such an object as a set of observable sequential processes. So the object lifetime is a series of events occurring on the object, and the current state of the object depends on all the events that have occurred on it in the past.
Object-modeling technique model of a system consists of:
- The object model represents the structure of objects in the system, similar to an ER diagram.
- The dynamic model shows the control aspects of the system like time, interactions between objects etc.
- The functional model defines the meaning of operations and how values are changed due to interactions in the system.
Now the drawback of object-modeling technique model is that the various operations on the object are spread over into 3 different models, causing a relationship among the entities in different models (like the dynamic and object model) to become abstract. The communication also can only be represented in the functional model.
Stages in system analysis
| This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2021) (Learn how and when to remove this message) |
System analysis basically consists of following stages:
- Structure analysis: gives the details of the hierarchical and organizational structure of the system.
- Task analysis: Like its name, it determines which task is done, when it is done and who did it. It processes the input and shows how the output is obtained.
- Communication analysis: show how relationships are established between operations, and class interactions.
- Document analysis: describes the documents and rules that are used in the system.
- Process analysis: gives information about the execution of operations.
Diagrammatic representations in OMTROLL
| This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2021) (Learn how and when to remove this message) |
Behaviour diagram
These are also called state transition diagrams. They define the behaviour of the system. They are usually modeled in the initial stages. There are two main states – initial and final state. The transition from one state to another is based on conditions/actions. The behavioural diagram is further refined to details.
Community model
The community model gives an overview of all the object classes and the concurrent objects of the system. An object class encapsulates the data that describes objects of the same structure and behaviour. A complex object class can have single or multiple components.
A complex object class contains many objects. An object can perform various actions at a particular time, but cannot have a concurrency within itself. Also an object class that isn't involved in any sort of relationship (component/specialization) is called an independent object class.
Object class declaration diagram
This diagram shows the object attributes and their domains, and optional parameters. Object attributes can be:
- Object-valued: these are the attributes that behave like a pointer or reference to the object. These may further be single or multiple object-valued attributes. Constructors like: set, list, bag, and map can be used with multiple object-valued attributes.
- Data-valued
A community diagram along with its corresponding object class diagram forms the structural part of a system.
Communication diagram
As its name suggests, it diagrammatically represents the communication between objects of the system. Object modelling approaches do not support interaction between objects, so the communication diagram is introduced in OMTROLL. The boxes represent the class and inner boxes refer to events. These event boxes are connected by means of arrows. A precondition can be assigned to events. Communication within a complex object class is also possible. Communication can be of two types – a complex object communicating with its components, or concurrent objects communicate with each other.
Data type diagram
For specifying attributes and actions, user-defined data types (nat, int (integer), real, bool (boolean), string, date etc.) are used to construct new data types such as lists, records, enumeration etc.
References
- Ralf Jungclaus, Roel J. Wieringa, Peter Hartel, Gunter Saake, Thorsten Hartmann (1994). "Combining TROLL with th Object Modelling Technique". CiteSeerX 10.1.1.49.3051.
{{cite CiteSeerX}}: CS1 maint: multiple names: authors list (link) - "TROLL overview".