Analysis-Models jjjkkkkjgffffffttui3k3k3j3n

2
Requirements Analysis
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system elements
 establishes constraints that software must meet
 Requirements analysis allows the software engineer
(called an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier
requirement engineering tasks
 build models that depict user scenarios, functional
activities, problem classes and their relationships, system
and class behavior, and the flow of data as it is
transformed.

3
A Bridge
system
description
analysis
model
design
model

4
Rules of Thumb
 The model should focus on requirements that are visible
within the problem or business domain. The level of
abstraction should be relatively high.
 Each element of the analysis model should add to an overall
understanding of software requirements and provide insight
into the information domain, function and behavior of the
system.
 Delay consideration of infrastructure and other non-functional
models until design.
 Minimize coupling throughout the system.
 Be certain that the analysis model provides value to all
stakeholders.
 Keep the model as simple as it can be.

Stakeholders
 Anyone with an interest in the final system
 E.g., end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc.

Exercise: ATM
stakeholders?
 Bank customers
 Representatives of other banks
 Bank managers
 Counter staff
 Database administrators
 Security managers
 Marketing department
 Hardware and software maintenance engineers
 Banking regulators

7
Domain Analysis
Software domain analysis is the identification, analysis,
Software domain analysis is the identification, analysis,
and specification of common requirements from a
and specification of common requirements from a
specific application domain, typically for reuse on
specific application domain, typically for reuse on
multiple projects within that application domain . . .
multiple projects within that application domain . . .
[Object-oriented domain analysis is] the identification,
[Object-oriented domain analysis is] the identification,
analysis, and specification of common, reusable
analysis, and specification of common, reusable
capabilities within a specific application domain, in
capabilities within a specific application domain, in
terms of common objects, classes, subassemblies, and
terms of common objects, classes, subassemblies, and
frameworks . . .
frameworks . . .
Donald Firesmith

Domain specific requirements
 Derived from the context and environment of where
the system will be deployed.
 For example, a train control system has to take into account
the braking characteristics in different weather conditions.
 Might be functional or non-functional.
 If you sell a system to multiple domains you might
have to tweak it for each.
 Domain experts often find these difficult
to articulate, or just assume the developer
knows.

9
Elements of Requirements Analysis

Use Case
Use Cases
s Were Introduced by Ivar
Were Introduced by Ivar
Jacobson
Jacobson in the Beginnig of the 1990s.
in the Beginnig of the 1990s.
“A use case is a specific way of using the system by
performing some part of the functionality. Each use
case constitutes a complete course of events initiated
by an actor, and it specifies the interaction that takes
place between an actor and the system…...
The collected use cases specify all the existing ways of
using the system.”

Grady Booch et al.:
Grady Booch et al.:
If you design a new house and you are reasoning
about how you and your family will use it, this is use
case-based analysis.
You consider the various ways in which you‘ll use
the house, and these use cases drive the design.

12
Some Definitions
Buy Items
UML icon for a use case
 A
A scenario
scenario is a
is a specific
specific sequence of actions
sequence of actions and
and interactions
interactions
between
between actors and the system under discussion
actors and the system under discussion (SuD); it is also
(SuD); it is also
called a
called a use case instance
use case instance. It is
. It is one particular story
one particular story of
of using a system
using a system
 A
A use case
use case is a
is a narrative
narrative documentation that describes the
documentation that describes the sequence
sequence
of events of an actor
of events of an actor (an external agent)
(an external agent) using a system
using a system to complete
to complete
a process
a process
 A use case is a collection of related success and failure scenarios that
describe actors using a system to support a goal.
 They are
They are stories
stories or
or cases of using
cases of using a system. They
a system. They are not
are not exactly
exactly
requirements
requirements or
or functional specifications
functional specifications, but they
, but they illustrate and imply
illustrate and imply
requirements
requirements in the
in the stories they tell
stories they tell.
.
Actor
 Actor:
Actor: is something with behavior, such as a person
is something with behavior, such as a person
(identified by role; a cashier), computer system, or
(identified by role; a cashier), computer system, or
organization
organization.
.

13
(1) Levels of Abstraction: Essential Vs Real (Concrete)
According to the level of detail required at analysis and
design stages.
(2) Amount of Details: High Level and Expanded
High Level Usecases : Brief but structured
Expanded Usecases: Fully dressed and structured
(3) Business Importance: Primary, Secondary, and
Optional)
 Primary use cases represent major common processes,
such as Buy Items.
 Secondary Use cases represent minor or rare processes,
such as Request for Stocking New Product.
 Optional use cases represents processes that may not be
tackled, like: Payment type analysis
Types of Use cases

14
 Header and structure of the use case are typical.
 UML does not specify a rigid format; may be altered to meet the needs
and spirit of documentation – clarity of communication
 Useful to start with high level use cases for a quick start and
understanding of overall major processes.
Example: High-Level Use Case: Buy Items
Use case: Buy Items
Actors: Customers?, Cashiers
Type: Primary
Description: A Customer arrives at a checkout with items
to purchase. The cashier records the purchase
items and collects payment. On completion, the
Customer leaves with the items.
UML and Use Case Format:

15
Use cases are defined to satisfy the user goals of the primary
actors. Hence, the basic procedure is:
 Choose the system boundary (e.g just a software application,
the hardware and application as a unit, an entire organization,
or a dept of the org).
 Identify the primary actors – those having user goals fulfilled
through using services of the system.
 For each (primary actors), identify their user goals.
 Define use cases that satisfy user goals; name them
according to their goal. Usually, user goal-level use cases will
be one-to-one with user goals (with some exceptions!; will be
examined).
Finding Primary Actors, Goals, and Use Cases

