ALLAMA IQBAL OPEN

UNIVERSITY
ISLAMABAD
Name: M.Irtiqua Khalid

Roll No: B0456054

7th Semester (Autumn

Semester: 2020)

Course: Analysis design

Code: 3464
Assignment NO 1
Question NO 1:
(a) What is meant by object orientation? Explain different representations of
object oriented technique.

Object Orientation:

In the past, information systems used to be defined primarily by their functions: data and
functions were kept separate and associated using input and output relations. The object-
oriented approach, however, focuses on objects that represent abstract or concrete things in
the real world. These objects are first defined by their character and their properties, which are
represented by their internal structure and their attributes (data). The behavior of these objects
is described by methods (functions).

Objects form a capsule, which combines the characteristics with behavior. Objects are intended
to enable programmers to map a real problem and its proposed software solution on a one-to-
one basis.

Typical objects in a business environment are, for example, 'Customer', 'Order', or 'Invoice'.
From Release 3.1 onwards, Business Object Repository (BOR) of SAP Web Application Server
ABAP has contained examples of such objects. The BOR object model will be integrated into
ABAP Objects in the next release by migrating the BOR object types to the ABAP class library. A
comprehensive introduction to object orientation as a whole would go far beyond the limits of
this introduction to ABAP Objects. This documentation introduces a selection of terms that are
used universally in object orientation and also occur in ABAP Objects. In subsequent sections, it
goes on to discuss in more detail how these terms are used in ABAP Objects. The end of this
section contains a list of further reading, with a selection of titles about object orientation.

Objects: Objects are instances of classes. They contain data and provides services. The data
forms the attributes of the object. The services are known as methods (also known as
operations or functions). Typically, methods operate on private data (the attributes, or state of
the object), which is only visible to the methods of the object. Thus the attributes of an object
cannot be changed directly by the user, but only by the methods of the object. This
guarantees the internal consistency of the object.

Classes: Classes describe objects. From a technical point of view, objects are runtime instances of
a class. In theory, you can create any number of objects based on a single class. Each instance
(object) of a class has a unique identity and its own set of values for its attributes.

Object References: In a program, you identify and address objects using unique object
references. Object references allow you to access the attributes and methods of an object. In
object-oriented programming, objects usually have the following properties:

Encapsulation: Objects restrict the visibility of their resources (attributes and methods) to
other users. Every object has an interface, which determines how other objects can interact
with it. The implementation of the object is encapsulated, that is, invisible outside the object
itself.

Inheritance: You can use an existing class to derive a new class. Derived classes inherit the
data and methods of the superclass. However, they can overwrite existing methods, and also
add new ones.
Polymorphism: Identical (identically named) methods behave differently in different classes.
In ABAP Objects, polymorphism is implemented by redefining methods during inheritance and
by using constructs called interfaces.

Uses of Object Orientation:

Below are some of the advantages of object-oriented programming:

Complex software systems become easier to understand, since object-oriented structuring

provides a closer representation of reality than other programming techniques.

In a well-designed object-oriented system, it should be possible to implement changes at class

level, without having to make alterations at other points in the system. This reduces the overall
amount of maintenance required.

Using polymorphism and inheritance, object-oriented programming allows you to reuse

individual components.

In an object-oriented system, the amount of work involved in revising and maintaining the
system is reduced, since many problems can be detected and corrected in the design phase.

Achieving these goals requires:

 Object-oriented programming languages

Object-oriented programming techniques do not necessarily depend on object-oriented

programming languages. However, the efficiency of object-oriented programming depends
directly on how object oriented language.

(b) Describe a large software system that was supposed to be created in the last
five years behind schedule, over budget or failed to perform as expected. What
factors were blamed? How called the failure have been avoided?

We know why projects fail, we know how to prevent their failure – so why do they still
fail?”(2)This statement could be applied to the recent Space Shuttle disaster, or the 2003
collapse of a large portion of the U.S. electrical grid. But the author was talking about
Information Technology and Information System project failures, as they existed in 1994.
Information Technology and Information System failures have been the topic of many articles,
conferences, symposiums, studies, and research initiatives. The literature of the IT and IS
community is rife with articles and commentary about project failures. But just how bad is the
situation? Do a large percent of projects really fail or do we only hear the bad news? What is
failure and what is success? And lastly, what can you do to improve your success quotient?
Let’s start by looking at project failure rates and why projects fail. There are many writers who
tell us why projects fail. For instance, Field(12) tells us that “projects fail too often because the
project scope was not fully appreciated and/or user needs not fully understood.” Hulme(13)
tells us that “MIS projects and associated procurements take place in an environment
characterized by the following: Lack of management continuity and an incentive system that
encourages overly optimistic estimates of the benefits that can be attained from doing the
project.” And Leitch (5) tells us that high user expectations can actually be the cause of project
failure. Hoffman (15) tells that projects fail because of poor alignment between IT departments
and business users. And in another article Hoffman(9) tells us that project managers too often
act as “process cops and report compilers and lose sight of what they’re supposed to be doing –
to make sure projects are running effectively”. Hodgson (23) style='mso-bidi-font-weight:
normal’ tells us that “projects fail – that’s the fact of life. Too many fail because the average
project is like an iceberg – 9/10ths of it lay hidden from view”. All of these writers are correct.
But none of these authors are reporting systematic research of the mechanisms that cause
project success or failure. And none of them provide insight into the rate of project failures.
The top 5 factors found in successful projects are:
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
These are the top 5 of 10 listed in the report. The report concludes that these were the
elements that were most often pointed to as major contributors to project success. Will these
elements alone guarantee success? Never. But if these are done well, a project, according to
the Standish Group, will have a much higher probability of success.
The next category of differentiators from the Standish report deals with projects that proved
to be “Challenged;” that is they were completed buy were over budget, over time, or did not
contain all functions and features originally required.
The top 5 indicators found in “Challenged” projects are:
1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements & Specifications
4. Lack of Executive Support
5. Technical Incompetence

