Unit IObject Modeling:

oatmealbrothersSoftware and s/w Development

Nov 18, 2013 (3 years and 6 months ago)

59 views

Unit


I

Object Modeling:
Objects and classes, links and association, generalization and inheritance, aggregation,
abstract class, multiple inheritance, meta data, candidate keys, constraints.


History of Computing

Computing is a constantly changing our world and our environment. In the 1960s large machines called
mainframes were created to manage large volumes of data (numbers) efficiently. Bank account and
payroll programs changed the way organizations worked and m
ade parts of these organizations much
more efficient. In the 1980s personal computers became common and changed the way many
individuals
worked. People started to own their own computers and many used word processors and spreadsheets
applications. In the 1
990s email became common and the world wide web was born. These technologies
revolutionized communications allowing individuals to publish information that could easily be accessed
on a global scale. The ramifications of these new technologies are still no
t fully understood as society is
adapting to opportunities of internet commerce, new social networking technologies (twitter, facebook,,
myspace, online games etc) and the challenges of internet related crime.

Just as new computing technologies are changi
ng our world so to are new techniques and ideas changing
the way we develop computer systems. In the 1950s the use machine code (unsophisticated, complex and
machine specific) languages were common.

In the 1960s high level languages, which made programming

simpler, became common. However these
led to the development of large complex programs that were difficult to manage and maintain.

In the 1970s the structured programming paradigm became the accepted standard for large complex
computer programs. The struc
tured programming paradigm proposed methods to logically structure the
programs developed into separate smaller, more manageable components. Furthermore methods for
analyzing data were proposed that allowed large databases to be created that were efficient
, preventing
needless duplication of data and protected us against the risks associated with data becoming out of sync.
However significant problems still persisted in a) understanding the systems we need to create and b)
changing existing software as user
s requirements changed.

In the 1980s ‘modular’ languages, such as Modula
-
2 and ADA were developed that became the precursor
to modern Object Oriented languages.

In the 1990s the Object Oriented paradigm and component
-
based software development ideas were
d
eveloped and Object Oriented languages became the norm from 2000 onwards.

The object oriented paradigm is based on many of the ideas developed over the previous 30 years of
abstraction, encapsulation and polymorphism and led to the development of software
components where
the operation of the software and the data it operates on are modeled together. Proponents

of the Object
Oriented software development paradigm argue that this leads to the development of software components
that can be re
-
used in differen
t applications thus saving significant development time and cost savings but
more importantly allow better software models to be produced that make systems more maintainable and
easier to understand.


Different Programming Paradigms

The structured programm
ing paradigm proposed that programs could be developed in sensible blocks that
make the program more understandable and easier to maintain.






















The Object Oriented paradigms
suggest we should model instructions in a computer program with the data
they manipulate and store these as components together. One advantage of doing this is we get reusable
components.



Activity 1

Assume you undertake the following activities on a daily basis. Arrange this list into a
sensible
order then split this list into three blocks of related activities and give each block
a heading to summarize the activities carried out in that block.

Get out of bed

Eat breakfast

Park the car

Get dressed

Get the car out of the garage

Drive to work

Find
out what your boss wants you to do today

Feedback to the boss on today’s results.

Do what the boss wants you to do



Feedback 1

You should have been able to organize these into groups of related activities and give each group
a title that summari
zes those activities.

Get up :
-


Get out of bed


Get dressed


Eat breakfast

Go to work :
-


Get the car out of the garage


Drive to work


Park the car

Do your job :
-


Find out what your boss wants you to do today


Do what the boss wants you to do


Feedback
to the boss on today’s results.


By structuring our list of instructions and considering the overall structure of the day (Get up, go
to work, do your job) we can change and improve one section of the instructions without
changing the other parts. For exam
ple we could improve the instructions for going to work….


Listen to the local traffic and weather report

Decide whether to go by bus or by car

If doing by car, get the car and drive to work.

Else walk to the bus station and catch the bus.


Without worryin
g about any potential impact this may have on ‘getting up’ or ‘doing your job’. In
the same way structuring computer programs can make each part more understandable and make
large programs easier to maintain.



















The Object

Oriented paradigm builds upon and extends the ideas behind the structured programming
paradign of 1970s.

Structured Programming Approach

Basically Structure programming f
ocuses on functions. In this, Most of the programs have to fixed well
-
defined structure and format. It is only known as “Procedure oriented programming”.

Disadvantages :

1.

It will produce confusion, what data are used by which function and which are global
data and
which are local data.

2.

If any software or system, which is developed, using structured programming, is very difficult
for maintenance, upgrading and modifications
.

3.

It is also difficult to understand the designing of the structure of any program.

4.

We

cannot simulate the problem with the real world problem using structure programming.




Imagine and a personal address book with some data stored abou
t your
friends .

Name,

Address,

Telephone Number.


List three things that you may do to this address book.


Next identify someone else who may use an identical address book for some
purpose other than storing a list of friends.




Feedback 2

With an address book we would want to be able to perform the following
actions :
-

find our details of a friend i.e. their telephone number, add an
address book and, of course, delete an address.

We can create a simple software component to store the data i
n the address
book (i.e. list of names etc) and the operations we can perform (i.e. add
address, find telephone number etc)

By creating a simple software component to store and manage addresses of
friends we can reuse this in another software system i.e. i
t could be used by
a business manager to store and find details of customers. It could also
become part of a library system to be used by a librarian to store and
retrieve details of the users of the library.

Thus in object oriented programming we can crea
te re
-
usable software
components (in this case an address book)

Object Oriented Approach

Object Oriented Approach is developed by using Real
-
world
-
Concepts. The base of this approach

is
Object which combines data structure and

behavior in a single entity.


Advantages :

1.

Each entity can be easily modify, easily reuse and easily upgrade.

2.

We can extend any entity (or department) according to our requirement.

3.

It also has scope for future enhancement.

4.

We can easily relate one entity
with another.

5.

We can add new function or behavior easily in any of the entity.

6.

