1 cmpt 275 software engineering requirements analysis activity (use case diagrams, class activity)...
TRANSCRIPT
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
Janice Regan, 2008-2014 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
Requirements Analysis Activities
Janice Regan, 2008-2014 4
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
Janice Regan, 2008-2014 5
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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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)
Janice Regan, 2008-2014 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)
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 10
UML: Use Case Diagrams
Use casename
Actor Use case
Relationships:
Dependency (extension and inclusion)
Association (communication)
Generalization
Janice Regan, 2008-2014 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
Use Case
Part of Use Case Diagram: Shows Communication
Janice Regan, 2008-2014 12
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
Janice Regan, 2008-2014 13
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>>
Janice Regan, 2008-2014 14
Use Case Diagrams Dependency Relationship: <<include>>
Make Cherry Pie
Make Pie Crust
<<include>>
Make Apple Pie
Make Meat Pie <<include>>
<<include>>
Janice Regan, 2008-2014 15
LMS: Partial Use Case Diagram
BrowseResource
CheckInResource
ReserveResource
Patron LibrarianDetermine Overdue
Charge
<<include>>
Check out resource
Verify Patron
<<include>>
<<include>>
Janice Regan, 2008-2014 16
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
Janice Regan, 2008-2014 17
Use Case Diagrams Dependency Relationship: <<extend>>
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>>
Janice Regan, 2008-2014 18
Use Case Diagrams Dependency Relationship: <<extend>>
Make cherry pie Baking in Microwave
<<extend>>
Baking in Convection oven
<<extend>>
Make optional cherry crème topping<<extend>>
Janice Regan, 2008-2014 19
Use Case: overlapping roles (good practice indicates 1 initiating actor per use case)
Regular Faculty
Sessional Lecturer
Record Grades
Recording Grades
Registrar
Design Course
Janice Regan, 2008-2014 20
Relationship
Generalization: book, music CD, videos are resources
Resource
Book Video Music CD
general
specific
Janice Regan, 2008-2014 21
Use Case: overlapping roles (1 initiating actor per use case)
Regular Lecturer
Sessional Lecturer
Record Grades
Recording Grades
Registrar
Instructor
Design Course
Janice Regan, 2008-2014 22
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
Janice Regan, 2008-2014 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
Janice Regan, 2008-2014 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 <<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
Janice Regan, 2008-2014 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?