1. Incomplete Requirements
2. Lack of user involvement
3. Lack of Resources
4. Unrealistic Expectations
5. Lace of Executive Support
6. Changing Requirements & Specifications
7. Lack of Planning
8. Didn’t Need it Any Longer
9. Lack of IT management
10. Technical Illiteracy
Notice in the above three project outcomes, user involvement is listed as the first or
second item in each.
ANOTHER PERSPECTIVE TO SUCCESS AND FAILURE:
The results of a research paper(6), presented at a 1991 PMI symposium, found that “there are
areas that should be emphasized by project managers who are committed to the success of
their projects.” The research method used Content Analysis of showcase articles featured in
pmNETwork and Project Management Journal. The researchers studied 24 areas of project
management and found that 3 of the 24, if done well, clearly indicated that a project had a high
probability of success. The paper states “it may be inferred that these three variables (Good
Planning, Clear Responsibility and Accountability, and Schedule Control) in particular have the
greatest impact on the performance of the project.” Do not, however, conclude that all of the
other areas were then not important to project success. The paper also tells us “the data
suggests that many different variables are needed to accomplish a successful project. Let’s look
at the three key areas that, if done well, point to a successful project completion.
Good Planning The first indicator, Good Planning, requires excellent forward planning, which
includes detailed planning of the process implementation stages, task timeliness, fall-back
positions, and re-planning. Notice that initial planning is not enough. Projects often take wrong
turns, or initial solutions prove unfounded. The project manager who does not prepare
to re-plan, or has not considered and planned fall-back positions when initial plans fail,
will often find that the project first stalls, and then fails. We must remember that project
management is not a straight-line process, but an iterative process that requires agile
rethinking as the known environment changes before your eyes.
Clear Responsibility and Accountability of Team Members:
This requires that all team members have a clear understanding of their roles and duties in the
project. They must understand how expectations vs. achievements will be measured and
graded. It is left to the project manager to properly implement the communication of these
responsibilities, to provide feedback, and to assure all understand that for which they will be
held accountable.

Schedule Control:
This requires the continual monitoring and measurement of time, milestones, people, and
equipment schedules. Properly done schedule control will also give the first hint that initial
planning may not be going according to schedule. If you pickup on these hints, you have an
opportunity to implement a fallback position and/or re-plan to get back on track.
The same paper finds two attributes that appeared equally for projects that succeeded or
failed. These two were: Use of Consultants, and Well Qualified Personnel. Equal numbers of
successful and failed projects used consultants, and the same was true for well-qualified
personnel. It is perhaps disappointing that these two attributes did not portend project
success. Obviously there are many other variables that hold great weight in determining the
ultimate outcome of an IT project. Lastly this same study listed four things that foreshadowed a
failed project. There were: Lack of Efficient Internal Communication Links, Lack of Efficient
External Communication Links, Lack of Responsive Decision Making, and Lack of Effective
Teamwork. These appeared most frequently in a negative context in failed projects. So at this
point we have several lists of things that might indicate project success and others that might
indicate project failure. But there is one thing primarily that you must recognize in all of these
lists. There are no stock answers, and there is no one list that will guarantee success. IT and IS
projects are complex by nature, and each is unique. It is very difficult to plan with complete
certainty something that has never before been done. Every single factor in all of these lists is
important and must be considered for each project. The most difficult part may be prioritizing
the factors. Which are most important? Which must be done first? Hopefully the lists will help
you answer these questions.
Question NO 2:
Differentiate the following terms with suitable examples:

(a) Link and association

The major difference between link and association is that link is a physical or
theoretical connection between the objects whereas association is a group of links
with same structure and semantics. Associations are implemented in programming
languages as a reference model in which one object is referenced from another.
While links cannot be referenced as these are not objects by itself, but rely on the
objects.

The link and association are mostly used in UML designing which can be seen as the
principle of software engineering. UML designing helps in understanding and
minimizing the dependencies among various design elements.

Definition of Link:

The logical or physical connection among objects is referred to as link. These links are used to
relate multiple objects and represent a relationship between objects. We cannot reference
links, because a link is not a component of either object by its own but do rely on the objects.

The link can be explained by the example such as students studying in university or
universities in which there would be several numbers of students studying in one or more than
one universities which can be represented by the below-given diagram.

Definition of Association:

A collection of links is specified by an association which have common structure and semantics.
Association is essentially bidirectional. As the class describes the potential objects, in the similar
fashion an association represents a group of possible links.
(b) Multiple inheritance and Multi-level inheritance
Multiple Inheritance:
A class can be derived from more than one base classes in Python. This is called multiple
inheritance. In multiple inheritance, the features of all the base classes are inherited into
the derived class (see the figure below).