We can add new entity also as a extension of class.


The Object Oriented (OO) concept is a development strategy based on the concept that systems should be
built from a collecti
on of reusable components called objects.
Instead of separating data and functionality
as is done in structured programming, objects encompass both.

Definition
:

Object

Oriented programming (OOP) is a programming language model organized around
“objects” rather than “actions” and data rather than logic. Historically, a program has been viewed as a
logical procedure that takes input data, processes it and produces

output data.


Object Oriented Approach includes Attributes, Functions, Objects and Classes.


Attributes :

Attributes are used to describe the characterstics of an object (entity). The attributes are called Data
members because they hold information of an
entity or object.


Functions :

The functions describes the behavior
of object. The function is a way to access the attributes. The
functions that operate on the member data are sometimes called methods or member functions of class.


Objects :

An object is
a real or abstract item that contains information and methods that allow it to be manipulated.
It is an real world entity.


Class :

A class

is a group of objects with the same data structures (attributes) and behavior (functions or
methods). A class is an abstraction that describes properties important to an application and ignores the
rest. Any choice of class is arbitrary and depend on the
applications. Each objects is said to an instance of
class. Class refer to a group of similar objects.


Features of Object Oriented Approach

Data Abstraction :
-

(Concept of Data Hiding)

Abstraction consists of focusing on the essential, inherent aspects of an entity and ignoring its accidental
properties. It is a feature to provide the access data of member data, without showing the detail of the
hidden data. Data Abstraction refers to pr
ovide essential features without including background details.
Use of abstraction during analysis means dealing only with application domain concepts, not making
design and implementation decisions before the problem is understood.

Since the classes use th
e concept of data abstraction, they are known as Abstract Data Type (ADT).

Two popular abstractions : Procedure abstraction and Data abstraction

Procedure abstraction is to divide a single problem to many simple sub
-
works. Data abstraction is to
collect es
sential elements composing to a compound data. These two abstractions have the same objective
: reusable and replaceable.

Data Abstraction is the process of distilling data down to its essentials.








Encapsulation

:
-

(Concept of Data binding)

When we bind data structure and the behavior in a single unit is called class. The property of binding
member dat and member functions in a single unit is called Encapsulation.

Encapsulation consists of
separating external aspects of an object, which are accessible to other objects,
fr
om the internal implementation
details of the object, which are hidden from the other objects. The
implementation of an object can be changed without affecting the applic
ati
on that use it.


Inheritance :
-

Inheritance is the process by which objects of one class acquire the properties of objects of another class.
It supports the concept of hierarchical classification.

Inheritance is a mechanism of sharing attributes and
operations among classes.







Phone

Properties :

Opening mechanism

Manufacturer

Type

Person

Employee

Student

Manager

Secretary

Art Student

Science Student


Common attribute of class Person : name, address, age

Common methods of class Person : get_name(), put_name()
, change_address
(), get_address(),
put_address(), get_age(), put_age()

Each Derived classes shares common properties with the class which it is derived.

So, the creating new class from the old one is called Inheritance (Derivation). The old class refer as Base
class, Pare
nt class, or Super class. And the new class is called Derived class, Sub class, or Child class.

E
ach subclass inherits all properties of its super class and adds its own unique properties. The inheritance
provides idea of Reusability.

Polymo
rphism
:
-

Polymo
rphism means that the same operation name may be have differently on different classes. It means
“One name, multiple forms”.

Using

a single function name to perform different types of tasks is known as Function Overloadin
g. The
different functions having same name can be differentiated in terms of their type of parameter or no. of
parameters / arguments.











The
process of
making an operator to exhibit different behaviors in different instances is known

as
Operator Overloading. Polymo
rphism also supports Data binding.

Some of Object Oriented Programming Languages are C++, Java, Simula, Small talk, ADA, Eiffel.

Object Oriente
d Development

Development refers to the front portion of the software life cycle : analysis, design and implementation.
The essence of object oriented development is the identification

and organization of application
-
domain
concepts, rather than their final representation in a programming language, object
-
oriented or not.

Shape

Height

Width

Area()

Rectangle

Height

Width

Area (height, width)

Square

Height

Area (double height)

Definition :

Object
-
oriented systems development is an extension of structured programming. Object
-
oriented developm
ent emphasizes the benefits of modular and reusable computer code and Modeling real
-
world objects, just as structured programming emphasizes the benefits of properly nested structures.

Expected Benefits of Object

Oriented Development

1.

Faster
Development:

OOD has long been touted as leading to faster development. Many of the
claims of potentially reduced development time are correct in principle, if a bit overstated.

2.

Reuse of Pr
e
vious
Work:

This is the benefit cited most commonly in literature, particularly in
business periodicals. OOD produces software modules that can be plugged into one another, which allows
creation of new programs. However, such reuse does not come easily. It takes plan
ning and investment.

3.

Increased
Quality:

Increases in quality are largely
a by
-
product of this program reuse. If 90% of new
application consists of proven, existing components, then only the remaining 10% of the code has to be
tested from scratch. That obse
rvation implies an order of magnitude reduction in defects.

4.

Modular
Architecture:

Object
-
Oriented systems have a natural structure for modular design :
objects, subsystems, framework and so on. Thus, OOD systems are easier to modify. OOD systems

can be
alt
ered in fundamental ways without ever breaking up since changes are neatly encapsulated. However,
nothing in OOD guarantees or requires that the code produced will be modular. The same level of care in
design and implementation is required to produce a mod
ular structure in OOD, as it is for any form of
software development.

5.

Client / Server
applications:

By their very nature, client / server applications involve transmission of
messages back and forth over a network and the object
-
message paragigm

of OOD meshes well with the
physical and conceptual architecture of client/server applications.

6.

Better Mapping to the Problem
Domain:

This is a clear winner for OOD, particularly when the
project maps to the real world. Whether objects represent customers
, machinery
, banks, sensors or pieces
of paper, they can provide a clean, self
-
contained implication which fits naturally into human thought
processes.


