UNIT – 2

Unit-02/Lecture-01

• Relationships between classes
• Association

              - Association of objects

            - Types of Association

            - Recursive Association

            - Named association

• Aggregation

               -Aggregation of objects

               -Types of Aggregation

·         Modeling Association and Aggregation

Relationships between classes

·         Classes can be related in two ways:

1. An aggregation relation, named Has-a:
   class C₂ is related by Has-a with class C₁ when C₂ has a field whose type is that of class C₁. This relation can be generalized as: C₂ has at least one field whose type is that of class C₁.
2. An inheritance relation, named Is-a:
   class C₂ is a subclass of class C₁ when C₂ extends the behavior of C₁. One big advantage of object-oriented programming is the ability to extend the behavior of an existing class while reusing the code written for the original class. When a class is extended, the new class inherits all the fields (data and methods) of the class being extended.

·         Before any programs are written, really before a single character is typed in a file, some design work must be done. For an object-oriented language, such as C++, design starts with choosing classes and defining their relationships.

·         The three main types of relationships between classes are generalization (inheritance), aggregation, and association.

ü  Generalization - This implies an "is a" relationship. One class is derived from another, the base class. Generalization is implemented as inheritance in C++. The derived class has more specialization. It may either override the methods of the base, or add new methods. Examples are a poodle class derived from a dog class, or a paperback class derived from a book class.

ü  Aggregation - This implies a "has a" relationship. One class is constructed from other classes, that is, it contains objects of any component classes. For example, a car class would contain objects such as tires, doors, engine, and seats.

ü  Association - Two or more classes interact in some manner. They may extract information from each other, or update each other in some way. As an example, a car class may need to interact with a road class, or if you live near any metropolitan area, the car class may need to pay a toll collector class.

Generalization

·         Generalization is the relationship between a class and one or more redefine versions of it.

                                The class being redefined is called the super class and each redefine versions is called a subclass. For example equipment is the super class of pump and tank. Attribute and operation common to a group of subclass are attached to the super class and shared by each subclass. Each subclass is said to inherit the feature of its superclass.

·         Generalization is sometime called the “is-a” relationship because each instance of a subclass is an instance of the super class as well.

·         The notation for generalization is a triangle connecting a super class to its subclasses.

                      The super class is connected by a line to the apex of the triangle. The subclasses are connected by lines to a horizontal bar attached to the base of the triangle.

Fig. 3 Generalization

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

·                  The term generalization is used to specify the classification relationship between a general element and a more specific element.

·                   In fact, the term 'generalization' specifies a viewpoint focused on a classification hierarchy. For example, an animal is a more general concept than a cat, a dog, or a raccoon.

·                  Conversely, a cat is a more specialized concept than an animal.
The more specific element may contain information that is particular to it, as long as it remains completely consistent with the description of the more general element.

·                   In the case of classes, the generalization relationship expresses the fact that the elements of one class are also described by another class (in fact, by the type of another class).

·                  The generalization relationship signifies 'is a' or 'is a kind of'. A cat is an animal; that has to do with generalization.

·                  The generalization relationship is represented by an arrow that points from the more specialized class to the more general class. The tip of the arrow is an empty triangle, which allows it to be distinguished from the open arrow that symbolizes the navigation property of associations. In the following example, the Animal class is an abstraction of the classes Cat, Dog and Raccoon.

Fig. 4   Generalization between class Animal and classes Cat, Dog and Raccoon

Unit-02/Lecture-02

Association

·         An association is a simple structural connection between classes.

·         Association establishes relationship between two classes through their objects. The relationship can be one to one, one to many, many to one and many to many.

·         It also represents a relationship between two or more objects where all objects have their own lifecycle and there is no owner. The name of an association specifies the nature of relationship between objects. This is represented by a solid line.

Fig.5 Notation for association

·         An association is assumed to be bidirectional, which means that you can navigate from either class to the other one. However, you can specify that navigation can only occur from one class to another by using a feathered arrow, as shown in fig.

Fig.6 One-way navigation between classes

·         Ex. Relationship between Teacher and Student. Multiple students can associate with a single teacher and a single student can associate with multiple teachers. But there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.

                                                  Fig. 7 Show Association

