CMPT 275 Software Engineering

1
CMPT 275Software Engineering

• Requirements Analysis Phase
• Requirements Analysis Activity (Identifying
  Objects, Scenarios)

2
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

3
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)

4
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

5
Requirements Analysis Activity
Software Developer
Client/User
Update SRS
Use Case Centered Development (UCCD)
Questions
Use Case Diagram
Use Cases
System Context Diagram
Class Diagram
Primary Classes
Scenarios
State Diagram
6
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

7
From use cases to classes

• Consider one use case, make a class diagram
• Identify primary classes to describe the objects
  involved in a use case
• 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

8
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

9
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

10
UML for RUP analysis models

• Entity Classes
• Boundary Classes
• Control Classes

11
Use case diagram for ATM

• Identified primary entity class, account

Deposit
Transfer
database
Bank customer
Withdraw
12
Example ATM analysis model
withdrawal
dispenser
Database query or response translator
Database query or response
Cashier interface
account
transfer
Bank customer
Money receptor
database
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
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
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
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
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
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
Boundary Classes

• Model the interaction of a system and its actors
• Receiving information from the actor
• Presenting information to the actor
• Represent abstractions of APIs, 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
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

21
Control Classes

• Control sequence of events, coordination between
  classes
• May represent complex sequences of calculations
  not related to one specific entity class
• Do not usually represent a concrete object in the
  real world
• Do not deal with interaction with actors or with
  management of persistent data
• The lifespan of the object should cover the use
  case duration or the duration of the user session

22
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

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
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

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 let Eva
  know that Paul owes the library 5 (max.).

26
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
Example Scenario 1 (cont)

• Post conditions
• Pauls 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
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
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.

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
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.