Oose
Oose
UNIT
Object Oriented Concepts,
1 Modeling and UML
Success Publication
Introduction
In addition, number of functions is written to accomplish these tasks. The primary focus is
on functions. The major motivating factor in the invention of object-oriented approach is to
remove some of the flaws encountered in the procedural approach.
OOP treats data as a critical element in the program development and does not allow it to
flow freely around the system.
It ties data more closely to the functions that operate on it, and protects it from accidental
modification from outside functions. OOP allows decomposition of a problem into a
number of entities called objects and then builds data and functions around these objects.
1.1. Object-Oriented Concepts
Modularit Informati
follows:
y on-Hiding
1.1. Object-Oriented Concepts
Interface
Basi Data
c Abstraction
Con
Message cept Encapsulati
Passing
s on
Methods Inheritance
Polymorphi
sm
1.1. Object-Oriented Concepts
Accelerate
Change Car Access Allowed
Brake
Other Object
Brand: Aston
Speed: 65 mph
Gear: 4th
Color: Silver
Access Denied
1.1. Object-Oriented Concepts
Focus on
Class Data Follows
Bottom Up
Libraries Approach
Class
Generic
Definition
Classes s
Polymo Objec
rphism ts
Inheritanc
e and Class
Abstra
Hierarchy
Encaps ction
ulation
1.1. Object-Oriented Concepts
3) Class Definitions:
Basic building blocks OOP and a single entity, which has data and operations on data
together.
4) Objects:
The instances of a class which are used in real functionality its variables and operations.
5) Abstraction:
Specifying what to do but not how to do, flexible features for having overall view of an
object’s functionality
1.1. Object-Oriented Concepts
8) Polymorphism:
Multiple definitions for a single name - functions with same name with different
functionality; saves time in investing many function names Operator and Function
overloading.
9) Generic Classes:
Generic Classes contains definitions for unspecified data. They are known as container
classes. They are flexible and reusable.
10)Class Libraries:
Class libraries contains built-in classes i.e. class which is already implemented and stored
somewhere. It is just use by different users.
1.2. Model
We use models when we think about problems and when we talk to each other, and when we
construct mechanisms and when we try to understand phenomena and when we teach. In
short, we use models all the time. That means: models have never been invented, they have
been around (at least) since humans started to exist.
A) Introduction to Modeling:
a) Concept of Model:
The term “model" is derived from the Latin word modulus, which means measure, rule,
pattern, example to be followed. Obvious examples are toy railways and dolls, maps,
architectural models of buildings. In software engineering, we have process models,
design patterns, class diagrams. Other models are less obvious, like project plans,
specifications and designs, metrics, and minutes of project meetings.
A) Introduction to Modeling:
c) The Model Criteria:
In order to distinguish models from other artefacts, we need criteria. Re
M
Pr According to
du
ap
ag
Stachowiak, any candidate must meet three criteria, or otherwise it is not
ctia model:
pin
ma
1) Mapping Criterion: on
tic
g
There is an original object or phenomenon that is mapped to the Cri
model. In the sequel, this original object or phenomenon is ter
ion
referred to as "the original".
2) Reduction Criterion:
Not all the properties of the original are mapped on to the
model, but the model is somehow reduced. On the other hand,
the model must mirror at least some properties of the original.
3) Pragmatic Criterion:
The model can replace the original for some purpose, i.e. the
model is useful.
1.2. Model
A) Introduction to Modeling:
d) Principles of Modeling:
The use of modeling has a rich history in all the engineering disciplines. That experience
suggests four basic principles of modeling.
1.2. Model
A) Introduction to Modeling:
d) Principles of Modeling:
1) ‘The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped’:
In other words, choose your models well. The right models will brilliantly illuminate the
most wicked development problems, offering insight that you simply could not gain
otherwise; the wrong models will mislead you, causing you to focus on irrelevant
issues. Setting aside software for a moment, suppose you are trying to tackle a
problem in quantum physics. Certain problems, such as the interaction of photons in
space-time, are full of wonderfully hairy mathematics.
2) ‘Every model may be expressed at different levels of precision’:
If you are building a high rise, sometimes you need a 30,000-foot view for instance, to
help your investors visualize its look and feel. Other times, you need to get down to
the level of the studsfor instance, when there's a tricky pipe run or an unusual
structural element. The same is true with software models. Sometimes a quick and
simple executable model of the user interface is exactly what you need; at other
times you have to get down and dirty with the bits, such as when you are specifying
cross-system interfaces or wrestling with networking bottlenecks.
1.2. Model
A) Introduction to Modeling:
d) Principles of Modeling:
3) ‘The best models are connected to reality’:
A physical model of a building that doesn't respond in the same way as do real
materials has only limited value; a mathematical model of an aircraft that assumes
only ideal conditions and perfect manufacturing can mask some potentially fatal
characteristics of the real aircraft.
4) ‘No single model or view is sufficient. Every nontrivial system is best approached
through a small set of nearly independent models with multiple viewpoints’:
If you are constructing a building, there is no single set of blueprints that reveal all its
details. At the very least, you'll need floor plans, elevations, electrical plans, heating
plans, and plumbing plans. And within any kind of model, you need multiple views to
capture the breadth of the system, such as blueprints of different floors.
1.2. Model
The definition of a good system varies in certain respects between different applications. In
some, it is performance that is important and in others perhaps user-friendliness. It can, in
fact, depend on the structure of the system, for instance, whether it is distributed or
centralized. What is common to all (larger) systems is that they will need to be modified.
B) Object-Oriented Analysis:
The purpose of object-oriented analysis, as with all other analysis, is to obtain an
understanding of the application: an understanding depending only on the system’s
functional requirements.
a) Difference Between Object-Oriented Analysis and Function/Data Analysis:
The difference between object-oriented analysis and function/data analysis is the means
of expression. While function/data analysis methods commence by considering the
system’s behavior and/or data separately, object-oriented analysis combines them and
regards them as integrated objects.
Finding the
Objects
1.3. Object Oriented System Development
B) Object-Oriented Analysis:
b) Activities of Object Oriented Analysis:
1) Finding the Objects:
The objects can be found as naturally occurring entities in the application domain. An
object becomes typically a noun which exists in the domain and, because of this, it is
often a good start to learn the terminology for the problem domain.
2) Organizing the Objects:
There are a number of criteria to use for the classification and organization of objects
and classes of objects. One classification starts by considering how similar classes of
objects are to each other.
3) Object Interaction:
In order to obtain a picture of how the object fits into the system, we can describe
different scenarios or use cases in which the object takes part and communicates
with other objects.
4) Operations of the Objects:
The object’s operations come naturally when we consider an object’s interface. The
operations can also be identified directly from the application, when we consider
what can be done with the items we model.
5) Object Implementation:
Finally, the object should be defined internally, which includes defining the
information that each object must hold.
1.3. Object Oriented System Development
The elements of an object model-classes and objects, attributes, operations, and messages-
were each defined and discussed in the preceding section. But how do we identifying these
elements for an actual problem? The sections given below present a series of informal
guidelines that will assist in the identification of the elements of the object model.
….Identifying Classes and Objects….
If we look around a room, there is a set of physical objects that can be easily identified,
classified, and defined (in terms of attributes and operations). But when we "look around" the
problem space of a software application, the objects may be more difficult to comprehend.
A) Categorization of Object:
External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.
Things (e.g., reports, displays, letters, signals) that are part of the information domain for
the problem.
Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
Roles (e.g., manager, engineer, salesperson) played by people who interact with the
system.
Organizational units (e.g., division, group, team) that is relevant to an application.
Places (e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function of the system.
1.4. Identifying the Elements of an Object Model
Retained
Information
Essential Needed
Requireme
nts Services
Common Multiple
Operations Attributes
Common
Attributes
1.4. Identifying the Elements of an Object Model
…. Specifying Attributes ….
Attributes describe an object that has been selected for inclusion in the analysis model. In
essence, it is the attributes that define the object-that clarify what is meant by the object in
the context of the problem space.
To illustrate, we consider (above example) the system object defined for XYZ. Homeowner can
configure the security system to reflect sensor information, alarm response information,
activation/deactivation information, identification information, and so forth.
Using the content description notation defined for the data dictionary, we can represent these
composite data items in the following manner:
sensor information = sensor type + sensor number + alarm threshold
alarm response information = delay time + telephone number + alarm type
activation/deactivation information = master password + number of allowable tries +
temporary password
identification information = system ID + verification phone number + system status
Each of the data items to the right of the equal sign could be further defined to an elementary
level, but for our purposes, they constitute a reasonable list of attributes for the system object.
1.4. Identifying the Elements of an Object Model
…. Defining Operations ….
Operations define the behavior of an object and change the object’s attributes in some way.
More specifically, an operation changes one or more attribute values that are contained within
the object. Therefore, an operation must have "knowledge" of the nature of the objects
attributes and must be implemented in a manner that enables it to manipulate the data
structures that have been derived from the attributes.
For example:
From the XYZ processing narrative, we see that "sensor
is assigned a number and type" or that "a master
password is programmed for arming and disarming the
system." These two phrases indicate a number of
things:
That can assign operation is relevant for the sensor
object.
That a program operation will be applied to the
system object.
That arm and disarm are operations that apply to
system (also that system status may ultimately be
defined (using data dictionary notation) as
1.4. Identifying the Elements of an Object Model
UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems. UML was created by Object Management Group and UML 1.0
specification draft was proposed to the OMG in January 1997.
….Overview of UML….
UML stands for Unified Modeling Language.
UML is different from the other common programming languages like C++, Java, COBOL etc.
UML is a pictorial language used to make software blue prints.
So UML can be described as a general purpose visual modeling language to visualize, specify,
construct and document software system. Although UML is generally used to model software
systems but it is not limited within this boundary. It is also used to model non software
systems as well like process flow in a manufacturing unit etc.
A) Goals of UML:
A picture is worth a thousand words, this absolutely fits while discussing about UML. Object
oriented concepts were introduced much earlier than UML. So at that time there were no
standard methodologies to organize and consolidate the object oriented development. At
that point of time UML came into picture.
There are a number of goals for developing UML but the most important is to define
some general purpose modeling language which all modelers can use and also it needs to
be made simple to understand and use.
1.5. Introduction to Unified Modeling Language (UML)
….Overview of UML….
B) Advantages of UML:
UML, the unified modeling language, is a standard used to visually describe a program,
specifically an object-oriented program.
1) Visual Representation:
A UML diagram is a visual representation of the relationships between classes and
entities in a computer program. A class is an object in programming that organizes
similar variables and functions in one location. To understand a program, it is essential to
understand what each class object does, the information it stores and how it relates to
other classes in the program.
1.5. Introduction to Unified Modeling Language (UML)
….Overview of UML….
B) Advantages of UML:
2) Readability and Re-usability:
A UML diagram is beneficial in that it is very readable. The diagram is meant to be
understood by any type of programmer and helps to explain relationships in a program
in a straightforward manner. Traditionally, to understand a program, a programmer
would read the code directly.
3) Standard:
UML is the current standard for programming in object-oriented programming
languages. When creating classes and other objects with relationships between each
other, UML is what is used to visually describe these relationships. Because it is used as a
standard, it is widely understood and well known.
4) Planning Tool:
UML helps to plan a program before the programming takes place. In some tools used to
model UML, the tool will generate code based on the classes set up in the model. This
can help reduce overhead during the implementation stage of any program.
1.5. Introduction to Unified Modeling Language (UML)
….Overview of UML….
C) Applications of UML:
The UML is intended primarily for software-intensive systems. It has been used effectively
for such domains as
Enterprise information systems
Banking and financial services
Telecommunications
Transportation
Defense/aerospace
Retail
Medical electronics
Scientific
Distributed Web-based services
The UML is not limited to modeling software. In fact, it is expressive enough to model non
software systems, such as workflow in the legal system, the structure and behavior of a
patient healthcare system, software engineering in aircraft combat systems, and the design
of hardware.
1.5. Introduction to Unified Modeling Language (UML)
Things Relationship
1.5. Introduction to Unified Modeling Language (UML)
a) Structural Things:
The Structural things define the static part of the model. They represent physical and
conceptual elements. Following are the brief descriptions of the structural things.
1) Class:
Class represents set of objects having similar responsibilities.
Class
Attributes
Operations
1.5. Introduction to Unified Modeling Language (UML)
3) Collaboration:
Collaboration defines interaction between elements.
4) Use Case:
Use case represents a set of actions performed by a system for a specific goal.
Use case
1.5. Introduction to Unified Modeling Language (UML)
Component
6) Node:
A node can be defined as a physical element that exists at run time.
Node
1.5. Introduction to Unified Modeling Language (UML)
Message
2) State Machine:
State machine is useful when the state of an object in its life cycle is important. It
defines the sequence of states an object goes through in response to events.
Events are external factors responsible for state change.
State
1.5. Introduction to Unified Modeling Language (UML)
Package
d) Annotational Things:
Annotational things can be defined as a mechanism to capture remarks, descriptions,
and comments of UML model elements. Note is the only one Annotational thing
available.
1) Note:
note
1.5. Introduction to Unified Modeling Language (UML)
b) Association:
Association is basically a set of links that connects elements of an UML model. It also
describes how many objects are taking part in that relationship.
1.5. Introduction to Unified Modeling Language (UML)
d) Realization:
Realization can be defined as a relationship in which two elements are connected.
One element describes some responsibility which is not implemented and the other
one implements them. This relationship exists in case of interfaces.
1.5. Introduction to Unified Modeling Language (UML)
Specifications Adornments
1) Specifications:
The UML is more than just a graphical language. Rather, behind every part of its
graphical notation there is a specification that provides a textual statement of the syntax
and semantics of that building block. For example, behind a class icon is a specification
that provides the full set of attributes, operations (including their full signatures), and
behaviors that the class embodies; visually, that class icon might only show a small part
of this specification.
Common Divisions Extensibility Mechanisms
1.5. Introduction to Unified Modeling Language (UML)
Every element in the UML's notation starts with a basic symbol, to which can be added a
variety of adornments specific to that symbol.
1.5. Introduction to Unified Modeling Language (UML)
In this figure, there is one class, named Customer, together with three objects: Jan
(which is marked explicitly as being a Customer object), :Customer (an anonymous
Customer object), and Elyse (which in its specification is marked as being a kind of
Customer object, although it's not shown explicitly here).
1.5. Introduction to Unified Modeling Language (UML)
Collectively, these three extensibility mechanisms allow you to shape and grow the
UML to your project's needs. These mechanisms also let the UML adapt to new
software technology, such as the likely emergence of more powerful distributed
programming languages.
1.5. Introduction to Unified Modeling Language (UML)
…. Architecture….
Visualizing, specifying, constructing, and documenting a software-intensive system demands
that the system be viewed from a number of perspectives. Different stakeholders end users,
analysts, developers, system integrators, testers, technical writers, and project managers each
bring different agendas to a project, and each looks at that system in different ways at different
times over the project's life.
…. Architecture….
As Figure below illustrates, the architecture of a software-intensive system can best be
described by five interlocking views. Each view is a projection into the organization and
structure of the system, focused on a particular aspect of that system.
1.5. Introduction to Unified Modeling Language (UML)
…. Architecture….
1) Use Case View:
The use case view of a system encompasses the use cases that describe the behavior of the
system as seen by its end users, analysts, and testers. This view doesn't really specify the
organization of a software system.
2) Design View:
The design view of a system encompasses the classes, interfaces, and collaborations that
form the vocabulary of the problem and its solution. This view primarily supports the
functional requirements of the system, meaning the services that the system should
provide to its end users.
3) Interaction View:
The interaction view of a system shows the flow of control among its various parts,
including possible concurrency and synchronization mechanisms. This view primarily
addresses the performance, scalability, and throughput of the system.
4) Implementation View:
The implementation view of a system encompasses the artifacts that are used to assemble
and release the physical system. This view primarily addresses the configuration
management of the system's releases, made up of somewhat independent files that can be
assembled in various ways to produce a running system.
1.5. Introduction to Unified Modeling Language (UML)
…. Architecture….
5) Deployment View:
The deployment view of a system encompasses the nodes that form the system's hardware
topology on which the system executes. This view primarily addresses the distribution,
delivery, and installation of the parts that make up the physical system.