Modeling Concept
s

Object oriented development is a co
nceptual process independent of a programming lang
uage until the
final stages. If we choose the language at the start then we restrict our application domain.


Object Oriented Methodology

Object Oriented Methodology (OOM) is a new system development approach encouraging and facilitating
re
-
use of software

components. With this methodology, a computer system can be developed on a
component basis which enables the effective re
-
use of existing components and facilities the sharing of its
components by other system. Through the adoption of OOM, higher producti
vity, lower maintenance cost
and better quality can be achieved.


Modeling

A model is an abstraction of something for the purpose of understanding it before building it.

The purposes of modeling according to Rumbaugh are


1.

testing

physical entities before building them (simulation),

2.

communication

with customers,

3.

visualization

(alternative presentation of information), and

4.

Reduction of
complexity
.

Abstraction

To implement real world entity into program, class uses the concept of

abstraction.

Some common definition :

1.

Abstraction is a process of mimicking behavior.

2.

Simplifying complex reality by Modeling classes appropriate to problem.

3.

Abstraction is a process that involves identifying the crucial behavior

of an object and eliminat
ing
irrelevant and tedious details.

The abstraction concept is usually used during analysis : deciding only with application domain concepts,
not making design and implementation decisions.

Kinds of Abstraction :

1.

Procedure Abstraction :

Procedure
Abstraction is to decompose problem to many simple sub
-
works. When using a certain
procedure, a programmer does not need to worry about all the details of how it performs its computations;
he or she only needs to know how to call it and what it computes.


Kinds of Procedure Abstraction :

Method :

A concrete implementation of an operation; a procedure in a class.


Operation :

The abstract notion of something that can be done by one or more classes.


Stub:

A piece of code that has the same interface (i.e. API
) as the lower level layers, but which does not
perform any real computations or manipulate any real data.


2.

Data Abstraction :

Data abstraction is to collect essential elements composing to a compound data. These two abstraction
have the same objective : r
eusable and replaceable.

The basic idea of data abstraction is to use compound data objects so that they operate on abstract data i.e.,
to use data in such a way, as to make no assumptions about the data that are not strictly necessary for
performing the t
ask at hand. At the same time, a concrete data representation is defined independent of the
programs that use the data.


Object Modeling Techniques (OMT)

Object Oriented Techniques allow user
to understand overall environment which they are attempting to
model. Identifying the components of the environment and detailing the relationship that exist between
them helps to achieve this aim.

Object Oriented

models are very useful for understanding problems, communicating with application
experts, modeling enterprises, preparing documentation and designing programs and databases.

OMT is a methodology that combines three views of modeling system
-

1.

Object Model

2.

Dynamic Model

3.

Functional Model

Object model


The object model represents the static and most stable phenomena in the modeled domain. Main concepts
are
classes

and
associations
, with
attributes
and
operations
.
Aggregation
and
generalization
(with
multiple i
nheritances) are predefined relationships.

Dynamic model


The dynamic model
emphasizes with changes to objects and their relationships over time. It is used to
represent the dynamic behavior of the system.It
represents a state/transition view on the model
. Main
concepts are
states
,
transitions
between states, and
events
to trigger transitions.
Actions
can be modeled as
occurring within states.
Generalization
and
aggregation
(concur
-
rency) are predefined relationships.

Functional model


The functional mode
l
describes those aspects of a system concerned with transformations of value
functions, mapping, constraints and functional dependence. It
handles the process perspective of the
model, corresponding roughly to data flow diagrams. Main concepts are
process
,
data store
,
data flow
,
and
actors
.

The entire OMT software development process has four phases: Analysis, system design, object design,
and implementation of the software. Most of the modeling is performed in the analysis phase. The
recommended method in
corporates the following activities:

1.

Develop a Problem Statement.

2.

Build an Object Model:

a)

Identify object classes.

b)

Develop a data dictionary for classes, attributes, and associations.

c)

Add associations between classes.

d)

Add attributes for objects and li
nks.

e)

Organize and simplify object classes using inheritance.

f)

Test access paths using scenarios and iterate the above steps as necessary.

g)

Group classes into modules, based on close coupling and related function.

3.

Build a Dynamic Model:

a)

Prepare scenarios of typical interaction sequences.

b)

Identify events between objects and prepare an event trace for each scenario.

c)

Prepare an event flow diagram for the system.

d)

Develop a state diagram for each class that has important dynamic behavior.

e)

Check for consistency and completeness of events shared among the state diagrams.

4.

Build a Functional Model:

a)

Identify input and output values.

b)

Use data flow diagrams as needed to show functional dependencies.

c)

Describe what each function does.

d)

Identify
constraints.

e)

Specify optimization criteria.

5.

Verify, iterate, and refine the three models:

a.

Add most important operations to the object model.

b.

Verify that classes, associations, attributes and operations are consistent and complete,
check with problem statement.

c.

Iterate steps to complete the analysis.

Object Model

To design a system, the object model provides the essential framework into which t
he dynamic and
functional model can be placed.

Main motto in constructing object model is to capture those concepts from the real world that are
important for implementation of system.

Comparisons of all the three models

:
-

Each model describes one aspect
of the system but contains references to the other models.

The object model describe data structure that the dynamic and functional model operate on. The
operations in the object model correspond to events in the dynamic model and functions in the function
al
model.
The dynamic model describes the control structure of objects. It shows decisions which depend on
object values and which cause actions that change object values and invoke functions. The functional
model describes functions invoked by operations
in the object model and actions in the dynamic model.
Functions operate on data values specified by the object model. The functional model also shows
constraints on object values.

The object model describe static structure i.e. static nature, Dynamic model

describe the control structure
i.e. temporal behavior and Functional model describe computational structure of the system i.e. data
values of an object changes.

OOP, OOD, OOA

Object Oriented Programming

Object
-
oriented programming

(
OOP
) is a
programming paradigm

using "
objects
"


data structures

consisting of
data fields

and
methods

together with their interactions


