Part III ObjectOriented Analysis

1
sysc-4800 Software Engineering

• Part III - Object-Oriented Analysis

2
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

3
Overview

• Transform the specifications of the system in a
  form suitable to designers, from the requirements
  elicitation results (use case model)
• Systematic procedure, heuristics
• Analysis of problem domain, as opposed to
  solution domain (Design)
• Model composed of static and dynamic UML models
• Static model classes relationships attributes
  (model system structure)
• Dynamic model object behavior, interactions
  between objects (model system behavior)
• The result is a model that is correct, complete,
  consistent and verifiable.

4
Overview (Bruegge and Dutoit, 2000)
5
Analysis Model (Bruegge and Dutoit, 2000)
6
Additions to Analysis Model

• Data dictionary (Glossary) All classes, methods,
  attributes are defined in a data dictionary that
  will be updated all along the development process
• Pre- and Post-conditions for methods in the class
  diagram
• Invariant for classes in the class diagram

7
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

8
Object Modeling

• Steps during object modeling
• Class identification
• Find the attributes
• Find the methods
• Find the associations between classes
• Review (iterate, iterate, iterate)
• Order of steps
• Order of steps secondary, only a heuristic
• Iteration is important
• Static model will be refined when devising
  dynamic models

9
Class Definition (reminder)

• UML definition description of a set of objects
  that share the same attributes , operations,
  methods, and relationships OMG UML Guide, 1999
• Class structure a 3-part box
• Attribute name, type, initial value, visibility
• Operation name, return type, visibility
• Parameter name, type, direction

10
Object Types

• To facilitate the identification of objects, it
  is useful to classify them. In every system, we
  find recurrent types of objects, though in
  varying proportions.
• Entity Objects
• Represent the persistent information tracked by
  the system (Application domain objects, Business
  objects)
• Boundary / Interface Objects
• Represent the interaction between the actors and
  the system user interface object, device
  interface object, system interface object
• Control Objects
• Represent the control tasks performed by the
  system, contains the logic and determines the
  order of object interactions

11
Entity Object Examples
Long-living objects that store information.
Account information in a bank system
Sensor data in a real-time system
12
Entity Classes in a Banking System
13
Object Types (cont.)

• The Boundary/Control/Entity classification can be
  refined
• See the accompaniment (pdf) document (course web
  site).

14
Object Types (cont.)

• Examples
• Entity objects
• information records of employees in company
• User interface object
• windows, scroll bars
• Device interface object
• sensors, actuators, I/O
• System interface object
• external system the system interfaces with
• Application logic objects
• accounting and tax rules (business logic,
  decision making, business-specific logic), speed
  control algorithms
• In the textbook, application logic objects are
  merged with the Entity category and Interface
  objects are referred to as Boundary.
• Examples for timer, coordinator and
  state-dependent

15
Use of Object Types

• Having these types of objects leads to models
  that are more resilient to change.
• The boundary objects of a system are more likely
  to change than the control
• The control objects of the system is more likely
  to change than the application logic and entity
  objects
• We do not want a large number of classes to
  change when errors are corrected or requirements
  change
• Helps identify objects and clearly identify
  responsibilities
• Helps verify objects
• Most objects should fit in one (and only one) of
  these categories
• Helps read class diagram (using stereotypes)

16
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

17
Associations (reminder)

• Model the possibility of links between objects of
  two or more classes
• Describe a group of links with common structure
  and semantics
• Can have a different name in each direction
• Use role names as often as possible
• Mathematically correspond to a set of tuples
  (relations)
• Multiplicity One-to-one, many-to-one,
  one-to-many, many-to-many
• Simple associations, aggregations, inheritance

18
FRIEND
writes
19
Association Classes (Fowler)
attends
2..

attends
2..

1
1
2..

20
Do Rolenames Attributes ?
1


bookedCab
dispatchedTo
0..1
1
performedBy
0..1
currentJob
0..1
currentDriver

1
performs
21
Whole-Part Class Relationship

• Four semantics possible
• ExclusiveOwns (e.g. Book has Chapter)
• Existence-dependency (deleting a composite ?
  deleting the components)
• Transitivity
• Asymmetricity
• Fixed property
• Owns (e.g. Car has Tire)
• No fixed property
• Has (e.g. Division has Department)
• No existence dependency
• No fixed property
• Member (e.g. Meeting has Chairperson)
• No special properties except membership

22
UML Aggregation (reminder)

• UML supports
• Aggregation
• Hollow diamond
• Corresponds to Has and Member aggregations
• Composition
• Solid diamond
• Corresponds to ExclusiveOwns and Owns
  aggregations

23
Example University Enrolment
24
Whole-Part Class Relationship

