Kate Gregory 1

Week 4

• Lab 2 due now

• Why document?

• Unified Modeling Language

• Class diagrams

Date Week Topic Hand Out Due Back Test

6-Sep-13 1 Administrivia / Overview / Motivation, benefits of OO

13-Sep-13 2 Use Cases Lab 1: Use cases

20-Sep-13 3 CRC Cards, collab graphs Lab 2: CRC cards lab 1 5%

27-Sep-134 start class diag   lab 2 5%  

4-Oct-13 5 Finish class diag, Associations Lab 3: Class Diag

11-Oct-13 6 Inh & Polymorphism / midterm review lab 3 5%

18-Oct-13 7 midterm Midterm 25%

25-Oct-13 Reading Break

1-Nov-13 8 Interaction diag / Design Patterns Lab 4: Interaction Diag    

8-Nov-13 9 Good Design / Modules & Packages / Deployment and component diagrams /Metrics / SOLID

Lab 5: Critiques lab 4 5%

15-Nov-13 10 State diagrams / Activity diagrams / Summary and Conclusion / The Future

22-Nov-13 11 Critiques critique lab (before class) 15%

29-Nov-13 12 Critiques

TBD Final Exam Final 40%

See Me

• At the break I need to see anyone who did not hand in Lab 1

Kate Gregory 3

Kate Gregory 4

Why document?

• To make yourself think

• To provide a reference– For yourself during this project– For your coworkers– For yourself after the project is over

• For your client

• For your manager

Kate Gregory 5

Documenting makes you think

• Does that class really know everything required for that calculation?

• Do these attributes belong together in a single class?

• Does that method really belong in that class?

Kate Gregory 6

Documentation is useful

• What were the methods in this class again?

• Is balance an integer or a floating point number?

• What are the arguments to print()?

• Is that class called Employee or Worker?

• When and for whom? – You now, others now, you later

Kate Gregory 7

Documentation releases money

• Clients approve cheques at milestones; documentation proves they’ve been reached

• Clients use documentation to confirm that a project is headed for success

• Managers use documentation to prove that work has been done and is headed for success

Kate Gregory 8

Unified Modeling Language

• A model is an abstract representation of a system, constructed to understand the system prior to building or modifying it.

• The unified modeling language (UML) is a language for specifying, constructing, visualizing, and documenting the software system and its components.

Kate Gregory 9

Who Unified What?

• Many authors developed notations for describing OO designs

• The unified modeling language (UML) was developed by Booch, Jacobson, and Rumbaugh and represents their agreement on notation

• It is now essentially the only formal notation used to document OO designs

Kate Gregory 10

Static Object Model

• A static model can be viewed as a "snapshot" of a system's parameters at rest or at a specific point in time.

• The classes’ structure and their relationships to each other, frozen in time.

• Contrast to dynamic techniques covered later in this course such as sequence diagrams

Kate Gregory 11

UML Class diagram

• The UML class diagram is the main static analysis diagram.

• Class diagrams show the static structure of the model.

• A class diagram is a collection of static modeling elements, such as classes and their relationships.

Kate Gregory 12

Class Structure

EmployeeName: stringMonthlySalary: intAnnualVacation: int

RaiseSalary (int)PrintPaycheque ()

Kate Gregory 13

Attributes and Methods• Identify attributes and methods by analyzing use cases

and CRC cards– CRC card may say “manages customer info”. You need to list

attributes that make up “customer info” (use cases will help) and decide which have get/set methods, which are affected by “services” the class offers

– Other responsibilities generally map to methods

• Attributes in top compartment– include the type (int, float) or meaning (dollars, degrees C) or

both

• Methods in bottom compartment – May or may not list arguments or return types here

Kate Gregory 14

Kate Gregory 15

Finding Attributes

• Attributes usually correspond to nouns followed by possessive phrases such as cost of the soup.

• Keep the class simple; only state enough attributes to define the object state.

• Attributes are less likely to be fully described in the problem statement.

Kate Gregory

Visibility

• Public + versus Private -– All attributes are private

– During analysis, typically all methods are public

• Public attributes and methods can’t be removed or changed without breaking another’s code

• Ignore protected, friendly, package, internal and other language-specific visibilities during analysis

Visibility examples

Kate Gregory 18

Gets and Sets• For a private variable called Description, you can add a

public method called GetDescription()– No arguments, return type is same as Description

