1 / 25

CMPT 275 Software Engineering

CMPT 275 Software Engineering. Requirements Analysis activity (use case diagrams, Class activity) . Class Project: Requirements Analysis. Object Oriented paradigm Requirements Gathering Activity: Develop informal scenarios to help you derive your software requirements specifications

reia
Download Presentation

CMPT 275 Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related