Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency

Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency

Ratings: (0)|Views: 1,652 |Likes:
Published by tarunkusum

More info:

Categories:Topics, Art & Design
Published by: tarunkusum on Aug 27, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency
 June 26th, 2010
These terms signify the relationships between classes. These are the building blocks of object oriented programming and very basic stuff. But still for some, these terms look like Latin and Greek. Justwanted to refresh these terms and explain in simpler terms.
Association is a relationship between two objects. In other words, association defines the multiplicity between objects. You may be aware of one-to-one, one-to-many, many-to-one, many-to-many all thesewords define an association between objects. Aggregation is a special form of association. Compositionis a special form of aggregation. 
A Student and a Faculty are having an association.
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 themspecified which object contains the other object. Aggregation is also called a “Has-a” relationship. 
Composition is a special case of aggregation. In a more specific manner, a restricted aggregation iscalled composition. When an object contains the other object, if the contained object cannot existwithout the existence of container object, then it is called composition. 
A class contains students. A student cannot exist without a class. There exists composition between class and students.
Difference between aggregation and composition
Composition is more restrictive. When there is a composition between two objects, the composedobject cannot exist without the other object. This restriction is not there in aggregation. Though oneobject can contain the other object, there is no condition that the composed object must exist. Theexistence of the composed object is entirely optional. In both aggregation and composition, direction ismust. The direction specifies, which object contains the other object.
A Library contains students and books. Relationship between library and student isaggregation. Relationship between library and book is composition. A student can exist without alibrary and therefore it is aggregation. A book cannot exist without a library and therefore its a
composition. For easy understanding I am picking this example. Don’t go deeper into example and justify relationships!
Abstraction is specifying the framework and hiding the implementation level information.Concreteness will be built on top of the abstraction. It gives you a blueprint to follow to whileimplementing the details. Abstraction reduces the complexity by hiding low level details.
A wire frame model of a car.
Generalization uses a “is-a” relationship from a specialization to the generalization class. Commonstructure and behaviour are used from the specializtion to the generalized class. At a very broader levelyou can understand this as inheritance. Why I take the term inheritance is, you can relate this term verywell. Generalization is also called a “Is-a” relationship. 
Consider there exists a class named Person. A student is a person. A faculty is a person.Therefore here the relationship between student and person, similarly faculty and person isgeneralization.
Realization is a relationship between the blueprint class and the object containing its respectiveimplementation level details. This object is said to realize the blueprint class. In other words, you canunderstand this as the relationship between the interface and the implementing class. 
A particular model of a car ‘GTB Fiorano’ that implements the blueprint of a car realizes theabstraction.
Change in structure or behaviour of a class affects the other related class, then there is a dependency between those two classes. It need not be the same vice-versa. When one class contains the other classit this happens. 
Relationship between shape and circle is dependency.
Visual Case Tool - UML Tutorial
2. The Use Case Diagram
In many design processes, the use case diagram is the first that designers will work with when starting a project.This diagram allows for the specification of high level user goals that the system must carry out. These goalsare not necessarily tasks or actions, but can be more general required functionality of the system.
Use Case
More formally, a
use case
is made up of a set of 
. Each scenario is a sequence of steps thatencompass an interaction between a user and a system. The use case brings scenarios together thataccomplish a specific goal of the user.A use case can be specified by textually describing the steps required and any alternative actions at each step.For example, the use case for searching a web for a keyword might be shown as:1. Customer enters the keyword2. Customer clicks the search button3. The search is executed4. The results are shownAlternative: Search FailedIf the search fails at 3, then the user is redirected back to the search screen at step 1In Visual Case, you can specify the steps of a use case in its description field. Simply right-click on a use caseand select properties. You can then run a report and print or export the results to html or ascii text. Together, thereport and the diagrams will include all of the details of the use case - their specific scenarios and the actors thatcarry them out.
use case diagram
allows a designer to graphically show these use cases and the actors that use them. An
is a role that a user plays in the system. It is important to distinguish between a user and an actor (better thought of as a role). A user of the system may play several different roles through the course of his, her or its job (since an actor may be another system). Examples of actors are salesperson, manager, support person, andweb store system. It is possible that the same person may be a sales person and also provide support. Whencreating a use case model, we are not concerned with the individuals, only the roles that they play.
On a use case diagram, associations are drawn between actors and use cases to show that an actor carries outa use case. A use case can be carried out by many actors and an actor may carry out many use cases.
In the above diagram, the actors are shown as the green stick figure shapes on the left, the use cases are theblue ellipses, and the associations between them are represented by the connecting lines. The developer and

Activity (5)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
bhatt_chintan7 liked this
praven636 liked this
syriluit liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->