OBJECT ORIENTED ANALYSIS AND DESIGN UNIT- 1 …UNIT- 1 INTRODUCTION TO UML 2 Prepared By: Prof. Vipin K. Wani Unit No. 1: Introduction to UML UML can be described as the successor

OBJECT ORIENTED ANALYSIS AND DESIGNUNIT- 1

INTRODUCTION TO UML

2

Prepared By: Prof. Vipin K. Wani Unit No. 1: Introduction to UML

UML can be described as the successor of object-oriented OO analysis

and design.

An object is an any real world entity which exists around the world

contains both data and methods that control the data.

The data represents the state of the object.

A class represents an object and they also form a hierarchy to model the

real-world system.

UML represent all the concepts that exist in object-oriented analysis and

design.

OBJECT-ORIENTED CONCEPTS


2

OBJECT-ORIENTED CONCEPTS


3

Following are some fundamental concepts of the object-oriented world:

1. Objects: Objects represent an entity and the basic building block.

2. Class: Class is the blueprint of an object.

3. Abstraction: Abstraction represents the collection of important data

related to object.

4. Encapsulation: Encapsulation bind the data together and hiding them from

the outside world.

5. Inheritance: Inheritance is the mechanism of deriving new classes from

existing ones.

6. Polymorphism: It defines the mechanism to express the object in different

forms.

Analysis of Object Oriented can be defined as an investigation and to be

more specific, it is the investigation of objects.

Design is collaboration of identified objects.

The most important purpose of Object Oriented analysis is to identify

objects of a system to be designed.

This analysis is also done for an existing system.

An efficient analysis plays very important role because the poor analysis is

going to affect the further steps design and implementation.

Object Oriented Analysis and Design


4

The purpose of Object Oriented analysis and design can described as:

1. Identifying the objects of a system.

2. Identifying their relationships.

3. Making a design, which can be converted to executable using Object

Oriented language

Object Oriented Analysis and Design


5

Analysis Designimplementation

using OOlanguages

UML is a standardized general-purpose modelling languageused for Visualization, Documentation and construction of thesystem.

UML is a standardized general-purpose modelling language inthe field of object-oriented software engineering.

UML includes a set of graphic notation techniques to createvisual models of object-oriented software systems.

UNIFIED MODELLING LANGUAGE (UML):


6

A model is a simplification at some level of abstraction.

We build models to better understand the systems we are

developing.

There is a difference between a UML model and the set of diagrams

of a system.

A diagram is a partial graphic representation of a system’s model.

The model also contains documentation that drives the model

elements and diagrams .

What is Modelling?


7

Why do we model? A model is a simplification at some level of abstraction.

We build models to better understand the systems we are developing.

1. To help us visualize

2. To specify structure or behaviour

3. To provide template for building system

4. To document decisions we have made

Importance of Modelling


8

The models we choose have a profound influence on the solution we

provide Every model may be expressed at different levels of

abstraction.

The best models are connected to reality No single model is

sufficient, a set of models is needed to solve any nontrivial system

Principles of Modelling


9

UML The vocabulary of the UML encompasses three kinds of

building blocks.

These are also considered as the components of UML:

1. Things

2. Relationships

3. Diagrams

BUILDING BLOCKS OF UML


10

A. Things: Things are the smallest building block of the system.

are the abstractions that are first-class citizens in a model; relationships tie

these things together; diagrams group are collections of things.

There are four kinds of things in the UML:

1. Structural things

2. Behavioural things

3. Grouping things

4. Un-notational things

BUILDING BLOCKS OF UML


11

1. Structural Things:

These are the mostly static parts of a model, representing

elements that are either conceptual or physical.

Collectively, the structural things are called classifiers.

The various structural things are classes, interfaces,

components, nodes etc.

Building Blocks of UML: Things


12

i. A class: is a description of a set of objects that share the same attributes, operations,

relationships, and semantics.

