Haven't found the Essay You Want?
For Only $12.90/page

Object-Oriented Analysis & Design UML Class Models Essay

Developing Class Models
• Class diagrams developed iteratively
– Details added over time during lifecycle – Initially: missing names, multiplicities, other details

Class Model Perspectives (cont’d)
• Specification
– Interfaces defined: a set of operations – But, each implementation class can include more than one interface – A given interface can be shared by more than one class – Sometimes known as a “type”

Some define particular perspectives for class models:
– Conceptual – Specification – Implementation

• Implementation
– Direct code implementation of each class in the diagram – A blue-print for coding

Conceptual perspective
– Represents concepts in the domain – Drawn with no regard for implementation (language independent) – Used in requirements analysis





Documenting Your Objects
• Need some kind of record of your definitions
– Your white-board? – A simple glossary – A data dictionary (perhaps in a CASE tool) • •

Classes in UML Diagrams
Attributes in middle Operations at bottom
– Can be suppressed. (What level of abstraction?)

Book +title : string

• • •

• What to define?
– Attributes, operations for each class – Also relationships between classes

• Can you define classes of related objects?
– Inheritance, Java interfaces

Attribute syntax: name : type = default Operation syntax: name ( params) : return type Visibility + public – private # protected etc. nothing? Java’s defaultpackage?

Book -title : string +borrow(c : Copy) : void +copiesOnShelf() : int +getTitle() : string 2/7/00 G-6




• For “real-world objects” is there an association between classes? • Classes A and B are associated if: – An object of class A sends a message to an object of B – An object of class A creates an instance of class B – An object of class A has an attribute of type B or collections of objects of type B – An object of class A receives a message with an argument that is an instance of B (maybe…) • Will it “use” that argument?

More on Associations
• Associations should model the reality of the domain and allow implementation • Associations are between classes – A link connects two specific objects – Links are instances of associations – Note we could draw an object diagram to show objects and links • But often interaction diagrams are more useful for modeling objects

• Does an object of class A need to know about some object of class B?



• Note: In practice, early in modeling, we may not name associations • Note: One may choose to have a dynamic view associations: if at run-time two objects exchange messages, their classes must be associated 2/7/00


• Also known as cardinality • Objects from two classes are linked, but how many? – – – – An exact number: indicated by the number A range: two dots between a pair of numbers An arbitrary number: indicated by * symbol (Rare) A comma-separated list of ranges

Examples of Associations
• From a Library catalog example • One book has 1 or more copies • One copy is linked to exactly one book • Should there be two associations: borrows and returns? • One copy is borrowed by either zero or one LibraryMember G-9


1 Is A Copy Of 1..*


• Examples: 1 1..2 0..* 1..* * (same as 0..* but…) • Important: If class A has association X with class B – The number of B’s for each A is written next to class B – Or, follow the association past the name and then read the multiplicity

0..* Borrows/Returns 0..1


• Implementing associations depends on multiplicity



Generalization and Inheritance
• You may model “inheritance” early but not implement it – Generalization represents a relationship at the conceptual level – Inheritance is an implementation technique

Aggregation and Composition
• Again, just a specific kind of association between classes – An object of class A is part of an object of class B – A part-whole relationship

• • •

Generalization is just an association between classes
– But so common we put a “triangle” at the superclass

Note this is a relationship between classes
– So no multiplicities are marked. Why not?

Inheritance may not be appropriate when it’s time to implement – Objects should never change from one subclass to another – Composition can be used instead

• Put a diamond on the end of the line next to the “whole” – Aggregation (hollow diamond): really no semantics about what this means! – Composition (solid diamond): a stronger relationship G-11 2/7/00 G-12



Aggregation and Composition (cont’d)
• Composition
– The whole strongly owns the parts – Parts are copied (deleted, etc.) if the whole is copied (deleted, etc.) – A part cannot be part of more than one whole – Mnemonic: the stronger relationship is indicated by the stronger symbol (it’s solid)

Example 1: University Courses
• Some instructors are professors, while others have job title adjunct • Departments offer many courses, but a course may be offered by >1 department • Courses are taught by instructors, who may teach up to three courses • Instructors are assigned to one (or more) departments • One instructor also serves a department chair G-13 2/7/00 G-14