The syntax for multiple inheritance is similar to single inheritance.

class Base1:
pass

class Base2:
pass

class MultiDerived(Base1, Base2):

pass

Multilevel Inheritance:

We also have Multilevel Inheritance at play. We can also inherit form a derived class. This is
called multilevel inheritance. It can be of any depth in Python. In our example, Cube 'is a'
Rectangle which 'is a' Shape...

class Base:
pass

class Derived1(Base):
pass

class Derived2(Derived1):
pass

Here, Derived1 is derived from Base, and Derived2 is derived from Derived1.
 (c) Event and State:
The event state diagram shows possible event states and describes how transitions occur
between these states based on the values in the alerts.status Severity and Tally fields.
The diagram also shows how different event types are handled.
The event state diagram is shown below. Each event is assigned one of these states as it passes
through the Event Gateway. Each state transition corresponds to an updated event received from
the Object Server. The event states are shown with an associated color as follows:
 Red indicates an active problem state.
 Green indicates an active clear state.
 White indicates that this is not an active state.

Event state transitions

Each transition is labelled on the diagram with a number from 1 to 8. The following table lists
the transitions associated with each label.

Label Field values in updated event

1 Severity =0

2 Severity = 0

Tally: Unchanged from previous event

3 Severity: 0

Tally: Changed from previous event

Label Field values in updated event

4 Severity: Non-zero

5 Severity: Non-zero

Tally: Unchanged from previous event

6 Severity: Non-zero

Tally: Changed from previous event

7 Type = 2: Resolution

8 Type = 13:Information

Table 1. Transition labels

Event state descriptions

Event states are listed in the following table. All of the states listed refer to events of Type = 1
(Problem events), unless otherwise stated.

State Description

Cleared The severity zero event was not previously known to the Event Gateway, or
was in an active problem state.

Deleted The event has been deleted from the Object Server. As this can happen at any
time, this state can be reached from any other state except Unknown.
Deletions are sent to plug-ins over the plug-in interface, and the state of the
event in the Event Gateway becomes Unknown.

Information Any incoming event that has the type Information (Type = 13) is given the
Information state, irrespective of other field values.

Occurred The non-zero severity event was not previously known to the Event Gateway.

Re-awakened The non-zero severity event was previously known to the Event Gateway, but
State Description

was not in an active problem state.

Re-cleared The severity zero event was previously known to the Event Gateway, and has re-
occurred.

Re-occurred The non-zero severity event was previously known to the Event Gateway and a new
occurrence of that problem event has occurred.

Re-synchronize The Event Gateway has resynchronized with the ObjectServer. This is a synthetic state
that does not correspond to any single ObjectServer event.

Resolution Any incoming event that has the type Resolution (Type = 2) is given the Resolution
state, irrespective of other field values.

Unknown The event has not been detected by the Event Gateway. This is the initial and final
state.

UpdateCleared The severity zero event was previously known to the Event Gateway, and an update,
as opposed to a reoccurrence, has been detected.

UpdateOccurred The non-zero severity event was previously known to the Event Gateway, and an
update, as opposed to a reoccurrence, has been detected.

(d) Concrete class and Abstract class

Abstract Class:
An abstract class is a type of class in Java that is declared by the abstract keyword. An abstract
class cannot be instantiated directly, i.e. the object of such class cannot be created directly using
the new keyword. An abstract class can be instantiated either by a concrete subclass or by
defining all the abstract method along with the new statement. It may or may not contain an
abstract method. An abstract method is declared by abstract keyword, such methods cannot have
a body. If a class contains an abstract method, then it also needs to be abstract.

Concrete Class:
A concrete class in Java is a type of subclass, which implements all the abstract method of its
super abstract class which it extends to. It also has implementations of all methods of
interfaces it implements.
Abstract Class vs Concrete Class
1. Modifier: An abstract class is declared using abstract modifier. Concrete class should not
be declared using abstract keyword, on doing so, it will also become an abstract class.
2. Instantiation: An abstract class cannot be instantiated directly, i.e. object of such class
cannot be created directly using new keyword. An abstract class can be instantiated
either by a concrete subclass or by defining all the abstract method along with the new
statement. A concrete class can be instantiated directly, using a new keyword.
Example: Invalid direct instantiation of an abstract class.
filter_none
brightness_4

abstract class DemoAbstractClass

{ abstract void display();
}

public class JavaApplication {

public static void main(String[] args)
{
DemoAbstractClass AC = new
DemoAbstractClass(); System.out.println("Hello");
}
}
prog.java:9: error: DemoAbstractClass is abstract; cannot be instantiated
DemoAbstractClass AC = new DemoAbstractClass();
^

Question NO 3:
(a) What is object modeling? Discuss different components of object
model with suitable example.

1. The properties of objects in general in a specific computer programming language,

technology, notation or methodology that uses them. Examples are the object models
of Java, the Component Object Model (COM), or Object-Modeling Technique (OMT).
Such object models are usually defined using concepts such as class, generic function,
message, inheritance, polymorphism, and encapsulation. There is an extensive
literature on formalized object models as a subset of the formal semantics of
programming languages.
 2. A collection of objects or classes through which a program can examine and manipulate
