Case Techniques Essay Samples

Case Techniques

...They separate the system into actors and use cases. Actors represent roles that can be played by users of the system. Actors can be human, other computers, pieces of hardware, or even other software systems. The only criterion is that they must be external to the part of the system being partitioned into use cases. The actors supply inputs to the system, and receive outputs from it. Use cases describe the behaviour of the system when one of these actors sends one particular input. This behaviour is initially documented in text form. It describes the nature of the input that triggers the use case; the inputs from and outputs to other actors, and the behaviours that convert the inputs to the outputs. The text of the use case also usually describes everything that can go wrong during the course of the specified behaviour, and what remedial action the system will take. Figure 1 is a typical template for recording use cases (a full use case sample document is provided in the appendix). A use case template is considered more a checklist than a form to be filled in. Some elements of the template may not be required fro all use cases. A brief description of the template elements is given on the following page. • Use Case ID – Use a hierarchical numbering system (1., 1.1…, 2., 2.1... etc.) to group related use cases. • Use Case Name – A concise name using a strong verb to reflect the task. (e.g. View part number, Place purchase order request etc.) • Actor – An external entity to the system. (e.g. Customer, Supplier, Visitor etc.) • Description – A brief high-level description of the reason for this use case. • Preconditions – A list of any activities that must take place or conditions that must be true before the use case can start. (e.g. Authenticate user, Insert CD etc.) • Postconditions – The system state upon conclusion of the use case. (e.g. Time updated, New User added to database, Invoice sent to customer etc.) • Normal Flow – User actions and system responses that take place under normal expected conditions. • Alternative Flow – Scenario based flows that can take place. • Exceptions – Possible errors than can occur during execution. • Includes – A list of other use cases that may be called by this use case. • Frequency of Use – An estimation of the number of times the use case will be performed per an appropriate unit of time. • Business Rules – Any business constraints that may affect the use case. • Special Requirements – Any additional requirements that need to be addressed. (e.g. Performance requirements, Quality attributes etc.) • Assumptions – List any assumptions made during the analysis. • Notes – Any TBDs (To Be Determineds) that need to be resolved. 3. USE CASE Diagrams 3.1. What is a Use Case Diagram? The functional requirements of the system being developed can be shown on a set of use case diagrams that summarise all a system can do. It shows what use cases are used, by what external user roles and any systems / users with whom the system will interact. As such it graphically defines the functional boundary of the system. The diagram is concentrated on what the system does not how it does it. 3.2. Use Case Diagram Components ACTOR The actor symbol represents the various devices that are external to the system being developed but interact with it in some fashion. The actor can be a specific role that a person carries out, e.g. EPOS Operator, or any other entity (e.g. a computer program) that communicates with the system but it’s outside the system scope. It is sometimes useful to identify non-human actors by overlaying “<>” on the actor symbol. An important distinction must be made between an actor and a system user. It is quite feasible that a single user carries out a number of different roles when interacting with the system. An example from my place of work could be a process control technician (PT). A PT is a user that operates the DCS (Distributed Control System) to make a product. Although a single high level view of this role such as can be defined, this in itself is a fairly useless and obvious. It would be more useful to define the various roles that this user performs: DCS Monitor, Recipe Manager, Quality Tester for example. An actor is a user class and the roles are instantiated objects of that class. USE CASE A use case is an action that a user carries out on the system. Each use case defines a scenario that explains possible sequences of user-system interaction. Depending on requirements, the use case can be granular i.e. specific or high level. Following on from the DCS example, “Log-In to DCS”, “Enter batch details”, “Get recipe” and “Set feed rates” are potential use cases. RELATIONSHIPS Relationships are the communications that take place between an actor and a use case. There are several types of relationships that may appear on a use case diagram: • An association between an actor and a use case. (1) • An association between two use cases. (2) • A generalisation between two actors. (3) • A generalisation between two use cases. (4) Figure 2 shows a very basic example of a use case diagram. Associations are indicated by an open arrowhead that points from the invoking entity to the invoked entity. Many developers leave off the arrowhead in actor-use case associations as they may be wrongly interpreted to mean data flow by some users. The <> association can be thought of as calling a procedure or something that must be done before the use case can be completed. In the above example the enrolling student must enrol on at least one module otherwise why would they be enrolling? <> is sometimes used in place of <>, but the association is the same. The <> association indicates an extension or variation to its base or parent use case. An extended use case may be executed, but it is not an absolute requirement and has no effect on its base case’s execution. Exten...

• View Full Text