• Finding the right whole-part class relationship
  between class A and class B is context dependent
• Depends on the specifics of your application
• For instance Class Car is associated with class
  Tire
• You have to build a software for a company
  building cars
• From the point of view of this company, once the
  car is built, the link Car-Tire does not change
• ExclusiveOwns
• You have to build a software for a company
  recycling cars
• Tires in good shapes can be reused.
• Has

25
Generalization / Specialization (reminder)

• Common features abstracted into a more generic
  class
• Subclasses inherit (reuse) superclass features
• Substitutability subclass object is a legal
  value for a superclass variable (e.g. a variable
  holding Fruit objects can have an Apple object as
  its value)
• Polymorphism the same operation can have
  different implementations in different classes
• Abstract operation implementation provided in
  subclasses
• Abstract class class with no direct instance
  objects
• A class with an abstract operation is abstract

26
Example Video Store
27
FRIEND Example
28
Simple Elevator (Schach, 1999)
29
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

30
System Context Class Diagram (Gomaa, 2000)

• Objective
• Understanding the interface (boundary) between
  the system and the external environment (i.e.,
  the system context)
• Such diagram can be discussed with customers.
• Use a System Context Class Diagram
• More detailed view of the system boundary than
  that provided by the use case diagram
• This is not part of the textbook methodology.
• Alternative to the data flow diagram
  (Telemarketing system in the previous part of the
  course)

31
External Classes (Gomaas taxonomy)
32
System Context Class Diagram (Gomaa, 2000)

• Contents of the System Context Class Diagram
• The system is shown as an aggregate class with
  the stereotype ltltsystemgtgt
• The external environment is depicted as external
  classes (with stereotypes) to which the system
  has to interface
• Standard association names are
• ltltexternal input devicegtgt Inputs to ltltsystemgtgt
• ltltsystemgtgt Outputs to ltltexternal output devicegtgt
• ltltexternal usergtgt Interacts with ltltsystemgtgt
• ltltexternal systemgtgt Interfaces with ltltsystemgtgt
• ltltexternal timergtgt Awakens ltltsystemgtgt
• Actors are associated with external classes
• Multiplicities can be used.

33
Context Class Diagram
-inputs to
External I/O Device
1
CardReader
Operator
1..
1
External output device
ReceiptPrinter
1
1
1..
1
1
-Interacts with
1
system
External user
Banking System
Operator
1
1..
1
External user
ATM
1
1
ATMCustomer
Customer
1..
-outputs to
External output device
1
CashDispenser
1..

• Note that the corresponding use case diagram is
  slightly different
• There are actor for the CardReader, the
  ReceiptPrinter, the CashDispenser

34
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

35
Modeling Interactions

• Sequence Diagrams
• Show an exchange of messages between objects
  arranged in a time sequence
• More useful in analysis
• Collaboration Diagrams
• Emphasize the relationships between objects along
  which the messages are exchanged
• More useful in design
• Can be used to determine operations in classes
• Sequences of messages must match operations pre
  and postconditions

36
Message Sequences

• Message can be labeled with a
• Signal
• Denotes asynchronous inter-object communication
• The sender continues executing after sending the
  signal message
• Call
• Denotes (Usually) synchronous invocation of an
  operation
• The return message can return some values to the
  caller or it can just acknowledge that the
  operation completed
• ltltcreategtgt and ltltdestroygtgt
• Use of the UML notation
• Analysis
• Design

37
Example - ATM
38
Example - ATM
ATM
1 cardInserted
1.1 bID bankID()
1.2 ePIN encryptedPIN()
1.3 aNum accountNumber()
1.4 validate(bID, aNum)
1.5 insertPIN()
2 enterPIN(p)
2.1 validatePIN(p)
2.2 selectTransaction()
3 fastCash(p)
3.1 provideAmount
4 withdrawal(amount)
4.1 withdrawal(amount)
4.1.1 ACK
4.1.1.1 dispense(amount)
4.1.1.2 ejectCard()
39
Use Cases vs. Sequence Diagrams

• Sequence diagrams specify how flows of events
  (use case descriptions) are realized by means of
  messages.
• Use case include and extend relationships help
  cope with the complexity of flows of events.
• How do include and extend use case relationships
  translate into message flows in sequence
  diagrams?
• See the accompaniment (pdf) document (course web
  site).

40
Textbook Advice on Using Use Cases for Analysis

• When constructing sequence diagrams, we not only
  model the order of interactions among objects, .
  we also assign responsibilities to each object in
  the form of a set of operations.
• These operations can be shared by any use case in
  which a given object participates . if an
  operation appears in more than one sequence
  diagram, its behaviour should be the same.
• Sharing operations across use cases help remove
  redundancies in the requirements specification
  and improve its consistency