some specific parts of its world. In other words, the object-oriented interface to some
service or system. Such an interface is said to be the object model of the represented
service or system. For example, the Document Object Model (DOM) [1] is a collection of
objects that represent a page in a web browser, used by script programs to examine
and dynamically change the page. There is a Microsoft Excel object model [2] for
controlling Microsoft Excel from another program, and the ASCOM Telescope
Driver [3] is an object model for controlling an astronomical telescope.
An object model consists of the following important features:
Object Reference
Objects can be accessed via object references. To invoke a method in an object, the
object reference and method name are given, together with any arguments.
Interfaces
An interface provides a definition of the signature of a set of methods without specifying their
implementation. An object will provide a particular interface if its class contains code that
implement the method of that interface. An interface also defines types that can be used to
declare the type of variables or parameters and return values of methods.
Actions
An action in object-oriented programming (OOP) is initiated by an object invoking a method in
another object. An invocation can include additional information needed to carry out the
method. The receiver executes the appropriate method and then returns control to the
invoking object, sometimes supplying a result.
Exceptions
Programs can encounter various errors and unexpected conditions of varying seriousness.
During the execution of the method many different problems may be discovered. Exceptions
provide a clean way to deal with error conditions without complicating the code. A block of
code may be defined to throw an exception whenever particular unexpected conditions or
errors arise. This means that control passes to another block of code that catches the
exception.

Component Object Model (COM):

As defined by Microsoft, the Component Object Model (COM) is an object-based software
architecture that allows applications to be built from binary software components. COM is the
foundation for various Microsoft technologies including OLE, ActiveX, Distributed COM (DCOM),
COM+, and Microsoft Transaction Server (MTS).
COM is not a programming language, rather it is a specification. The goal of COM is to allow
applications to be built using components. These COM components can be created by different
vendors, at different times, and using different programming languages. Also, COM
components can run on different machines and different operating systems.

The following concepts are fundamental to the way COM works:

 COM Interfaces: A group of related functions implemented by the COM class. COM
interfaces are the mechanisms by which COM objects expose their functionality to
applications and other components. An interface is a table of pointers to functions that are
implemented by the object. The table represents the interface and the functions to which
the table points represent the methods of that interface. COM objects can expose multiple
interfaces. Each interface has its own unique interface ID (IID).

 IUnknown: This is the basic COM interface on which all other interfaces are based;
it provides reference counting and interface querying mechanisms. IUnknown
allows navigation to all other interfaces exposed by the object.

 Reference counting: This is a mechanism by which an interface determines it is no longer

being used and is, therefore, free to remove itself. IUnknown uses the methods AddRef
and Release to implement reference counting.
 QueryInterface: This is the IUnknown method used to query an object for a given interface.
 Aggregation: This is a technique by which one object can make use of another.

 Marshaling: This mechanism lets objects be used across thread, process, and
network boundaries, thus providing location independence.
 (b) Elaborate different notations used in object modelling.

1. Experimental Object-Oriented Modelling

DEFF Research Database (Denmark)

Hansen, Klaus Marius

Through, e.g., technical prototyping and active user involvement. We introduce and examine
experimental object-oriented modelling as the intersection of these practices. The contributions of
this thesis are expected to be within three perspectives on models and modelling in experimental
system. development: Grounding We develop an empirically based conceptualization
of modelling and use of models in system development projects characterized by a high degree of
uncertainty in requirements and point to implications for tools and techniques for modelling in
such a setting. Techniques we introduce. This thesis examines object-oriented modelling in
experimental system development. Object-oriented modelling aims at representing concepts and
phenomena of a problem domain in terms of classes and objects. Experimental system
development seeks active experimentation in a system development project.

2. Object Oriented Modelling and Dynamical Simulation

DEFF Research Database (Denmark)

Wagner, Falko Jens; Poulsen, Mikael Zebbelin

1998-01-01

This report with appendix describes the work done in master project at DTU. The goal of the
project was to develop a concept for simulation of dynamical systems based
on object oriented methods. The result was a library of C++-classes, for use when both
building component based models and when...

3. Apricot - An Object-Oriented Modeling Language for Hybrid

Systems OpenAIRE

Fang, Huixing; Zhu, Huibiao; Shi, Jianqi

2013-01-01

We propose Apricot as an object-oriented language for modeling hybrid systems. The language
combines the features in domain specific language and object-oriented language that fills the gap
between design and implementation, as a result, we put forward the modeling language with
simple and distinct syntax, structure and semantics. In addition, we introduce the concept of
 design by convention into Apricot. As the characteristic of object-oriented and the component
architecture in Apricot, we c...

4. An object-oriented approach to energy-economic

modeling Energy Technology Data Exchange (ETDEWEB)

Wise, M.A.; Fox, J.A.; Sands, R.D.

1993-12-01

In this paper, the authors discuss the experiences in creating an object-

oriented economic model of the U.S. energy and agriculture markets. After a discussion of some
central concepts, they provide an overview of the model, focusing on the methodology of
designing an object-oriented class hierarchy specification based on standard microeconomic
production functions. The evolution of the model from the class definition stage to programming it
in C++, a standard object-oriented programming language, will be detailed. The authors then
discuss the main differences between writing the object-oriented program versus a procedure-
oriented program of the same model. Finally, they conclude with a discussion of the advantages
and limitations of the object-oriented approach based on the experience in building energy-
economic models with procedure-oriented approaches and languages.

