Here you will get more and more study material

1. EDUCATION HOLE PRESENTS
OBJECT ORIENTED SYSTEMS
Unit-III

2. Functional Modeling................................................................................................................ 2
Data flow diagram.................................................................................................................................................3
Specifying operations.......................................................................................................................4
(i) Identifying input and output values .................................................................................................................4
(ii) Building DFD ....................................................................................................................................................4
iii) Describing Functions........................................................................................................................................5
(iv)Identify constraints between objects ..............................................................................................................5
(v) Specifying Optimization criteria.......................................................................................................................5
A sample functional model ...................................................................................................... 6
OMT (object modeling techniques) methodologies ..........................................................................6
Phases of OMT......................................................................................................................................................7
Analysis.............................................................................................................................................................7
Design .................................................................................................................................................................10
Case studies to demonstrate methodologies ......................................................................... 10
Comparisons of methodologies..........................................................................................................................10
1. Comparisons with SA/SD ............................................................................................................................10
2. Comparisons with JSD: JSD has a different life cycle..................................................................................11
Principles of operation........................................................................................................................................11
Functional Modeling
The functional model shows how the input and output values of a program are derived. It does
this using data flow diagrams (DFD). A DFD is a networked view of the system which
represents the program’s calculations. DFDs are made up of processes, data flows, actors and
data sources. A process which is drawn as an ellipse, changes the input values into output
values. The processes in the DFD correspond to the operations in the object model. A data flow,
represented as an arrow, illustrates the flow of data through a series of connected processes.
Data flows starts and finishes at a process, actor or data store. Actors are objects and are
represented as rectangles located at the edge of the DFD. Actors can be either sources or sinks
of data. Data stores are depicted as parallel lines and provide a location for the temporary
storage of data. A functional modeling perspective concentrates on describing the dynamic
process. The main concept in this modeling perspective is the process; this could be a function,
transformation, activity, action, task etc. A well-known example of a modeling language

3. employing this perspective is data flow diagrams. The perspective uses four symbols to describe
a process, these being:
• Process: Illustrates transformation from input to output.
• Store: Data-collection or some sort of material.
• Flow: Movement of data or material in the process.
• External Entity: External to the modeled system, but interacts with it.
Now, with these symbols, a process can be represented as a network of these symbols. This
decomposed process is a DFD, data flow diagram.
Data flow diagram
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modeling its process aspects. Often they are a preliminary step used to
create an overview of the system which can later be elaborated. DFDs can also be used for the
visualization of data processing (structured design). A DFD shows what kinds of information
will be input to and output from the system, where the data will come from and go to, and where
the data will be stored. It does not show information about the timing of processes, or
information about whether processes will operate in sequence or in parallel (which is shown on a
flowchart). Data flow diagrams follow the rules of abstraction. First a top level DFD is drawn.
Each of the processes identified are continually broken up until they reach a level where no
further decomposition can occur. At this stage each process can represent a class method. As a
result of this decomposition DFD’s are drawn as a series of diagrams. A top level data flow
diagram is drawn first fig 4.6, it can be seen that the input and output values start and end with an
external source i.e. the user. The generate results process can be further decomposed as shown.

4. During analysis three models of the system were created; the object model, the dynamic model
and the functional model. These models along with the problem statement make up the analysis
of the project.
Specifying operations
(i) Identifying input and output values
List input and output values. The input and output values are parameters of events between
system and outside world. Find any input or output values missed.
(ii) Building DFD
Now construct a DFD, show each output value is completed from input values. A DFD is usually
constructed in layers. The top layer may consist of a single process, or perhaps one process to
gather inputs, compute values, and generate outputs. Within each dfd layer, work backward from
each output value to determine the function that computes it. If the inputs are operations are all
inputs of the entire diagram, you are done; otherwise some of the operation inputs are
intermediate values that must be traced backward in turn. You can also trace forward from inputs
to outputs, but it is usually harder to identify all users of an input, than to identify all the sources
of an output.