16
Choosing the System Boundary
 For this case study, the POS system itself is the SuD;
every-thing outside of it is outside the system boundary,
including the cashier, payment authorization services, and
so on.
 Once the external actors are identified, the boundary
becomes clearer. For example, is the complete
responsibility for payment authorization within the system
boundary? No, there is an external payment authorization
service actor.
Finding Primary Actors and Goals
 It is artificial to strictly linearize the identification of primary
actors before user goals. Sometimes, goals reveal the
actors, or vice versa.
……2

17
Primary and Supporting Actors
 Recall that primary actors have user goals fulfilled through
using services of the system (e.g. roles that people play, the
cashier).
 Why identify? To find user goals, which drive the use
cases.
 In contrast, supporting actors, provide services to the SuD.
For now, the focus is on finding the primary actors, not the
supporting ones (Often a computer system, but could be an
organization or person, Electrical or mechanical devices).
 Why identify? To clarify external interfaces and
protocols.
 Offstage actor – has an interest in the behavior of the use
case, but is not primary or supporting; for example, a
government tax agency.
 Why identify? To ensure that all necessary interests are
identified and satisfied.

18
 Why is the cashier, and not the customer, the primary
actor in the use case Process Sale?
 Why doesn’t the customer appear in the actor-goal
list?
 The answer depends on the system boundary of the
Sud, as illustrated on next slide.
Primary Actor and User Goals
depend on System Boundary

20
Actors and Goals via Event Analysis
Another approach to aid in finding actors, goals, and use
cases is to identify external events.
1. Identify the external events that a system must respond to.
2. Relate the events to actors and use cases.
External Event From Actor Goal
Enter sale line item Cashier Process a sale
Enter payment Cashier or
Customer
Process a sale
……………

21
Actor-based: (easy, simple, systematic)
Event-based: (Difficult)
Summery: Identifying Use Cases
Cashier Log In
Cash Out
Customer Buy Items
Refund Items
EnterItem (to be purchased)
MakePayment
EndSale
Identifying and Relating
with Actor and Use Case ??
(Not straightforward)

22
Starting off an Expanded use case
Start an expanded use case with the following schema:
1. This use case begins when <Actor> <initiates an event >
for example:
1. This use case begins when a customer arrives at a
POST with items to purchase.
This encourages a clear identification of the initiating actor
and event.

23
Example:
Expanded Use Case: Buy Items with Cash
Use case: Buy Items with Cash
Actors: Customers (initiator), Cashiers
Purpose: Capture a sale and its cash payment.
Overview: A Customer arrives at a checkout with items
items and collects a cash payment.
On completion, the customer leaves with the
items.
Type: primary and essential
Cross Reference: Functions: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1…..
Expanded Use Case

24
Typical Course of Events
Actor Action System Response
1. This use case begins when a Cus-
tomer arrives at a POST checkout
with items to purchase.
2. The Cashier records the identifier 3. Determines the item price
from each item. and adds the item information
If there is more than one of the to the running sales transaction.
same item, the Cashier can enter The description and price of the
the quantity as well current item are presented.
4. On completion of item entry, the 5. Calculates and presents the sale
Cashier indicates to the POST that total.
item entry is complete.
6. The Cashier tells the Customer
the total.
Expanded Use Case (2)

25
Typical Course of Events………
7. The Customer gives a cash payment –
the “cash tendered”- possibly greater
than the sale total.
8. The Cashier records the cash 9. Shows the balance due back
to
received amount. the Customer.
10.The Cashier deposits the cash received 11. Logs the completed sale.
and extracts the balance owing. The Cashier
gives the balance owing and the printed
receipt to the Customer.
12. The Customer leaves with the
items purchased.
Expanded Use Case (3)
Alternative Courses
• Line 2: Invalid identifier entered. Indicate error.
• Line 7: Customer didn ‘t have enough cash. Cancel sales
transaction.

26
Notating Decision Points and Branching
1. This use case begins when a Customer
arrives at the POST checkout with items
to purchase.
2.(intermediate steps excluded). . .
3.Customer chooses payment type:
a. If cash payment, see section
Pay by Cash.
b. If credit payment, see section
Pay by Credit.
c. If check payment, see section
Pay by Check
4. Logs the completed sale.
5. Prints a receipt
6. The Cashier gives the receipt to the Customer.
7. The Customer leaves with the items purchased.
Section: Main

27
Section Pay by Cash
1. The Customer gives a cash payment-the
“cash tendered” - possibly greater then
the sale total.
2. The Cashier records the cash tendered. 3. Shows the balance
due
4. The Cashier deposits the cash received and to the Customer.
extracts the balance owing.
The Cashier gives the balance owing to
the Customer.
Alternative Courses
Line 4: Insufficient cash in drawer to pay balance. Ask for cash from
supervisor, or ask Customer for a payment closer to sale total.

28
1. The customer identifies themselves 2. Presents options
3. and so on 4. and so on
1. The Customer inserts their card 2. Prompts for PIN.
3. Enters PIN on key pad 4. Display options menu.
5.and so on. 6. and so on.
Real Use Cases
Concretely describes the process in terms of its real current design, committed to
specific I/O technology etc.
Essential Versus Real Use Cases
Essential Use Cases
• Are expanded use cases, remain relatively free of technology and implementation details
• design decisions are deferred and abstracted. That is, only essential activities and motivations
• High level use cases are always essential in nature due to their brevity and abstraction.
Degree of design commitment
Essential very abstract Real very concrete
<exist on continuum>

