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

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

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 Janice Regan, 2008-2014

Requirements Analysis Activities Software Developer Client/User Update SRS Use Case Centered Development (UCCD) Questions Use Case Diagram Use Cases Class Diagram System Context Diagram Primary Classes Scenarios State Diagram Janice Regan, 2008-2014

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

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

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

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

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

UML: Use Case Diagrams Actor Use case Use case name Relationships: Dependency (extension and inclusion) Association (communication) Generalization Janice Regan, 2008-2014

Part of Use Case Diagram: Shows Communication 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 Janice Regan, 2008-2014

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 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 A B Janice Regan, 2008-2014

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 case or target use case <<include>> Janice Regan, 2008-2014

Use Case Diagrams Dependency Relationship: <<include>> Make Meat Pie <<include>> <<include>> Make Apple Pie Make Pie Crust <<include>> Make Cherry Pie Janice Regan, 2008-2014

LMS: Partial Use Case Diagram BrowseResource Check out resource <<include>> Verify Patron ReserveResource <<include>> CheckInResource Patron <<include>> Librarian Determine Overdue Charge Janice Regan, 2008-2014

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

<<extend>> 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 Case or Extension Use Case Target Use Case Or Base Use Case <<extend>> Janice Regan, 2008-2014

Use Case Diagrams Dependency Relationship: <<extend>> Make optional cherry crème topping <<extend>> Make cherry pie <<extend>> Baking in Microwave <<extend>> Baking in Convection oven Janice Regan, 2008-2014

Use Case: overlapping roles (good practice indicates 1 initiating actor per use case) Recording Grades Design Course Regular Faculty Record Grades Registrar Sessional Lecturer Janice Regan, 2008-2014

Relationship Resource Book Video Music CD Generalization: book, music CD, videos are resources Resource general specific Book Video Music CD Janice Regan, 2008-2014

Use Case: overlapping roles (1 initiating actor per use case) Recording Grades Record Grades Instructor Registrar Design Course Sessional Lecturer Regular Lecturer Janice Regan, 2008-2014

Modeling the context of a system From: 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 Janice Regan, 2008-2014

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

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

Validation & Verification 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? Janice Regan, 2008-2014