to design applications and
computer programs. Programming techniques may include features such as
data abstraction
,
encapsulation
,
messaging
,
modularity
,
polymorphism
, and
inheritance

Object
-
oriented programming has roots that can be traced to the 1960s. As hardware and software became
increasingly complex, manageability often became a concern. Researchers studied ways to maintain
software quality and developed

object
-
oriented programming in part to address common problems by
strongly emphasizing discrete, reusable units of programming logic. The technology focuses on data rather
than processes, with programs composed of self
-
sufficient modules ("classes"), each

instance of which
("objects") contains all the information needed to manipulate its own data structure ("members").

The Simula programming language was the first to introduce the concepts underlying Object
-
oriented
programming (objects, classes, subclasse
s, virtual methods, coroutines, garbage collection and discrete
event simulation) as a superset of Algol. Simula was used for physical modeling, such as models to study
and improve the movement of ships and their content through cargo ports. Samalltalk was

the first
programming language to be called object oriented programming language.

OOP may be seen as a collection of cooperating objects, as opposed to the more conventional model, in
which a program is seen as a list of tasks (subroutines) to perform. In

OOP, each object is capable of
receiving messages, processing data and sending messages to other objects.

Each object can be viewed as an independent machine with a distinct role or responsibility. The actions
(or operators) on the objects are closely ass
ociated with the object.

Object Oriented Analysis

Object
-
oriented analysis (OOA) looks at the
problem domain
, with the aim of producing a conceptual
model of the information t
hat exists in the area being analyzed. Analysis models do not consider any
implementation constraints that might exist, such as
concurrency
,

distribution
,
persistence
, or how the
system
is to be built. Implementation constraints are dealt during object
-
oriented design (OOD).
Analysis is done before the Design.

The sources for the analysis can be a written requirements statement, a formal vision document,
interviews with stakeholders or ot
her interested parties. A system may be divided into multiple domains,
representing different business, technological, or other areas of interest, each of which are analyzed
separately.

The result of object
-
oriented analysis is a description of
what

the sy
stem is functionally required to do,
in the form of a conceptual model. That will typically be presented as a set of
use cases
, one or more
UML

class diagrams
, and a number of
interaction diagrams
. It may also include some kind of
user
interface

mock
-
up. The purpose of object oriented analysis is to develop a model that describes
computer softwar
e as it works to satisfy a set of customer defined requirements.

Object Oriented Design

Object
-
oriented design

is the process of planning a system of interacting
objects

for the purpose of
solving a software problem

that was identified and documented during object oriented analysis
. It is one
approach to
software design
.

Input (sources) for object
-
oriented design

The input for object
-
oriented design is provided by the output of
object
-
oriented analysis
.

Realize that an
output artifact does not need to be completely developed to serve as input of object
-
oriented design;
analysis and design may occur in parallel, and in practice the results of one activity can feed the other in
a short feedback cycle throu
gh an iterative process. Both analysis and design can be performed
incrementally, and the artifacts can be continuously grown instead of completely developed in one shot.

Some typical input artifacts for object
-
oriented design are:



Conceptual model
: Conceptual model is the result of object
-
oriented analysis, it captures
concepts in the
problem domain
. The conceptual model is explicitly chosen to be independent of
implementation details, such as
concurrency

or data storage.



Use case
: Use case is a description of sequences of events that, taken together, lead to a system
doing something useful. Each use case provides one or more

scenarios

that convey how the
system should interact with the users called actors to achieve a specific business goal or function.
Use case actors may be end u
sers or other systems. In many circumstances use cases are further
elaborated into use case diagrams. Use case diagrams are used to identify the actor (users or
other systems) and the processes they perform.



System Sequence Diagram
: System Sequence diagram (SSD) is a picture that shows, for a
particular scenario of a use case, the events that external actors generate, their order, and possible
inter
-
system even
ts.



User interface

documentations (if applicable): Document that shows and describes the
look and
feel

of the end product's
user interface
. It is not mandatory to have this, but it helps to visualize
the end
-
product and therefore helps the designer.



Relational data model

(if applicable): A data model is an abstract model that describes how data
is represented and used. If an
object database

is not used, the relational data model should
usually be created before the design, since the strategy chosen for
object
-
relational mapping

is an
output of the OO design process. However, it is possible to develop the relational data model and
the object
-
oriented design artifacts in parallel, and the growth of an artifact can stimulate the
refinement of other artifact
s.

Output (deliverables) of object
-
oriented design



Sequence Diagrams
: Extend the
System Sequence Diagram

to add specific objects that handle
the system events.

A sequence diagram shows, as parallel vertical lines, different processes or obje
cts that live
simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in
which they occur.



Class diagram
: A class diagram is a type of static

structure
UML

diagram that describes the
structure of a system by showing the system's classes, their attributes, and the relationships
between the class
es. The messages and classes identified through the development of the
sequence diagrams can serve as input to the automatic generation of the global class diagram of
the system.what is it...

Some design principles and strategies



Dependency injection
: The basic idea is that if an object depends upon having an instance of
some other object then the needed object is "injected" into the dependent

object; for example,
being passed a database connection as an argument to the constructor instead of creating one
internally.



Acyclic dependencies principle
: The dependency graph of packages or components should have
no cycles. This is also referred to as having a
directed acyclic graph
.
[2]

For example, package C
depends on package B, which depends on package A. If package A also depended on package
C,
then you would have a cycle.



Composite reuse principle
: Favor polymorphic composition of objects over inheritance.

Object Modeling

Objec
t and classes a
re the basic concept used to bui
ld object model.
The object model captures the static
structure of a system by showing the objects in the system, relationships between the objects, and the
attributes and operations that characterize each class of objects.
The object model is the most important of
the three models.

Objects

The object refers to a conceptual object that represent an item in our program or system. Object represent
real world entity into a program.

For eg :

a person who is real world entity, we can make an object of it and then utilize it in a program with
its behaviors and actions.

Object is an instance of class. It is a variable of user defined type / abstract data type.