5. C++, objected-oriented programming, and astronomical data models

Science.gov (United States)

Farris, A.

1992-01-01

Contemporary astronomy is characterized by increasingly complex instruments and observational

techniques, higher data collection rates, and large data archives, placing severe stress on software
analysis systems. The object-oriented paradigm represents a significant new approach to software
design and implementation that holds great promise for dealing with this increased complexity.
The basic concepts of this approach will be characterized in contrast to more traditional procedure-
oriented approaches. The fundamental features of objected-oriented programming will be
discussed from a C++ programming language perspective, using examples familiar to astronomers.
This discussion will focus on objects, classes and their relevance to the data type system; the
principle of information hiding; and the use of inheritance to implement
generalization/specialization relationships. Drawing on the object-oriented approach, features of a
new database model to support astronomical data analysis will be presented.
6. Model-Based Software Testing for Object-Oriented Software

Science.gov (United States)

Biju, Soly Mathew

2008-01-01

Model-based testing is one of the best solutions for testing object-oriented software. It has a
better test coverage than other testing styles. Model-based testing takes into consideration
behavioral aspects of a class, which are usually unchecked in other testing methods. An increase
in the complexity of software has forced the software industry

7. An object-oriented approach to evaluating multiple spectral models

International Nuclear Information System (INIS)

Majors, R.E.; Richardson, W.M.; Seymour, R.S.

1995-01-01

A versatile, spectroscopy analysis engine has been developed by using object-oriented design and
analysis techniques coupled with an object-oriented language, C++. This engine provides the
spectroscopes with the choice of several different peak shape models that are tailored to the type
of spectroscopy being performed. It also allows ease of development in adapting the engine to
other analytical methods requiring more complex peak fitting in the future. This results in a
program that can currently be used across a wide range of spectroscopy applications and
anticipates inclusion of future advances in the field. (Author) 6 refs; 1 fig

8. Object-oriented biomedical system modelling--the language.

Science.gov (United States)

Hakman, M; Groth,

T 1999-11-01

The paper describes a new object-oriented biomedical continuous system modelling language
(OOBSML). It is fully object-oriented and supports model inheritance, encapsulation,
and model component instantiation and behavior polymorphism. Besides the traditional
differential and algebraic equation expressions the language includes also formal expressions for
documenting models and defining model quantity types and quantity units. It supports explicit
definition of model input-, output- and state quantities, model components and component
connections. The OOBSML model compiler produces self-contained, independent,
 executable model components that can be instantiated and used within other
OOBSML models and/or stored within model and model component libraries. In this way complex
models can be structured as multilevel, multi-component model hierarchies. Technically the
model components produced by the OOBSML compiler are executable computer code objects
based on distributed object and object request broker technology. This paper includes both the
language tutorial and the formal language syntax and semantic description.

9. Object Oriented Toolbox for Modelling and Simulation of Dynamical Systems

DEFF Research Database (Denmark)

Poulsen, Mikael Zebbelin; Wagner, Falko Jens; Thomsen, Per Grove

1998-01-01

This paper presents the results of an ongoing project, dealing with design and implementation of
a simulation toolbox based on object oriented modelling techniques. The paper describes an
experimental implementation of parts of such a toolbox in C++, and discusses the experiences
drawn from that process. Essential to the work is the focus on simulation of complex dynamical
systems, from modelling the single components/subsystems to building complete system such a
toolbox in C++, and discusses the experiences drawn from that process.

10. Improving Quality in Object-Oriented Software. Systematic Refinement and Translation

of Models to Code

OpenAIRE

Bunse, C.; Atkinson, C.

1999-01-01

The reliable attainment of quality requirements is still a major weakness of the object-oriented
development paradigm, with a significant proportion of object-oriented systems either failing to
work correctly, or failing to do so in a way that meets non-functional requirements. One of the
main reasons for this problem is the discrepancy between the various object-
oriented languages/notations typically used during the course of an object-oriented project and
the lack of well-defined mappings b.

11. Ferromanganese Furnace Modelling Using Object-Oriented

Principles Energy Technology Data Exchange (ETDEWEB)

Wasboe, S.O.
 1996-12-31

This doctoral thesis defines an object-oriented framework for aiding unit process modelling and
applies it to model high-carbon ferromanganese furnaces. A framework is proposed for
aiding modelling of the internal topology and the phenomena taking place inside unit processes.
Complex unit processes may consist of a number of zones where different phenomena take place.
A topology is therefore defined for the unit process itself, which shows the relations between the
zones. Inside each zone there is a set of chemical species and phenomena, such as reactions, phase
transitions, heat transfer etc. A formalized graphical methodology is developed as a tool
for modelling these zones and their interaction. The symbols defined in the graphical framework
are associated with objects and classes. The rules for linking the objects are described using OMT
(Object Modeling Technique) diagrams and formal language formulations. The basic classes that
are defined are implemented using the C++ programming language. The ferromanganese process
is a complex unit process. A general description of the process equipment is given, and a detailed
discussion of the process itself and a system theoretical overview of it. The object-
oriented framework is then used to develop a dynamic model based on mass and energy balances.
The model is validated by measurements from an industrial furnace. 101 refs, 119 figs., 20 tabs.

