Sunday, April 25, 2010

Working with USE Case Diagrams.

Link here for latest UML and architecture  examples and case study once you read below, we will keep on updating the page as soon as we develop some new artifacts:-

A use case diagram for system modeling describes the interaction between the use case and actors of the proposed software system. In addition, a use case diagram outlines the various relationships, such as association and generalization, which exist between use cases and actors.

Identifying use cases.
The use case identified for system modeling are text descriptions of the interaction between outside entities and the software system. Use cases can model both functional and non-functional requirements. In addition, you use use case in the design, implementation, and testing phase of software development.

 The use cases for the proposed software system should contain following characteristics.

Provide value to actors: - Each interaction show using a use case diagrams should either provide an output to the external entity or affect the output provided to an external entity that does not paricipate in the interaction.

Provide a brief description of the desired functionality: - the use case diagram should contain a brifef description of the proposed process at the fist level. Detailed information should be provided in the subsequents steps. A use case should explain all the business and technical requirements that the sub-process needs to implement.

The information that a use case should contain include.

Name: Indicates a unique identification of the use case

Summary: indicates the functions provided by the use case.

Basic course of events: indicates the steps of interaction that ocucur between the actor and the software system to achieve the functions described in the use case.

Alternative paths: Describe the situations in which an uncommon condition occurs.

Exception path: Describe the interactions that occur between a use case and an actor when an error occurs.

Triggers: list the conditions that must occur to make an actor initiate a use case. Triggers describe a business need, time related event, or the output of another use case.

Assumptions: specify the conditions that should be true to make the system work.

Preconditions: List the conditions that must occur before the interaction between the use case and an external entity begins. Preconditions are outside the scope of the use case and the software system.

Post conditions: List the conditions that are satisfied when the use case is completed. Post conditions are part of the contract between this use case and outside world.

Business rule: List the business rules that relate to the requirements presented in the use case.

Non- functonal requirements: List the non- functonal requirements that the use case must.

Author: Specify the name of the author.

Date: Contains the date on which the use case was originally written with references to when it was changed.

Exclusion:-Exclusion is happening in the executor, not the planner. That allows this form of exclusion to work with stable functions and parameters without problem.

It would also be possible to exclude some types of value in the planner only, but this only works when the planner and executor are run at the same time.

One potential objection to this approach is that immutable functions and constants cannot be removed by the planner in a prepared query because the partition constraints are dynamic.

The following figure depicts the use case diagram with the system bonundary for the hospital adiministration system.

Note :- Accept fee form the patient for the services of the doctor,Print fee receipt for the patient,Accept fee enables patients to use their credit card to make payment for the availed services of the doctor, print fee receipt enable patients to obtain a fee receipt in return of payment.

What Other's are reading.
Representing a USE Case model and understanding the high-level USE Case diagrams.
Creating-activity-diagram in UML
Creating state-machine-diagrams
Pattern and Practices Basic with Design Patterns part 1
Pattern and Practices Basic with Design Patterns part 2
Pattern and Practices Basic with Design Patterns part 3

No comments:

Recent Posts