Você está na página 1de 7

OBJECT ORIENTED STRUCTURE

Unit-3
Object Modeling Methodologies
The Object Modeling Technique (OMT) software engineering methodology [#!omt!#] is
another well known example of a software engineering methodology. The OMT software
engineering methodology deals with object-oriented development in the analysis and
design phases.

The analysis phase starts with a problem statement which includes a list of goals and
a definitive enumeration of key concepts within a domain. This problem statement is then
expanded into three views, or models: an object model, a dynamic model, and a
functional model. The object model represents the artifacts of the system. The dynamic
model represents the interaction between these artifacts represented as events, states, and
transitions. The functional model represents the methods of the system from the
perspective of data flow. The analysis phase generates object-model diagrams, state
diagrams, event-flow diagrams, and data-flow diagrams. The analysis phase is now
complete.

The system design phase follows the analysis phase. Here the overall architecture is
established. First the system is organized into subsystems which are then allocated to
processes and tasks, taking into account concurrency and collaboration. Then persistent
data storage is established along with a strategy to manage shared-global information.
Next, boundary situations are examined to help guide trade-off priorities.

The object design phase follows the system design phase. Here the implementation
plan is established. Object classes are established along with their algorithms with special
attention to the optimization of the path to persistent data. Issues of inheritance,
associations, aggregation, and default values are examined.

Object Modeling Technique


Object Model
The object model describes the structure of the objects in the system - their identity, their
relationships to other objects, their attributes, and their operations. The object model
depicts the primary view of how the real world in which the system interacts is divided
and the overall decomposition of the system. The object model provides the framework
into which the other models are placed.

The object model is represented graphically with object class diagrams containing the
object classes and their relationships. Each application-domain concept from the real
world that is important to the application should be modeled as an object class. Classes
By:- Kapil Kumar Gupta
(Astt.Professor)
OBJECT ORIENTED STRUCTURE

are arranged into hierarchies sharing common structure and behavior and are associated
with other classes. Classes define the attributes carried by each object instance and the
operations that each object performs or undergoes.

The object class diagram should adhere to OMT's notation and exploit the capabilities of
OMT, such as links and associations, inheritance (generalization and specialization), and
aggregation. The attributes and operations need not be included in this diagram, as they
will be described below in the object class specifications.

Dynamic Model
The dynamic model describes those aspects of the system concerned with the sequencing
of operations and time - events that cause state changes, sequences of events, states that
define the context for events, and the organization of events and states. The dynamic
model captures control information without regard for what the operations act on or how
they are implemented.

The dynamic model includes event trace diagrams describing scenarios. An event is an
external stimulus from one object to another, which occurs at a particular point in time.
An event is a one-way transmission of information from one object to another. A scenario
is a sequence of events that occurs during one particular execution of a system. Each
basic execution of the system should be represented as a scenario (this may correspond to
the scenarios in your HCI mockup).

The dynamic model is represented graphically by state diagrams. A state corresponds to


the interval between two events received by an object and describes the "value" of the
object for that time period. A state is an abstraction of an object's attribute values and
links, where sets of values are grouped together into a state according to properties that
affect the general behavior of the object. Each state diagram shows the state and event
sequences permitted in a system for one object class. State diagrams also refer to other
models: actions correspond to functions in the functional model; events correspond to
operations on objects in the object model.

The state diagram should adhere to OMT's notation and exploit the capabilities of OMT,
such as transition guards, actions and activities, nesting (state and event generalization),
and concurrency.

Functional Model
The functional model describes computations and specifies those aspects of the system
concerned with transformations of values - functions, mappings, constraints, and
functional dependencies. The functional model captures what the system does, without
regard to how or when it is done.

By:- Kapil Kumar Gupta


(Astt.Professor)
OBJECT ORIENTED STRUCTURE

The functional model is represented graphically with multiple data flow diagrams, which
show the flow of values from external inputs, through operations and internal data stores,
to external outputs. Data flow diagrams show the dependencies between values and the
computation of output values from input values and functions. Functions are invoked as
actions in the dynamic model and are shown as operations on objects in the object model.

The data flow diagram should adhere to OMT's notation and exploit the capabilities of
OMT, such as nesting, control flows, and constraints.

SA/SD - Light on Functions and Data

Structured analysis /structured design (SA/SD) approach, with all the models most
physicists are used: data flow diagrams, algorithmic decomposition, flow charts, top-
down module hierarchical tree. SA/SD puts the emphasis on decomposing a system as a
set of processes and the set of data they manage, and their mutual dependencies. Hence, it
focuses upon and exposes the structure of data and the implementation details of the
processes that manipulate it, exactly those parts that in a complex software environment
are most subject to changes for improvement.

Indeed most of the effort spent is in trying to achieve first the most stable data structures,
then the hierarchical tree of processes that mutually exchange them. Unfortunately, once
defined the data, processes are so tightly depending on data structures to become difficult
to improve, if not to simply modify, and the knowledge of data structures is so deep in
the fabric of the system to discourage any evolution, even when major improvements
would then be achievable. In facts, the modules that express the relevant abstractions
depend upon the modules that contain the irrelevant details! From this derives that when
changes are made to the details, the abstractions are affected. In SA/SD, the top-down
tree of the structured program expresses also the chain of dependencies from the more
abstract modules at the top (closer to the problem domain) to the more detailed ones at
the bottom: purely implementation concerned (solution domain) modules. Therefore, if
we attempt to reuse one of those abstractions we must carry along all the details that
those abstractions depend upon (the traditional reuse). It is not an exaggeration to say that
every experiment in HEP has faced these and similar problems during its life time.

OO - Light on Interfaces
In many respects OO is an improvement in the way we can model complex tasks: we can
describe applications in terms of interfaces instead of data and processes, that is, instead
of implementation structures. The interfaces become software entities in all respect and
depend neither on the software that uses them, nor in the software which implements
By:- Kapil Kumar Gupta
(Astt.Professor)
OBJECT ORIENTED STRUCTURE

them! Interfaces are to be seen as screens behind which we can hide many different
implementations (data and processes). Therefore these interfaces represent stereotypes
relieving us from the burden of knowing their exact implementation, hence leading to
more flexible and robust designs. OO uses a completely different perspective: data and
processes are hidden within objects that have interfaces and responsibilities: an
application is a set of objects that collaborate with each other to fulfill their
responsibilities.

What we aim to with OO is that dependencies are no more on the data model and the
processes that manipulate them ( as arising from data and functional decomposition) but
on the interfaces only: given a client and a server, no part of the client has a dependency
upon the server internals; instead the client depends on the interface that hides the server
itself. But the more important thing in OO is that the interface does not depend on the
server either, actually the server too is made to depend on the interface: it is said the OO
makes a dependency inversion. This means that we can reuse (the OO reuse way) both
the server and the client in other contexts and, what is more, separately, with all the
economic and quality gains that may result from this. Only the interfaces need to be
implemented, the re-users being legitimated to implement those interfaces by any means
they choose.

Having the dependencies only on the interfaces also implies that changes made to one
part of a program (some servers) do not propagate into the rest of the application. The
changes will be contained within a particular client or server and will be irrelevant to
other software chunks elsewhere in the system. OO development is the technique with
which the realization of one of the toughest goal of software engineering is finally within
reach: open-closed components. One can add new features to the software, or modify
previous ones, without disturbing its existing capabilities. Needless to say, all this is
extremely difficult, if not impossible, to achieve with SA/SD.

Jackson System Development

Jackson System Development (JSD) is a linear software development methodology


developed by Michael A. Jackson and John Cameron in the 1980s.

Principles of operation and steps

Three basic principles of operation of JSD is that:


By:- Kapil Kumar Gupta
(Astt.Professor)
OBJECT ORIENTED STRUCTURE

• Development must start with describing and modeling the real world, rather than
specifying or structuring the function performed by the system. A system made
using JSD method performs the simulation of the real world before any direct
attention is paid to function or purpose of the system.
• An adequate model of a time-ordered world must itself be time-ordered. Main aim
is to map progress in the real world on progress in the system that models it.
• The way of implementing the system is based on transformation of specification
into efficient set of processes. These processes should be designed in such a
manner that it would be possible to run them on available software and hardware.

When it was originally presented by Jackson in 1983, the method consisted of six steps.[1]

1. Entity/Action Step
2. Initial Model Step
3. Interactive Function Step
4. Information Function Step
5. System Timing Step
6. System Implementation Step

Later, some steps were combined to create a method with only three steps[2].

1. Modeling Stage (Analysis): with the Entity/Action Step and Entity Structures Step.
2. Network Stage (Design) : with the Initial Model Step, Function Step, and System
Timing Step.
3. Implementation Stage (Realization) : The implementation Step.

Modeling Stage

In the modeling stage the designer creates a collection of entity structure diagrams and
identifies the entities in the system, the actions they perform, the time-ordering of the
actions in the life of the entities, and the attributes of the actions and entities. Entity
structure diagrams use the diagramming notation of Jackson Structured Programming
structure diagrams. Purpose of these diagrams is to create a full description of the aspects
of the system and the organization. Developers have to decide which things are important
and which are not. Good communication between developers and users of the new system
is very important.

This stage is the combination of the former Entity/Action Step and the Entity Structures
Step.

Network Stage

In the network stage a model of the system as a whole is developed and represented as a
system specification diagram (SSD) (also known as a network diagram). Network
diagrams show processes (rectangles) and how they communicate with each other, either
via state vector connections (diamonds) or via data stream connections (circles). In this
By:- Kapil Kumar Gupta
(Astt.Professor)
OBJECT ORIENTED STRUCTURE

stage is the functionality of the system defined. Each entity becomes a process or
program in the network diagram. External programs are later added to the network
diagrams. The purpose of these programs is to process input, calculate output and to keep
the entity processes up-to-date. The whole system is described with these network
diagrams and are completed with descriptions about the data and connections between the
processes and programs.

The Initial Model Step specifies a simulation of the real world. The Function Step adds to
this simulation the further executable operations and processes needed to produce output
of the system. System Timing Step provides synchronization among processes,
introduces constraints. This stage is the combination of the former ‘Initial model’ step,
the ‘Function’ step and the ‘System Timing’ step.

Implementation Stage

In the implementation stage the abstract network model of the solution is converted into a
physical system, represented as a system implementation diagram (SID). The SID shows
the system as a scheduler process that calls modules that implement the processes. Data
streams are represented as calls to inverted processes. Database symbols represent
collections of entity state-vectors, and there are special symbols for file buffers (which
must be implemented when processes are scheduled to run at different time intervals).

The central concern of Implementation Step is optimization of system. It is necessary to


reduce the number of processes because it is impossible to provide each process that is
contained in specification with its own virtual processor. By means of transformation,
processes are combined in order to limits their number to the number of processors.

Designing the diagrams


Entity structure diagram (ESD)

The diagram shows how the action entities cooperate with the system. Entity structure
diagram (ESD) notations:

• Entity: An entity is an object that is used on the system and by the system.
• Action: The actions that are carried out by entities and the actions that affect other
entities.
• Construct-Sequence: The JSD construct is identical to the SSADM Entity Life
History construct. Use a Sequence Construct to illustrate actions that are applied
from left to right.
• Construct-Selection: To reflect a choice between two or more actions. Mark the
options in the topright corner with a "o" (option).
• Construct-Recurrence: When an action repeats, place a small asterisk (*) in the
topright corner.

Normally there would be only one action underneath a Recurring Construct.

By:- Kapil Kumar Gupta


(Astt.Professor)
OBJECT ORIENTED STRUCTURE

Null component: A Null component can make sure nothing happens in an IF-ELSE
statement.

Network Diagram (ND)

Network diagrams show the interaction between the processes. Sometimes they are
referred to as System Specification Diagrams (SSD's). Network Diagram (ND) notations:

• Process: Processes represent system functions. A process model represents the


primary system functions. It generally has a relation with an outside entity
through the data stream.
• Data stream Connection: In a data stream connection, process A (the entity that
writes the data stream) actively sends information to another process B.
• State vector inspection: In a state vector connection, process B (the entity that
reads the state vector information) reads the state vector information of another
entity A.

The difference between a state vector connection and a data stream connection lies in
which process is active. In a data stream connection, the process with the information, A,
is the active process; it actively sends a message to the data stream reader B at a time that
it (A, the sender) chooses. In a state vector inspection, the process with the information ,
A, is passive; it does nothing but let the reader process B inspect its (A's) state vector. B,
the process doing the inspection, is the active process; it decides when it will read
information from A. Roughly speaking, data stream connection is an abstraction of
message passing, while state vector inspection is an abstraction for polling (and for
database retrieval).

By:- Kapil Kumar Gupta


(Astt.Professor)

Você também pode gostar