• Aggregation and composition associations are not named • They do have multiplicities • They can be used too often. If in doubt, use a 2/7/00 “plain”, named association.

Class Diagram for Univ. Courses
chairs 0..1

Example 2: Problem Report Tool
• A CASE tool for storing and tracking problem reports


1..* assigned to

1 1..*

1..* 1


offers teaches 1..* 0..3




– Each report contains a problem description and a status – Each problem can be assigned to someone – Problem reports are made on one of the “artifacts” of a project – Employees are assigned to a project – A manager may add new artifacts and assign problem reports to team members

• Note this implies adjuncts can be chairs
2/7/00 G-15 2/7/00 G-16

Class Diagram for Prob. Rep. Tool
0..* Employee +name : string 1 1 Responsible For 0..n Manager Developer Problem Report 0..n About 1..* Assigned To Project +name : string Artifact 1 0..* +name : string +status : enum

Example from Fowler

1 1 Managed By 0..* History Log 0..n

History Entry -when : Date -whatDone : string

Code Bug Report






Objects, Object Diagrams
• Objects drawn like classes, but names for all instances underlined • Objects may be “anonymous” • Attributes are given values

Class Attributes, Operations
• Recall in Java and C++ you may have class attributes and class operations – keyword static used – One attribute for all members of class – An operation not encapsulated in each object, but “defined in” that class’ scope

• In UML class diagrams, list these in the class box’s compartments, but underline them





• Some call this “direction of visibility” • Does each class really store a reference to each other? • Do we need to decide this now? (When is “now”?) • We can add arrows to associations to indicate this – What does a line with no arrows mean?

More on Associations: Navigability
• One reason for having an association between classes: Messages between objects of those classes • But, often “knowledge” indicated by association is only in one direction – Example: In a computer system, a User needs access to his/her Password – From a Password object we should not be able to get back to a User!

• Note: Often ignored until design!
2/7/00 G-21 2/7/00 G-22

More on Associations: Roles
• Review:
– Associations have an optional name – Name might have a “direction” indicator

• Dependency: A using relationship between two classes
– A change in the specification of one class may affect the other – But not necessarily the reverse

• But, direction or semantics often easier to understand if we simply but a role name at one or both ends of the line

• Booch says: use dependencies not associations when one class uses another class as an argument in an operation. • Often used for other things in UML: A general relationship between “things” in UML – Often use a stereotype to give more info




advisee Student advisor Professor

• Uses: binding C++ class to template; Java interfaces; a class only instantiates objects (a factory) 2/7/00 G-23 2/7/00 G-24


• Extends the “vocabulary” of UML • Creates a new kind of building block –
Derived from existing UML feature – But specific for current problem

Stereotypes (cont’d)
• UML predefines many:
– Classes: , , , , – Constraints: etc. – Dependencies: , – Comments: , – Packages: , (maybe classes, too)

• Also, some pre-defined stereotypes • UML allows you to provide a new icon! • Syntax: Above name add inside guillemets (French quotes) • Again, used to provide extra info about the UML modeling construct

• Or, create your own if needed.





Class Categories
• You can use stereotypes to organize things by category within a class box

Stereotype Example
«Interface» IStringifiable Module

stringify() : string «use» prints

• IStringifiable is not a class
– Interface (as in Java) – Module implements this interface


• Printer depends on what’s in the interface
2/7/00 G-27 2/7/00 G-28

• Interface: specifies a set of operations that any class implementing or realizing the interface must provide – More than one class may realize one interface – One class may realize more than one interface – No attributes, and no associations

Interface Example Diagram

• Notation:
– Use with a class; list operations – “Lollipop” notation






Classes Realize an Interface
• “Realizes” AKA implements, supports, matches, etc. • This means that class provides all the operations in the interface (and more?) – Remember, no implementation in interface definition

Tagged Values, Properties
• Every modeling element in UML has its set of properties
– Classes have: name, attributes, operations, etc. – What if we want to add our own? (e.g. author?)

• Realization shown with dashed line, hollow arrow
– Like dependency plus generalization

• Why have this?
– Just factor out common functionality?

