1 / 59

Lecture 05

Lecture 05. ITEC 4040 – Requirements Management Prof. Dawid Kasperowicz http://www.yorku.ca/dkasper. Objects. Object – Direct relationship with the real world describing stable and (hopefully) reusable components Object Memory  Data  Attributes Processes  Operations  Messages

polly
Download Presentation

Lecture 05

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. Lecture 05 ITEC 4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper

  2. Objects • Object – Direct relationship with the real world describing stable and (hopefully) reusable components • Object • Memory  Data  Attributes • Processes  Operations  Messages • Object – Organization – Hierarchy • Aggregation • Generalization ITEC 4040 – Requirements Management

  3. Object Orientation • Tries to maximize reusability by using persistent objects • Goals are to • Encapsulate behaviour (states and events), information (data) and actions within the same objects • Define persistent objects, which can be used within both requirements and design phases • Add information by defining the objects in more detail • Create new objects by specialization of existing objects, not creating new objects ITEC 4040 – Requirements Management

  4. UML • Birth • Several methods and techniques for object oriented design, with many common aspects but using different notations • Difficult to learn, to apply, to build and to use tools • Differences among different approaches (authors) • OMT (1991), Objectory (1993), Booch (1994) • There was a need for a standard notation ITEC 4040 – Requirements Management

  5. UML • “Unified Method” • An attempt to bring together the three approaches • Grady Booch and Jim Rumbaugh • First presented at an OOPSLA‘95 • Rational Software • Grady Booch, Jim Rumbaugh and Ivar Jacobson • Rational Rose CASE tool ITEC 4040 – Requirements Management

  6. UML • UML 1.0 became a standard in 1997, following acceptance by the Object Management Group (OMG) • Version 1.3 was released in 1999 and in 2003 UML 2.0 was released • Made up of a number of models, which together describe the system under development ITEC 4040 – Requirements Management

  7. UML Diagrams ITEC 4040 – Requirements Management

  8. UML Diagrams • From the 13 diagrams available in UML, many will not be used and often only a small subset of the diagrams will be necessary to model a system • Class diagrams, use case diagrams and sequence diagrams are the most frequently used • If dynamic modelling is required, activity and state machine diagrams should be used ITEC 4040 – Requirements Management

  9. UML Diagrams Implementation Requirements Design States Sequence Distribution Classes Use Cases Collaboration Components Activity (work flow, use cases) Activity (object behaviour, operation algorithms) ITEC 4040 – Requirements Management

  10. Use Case Diagrams • Definition: Defines the interaction that takes place between a user of a system (an actor) and the system itself • Definition: Represents the functionality of the system from a user’s point of view. They define boundaries of the system. • Contains actors (external entities that interact with the system) and the use cases (description of the behaviour of the system as seen from an actor’s point of view) and shows the relationship between them • Actors initiate a use case to access system functionality, which can initiate other use cases and gather more information from the actors • When actors and use cases exchange information, they are said to communicate ITEC 4040 – Requirements Management

  11. Use Case Diagrams • Each use case defines functional requirements for the system • Actors do not need to be human, even though they are represented as stick figures, but in fact represent roles • Each actor needs to have an association with at least one use case • The system boundary is also defined on the use case diagram by a rectangle, with the name of the system being given within the box ITEC 4040 – Requirements Management

  12. Use Case Diagrams Use case diagram for a Banking system ITEC 4040 – Requirements Management

  13. Use Case Diagrams ITEC 4040 – Requirements Management

  14. Use Case Diagrams • Use cases are accompanied by descriptions • Descriptions are composed of six fields • Name of the use case, which is unique across the system • Participating actors are actors interacting with the use case • Entry conditions describe the conditions that need to be satisfied before the use case is initiated • Flow of events describes the sequence of interactions of the use case that are numbered for reference • Exit conditions describe the conditions that are satisfied after the completion of the use case • Quality requirements are requirements that are not related to the functionality of the system (generally NFRs) ITEC 4040 – Requirements Management

  15. Use Case Diagrams • Using natural language enables developers to use them for communicating with the client and the users, who generally don’t have an knowledge of UML notation • Using natural language enables participants from other disciplines to understand the requirements of the system • Allows developers to capture things, in particular special requirements, that cannot easily be captured in diagrams ITEC 4040 – Requirements Management

  16. Use Case Diagrams • Identify actors: • Who is interested in the requirements • Who will benefit from the product • Who will give information to the software • Who will use the software • Who will remove information from the software • Identifying use cases: • What are the actors tasks • Which information each actor creates, stores, consults, changes or removes • Which information each use case creates, consults, changes or removes ITEC 4040 – Requirements Management

  17. Use Case Diagrams • Determining use case flow • When and how a use cases starts • How the use case interacts with the actors • Standard Sequences (Steps) for a use case • Exceptions Sequences and alternative sequences for a use case ITEC 4040 – Requirements Management

  18. Use Case Diagrams – Include Relationships • Complex systems can cause complex use case models and can contain redundancy • To reduce complexity, we must identify commonalities in different use cases • Two use cases are related by an include relationship if one of them includes the second one in its flow of events • Includerelationships are depicted by a dashed open arrow originating from the including use case and labeled with the string <<include>> ITEC 4040 – Requirements Management

  19. Use Case Diagrams – Include Relationships ITEC 4040 – Requirements Management

  20. Use Case Diagrams – Extend Relationships • Alternative means of reducing complexity in the use case model is by using extend relationships • Extend relationship indicates that an instance of an extended use case may include (under certain conditions) the behaviour specified by the extending use case ITEC 4040 – Requirements Management

  21. Use Case Diagrams – Extend Relationships ITEC 4040 – Requirements Management

  22. Requirements and Use Case Diagrams • Use cases are not requirements • If written carefully, they can be seen as requirements per se • They don’t detail external interfaces, data format, business rules, NFR… ITEC 4040 – Requirements Management

  23. Class Diagrams • The basic diagramming notation from object-oriented analysis and design • Describe information about classes of objects and their relationships • Objects can be part of the real world or conceptual entities • Objects are connected to other objects through relationships (association, aggregation…) ITEC 4040 – Requirements Management

  24. Class Diagrams • The top compartment displays the name of the class/object • The center compartment displays its attributes • The bottom compartment displays its operations • Object names are underlined to indicate that they are instances • Class names start with an uppercase letter • Objects in object diagrams may be given names, followed by their class, for reference. Names must start with lowercase letter ITEC 4040 – Requirements Management

  25. Class/Object • Class: • Describe a set of objects that share the same properties (attributes), behaviours (operation), relationships with other objects and semantics • Object: • An Object is an instance or occurrence of a class ITEC 4040 – Requirements Management

  26. Class/Object Properties: Fuel capicity Km/galon availability km Behavior: travel refuel car A instanciation instanciation car B ITEC 4040 – Requirements Management

  27. Class Car FuelCapacity: Integer kmpergalon: Real availability: Real Km: Integer travel (Kms: Real) Refuel (quantity: Real) name attributes operations ITEC 4040 – Requirements Management

  28. Class rj5015: Car FuelCapacity: 200 kmpergalon: 40 Availability: 40 km: 1400 Car - FuelCapcity: Integer - Kmpergalon: Real - availability: Real = 0 - km: Real = 0 ... Object with Values • Attributes • Examples Class whit attributes ITEC 4040 – Requirements Management

  29. Class Diagrams • Associations are used to represent a wide range of connections among a set of objects • Aggregation and composition are frequent special cases of association • Composition – When the owning object is destroyed, so are the contained objects • Aggregation – When the owning object is destroyed, the contained objects may not be destroyed ITEC 4040 – Requirements Management

  30. Class Diagrams • Example: • A university owns various departments • Each department has a number of professors • If the university closes, the departments will no longer exist • If the university closes, the professors in those departments will continue to exist • University can be seen as a composition of departments • Departments have an aggregation of professors ITEC 4040 – Requirements Management

  31. Class Diagram Company Managers Project Employee Employee schedule HourBasis MonthlyBasis • Example: Company Agregation 0..N 1 Association Class 0..N Generalization ITEC 4040 – Requirements Management

  32. Class Diagram • What is this a model of? ITEC 4040 – Requirements Management

  33. Inheritance • The relationship between a general class and one or more specialized classes • A subclass (specialized) inherits attributes, operations, state diagram and associations from a superclass (generalized) • Inherited properties may be reused from the superclass or redefined in the subclass • New properties can be added to the subclass • Can be • Simple: only one superclass • Multiple: more than one superclass • Multiple • A class inherits attributes, operations and association from multiple classes • Offer a greater modelling power but leads to a greater complexity ITEC 4040 – Requirements Management

  34. Inheritance Vehicle water land Boat Car Amphibian • Multiple ITEC 4040 – Requirements Management

  35. Inheritance Account AccoountNumber:integer Withdraw() Regular Savings Minimum: RealServiceFee: Real Interest: Real chargeFee() calculateInterest() • Multiple ITEC 4040 – Requirements Management

  36. State Machine Diagrams Input/Output S0 S1 “data oriented” Input/Output f1 S0 S1 “function oriented“ f2 ITEC 4040 – Requirements Management

  37. State Machine Diagrams • Notation for describing the sequence of states an object goes through in response to external events • A state is a condition satisfied by the attribute of an object • E.g.: Active, Inactive, Closed, Archived for an Incident object • A transition represents a change of state triggered by events, conditions, or time ITEC 4040 – Requirements Management

  38. State Machine Diagrams • A state is depicted by a rounded rectangle • A transition is depicted by open arrows connecting two states where the states are labeled with their name • A small solid black circle indicates the initial state • A circle surrounding a small solid black circle indicates a final state ITEC 4040 – Requirements Management

  39. State Machine Diagrams ITEC 4040 – Requirements Management

  40. State Machine Diagrams ITEC 4040 – Requirements Management

  41. Problems with OO • Disadvantages (Jackson): • The idea of objects come from programming languages and it is not suitable to most of the individuals in non-related fields • When has someone sent a message to a paycheck? • When has a doctor sent a message to a Patient’s record? ITEC 4040 – Requirements Management

  42. Communication Cenários Anlysis Is my understanding (vision) correct? Domínio do problema Compreender modelo • It is necessary to have a good communication between user/stakeholder and developers Scenarios Problem Domain Understand the Models ITEC 4040 – Requirements Management

  43. Scenarios • An instance of a use case describing a concrete set of actions • Used as examples for illustrating common cases; their focus is on understandability • Use cases are used to describe all possible cases; their focus is on completeness ITEC 4040 – Requirements Management

  44. Scenarios • Easy to understand (written using the problem language) • Help to unify criteria • Stimulate thinking • Help with training • Help on tracking/traceability • Help identifying Non-Functional Requirements ITEC 4040 – Requirements Management

  45. Scenarios • Situation’s/Scenarios Characteristics • Purpose – A situation deals with satisfaction of a goal • Actors – A situation encompass a certain identifiable numbers of actors (people or devices within organizations) • Resources – Elements that are necessary in one particular situation • Time – Represent a specific moment • Place – Situations take place within a geographical context • Constraints – There might be pre-conditions to a situation to happen • Independent – Need to be understood alone • Inter-Related – Are related to other situations, although still independent • Concrete – Are anchored in reality • Alternatives – May lead to alternative actions ITEC 4040 – Requirements Management

  46. Write Scenarios • Describe situations of the macro system • Describe situations and their relationship with the system-to-be • May be used to describe interactionsbetween system components • Use a semi-structured natural language (same as in LEL) ITEC 4040 – Requirements Management

  47. Write Scenarios ITEC 4040 – Requirements Management

  48. Why Semi-Structured? • Avoid confusion • Provide an homogeneous description style • Works as a reminder of the several aspects that might be considered within a scenario • Facilitates to validate it with the users/stakeholders ITEC 4040 – Requirements Management

  49. Scenarios • Title: Store checks client’s registration • Objective: Verify if information on client’s registration is correct • Context:Client hand over client’s registration and show a photo id • Actors:Store, Client • Resources:photo id, client’s registration • Episodes: • Store fills up blank spaces in client’s registration using the initial “NE” (Non-Existent) • Storesverify id number on client’s registration against the one in the photo id • Constraint: id number must comply with standards • Store verify address and phone number calling the number in client’s registration ITEC 4040 – Requirements Management

  50. Identifying Scenarios • List Situations • Is there a goal? Is it general (abstract enough)? Are there different outputs or is it a sole case? • Who is involved? Are there other important artifacts or important structures? • Are there any information or physical elements that are important to this situation? • Organize identified situations in a list ITEC 4040 – Requirements Management

More Related