1 CMPT 275 Software Engineering Requirements Analysis activity (use case diagrams, Class activity) Janice Regan, 2008-2014

1

CMPT 275Software Engineering

Requirements Analysis activity (use case diagrams, Class activity)

Janice Regan, 2008-2014

Janice Regan, 2008-2014 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 user’s/client’s 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


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

Requirements Analysis Activities


Software DeveloperClient/User

Update SRS

Questions

Use Case Centered Development (UCCD)

System Context Diagram

Use Cases

Primary Classes

Use Case Diagram

State Diagram

ClassDiagram Scenarios


Use Cases Specify the behaviour of the system from the

user’s 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


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


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)


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)


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


UML: Use Case Diagrams

Use casename

Actor Use case

Relationships:

Dependency (extension and inclusion)

Association (communication)

Generalization


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

Use Case

Part of Use Case Diagram: Shows Communication


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 B’s 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

Relationships: Dependency

A B


Use Case Diagrams Dependency Relationship: <<include>>

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 caseor target use case

<<include>>


Use Case Diagrams Dependency Relationship: <<include>>

Make Cherry Pie

Make Pie Crust

<<include>>

Make Apple Pie

Make Meat Pie <<include>>

<<include>>


LMS: Partial Use Case Diagram

BrowseResource

CheckInResource

ReserveResource

Patron LibrarianDetermine Overdue

Charge

<<include>>

Check out resource

Verify Patron

<<include>>

<<include>>


Use Case Diagrams Dependency Relationship: <<extend>>

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



Source use case extends the behavior of the target use case

Allows options to be extension cases

Source Use Caseor Extension Use Case

Target Use CaseOr Base Use Case

<<extend>>



Make cherry pie Baking in Microwave

<<extend>>

Baking in Convection oven

<<extend>>

Make optional cherry crème topping<<extend>>


Use Case: overlapping roles (good practice indicates 1 initiating actor per use case)

Regular Faculty

Sessional Lecturer

Record Grades

Recording Grades

Registrar

Design Course


Relationship

Generalization: book, music CD, videos are resources

Resource

Book Video Music CD

general

specific


Use Case: overlapping roles (1 initiating actor per use case)

Regular Lecturer

Sessional Lecturer

Record Grades

Recording Grades

Registrar

Instructor

Design Course


Modeling the context of a systemFrom: Booch, Rumbaugh, Jacobson

Customer

Individual Customer

Perform Transaction

Manage Customer Account

Credit Card Validation System

Process Customer Bill

Reconcile Transactions

Corporate Customer

Retail Institution

FinancialInstitution


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


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 <<include>> 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 <<extend>> dependency to factor out use

cases that are extensions


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?

Documents

1 CMPT 275 Software Engineering Requirements Analysis activity (use case diagrams, Class activity) Janice Regan, 2008-2014