• But, clarity should be given precedence to
  eliminate redundancy
• Building interaction diagrams is time consuming
• Developers should focus on problematic and
  underspecified functionality first
• But, drawing for simple and well-defined
  use-cases are also a good investment of time and
  effort, to avoid overlooking key decisions.

41
State Change Specifications

• Statechart Diagrams
• For each class that exhibits an interesting
  dynamic behavior
• Changes to some attributes may signify state
  changes, e.g.,
• BankAccount.balance lt 0 gt state overdraft

42
Specifying object states

• State transition fires when a certain event
  occurs or a certain condition is satisfied
• transition line does not have to be labeled with
  an event name
• condition itself (written in square brackets) can
  fire the transition
• Transition can be triggered by
• Signal event
• Call event
• Change event
• Time event

43
ElevatorController Statechart
44
Example Movie Title
rentOut() last item /subtractItem()
Not in Stock
Available
returnItem() no items /addQuantity()
orderItem()
putOnShelf()
replenishStock()
In Stock
Ordered
45
Example Movie Title
46
Example Vending Machine
47
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

48
Class Modeling during Analysis

• Classes, their invariant, associations, and
  attributes are determined at this stage
• Associations among classes
• Attributes of classes
• But also system operations and their contracts,
  I.e., pre- and post-conditions
• Invariant condition that must remain true under
  any circumstances for an instance of the class
• Pre-condition condition that must be true for
  the operation to execute correctly
• Post-condition the effect of executing the
  operation in terms of system state change and
  outputs

49
Finding classes (I)

• Identify participating objects in each use case
• Pick one (there are many, so prioritize!)
• They will correspond to the main concepts of the
  application domain
• Always use application domain terms
• They are named, described, consolidated into the
  data dictionary (glossary)
• If two use cases refer to the same concept, the
  corresponding object should be the same.
• If two objects share the same name and do not
  correspond to the same concept, one or both
  concepts are renamed to acknowledge and emphasize
  their difference.
• Benefits of a data dictionary
• consistent set of definitions for all developers
• single term for each concept
• precise and clear official meaning
• Definitions of objects and attributes may be
  reviewed by the users
• Initial Analysis model, several iterations

50
Example 4th Year Project Selection
Browse Projects
Propose Project
Professor
Select Project
Student

• System displays form
• Professor enters information.
• System re-displays info as it will be posted.
• Professor confirms.
• System adds project to the list for that
  professor.

• System displays all projects.
• Student student either identifies a project they
  wish to join, or provides supervisor and title of
  a project they wish to create. In either case,
  they provide their personal information (name,
  number,email)
• System updates the list of projects.
• System sends confirmation email to student,
  supervisor and any other group members, if any.

• System prompts for search criteria All, prof,
  keyword
• Student selects criteria.
• System displays all projects for criteria.

51
Example 4th Year Project Selection
Projects title
0..
1
1..2
0..
supervisor
member
Student -name -number -email
Professor -name -email -extension
52
Example 4th Year Project Selection
ProjectProposal -title -description
Project -title
0..
1
0..
supervisor
member
1..
1..2
Student -name -number -email
Professor -name -email -extension
1..2
supervisor
53
Finding classes (II)

• General Advice
• Find the nouns in the use cases (e.g., Incident)
• Systematic Processes
• Abbotts Textual Analysis
• CRC cards (Class-Role-Collaboration)
• Heuristics
• Heuristics for Entity
• Heuristics for Boundary
• Heuristics for Control

54
Example Report Emergency

• Flow of Events
• FieldOfficer activates the Report Emergency
  function of terminal
• FRIEND responds by presenting a form to the
  officer, including location, incident
  description, resource request and hazardous
  material fields.
• FieldOfficer completes form by specifying
  minimally the emergency type and description
  fields. May also describe possible responses to
  the emergency situation and request specific
  resources. Once form is completed, FieldOfficer
  submits the form.
• FRIEND receives form and notifies Dispatcher
• Dispatcher reviews submitted information and
  creates an Incident in the database by invoking
  the OpenIncident use case. All information
  contained in form is automatically included in
  the Incident. Dispatcher selects a response by
  allocating resources to the Incident (with
  AllocateResources use case) and acknowledges the
  emergency report with a short message to
  FieldOfficer
• FRIEND display acknowledgement and selected
  response to FieldOfficer.

55
Textual Analysis
Mapping parts of speech to object model
components Abbot 1983 Examples from
ReportEmergency Use Case

• Part of speech
• Proper noun
• Common noun
• Doing verb
• being verb
• having verb
• modal verb
• adjective

• Example
• Alice
• FieldOfficer
• Submit
• Is a kind of
• Has, includes
• must be
• Incident description