29
Design Phase: Real UC
Use cases: Buy Items with Cash
Actors: Customers (initiator), Cashiers
Purpose: Capture a sale and its cash payment.
Overview: A Customer arrives at a checkout with items
items and collects a cash payment.
On completion, the customer leaves with the
items.
Type: primary and real
Cross Reference: Functions: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1,
Real Buy Items-Version 1
REAL USE CASES: Touching the HOW part
 Real/Actual Design in terms of concrete I/O and its implementation
 Only Storyboards (rough UI widgets required, implementation later)
Object Store
Enter Item End Sale
UPC
Make Payment
Total
Quantity
Tendered
Balance
A
C
E
G
H I J
Price
Desc
B
D
F
Window-1

30
.
1. This use case begins when Customer
arrives at the POST checkout with
items to purchase.
2. For each item, the Cashier types in
the Universal Product Code (UPC) 3. adds the item information
in A of Window-1. to the running sales transaction.
If there is more than one of an item,
the quantity may optionally be entered
in E. Then press H after each item entry. The description and price of the
current item are presented in B.
4. On completion of item entry, the and F of Window-1.
Cashier indicates to the POST that item
entry is complete by pressing. 5. Calculates and presents the
widget-I. sale total C.
Object Store
Enter Item End Sale
UPC
Make Payment
Total
Quantity
Tendered
Balance
A
C
E
G
H I J
Price
Desc
B
D
F
Window-1

31
1. For each item, the Cashier types 2. Displays the item price
in the Universal Product Code and adds the item infor-
(UPC) in the UPC input field of mation to the running sales
Window1. They then press the transaction.
“ Enter Item” button with the mouse
OR by pressing the <Enter> key The description and price of
the current item are displayed
in Textbox2 of Window1.
3. Etc. 4. etc.
Real <Buy Items> Use Case

32
Use-Case Diagram
homeowner
Access camera
surveillance via the
Internet
ConfigureSafeHome
system parameters
Set alarm
cameras
SafeHome

Use case diagrams
NextGen
Manage Users
. . .
Cashier
System
Administrator
actor
use case
communication
system boundary
Handle Returns
Payment
Authorization
Service
«actor»
Tax Calculator
«actor»
Accounting
System
Process Rental
Cash In
Process Sale
«actor»
Sales Activity
System
Manage Security
Analyze Activity
«actor»
HR System
notation
for human
and computer
actors

34
Relationships between Use
Cases
1. Generalization - use cases that are specialized
versions of other use cases.
2. Include - use cases that are included as parts
of other use cases. Enable to factor common
behavior.
3. Extend - use cases that extend the behavior of
other core use cases. Enable to factor variants.

35
1. Generalization
 The child use case inherits the
behavior and meaning of the
parent use case.
 The child may add to or
override the behavior of its parent.
parent
child

36
registration
graduate
registration
non-graduate
registration
More about Generalization

37
2. Include
 The base use case explicitly incorporates the
behavior of another use case at a location
specified in the base.
 The included use case never stands alone. It
only occurs as a part of some larger base that
includes it.
base included
<<include>>

38
More about Include
 Enables to avoid describing the same flow of
events several times by putting the common
behavior in a use case of its own.
updating
grades
output
generating
verifying
student id
<<include>>
<<include>>

• The base use case is dependent of the included use case but not the opposite way.
• Functionality shared between two use cases can in this way be extracted out and
described in a separate use case.
Include
Include
Validate
student
Register for
course
“include”
base

Specifying an Inclusion Point
Specifying an Inclusion Point
 Student register for course, main flow of event:
 The use case starts when the student brows the
course register page.
 The user write user name and password.
 Inclusion point: Validate student
 The system presents all possible courses for this
student.
 The student select course and commits the entry by
pressing the Enter button.

student
validate student
for study
register
as
student
enter student in
“student register”
adm
make student
profile
register as student
register as student
Use Case “register as student”:
This use case is started by the student (which at this point is not a
student), which request to be registered as a student. A person
from the administration updates the student register.
Refinement of:
Refinement of:
“include”
“include”
“include”

More On Include
More On Include
 Include is used to define functionality that is common to
several use cases, a modularization technique.
 If we see that a component can be used, we can model this
by a separate use case describing the component.
 A scenario that is an instance of the base use case will
typically contain a sub scenario from the included one.

• If a use case incorporates two ore more clearly different
scenarios - some condition dictates which - this can be
modeled by an extend relation.
• So the extend relationship can be used to model behavior
that the user sees as optional or as an exception on
normal behavior. The base use case can incorporate the
extended behavior under certain conditions otherwise
stand alone.
Types of Relationships Between
Types of Relationships Between
Use Cases
Use Cases:
: Extend
Extend

• You should specify:
– The condition under which the extended use applies
– At which point the condition is tested and the behavior may diverge; This point is
called the extension point.
Extend
Extend - The Notation
- The Notation
Issue Diploma
Extension points
exams not completed
Issue Incomplete
Diploma
“extend”
(exams not complete)
base

Use Case from Booch et al.
Use Case from Booch et al.
Place order
Extension points
set priority
Place
rush order
Validate
user
Track
order
Check
password
“include”
“include”
“extend”
(set priority)

• This relations are very similar, some claim that UML would be better with only one oft them!
• How to select one of them:
– Extend: if you wants to describe extra behavior that is to be used under certain condition; a condition that is tested at run
time.
– Generalization: if you have a specialization of a whole use case.
Extend and Generalization
Extend and Generalization

47
Activity Diagram
Supplements the use
case by providing a
graphical representation
of the flow of interaction
within a specific
scenario

49
Swimlane Diagrams
Allows the modeler to represent the
Allows the modeler to represent the
flow of activities described by the
flow of activities described by the
use-case and at the same time
use-case and at the same time
indicate which actor (if there are
indicate which actor (if there are
multiple actors involved in a specific
multiple actors involved in a specific
use-case) or analysis class has
use-case) or analysis class has
responsibility for the action
responsibility for the action
described by an activity rectangle
described by an activity rectangle

