Object-Oriented Analysis & Design UML Class Models Essay

Custom Student Mr. Teacher ENG 1001-04 25 March 2016

Object-Oriented Analysis & Design UML Class Models

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

2/7/00

G-3

2/7/00

G-4

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

2/7/00

G-5

A-1

Associations
• 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?

2/7/00

G-7

• 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

G-8

Multiplicity
• 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

Book

1 Is A Copy Of 1..*

Copy

• 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

LibraryMember

• Implementing associations depends on multiplicity
2/7/00

2/7/00

G-10

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

2/7/00

A-2

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

Department

1..* assigned to

1 1..*

1..* 1

Instructor

offers teaches 1..* 0..3

Course

Adjunct

Professor

– 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

2/7/00

G-17

2/7/00

G-18

A-3

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

2/7/00

G-19

2/7/00

G-20

Navigability
• 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

Dependencies
• 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

Student

advises

Professor

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

A-4

Stereotypes
• 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.

2/7/00

G-25

2/7/00

G-26

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

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

Interfaces
• 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

2/7/00

G-29

2/7/00

G-30

A-5

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

Constraints
• 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

husband

0..1

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

Department

* {subset}

*

member 1..* manager 1

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

Person
is taking / teaches student

2/7/00

G-35

Student

2/7/00

G-36

A-6

Example: Ticket Sales

Unused slides follow

2/7/00

G-37

2/7/00

G-38

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

Company

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

Person

2/7/00

G-40

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

*

3

Play
n ysI Pla

s at

City

*
4

Country 1 Represents

Zone
1

2

*

Referee

3

*
Assignment

*
Game

*

5

2/7/00

G-42

A-7

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

Show

• 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

2/7/00

G-43

2/7/00

G-44

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”

2/7/00

G-46

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

2/7/00

G-47

2/7/00

G-48

A-8

Free Object-Oriented Analysis & Design UML Class Models Essay Sample

A+

  • Subject:

  • University/College: University of Arkansas System

  • Type of paper: Thesis/Dissertation Chapter

  • Date: 25 March 2016

  • Words:

  • Pages:

Let us write you a custom essay sample on Object-Oriented Analysis & Design UML Class Models

for only $16.38 $13.9/page

your testimonials