1

Overview of Analysis

Analysis is an iterative process… make a ‘first cut’ conceptual model and then iteratively refine it as your understanding of the problem increases.

Steps in the analysis process 1. Identifying the classes

2. Identifying the classes attributes and responsibilities

3. Identifying relationships and collaborations between classes

2

Couple of rules

good classes provide adequate

encapsulation

responsibilities should be well

distributed among all classes (there

should not be one main class that does

almost everything)

3

Case study: a resort reservation

system

Design the software to handle reservations at Blue Lake Resort. The resort comprises several cottages and two meeting rooms. Cottages can comprise from one to three beds. The first meeting room has a capacity of 20 persons, the second, 40 persons. Cottages can be booked by the night; meeting rooms can be booked by the hour. Rates for cottages are expressed per person, per night; rates for meeting rooms are expressed per hour.

4

Case study: a resort reservation

system

Clients can book cottages and meeting rooms in advance by providing a phone number and a valid credit card information. Customers can express preferences for specific cottages. Cancellation of reservations is possible but requires 24 hours notice. An administrative charge applies to all cancellations. Every morning, a summary of the bookings for the previous day is printed out and the related information is erased from the computer; a list of the cottages and meeting rooms that will require cleaning is printed.

5

Identification of Classes

Step 1: identify candidate classes

Using nouns: extract objects from the nouns in the requirements

Class-Responsibility-Collaboration: each card describes one class, its responsibilities, and its collaborations with other classes

Data flow: start with inputs and determine what objects are needed to transform the inputs to the outputs

6

Identification of Classes

Using the things to be modeled: identify

individual or group things such as persons,

roles, organizations, logs, reports… in the

application domain that is to be modeled;

map to corresponding classes

Using object decomposition (top-down

approach): treat everything as an aggregate

that can be decomposed into parts

7

Identification of Classes

Using generalization (bottom-up

approach): look for objects that have

commonalities, and generalize the

corresponding classes

Using previous experience: object-

oriented domain analysis, application

framework, class hierarchies, and

personal experience

8

Noun identification

Identify candidate classes by extracting

all nouns out of the requirements/

specifications of the system.

Don’t be too selective at first; write

down every class that comes to mind. A

selection process will follow.

9

Noun identification: Case Study

Design the software to handle reservations at Blue

Lake Resort. The resort comprises several

cottages and two meeting rooms. Cottages can

comprise from one to three beds. The first

meeting room has a capacity of 20 persons, the

second, 40 persons. Cottages can be booked by

the night; meeting rooms can be booked by the

hour. Rates for cottages are expressed per

person, per night; rates for meeting rooms are

expressed per hour.

10

Noun identification: Case Study

Clients can book cottages and meeting rooms in advance by providing a phone number and a valid credit card information. Customers can express preferences for specific cottages. Cancellation of reservations is possible but requires 24 hours notice. An administrative charge applies to all cancellations. Every morning, a summary of the bookings for the previous day is printed out and the related information is erased from the computer; a list of the cottages and meeting rooms that will require cleaning is printed.

11

Keeping the right candidate

classes

Having made a tentative list of classes, eliminate unnecessary or incorrect classes according to the following criteria:

Redundant classes: nouns that express the same information

Irrelevant classes: nouns that have nothing to do with the problem

Vague classes: nouns with ill-defined boundaries or which are too broad

Attributes: nouns referring to something simple with no interesting behavior, which is simply an attribute of another class

Events or operations: nouns referring to something done to the system (sometimes events or operations are to be kept: check if they have state, behavior and identity).

Outside the scope of the system: nouns that do not refer to something inside the system

12

Refined list: Case Study

Good classes: Cottage, Meeting room, Client

Bad classes: Software, Blue Lake Resort, Bed,

Capacity, Night, Hour, Rate, Phone number, Credit

card information, Customer, Preference,

Cancellation, Notice, Administrative charge, Morning,

Day, Information, Computer

Don’t know: Reservation, Resort, Summary, List

13

More Class Identification Tips

Adjectives can suggest different kinds of objects or different use of the same object. If the adjectives indicate different behavior then make a new class.

Be wary of sentences in the passive voice, or those whose subjects are not part of the system. Recast the sentence in the active voice and see if it uncovers other classes. e.g.: "a summary of the bookings for the previous day is printed out". Missing from this sentence is the subject or who is doing the printing.

14

More Class Identification Tips

Keeping two lists (strong candidates and weaker ones) is a useful technique to avoid losing information while still sorting between things you are sure about and things that have yet to be settled. Additional techniques in Step 2 (identifying responsibilities and attributes) and Step 3(identifying relationships and attributes) will help.

15

Relationships

Association : An Association is a bi-directional connection between classes (e.g. the "hires/works for" relationship between an "employee" class and a "boss" class). It is represented by a solid line. This line can be qualified with the type of relationship, and can also feature multiplicity rules (eg. one-to-one, one-to-many, many-to-many) for the relationship.

16

Relationships

Aggregation: Aggregations indicate a

whole-part relationship, and are known as

"has-a" relationships. An aggregation is

represented as a line connecting the

related classes with a diamond next to the

class representing the whole.

17

Relationships

Composition: If a class cannot exist by

itself, and instead must be a member of

another class, then that class has a

Composition relationship with the

containing class. A Composition

relationship is indicated by a line with a

filled diamond.

18

Relationships