12. Field Model: An Object-Oriented Data Model for Fields

Science.gov (United States)

Moran, Patrick J.

2001-01-01

We present an extensible, object-oriented data model designed for field data entitled
Field Model (FM). FM objects can represent a wide variety of fields, including fields of arbitrary
dimension and node type. FM can also handle time-series data. FM achieves generality through
carefully selected topological primitives and through an implementation that leverages the
potential of template C++. FM supports fields where the nodes values are paired with any cell
type. Thus FM can represent data where the field nodes are paired with the vertices ("vertex-
centered" data), fields where the nodes are paired with the D-dimensional cells in R (sup D) (often
called "cell-centered" data), as well as fields where nodes are paired with edges or other cell types.
FM is designed to effectively handle very large data sets; in particular FM employs a demand-
driven evaluation strategy that works especially well with large field data. Finally, the interfaces
developed for FM have the potential to effectively abstract field data based on adaptive meshes.
We present initial results with a triangular adaptive grid in R (sup 2) and discuss how the same
design abstractions would work equally well with other adaptive-grid variations, including meshes
in R (sup 3).

13. Object-Oriented Approach to Modeling Units of Pneumatic Systems

Directory of Open Access Journals (Sweden)

 Yu. V. Kyurdzhiev

2014-01-01

Full Text Available The article shows the relevance of the approaches to the object-oriented
programming when modeling the pneumatic units (PU. Based on the analysis of the calculation
schemes of aggregates pneumatic systems two basic objects, namely a cavity flow and a material
point were highlighted. Basic interactions of objects are defined. Cavity-cavity interaction: ex-
change of matter and energy with the flows of mass. Cavity-point interaction: force interaction,
exchange of energy in the form of operation. Point-point in-traction: force interaction, elastic
interaction, inelastic interaction, and inter-vals of displacement. The authors have developed
mathematical models of basic objects and interactions. Models and interaction of elements are
implemented in the object-oriented programming. Mathematical models of elements of PU design
scheme are implemented in derived from the base class. These classes implement the models of
flow cavity, piston, diaphragm, short channel, diaphragm to be open by a given law, spring,
bellows, elastic collision, inelastic collision, friction, PU stages with a limited movement, etc. A
numerical integration of differential equations for the mathematical models of PU design scheme
elements is based on the RungeKutta method of the fourth order. On request each class performs a
tact of integration i.e. Calculation of the coefficient method. The paper presents an integration
algorithm of the system of differential equations. All objects of the PU design scheme are placed in
a unidirectional class list. Iterator loop cycle initiates the integration tact of all the objects in the
list. One in four iteration makes a transition to the next step of integration. Calculation process
stops when any object shows a shutdowns flag. The proposed approach was tested in the
calculation of a number of PU designs. With regard to traditional approaches to modeling, the
authors-proposed method features in easy enhancement, code reuse, high reliability

14. Modeling a terminology-based electronic nursing record system: an object-oriented approach.

Science.gov (United States)

Park, Hyeoun-Ae; Cho, InSook; Byeun, NamSoo

2007-10-01

The aim of this study was to present our perspectives on healthcare information analysis at a
conceptual level and the lessons learned from our experience with the development of a
terminology-based enterprise electronic nursing record system - which was one of components in an
EMR system at a tertiary teaching hospital in Korea - using an object-oriented system analysis and
design concept. To ensure a systematic approach and effective collaboration, the department of
nursing constituted a system modeling team comprising a project manager, systems analysts, user
representatives, an object-oriented methodology expert, and healthcare informaticists (including the
authors). A rational unified process (RUP) and the Unified Modeling Language were used as a
development process and for modeling notation, respectively. From the scenario and RUP approach,
user requirements were formulated into use case sets and the sequence of
 activities in the scenario was depicted in an activity diagram. The structure of the system was
presented in a class diagram. This approach allowed us to identify clearly the structural and
behavioral states and important factors of a terminology-based ENR system (e.g., business
concerns and system design concerns) according to the viewpoints of both domain and technical
experts.

15. Object-oriented process dose modeling for glovebox operations

International Nuclear Information System (INIS)

Boerigter, S.T.; Fasel, J.H.; Kornreich, D.E.

1999-01-01

The Plutonium Facility at Los Alamos National Laboratory supports several defense and
nondefense-related missions for the country by performing fabrication, surveillance, and research
and development for materials and components that contain plutonium. Most operations occur in
rooms with one or more arrays of glove boxes connected to each other via trolley glove boxes.
Minimizing the effective dose equivalent (EDE) is a growing concern as a result of steadily declining
allowable dose limits being imposed and a growing general awareness of safety in the workplace.
In general, the authors discriminate three components of a worker's total EDE: the primary EDE,
the secondary EDE, and background EDE. A particular background source of interest is the nuclear
materials vault. The distinction between sources inside and outside of a particular room is arbitrary
with the underlying assumption that building walls and floors provide significant shielding to justify
including sources in other rooms in the background category. Los Alamos has developed the
Process Modeling System (Pro MoS) primarily for performing process analyses of nuclear
operations. Pro MoS is an object-oriented, discrete-event simulation package that has been used to
analyze operations at Los Alamos and proposed facilities such as the new fabrication facilities for
the Complex-21 effort. In the past, crude estimates of the process dose (the EDE received when a
particular process occurred), room dose (the EDE received when a particular process occurred in a
given room), and facility dose (the EDE received when a particular process occurred in the facility)
were used to obtain an integrated EDE for a given process. Modifications to the Pro MoS package
were made to utilize secondary dose information to use dose modeling to enhance the
process modeling efforts.

16. Handling Emergency Management in [an] Object Oriented Modeling Environment

Science.gov (United States)

Tokgoz, Berna Eren; Cakir, Volkan; Gheorghe, Adrian V.

2010-01-01
 It has been understood that protection of a nation from extreme disasters is a challenging task.
Impacts of extreme disasters on a nation's critical infrastructures, economy and society could be
devastating. A protection plan itself would not be sufficient when a disaster strikes. Hence, there is
a need for a holistic approach to establish more resilient infrastructures to withstand extreme
disasters. A resilient infrastructure can be defined as a system or facility that is able to withstand
damage, but if affected, can be readily and cost-effectively restored. The key issue to establish
resilient infrastructures is to incorporate existing protection plans with comprehensive
preparedness actions to respond, recover and restore as quickly as possible, and to minimize
extreme disaster impacts. Although national organizations will respond to a disaster, extreme
disasters need to be handled mostly by local emergency management departments. Since
emergency management departments have to deal with complex systems, they have to have a
manageable plan and efficient organizational structures to coordinate all these systems. A strong
organizational structure is the key in responding fast before and during disasters, and recovering
quickly after disasters. In this study, the entire emergency management is viewed as an enterprise
and modelled through enterprise management approach. Managing an enterprise or a large
complex system is a very challenging task. It is critical for an enterprise to respond to challenges in
a timely manner with quick decision making. This study addresses the problem of handling
emergency management at regional level in an object oriented modelling environment developed
by use of TopEase software. Emergency Operation Plan of the City of Hampton, Virginia, has been
incorporated into TopEase for analysis. The methodology used in this study has been supported by
a case study on critical infrastructure resiliency in Hampton Roads.

17. Object-oriented classification of drumlins from digital elevation models

Science.gov (United States)

Saha, Kakoli

Drumlins are common elements of glaciated landscapes which are easily identified by their distinct
morphometric characteristics including shape, length/width ratio, elongation ratio, and uniform
direction. To date, most researchers have mapped drumlins by tracing contours on maps, or
through on-screen digitization directly on top of hill shaded digital elevation models (DEMs). This
paper seeks to utilize the unique morphometric characteristics of drumlins and investigates
automated extraction of the landforms as objects from DEMs by Definiens Developer software
(V.7), using the 30 m United States Geological Survey National Elevation Dataset DEM as input. The
Chautauqua drumlin field in Pennsylvania and upstate New York, USA was chosen as a study area.
As the study area is huge (approximately covers 2500 sq.km. of area), small test areas were
selected for initial testing of the method. Individual polygons representing the drumlins were
extracted from the elevation data set by automated recognition, using Definiteness' Multi
resolution Segmentation tool, followed by rule-based classification. Subsequently parameters such
as length, width and length-width ratio, perimeter and area were measured automatically. To test
the accuracy of the method, a second base map was produced by manual on-screen digitization of
drumlins from topographic maps and the same morphometric parameters were extracted from the
mapped landforms using Definiteness Developer. Statistical comparison showed a high agreement
 between the two methods confirming that object-oriented classification for extraction of drumlins
can be used for mapping these landforms. The proposed method represents an attempt to solve
the problem by providing a generalized rule-set for mass extraction of drumlins. To check that the
automated extraction process was next applied to a larger area. Results showed that the proposed
method is as successful for the bigger area as it was for the smaller test areas.

18. Principles of object-oriented modeling and simulation with Modelica 2.1

CERN Document Server

Fritzson, Peter

2004-01-01

A timely introduction to the latest modeling and simulation techniques. Object-

oriented modeling is a fast-growing area of modeling and simulation that provides a structured,
computer-supported way of doing mathematical and equation-based modeling. Modelica is today's
most promising modeling language in that it effectively unifies and generalizes previous object-
oriented modeling languages and provides a sound basis for the basic concepts. Principles
of Object-Oriented Modeling and Simulation with Modelica 2.1 introduces the latest methods
of object-oriented component-based system modeling and

19. Business Process Modeling Notation - An Overview

Directory of Open Access Journals (Sweden)

Alexandra FortiÅŸ

2006-01-01

Full Text Available BPMN represents an industrial standard created to offer a common and user
friendly notation to all the participants to a business process. The present paper aims to briefly
present the main features of this notation as well as an interpretation of some of the main patterns
characterizing a business process modeled by the working fluxes.

20. A method of formal requirements analysis for NPP I and C systems based on object-
oriented visual modeling with SCR

International Nuclear Information System (INIS)

Koo, S. R.; Seong, P. H.

1999-01-01
In this work, a formal requirements analysis method for Nuclear Power Plant (NPP) I and C systems
is suggested. This method uses Unified Modeling Language (UML) for modeling systems visually
and Software Cost Reduction (SCR) formalism for checking the system models. Since object-
oriented method can analyze a document by the objects in a real system, UML models that
use object-oriented method are useful for understanding problems and communicating with
everyone involved in the project. In order to analyze the requirement more formally, SCR
tabular notations is converted from UML models. To help flow-through from UML models to SCR
specifications, additional syntactic extensions for UML notation and a converting procedure are
defined. The combined method has been applied to Dynamic Safety System (DSS). From this
application, three kinds of errors were detected in the existing DSS requirements

Question NO 4:
Select a software system as specified by your instructor and draw the
following UML diagram (Teachers please assign separate system to
each student)

1) Use case Diagram

