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
Software Design 1

October 8, 2004

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)

October 8, 2004

Software Design

Case study: a resort reservation system [1]

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.
October 8, 2004 Software Design 3

Case study: a resort reservation system [2]

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.
October 8, 2004 Software Design 4

Identification of Classes[1]
 

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
Software Design 5

October 8, 2004

Identification of Classes[2]


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

October 8, 2004

Software Design

Identification of Classes[3]


Using generalization (bottom-up approach): look for objects that have commonalities, and generalize the corresponding classes Using previous experience: objectoriented domain analysis, application framework, class hierarchies, and personal experience
Software Design 7

October 8, 2004

Noun identification


Identify candidate classes by extracting all nouns out of the requirements/ specifications of the system. Dont be too selective at first; write down every class that comes to mind. A selection process will follow.

October 8, 2004

Software Design

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.
October 8, 2004 Software Design 9

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.
October 8, 2004 Software Design 10

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
October 8, 2004 Software Design 11

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

Dont know: Reservation, Resort, Summary, List

October 8, 2004

Software Design

12

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.
Software Design 13

October 8, 2004

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.
Software Design 14

October 8, 2004

Relationships


Association : An Association is a bidirectional 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-tomany, many-to-many) for the relationship.

October 8, 2004

Software Design

15

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.

October 8, 2004

Software Design

16

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.

October 8, 2004

Software Design

17

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.

October 8, 2004

Software Design

18

Relationships

October 8, 2004

Software Design

19

Class notation
A class diagram exhibits classes and their associations used in an application.

ClassName attributes methods

Contrast this with a conceptual model which shows domain concepts and their associations.

A class

Note: you can include visibility attributes: + for public, for private, # for protected
October 8, 2004 Software Design 20

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.
October 8, 2004 Software Design 21

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.
October 8, 2004 Software Design 22

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.
Software Design 23

October 8, 2004

Making class diagrams (1)



 

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.
Software Design 24

October 8, 2004

Making class diagrams (2)

 

Add the associations needed for visibility. Add navigability arrows to indicate the direction of attribute visibility. Add dependency relationships to indicate non-attribute visibility.

October 8, 2004

Software Design

25

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.

October 8, 2004

Software Design

26

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.
27

October 8, 2004

Software Design

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.

October 8, 2004

Software Design

28

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.
29

October 8, 2004

Software Design

Multiplicity (Cardinality)


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

October 8, 2004

Software Design

Constraint


Place constraints inside curly braces {}.

Simple Constraint

October 8, 2004

Software Design

31

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.
Software Design 32

October 8, 2004

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.
33

October 8, 2004

Software Design

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.
BookEntrySession
isComplete: Boolean

If the message makeNewBook() is sent to an instance of class BookEntrySession, then class BookEntrySession must define a makeNewBook() method.

makeNewBook()

:Terminal
October 8, 2004

1: makeNewBook()
Software Design

:BookEntrySession
34

Method names and multiobjects



:Book

:Catalog
2.2: add (b) 2.1: create ()

b: Book


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.

October 8, 2004

Software Design

35

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.

October 8, 2004

Software Design

36

Class diagram
Terminal LibraryClerk Accesses 1 1 makeNewBookEntry() 1 addBook() endBookEntry() 1 Accesses 1 Uses 1 Catalog books: vector; Book author title publisher year * Contained-in 1
37

BookEntrySession Captures * isComplete: Boolean; initiateBookEntrySession() makeNewBook() becomeComplete() 1

makeNewBook()

October 8, 2004

Software Design

Conceptual model versus class diagrams (1)



A Sale in a conceptual model represents a system concept. A Sale in a class diagram represents a software entity.

October 8, 2004

Software Design

38

Conceptual model versus class diagrams (2)

captures 1 Sale POST 1
Conceptual model POST Date isComplete:boolean time
October 8, 2004 Software Design

Date isComplete: boolean time Sale Date isComplete:boolean time makeLineItem() Software components
39

captures

Class diagrams: notables (1)



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.
Software Design 40

October 8, 2004

Class diagrams: notables (2)



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.)
Software Design 41

October 8, 2004

Class diagrams: navigability (1)

POST will likely have an attribute pointing to Sale. Navigability arrow: POST objects are connected uni-directionally to Sale objects.

POST 1 Date isComplete:boolean time

captures

Sale Date isComplete:boolean time makeLineItem()

No navigability arrow..Sale does not have connection to POST.

October 8, 2004 Software Design 42