51
Data Modeling
 examines data objects independently of
processing
 focuses attention on the data domain
 creates a model at the customer’s level
of abstraction
 indicates how data objects relate to one
another

52
What is a Data Object?
 a representation of almost any composite information that
must be understood by software.
 composite information—something that has a number of
different properties or attributes
 can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display),
an occurrence (e.g., a telephone call) or event (e.g., an
alarm), a role (e.g., salesperson), an organizational unit
(e.g., accounting department), a place (e.g., a warehouse),
or a structure (e.g., a file).
 The description of the data object incorporates the data
object and all of its attributes.
 A data object encapsulates data only—there is no reference
within a data object to operations that act on the data.

53
Data Objects and Attributes
A data object contains a set of attributes that
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
act as an aspect, quality, characteristic, or
descriptor of the object
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

54
 Domain Model is the most important artifact to
create during Object Oriented Analysis
 Use Case Model is important but its not Object
Oriented.
 OOA is concerned with creating a description of
the domain (concepts) from the perspective of
classification by objects.
 A decomposition of the domain involves an
identification of the concepts, attributes, and
associations that are considered noteworthy.
The result can be expressed in a domain model
(previously called Conceptual Model).
Domain Model

55
Object Versus Function-Oriented Analysis Design
 Decomposition is the primary strategy to deal with the complexity of S/W project.
 Functional decomposition is common in the structured analysis and design.
System can be functionally divided into sub-functions differently by different
people.
 That’s why it is more commonly called as Analysis & Design.
 That’s why a functional hierarchy exists.
 Object oriented decomposition has been mentioned in few (Larman) books but
Object identification or classification are most suitable terms used in the OOA.
 That’s why Object Modeling is more commonly used term as object’s are identified
(they are already there) and modeled in a language rather defined by the analyst.
 That’s why decomposition hierarchy does not exist but a collaboration between
objects.
Catalog
Book Magazine
Librarian
Classification/Decomposition
by Objects/concepts
OO A&D
Lib System
Cataloging Acquisition
Circulation
Decomposition by functions/processes
Structured A&D

56
A quality to appreciate about domain model: a representation of real-
word things, not of software components.
Introduction
Domain Model
Concepts
Associations between concepts
Attributes of concepts
POST
Item
Store
address
name
Sale
date
time
Payment
amount
Sales
LineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
1
1
Captured-on 
Concept
Association
Attributes
Domain Model

57
Domain models are not models of software designs
 No software artifacts, such as a window or a database, unless the domain being
modeled is of software concepts (e.g. graphical user interfaces).
 No responsibilities or methods.
Sale
date
time
real-world concept,
not a software class
SalesDatabase
software artifact; not part
of conceptual model
avoid
software class; not part
of conceptual model
Sale
date
time
print()
avoid

58
 Symbol--words or images representing a concept
 Intention--the definition of a concept
 Extension--the set of examples to which the concept applies.
Sale
date
time
concept's symbol
"A sale represents the event
of a purchase transaction. It
has a date and time."
concept's intension
sale-1
sale-3
sale-2
sale-4
concept's extension
*Concept: is an idea, thing, or object has symbol, intension, and extensions.
Concepts

59
Specification/Description Concepts
• An Item instance represents a physical item in a store; it may even
have a serial number (unique).
• An Item has a description, price, and UPC (Not unique), which are
not recorded anywhere else.
• When a real physical item is sold, a corresponding software instance
of Item is deleted* from “Software land”.
Should we have a single concept or two separate as Item and its description ?
Item
description
price
serial number
UPC
ProductSpecification
description
price
UPC
Item
serial number
Describes Better
Worse
1 *
Conclusion:Add a specification or
description concept (e.g. Product
Specification) when:
(1) Deleting instances of things
(e.g. Item) results in a loss of
information that needs to be
maintained. *
(2) It reduces redundant or
duplicated information.

60
A central distinction between object-oriented and structured analysis:
division by concepts (objects) rather than division by functions.
Domain Model and Decomposition
It is better to overspecify a domain model with lots of fine-grained
concepts, than to underspecify it.
Strategies to Identify Concepts
Store POST Sale

61
Concept Category Example
physical or tangible objects POST, Air plane
specifications, designs, or Production Specification
descriptions of things Flight Description
places Store, Air Port
transactions Sale, Payment,
Reservation
transaction line items SaleLineItem
roles of people Cashier, Pilot
containers of other things Store, Bin, Air Plane
things in a container Item, Passenger
1. Finding Concepts with the Concept Category List
Continue…………

62
other computer or electro CreditCardAuthorizaitonSystem
-mechanical systems external to our AirTrafficControl
system
Abstract noun concepts Hunger, Acrophobia, (Warning)
Organizations SaleDepartment
AirLines
Events Sale, Robbery, Meeting
Flight, Crash, Landing
Processes SellingAProduct
(often not presented as a concept, BookingASeat
but may be)
Rules and policies RefundPolicy
CancellationPolicy
More ……Concept Category List (2)
Continue…………

63
Catalogs ProductCatalog
PartsCatalog
Records of finance, work, contracts, Receipt, Ledger,
EmploymentContract
legal matters MaintenanceLog
Financial instruments and services LineOfCredit
Stock
Manuals, books EmployeeManual
RepairManual
More Concepts with Category List (3)