A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
different use cases and will often be accompanied by other types of diagrams as well. The use
cases are represented by either circles or ellipses.

Here are some questions that have been asked frequently in the UML world are: What is a
use case diagram? Why Use case diagram? or simply, Why use cases?. Some people don't
know what use case is, while the rest under-estimated the usefulness of use cases in
developing a good software product. Is use case diagram underrated? I hope you will find
the answer when finished reading this article.
2) Composite Diagram
Composite structure diagram in the Unified Modeling Language (UML) is a type of static
structure diagram that shows the internal structure of a class and the collaborations that this
structure makes possible.

This diagram can include internal parts, ports through which the parts interact with each other
or through which instances of the class interact with the parts and with the outside world, and
connectors between parts or ports. A composite structure is a set of interconnected elements
that collaborate at runtime to achieve some purpose. Each element has some defined role in
the collaboration.

Composite Structure Diagram is one of the new artifacts added to UML 2.0. A composite
structure diagram is a UML structural diagram that contains classes, interfaces, packages, and
their relationships, and that provides a logical view of all, or part of a software system. It shows
the internal structure (including parts and connectors) of a structured classifier or
collaboration.
A composite structure diagram performs a similar role to a class diagram, but allows you to go
into further detail in describing the internal structure of multiple classes and showing the
interactions between them. You can graphically represent inner classes and parts and show
associations both between and within classes.