A class implements one or more interfaces.

Graphically, a class is rendered as a rectangle, usually including its name,

attributes, and operations

Building Blocks of UML: Things: Structural Things:


13

ii. An interface is a collection of operations that specify a service of a class or component.

The declaration of an interface looks like a class with the keyword«interface» above the name.

An interface provided by a class to the outside world is shown as a smallcircle attached to the class box by a line.

An interface required by a class from some other class is shown as a smallsemicircle attached to the class box by a line.



13

iii. A collaboration is a set of roles or responsibilities and other elements that work together to

provide some cooperative behaviour that's bigger than the sum of all theelements.

Collaborations have structural, as well as behavioural, dimensions. A givenclass or object might participate in several collaborations.

Graphically, a collaboration is rendered as an ellipse with dashed lines,sometimes including only its name.



13

iv. A use case is a description of actions that a system performs that yield observable

results of value to a particular actor. A use case is used to structure the behavioural things in a model. Graphically, a use case is rendered as an ellipse with solid lines, usually

including only its name.



13

v. An active class is a class whose objects own one or more processes or threads and therefore

can initiate control activity. Graphically, an active class is rendered as a class with double lines on the left

and right.



13

vi. A component Component can be any hardware or software part of the system. is a modular part of the system design that hides its implementation behind

a set of external interfaces. Graphically, a component is rendered like a class with a special icon in the

upper right corner.



13

vii. An artifact is a physical and replaceable part of a system that contains physical

information. In a system, you'll encounter different kinds of deployment artifacts, such as

source code files, executable files, and scripts. Graphically, an artifact is rendered as a rectangle with the keyword

«artifact» above the name.



13

viii. A node is a physical element that exists at run time and represents a computational

resource, generally having at least some memory and, often, processingcapability.

Graphically, a node is rendered as a cube, usually including only its name.



13

2. Behavioural Things: Behavioural things are the dynamic parts of UML models.

These are the verbs of a model, representing behaviour over time and space.

In all, there are three primary kinds of behavioural things. These three

elements interactions, state machines, and activities are the basic

behavioural things that you may include in a UML model

Building Blocks of UML: Things: Behavioural Things:


13

i. an interaction: is a behaviour that comprises a set of messages exchanged among a set of

objects or roles within a particular context to accomplish a specific purpose.

An interaction involves a number of other elements, including messages,

actions, and connectors (the connection between objects).

Graphically, a message is rendered as a directed line, almost always

including the name of its operation.



13

ii. a state machine is a behaviour that specifies the sequences of states an object or an

interaction goes through during its lifetime in response to events.

A state machine involves a number of other elements, including states,

transitions (the flow from state to state), events, and activities.

Graphically, a state is rendered as a rounded rectangle.



13

iii. an activity is a behaviour that specifies the sequence of steps a computational process

performs. A step of an activity is called an action. Graphically, an action is rendered as a rounded rectangle with a name

indicating its purpose It is just similar to flow chart.



13

3. Grouping Things Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. There is one primary kind of grouping thing, namely, packages.

A package is a general-purpose mechanism to group or collect all the things together in

a bundle. Structural things, behavioural things, and even other grouping things may

be placed in a package. a package is purely conceptual. Graphically, a package is rendered as a tabbed folder, usually including only

its name and, sometimes, its contents.

Building Blocks of UML: Things: Grouping Things:


13

4. An notational Things: An notational things are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate, and remark

about any element in a model. There is one primary kind of an notational thing, called a note.

A note is simply a symbol for rendering constraints and comments attached to an

element or a collection of elements. Graphically, a note is rendered as a rectangle with a dog-eared corner,

together with a textual or graphical comment.

Building Blocks of UML: Things: Notational Things:


13

B. Relationships in the UML:

is used to show the relation between the various components of UML.

There are four kinds of relationships in the UML. These relationships are the

basic relational building blocks of the UML.