• Model component
• instance
• class
• method
• inheritance
• aggregation
• constraint
• attribute

56
Example ReportEmergency

• Flow of Events
• FieldOfficer activates the Report Emergency
  function of terminal
• FRIEND responds by presenting a form to the
  officer, including location, incident
  description, resource request and hazardous
  material fields
• FieldOfficer completes form by specifying
  minimally the emergency type and description
  fields. May also describe possible responses to
  the emergency situation and request specific
  resources. Once form is completed, FieldOfficer
  submits the form.
• FRIEND receives form and notifies Dispatcher
• Dispatcher reviews submitted information and
  creates an Incident in the database by invoking
  the OpenIncident use case. All information
  contained in form is automatically included in
  the Incident. Dispatcher selects a response by
  allocating resources to the Incident (with
  AllocateResources use case) and acknowledges the
  emergency report with a short message to
  FieldOfficer
• FRIEND displays acknowledgement and selected
  response to FieldOfficer.

57
Pros and Cons

• Focus on users terms
• Model quality depends on analyst writing style
• Natural language is inherently imprecise
• More nouns than relevant classes
• Usually imply clarifying and rephrasing the
  scenarios and use cases with users, and use a
  data dictionary
• Use of heuristics is necessary with natural
  language

58
Heuristics for Entity Objects

• Find terms that developers or users need to
  clarify in order to understand the flow of events
• e.g., information submitted by FieldOfficer
• Clarify as EmergencyReport
• Recurring nouns in use cases
• e.g., Incident
• Real world entities that the system needs to keep
  track of
• e.g., FieldOfficer, Dispatcher
• Real world procedures that the system needs to
  keep track of
• e.g., EmergencyOperationsPlan

59
ReportEmergency (entity objects only)

• Dispatcher
• Police officer who manages Incidents
• EmergencyReport
• Initial report about an Incident from a
  FieldOfficer to a Dispatcher.
• FieldOfficer
• Police or fire officer on Duty.
• Incident
• Situation requiring attention from a
  FieldOfficer.

60
Heuristics for Boundary Objects

• Represent the system interface with actors
• Each actor interacts with at least one boundary
  object
• They transform the actor information to be used
  by entity and control objects
• Forms and windows the users need to enter data
  into the system
• e.g., EmergencyReportForm
• Notices and messages the system uses to respond
  to the user
• e.g., AcknowledgmentNotice
• Data sources or sinks (eg. Printer)
• Beware Model the user interface at coarse level
• Do not model the visual aspects at this stage
• Visual aspects are dealt with by a GUI subsystem,
  e.g., based on SWING in Java, which is the
  intermediary between the user and the interface
  class

61
ReportEmergency (Boundary)

• AcknowledgementNotice
• Notice used for displaying the Dispatchers
  acknowledgement to the FieldOfficer
• DispatcherStation
• Computer used by the Dispatcher
• FieldOfficerStation
• Mobile Computer used by the Dispatcher
• ReportEmergencyButton
• Button used by FieldOfficer to initiate
  ReportEmergency use case.
• IncidentForm
• Form used for the creation of Incidents,
  presented to Dispatcher on DispatcherSation when
  EmergencyReport is received.
• Not mentioned in the use case description, but
  dispatcher needs an interface to view emergency
  an report
• EmergencyReportForm
• Form used for input of the ReportEmergency,
  presented to FieldOfficer on the
  FieldOfficerStation.

62
Heuristics for Control Objects

• Responsible for coordinating boundary and entity
  objects
• e.g., ElevatorController in Elevator class
  diagram
• Do not have usually a counterpart in real world
• Creation/Destruction (usually)
• created when a user session or a use case
  scenario starts
• ceases to exist at the end of the session or use
  case scenario
• Collect information from boundary objects and
  dispatch them to entity and application logic
  objects
• Collect information from entity or other control
  objects and dispatch them to boundary objects.

63
Heuristics for Control Objects

• Identify one control object per use case or more
  if the use case is complex
• Identify one control object per actor in the use
  case
• e.g., FRIEND ReportEmergencyControl for the
  FieldOfficer and ManageEmergencyControl for the
  Dispatcher
• The life span of a control object should be
  determined by the use case or extent of user
  session

64
FRIEND Example (Control)

• ReportEmergencyControl
• Manages the report emergency reporting function
  on the FieldOfficerStation. The object is created
  when the FieldOfficer selects the report
  Emergency button.
• ManageEmergencyControl
• Manages the report emergency reporting function
  on the DispatcherStation. This object is created
  when an EmergencyReport is received.
• Two control objects for one Use Case due to
  distribution of FieldOfficer and Dispatcher
  stations