Dependency: When a class uses another class, perhaps as a member variable or a parameter, and so "depends" on that class, a Dependency relationship is formed. A Dependency is a relationship where the client does not have semantic knowledge of the supplier. It can be used, for example to show the relationship between an "encoder" class and a "generic Algorithm" class that is inserted in runtime to help it encode a stream. A dependency is shown as a dashed line pointing from the client to the supplier.

19

Relationships

20

Class notation

A class

ClassName

methods

attributes

A class diagram exhibits classes and their

associations used in an application.

Contrast this with a conceptual model which

shows domain concepts and their associations.

Note: you can include visibility attributes: + for

public, – for private, # for protected

21

Class Diagrams

A class diagram is a visual representation of various classes and their relationships as identified during design.

The class diagram is core to object-oriented design.

Class diagrams identify the class structure of a system, including the properties and methods of each class.

It describes the types of objects in the system and the static relationships between them, such as an inheritance relationship.

22

Building a class diagram

Once the interaction diagrams have been completed it is possible to identify the specification for the software classes and interfaces.

The UML has notation to define design details in static structure, or class diagrams.

Conceptual model is also useful in deriving classes by addition of detail.

A class diagram differs from a domain model by showing software entities rather than real-world concepts.

23

Building a class diagram

(cont.)

Typical information in a class diagram includes: Classes, associations and attributes

Interfaces (with operations and constants)

Attribute type information

Methods

navigability

dependencies

The class diagram depends upon the domain model and interaction diagrams.

24

Making class diagrams

Identify all classes by examining interaction

diagrams.

Draw them in a class diagram.

Duplicate the attributes from the associated

concepts shown in the conceptual model.

Add method names by examining interaction

diagrams.

Add type information to the attributes and

methods.

25

Making class diagrams

Add the associations needed for visibility.

Add navigability arrows to indicate the

direction of attribute visibility.

Add dependency relationships to indicate

non-attribute visibility.

26

Classes

Classes are the building blocks in

object-oriented programming.

Illustrate classes with rectangles

divided into compartments. Place

the name of the class in the first

partition (centered, bolded, and

capitalized), list the attributes in

the second partition, and write

operations into the third.

27

Active Class

Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Illustrate active classes with a thicker border.

28

Visibility

Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class.

29

Associations

Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other.Note:It's uncommon to name both the association and the class roles.

30

Multiplicity (Cardinality)

Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to oneinstance of the other class. For example, one company will have one or more employees, but each employee works for one company only.

31

Place constraints inside curly braces {}.

Constraint

Simple Constraint

32

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a filled diamond.Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate.

33

Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class is a specialized version of another. For example, Honda is a type of car. So the class Honda would have a generalization relationship with the class car.

34

Building a class diagram

Identify all the classes participating in the software solution. Do this by analyzing the interaction diagrams. Draw them in a class diagram.

Duplicate the attributes from the associated concepts in the Domain Model.

Add method names by analyzing the interaction diagrams.

:Terminal :BookEntrySession1: makeNewBook(…)

If the message makeNewBook() is

sent to an instance of class

BookEntrySession, then class

BookEntrySession must define a

makeNewBook() method.

BookEntrySession

makeNewBook()

isComplete: Boolean

35

Method names and

multiobjects

The add() message to

the multiobject should

be interpreted as a

message to the

container/ collection

object.

The add() method is

not part of class Book.

b: Book

2.1: create (…)

2.2: add (b)

:Catalog:Book

36

Navigability and dependency

relationships

Navigability is a property of the role implying visibility of the source to target class.

Attribute visibility is implied.

Add navigability arrows to the associations to indicate the direction of attribute visibility where applicable.

Common situations suggesting a need to define an association with navigability from A to B:

A sends a message to B.

A creates an instance of B.

A needs to maintain a connection to B

Add dependency relationship lines to indicate non-attribute visibility.

37

Class diagram

LibraryClerkAccesses Captures

1 1 1 *

1

BookEntrySession

initiateBookEntrySession()

makeNewBook()

becomeComplete()

isComplete: Boolean;

Book

author

title

publisher

year

Accesses

Contained-in

1

1*

Catalog

makeNewBook()

books: vector;

Terminal

makeNewBookEntry()

addBook()

endBookEntry()

Uses

1

1

38

Conceptual model versus class diagrams

A Sale in a conceptual model represents a

system concept. A Sale in a class diagram

represents a software entity.

39

Conceptual model versus class diagrams

(2)

POST captures1 1

Sale

Date

isComplete: boolean

time

captures1 1

POST

Date

isComplete:boolean

time

Sale

Date

isComplete:boolean

time

makeLineItem()

Conceptual model

Software components

40

Class diagrams: notables

create is a special language independent

UML message to indicate instantiation and

initialization. As this is a common operation, it

is often omitted from class diagrams.

Access methods for class attributes are also

omitted from class diagrams to reduce clutter.

Messages to a multiobject are not shown as

methods in the class whose objects are

contained in a multiobject.

41

Class diagrams: notables

It is recommended that UML syntax be used

for method naming. This will keep naming

language independent. UML format:

methodName(parameterList)

Should all type information be shown in a

class diagram?

If automatic code generation is desired then YES.

If the sole purpose is to use the diagram as a

communication aid, then all type information is not

of any significant value. (See Fig 21.7 of T1.)

42

Class diagrams: navigability

captures1 1

POST

Date

isComplete:boolean

time

Sale

Date

isComplete:boolean

time

makeLineItem()

POST will likely have an

attribute pointing to Sale.

Navigability arrow: POST

objects are connected

uni-directionally to Sale

objects.

No navigability arrow..Sale

does not have connection

to POST.