64
Care must be applied with this method; a mechanical noun-to-concept mapping isn’t
possible, and words in natural languages are ambiguous (especially English).
2. Finding Concepts with Noun Phrase Identification
items to purchase.
2. The Cashier records the universal 3. Determines the item price
product code (UPC) from each item. and adds the item information
to the running sales transaction.
the Cashier can enter the quantity as well. The description and price of the
current item are presented.
Identifying nouns and noun phrases in textual description of problem domain as
candidate concept or attribute.
 Expanded use cases are good candidates for nouns based concept or attribute
items to purchase.
2. The Cashier records the universal 3. Determines the item price
product code (UPC) from each item. and adds the item information
to the running sales transaction.
the Cashier can enter the quantity as well. The description and price of the
current item are presented.

65
Resolving Similar Concepts - POST versus Register
POST Register
or?
similar concepts with
different names
Sale
Records 
1
*
Sale
Records 
1
*
Rule of thumb, a domain model is
not absolutely correct or wrong,
but useful tool of communication.
Both POST and Register are equally
useful terms but POST will give a better
implementation view.

66
If in doubt, make it a separate concept.
If we do not think of some concept X as a number or text in the real
world. X is probably a concept, not an attribute.
A Common Mistake in Identifying Concepts: Attribute OR Concept?
Flight Airport
name
Flight
destination
or... ?
Another Example
Worse
Flight
date
number
time
Airport
name
Flies-to
1
*
Many flights to a destination
Some being booked,
cancelled, etc.
Flight
date
time
Flight Description
number
Airport
name
Describes-flights-to
Described-by
Better
1
*
1
*
Requires specific Flights to be
separated from its description

67
Report Objects– Should include receipt in the model?
 A receipt is a report of a sale, derived from other sources. This is one reason to
exclude it.
 A receipt has a special role (confers the right to the bearer of the receipts to
return). This is a reason to show it in the model (but during return items use
case).
The Point-of-Sale Domain Model (concepts only: in UML static structure)
Store
POST Sale
Item
Payment
Sales
LineItem
Cashier Customer Manager
Product
Catalog
Product
Specification

68
1. using the concept category list and noun phrase identification
related to the current requirements under consideration.
 2. Draw them in a domain model.
3. Add associations to record relationships (for which there is a
need to preserve some memory.)
4. Add attributes (to fulfill the information requirements)
Domain Modeling Guidelines
How to make a Domain Model
UML static structure is being used as “concept” to refer to real-world things,
and “class” will be used to refer to software specifications and
Implementations (design class).

69
Consider including the following association:
• knowledge of the relationship needs to be preserved for some
duration (“need-to-know” associations).
• Associations derived from the Common Associations List.
Criteria for Useful Associations
Sale
POST
Records-current
1 1
association
Associating Concepts
Association is a relation b/w concepts that indicates some meaningful and interesting connection

70
Category Examples
Common Associations List (1)
Drawer-POST
Wing-Airplane
A is a physical part of B.
SaleLineItem-sale
FlightLeg-FlightRoute
A is a logical part of B
POST-store, item-shelf
Passenger-Airline
A is physically contained
in B
Item description-catalog
Flight – flight_schedule
A is logically contained in B
ItemDescription- Item
FlightDescription- Flight
A is a description for B
Sale line item-Sale
Maintenance job -
maintainancelog
A is a line item of a
transaction or report B

71
A is a known/logged/
recorded/ reported/captured
in B
Sale-POST
Reservation-
Flightmanifest
A is member of B Cashier-store
Pilot-Airplane
A is an organizational
subunit of B
Department-store
Maintenance-airline
A communicates B Customer-Cashier
ReservationAgent-
Passenger
A uses or manages B Cashier-POST
Pilot-Airplan
Category Examples

72
Category Examples
A is related to a
transaction B
Customer-Payment
Passenger-ticket
A is a transaction
related to another
transaction B
Payment--Sale
Reservation--Cancellation
A is next to B POST--POST
City—City
A is owned by B POST—Store
Plane--Airline

73
Sale
POST
Records-current
1 1
multiplicity
association name

-"direction reading arrow"
-has no meaning except to indicate direction of
reading the association label
-often excluded
Inherently bi-directional
•Not a statement about connection b/w s/w entities (not implementation guide).
UML Association

74
High Priority Association
• A is a physical or logical part of B
• A is physically or logically contained in B.
• A is recorded in B.
Association Guidelines
• Finding concepts is much more important than finding associations.
• More time should be devoted to identifying concepts, not associations.
• Focus associations for which knowledge of the relationship needs to be
preserved for some duration (“need to know” associations).
• Avoid redundant (or derivable associations at this level).
Roles
Each end of an association is called a role. Roles may optionally have
• name
• multiplicity
• navigability

76
Item
Store Stocks
*
multiplicity of the role
1
Multiplicity
How many instances of a type A can be associated with one instance of B.
zero or more;
"many"
one or more
one to forty
exactly five
T
T
T
T
*
1..*
1..40
5
T
3, 5, 8 exactly three,
five or eight

77
Naming Associations
1. based on a TypeName-VerbPhrase-TypeName format
2. verb phrase creates a sequence that is readable and
meaningful
3. verb phrase should have –default direction left-right or top-
bottom
Supervises
Person
Airline
Employs
1..*
Flight
Assigned-to
Plane
*
 Assigned-to
*
*
1
1
1 1
Store
Contains
Sale
POST Captures
1..*
1..*
Payment
Paid-by
1
1
1 1
Note

78
Multiple Associations Between Two Types
Flight Airport
Flies-to
Flies-from
*
* 0..1
1
Unforgettable Relationships in the Store
POST Captures Sale In order to know the current sale,
generate a total, print a receipt.
Sale Paid-by
Payment
In order to know if the sale has
been paid, relate the amount
tendered to the sale total, and print
a receipt
ProductCatalog
Records
ItemSpecification
In order to retrieve an
ItemSpecification, given a UPC
Teacher <teaches >Student
<has-TA>