·         Oftentimes when modeling how classes associate with one another, the association itself specifies a lot of information about the relationship. When such is the case, you may model the association as an 'association class' -- literally specifying that the association has class-like properties, such as attributes, operations, and other associations.

·         In the UML Class diagram, the association class is shown as a class symbol attached to the association path by a dashed line. Logically, the association class and the association represent

the same underlying model element, which has a single name; however, they are graphically distinct. The name may be placed on the path, in the class symbol, or on both.

·         For example, you are building an application for Human Resources. In your application you want to specify that a class Person may have a job with the class Company. A person is paid a salary, and so you could model salary as an attribute of the class Person. But what if the person has more than one job (different companies), or even more than one job at your company (they might have a 9-5 job but also work freelance for another department). For a number of reasons, it makes sense to make the association contain job information such as salary.

Fig. 8 An example of Association Class

·         An association can contain roles, which are the faces that classes present to other classes. As shown in Figure, roles generally appear in pairs.

Fig. 9 Association roles

You read an association with role names from a class to the role immediately next to it to the class on the other side of the association. A class can play the same role or different roles within different associations.

Unit-02/Lecture-03

·           Types of Association

-          One-to-One Association

-          Many-to-many Association

-          Ternary Association

One-to-One

·         One-to-One denotes a very narrow association. Each association in the class diagram corresponds to asset of links in the instance diagram like each class corresponds to set of objects.

·         Ex. Each country has a capital city. Has capital is the name of the association

                                                            Fig. 10 One-to-One Association

Many-to-Many

·         To implement M:N associations, a new relation is created that represents the association. For example, consider the following association between Employee and Project:

                                                               Fig. 11 Many-to-Many association

Ternary Association

·         A ternary association describes a fact that involves three classes and cannot be split up into component binary associations without losing information.

·         For example, when a seller negotiates a price with a buyer through an agent, a decomposition of the ternary into two binary associations between buyer and seller and seller and agent would lose the information on which buyer was involved in the deal between the seller and agent.

Fig.12 Ternary Association

Ex. Association Example

class CarClass{

   String carName;

   double carSpeed;

   int carId;

   CarClass(String name, double speed, int Id)

   {

                    this.carName=name;

                    this.carSpeed=speed;

                    this.carId=Id;

   }

}

class Driver{

   String driverName;

   int driverAge;

   Driver(String name, int age){

      this.driverName=name;

      this.driverAge=age;

   }

}

class TransportCompany{

   public static void main(String args[])

   {

                    CarClass obj= new CarClass("Ford", 180.15, 9988);

                    Driver obj2 = new Driver("Andy", 45);

                    System.out.println(obj2.driverName+" is a driver of car Id: "+obj.carId);

   }

}

Output:

Andy is a driver of car Id: 9988

In this example, there is a one to one relationship (Association) between two classes: Car and Driver. Both the classes represent two separate entities.

Unit-02/Lecture-04

Recursive Association

·         Recursive association: A class has a relation with itself.

·         Recursive aggregation is referred to as recursive association because aggregation is a special kind of association.

·         A recursive association has directly or indirectly, an instance of the same kind of association, there is unlimited number of potential levels.

·         Recursive associations are associations in which one class is involved.

Fig. 13(a) Recursive association

 Ex. following figures shows example of computer program.

Fig. 13 (b) Recursive association

·       An aggregation of blocks is a computer program with optionally recursive compound statements, the recursion finishes with simple statement. Blocks are nested to arbitrary depth.

·       Recursive association can represent many sorts of single parent hierarchies.

Multiplicities

·         An association can show multiplicity.

Fig. 14 (a) Multiplicities

Fig. 14 (b) Multiplicities

·         Multiplicity is a definition of cardinality - i.e. number of elements - of some collection of elements by providing an inclusive interval of non-negative integers to specify the allowable number of instances of described element.

·         A multiplicity specification is a subset of the open set of non-negative integers. You can give multiplicity specifications for roles in association relationships.

·         A multiplicity relationship appears as a text string that comprises an integer value that represents the number of data objects that can be associated with a C/C++ class.

·         Multiplicity relationships are possible in that one class can relate to another in a one-to-one or a one-to-a bounded interval; for example, 1 to 1 or 1 to 10.