1. Dependency

2. Association

3. Generalization

4. Realization

5. Aggregation

Building Blocks of UML: Relationships


13

1. Dependency: is a semantic relationship between two model elements in which a change to

one element may affect the semantics of the other element.

Graphically, a dependency is rendered as a dashed line, possibly directed,

and occasionally including a label.

Building Blocks of UML: Relationships : Dependency


13

2. An association : is a structural relationship among classes that describes a set of links, a link

being a connection among objects that are instances of the classes. Graphically, an association is rendered as a solid line, possibly directed,

occasionally including a label.

Building Blocks of UML: Relationships : Association


13

3. Generalization is a specialization/generalization relationship in which the specialized

element builds on the specification of the generalized element.

The child shares the structure and the behaviour of the parent.

Graphically, a generalization relationship is rendered as a solid line with a

hollow arrowhead pointing to the parent.

Building Blocks of UML: Relationships : Generalization


13

4. Realization is a semantic relationship between classifiers, wherein one classifier

specifies a contract that another classifier guarantees to carry out. You'll encounter realization relationships in between interfaces and the

classes or components that realize them. Graphically, a realization relationship is rendered as a cross between a

generalization and a dependency relationship.

Building Blocks of UML: Relationships : Realization


13

5. Aggregation: In UML models, an aggregation relationship shows a classifier as a part of or

subordinate to another classifier.

An aggregation is a special type of association in which objects are

assembled or configured together to create a more complex object.

It represents has a type of relationship.

Building Blocks of UML: Relationships : Aggregation


13

C. A Diagram is the graphical presentation of a set of elements.

You draw diagrams to visualize a system from different perspectives, so a

diagram is a projection into a system.

a diagram may contain any combination of things and relationships.

Different UML diagrams are

1. Class diagram

2. Object diagram

3. Component diagram

4. Composite structure diagram

Building Blocks of UML: Diagrams


13

5. Use case diagram

6. Sequence diagram

7. Package diagram

8. State diagram

9. Activity diagram

10. Deployment diagram

11. Communication diagram

12. Timing diagram

13. Interaction overview diagram

Building Blocks of UML: Diagrams


13

Object Management Group is an international, open membership, not-for-

profit technology standards founded in 1989.

OMG standards are driven by vendors, end-users, academic institutions and

government agencies.

OMG having more than 300 International organization working for it which

are taking a hard work for improvement and development in Object oriented

concepts.

The goal of the OMG was a common portable and interoperable object model

with methods and data that work using all types of development

environments on all types of platforms.

The group provides only specifications, not implementations.

INTRODUCTION TO OMG


14

Model Driven Architecture is an approach to software design used in

development of softwares.

MDA provides guidelines for structuring software specifications that are

expressed as models.

It is a New Way to Specify and Build Systems based on open standards from

the OMG.

It Focus on Business Needs First rather than focusing on rest of the things.

Its purpose is to generate platform specific models (PSM) from platform

independent models (PIM).

MDA separates business and application logic from underlying platform

technology.

OMG Standards: Model Driven Architecture (MDA)


15

Platform independent model (PIM) - is independent of, and can be used

with, platforms of any particular type - hiding the details necessary for

particular platforms.

Platform specific model (PSM) - combines the specifications in the PIM

with the details that specify how that system uses a particular type of

platform - specifies a system in terms of elements used in platforms.

How it converts PIM to PSM

1. It begins with specifying the system independent of platform.

2. The next step is to specify the platform.

3. Next step is to choose a platform suitable for system.

4. Transforming the PIM to PSM and then implementing the system.



15



15

Figure: PIM to PSM Conversion



15

Figure: MDA Architecture

Some of the other standards of OMG which are driven by MDA are

1. Common Object Request Broker Architecture

2. Meta-Object Facility

3. XML Metadata Interchange

4. OMG's Unified Modelling Language

5. Common Warehouse Metamodel



