Part III: Analysis

1
Part III Analysis

• Analysis Workflow
• Classes and Objects
• Finding Analysis Classes
• Analysis Relationships

2
The Analysis Workflow

• The main work starts at the end of inception
• The main focus of Elaboration is the analysis
• Most of the activity of elaboration is
• Creating models to capture
• the desired behavior of the system
• Requirements capture
• and analysis go together
• The main aim is
• To produce the analysis model
• Focus
• What the system needs to do
• not the details of how.

3
The Analysis Workflow
4
Analysis Activities
5
Analysis Model

• Every system is different
• Moderate size and complexity projects
• 50-100 analysis classes in the analysis model
• Concentrate only on the classes
• that are part of the problem domain
• Avoid from design classes
• Communication classes
• Database access classes

6
Rules of Thumb

• Use the language of business
• Each diagram must
• tell important part of the systems desired
  behavior
• Concentrate on the capturing the big picture
• Do not lose time for details
• Distinguish between
• the problem domain (business requirements)
• and solution domain
• Try to minimize the coupling
• Explore inheritance
• if there is a natural hierarchy of abstractions
• Try to provide a model
• that is useful for all stakeholders
• Keep the model simple

7
What are objects?

• Definition (The UML Reference Manual)
• A discrete entity with a well-defined boundary
• encapsulating state and behavior
• An instance of a class
• A cohesive packet of
• data and function
• Access to data is only possible
• by calling a function of the object
• A function is called as
• Operation in analysis
• Method in design
• Data-hiding
• To hide the data part of the object
• behind the function layer

8
What are objects?

• Every object is an instance of a class
• defining the common set of features
• Attributes,
• Operations/Methods
• A specific instance of a class is called object
• Common properties of objects
• Identity Makes it different from all other
  objects
• The unique existence of object in time and space
• An address in memory
• State
• The attribute values of object at a time
• Behavior
• Movement of object from one state to another
  state
• Changing attribute value or values in time

Class Epson Photo 1200
Object Epson Photo 1200 S/N 34120098
Object Epson Photo 1200 S/N 30040065
Object Epson Photo 1200 S/N 70050516
9
Encapsulation

• To enable user to concern
• only with the services the object offers
• Instead of the structure of data
• Data is hidden inside of the object.
• The behavior of an object is
• What it can do for us.
• List of operations
• changing attribute values
• and generate state transitions.
• State transition
• Any method invocation
• leading to substantive change
• in the objects nature
• in UML
• Statecharts (Chapter 19) are used
• to model state transition.

10
Encapsulation
Operation Semantics
deposit() Deposit some money in the Account object. Increment the balance attribute value.
withdraw Withdraw some money from the Account. Decrement the balance attribute value.
getOwner() Returns the owner of the Account object.
setOwner() Change the owner of the Account object.

• Operations causing state transitions (changing
  attribute values)
• deposit(), withdraw(), setOwner().
• Operations causing state transitions (not
  changing attribute values)
• getOwner()

11
Messaging

• Objects collaborate to perform functions of the
  system
• Forming links to other objects
• and send messages back and forth along these
  links
• When an object receives a message
• Compares the message with operation signatures
  defined
• if there is any match
• invokes the corresponding operation
• performs the activities
• sends the result back to the caller object.
• This is quite different from procedural systems
• Execution is not ordered in time.
• Exact time of invoking operation is undetermined.

12
Messaging of Objects
13
UML Object Notation

• Object icon of UML has two compartments
• Object identifier
• Always underlined to distinguish from class
  notation
• The class name might be included using a colon
• Example jimsAccountAccount
• Attributes
• Name, type and values can be shown
• nametypevalue
• Example numberint1234567
• Attribute types might be omitted for
  simplification

14
UML Object
15
What are Classes?

• Definition (The UML Reference Manual)
• The descriptor for a set of objects sharing the
  same
• attributes,
• operations/methods,
• relationships
• and behavior
• A class is a descriptor for a set of objects
• having the same features
• Every object is an instance of exactly one class
• A class is a template for objects
• Determines the structure of objects
• Allows to describes a set of features
• that all objects must have
• No need to describe every feature of each object
• All objects have
• the same attributes, and relationships
• but different attribute values

16
Classes and Objects

• Relationship
• A connection between the modeling elements
• Dependency
• A relationship between two elements
• A change in supplier element
• affects the client element
• instantiate relationship
• Represented by a dotted arrow
• between the class and objects
• An ordinary dependency
• Between the class and objects of that class

17
Relationship between Class and Objects
18
Object Instantiation

• Instantiation
• The creation of new instances of model elements
• Constructors
• Special operations belong to the class
• Used to create class instances
• Allocates memory for the new object
• Gives a unique identity to the object
• Sets the initial attribute values
• Constructs links to other objects

19
UML Class Notation

• Three compartments
• Name compartment
• The only mandatory part
• Contains the name and general information about
  the class
• Attribute compartment
• Is optional
• Used for data values
• Initial values are represented
• Operations compartment
• Is optional
• Used to define the operations

20
UML Class Example
21
Name compartment