Real
-
world objects share two charac
teristics: They all have
state

and
behavior
.

For each object that you see, ask yourself two questions: "What possible states can this object be in?" and
"What possible behavior can this object perform?".

Make sure to write down your observations. As you
do, you'll notice that real
-
world objects vary in complexity; your desktop lamp may have only two
possible states (on and off) and two possible behaviors (turn on, turn off), but your desktop radio might
h
ave additional states (on, off, current volume, current station) and behavior (turn on, turn off, increase
volume, decrease volume, seek, scan, and tune). You may also notice that some objects, in turn, will also
contain other objects. These real
-
world obs
ervations all translate into the world of object
-
oriented
programming.

A software object.

Software objects are conceptually similar to real
-
world objects: they too consist of state and related
behavior. An object stores its state in
fields

(variables in s
ome programming languages) and
exposes its behavior through
methods

(functions
in some programming languages). Methods
operate on an object's internal state and serve as
the primary mechanism for object
-
to
-
object
communication. Hiding internal state and
re
quiring all interaction to be performed through
an object's methods is known as
data encapsulation



a fundamental principle of object
-
oriented
programming
.

Classes

In
object
-
oriented programming
, a
class

is a construct that is used as a
blueprint

to

create
instances

of
itself


referred to as
class instances
,
class objects
,
instance objects

or simply
objects
. A class defines
constituent members which enable these class instances to have
state

and
behavior
. Data field members
(
member variables

or
instance variables
) enable a class object to maintain state. Other kinds of members,
especially
methods
, enable a class object's behavior. Class instances are of the
type

of the associated class.

A class usually represents a noun, such as a person, place or (possibly quite abstract) thing, or something
nominalized
. For example, "Banana" is an instance of the class "Fruit" (a "Fruit" object). It is of the type
"Fruit".

Class is
a collection of data and code to handle that data.

Class is a user defined data/ abstract data type
.

Class defines basic layout and functionality of an object.


A class diagram is denoted by a rectangle that contain



Class name



Attributes


for each attribute : type(class) and initial value



Methods


for each method : argument list and result type

Example :








We can also draw instance of a class. This diagram contains :



Instance name
(optionally)



Class name



Attribute value

An
instance

is a specific occurrence of a class.

For a class called Person, sample instances
are "Mary Smith" and
"John
"











Class Diagram



Instance Diagram















Association, Aggregation and Composition

The
association

link indicates that
two classes have a relationship. It denotes a relation between objects of
two classes

that can be expressed in terms like “has a’, “uses”

a student attends a school; a student takes
courses.














Has capital


T
he optional triangle has no formal meaning, it just denotes the direction to read the description of the
association.

The

number of classes involved in an as
sociation can be
larger than 2.

For eg : a ternary association







File

Name

Size

print

Geomatric object

Color : Integer

Position : vector

Move (
delta : vector)

Select (p: Point) Bool

Rotate (angle)

P : Person

Name

= “John”

Age = 30

Person

Name

Age

Change job

Country

Name


City

Name











Class Diagram for ternary association








Instance Diagram for ternary association


Each association link has two ends which are called
roles
.

Each role has a
name
, a
multiplicity
, a
navigability

and a
type
.

Multiplicity:

The
multiplicity

of a role indicates how many objects can participate in the relationship.

In the example
above, a school has many students and each student attends only one school.


Navigability:

Sometimes a role has an arrow indicating its
navigability
.

This shows whi
ch class has the responsibility
for maintaining the relationship between the classes.

In the example above, the school class has a
responsibility for knowing which students attend.

Therefore, you don't have to explicitly define a
getStudents operation in

the school class (although you may) since it is already implicitly defined by the
navigability of the association.

Type:

The role can have one of three types:
association
,
composition

or
aggregation
.

Associations indicate
that the two classes have a rela
tionship as discussed above.

Composition and aggregation indicate
something more about the relationship:

Composition

indicates that one class belongs to the other.

A polygon is made up of several points.

If
the polygon is destroyed, so are the points.


Aggregation

is similar to composition, but is a less rigorous way of grouping things.

An order is made
up of several products, but a product continues to exist even if the order is destroyed.


In Visual Case, there are icons in the class diagram toolbar t
o allow you to draw an association,
composition or aggregation link directly onto your diagram.

However, once the link is drawn, you can
change either role type to any of three possible values.


Generalization

If two classes are very similar it may be helpful to put the similarities into a more general class called a
superclass
.

For example, if you set up a superclass called Student, then Graduate Student and
Undergraduate Student can be subclasses of Student.

Project


Language

Person

Cad :Project

C++ :Language

Banking : Project

Java :Language

Rahul : Person



Everything about the Student class is the same in the Graduate Student and Undergraduate Student
classes.

However, the two subclasses may have additional attributes and operations.


The concept of

generalization has broad application in many related d
isciplines, sometimes having
specialized context
-
specific meaning

For any two related concepts, A and B; A is considered a generalization of concept B if and only if



Every instance of concept B is also an instance of concept A;



There are instances of conce
pt A which are not instances of concept B.

Link Attributes

Link attribute is a property of links in association. It basically justifies the links.


Works for





In this example, salary is the attribute that is justifying the link works for i.e. staff works for salary in the
organization. A link attribute is show by dotted line.














Employee


Employer


Works for

Person and organization participate in association “works for”. A person has a role of employee while an
organization has role of employer.

Role Names

A role is an end of an association. A binary asso
ciation has two roles and each of them may have role
name which will uniquely identify at one end of association.

Organization

Staff


Salary

Organization

Staff


Salary

Person

Organization

Role names

are important for the association between the objects of the same class.







job

boss














0..1




employee


employer

























*

workers











manages



Every boss manages many workers.

Every worker has at most one boss : the general manager has no boss.


An employee has a job with an employer.

In reality, the “manages” association does not belong to a person, but to a person’s job. This is
modelled by an association class.






job


employee employer






boss












0..1

























* workers



















manages

Ordering

