week5-summ.pdf

Use-Case Modeling ▪ Models business processes in terms of: ▪ Business events ▪ Triggers of business events ▪ System responses to business events ▪ Origins in object-oriented modeling ▪ Well accepted by non-object methodologies as a good communication tool with end users Use-Case Diagrams Use-Cas...

Use-Case Modeling ▪ Models business processes in terms of: ▪ Business events ▪ Triggers of business events ▪ System responses to business events ▪ Origins in object-oriented modeling ▪ Well accepted by non-object methodologies as a good communication tool with end users Use-Case Diagrams Use-Case Diagram ▪ Graphically depicts the interactions between the system and its actors ▪ Depicts the functionality of the system ▪ Defines the boundaries of the system Actor A person, an object, time, an organisation or another system which interact with the system to exchange information. Use case ▪ A behavior of the system that describes a single business task from an actor’s point of view. ▪ A function provided by the system as a set of events that yields a visible result to the actor. ▪ Initiated by an actor that access the functionality of the system or another use case Use Case Association Relationship A relationship that shows an interaction between an actor and a use case ▪ Modeled as a solid line ▪ An arrow-headed line touching the use case indicates that the use case was initiated by the actor. ▪ A line without arrows indicates a receiver actor. ▪ Associations may be bidirectional or unidirectional Objectives and Steps of Requirements Use-Case Modeling ▪ Objectives: ▪ ▪ Collect and analyse requirements free of implementation details Use the Use Case model as a communication tool ▪ Steps 1. Identify business actors (produce Actor Glossary) 2. Identify business use cases (produce Use Case Glossary) 3. Construct Use-Case Model diagram 4. Produce Use-Case narratives (high-level and fullydocumented) Step 1: Identify Business Actors Ask questions like: ▪ Who provides inputs to the system? ▪ Who receives outputs from the system? ▪ Is there a need for interfaces to other systems? ▪ Are there use cases triggered by time ? ▪ Who will maintain information in the system? Step 2: Identify Business Requirements Use Cases Ask questions like: ▪ What are the tasks performed by an actor? ▪ What information does the actor provide to the system? ▪ What information does the actor need from the system? ▪ Are there documents that can be used to discover use cases? Evolving Use case Model to ObjectOriented Usecase Model The following steps evolve the requirements use-case model into an Object-Oriented analysis use-case model: 1. 2. 3. 4. 5. Identify, define, and document new actors. Identify, define, and document new use cases. Identify any reuse possibilities. Refine the use-case model diagram (if necessary). Document system analysis use-case narratives. System Analysis Use Case A detailed documentation of the interaction between the system user and the system. 7 Abstract Use Case ▪ Common steps in two or more use cases extracted and ▪ ▪ ▪ ▪ put into a new use case Reduces redundancy Increases re-usability; can be used by any use case that requires its functionality The relationship between the use case and the abstract use case are called <<uses >> or <<includes>> relationship. The <<uses>> relationship represented by a line pointing to the abstract use case 8 <<extends>> Relationship ▪ Represented as an arrow-headed line beginning at the ▪ ▪ extension use case and point to the use case it is extending Labeled <<extends>> Extension use case ▪ Consists of steps extracted from a complex use case to simplify the original case and thus extend its functionality. 9 Inheritance Relationship ▪ Use case relationship that connects actors to an abstract ▪ ▪ actor Tells that other actors can inherit the behaviors of the abstract actor. Reduces redundancy 10 Use Case Narratives A textual description of the business event that specifies the steps between an actor and the system. There are three types of descriptions: ▪ Brief description ▪ Intermediate description ▪ Fully developed description Some Definitions ▪ Trigger- a signal that indicates an event that initiated the ▪ ▪ ▪ ▪ execution of the use case Pre-condition - the state of the system that must be satisfied before the execution of the use case Flow of events (typical course of events) ▪ A sequence of activities between an actor and the system. ▪ It assumes a ‘happy scenario’ (everything is going smoothly) Exception conditions – document the behaviours of the system if an exception or variation of the typical flow of events occurs Post-condition - the condition that must be satisfied after the completion of the use case. Triggering Events and Types of Events Events are occurrences at a specific time and place. Types of events: ▪ External ▪ ▪ ▪ Outside system ▪ Initiated by external agent or actor (e.g. Customer places an order) Temporal ▪ Occurs as result of reaching a point in time; triggered by time ▪ Based on system deadlines ▪ Example: Monthly payroll report State ▪ Something inside system triggers processing need (e.g. Stock Item Level falls below ‘Reorder point’)