65
Cross-Checking

• Cross-checking use cases and participating
  objects
• Which use cases create this object (i.e., during
  which use cases are the values of the object
  attributes entered in the system)? Which actors
  can access this information?
• Which use cases modify and destroy this object
  (i.e., which use cases edit or remove this
  information from the system)? Which actor can
  initiate these use cases?
• Is this object needed (i.e., is there at least
  one use case that depends on this information?)
• You can use table(s) to report on such
  information.

66
FRIEND Example (cont.)
1 press()
ReportEmergencyControl
1.1 create()
ReportEmergencyForm
1.1.1 create()
2 fillContents()
3 submit()
3.1 submitReport()
3.1.1 create()
EmergencyReport
3.1.2 submitReportToDispatcher()
67
Finding Classes Advice from Authors

• Lethbridge
• You might choose to be liberal in building the
  initial list of classes (keeping all possible
  candidates) or you might choose to be strict
  (keeping only if you are definite)
• Suggestion Be liberal. Easy to eliminate classes
  during a review.
• As a rule of thumb, a class is only needed in a
  domain model if you have to store or manipulate
  instances of it in order to implement a
  requirement.
• Common Difficulty Deciding whether to have
  classes in a domain model that represent actors
• Example Security or Instant Messaging System
• Example Drawing Package
• Example Managing Corporate Accounts.

68
Common Difficulty Example from Cab Lab
ltltinitiategtgt
Log PrebookedJob
Dispatcher
Job
Cab
ltltinitiategtgt
Handle ImmediateJob
Driver
Dispatch PrebookedJob
Driver -driverID -driverMode
Customer
ltltinitiategtgt
Timer
ChangeDriverStatusForm
Create CustomerAccount
ltltinitiategtgt
ChargeCustomerAccountForm
Administrator
69
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

70
Identify Associations

• Identify classes that need to know about another
  class instances,
• e.g., they create, access, destroy instances of
  that class
• e.g., EmergencyReport can be created by
  FieldOfficer
• Association properties Name, Roles,
  Multiplicities, navigation
• An iterative process
• Initial identification
• Then, refinement (analyzing and verifying the
  associations)
• For every association, ask yourself Is it
  relevant to the application ?
• Is it needed to implement some requirement ?
• If there is no requirement, you are simply
  complicating the model.

71
Association Heuristics Initial Identification

• Start with class(es) that are most central to the
  system.
• Start with associations between entity classes.
• Work outwards.
• Initially, examine verb phrases in scenarios and
  Use Case descriptions
• e.g., FieldOfficer submits an EmergencyReport
• Name associations and Roles precisely
• If you omit, association defaults to has (not
  always informative)
• Add sufficient names to make the association
  clear and unambiguous.
• Do not worry about multiplicity until the set of
  associations is stable
• In general, take a non-restrictive approach to
  multiplicity
• Begin with , rather than 1..n
• Dont worry about part-whole (aggregation vs
  composition)
• Do not worry about directionality of association,
  until design
• By default, associations are bi-directional

72
Association Heuristics Refinement

• Eliminate associations that can be derived from
  other associations (avoid redundancy during
  Analysis)
• Analyze multiplicity
• Read every association in both directions. Does
  it make sense ?
• Consider association class for any many-to-many
  association
• Analyze each entity class to see how it is
  identified
• Most entity objects have an identifying
  characteristics
• Use qualifiers as often as possible to identify
  key attributes
• Reduces multiplicity values
• Use sequence diagrams
• Uncover missing associations (no message can be
  sent from one object to another)
• An association is legitimate only if its links
  survive beyond the execution of a single
  operation
• If information does not need to be stored,
  perhaps you can eliminate the association

73
Identify Associations
ltltboundarygtgt ReportEmergencyButton

0..1
ltltentitygtgt Dispatcher
74
Qualification

• The qualifier improves the information about the
  multiplicity of the association between the
  classes.
• Reduces multiplicity by using keys
• the key is called the qualifier
• the association is called a qualified association
• It is used for reducing 1-to-many multiplicity to
  1-1 multiplicity

75
FRIEND Example
76
Common Mistake

• Actions are not associations.

borrows

LibraryPatron
LibraryItem
returns


LibraryPatron
1

Loan

1
LibraryItem
77
Identify Attributes

• The name of the tournament Not all nouns
  become classes
• complete the form by specifying the type
  Not all verbs become associations.
• Attributes are properties of individual objects
• Property is a partial aspect of an object
  (incomplete)
• Identify associations before attributes
• Do not confuse associated objects and attributes
• For every attribute, ask yourself Is it
  relevant to the application ?
• Is it needed to implement some requirement ?
• If there is no requirement, you are simply
  complicating the model.