16

1. Common Object Request Broker Architecture (CORBA): CORBA is OMG's open, vendor-independent specification for an architecture

and infrastructure that computer applications use to work together over

networks.

In other words it provides a communication mechanism for objects

distributed over the network.



16

2. Meta-Object Facility (MOF): standardizes a meta-model - the concepts that you use to build your

application model.

It provides the interfaces for communication in CORBA.

UML models, which are built from the MOF metamodel, interchange easily

because of this commonality.

Another part of the MOF specification defines a repository for metamodels

and models.



16

3. XML Metadata Interchange (XMI):

is a stream format for interchange of metadata including the

UML models that you create during your analysis and design

activities.

It's useful for transferring the model from one step to the next

as your design and coding progress, or for transferring from

one design tool to another.



16

4. OMG's Unified Modelling Language:

is a graphical language that expresses application requirements

analysis and program design in a standard way.



16

5. Common Warehouse Metamodel:

standardizes a basis for data modelling commonality within an

enterprise, across databases and data stores.

Building on a foundation metamodel, it adds metamodels for

relational, record, and multidimensional data.



16

Class Diagram


17

Class diagram in the UML is a type of static structure diagram that describes the

structure of a system by showing the system's classes, their attributes, operations

and the relationships among objects.

The class diagram is the main building block of object-oriented modelling.

It is used for general conceptual modelling of the structure of the application, and

for detailed modelling translating the models into programming code.

Class diagrams can also be used for data modelling.

The classes in a class diagram represent both the main elements, interactions in the

application, and the classes to be programmed.

Thepurposeoftheclassdiagramcanbesummarizedas−

Analysis and design of the static view of an application.

Describe responsibilities of a system.

Describe various attributes and operations of a system.

To describe relationship among the classes.

Base for component and deployment diagrams.

Forward and reverse engineering.

Purpose of Class Diagram


18

1. Class: In the diagram, classes are represented with boxes that contain

three compartments, representing class name, attributes andoperations.

Components of Class Diagram


19

1. Class: In the diagram, classes are represented with boxes that contain three

compartments, representing class name, attributes and operations.



19

Object relation model is a very powerful model but coming to its design it is quiet

complex.

This complexity is not problem because it gives efficient results and widespread with

huge applications. It has a feature which allows working with other models like

working with the very known relation model.

Advantages of Object Relational model is inheritance The Object Relational data

model allows its users to inherit objects, tables etc.

The object relational data model can get quite complicated and difficult to handle at

times as it is a combination of the Object oriented data model and Relational data

model and utilizes the functionalities of both of them.

Components of Class Diagram: Class


20

Member access modifiers

All classes have different access levels depending on the access modifier

(visibility). Here are the access levels with their corresponding symbols:

Public (+)

Private (-)

