CMPT 275 Software Engineering

1
CMPT 275Software Engineering

• Requirements Analysis Phase
• Requirements Analysis activity (use case
  diagrams)

2
Class Project Requirements Analysis

• Object Oriented paradigm
• Requirements Gathering Activity Develop informal
  scenarios to help you derive your software
  requirements specifications
• Requirement specification Activity Build an
  analysis model representing the users/clients
  view of the system
• analysis model includes a list of functional
  and non-functional requirements. Each functional
  requirement represent all or part of at least one
  function/activity
• Functional requirements are not dependent on
  specific methods of implementation

3
Class Project Requirements Analysis

• Next you will proceed using use case centered
  development (UCCD) to analyze that model
• System Context Diagram
• Identifying Actors and developing Use Cases
• Use case Diagrams
• Primary classes
• Use cases and Scenarios (formal and informal)
• Class (object) Diagram
• State Diagrams

4
Requirements Analysis Activities
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
5
Use Cases

• Specify the behaviour of the system from the
  users perspective
• Provides value to at least one user of the system
• Describe a sequence of actions, performed by the
  system, to yield a result desired by that user
• The behavior of the system is expressed without
  specifying how the behavior is implemented (What
  is behavior, not how is it done)
• To get started generalize an informal scenario
  (or closely related set of informal scenarios)
• Informal scenarios are a good starting point

6
UML Unified Modeling Language

• Object-Oriented Paradigm modelling notation
• Clear and effective way to model many aspects of
  a software system using a commonly understood
  language
• Programming language independent
• Enables a variety or analysis and design
  techniques
• A subset of UML will be used in this course

7
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)
• Dynamic behavior (state diagrams, collaboration
  diagrams sequence diagrams)

8
Use Case Diagrams

• Depicts overall behavior of s/w system
• Models the context of a system (what is part of
  the system what external entities interact with
  the system)
• AND
• Models the requirements of a system, the desired
  behavior of the system (what the system should do
  from an external viewpoint, not how it should do
  it)

9
Use Case Diagrams

• Depicts overall behavior of software system
• Depicts interaction between
• use cases and actors
• use cases and use cases
• actors and actors
• Depicts a set of use cases, a set of actors, and
  the relationships between the use cases and
  actors

10
UML Use Case Diagrams
Actor
Use case
Use casename
Relationships
Association (communication)
Generalization
Dependency (extension and inclusion)
11
Use Case Diagrams

• Relation between actor and use case is a
  communication if
• Actor initiates use case
• Actor supplies information to use case
• Actor receives information from use case
• Use case initiates another use case

Part of Use Case Diagram Shows Communication
Use Case
12
Relationships Dependency

• Dependency Class A is said to depend on class B
  if
• A uses at least one feature of B, e.g., it
  accesses one of Bs data fields or invokes one of
  its methods.
• Changing the specification of B may change A (A
  uses or depends on B) but not necessarily the
  reverse

13
Use Case Diagrams

• Dependency Relationship ltltincludegtgt
• Encapsulates common logic required by several use
  cases into one included use case
• Used for factoring out common behaviour (promote
  reuse)
• Can also be used to break a large and complicated
  used case into smaller more manageable parts

Source Use Case or Base Use Case
inclusion use case or target use case
ltltincludegtgt
14
Use Case Diagrams

• Dependency Relationship ltltincludegtgt

Make Meat Pie
ltltincludegtgt
ltltincludegtgt
Make Apple Pie
Make Pie Crust
ltltincludegtgt
Make Cherry Pie
15
LMS Partial Use Case Diagram
BrowseResource
Check out resource
ltltincludegtgt
Verify Patron
ReserveResource
ltltincludegtgt
CheckInResource
Patron
Librarian
ltltincludegtgt
Determine OverdueCharge
16
Use Case Diagrams

• Dependency Relationship ltltextendgtgt
• Extension use case defines logic that may be
  required during a base use case
• Exceptional logic that is not always needed
• Can be a conditionally executed separate subflow
  (label with condition)
• One of several possible flows that may be
  inserted at a given point governed by interaction
  with the actor

17
Use Case Diagrams

• Dependency Relationship ltltextendgtgt
• Source use case extends the behavior of the
  target use case
• Allows options to be extension cases

Source Use Case or Extension Use Case
Target Use Case Or Base Use Case
ltltextendgtgt
18
Use Case Diagrams

• Dependency Relationship ltltextendgtgt

Make optional cherry crème topping
ltltextendgtgt
Make cherry pie
ltltextendgtgt
Baking in Microwave
ltltextendgtgt
Baking in Convection oven
19
Use Case overlapping roles (good practice
indicates 1 initiating actor per use case)
Recording Grades
Design Course
Regular Faculty
Record Grades
Registrar
Sessional Lecturer
20
Relationship

• Generalization book, music CD, videos are
  resources

Resource
general
specific
Book
Video
Music CD
21
Use Case overlapping roles (1 initiating actor
per use case)
Recording Grades
Record Grades
Instructor
Registrar
Design Course
Regular Lecturer
Sessional Lecturer
22
Modeling the context of a systemFrom Booch,
Rumbaugh, Jacobson
Credit Card Validation System
Perform Transaction
Retail Institution
Process Customer Bill
Customer
Reconcile Transactions
Financial Institution
Manage Customer Account
Individual Customer
Corporate Customer
23
Constructing a Use Case Diagram

• Identify all actors (primary and secondary)
• For each actor
• Identify each function the actor expects from the
  system (can consider the whole system or a few
  requirements at a time)
• Name each of these functions, and consider it to
  be a use case

24
Constructing a Use Case Diagram

• Analyze the use cases
• Determine which actor (one only) or which use
  case initiates each use case
• Find any actions common to multiple use cases.
• Use the ltltincludegtgt dependency to connect the use
  case for the common action to the original use
  cases
• Find any actions that are done rarely/sometimes
• Use the ltltextendgtgt dependency to factor out use
  cases that are extensions

25
Validation Verification

• Validation
• Are we building the right product?
• To facilitate validation we number our functional
  requirements and propagate these numbers
  throughout our models and source code, validating
  that all functional requirements are parts of the
  system.
• Verification
• Are we building the product right?

26
Class exercise

• Read the requirements for the "Matrix Math
  Demonstrator" (hand out)
• Work in your project groups
• You will have 2-3 minutes to identify the actors
  in the "Matrix Math Demonstrator (MMD)
• Then we will work through, requirement by
  requirement, to identify the list of use cases
  needed to implement the "Matrix Math
  Demonstrator, and the relationships between
  those use cases