Association & Aggregation Lecture-9. Vehicle Car Tyre Engine Bus Passenger.

Slides:



Advertisements
Similar presentations
Nested state diagrams:Problems with flat state diagram
Advertisements

1 CIS224 Software Projects: Software Engineering and Research Methods Lecture 9 Object, Package, Component and Deployment Diagrams (Based on Fowler, 2004,
Computer Science Dept. Fall 2003 Object models Object models describe the system in terms of object classes An object class is an abstraction over a set.
Object-oriented modeling Class/Object Diagrams
Stereotypes Stereotypes provide the capability to create a new kind of modeling element. –They can be used to classify or mark modeling elements. –A type.
Inheritance Inheritance Reserved word protected Reserved word super
Software Engineering COMP 201
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Inheritance. Extending Classes It’s possible to create a class by using another as a starting point  i.e. Start with the original class then add methods,
Class Relationships. In systems with multiple classes, it can become difficult to keep track of relationships  e.g. the Student class requires the Course.
Essentials of interaction diagrams Lecture 23 & 24.
Essentials of interaction diagrams Lecture Outline Collaborations Interaction on collaboration diagrams Sequence diagrams Messages from an object.
What is UML? A modeling language standardized by the OMG (Object Management Group), and widely used in OO analysis and design A modeling language is a.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Unified Modeling Language (UML)
© Copyright Eliyahu Brutman Programming Techniques Course.
MORE ON CLASS MODELS Lecture Outline Aggregation and composition Roles Navigability Qualified association Derived association Constraints Association.
©TheMcGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 1 Introduction to Object-Oriented Programming and Software Development.
Modelling classes Drawing a Class Diagram. Class diagram First pick the classes –Choose relevant nouns, which have attributes and operations. Find the.
© 2006 Pearson Education Making Objects 1 of 19 MAKING OBJECTS Views of a Class Defining Your Own Class Declaring Instance Variables Declaring Methods.
SE-565 Software System Requirements More UML Diagrams.
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
CET203 SOFTWARE DEVELOPMENT Session 1B Modelling and the Theory of Inheritance.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Unified Modeling Language
Relationships. In the Interaction diagrams, we began to look at how classes communicate with one another. Now, we'll focus on the relationships between.
UML Unified Modeling Language. What is UML? Unified Modeling Language (UML) is a standardized, general-purpose modeling language in the field of software.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 2: Modelling.
OBJECT ORIENTED PROGRAMMING LECTURE 12 Instructor: Rashi Garg Coordinator: Gaurav Saxena.
CSCI-383 Object-Oriented Programming & Design Lecture 9.
Java Class Syntax CSIS 3701: Advanced Object Oriented Programming.
Chapter 5 Entity–Relationship Modeling
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
Stephenson College DP 98 1 Associations & Aggregations by Derek Peacock.
R McFadyen Chapter 7 Conceptual Data Modeling.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 - Domain Classes.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 03. Classes,
Modeling system requirements. Purpose of Models Models help an analyst clarify and refine a design. Models help simplify the complexity of information.
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
UML Class Diagram Trisha Cummings. What we will be covering What is a Class Diagram? Essential Elements of a UML Class Diagram UML Packages Logical Distribution.
1 Object Oriented Design and UML Class Relationships –Dependency –Aggregation –Interfaces –Inheritance Interfaces Reading for this Lecture: L&L 6.4 – 6.5.
BCS 2143 Object Oriented Design Using UML. Objectives Objects Interactions Finding Classes Relationship Between Classes Attribute and Operation Class.
Object Oriented Software Development
Design Model Lecture p6 T120B pavasario sem.
Object Oriented Analysis: Associations. 2 Object Oriented Modeling BUAD/American University Class Relationships u Classes have relationships between each.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
CSCI-383 Object-Oriented Programming & Design Lecture 10.
CS3773 Software Engineering Lecture 06 UML State Machines.
Inheritance CSI 1101 Nour El Kadri. OOP  We have seen that object-oriented programming (OOP) helps organizing and maintaining large software systems.
UML Part 1: Class Diagrams. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and notations presented.
1 Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L 9.1 – 9.4.
INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Chapter 5 Classes and Methods II Lecture Slides to Accompany An Introduction to Computer Science Using Java (2nd Edition) by S.N. Kamin, D. Mickunas, E.
Chapter 7 Classes and Methods III: Static Methods and Variables Lecture Slides to Accompany An Introduction to Computer Science Using Java (2nd Edition)
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
Inheritance and Aggregation Lecture References Inheritance from Lecture Notes on Object Oriented Programming with C++. Available at
Class Diagram Lecture # 1. Class diagram A Class Diagram is a diagram describing the structure of a system shows the system's classes Attributes operations.
TK2023 Object-Oriented Software Engineering CHAPTER 11 CLASS DIAGRAMS.
1 Kyung Hee University Interaction Diagrams Spring 2001.
2-1 © Prentice Hall, 2004 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Unified Modeling Language (UML)
Object-Oriented Analysis and Design
Software Engineering Lecture #11.
Lecture 22 Inheritance Richard Gesick.
Class Diagrams Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application.
Object Oriented System Design Class Diagrams
COP 3330 Object-oriented Programming in C++
Presentation transcript:

Association & Aggregation Lecture-9

Vehicle Car Tyre Engine Bus Passenger

Vehicle Car Tyre Engine Bus Passenger

Association So far we have seen objects being sent messages within a 'main' function. However this does not address how objects can communicate with each other. In order to do this we need to have links between objects which allow them to communicate

Association At this level of class design this is know as an association and these come in three types  A one to one association where one object of a class has a link to one other object of a class  A one to many association, where one object of a class has links with many objects of a particular class  A many to many association, where many objects of one class have links with many objects of a particular class. Associations more frequently occur between objects of different classes, but also occur between different objects of the same class

How to draw Associations (UML Notation) A one-to-one association A one-to-many association A many-to-many association numbers or ranges can be used if known: a 'zero or 1' to 'exactly 10' associations a text label with direction indicator associates with ** *

Direction of message passing Associations are generally assumed to be bi-directional. i.e. a message can pass in both directions between objects. However in implementation this doesn't have to be the case as shown in the example bellow switchLight bulb controls

Association in applications The previous example doesn't bear much relevance to a real software application The following example shows a more realistic diagram Lecturer Module Teaches ContractClassroom Teaches toTakes place in The Association in a timetable example * * *

Aggregation v. Inheritance A classification hierarchy shows how classes inherit from each other and shows the position in the hierarchy as 'a kind of' relationship. i.e. An Estate car is 'a kind of' car and a car is 'a kind of' vehicle. Associations also form hierarchies but they are very different from inheritance. These are described by the following terms Aggregation Composition Part-Whole A Part Of (APO) Has a Containment

Aggregation v. Inheritance (2) In this type of hierarchy, classes do not inherit from other classes but are composed of other classes This means that an object of one class may have it's representation defined by other objects rather than by attributes. The enclosing class does not inherit any attributes or methods from these other included classes. This means that this is a relationship (association) between objects. An object of the enclosing class is composed wholly or partly of objects of other classes Any object that has this characteristic is know as an aggregation

Aggregation v. Containers The commonly used term for this type of relationship is 'containment' However this is semantically different for the idea of a container  In 'containment', a composition hierarchy defines how an object is composed of other objects in a fixed relationship. The aggregate object cannot exist without it's components, which will probably be of a fixed and stable number, or at least will vary within a fixed set of possibilities.  A 'container' is an object (of a container class) which is able to contain other objects. The existence of the container is independent of whether it actually contains any objects at a particular time, and contained objects will probably be a dynamic and possibly heterogeneous collections (i.e. the objects contained may be of many different classes).

A Containment Example For Example A Car will have an engine compartment with an integral component :- the engine This is a containment relationship as the engine is an essential part of a car Another part of a car is the boot. What is in the boot does not effect the integrity of the car (i.e. what the car is) The boot can contain many different types of objects (tools, shopping etc) but this does not affect the car object. Therefore the boot is a container existing independently of it's contents.

Composition: 'parts explosion' A common analogy for composition is the exploded parts diagram For example a clock can be thought of of being composed of the following parts  Case, Works, Face, Minute Hand, Hour Hand These objects may exist in many layers for example the works is an object made up of many other objects (gears, springs etc)

Aggregation or composition? An object which comprise parts of a larger object may or may not be visible from outside the object. Composition implies that the internal objects are not seen from the outside, Whereas aggregation shows that the object may be directly accessed and is visible from outside the object. In UML notation this is draw with a Diamond shape and is Filled in to indicate a composition Outlined (left blank) for an aggregation This is shown in the following Diagram

UML Diagram of Clock aggregation Clock FaceWorksHand battery

Properties of Aggregations There are certain properties associated with objects in an aggregation that make them different from normal associations. These may be classed as follows Transitivity If A is part of B and B is part of C then A is part of C Antisymmetry If A is part of B, then B is not part of A. (i.e. not a simple association) Propagation The environment of the part is the same as that of the assembly

Properties of Aggregations (2) Aggregation can be fixed, variable or recursive These may be classed as follows Fixed The particular numbers and types of the component parts are pre-defined. Variable The number of levels of aggregation is fixed, but the number of parts may vary Recursive The object contains components of its own type. (like a Russian doll)

Aggregation C++ Syntax There are two basic ways in which associations and aggregations are implemented The first approach is used to create fixed aggregations (objects inside The second is used to create variable aggregations to make programs more flexible 1.Objects contain Objects 2.Objects contain pointers to Objects

Implementing fixed aggregations In C++ fixed aggregations are implemented by defining classes with objects of other classes inside of them. For example a simplified aircraft set of components could contain the following PortWing, StarbordWing Engine1, Engine2 Fuselage Tailplane All of which will be contained as private elements of the class Aircraft as shown in the following class.

Aircraft Class Each of the separate classes within the Aircraft class will have their own methods which can be called within the Aircraft class as shown below class Aircraft { private : PortWing port_wing; StarboardWing starboard_wing; Engine engine1,engine2; Fuselage fuselage; Tailplane tailplane; };

Example of Methods Aircraft Class Activities of some composing objects will depend on the state of others void Aircraft::turnToPort() { port_wing.elevatorUp(); starboard_wing.elevatorUp(); port_wing.aileronUp(); starboard_wing.aileronDown(); tailplane.rudderLeft(); }

Example of Methods Aircraft Class This is an example of a propagation as the state of the Aircraft propagates to the state of the door. void Aircraft::openDoors() { if(engine1.getSpeed()>IDLE||engine2.getSpeed()>IDLE) { //don't open doors } else fuselage.openDoors(); }

Constructing Aggregations with parameters With aggregation we sometimes have to call parametrised constructors When an object is created, any contained objects must be created at the same time. Some objects may not have parametrised constructors so this is easy If some objects do need parameters in the constructors some mechanism is required to pass the parameter to the associated objects. This is done using the colon (:) operator as shown in the following example

Car Class Comprised of wheel and engine class Wheel { private: int diameter; public: Wheel(int diameter_in){ diameter = diameter_in; } int getDiameter() { return diameter; } }; class Engine { private: int cc; public: Engine(int cc_in) { cc = cc_in; } int getCC()return cc; } };

Car Class class Car { private: Wheel nearside_front, offside_front, nearside_rear, offside_rear; Engine engine; int passengers; public: Car(int diameter_in, int cc_in, int passengers_in); void showSelf(); };

Car Class Car::Car(int diameter_in, int cc_in, int passengers_in) : nearside_front(diameter_in), offside_front(diameter_in), nearside_rear(diameter_in), offside_rear(diameter_in), engine(cc_in) { passengers = passengers_in; }