• Least stable part of analysis object model

78
FRIEND Example

• Describe each attribute in data dictionary
• Name, brief description, type (legal values)

79
Attribute Heuristics (I)

• Properties generally have simple types (or at
  least conceptually atomic)
• If attribute is an object, use association
  instead
• Exceptions Strings, address, date
• e.g., FieldOfficer who authored an
  EmergencyReport
• Word analysis Possessive phrases and adjective
  phrases
• Nouns that are collections are associations, not
  attributes
• Attribute name should not be plural

Person -nameString homeStreet homeCity workStreet
workCity
Person nameString
Address street city

80
Attribute Heuristics (II)

• Attributes should not have an implicit internal
  structure.
• Represent stored state as attribute of entity
  object

Person -nameString getSurname() getFirstName()
Person -surnameString -firstnameString getSurna
me() getFirstName()
81
Generalization

• Eliminate redundancy in the analysis model
• Share attributes, operations
• Dispatchers and Fieldofficers both have
  badgeNumber to identify them within the city.
  They are both PoliceOfficer
• Abstract PoliceOfficer class, containing common
  functionality and attributes

82
PoliceOfficer
ltltboundarygtgt ReportEmergencyButton

0..1
ltltentitygtgt Dispatcher
83
Analysis Example

• Use case Book Flight
• Flow of Events
• User requests flights for src, dest, and date
  with given number of passengers
• System displays all flights on that day with
  availability.
• User selects the desired time
• System reserves enough space and computes costs
• User enters name,address payment
• System confirms booking
• If user wish, include Book Seats.
• Postcondition System issues ticket.
• Exceptions
• Plane is full. Redisplay available flights.
• User cancels selection before payment.

• Use case Book Seat
• Flow of Events
• System displays all available seats on the plane.
• User selects seats.
• System confirms seat selections
• Postcondition Seat is assigned to user.

84
Analysis Example Textual Analysis

• Proper noun None (other than System)
• Common nouns passengers, user, flight, booking,
  ticket, space, seats, plane, time, src, dest,
  number, availability, costs, name, address,
  payment
• Doing verbs requests, displays, selects,
  reserves, computes, confirms,
• Being verbs
• Having verbs for src,dest, date with given
  number of passengers, with availability
• Modal verbs on that day, with availability,
  enough space, all available space
• Adjective desired time, is full

85
Analysis Example Entity Classes
Flight src dest date capacity
User name address

1..
passenger
Flight src dest date capacity
User name address
1..
0..
1..
0..1
Booking
passenger
86
Analysis Example Data Dictionary

• Customer A person who is initiating a booking
• Passenger A person who is actually flying.
• Plane Model A description of a model of plane,
  including seating capacity, distance
• Plane A particular instance of a plane model,
  complete with serial id, service history...
• Scheduled Flight An authorized flight plan from
  a source to destination, along a planned route at
  a particular time of day, but recurring on a
  daily or weekly basis.
• Flight A specific occurrence of a scheduled
  flight, occurring on a particular day, assigned
  with a plane and staff
• Booking A reservation for 1 to n passengers to
  fly on a set of 1 m flights, possibly with
  reserved seating.

87
Analysis Example Version 2
ScheduledFlight src, dest time flightNum
PlaneModel capacity

1
1
1


Plane seatAssignments
Flight date

customer

Person
Booking confirmNum
1

1..

passenger
88
Analysis Example Alternative
ScheduledFlight src,dest time flightNum
PlaneModel capacity

1
1
1
date

0..1
Plane seatAssignments
Flight