• Convention is
• to represent class names in CamelCase
• Special symbols are avoided
• Avoid abbreviations
• Class name must reflect
• real world entities
• Abbreviated names are
• harder to read and understand

22
Attribute Compartment
visibility name multiplicitytype
initialValue
optional
mandatory
optional

• Visibility
• Represents the accessibility of the attribute
• Name
• Used to identify the attribute
• Multiplicity
• To constraint the number of occurrences
• Type
• Type of the attribute
• Integer, string, array, float, char, etc.
• Initial Value
• The first value assigned to the attribute
• after the object creation

23
Visibility

• To restrict the access to the attribute
• Implementation language dependent
• Must be described at the design

24
Visibility - semantics
25
Multiplicity

• Widely used in design
• Might be used in analysis too
• Expresses the constraints to the number of things
• Arrays
• If multiplicity is an integer greater than 1
• colors7
• Null values
• Values for non-initialized attributes

26
Multiplicity Examples
27
Operation Compartment
Operation signature
visibility name (parameterName
paramaeterType, ) returnType
parameter list

• Operation signature combination of
• Operation name
• Type of all parameters
• Return type
• When a message sent to an object
• Message signature is compared
• with operations signature
• If a match is found
• the operation is invoked
• Operations are named camelCase
• Always starts with lowercase character

28
Scope

• It is sometimes useful
• to define attributes
• have a single shared value
• for every object of the class
• to have those operations that
• Do not operate on any particular class instance
• Example object creation and destruction
  operations
• Such type of attributes and operations have class
  scope.
• Provide a set of global features
• for an entire objects of that class.

29
Scope

• Instance scope operations
• are specific for the object operations
• can access
• other instance scope attributes and operations
• all class scope attributes and operations
• Class scope operations
• are defined as class-wide
• access only other class scope attributes and
  operations
• cant access instance scope operations.

30
Example BankAccount
create(aNumber int) countcount
1 accountNumber aNumber
create(aNumber int) incrementCount() accountNu
mber aNumber
31
Object Destruction

• Objects are destructed when they are not required
  anymore
• their memory is deallocated
• Different languages have different semantics
• C
• ClassName(parameterList)
• Java
• finalize()
• C
• Finalize()
• Some languages (Java) automatically destructs the
  objects
• When they are not referenced anymore
• Garbage collector removes such objects from
  memory.
• It is a good programming style
• To call destructors
• when objects are not required anymore

32
UP Activity Analyze a use case

• To realize the use cases
• To derive the analysis classes

33
Analysis Classes

• Represent an abstraction in the problem domain
• Map on to real-world business concept
• OO analyst must
• Try to clarify the confused business concepts
• to a form a basis for analysis classes
• Clarify the problem domain!

34
Anatomy of Analysis Classes

• Analysis classes
• Must present very high level set of attributes
• Contain the attributes
• that might be the member of design classes
• Only a subset of class syntax is used
• Name
• Mandatory, shown
• Attributes
• Names are mandatory, types optional
• Operations
• As a very high level statements
• Parameters and return types shown only if it is
  important
• Visibility
• Generally not shown
• Stereotypes
• Shown only if they enhance the model
• Tagged values
• Shown only if they enhance the model

35
Example Analysis Class
36
A Good Analysis Class

• models an element in problem domain
• Maps to a clearly identifiable feature
• Has small, well defined set of responsibilities
• Well defined set of services
• accommodating the intent of the class
• Example ShoppingBasket
• Add item to the basket
• Remove item from the basket
• Show the items in the basket

37
A Good Analysis Class

• Has a name reflect its intent
• in e-commerce system
• Customer, ShoppingBasket
• WebSiteVisitor has vague semantics
• Has high cohesion
• All responsibilities must be
• working for the same goal
• Example
• ShoppingBasket validate card, accept payment,
  print receipt
• Has low coupling
• Optimize relationships with other classes

38
Finding Classes

• There is no simple algorithm
• to find the right analysis classes
• Finding the right classes depends on
• Perspective
• Skill
• Experience
• Some techniques are available to help

39
Noun/Verb Analysis

• A simple way to find
• Classes
• Attributes
• Responsibilities
• Analyze the text (i.e. specification)
• Nouns and noun phrases
• become Classes or attributes
• Verbs and verb phrases
• become responsibilities or operations
• Be aware of
• Synonyms different words meaning the same thing
• Homonyms the same words with different meanings
• The problem domain must be well-understood
• Hidden classes
• Classes that are not mentioned directly

40
Noun/Verb Analysis Procedure

• Collect as much relevant information as possible
• Requirements specification
• Use cases
• Project glossary
• Architecture, vision documents, etc.
• Highlight
• Nouns e.g. flight
• Noun phrases e.g. flight number
• Verbs e.g. allocate
• Verb phrases e.g. verify credit card
• Clarify the words/terms that are not understood
• Prepare a first cut
• entering the classes to a CASE tool

41
CRC Analysis

• Class-Responsibility-Collaborators
• The sticky notes method with three compartments
• Class name
• The name of the candidate class
• Responsibilities
• The expected responsibilities of the classes
• Collaborators
• Other classes that the class interact with