·         Multiplicity relationships are the number of objects from one class that relate to a single object in an associated class. As the following figure illustrates, to represent these numbers in a class diagram, multiplicity relationships are shown close to the association line (connector) near the associated class.

·                Multiplicity indicates the number of class instances (objects) that can be involved in an association.

·                Multiplicity specifies how many i9nstances of one class may relate to single instance of an associated class.

·                Multiplicity constraints the number of related objects.

·                The number of objects involved on both sides of a relationship is called multiplicity of the relationship.

·                IN the class diagram, symbols are used at both ends of the relationship line to indicate multiplicity.

Fig. 15

Unit-02/Lecture-05

Navigability

·         An association is assumed to be bidirectional, which means that you can navigate from either class to the other one. However, you can specify that navigation can only occur from one class to another by using a feathered arrow, as shown in Figure

Fig. 16   One-way navigation between classes

·         Navigability arrows in the class indicate in which direction an association can be traversed and are based on the collaboration modeled in communication and sequence diagrams.

·         Establishing the navigation arrow on this association means that a Customer has access to his or her Password, but no one can in turn use a Password to identify a Customer.

·                Navigation is optional and indicates whether a class may be referenced from the other classes in an association.

·                If no arrows are present, associations are assumed to be navigable in all directions, and all classes involved in the association may reference one another.

·                Figure shows navigation arrows applied to an n-ary association. Given a worker, you can reference his work products and units of work to determine his utilization, but given a work product or

unit of work, you are unable to determine its utilization by a worker.

Named Association

·                Named associations can be given in any order, but if both positional and named associations are used in the same call, positional associations must occur first, at their normal position. Hence once a named association is used, the rest of the call must use only named associations.

·                 Use named parameter association in calls of infrequently used subprograms or entries with many formal parameters.

·                Use named association when instantiating generics.

·                Use named association for clarification when the actual parameter is any literal or expression.

·                 Use named association when supplying a non default value to an optional parameter.

·                An association can have a name that indicates the nature of the relationship. If a name is present, there can also be a triangle that points in the direction in which you should read the name.

Fig. 17 Named association

Unit-02/Lecture-06

Aggregation

·       Aggregation is a way of composing different abstractions together in defining a class.

 Ex. A car class can be defined to contain other classes such as engine class, seat class, wheels class etc. The car class can define an engine class as one of its attributes.

·       Objects could share other objects. When ford and fiat are using the same engine design, it is possible for them to share one engine design object. In such a case, engine design object is said to be nominally part of car design object.

·       It is a specialized form of Association where all object have their own lifecycle but there is ownership. This represents “whole-part or a-part-of” relationship. This is represented by a hollow diamond followed by a line.

Fig. 18 Notation for Aggregation

·         The relation between class picture and class point is represented graphically in figure . An arrow with a diamond at the tail represents aggregation. In this example, class picture has 0 or more points.

Fig. 19 Aggregation relation

·         An aggregation is a special kind of association—a “whole/part” relationship within which one or more classes are parts of a larger whole. A class can be aggregated to one or more other classes.

·         Using aggregation is an excellent way to establish a “pecking order” of complexity, with more complex classes aggregating less complex ones. For a system of any size, doing this can only help viewers of your models more easily understand the concepts that are important to them while enabling them to ignore concepts expressed at lower levels of detail.

·         An aggregation appears as a line with an open diamond at one end. The class next to the diamond is the whole class; the class at the other end of the line is the part class.

Fig. 20 Aggregation notation

·           Ex. A car object is an aggregation of engine, seat, wheels and other objects.

Fig. 21 A Car is an aggregation of other objects such as engine, seat, and wheel objects

Unit-02/Lecture-07

·      Types of Aggregation

There are three types of aggregation-

(i). Fixed- The particular numbers and types of the component parts predefined e.g. a car has one engine, four wheels, one steering wheels.

(ii). Variable- The number of levels of aggregation are fixed, but number of parts may vary, like the train.

(iii). Recursive- The object contains components of its own type, like the russian doll. A more specific example in C
++ is the ability for an object to contain a pointer of its own type, allowing it to send messages to other objects of the same class.