passenger
Person name
customer
Booking
0..1
confirmNum
1
89
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships associations and
  attributes (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

90
Modeling Object Behavior

• Sequence diagrams represent behavior from the
  perspective of single use case
• Shows how the behaviour of a use case is
  distributed among participating objects.
• Statechart diagrams capture behavior from the
  perspective of single object
• Focus only on objects with non-trivial behavior
  (multi-modal, state-dependent)
• Help identify missing Use Cases
• Help identify missing objects and/or operations
• Build more formal description of the object
  behavior

91
Incident Statechart

• Are there Use Cases for documenting, closing, and
  archiving Incidents?
• The Active state could be further refined and
  decomposed nested statecharts
• Transitions conditions can and should be
  described more formally. (OCL)

92
ReportEmergency SD
93
ReportEmergency SD II

• New entity object Acknowledgment that we forgot
  during our initial examination of the
  ReportEmergency use case.
• It holds the information associated with an
  Acknowledgment (Entity object) and is created
  before the AcknowledgementNotice boundary object
  (next slide).
• We also need to clarify with the user what
  information is contained by an acknowledgement.

94
ReportEmergency SD III
ReportEmergency
Acknowledgment
Manage

FieldOfficer
Control
Notice
EmergencyControl
acknowledgeReport()
Create()
View()
95
Heuristics

• First column actor who initiates the use case
• Second column boundary object
• Third column control object that manages the
  rest of the use case
• Control objects are created by boundary objects
  initiating use cases
• Other boundary objects are created by control
  objects
• Entity objects are accessed by control and
  boundary objects
• Entity objects never access boundary or control
  objects

96
Change to ReportEmergency

• New Entity object Acknowledgment Response of a
  Dispatcher to a FieldOfficers EmergencyReport.
  Contains resources allocated, predicted arrival
  time
• Modify Step 4 of ReportEmergency flow of events
  description The acknowledgment indicates to the
  FieldOfficer that the EmergencyReport was
  received, an Incident created, and resources
  allocated to the Incident.

97
Breugge
League
League

Owner
1

Attributes
Attributes
Operations
Operations
Tournament
Attributes
Operations
Player
Match


Attributes
Attributes
Operations
Operations
98
An ARENA Sequence Diagram Create Tournament
Breugge
99
Breugge
League
League

Owner
1

Attributes
Attributes
Operations
Operations
Tournament
Attributes
Operations
Player
Match


Attributes
Attributes
Operations
Operations
100
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

101
Object Responsibilities

• Sequence diagrams imply we distribute the
  behavior of the use case across participating
  objects.
• Responsibilities, under the form of operations,
  are assigned to objects
• These operations may be shared by several Use
  Cases remove redundancies but consistency needs
  to be checked
• During analysis, sequence diagrams only focus on
  high-level behavior implementation issues
  should not be addressed at this point

102
Specifying Responsibilities

• Pre-condition Conditions under which operations
  can be executed and yield a correct result
• Post-Condition Conditions that are guaranteed
  true after execution of an operation
• Class invariant Conditions that must remain
  true, at all times, for any instance of a class
• Contract All of the above are referred to as a
  contract
• Sysc-3100
• discussed how contracts can be precisely defined

103
Cross-Checking

• Sequence diagrams can be used to help check the
  completeness / correctness of the use case model
  and class diagrams.
• Which Use Cases create this object? Which actors
  can access this information?
• Which Use Cases modify and destroy this object?
  Which actors initiate these Use Cases?
• Is this object Needed? (at least one Use Case
  depends on this information)

104
Impact on ARENAs Object Model (ctd)
Breugge

• The Sequence Diagram also supplied us with a lot
  of new events
• newTournament(league)
• setName(name)
• setMaxPlayers(max)
• Commit
• checkMaxTournaments()
• createTournament
• Question Who owns these events?
• Answer For each object that receives an event
  there is a public operation in the associated
  class.
• The name of the operation is usually the name of
  the event.

105
Example from the Sequence Diagram
Breugge
createTournament is a (public) operation owned
by Announce_Tournament_Control
createTournament (name, maxp)
106
Breugge
League
League

Owner
1

Attributes
Attributes
Operations
Operations
Tournament
Announce_ Tournament_ Control
Attributes
Operations
Attributes
createTournament (name, maxp)
Player
Match


Attributes
Attributes
Operations
Operations
107
What else can we get out of sequence diagrams?
Breugge

• Sequence diagrams are derived from the use cases.
  We therefore see the structure of the use cases.
  
• The structure of the sequence diagram helps us to
  determine how decentralized the system is.
• We distinguish two structures for sequence
  diagrams Fork and Stair Diagrams (Ivar Jacobsen)

108
Fork Diagram
Breugge

• Much of the dynamic behavior is placed in a
  single object, usually the control object. It
  knows all the other objects and often uses them
  for direct questions and commands.

109
Stair Diagram
Breugge

• The dynamic behavior is distributed. Each object
  delegates some responsibility to other objects.
  Each object knows only a few of the other objects
  and knows which objects can hel with a specific
  behavior.

110
Fork or Stair?
Breugge

• Which of these diagram types should be chosen?
• Object-oriented fans claim that the stair
  structure is better
• The more the responsibility is spread out, the
  better
• However, this is not always true. Better
  heuristics
• Decentralized control structure
• The operations have a strong connection
• The operations will always be performed in the
  same order
• Centralized control structure (better support of
  change)
• The operations can change order
• New operations can be inserted as a result of new
  requirements

111
sysc-4800 Software Engineering

• Overview
• Analysis Concepts
• Different kinds of classes
• Different kinds of relationships
• System boundaries
• Modeling interaction/behavior
• Analysis Process
• Finding objects/classes (heuristics)
• Finding relationships (heuristics)
• Interactions/behavior (heuristics)
• Responsibilities
• Analysis review

112
Analysis Review - Correctness

• Is the data dictionary understandable by the
  user?
• Do abstract classes correspond to user-level
  concepts?
• Are all descriptions in accordance with the
  users definitions
• Do all entity and boundary objects have
  meaningful noun phrases as names?
• Do all use cases and control objects have
  meaningful verb phrases as names?
• Are all error cases described and handled?
• Are system administration functions of the system
  described?

113
Analysis Review - Completeness

• For each object Is it needed by any use case?
  Where is it created, modified, destroyed?
• For each attribute When is it set? What is its
  type? Should it be a qualifier?
• For each association When is it traversed? Why
  was the specific multiplicity chosen? Can
  associations with one-to-many and many-to-many
  multiplicities be qualified?
• For each control object Does it have the
  necessary associations to access the objects
  participating in its corresponding use case?

114
Review-Consistency

• Are there multiple classes or use cases with the
  same name?
• Do model elements with similar names denote
  similar phenomena?
• Are all model elements described at the same
  level of detail?
• Are there classes with similar attributes and
  associations that are not in the same
  generalization hierarchy?

115
Analysis Activities
116
Requirements Analysis Document Template

• 1. Introduction
• 2. Current system
• 3. Proposed system
• 3.1 Overview
• 3.2 Functional requirements
• 3.3 Nonfunctional requirements
• 3.4 Constraints (Pseudo requirements)
• 3.5 System models
• 3.5.1 Scenarios
• 3.5.2 Use case model
• 3.5.3 Object model
• 3.5.3.1 Data dictionary
• 3.5.3.2 Class diagrams
• 3.5.4 Dynamic models
• 3.5.5 User interface
• 4. Glossary/Data dictionary

117
Reading/Analyzing UML Analysis Documents

• Take a look to use cases
• Browse through class diagrams using the data
  dictionary
• Read statecharts where available
• Read sequence diagrams looking at the
  corresponding use case descriptions

118
Consistency Rules
119
Use Case Diagram

• Use case Description Each use case in the use
  case diagram must have a textual description
  indicating
• Use case name, Participating actors, Entry
  conditions, Flow of events (in the right
  sequence), Exit condition, Possible special
  requirements
• Sequence Diagram Each use case in the use case
  diagram must be accompanied with a sequence
  diagram
• There should be consistency between actors/use
  cases relations in the use case diagram and in
  the sequence diagram
• Sequence diagrams of Include / extends use case
  consistent
• Data Dictionary Actors and use cases in the
  diagram must appear in the data dictionary
• Sequence Diagram The services described in a use
  case description (flow of actions) must find a
  realization in a sequence diagram
• Actors, classes, methods and attributes must
  correspond

120
Use Case Description

• Class Diagram Methods, attributes and class
  names appearing in the use case description must
  be consistent with those specified in the class
  diagram
• Data Dictionary The use case name and the actors
  involved must appear in the data dictionary
• Methods, attributes and class names appearing in
  the use case description must be consistent with
  those specified in the data dictionary

121
Sequence Diagram - Class Diagram

• Each object in a sequence diagram must be an
  instance of a class in the class diagram
• Each operation, attribute in a sequence diagram
  must appear in the class diagram and must be
  consistent with it
• Two objects can communicate with messages
  provided there is an association between them

122
Class Diagram - Data Dictionary

• Each class, attribute, operation must be
  described in the data dictionary
• Attribute types and method return types must be
  consistent
• Method signature should be consistent
• Association roles and multiplicities should be
  consistent

123
Statechart - Class Diagram

• Each statechart must describe the behavior of a
  class in the class diagram
• Attributes, operations used in a statechart must
  be defined in the class diagram and consistent
  with it
• Navigation to attributes and methods of other
  classes is possible provided there is an
  association

124
Library Class Diagram (Simplified)
125
LibraryborrowCopy Precondition

• LibraryborrowCopy(uid, cid)
• pre
• self.user-gtexists(user User user.userid
  uid and not user.numberofcopy user.limit )
• and
• self.onShelf-gtexists(onshelf OnShelf
  onshelf.copyid cid)

126
LibraryborrowCopy Postcondition

• LibraryborrowCopy(uid, cid)
• post
• not self.onShelf-gtexists(onshelf OnSelf
  onshelf.copyId cid)
• and
• self.onLoan-gtexists(onloan OnLoan
  onloan.copyId cid)
• and
• self.user-gtexists(user User user.userid
  uid
• and user.numberofcopy user.numberofcopy_at_pre
  1
• and user.onLoan-gtexists(onloan Onloan
  onloan.copyId cid ))

127
Sequence Diagram (BorrowCopy Use Case)
128
Sequence Diagram (BorrowCopy Use Case)