PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams.
-
Upload
bernard-carr -
Category
Documents
-
view
216 -
download
0
Transcript of PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams.
PRJ566: PROJECT PLANNING AND MANAGEMENT
Class Diagrams
Class Design Analysis objects are things in the real
world, e.g invoice, registration form, sales person
Design objects are logical constructs which may map to objects in the real world but which find their existence only in code
Transformation Is the process of turning real world domain
abstraction into an object in the model.
Every significant object in the domain analysis is a candidate for being transformed into one or more design objects (Noun Filter)
Class Diagrams
A class diagram shows the existence of classes and their relationships in the logical view of a system
UML modeling elements in class diagrams Classes and their structure and behavior Association, aggregation, and inheritance
relationships Multiplicity and navigation indicators
Copyright © 1997 by Rational Software Corporation
Relationships Relationships provide a pathway for communication
between objects Sequence and/or collaboration diagrams are
examined to determine what links between objects need to exist to accomplish the behavior -- if two objects need to “talk” there must be a link between them
Types of relationships are: Association Aggregation
Copyright © 1997 by Rational Software Corporation
Relationships An association is a bi-directional connection
between classes An association is shown as a line connecting the related
classes An aggregation is a stronger form of relationship
where the relationship is between a whole and its parts An aggregation is shown as a line connecting the related
classes with a diamond next to the class representing the whole
Copyright © 1997 by Rational Software Corporation
Registration Manager
Math 101: Course
3: add student(joe)
RegistrationManager
Course
Finding Association Relationships
Relationships are discovered by examining interaction diagrams If two objects must “talk” there must be a
pathway for communication
Copyright © 1997 by Rational Software Corporation
Multiplicity and Navigation
Multiplicity defines how many objects participate in a relationships Multiplicity is the number of instances of one
class related to ONE instance of the other class For each association and aggregation, there are
two multiplicity decisions to make: one for each end of the relationship
Aggregations
An aggregation is a special kind of association the composition of a set of parts—a whole-
part relationship a “has a” or “consists of” relationship
Aggregations
Examples: An invoice has invoice items A company has contacts
Aggregate Class
Component Class
Aggregation Symbol
Invoice
InvoiceItem1..n
1
Company
ContactPerson
1..n
11
1..n1..n
1
Proxy Is an object in the design which represents
key aspects of a real world entity Also called a surrogate
First create proxy for all the actors in the system, e.g. customer, guest
Then for many of the real world objects, e.g, invoice, receipt, reservation
AggregationsEssential property The aggregate (Invoice) acts as a proxy for its
parts (InvoiceItem) This means the aggregate takes on operations
which are then propagated to the individual parts. (These operations don’t necessarily cause a change in the aggregate itself.)
Here adding a ContactPerson does not change the proxy (Company).
: UCControl : Company : ContactPerson
1: addCompanyContact(companyID, contactInfo)
2: addContact(contactInfo)
Here adding an InvoiceItem does change the proxy (Invoice). Its totals are updated.
: UCControl : Invoice : InvoiceItem
1: addToInvoice(invoiceID, itemID, qty, price)
2: add(itemID, qty, price)
3: updateTotals()
AggregationsAggregation vs Association In contrast to the association, the involved
classes do not maintain an equal relationship but the aggregate class assumes a special role for delegation of responsibility and leadership
Multiplicity in Aggregation Generally a 1:M relationship
The aggregate will be the 1 The parts will be the many 1…n
Aggregation Can describe a relationship where the parts
are existence-dependent on the whole. If the whole is deleted, the individual parts will
be deleted. If an individual part is deleted, the aggregate will
survive.
CompositionComposition is a strict form of aggregation. The life of the parts is subordinate to the
whole. The parts are generated together with the
aggregate or later. Parts are destroyed before the whole
Composition The component parts depend on the aggregate
for existence—delete the aggregate and the components disappear (this is called a cascading delete)
CompositionWhich of these might be composition? An invoice has invoice items A company has contacts A catalogue has catalogue items An MSWord document style has a font, a
language, a paragraph control, and so on…
When we delete Invoice, does InvoiceItem disappear? Yes! It has no meaning without Invoice.
To indicate a composition, the diamond is coloured black.
Invoice
InvoiceItem
1..n
1
1..n
1
When we delete Company, does ContactPerson disappear? Yes! It has no meaning without Company.
ContactPerson
Company
1..n
1
1..n
1
When about Catalogue and CatalogueItem?
If CatalogueItem belongs to only one catalogue and it is the intersection between that Catalogue and an Item then yes, it would disappear if Catalogue were deleted and we would have a composition relationship. But note the Item itself would not disappear!
Catalog
ItemCatalogItem
1..n
1
1..n
1
0..n 10..n 1
This sequence diagram shows the proxy relationship of Catalogue to CatalogueItem
: CatalogControl
: Catalog : CatalogItem : Item
1: initiateGetItem()
2: getItem()
4: initiateAddItem(catID, itemInfo)
3: *item list
5: addCatItem (catID, itemInfo)
6: addCatItem
This sequence diagram shows an example of the cascading delete that identifies Composition.
: CatalogControl
: Catalog : CatalogItem
1: initiateDeleteCat(catID)
2: deleteCat(catID)
AggregationsAggregation vs Association Useful in modeling—an aggregation shows
where there is higher binding between classes which in turn makes models easier to understand
Aggregation helps determine implementation (e.g. arrays, etc.)
When in doubt use an association
Copyright © 1997 by Rational Software Corporation
Inheritance
Inheritance is a relationships between a base class and its derived classes
There are two ways to find inheritance: Generalization Specialization
Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy
Inheritance Generalization
Identify similar structure and behaviour among classes
Specialization Identify a parent class--how can it be
“specialized” for use in other parts of the system?
Inheritance Inheritance is a “generalization” relationship The base class (parent class, super class)
carries a certain set of characteristics (attributes, operations, relationships)
The derived classes (child classes, sub classes) inherit those characteristics plus they have some of their own
Inheritance A child class “is a” special type of the more
general parent class E.g.
“A video is a type of library item” “A part-time student is a type of student” “A reserve item screen is a type of library
screen”
Why Inheritance?Why do we care about inheritance? Less duplication More reusability More standardization Less change impact Classes are more focused
Inheritance Structures
showing inheritance are called Inheritance Hierarchies
LibraryItem
itemIDitemTitleitemDescription
addItem()getItem()retireItem()
LibraryBook
ISBNauthorpublisher
LibraryCD
artistrecordingCompanynumberOfCDsnumberOfTracks
LibraryVideo
productionCompanynumberOfVideosvideoLength
How do you find inheritance? Look for classes that share many operations,
attributes (But be careful! Don’t create false inheritance!)
Look for actions or text (i.e. in specs) that imply that there are several types of objects in a class--investigate further.
Copyright © 1997 by Rational Software Corporation
Inheritance
GeneralizationThe capability to create base classes that
encapsulate structure and behaviour
common to several classes.
InheritanceGeneralization: Here we see similar
structure and behaviour among
classes
LibraryItem
itemIDitemTitleitemDescription
addItem()getItem()retireItem()
LibraryBook
ISBNauthorpublisher
LibraryCD
artistrecordingCompanynumberOfCDsnumberOfTracks
LibraryVideo
productionCompanynumberOfVideosvideoLength
InheritanceGeneralization: Now we create a parent class
LibraryItem
InheritanceGeneralization: Now we move all common
elements from children to parent and we draw the inheritance relationship
LibraryItem
itemIDitemTitleitemDescription
addItem()getItem()retireItem()
LibraryBook
ISBNauthorpublisher
LibraryCD
artistrecordingCompanynumberOfCDsnumberOfTracks
LibraryVideo
productionCompanynumberOfVideosvideoLength
Copyright © 1997 by Rational Software Corporation
Inheritance
SpecializationThe ability to create derived classes that represent
refinements to the base class—typically structure and behaviour are added to the new derived class.
Inheritance
In Rational Rose you need to set Parent attributes as PROTECTED instead of private
Inheritance
You will see the inherited operations and attributes only in the specification window not in class diagrams
Inheritance A critical aspect of public inheritance is that
it should model specialization/ generalization and nothing else.
Base Classes and Derived Classes Derived classes must know who their base
class is, and they depend on their base class.
Base classes should know nothing about their derived classes.
Class Design Build the inheritance hierarchy Map use cases to object interaction Delegate every responsibility of the system
to a specific object Fully understand the collaboration between
objects Create a blueprint for your implementation