Protected (#)

Package (~)

Derived (/)

Static (underlined)

Components of Class Diagram: Class


20

2: Interfaces:A collection of operation signatures and/or attribute definitions that define a

cohesive set of behaviors. Interfaces are similar to classes, except that a class

can have an instance of its type, and an interface must have at least one class to

implement it.



20

3. Enumerations:

It is also called as enum, is a type is a special data type that enables for a

variable to be a set of predefined constants. The variable must be equal to one

of the values that have been predefined for it.



20

4. Artifacts:

is a physical and replaceable part of a system that contains physical

information.

In a system, you'll encounter different kinds of deployment artifacts, such as

source code files, executable, and scripts, documents, databases, executable

files, software components



20

5. Objects:Instances of a class or classes. Objects can be added to a class diagram to

represent either concrete or prototypical instances



20

6. Packages:

These are the boxes into which a model can be decomposed.

Is a kind of grouping thing, namely, packages.

Structural things, behavioural things, and even other grouping things may be

placed in a package



20

7. Signals:

Symbols that represent one-way, asynchronous communications between

active objects.



20

8. Relationships:

The term "interactions" refers to the various relationships and links that can

exist in class and object diagrams. Some of the most common interactions

include:

1. Dependency

2. Association

3. Generalization

4. Realization

5. Aggregation

6. Composition



20

1. Dependency: A dependency means the relation between two or more

classes in which a change in one may force changes in the other. However, it

will always create a weaker relationship. Dependency indicates that one

class depends on another.

In the following example, Student has a dependency on College



20

2. Association: This kind of relationship represents static relationships

between classes A and B. For example; an employee works for an organization.

Here are some rules for Association:

It should be named to indicate the role played by the class attached at the

end of the association path.



20

3. Aggregation: Aggregation is a special type of association that models a

whole- part relationship between aggregate and its parts.



20

4. Composition: The composition is a special type of aggregation which

denotes strong ownership between two classes when one class is a part of

another class.

For example, if college is composed of classes student. The college could

contain many students, while each student belongs to only one college.



20

5. Generalization: A generalization helps to connect a subclass to its

superclass. A sub-class is inherited from its superclass.

Generalization relationship can't be used to model interface implementation.

Class diagram allows inheriting from multiple super classes.



20

6. Realization is a semantic relationship between classifiers, wherein one

classifier specifies a contract that another classifier guarantees to carry out.

You'll encounter realization relationships in two places: between interfaces and

the classes or components that realize them, and between use cases and the

collaborations that realize them.



20

Class Diagram for Library Management System


21

Draw the Class Diagrams for

1. Restaurant management System

2. Railway ticket booking System

3. Hospital Management System

4. Two Wheeler Showroom management System.

Exercise


23

The project development is a continuous activity consisting of various phases

included in it which are executed in collaboration with each other. The

various phases of project development life cycle are as follow.

1. Inception

2. Elaboration

3. Construction

4. Transition

The Project Development Life Cycle


24



24



24

Inception: The primary goal of the Inception phase is to establish the case for the

viability of the proposed system. The tasks that a project team performs during

Inception include the following:

1. Defining the scope of the system (that is, what's in and what's out)

2. Outlining a candidate architecture, which is made up of initial versions of six

different models

3. Identifying critical risks and determining when and how the project will address

them

4. Starting to make the business case that the project is worth doing, based on initial

estimates of cost, effort, schedule, and product quality

5. Identifying the complete requirement of customer.

6. Identifying the customer and users.



24

Elaboration: The primary goal of the Elaboration phase is to establish the ability to

build the new system given the financial constraints, schedule constraints, and other

kinds of constraints that the development project faces.

The tasks that a project team performs during Elaboration include the following:

1. Preparing a design or blueprint of the system.

2. Flexibility study of customer requirement

3. Cost estimation of the system

4. is to analyse the problem domain. develop the project plan, and eliminate the

highest risk elements of the project.

5. Addressing significant risks on an on going basis

6. Finalizing the business case for the project and preparing a project plan that

contains sufficient detail to guide the next phase of the project (Construction).



24

Construction: The primary goal of the Construction phase is to build a system

capable of operating successfully in beta customer environments.

During Construction, the project team performs tasks that involve building the

system iteratively and incrementally, making sure that the viability of the

system is always evident in executable form.



24

Transition: The primary goal of the Transition phase is to roll out the fully

functional system to customers. During Transition, the project team focuses

on correcting defects and modifying the system to correct previously

unidentified problems.

The major milestone associated with the Transition phase is called Product

Release.

It includes following activities

1. Deployment of application on client platform

2. Taking a feedback from customer

3. Implementing the customer feedback in next release.

4. It also includes users training.

Thank You74


Documents

OBJECT ORIENTED ANALYSIS AND DESIGN UNIT- 1 …UNIT- 1 INTRODUCTION TO UML 2 Prepared By: Prof. Vipin K. Wani Unit No. 1: Introduction to UML UML can be described as the successor