5. • Expand each non trivial process in the top level DFD into a lower level DFD.
• Most systems contain internal storage objects that retain values between iterations. An
internal store can be distinguished from a data flow or a process because it receives
values that don’t result in immediate outputs but are used at some distant time in the
future.
• The DFD show only dependencies among operations. They don’t show decisions.(control
flows)
iii) Describing Functions
When the dfd has been refined enough, write a description of each function. The description can
be in natural language, mathematical equations, pseudo code, decision tables, or some
appropriate form.
• Focus on what the function does, and not how it is implemented.
• The description can be declarative or procedural.
• A declarative description specifies the relationships between input and output values and
the relationships among output values.
For example, “sort and remove duplicate values”
Declarative: “Every value in the input list appears exactly once in the output list, and the values
in the output list are in strictly increasing order.”
Procedural:-specifies function by giving an algorithm to compute it. The purpose of the
algorithm is only to specify what the function does.
A declarative description is preferable; they don’t imply implementation but if procedural is easy
it should be used.
(iv)Identify constraints between objects
Identify constraints between objects. Constraints are functional dependencies between objects
that are not related by an input output dependency. Constraints can be on two objects at the same
time, between instances of the same object at different times (an invariant) or between instances
of different object at different times.
 Preconditions on functions are constraints that the input values must satisfy.
 Post conditions are constraints that the output values are guaranteed to hold.
 State the times or conditions under which the constraints hold.
(v) Specifying Optimization criteria
Specify values to be maximized, minimized or optimized. If there is several optimization criteria
that conflict, indicate how the trade-off is to be decided.

6. A sample functional model
Functional model specifies the result of a computation without specifying when or how they are
computed. The Data Flow Diagram (DFD) is used to model the processes involved in the system.
OMT (object modeling techniques) methodologies
During the early phases of this research, focus was on the acquisition of knowledge which is
considered to be the most difficult task in the development of a KBS system. A more general
approach based on the Object Oriented paradigm was used in systems design. Several
methodologies were examined but the most rational and more logical choice was the Object
Modeling Technique by [Rumbaing 1991]. This approach was also used by numerous
researchers in CIM related projects [Ito 1993]. The OMT approach models real world objects.
Instead of thinking about computer implementation, algorithm or techniques, focus is on real
world objects that comprise the system. This includes the behavior of objects and relationships
between objects. How and why objects behave in a particular manner during certain situations
are explicitly defined. The representation of such objects contains both data and behavior in the
form of attributes and methods. The OMT has a three phase development process consisting of
analysis, design and implementation. The analysis phase revolves around building a model of
the real-world that specifies what the system must do. Objects in the analysis phase are objects
that actually exist in the application and not computer implementations. What is defined are the
objects and relationships that define the system. If the objects belong to particular class, then
such class is defined. Relationships are always defined between objects and can consist of
objects themselves. Attributes and methods complete the description of the object. The design