·         Example: Class C₁ aggregates class C₂ when at least one of its instance variables has type C₂. One gives the arity of the aggregation relation when it is known.

·         Program

#include<string>

#include<iostream>

using namespace std;

class Mobile

{

public: string IMEI_NO;

public: string Model;

public: Mobile(string im_no,string model)

        {

            IMEI_NO=im_no;

            Model=model;

        }

public: void show()

        {

            cout<<"IMEI no is == "<<IMEI_NO<<endl;

            cout<<"Model of your mobile is == "<<Model<<endl;

        }

};

class Person

{

    Mobile *mymobile;

public: string name;

public: string CNIC;

public: Person(string n , string c)

        {

            name=n;

            CNIC=c;

        }

public: void show()

        {

            cout<<"The name of the person is == "<<name<<endl;

            cout<<"The CNIC of a particular person is == "<<CNIC<<endl;

            mymobile->show();        

        }

public:void setmobile(Mobile * m1)

        {

            mymobile=m1;

        }

};

int main()

{

    Mobile *mob;

    mob=new Mobile("12589874458580","nokia 3310");

    Person myperson("Anonymous","37405-58925986-5");

    myperson.setmobile(mob);

    myperson.show();

    getchar();

    return 0;

}

Unit-02/Lecture-08

Delegation

·         Delegation allows the behaviour of an object to be defined in terms of the behaviour of another object. 

·         The term 'delegation' refers to the delegation of responsibility.

·         The primary emphasis of delegation is on message passing where an object could delegate responsibility of a message it couldn't handle to objects that potentially could (its delegates).

·         Delegation can be explicit or implicit. With explicit delegation an object can explicitly delegate a message to any other object it has knowledge of. With implicit delegation an object can explicitly designate another object as its "parent". Messages that are not understood by the receiving object are automatically (implicitly) delegated to this parent.

·         Delegation is alternative to class inheritance. Delegation is a way of making object composition as powerful as inheritance.

·         In delegation, two objects are involved in handling a request: receiving object delegates operations to its delegate. This is analogous to the child classes sending requests to the parent classes.

Ex. class A {

  void foo() {

    // "this" also known under the names "current", "me" and "self" in other languages

    this.bar();

  }

  void bar() {

    print("a.bar");

  }

};

class B {

  private delegate A a; // delegation link

  public B(A a)

  {

    this.a = a;

  }

  void foo() {

    a.foo(); // call foo() on the a-instance

  }

  void bar() {

    print("b.bar");

  }

};

a = new A();

b = new B(a); // establish delegation between two objects

Calling b.foo() will result in b.bar being printed, since this refers to the original receiver object, b, within the context of a.

Aggregation of objects

·            There is a closely related concept to composition called aggregation. In conversation the differences between composition and aggregation are often ignored. However, for the sake of accuracy, it will be covered here.

·            Just like composition, aggregation occurs when an object is composed of multiple objects. However, with composition, the internal objects (such as Leg , Seat and Back ) are owned by the main object ( Chair ). If you destroy the Chair , you also likely want the Leg , Seat and Back instances destroyed because they are a composition which, together, form a single Chair .

·            However, imagine you make a new type of Chair called DinnerChair . DinnerChair extends Chair but it also defines a property which refers to the person currently sitting in the DinnerChair . You could say that DinnerChair has a Person .

·            The Chair instance certainly doesn't own the Person and you probably shouldn't assume that the Person is destroyed if the Chair is destroyed. Further, the Person exists independent of the Chair . The Person can leave this chair and sit on another one. This independence makes a great deal of difference so this combination of objects is referred to as an aggregation instead of composition. When designing your applications, it is important to note that difference.

·            Usually, when using composition, the object instantiates the objects it has. Look at the Chair class above. You can see that Back , Seat , and Leg are instantiated in the Chair class. When using aggregation, the object does not instantiate the objects it has. Look at the code below. The DinnerChair class has a Person , but it does not instantiate Person .

Example:

package humans  {

 public class Person {

                               public function Person()   {}  

                                  }

 }

package chairs {

                import humans.Person;

        public class DinnerChair extends Chair   {

 public var person:Person;

 public function DinnerChair()

 { super();

      }

   }

 }