It is an inherent part of an ass
ociation in which objects are e
xplicitly order. Basically ordering is used to
present a particular order in an association. It is done by writing the { ordered} on the many end of an
association.


3+










{
ordered}


As the polygon is made of different points and all the points should be in a particular
order. So, to show them in a particular order {ordered} has been used.



Person

name

Company


Person

name

Company

Job

Salary

Polygon

Point

X
-
coordinate

Y
-
coordinate

Qualifiers

Qualifiers are used to relate two objects and classes. To reduce the
effective multiplicity of an
association, we can qualify it by the qualifiers.

A qualifier is a small box at the end of the association near the class it qualifies.




Constraints

Constraint defines some functional
relationships between entities of an object. The term entity may
include objects, classes, attributes, links and association. So we can implement the constraint on these
entities. This constraint is shown within {} braces.






{Length / Breadth = 15 ft}

Aggregation

Aggregation

is a special kind of association that specifies a whole/part relationship between the
aggregate (whole) and a component part. When compared to an ordinary association, some
distinguishing characteristics o
f aggregation include:



aggregation is an asymmetric relationship



aggregation is a transitive relationship



aggregation implies stronger coupling



behavior (copy, delete, etc.) is normally propagated across an aggregation.

Since aggregation is not symmetric
, it is important to visually distinguish which class is the
aggregate and which is a component part. Therefore
OMT uses

the association line with a small
open diamond at the aggregate end.




In this diagram, the document contain paragraph, paragraph contain sentence and sentence contain word.
The decision to use aggregation is largely a matter of judgement. So, when in doubt, always use an
ordinary
association.


CD
-

Name

CD

Music gallery

Room

Length

Breadth

Document

Parag
raph

Sentance

Word


Examples of Aggregation :









1


*

1

0..1

1




1

1..*

1..*

0..1



An aggregation relationship is essentially a binary association, a pairing between the assembly

class and a component class. An assembly with many kinds of components corresponds

to

many aggregations. We define each individual pairing as an aggregation so that we

can specify the multiplicity of each component within the assembly. This definition emphasizes

that aggregation is a special form of association. An aggregation can be quali
fied, have

roles, and have link attributes just like any other association

Aggregation Vs Association


An association is a channel between classes through which messages can be sent. As sending messages
translates to calling methods in Java, Associations a
re typically(but not necessarily) implemented by
references.

An Aggregation is an Association which denotes an “IS_PART_OF” relationship. Unfortunately, the
definition of this relationship is quite lax, so basically everyone is using his own interpretation
. The only
definitive (?) property is that in an instance graph, aggregations are not allowed to be circular


that is,
an object cannot be “a part of itself”. (Or) When building new classes from existing classes using
aggregation, a composite object built

from other constituent objects that are its parts. Java supports
aggregation of objects by reference, since objects can’t contain other objects explicitly.

Book

Front Matter

Chapter

Back Matter

Title page

Preface

Appendix

Index

Key board

Monitor

Computer

Syst. box

Mouse

Title page

Preface

Appendix

Index

Aggregation is typical whole/ part relationship. This is exactly the same as an association with th
e
exception that instances cannot have cyclic aggregation relationships (i.e. a part cannot contain its
whole)

Aggregation Vs Generalization




Subclasses inherit attributes, associations, & operations from the superclass

o


A subclass may override an
inherited aspect

o

e.g. AdminStaff & CreativeStaff have different methods for calculating bonuses

o


Superclasses may be declared {abstract}, meaning they have no instances

o


Implies that the subclasses cover all possibilities

o

e.g. there are no other staff than AdminStaff and CreativeStaff


Usefulness of generalization


Can easily add new subclasses if the organization changes


Look for generalizations in two ways:



Top Down

o

You have a class, and discover it can be subdivided

o

Or
you have an association that expresses a “kind of” relationship

o

E.g. “Most of our work is on advertising for the press, that’s newspapers and

magazines, also for advertising hoardings, as well as for videos”



Bottom Up

o

You notice similarities between
classes you have identified

o

E.g. “We have books and we have CDs in the collection, but they are all filed

using the Dewey system, and they can all be lent out and reserved”



But don’t generalize just for the sake of it

o

Be sure that everything about the
superclass applies to the subclasses

o

Be sure that the superclass is useful as a class in its own right



I.e. not one that we would discard using our tests for useful classes

o

Don’t add subclasses or superclasses that are not relevant to your analysis

GENERAL
IZATION

Abstract and Concrete Classes

A
concrete class
is a class that can have direct instances. In Figure 3.19
Stock
,
Bond
, and

Insurance
are concrete classes because they have direct instances.
FinancialInstrument
also

is a concrete class because some
FinancialInstrument
occurrences (such as real estate) are

not in the listed subclasses. The legend
concrete
below the class name indicates a concrete

superclass.






Concrete Class


An
abstract class
is a class that has no direct instances. The

descendant classes can also

be abstract, but
the generalization hierarchy must ultimately terminate in subclasses with direct

instances. In Figure 3.20
Person
is an abstract class but the subclasses
Manager
and
IndividualContributor

are concrete. The
lege
nd
abstract
indicates an abstract superclass. You

may define abstract operations for abstract classes.
An
abstract operation
specifies the signature

of an operation while deferring implementation to the
subclasses. The
signature
of an

operation specifies
the argument types, the result type, exception
conditions, and the semantics

of the operation. The notation for an abstract operation is the legend
{abstract}
following

the operation name.




























Abstract class


Generalization versus
Other Object
-
Modeling Constructs

It
shows how generalization differs from association. Both generalization and association

involve
classes, but association describes the relationship between two or more instances,

while generalization
describes different a
spects of a single instance.



During analysis, associations are more important than generalization. Associations add

information.
Associations transcend class encapsulation boundaries and can have a broad

impact on a system. In
contrast, generalization e
liminates duplications of shared properties

(consolidates), but does not change
the instances that conform to the model.

During design, generalization becomes more significant.
Developers tend to discover

data structure during analysis and behavior during
design. Generalization
provides a reuse