• Just add text in curly-brackets, with name=value, and put below the element name • Note: These tell you something about the model, not about the final system to be built! – Often used for code generation, version control, etc.

• Better “pluggability”, extensibility

• Example: {abstract} classes instead of italics
2/7/00 G-31 2/7/00 G-32

Abstract Classes
• Implementation not provided for one or more operations
– So, a subclass must extend this to provide implementations

• Conditions that restrict values, relationships,… • Can be free text or Object Constraint Langauge (OCL) (see textbook) • Recommendation: Use sparingly! • This example: from UML User Guide, p. 82 Portfolio Corporation

{secure} {or} BankAccount

• How to show this in UML?
– Either italics for class name and operations – Or, use {abstract} property by name

Person gender : {female, male}

• An abstract class with no attributes and all abstract operations is effectively an interface – But Java provides a direct implementation
2/7/00 G-33



0..1 wife

{self.wife.gender = female and self.husband.gender = male}
2/7/00 G-34

Constraints and Semantics
• Example from UML User Guide, p. 88 • A dependency and a constraint used • Shows Manager must be one of Members of a Department • One link (say, Jane-toDeptA) is a subset of all links between Persons and DeptA

Derived Associations
• Often an association in a model be deduced from the existence of one or more other associations • Do we show it? Is it redundant? • Option: Draw it but mark it as derived – Use a slash symbol / before name


* {subset}


member 1..* manager 1

• Can use slash in front of class attributes too!
Course teaches Professor

is taking / teaches student







Example: Ticket Sales

Unused slides follow





Association Classes
• Recall that qualified associations really mean that the link between two objects has an attribute • Often associations are “first-class” things – They have a life-time, state, and maybe operations – Just like objects!

Association Class Example


0..* employer Job description : string dateHired : Date salary : Money

employee 1..*

• Association classes
– Same name as the association because… – They represent the same thing! 2/7/00 G-39




World Cup Example
• We need a system to handle the World Cup. Teams represent countries and are made up of 22 players. • Countries qualify from zones, where each zone is either a country or a group of countries. • Each team plays a given number of games in a specific city. Referees are assigned to games. Hotel reservations are made in the city where the teams play. 2/7/00 G-41

World Cup Problem: Class Model
ts sen pre Re
0… 1

Team 2 * Qualifying Unit 22 Player 1

Hotel Reservation



n ysI Pla

s at



Country 1 Represents













Qualified Associations
• Equivalent to programming language idea of lookup, map, dictionary, associative array, etc. • An object is associated with some number of other
objects in a class – How do we identify which one we want given that association?

Qualified Association Examples:
0..1 Show 1 sales Ticket


• The qualifier documents attribute(s) used to identify which object – The “key” for “lookup”

perf: Date, seat: Number

0..1 1 sales Ticket

• Formally, these are attributes of the association
0..1 RepairDesk jobID: int ReturnedItem





Identifying Classes for Requirements
• From textual descriptions or requirements or use cases, how do we get classes? • Various techniques, and practice! – Key Domain Abstractions: • Real-world entities in your problem domain – Noun identification • Not often useful (but easy to describe)

Noun Extraction
• Take some concise statement of the requirements • Underline nouns or noun phrases that represent things – These are candidate classes

• Object or not?
– – – – Inside our system scope? An event, states, time-periods? An attribute of another object? Synonyms?

• Remember: external view of the system for requirements
– Not system internals, not design components!
2/7/00 G-45

• Again, looking for “things”



Identifying Good Objects
• Don’t forget from earlier:
– attributes and operations are encapsulated in objects – objects have a life-cycle

Actors and Classes
• In some diagrams, actors represented as class boxes
– With special stereotype above class name:

• Also, don’t worry about user interface
– Think of user-commands as being encapsulated in the actors

• Consider:
– Collections, things in a container – Roles – Organizations

• UML allows special graphical symbol (e.g. a stick figure) to replace stereotyped classes – See Richter, p. 53






Essay Topics:

Sorry, but copying text is forbidden on this website. If you need this or any other sample, we can send it to you via email. Please, specify your valid email address

We can't stand spam as much as you do No, thanks. I prefer suffering on my own