79
Category Examples
A is physical part of B. Not applicable
A is a logical part of B SalesLine item--Sale
A is logically contained in B ProductSpecification-Product-
Catalog, ProductCatalog-Store
A is physically contained
in/on B
POST--Store, item--Shelf
A is a description for B ProductSpecificaiton--Item
A is a line item of a
transaction or report B
SaleLineItem-Sale
Applying the Category of Associations to POST
Checklist (1)

80
A is known/logged/record/
reported/captured in B
(Completed)Sale--Store
(current) Sale-POST
A is member of B Cashier--Store
A is an organizational subunit
of B
Not applicable
A uses or manages B
Cashier--POST
Manger - POST
Manager-Cashier (but
probably not applicable)
A communicate with B Customer-Cashier
Category Examples
Checklist (2)

81
A is related to a
transaction B
Customer--Payment
Cashier-Payment
A is a transaction
related to another
transaction B
Payment--Sale
A is next to B POST--POST, but
probably not applicable
A is owned by B POST--Store
Category Examples
Checklist (3)

82
POST
Item
Store
address
name
Sale
date
time
Payment
amount
Sales
Lineitem
quantity
Cashier
Customer
Manager
Product
Catalog
Product
Specification
description
price
UPC
Stocks
*
Contains
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Entered-by
Used-by
Logs-
completed
*
POST Domain Model

83
Domain model is a representation of real-word things, Any statement regarding
attributes should be interpreted in the context of real-world entities.
Attributes
Include those:
 for which the requirement (for example, use cases) suggest or imply a need to
remember information.
 things which are not associations (but valid attributes)
UML Attribute Notation
Sale
date
startTime : Time
attributes
Adding Attributes

84
Flight
Flight
destination
Worse
Better
Flies-to Airport
1 1
destination is a complex
concept
Relate concepts with an association, not with an attribute
Keep attributes simple………..

85
Design Creep: No Attributes as Foreign Keys
Cashier
name
currentPOSTNumber
Cashier
name
POST
number
Uses
Worse
Better
a "simple" attribute, but being
used as a foreign key to relate to
another object
1 1
Relating objects by foreign key–just one approach
How associations relate objects: wait until design phase.

86
Primitive VS Non Primitive Data Types
A data type is a classification of data, which can store a specific type of
information. Data types are primarily used in computer programming, in
which variables are created to store data. Each variable is assigned a data
type that determines what type of data the variable may contain.
The term "data type" and "primitive data type" are often used
interchangeably. Primitive data types are predefined types of data, which are
supported by the programming language. For example, integer, character,
and string are all primitive data types. Programmers can use these data
types when creating variables in their programs. For example, a programmer
may create a variable called "lastname" and define it as a string data type.
The variable will then store data as a string of characters.
Non-primitive data types are not defined by the programming language, but
are instead created by the programmer. They are sometimes called
"reference variables," or "object references," since they reference a memory
location, which stores the data. In the Java programming language, non-
primitive data types are simply called "objects" because they are created,
rather than predefined. While an object may contain any type of data, the
information referenced by the object may still be stored as a primitive data
type.

87
Represent what may initially be considered a primitive data type
(such as a number or string) as a non-primitive type if:
• It is composed of separate sections.
phone number, name of person
• There are operations usually associated with it.
such as parsing or validation.
• It has other attributes.
promotional price could have a start and end date
• It is a quantity with a unit.
payment amount has a unit of currency
Non-primitive Attribute types

88
Primitive/Non-primitive Attribute: Analysis of POST
 The UPC should be non primitive UPC type, because it can be check
sum validated and may have other attributes (such as the manufacturer
who assigned it).
 The price and amount attributes should be non-primitive Quantity
types because they are quantities in a unit of currency.
 The address attribute should be a non-primitive Address type because
it has separate sections.
OK
OK
UPC
Product
Specification
Product
Specification
upc : UPC
1
* Address
Store
Store
address : Address
1
*
UPC should be shown as attribute (being pure data value) or as concept (being
non-primitive)?? NO correct Answer. Choice should be made what is to be
communicated.

89
Keep attributes simple
simple attributes or pure data values.
types include:
Boolean, Data, Number, String(Text), Time
Other common types include:
Address, Color, Geometric (point, rectangle,…), Phone number,
Social Security Number, Universal Product Code(UPC), ZIP or
postal codes enumerated types.
Cashier
name
currentPOST
Worse not a "simple" attribute
Cashier
name
POST
number
Uses
Better 1 1

90
Modeling Attribute Quantities and Units
Payment
amount : Number
Payment Quantity
amount : Number
Unit
...
Payment
amount : Quantity
Has-amount
1
*
Is-in
1
*
usable, but not
flexible or robust
quantities are pure data
values, so suitable to show
in attribute section
better

91
• requirements specifications
• current use cases under consideration
• simplification, clarification, and assumption documents
Attributes in the Point-of-Sale Model
Product
Catalog
Product
Specification
Manager
Sale
date : Date
Manager
Sales
LineItem
Manager
Customer
Manager
Cashier
Quantity:Integer
Store
POST Item
Address : Address
name :Text
Payment
Amount : Quantity Description : Text
price : Quantity
upc : UPC
Can be found from

92
Point of Sale Domain Model
POST
Item
Store
address
name
Sale
date
time
Payment
amount
Sales
LineItem
quantity
Cashier
Customer
Manager
Product
Catalog
Product
Specification
description
price
UPC
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Logs-
completed

*
 Records-sales-on
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 1
1

93
What is a Relationship?
 Data objects are connected to one another in
