CMPT 275 Software Engineering

1. CMPT 275Software Engineering Requirements Analysis activity (use case diagrams, Class activity)

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

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

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. A B 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 thespecification of B may change A (A uses or depends on B) but not necessarily the reverse

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 case or target use case <<include>>

14. Use Case Diagrams • Dependency Relationship: <<include>> Make Meat Pie <<include>> <<include>> Make Apple Pie Make Pie Crust <<include>> Make Cherry Pie

15. LMS: Partial Use Case Diagram BrowseResource Check out resource <<include>> Verify Patron <<include>> ReserveResource CheckInResource Patron Librarian <<include>> Determine OverdueCharge

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

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 Case or Extension Use Case Target Use Case Or Base Use Case <<extend>>

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

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 Sessional Lecturer Regular 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 <<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

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?