7. phase includes both System and Object design. In this phase, sub-systems are organized based on
the results of analysis. In system design, resources are allocated, performances that must be
optimized are established and strategies are decided. Objects include both the data structures and
algorithms that must be implemented. Implementation covers the translation of results of the
analysis and design phases into a particular programming language. Object Oriented systems
such as Smalltalk, C++, Eiffel, Objective C, are commonly used for implementation. General
purpose programming languages can also be used but some difficulty is encountered in installing
object oriented features such as inheritance, encapsulation, polymorphism and object behavior
mechanisms. In this research, much of the focus was on the analysis phase and the determination
of important domain objects and classes. Paragraph was used as the language and the Object
Oriented Design techniques used in OMT proved to be directly implementable by its structure.
This made unnecessary involved design and implementation activities for the problem. In this
regard the following explanation focused on the analysis methodology of OMT.
Phases of OMT
Analysis
There are three models produced in the analysis phase of OMT:
1. Object model describes the static structure of the system and consists of representations of the
object as it exists in the real world. Objects are modeled by means of Object Diagrams which
may be represented as hierarchies or networks. Objects can belong to a class such that they are
instances of the class or are components of a collection under the class. Included with each
object are variables and methods or operations that the object performs. Objects are related to
each other by means of links or associations which may be other objects. Aggregation or the has-
a relationship, inheritance and generalization or the is-a relationship were used for classifying
and grouping objects.
2. Dynamic model describes aspects of the system that changes over time. This is represented by
a State Transition Diagram (STD) that describes events and states of the system. Other tools such
as the Event Trace and Event Flow Diagram could also be used to describe the dynamic model.
3. Functional model specifies the result of a computation without specifying when or how they
are computed. The Data Flow Diagram (DFD) is used to model the processes involved in the
system.
Actual OMT modeling and design was conducted only on the knowledge acquisition systems
developed because the approach was more general in nature and the specific knowledge required
for the task was not yet determined. Objects included in the system are represented by squares.
Relationships between objects are shown by lines. The generalization relationship is represented
by a triangle to designate an in-a or class-based relationship. Filled circles indicate many (e.g.

8. many sources of expertise, many knowledge bases, etc.) while the default is 1 (ordinary line ends
point). Aggregation or the "has-a" relationship is represented by a diamond and is included in
the figure to show the components of knowledge acquisition and knowledge base development.
There were two systems developed using the OMT technique, the Select Tool and the Geometry
Acquisition Tool. In the following chapters, the object, dynamic and functional models for each
system are discussed in more detail but the Object Model that includes both systems is shown in
Figure 4.1.
Figure 4.1 The OMT view of KBS development.
The dynamical model for the knowledge acquisition phase is represented by a State Transition
Diagram where the nodes or round figures represent states of the system. States are represented
in terms of object or attribute states. States represent conditions of the attributes and are the
result of an event represented by lines. An event is something that happens sometime. In this
case, it was broadened to include not only user events but also system activities that result in
different conditions for objects included in the system. The general or upper level dynamic
model for knowledge acquisition is shown.

9. Figure 4.2 Dynamic models of knowledge acquisition and KBS development.
The Functional model specifies what happens in the system. It is represented by Data Flow
Diagrams (DFDs) which shows the relationships of values resulting from system activities. Oval
figures represent processes or tasks that require an input and produce an output. Square figures
represent external agents or "actors" that produce or use data. Data stores, represented by two
lines, are objects that store data without doing anything. Lines connecting the components
represent the flow of data from one figure to the other. A simple Functional Model for the
knowledge acquisition process is described in Figure 4.3.

10. Figure 4.3 Functional model of knowledge acquisition.
Design
The design phase includes the strategy for building the solution to the problem. In this phase, the
system architecture is established and subsystems are allocated to software and hardware
components. The focus on this phase is on how to solve the problem. Algorithms, data types and
implementation decisions and details are added to determine how each described class, instant or
function operates and behaves. The components necessary to achieve the desired behavior are
assembled in this phase. Both programs developed were implemented in Paragraph.
Case studies to demonstrate methodologies
Comparisons of methodologies
There are several popular software engineering approaches for developing the software. And the
most of the approaches and based on the data flow diagrams. Two approaches to compare with
OMT, which are :
1. Structured analysis / structured Design (SA/SD)
2. Jackson Structured Design (JSD)
1. Comparisons with SA/SD: SA/SD methodology contains much common features as
OMT both methodology use similar modeling constructs and support the three orthogonal views
of a system. It includes a variety of notations for formally specifying software.

11. a. In SA/SD approached the functional model dominates, the dynamic model is next important ,
and the object model least important.
b. SA/SD organizes a system around procedures, while OMT organizes a system around real
world objects.
c. SA/SD is useful for problems where functions are more important and complex than data. d.
An SA/SD design has a clearly – designed system boundary.
2. Comparisons with JSD: JSD has a different life cycle.
JSD is the approaches where JSD does not discuss between analysis and design phases.
JSD software development consists of six steps:
• Entity action
• Entity structure
• Initial model
• Function
• System timing
• Implementation JSD approach uses graphical models but JSD is less graphically oriented
then SA/SD and OMT.
JSD
• JSD approach is complex.
• JSD places more emphasis on action and less on attributes that OMT.
• Jackson system development (JSD) is a linear software development methodology
developed by Michael A. Jackson and John Cameron in the 1980s.
Principles of operation
Three basic principles of operation of JSD is that:
• Development must start with describing and modelling 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.