different ways.
 A connection is established between person and car
because the two objects are related.
• A person owns a car
• A person is insured to drive a car
 The relationships owns and insured to drive
define the relevant connections between
person and car.
 Several instances of a relationship can exist
 Objects can be related in many different ways

94
ERD Notation
(0, m) (1, 1)
object
object object
object
relationship
relationship
1
1 2
2
One common form:
One common form:
(0, m)
(0, m)
(1, 1)
(1, 1)
object
object1
1 object
object2
2
relationship
relationship
Another common form:
Another common form:
attribute
attribute

95
Class-Based Modeling (Design)
 Class-based modeling represents:
 objects that the system will manipulate
 operations (also called methods or services) that will
be applied to the objects to effect the manipulation
 relationships (some hierarchical) between the objects
 collaborations that occur between the classes that are
defined.
 The elements of a class-based model include
classes and objects, attributes, operations, CRC
models, collaboration diagrams and packages.

96
CRC Models
 Class-responsibility-collaborator (CRC) modeling
[Wir90] provides a simple means for
identifying and organizing the classes that are
relevant to system or product requirements.
Ambler [Amb95] describes CRC modeling in
the following way:
 A CRC model is really a collection of standard index
cards that represent classes. The cards are divided
into three sections. Along the top of the card you
write the name of the class. In the body of the card
you list the class responsibilities on the left and the
collaborators on the right.

97
CRC Modeling
Class:
Description:
Responsibility: Collaborator:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
incorporates walls, doors and windows
shows position of video cameras
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
Wall
Camera

98
Identifying Analysis Classes
Identifying nouns and noun phrases in textual description of problem domain as
candidate concept or attribute.
Care must be applied with this method; a mechanical noun-to-concept mapping
isn’t possible, and words in natural languages are ambiguous (especially
English).
If we do not think of some concept X as a number or text in the real
world. X is probably a concept, not an attribute.

99
Manifestations of Analysis Classes
 Analysis classes manifest themselves in one of the following
ways:
• External entities (e.g., other systems, devices, people) that produce
or consume information
• Things (e.g, reports, displays, letters, signals) that are part of the
information domain for the problem
• Occurrences or events (e.g., a property transfer or the completion
of a series of robot movements) that occur within the context of
system operation
• Roles (e.g., manager, engineer, salesperson) played by people
who interact with the system
• Organizational units (e.g., division, group, team) that are relevant
to an application
• Places (e.g., manufacturing floor or loading dock) that establish
the context of the problem and the overall function
• Structures (e.g., sensors, four-wheeled vehicles, or computers)
that define a class of objects or related classes of objects

100
Defining Attributes
 Attributes describe a class that has been
selected for inclusion in the analysis model.
 build two different classes for professional baseball
players
• For Playing Statistics software: name, position, batting
average, fielding percentage, years played, and games
played might be relevant
• For Pension Fund software: average salary, credit
toward full vesting, pension plan options chosen,
mailing address, and the like.

101
Defining Operations
 Do a grammatical parse of a processing
narrative and look at the verbs
 Operations can be divided into four broad
categories:
 (1) operations that manipulate data in some way
(e.g., adding, deleting, reformatting, selecting)
 (2) operations that perform a computation
 (3) operations that inquire about the state of an
object, and
 (4) operations that monitor an object for the
occurrence of a controlling event.

Classes
 The three class types in the Unified Process
are
 Entity classes
 Boundary classes
 Control classes
 UML notation

Entity Classes
 An entity class models information that is long lived
 Examples:
 Account Class in a banking information system
 Painting Class
 Mortgage Class and Investment Class
 Instances of all these classes remain in the information
system for years

Boundary Classes
 A boundary class models the interaction between the
information system and its actors
 Boundary classes are generally associated with input
and output
 Examples:
 Purchases Report Class and Sales Report Class
 Mortgage Listing Class and Investment Listing Class

Control Classes
 A control class models complex computations
and algorithms
 Examples:
 Compute Masterpiece Price Class,
 Compute Masterwork Price Class, and
 Compute Other Painting Price Class

106
Responsibilities
 Each responsibility should be stated as generally as
possible
 Information and the behavior related to it should reside
within the same class
 Information about one thing should be localized with a
single class, not distributed across multiple classes.
 Responsibilities should be shared among related
classes, when appropriate.

107
Collaborations
 Classes fulfill their responsibilities in one of two ways:
 A class can use its own operations to manipulate its own
attributes, thereby fulfilling a particular responsibility, or
 a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class
can fulfill each responsibility itself

10
8
Heading toward OOP: Generalization and type definition
A super type definition is more general or encompassing than a subtype definition.
Cash
Payment
Credit
Payment
Check
Payment
Payment
amount : Money

10
9
Composition:
As we know, inheritance gives us an 'is-a' relationship. To
make the understanding of composition easier, we can
say that composition gives us a 'part-of' relationship.
Composition is shown on a UML diagram as a filled
diamond (see Figure 1).
If we were going to model a car, it would make sense to say that an engine is part-of a car. Within composition, the
lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed
along with it. So how do we express this in C#?
public class Engine
{
. . .
}
public class Car
{
Engine e = new Engine();
.......
}
As you can see in the example code above, Car manages the lifetime of Engine.

11
0
Aggregation:
If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a'
relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we
need an example.
The CRM system has a database of customers and a separate database that holds all addresses within a geographic
area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say
that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does
the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled
diamond (see Figure 2).
So how do we express the concept of aggregation in C#? Well, it's a little different to composition. Consider the following code:
public class Address
{
. . .
}
public class Person
{
private Address address;
public Person(Address address)
{
this.address = address;
}
. . .
}
Person would then be used as follows:
Address address = new Address();
Person person = new Person(address);
or
Person person = new Person( new Address() );
As you can see, Person does not manage the lifetime of Address. If Person is destroyed, the Address still exists. This scenario
does map quite nicely to the real world.
Conclusion:
As I said at the beginning of the article, this is my take on composition and aggregation. Making the decision on whether to use

