uml constructs

29
UML Constructs Object Oriented Programming

Upload: sardar-dawood-faheem-abbasi

Post on 13-Feb-2017

107 views

Category:

Education


0 download

TRANSCRIPT

Page 1: UML constructs

UML Constructs

Object Oriented Programming

Page 2: UML constructs

University of Azad Jammu & KashmirMuzaffarabad

Deparment of CS & IT

• Dawood Faheem Abbasi

Page 3: UML constructs

CONTENT LIST

• UML• GENERALIZATION• SPECIALIZATION• CATEGORIES

• AGGREGATION• ASSOCIATION • REALIZATION• DEPENDENCY

Page 4: UML constructs

UML(Unified Modeling Language)

• The UML is a graphical language for modeling computer programs. Modeling means to create a simplified representation of something, as a blueprint models a house. The UML provides a way to visualize the higher level organization of programs without getting mired down in the detail of actual code.

• The blueprint of a system is written in it.• UML is a notation system though which we can

visualize a model of a system• It describe only design or structure of system

Page 5: UML constructs

Generalization• The process of extracting common characteristics

from two or more classes and combining them into a generalized superclass, is called Generalization.

• The common characteristics can be attributes or methods.

• Generalization is represented by a triangle followed by a line.

Page 6: UML constructs

Specialization

• Specialization is the reverse process of Generalization means creating new sub classes from an existing class.

Page 7: UML constructs

Example

• Let’s take an example of Bank Account;

• A Bank Account is of two types – • Current Account and Saving

Account.• Current Account and Saving

Account inherits the common/ generalized properties like Account Number, Account Balance etc. from a Bank Account and also have their own specialized properties like interest rate etc.

Page 8: UML constructs

Advantages of specialization

• Reusability:It allows the developer to reuse the existing code

in many situations. Single class can be used many times.• Saves time and effort:

It allow a developer to save a lot of time to rewrite the same classes again.• Increase program structure and reliability:

Super class is already compiled and tested properly. This can be used again without compiling again. It increases reliability of program or software.

Page 9: UML constructs

Syntax

#include<iostream.h>#include<conio.h>Class parent{};Class child: public parent{};

Page 10: UML constructs

Categories

• Single:• The modeling in which a child class is derived from a

single parent class. • This child class inherits all data members and

member functions of parent class.• Multiple:• The type of modeling in which child class is derived

from the multiple parents. • The child class inherits all data members and

member functions of all the parent class.

Page 11: UML constructs

Access level

Access specifier Accessible from own class

Accessible from derived class

Accessible from objects outside class

public Yes Yes Yes

protected Yes Yes No

private Yes No No

Page 12: UML constructs

Single parent class

• Class A• {• };• Class B: public A• {• };• Class C: public A• {• };

A B C

Page 13: UML constructs

Multiple parent classes

Class A{};Class B{};Class C: public A, public B{};

A B C

Page 14: UML constructs

Association

• Association is a relationship between two objects. In other words, association defines the multiplicity between objects.

• 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.

Page 16: UML constructs

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.

Page 17: UML constructs

Dependency

• Dependency is a relationship between two things in which change in one element also affects the other one.

Page 18: UML constructs

Aggregation

• Aggregation is a special case of association. A directional association between objects. When an object ‘has-a’ another object, then you have got an aggregation between them. Direction between them specified which object contains the other object. Aggregation is also called a “Has-a” relationship.

Page 19: UML constructs

Composition

• Composition is a special case of aggregation. In a more specific manner, a restricted aggregation is called composition. When an object contains the other object, if the contained object cannot exist without the existence of container object, then it is called composition.

Page 20: UML constructs

Difference between aggregation and composition

• Composition is more restrictive. • When there is a composition between two objects, the

composed object cannot exist without the other object. • This restriction is not there in aggregation. • Though one object can contain the other object, there is

no condition that the composed object must exist. • The existence of the composed object is entirely optional. • In both aggregation and composition, direction is must. • The direction specifies, which object contains the other

object.

Page 21: UML constructs

Understanding Association, Aggregation and Composition

1. Manager is an employee of XYZ limited corporation.2. Manager uses a swipe card to enter XYZ premises.3. Manager has workers who work under him.4. Manager has the responsibility of ensuring that the project is

successful.5. Manager's salary will be judged based on project success.If you flesh out the above 5 point requirement we can easily visualize 4 relationships:-

– Inheritance– Aggregation– Association– Composition

• Let's understand them one by one.

Page 22: UML constructs

Requirement 1 (The IS A relationship)

• If you see the first requirement (Manager is an employee of XYZ limited corporation) it's a parent child relationship or inheritance relationship. The sentence above specifies that Manager is a type of employee, in other words we will have two classes one the parent class "Employee" and the other a child class "Manager" which will inherit from "Employee" class.

Page 23: UML constructs

Requirement 2 (The Using relationship: - Association)

• The requirement 2 is an interesting requirement (Manager uses a swipe card to enter XYZ premises).

• In this requirement the manager object and swipe card object use each other but they have their own object life time. In other words they can exist without each other.

• The most important point in this relationship is that there is no single owner.

Page 24: UML constructs

• The above diagram shows how the "Swipe Card" class uses the "Manager" class and the "Manager" class uses the "Swipe Card" class. You can also see how we can create the object of the "Manager" class and "Swipe Card" independently and they can have their own object life time.

• This relationship is called as the "Association" relationship.

Page 25: UML constructs

Requirement 3 (The Using relationship with Parent: - Aggregation)

• The third requirement from our list (Manager has workers who work under him) denotes the same type of relationship like association but with a difference that one of them is an owner. So as per the requirement the "Manager" object will own "Workers" object.

• The child "Worker" objects can not belong to any other objects. For instance the "Worker" object cannot belong to the "Swipe Card" object.

• But But....the "Worker" object can have his own life time which is completely disconnected from the "Manager" object. Looking from a different perspective it means that if the "Manager" object is deleted the "Worker" object does not die.

• This relationship is termed as the "Aggregation" relationship.

Page 26: UML constructs

Requirement 4 and 5 (The Death relationship: - Composition)

• The last two requirements are actually logically one. If you read closely both the requirements which are as follows:-

• Manager has the responsibility of ensuring that the project is successful.

• Manager's salary will be judged based on project success.

• Below is the conclusion from analyzing the above requirements:-

• Manager and the project objects are dependent on each other.

• The lifetimes of both the objects are same. In other words the project will not be successful if the manager is not good and manager will not get good increments if project has issues.

• Below is how the class formation will look like. You can also see when I go to create the project object it needs the manager object.

Page 27: UML constructs

Putting all things together

Page 28: UML constructs

SummaryTo avoid confusion hence forth in these 3 terms I have put forward a table below

which will help you compare them from 3 angles owner , life time and child object.

Association Aggregation composition

Owner No owner Single owner Single owner

Life time Have their own life time

Have their own life time

Owner’s life

Child object No child objects, all are independent

Child objects belong to single parent

Child objects belong to single parent

Page 29: UML constructs

THANK YOU

TAKE A SMILE..! THEY ARE FREE…;)