L7_primaryClass
CMPT 275
Software Engineering
Requirements Analysis Phase
Requirements Analysis Activity
(Identifying Objects, Scenarios)
Janice Regan, 2008-2014 1
Requirements Analysis
You made a list of functional requirements
Describe the required interactions between the system and its environment (independent of implementation)
You made list of non-functional requirements
QUALITY REQUIREMENTS: Usability, reliability, performance, maintainability
CONSTRAINTS or PSEUDO REQUIREMENTS:
Implementation (tools, languages), interface (to external systems), operation (admin, management), packaging, Legal
2 Janice Regan, 2008-2014
Requirements Analysis
Now you need to validate and verify your requirements to assure that they are
Complete: all required features must be described
Consistent: no two requirements in the specification may contradict each other
Unambiguous: no requirement can be interpreted in two different and contradictory ways
Correct: Only features desired by the client / developer are included not unintended extra features (problems)
3 Janice Regan, 2008-2014
Requirements Analysis
You continued to build your analysis model and verify/validate your requirements by
Identifying the actors for your system
Building a system context diagram to clarify what is part of your proposed system
Identifying and developing informal scenarios that describe all functions of your system
Building use cases based on groups of related informal scenarios
Building a functional model of your system by investigating relationships between use cases and actors and making a use case diagram
4 Janice Regan, 2008-2014
Requirements Analysis Activity
Client/User
Software
Developer
Update SRS
Use Case Centered Development (UCCD)
Questions
Janice Regan, 2008-2014
Class
Diagram
Use Case
Diagram
Use Cases
Scenarios
Primary
Classes
State
Diagram
System
Context
Diagram
5
UML: Unified Modeling Language
Used in this course for analysis models of
System functionality
use case diagrams, use cases and scenarios
Objects and their static relationships
class diagrams, analysis models
Dynamic behavior
state diagrams, collaboration diagrams sequence diagrams
Janice Regan, 2008-2014 6
From use cases to classes
Consider one use case, make a class diagram
1.
Identify primary classes to describe the objects involved in a use case
2.
Add the relationships between these classes extracted from the use case and / or the requirements satisfied by the use case
Consider additional use cases one by one, adding the additional primary classes and relationships between classes
7 Janice Regan, 2008-2014
Primary Classes (objects)
Primary Classes are abstractions that describe the attributes and behaviors of sets of objects
According to the rational unified process (RUP)
Primary classes can be of one of three types,
Primary Entity classes represent entities
(objects) present in conceptualization
Primary Boundary Classes model interfaces with external entities (actors)
Primary Control Classes model coordination and sequencing of events/calculations and manipulation of instances of entity classes
8 Janice Regan, 2008-2014
From use cases to classes
For the Rational Unified Process
For each use case need at least one interface class
For each used case need one (rarely more) control class
For each use case identify primary entity classes to describe the objects involved
Make a class diagram for each class, then combine. Or make a analysis model for one use case, then add additional use cases
Janice Regan, 2008-2014 9
UML for RUP analysis models
Entity Classes
Boundary Classes
Control Classes
Janice Regan, 2008-2014 10
Use case diagram for ATM
Deposit
Transfer
Bank customer database
Withdraw
Identified primary entity class, account
Janice Regan, 2008-2014 11
Example: ATM analysis model
dispenser withdrawal
Cashier interface
Database query or response translator
Database query or response
Bank customer
Money receptor transfer account database
12 Janice Regan, 2008-2014 deposit
Example: ATM analysis model
<<Boundary>> dispenser
<<control>> withdrawal
<<entity>> account
<<Boundary>>
Cashier interface
<<control>> transfer transfer <<Boundary>>
Database interface
<<Boundary>> receptor
Janice Regan, 2008-2014
<<control>> deposit
13
Primary Entity Classes
Model phenomena or concepts
real life objects or events in the application domain
Other objects, events or concepts handled by the system
Require long term or persistent storage of information describing their instances (objects).
May be passive or active (encapsulate complex behavior related to the information it represents)
Isolate changes to the data they represent
14 Janice Regan, 2008-2014
Identifying Primary Entity Classes
Look for application domain (real world) things and roles that the use case is tracking or manipulating
Look for application domain (real world) events that the use case is tracking or manipulating
Look for recurring references to objects in the use case (recurring nouns)
15 Janice Regan, 2008-2014
Identifying Primary Entity Classes
To identify entities that should be represented by primary classes select nouns from the use case and functional requirements for the use case, inspect each noun (start with recurring nouns) for the following properties
Retained information
Common attributes (different instances)
Multiple attributes
Needed services
Common operations
16 Janice Regan, 2008-2014
Primary Entity Class ?
Retained information
Primary entity classes require long term or persistent storage of information describing their instances (objects).
Consider some examples from the LMS
Patron
Home phone number of each patron
Book
All of these examples require persistent storage of information describing their instances
17 Janice Regan, 2008-2014
Primary Entity Class ?
Multiple attributes, Common attributes
Is there more than one attribute (other noun) describing the candidate for primary class?
Home phone number of patron ? NO
Book (title, publisher, call number, …)
Patron (type, home phone #, address …)
Can these attributes be used to describe each object in the candidate primary class?
YES (for Book and Patron)
18 Janice Regan, 2008-2014
Primary Entity Class ?
Needed services, common services
Are operations needed to manipulate the persistent data?
Do such operations need to be available to other classes?
Books, patrons and home phone numbers must be added, removed, and information describing them must be updated. Not enough, what else
Books and patrons must have services to update their values when a patron checks out, checks in, reserves, or requests a book.
19 Janice Regan, 2008-2014
Boundary Classes
Model the interaction of a system and its actors
Receiving information from the actor
Presenting information to the actor
Represent abstractions of API’s, sensors, input
/ output devices, external data repositories, forms …
Model conceptually what requests and information exchanged (no details of how or interface, just what)
Each boundary class should be associated with at least on actor. Each actor should be associated with at least one boundary class
20 Janice Regan, 2008-2014
Identifying Boundary Classes
Actor interfaces with parts of the system
(ATM client interface)
Identify forms needed to enter data
(Ballot entry form)
Identify messages (notices) used to respond to actor input
Janice Regan, 2008-2014 21
Control Classes
Control complex sequences of events or calculations
DO NOT DO calculations/tasks
USE functionality of classes, coordinating execution order of tasks done by and events important to the entity classes (>2) involved
Do not usually represent a concrete object in the real world
Do not deal with interaction with actors
The lifespan of the object should cover the use case duration or the duration of the user session
22 Janice Regan, 2008-2014
Support Classes
Container classes
e.g.: List and Hash Table classes
Service classes
e.g.: Stream classes
They are not present in conceptualization of software system
The need for these classes identified during design
Janice Regan, 2008-2014 23
Formal Scenario Development
Scenarios are derived from use cases
Scenarios are like informal scenarios, but are more formally structured
Use cases are abstract because they do not reference specific values
Scenarios are concrete because they do reference specific and plausible values
Multiple scenarios may be required for a single use case
24 Janice Regan, 2008-2014
Example: Scenario #1
Use Case Name: CheckInResource (#7)
Scenario: Paul returns an overdue book by coming to the library counter.
Preconditions:
Eva the Librarian has successfully gained access to the LMS.
LMS is ready to go (DB has been populated and
LMS has been initialized).
Options screen is displayed
Janice Regan, 2008-2014 25
Example: Scenario #1 (cont)
Main flow of events:
Patron Paul (a student) comes up to the counter and wishes to return the Quantum Physics book he borrowed the previous semester.
Eva the librarian takes the book Paul is handing out to her selects CHECKINRESOURCE option and types in its valid Dewey call number.
The LMS displays the information related to the
Quantum Physics book on the screen and lets
Eva know that Paul owes the library $5 (max.).
26 Janice Regan, 2008-2014
Example: Scenario #1 (cont)
Main flow of events: (cont)
Eva notifies Paul of his overdue charge and
Paul, after searching throughout all his pockets, produces a $5 bill.
Eva makes sure that Paul's record is now clean and that no one has requested the book. Since no one has, Eva verifies by looking at the screen that the book has been checked in properly.
Paul wishes Eva "Good day" and departs.
27 Janice Regan, 2008-2014
Example: Scenario #1 (cont)
Post conditions:
Paul’s record is now showing that he has returned the Quantum Physics book and that he has paid the overdue charge. The
Quantum Physics book has now a status of
"reshelve", today's date as a date of return, date of loan has been cleared and so as the due date.
NO NEED FOR EXCEPTIONAL FLOW OF EVENTS!!!
Each exceptional flow of events would be another scenario
28 Janice Regan, 2008-2014
Example: Scenario #2
Use Case Name: CheckInResource (#7)
Scenario: Paul returns an overdue book by putting it in the return box.
Preconditions:
Eva the Librarian has successfully gain access to the LMS.
LMS is ready to go (DB has been populated and LMS has been initialized).
29 Janice Regan, 2008-2014
Example: Scenario #2 (cont)
Main flow of events
Patron Paul (a student) has deposited the
Quantum Physics book he borrowed the previous semester in the return box.
Eva the librarian takes the book from the return box and types in its Dewey call number.
Janice Regan, 2008-2014 30
Example: Scenario #2
Main flow of events (Cont)
The LMS displays the information related to the Quantum Physics book on the screen and lets Eva know that the borrowing patron Paul owes the library $5. Eva makes sure that
Paul's record reflects such overdue charge.
Then Eva ensures that no one has requested the book. Since no one has, Eva verifies looking at the screen that the book has been checked in properly.
31 Janice Regan, 2008-2014
Example: Scenario #2
Post conditions:
Paul record now showing an overdue charge of $5 (since it was overdue by quite a few weeks). The Quantum Physics book has now a status of "reshelve", today's date as a date of return, date of loan has been cleared and so as the due date.
32 Janice Regan, 2008-2014