42
CRC Card
43
CRC Example Rental Contract
Class Name Rental Contract Class Name Rental Contract Class Name Rental Contract Class Name Rental Contract
Superclasses Superclasses Superclasses Superclasses
Subclasses Subclasses Subclasses Subclasses
Responsibilities Collaborators Object Think Property
Update customer info Customer I know the customer Customer
Select vehicle Rental agent I know the rental agent Rental Agent
Return vehicle Rental agent I know the vehicle Vehicle
Print contract Vehicle I know the time checkout Out Time Stamp
I know the time return In Time Stamp
I know the miles driven Miles Driven
I know any damage done Damage Report
I know the rental status Status
44
CRC Procedure

• Should be used in conjunctions with noun/verb
  analysis
• Two phase activity
• Brainstorming
• Gather the information
• Analyze the information
• Deciding which of the sticky notes would become
  classes

45
Phase 1 Brainstorming

• Explain that this is a true brainstorming
• All ideas are accepted as good ideas
• Ideas are recorded but not debated
• Never argue about something
• Just write it down
• Ask the team members to name things
• Write each thing on a sticky note
• Stick the note on a wall or whiteboard
• Ask the team to state responsibilities
• Write down to the responsibilities compartment
• Identify the classes to work together
• Draw lines between them
• Record them in collaborators department

46
Phase 2 Analyze Information

• Classes
• Certain sticky notes represent
• an abstraction in business domain
• need to be classes
• Attributes
• Check the following notes
• logically seems to be a part of other note
• not selected as classes
• does not seem to be particularly important
• has very little interesting behavior

47
Other Sources of Classes

• Physical objects in the problem domain
• Aircraft, people, hotels, etc.
• Paperwork
• Invoices, orders, bankbooks, etc.
• Known interfaces to outside world
• Screens, keyboards, peripherals, etc.
• Conceptual entities
• Not concrete
• But crucial for the business operation

48
What is a Relationship?

• A semantic connections between modeling elements
• Examples
• Between actors and use cases
• Associations
• Between use cases and other use cases
• Generalization
• include
• extend
• Between actors and other actors
• Generalization
• Objects must be connected to perform a useful job
• Link
• A connection between the objects
• An instance of an association between their
  classes

49
Object Diagrams

• A snapshot of an executing OO system
• To show objects and their relationships
• Connected objects
• may adopt various roles
• relative to each other
• Links are dynamic connections
• after a time, the roles might change
• Links may connect
• One object to the other
• Unidirectional link
• Arrow head shows the target
• Two objects to each other
• Single line
• More than two objects to each other
• More than one line
• all are connecting the objects

50
Objects and Roles
51
Unidirectional Links
Data sent only from PersonDetails to Address
but not vice versa
52
Paths
Connecting objects with orthogonal paths to
represent the links
53
Association

• Is a relationship between classes
• If there is a link between two objects
• There must be an association between their
  classes
• Associations may have
• Association name
• Verb phrase
• An arrow head is used to represent the direction
• CamelCase starting with lowercase letter
• Role name
• Alternative to the single name
• On one or both ends of the association
• Multiplicity
• Navigability

54
Objects Class Instances
55
Association Syntax
56
Role Names in Associations
Role names are represented in both ends of the
association
57
Multiplicity

• Specifies
• the number of objects
• can participate in a relationship
• at any point in time
• Depends on the requirements
• Can encode business rules
• Specified as a comma-separated list of intervals
• minimum..maximum

58
Multiplicity
Multiplicity is 1-to-n
59
Specifying the Multiplicity
60
Association Example with Multiplicity
61
Modeling with Multiplicity

• There is a certain amount of debate on
• to show the multiplicity on analysis model or not
• It should be included
• Because multiplicity describes
• business rules
• constraints
• assumptions
• Reflexive associations
• One class has an association to itself

62
Reflexive Associations
63
Hierarchies and Networks

• Hierarchy
• Tree structured systems
• One root at the top
• An object
• has only one object above
• but many objects below
• Network
• Graph structured systems
• No root is defined
• Many objects are connected to each other

64
Example Hierarchy
65
Example Network
66
Navigability

• Shows that it is possible to traverse from one
  object to the other
• Means
• messages are sent in one direction
• Navigability is used
• To minimize the coupling between classes
• Relationships with arrows
• are unidirectional
• Traverse in one direction is possible
• Relationships without arrows
• are bi-directional
• Traverse in both directions is possible

67
Navigability
68
Associations and Attributes

• One-to-one associations between classes
• is converted into attributes of source class
• Multiplicities greater than one implemented as
  either
• An attribute of type array
• An attribute of some type that is a collection
• Example Java - Vector

69
1-to-1 Associations
public class private Address address
1-to-1 associations turn into attributes of the
source classes
70
Dependency

• A relationship between two elements
• A change to one element (supplier)
• effect the other element (client)
• The client depends on the supplier
• 4 basic dependencies
• Usage
• Abstraction
• Permission
• Binding
• Dependencies occur between
• Classes and classes
• Classes and objects
• Packages and packages
• Represented with
• Dotted arrow
• With the name of the dependency

71
Basic Types of Dependencies
72
Dependency Example
73
End of Chapter