mechanism for concisely expressing behavior and including code from class libraries.
Judicious

reuse reduces development time and substitutes carefully tested library code for errorprone

application code.

Figure

shows how generalization differs from aggregation. Both generalization and

aggregation give rise to trees through transitive closure, but generalization is the “or” relationship

and
aggregation is the “and” relationship. In the figure, a bond is a fixed
-
r
ate bond

or
a variable
-
rate bond. A
book comprises front matter
and
many chapters
and
back matter.

Generalization relates classes that
describe different aspects of a single object. Aggregation

relates distinct objects that compose an
assembly.


Figure

s
hows how generalization differs from instantiation. Some modelers erroneously

introduce an
object as a subclass in a generalization. Generalization does not deal

with individual objects;

g
eneralization relates
classes

the superclass and the subclasses. In
stantiation

relates an instance to a
class.

A common mistake is to confuse a subclass with a role. Figure shows the difference

between a
subclass and a role. A subclass is a specialization of a class; a role is a usage of a

class. By definition, a
subclass pertains to only some superclass instances. There is no such

constraint with a role; a role may
refer to any or all instances.




subclasses for the class
Person
.
Pilot
and
FlightAttendant
are modeled as subclasses,
since

they have
different attributes and associations. In contrast,
employee
is merely a role for a

Person
;
pilot
and
copilot
are roles for
Pilot
; and
leadAttendant
is a role for
FlightAttendant
.

Generalization

is the process of extracting shared characteristics from two or more classes, and

combining them into a generalized superclass. Shared characteristics can be attributes, associations,
or

methods.

In Figure
, the classes
Piece of Luggage

(1)

and
Piece of C
argo

(2)

partially share the same attributes.
From a domain perspective, the two classes are also very similar. During generalization, the shared
characteristics
(3)

are combined and used to create a new superclass
Freight

(4)
.
Piece of Luggage

(5)

and
Pie
ce of Cargo

(6)

become subclasses of the class
Freight
.

The shared attributes
(3)

are only listed in the superclass, but also apply to the two subclasses, even
though they are not listed

there


In contrast to generalization,
specialization

means creating
new subclasses from an existing class. If it
turns out that certain attributes, associations, or methods only apply to some of the objects of the class, a
subclass can be created. The most inclusive class in a generalization/specialization is called the
su
perclass and is generally located at the top of the diagram. The more specific classes are called
subclasses and are generally placed below the

superclass.

In Figure
, the class
Freight

(1)

has the attribute
Degree of Hazardousness

(2)
, which is needed only

for
cargo, but not for passenger luggage. Additionally (not visible in Figure), only passenger luggage has a
connection to a coupon. Obviously, here two similar but different domain concepts are combined into
one class. Through specialization the two spec
ial cases of freights are formed:
Piece of Cargo

(3)

and
Piece of Luggage

(4)
. The attribute
Degree of Hazardousness

(5)

is placed where it belongs

in
Piece of
Cargo
. The attributes of the class
Freight

(1)

also apply to the two subclasses
Piece of Cargo

(3)

and
Piece of Luggage

(4)
:


Inheritance

In
object
-
oriented programming

(OOP),
inheritance

is a way to compartmentalize and
reuse

code by
creating collections of attributes and behaviors called
objects

which can be based on previously created
objects. In
classical inheritance

where objects are defined by
classes
, classes can inherit other classes.
The
new classes, known as
subclasses

(or derived classes), inherit attributes and behavior (i.e.
previously coded algorithms) of the pre
-
existing classes, which are referred to as
superclasses
, ancestor
classes or
base classes
. The inheritance relationships of
classes

gives rise to a
hierarchy
.

The inheritance concept was invented in 1967 for
Simula

Inheritance should not be confused with
(subtype) polymorphism
, commonly called just
polymorphism
.
Inheritance is a relationship between implementations, whereas subtype polymorphism is relationship
between
types

(interfaces in OOP).
[2]

(Compare
connotation/denotation
.) In some, but not

all OOP
languages, the notions coincide because the only way to declare a subtype is to define a new class that
inherits the implementation of another.

Inheritance in the object model is a means of defining one class in terms of another. This is common
us
age for most of us. For example, a conifer is a type of tree. There are certain characteristics that are
true for all trees, yet there are specific characteristics for conifers.

Note that in an object model, there is no distinction in usage between system
pre
-
defined types and user
-
defined types. This is known as
extensibility
. So it is possible to define a type as a sub
-
type of a system
type or as a sub
-
type of a user
-
define type.


In this example, a Student is a type of
Person. Likewise, a Employee is a
type of
Person. Both Student and Employee inherit
all the attributes and methods of Person.
Student has a locally defined student ID
attribute. Employee has a locally defined
employee ID attribute.

So, if you would look at a Student object,
you would see
attributes of name, date of
birth, parents, children, and student ID.





Applications

Overriding

Many
object
-
oriented programming languages

permit a class or object to replace the implementation of
an aspect

typically a behavior

that it has inherited. This process is usually called
overriding
.
Overriding introduces a complication: which version of the behavior does an instance of the inherited
class use

the one that is part of its own class, or the one from the parent (base) cl
ass? The answer
varies between programming languages, and some languages provide the ability to indicate that a
particular behavior is not to be overridden and behave according to the base class.

Code reuse

One of the earliest motivations for using inheritance was the reuse of code which already existed in
another class. This practice is usually called implementation inheritance. The primary concern is that
implementation inheritance does not provide any assu
rance of
polymorphic

substitutability

an instance
of the reusing class cannot necessarily be substituted for an instan
ce of the inherited class. An alternative
technique,
delegation
, requires more programming effort but avoids the substitutability issue.

Types of Inheritance

So far inh
eritance has been modelled in such a way that one parent can have many

children, but each
child can only have one parent. This form of inheritance is also

known as
single inheritance
.While this
mechanism is extremely powerful, it has two

distinct disadvant
ages.

∙ Hierarchies can become very complex and grow either too deep or too wide or

