MCS 270 Spring 2014

MCS 270 Spring 2014

Object-Oriented Software Development

GUSTAVUS ADOLPHUS COLLEGE gustavus.edu

Today’s schedule

Basics of UML

Class Diagrams

MCS 270 Object-Oriented Software Development


Unified modeling language (UML)1980’s and 90’s - Several competing object-oriented

notations (Babel of notation)

1994 - Rumbaugh (one of our textbook’s authors) and Booch began working at IBM Rational to standardize their notations (OMT and Booch)

Result was Unified Modeling Language (UML)Rights owned by Object Management Group (OMG),

www.omg.org


http://www.omg.org/


Collection of notations representing software designs from three points of view:

Class modelState modelInteraction model

Generally need all three models to describe a systemNo single model describes everything in problem

domain

Unified modeling language (UML)



Class model: describes the static structure of objects and relationships in a system

Comprises object and class diagrams

State model: describes the dynamic aspects of objects and the nature of control in a system

Interaction model: describes how objects in a system cooperate to achieve broader results

Unified modeling language (UML)



Class Model



Good Class/Object DesignMeaningful concept or “thing” in an application domain

Has identity that does not encapsulate an object within itself, does not use attribute values of another object

Classes model relationships among things in domain



Good Class/Object DesignWhat is wrong with this

definition of a city class?


CitycityName : Stringpopulation : int

timeZone : StringairportName : StringairportCode : String


Good Class/Object DesignWhat is wrong with this

definition of a city class?


CitycityName : Stringpopulation : int

timeZone : StringairportName : StringairportCode : String

Answer: These attributes “hide” an object (i.e., an airport) that is meaningful in this domain


Question

Why might it be bad to encode one object as a collection of attribute values within another?



Question

Why might it be bad to encode one object as a collection of attribute values within another?

Potential for redundancy/inconsistencysome airports serve multiple citiessome cities served by no airportssome cities served by multiple airports

Operations over Airport objects may not need to know details associated with cities, such as population



Design tip

When designing a class:Apply the identity test to each attribute (does attribute belong

to class?)Never use an attribute to model another object attribute

UML notation helps enforce this discipline

Next: how do we model connections between objects, such as Cities and Airports?



Relationships among objects

Link: Physical or conceptual connection between objects

Most (not all) links relate exactly two objects

Association: Description of a group of links with common structure and semantics

A link is an instance of an association:Links connect objects Association describes set of potential links just as a

class describes a set of potential objects



Examples of links

Houston : City

cityName = “Houston, TX”population = 3000000

HOU : Airport airportCode = “HOU”

airportName = “Hobby”timeZone = “Central”

IAH : Airport airportCode = “IAH”

airportName = “Intercontinental”timeZone = “Central”

Serves

Serves



City

cityName : Stringpopulation : int

Airport

airportName : StringairportCode : String

timeZone : String

Serves1..* *

association name

multiplicities

Example of an association



Association End Names

Professor University

EmployerEmployee

End Names

WorksFor

Association Name

Association end name defines role of Object The class could play same or different roles in other

associations.Ex: Professor could also be classified as Teacher



Association End Names

Parent Child

Association end name is used for multiple references to same class

2 *

Person

child *

parent

0..2

Not advisable – only use one class to represent a person

Better



New abstraction: Generalization (Sub-Super)

Employeefirst_name : Stringlast_name : Stringhire_date : Datedepartment : int

Managerlevel : short

grou

p

*

0..1

This is the “is-a” relationRelates class to one that is “more

general”Open arrow points to Base ClassDerived class inherits all

attributes/operations of parentRelation is anti-symmetric and

transitive



Cheat Sheet

Book – front and back have summary of diagramsHandout – another summary with annotated explanations



Practice



Practice

Groups of two: Create a class model to describe undirected graphs. An undirected graph consists of edges connecting pairs of vertices.


An undirected graph with 6 nodes and 7 edges

en.wikipedia.org/wiki/Graph_(mathematics)


Practice

Groups of two: Create a class model to describe directed graphs. Here edges are directed from start to end.


A directed graph with 3 nodes and 3 edges

en.wikipedia.org/wiki/Graph_(mathematics)


Why do we use UML?

A Picture = Rich Data Encoding: we think in pictures and can relate info quickly in figures

Creative destruction: Diagrams are easily changed, programs not so much

Employment: UML is used in the workplace



Design tips

Use a UML diagram when:Brainstorming ideasSharing ideas with teamSaving blueprint of idea You can't find a bug in codeTeacher/manager requires it



Design tips

Keep it simple – only use UML when you need toManage Complexity: Draw diagrams that give most

value, e.g. do not draw a diagram for system with one or two classes. Likewise, do not put in all detail in first iteration.



Design tips

Good design practice: switch back and forth between what is said in the diagram and what is allowable in the code

Good Programming Practice: Plan code using links/associations rather than Java classes and methods.

This is good training in abstraction!



Summary

UML provides notations for modeling objects, classes, and associations of an application domainDiagrams represent models:

more abstract than codeuseful for explanation/documentation



Assignments

Friday - Read Chapter 5 in text.Homework: Chapter 3. Exercises 3.8, 3.11, and 3.12 Due Monday, Feb. 17


MCS 270 Spring 2014

Documents

Transcript of MCS 270 Spring 2014