Upload
garapati-avinash
View
106
Download
3
Tags:
Embed Size (px)
Citation preview
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.