1. 1 CMPT 275 Software Engineering Requirements Analysis Phase Requirements Analysis activity Janice Regan, 2008-2014

2. 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. Janice Regan, 2008-2014 3 UML Analysis models  Role: clear and effective way to represent and analyze (model) various aspects of software system  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)

4. Janice Regan, 2008-2014 4 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  Primary classes  Use cases and Scenarios (formal and informal)  Use case Diagram  Class (object) Diagram

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

6. Janice Regan, 2008-2014 6 Class Diagrams  Models the composition of classes and the relationships between classes  Shows a set of classes, interfaces, and collaborations (used in design), and their relationships  Dependency, generalization, and association relationships are represented  Models a static perspective (emphasizes structure not behavior of the system) of the system  Primarily supports the definition of functional requirements of a system. (services the system provides to users)

7. Janice Regan, 2008-2014 7 UML: Class Diagrams Class Name ClassDetailed Class Relationships: Dependency Association: application-related Generalization Class Name Attributes Methods Association: aggregation Association: composition Stereotype Analysis Only Class Name Realization

8. Janice Regan, 2008-2014 8 Relationships: 1  Association:  Aggregation: catalog has resources  ONLY distinguishes a whole from a part, may be a part of multiple wholes, destroying the catalog does not destroy the resources  Composition: game board is composed of squares  Strong aggregation: square can be part of 1 board only, destroying the board (whole) must destroy the squares (parts) as well whole CatalogResource Game board squares part whole part

9. Janice Regan, 2008-2014 9 Relationships: 2  Association:  Application-specific: patron checks out a resource  Application specific Association: The label “  Is checked out by” indicates what action this relation between classes represents. Such labels are used to identify associations with actions other than obvious ones such as uses Patron Resource 0..1 0..8  Is checked out by staff book

10. Janice Regan, 2008-2014 10 Relationships: 3  Association:  Bi directional Each object knows about the other (arrows are optional)  Roles: A patron may be a faculty member a student …, we can use a role, the text next to the patron box to indicate that the relation shown applies only to the specialized patron class student. Patron Resource 0..1 0..4  Is checked out by student video

11. Janice Regan, 2008-2014 11 Relationships: 4  Association:  Application-specific: patron checks out a resource  Multiplicity of an association: # of entities “from this side” that can be associated with an entity ‘of the other side’, exact: n, range: 0..1, 0..n, 1..n, set: 1, 3..20, unspecified: 1..*, * Patron Resource checks out  0..1 0..2 faculty painting

12. Janice Regan, 2008-2014 12 Actors and Entities (classes)  The patron entity (primary entity class) is not the same as the patron actor.  The patron primary entity class contains attributes describing the actor and methods to manipulate those attributes within the LMS.  The patron actor is external to the system and acts on the system,  The patron entity (class) is part of the system  When building a class diagram consider the interactions of the classes not the actors

13. Janice Regan, 2008-2014 13 Sample Association  Patron entity is associated with the book entity through the “put on hold” relationship  Patron and Book attributes will be updated to reflect the hold  Patron and Book methods may be used to update the information.  Actor not equivalent to entity Patron Actor Patron Entity Book Entity 0..* Put on hold

14. Janice Regan, 2008-2014 14 Relationships: 5  Association:  Uni directional Overdue letter knows about the resources (single arrow is not optional) but the resources do not know about the overdue letter  report classes can know about the class they report without those classes knowing about them  Also useful for relating classes to classes defining complex attribute Overdue letterResource 1

15. Janice Regan, 2008-2014 15 Relationships: 6  Generalization: book, music CD, videos are resources Resource Book Video Music CD general specific

16. Janice Regan, 2008-2014 16 Relationships: 7  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

17. Relationships: 8  Association Class  Add attributes, operations to associations  Usually used when a relation between classes A and B is a many to many association  Helps you represent the case when there can be only one association between each member a of class A and each member b of class B Janice Regan, 2008-2014 17

18. Association classes  Consider a course registration system.  Lower diagram gives additional information: each student has only one association with each seminar. (A student cannot register twice in one seminar) Janice Regan, 2008-2014 18 studentseminar student seminar registration 1..100 0..6 1..100 0..6

19. Relationships: 9  Consider a system for recording appointments in a medical clinic  Each patient can have many appointments with each doctor. Janice Regan, 2008-2014 19 patient doctor patient doctor appointment 1..* 0..* 1..*

20. Janice Regan, 2008-2014 20 Class Exercise  You will have 2-3 minutes to discuss with your team what classes you will need in the class diagram  After your discussions, I will choose one requirement or one group of requirements  You will have another 1-2 minutes to decide how to add that requirement to the class diagram  I will then choose a team randomly and ask one of the team members to come and add that requirement to the class diagram  I will repeat this until all requirements have been added  After each requirement is added we will discuss what has been added, and other ways of adding the same requirement (if any)

21. Janice Regan, 2008-2014 21 Class exercise  Consider a University (we will be building a registration system)  Instructors are part of one or more departments  A course offering is a course offered in a particular term  Each course offering is taught by one instructor  2 offerings of the same course can have different instructors  Instructors teach course offerings (<=4 per term)  Students take course offerings (<=8 per term)  Students can be full time students or part time students  Faculties consist of departments  Departments offer course offerings  Students are part of one department  We want to build a class diagram for this university