– This method will need to be supported even if you change the private variable (or completely remove it) later

• You might not always have a public SetDescription() method

• Some variables are managed by other methods– Deposit() and Withdraw() change balance

– Does SetBalance() make sense?

• CRC cards remind you what other objects will need

Kate Gregory 19

Gets and Sets• Get means you are asking the object for

information: tell me your balance, tell me your description

• Set means you are telling the object a new value for some information

• Use consistent nomenclature– GetDescription(), get_name(), getAddress(), Age()

• Neither get nor set must map to a single attribute

Kate Gregory 20

No Derivable Attributes

• If age can be calculated from birth date, don’t store both age and birth date– extra memory consumed– extra work to keep them “in sync”

• Use get methods for both: one returns a simple value, the other calculates the answer

Kate Gregory 21

More on Derivable Attributes

• Choose arbitrarily

• At any time you can change your mind, change the code for the get methods, and break no other code

• If there’s a performance problem, you can flip which is stored and which is calculated, even once the application is in production

Sharing an attribute• Some attributes are specific to each instance

of the class– The balance in Steve’s account– The balance in Jane’s account

• Some are shared by all the instances of the class– Interest rate– Service charge amounts (eg $1 for a

withdrawal)

Kate Gregory

Kate Gregory

Class Attributes• No matter how many instances of the class

(objects) exist, exactly one memory slot is used for the class attribute

• The value is shared by all the objects• If it’s public, the value can be accessed even when

no objects of the class have been created• Avoids namespace issues and global variables

(especially useful in languages that don’t allow globals)

• Avoids synchronization issues

Kate Gregory

Class Methods• Often used to access class attributes

– Eg GetInterestRate(), SetInterestRate()

• Sometimes used to find/create instances• Or for utilities, arithmetic, etc

– you want to collect like methods together (sin, cos, tan, …) but no meaningful state for them to operate on

• Cannot access instance member variables – which instance’s ones would be used?

Kate Gregory

Notation

• Both class attributes and class methods are underlined on the class diagram

• Various languages have keywords that apply to class attributes and methods– static– Shared

static private int NumInvoices;

Class Attributes

• Underline class attributes or methods

• Rest of the notation is the same

Kate Gregory

Kate Gregory

Class attribute

• All contracts have the same commission

House for Sale Agent

Client

Contract

Expirydate

Commission: num

Kate Gregory 28

Finding Methods

• How am I going to be used?

• How am I going to collaborate with other classes?

• How am I described in the context of this system's responsibility?

• What do I need to know?

• What states can I be in?

Kate Gregory 29

Finding Methods

• Some methods are responsible for managing the value of attributes. Query, Update, Read, Write.

• Some methods provide the services of the class. CreditInterest, Deposit, PrintPayCheque.

• Use the responsibilities from the CRC cards

Kate Gregory 30

Methods to Manage Data• Class holds or knows a list of things?

– Probably need methods to add/edit/delete/find items• May need an initializer method to create a new

instance of the class with all required data– Constructor– Specify minimal values needed to create a valid instance

(can the name be blank? Can the birthdate be null?)• May need a method to clean up departing objects

– Destructor– Finalizer– Dispose

• Add these methods to the class diagram only if you see a need for them

Notation for Methods• Parameter names and types

• Return types

• Some show in/out also

Why parameter names?

Kate Gregory 32

Methods and Parameters can make the boxes big

Kate Gregory 34

Kate Gregory 35

Omit Details if you must• In class notation, either or both of the attribute and

operation compartments may be suppressed.

Boeing 737

Boeing 737

length: meterfuelCapacity: Galdoors: int

Kate Gregory 36

Current car: Car

Objects are not Attributes

• On a class diagram, do not list attributes that are objects.

• Every person has a car, but not:

Person

BirthDate: Date

travel ()

CurrentCar: Car

Kate Gregory 37

Prepare to record relationships

• If another object appears to be an attribute, it’s actually a related class

• Next lecture’s topics will include ways to record these relationships

Kate Gregory 38

Remember what class diagrams are for

• Reference– Names of classes– Names of methods– Parameters to methods– Names of attributes

• Excellent summary of decisions

• Visual understanding of the system

Kate Gregory 39

For Next Lecture

• Read UML notation for a class diagram

• Read ahead for more on relationships between classes

• This lecture and next will be covered by Assignment 3

– Due Oct 11th