3) Activity Diagram
We use Activity Diagrams to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows visually using an activity diagram. An
activity diagram focuses on condition of flow and the sequence in which it happens. We
describe or depict what causes a particular event using an activity diagram.
UML models basically three types of diagrams, namely, structure diagrams, interaction
diagrams, and behavior diagrams. An activity diagram is a behavioral diagram i.e. it depicts
the behavior of a system.
An activity diagram is very similar to a flowchart. So let us understand if an activity diagrams
or a flowcharts are any different:

Activity diagram is another important behavioral diagram in UML diagram to describe

dynamic aspects of the system. Activity diagram is essentially an advanced version of flow
chart that modeling the flow from one activity to another activity.

4) Entity Relationship Diagram

Entity Relationship Diagram:

An entity relationship diagram (ERD) shows the relationships of entity sets stored in a database. An
entity in this context is an object, a component of data. An entity set is a collection of similar
entities. These entities can have attributes that define its properties. By defining the entities, their
attributes, and showing the relationships between them, an ER diagram illustrates the logical
structure of databases. ER diagrams are used to sketch out the design of a database.
Question NO 5:
(a) What is association? Differentiate between 1-way and 2-way
association with example for each.
Association:

An association defines a relationship between two entity objects based on common attributes.
The relationship can be one-to-one or one-to-many; you can use two one-to-many associations
to implement a many-to-many relationship. The association allows entity objects to access the
data of other entity objects through a persistent reference.

Associations act independently from referential integrity constraints

Although the same type of relationship can also exist at the table level through a foreign-key
relationship or object REF, an entity object only needs an association to access the data of
another entity object. You can create associations regardless of whether the database has
the corresponding referential integrity constraints.

1-way and 2-way

One-Way

A one-way ANOVA is a type of statistical test that compares the variance in the group means
within a sample whilst considering only one independent variable or factor. It is a hypothesis-
based test, meaning that it aims to evaluate multiple mutually exclusive theories about our
data. Before we can generate a hypothesis, we need to have a question about our data that we
want an answer to. For example, adventurous researchers studying a population of walruses
might ask “Do our walruses weigh more in early or late mating season?” Here, the
independent variable or factor (the two terms mean the same thing) is “month of mating
season”. In an ANOVA, our independent variables are organized in categorical groups. For
example, if the researchers looked at walrus weight in December, January, February and
March, there would be four months analyzed, and therefore four groups to the analysis.
A one-way ANOVA compares three or more than three categorical groups to establish
whether there is a difference between them. Within each group there should be three or
more observations (here, this means walruses), and the means of the samples are compare.
Two-Way

A two-way ANOVA is, like a one-way ANOVA, a hypothesis-based test. However, in the two-way
ANOVA each sample is defined in two ways, and resultantly put into two categorical groups.
Thinking again of our walruses, researchers might use a two-way ANOVA if their question is:
“Are walruses heavier in early or late mating season and does that depend on the gender of the
walrus?” In this example, both “month in mating season” and “gender of walrus” are factors –
meaning in total, there are two factors. Once again, each factor’s number of groups must be
considered – for “gender” there will only two groups “male” and “female”.
The two-way ANOVA therefore examines the effect of two factors (month and gender) on a
dependent variable – in this case weight, and also examines whether the two factors affect
each other to influence the continuous variable.
(b) Draw a dynamic model for course registration in learning
Management System based distance learning course.

*****************************************