both. This can cause a
so
-
called ‘Yo
-
Yo’ effect, which becomes apparent when

trying to find certain attributes in a hierarchy.

∙ Sometimes, it is more natural that a single

class inherits properties from more

than one class and
artificial constructs have to be modelled which do not reflect

the actual appearance.

The latter point is an
advanced version of inheritance and is called
multiple

inheritance
.

Have a look at the familiar Sloopy
hierarchy below. At the sub
-
sub
-
class level, we

have hovering and skateboarding boys as well as singing
and flying girls. It was

possible to model all these activities using single inheritance.


If we want to create a ne
w class of skating Sloopies
which can also fly, we have to

create a sub
-
class under
Kojak
or
two other classes, one for male Sloopies and

another for female Sloopies.
Multiple inheritance
provides an alternative approach

where the new class
can inherit inf
ormation from the two relevant classes.








If you look at this diagram closely you may find some
inconsistencies. For example

the Sloopy at the bottom has
both a skateboard and wings which have been inherited

from the
SkatingSloopy
and
FlyingSloopy.
However, the
representation is of a boy

Sloopy and not a girl Sloopy. In
fact the skating flying Sloopy has actually inherited

the
attributes of both the boy and of the girl. You can see that
this causes conflict.



Desi
gn constraints



Singleness
: using single inheritance, a subclass can inherit from only one superclass. Continuing
the example given above,
Person

can be either a
Student

or an
Employee
, but not both. Using
multiple inheritance

partially solves this problem, as one can then define a
StudentEmployee

class that inherits from both
Student

and
Employee
. However, it can still inherit from each
superclass only once; this scheme does not support case
s in which a student has two jobs or
attends two institutions.



Static
: the inheritance hierarchy of an object is fixed at
instantiation

when the o
bject's type is
selected and does not change with time. For example, the inheritance graph does not allow a
Student

object to become a
Employee

object while retaining the state of its
Person

superclass.
(Although similar behavior can be achieved with the
decorator pattern
.) Some have criticized
inheritance, contending that it locks developers into their original design standards.
[6]



Visibility
: whenever client code has access to an object, it generally has access to all the object's
superclass data. Even if the superclass has not been declared public, the client can s
till
cast

the
object to its superclass type. For example, there is no way to give a function a pointer to a
Student
's grade point average and transcript without also giving that function access to all of the
personal data stored in the student's
Person

superclass. Many modern languages, including C++
and Java, provide a "protected" access modifier that allows subclasse
s to access the data, without
allowing any code outside the chain of inheritance to access it. This largely mitigates this issue.

Polymorphism

Polymorphism indicates the meaning of “many form.” In object
-
oriented design, polymorphism
present a method can has many definitions (forms). Polymorphism is related to
Overloading

and
Overriding
. Overloading indicates a method can have different definitio
ns by defining
different type of parameter, for example


getPrice(): void

getprice(String name): void


getPrice(
)

has two different forms


is the same meaning of different definitions. Overriding
indicates that subclass and
parentclass

have the same methods, parameters and return types
(namely to redefine the methods in
parentclass
). In
figure 3.12
,
encrypt(
String)

method has
three definitions, distribute in subclass an
d
parentclass
. Document object claims Encryption
object to assist
ecryption
. In its
encryString(
)

method, it doesn’t indicate
RSAEncryption

or
DesEncryption

is the encryption actor, just only send a message to
Encryption
object:

EncryptString(Encryption e
) {



result = e.encrypt(source);





}



MetaData

Metadata is structured data which describes the characteristics of a resource. It shares many similar
characteristics to the cataloguing that takes place in libraries, museums and archives. The term "meta"
derives from the Greek word denoting a nature of a

higher order or more fundamental kind. A metadata
record consists of a number of pre
-
defined elements representing specific attributes of a resource, and
each element can have one or more values. Below is an example of a simple metadata record:

Element na
me

Value

Title

Web catalogue

Creator

Dagnija McAuliffe

Publisher

University of Queensland Library

Identifier

http://www.library.uq.edu.au/iad/mainmenu.html

Format

Text/html

Relation

Library Web site

Each metadata schema will usually have the following characteristics:



a limited number of elements



the name of each element



the meaning of each element

Typically, the semantics is descriptive of the contents, location, physical
attributes, type (e.g. text or
image, map or model) and form (e.g. print copy, electronic file). Key metadata elements supporting
access to published documents include the originator of a work, its title, when and where it was
published and the subject are
as it covers. Where the information is issued in analog form, such as print
material, additional metadata is provided to assist in the location of the information, e.g. call numbers
used in libraries. The resource community may also define some logical gro
uping of the elements or
leave it to the encoding scheme. For example, Dublin Core may provide the core to which extensions
may be added.

Candidate Keys for Classes


A
candidate key
for a class is a combination of one or more attributes that uniquely ident
ifies

objects
within a class. The collection

of attributes in a candidate key must be minimal; no attribute can be
discarded from the

candidate key without destroying uniqueness. No attribute in a candidate key can be
null. A

given attribute may participat
e in multiple candidate keys.

For example, in Figure
airportCode
and
airportName
are two candidate keys for

Airport
. The model specifies that each
airportCode
(such as
IAH, HOU, STL, ALB) uniquely

identifies an airport. Each
airportName
(such as Houston
Intercontinental, Houston Hobby,

Lambert St. Louis airport, and Albany NY airport) also uniquely
identifies an airport.




W
e indicate a candidate key for a class with the notation
CKn
in braces next to the appropriate

attributes. The
n
is a number that d
ifferentiates multiple candidate keys. For a

multi
-
attribute candidate
key, multiple attributes have the
CKn
designation with the same

value of
n
.

Some readers may recognize the term “candidate key” from the database literature, but

the notion of a
candida
te key is a logical construct, not an implementation construct. It is often

helpful to be able to
specify the constraint that one or more attributes taken together are

unique. Relational database
managers and most object
-
oriented database managers can

read
ily enforce candidate keys.