111
Associations and Dependencies
 Two analysis classes are often related to one
another in some fashion
 In UML these relationships are called associations
 Associations can be refined by indicating multiplicity
(the term cardinality is used in data modeling
 In many instances, a client-server relationship
exists between two analysis classes.
 In such cases, a client-class depends on the server-
class in some way and a dependency relationship is
established

112
Dependencies
Camera
DisplayWindow
{password}
<<access>>

113
Item
Store Stocks
*
multiplicity of the role
1
Multiplicity
How many instances of a type A can be associated with one instance of B.
zero or more;
"many"
one or more
one to forty
exactly five
T
T
T
T
*
1..*
1..40
5
T
3, 5, 8 exactly three,
five or eight

114
Multiplicity
WallSegment Window Door
Wall
is used to build
is used to build
is used to build
1..*
1 1 1
0..* 0..*

11
5
Add details in Notes
Class Name
attribute
attribute : type
attribute : type = initial value
classAttribute
/derivedAttribute
...
method1()
method2(parameter list) : return type
abstractMethod()
+publicMethod()
-privateMethod()
#protectedMethod()
classMethod()
...
java.awt.Font
plain : Integer = 0
bold : Integer = 1
name : String
style : Integer = 0
...
+getFont(name : String) : Font
+getName() : String
...
java.awt.Toolkit
#createButton(target : Button) : ButtonPeer
...
+getColorModel() : ColorModel
...
Class member details
classAttribute: Constants?
classMethod: Constructor/destructor
AbstractMethod: Pure Virtual
ClassMethod: Internal (not as Interface)
*

11
6
SalesLineItem
quantity : Integer
subtotal()
ProductCatalog
specification()
ProductSpecification
description : Text
price : Quantity
upc : UPC
Store
address : Address
name : Text
addSale()
Payment
amount : Quantity
Contains
1..*
Contains
1..*
POST
endSale()
enterItem()
makePayment()
Sale
date : Date
isComplete : Boolean
time : Time
becomeComplete()
makeLineItem()
makePayment()
total()
Captures
Houses
Uses
Looks-in
Paid-by
Describes
1 1
1
1 1
1
1
1
1
1
1
1
1
*
A dependency of POST knowing about
ProductSpecification.
Recommended when there is parameter,
global or locally declared visibility.
Logs-completed *
1
CLASS DIAGRAM: Dependency relationship indicating non-attribute visibility

117
Analysis Packages
 Various elements of the analysis model (e.g., use-cases,
analysis classes) are categorized in a manner that
packages them as a grouping
 The plus sign preceding the analysis class name in each
package indicates that the classes have public visibility
and are therefore accessible from other packages.
 Other symbols can precede an element within a
package. A minus sign indicates that an element is
hidden from all other packages and a # symbol indicates
that an element is accessible only to packages
contained within a given package.

11
8
Products
1..*
Core::
Store
Stocks
*
Describes
*
Sales::
SalesLineItem
Described-by *
Records-sale-of
0..1
Product
Specification
description
price
UPC
ProductCatalog
Item
1
1
1
1
1
Products

11
9
Sales
Cashier
Customer
1..*
SalesLineItem
/quantity
Sale
date
isComplete
time
Initiates
Core::
POST
Records-sales-on
Captured-on
Core::
Store
Logs-completed
*
1
1
1
1
1
1
1
1
Sales

12
0
Authorization Transactions
CreditPayment
Approval
Request
CheckPayment
Approval
Request
Payment
Authorization
Request
CreditPayment
Approval
Reply
CheckPayment
Approval
Reply
CreditPayment
Denial
Reply
CheckPayment
Denial
Reply
Payments::
Authorization
Service
Sends Receives
Payments::
CreditPayment
Payments::
CheckPayment
Payment
Authorization
Transaction
date
time
Core::
Store
Payment
Authorization
Reply
Receives
*
Sends
*
* *
1
1
1
1
1
1
1
1
1
1
1 1
1
1 1
1
Authorization Transaction
A Package can have an interface

121
Analysis Packages
Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building
+VisualEffect
+Scene
Characters
+Player
+Protagonist
+Antagonist
+SupportingRole
RulesOfTheGame
+RulesOfMovement
+ConstraintsOnAction
package name

122
Reviewing the CRC Model
 All participants in the review (of the CRC model) are given a subset of the CRC model
index cards.
 Cards that collaborate should be separated (i.e., no reviewer should have two
cards that collaborate).
 All use-case scenarios (and corresponding use-case diagrams) should be organized
into categories.
 The review leader reads the use-case deliberately.
 As the review leader comes to a named object, she passes a token to the person
holding the corresponding class index card.
 When the token is passed, the holder of the class card is asked to describe the
responsibilities noted on the card.
 The group determines whether one (or more) of the responsibilities satisfies the
use-case requirement.
 If the responsibilities and collaborations noted on the index cards cannot accommodate
the use-case, modifications are made to the cards.
 This may include the definition of new classes (and corresponding CRC index
cards) or the specification of new or revised responsibilities or collaborations on
existing cards.

Analysis-Models jjjkkkkjgffffffttui3k3k3j3n

More Related Content

Similar to Analysis-Models jjjkkkkjgffffffttui3k3k3j3n

Recently uploaded

Analysis-Models jjjkkkkjgffffffttui3k3k3j3n

Editor's Notes