Case Diagram

• In 1986 Ivar Jacobson first formulated textual, structural and visual modeling techniques for specifying use cases.
• In software and system engineering, a use case ( a case in the use of a system) is a list of steps, typically defining interactions between a role (known in UML [Unified Modeling Language] as an  "actor") and a system, to achieve a goal.
• The actor can be a human or an external system.
• In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML or as contractual statements.

Use case diagrams are helpful in three areas:

• Determining features (requirements): New use cases often generate new requirements as the system is analyzed and the design takes shape.
• Communicating with clients: Notational simplicity makes use case diagrams a good way for developers to communicate with clients.
• Generating test cases: The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

Definition

• Use Case Diagrams describe what a system does from the viewpoint of an external observer. The emphasis is on what a system does rather than how.  
• Use Case Diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system.
• Martin Fowler states;

"There is no standard way to write the content of a use case, and different formats work well in different cases." 

• Martin Fowler describes "a common style to use" as follows:
• Title: "goal the use case is trying to satisfy"
• Main Success Scenario: numbered list of steps
• Step: "a simple statement of the interaction between the actor and a system"
• Extensions: separately numbered lists, one per Extension
• Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.

 

·      Alistair Cockburn describes a more detailed structure for a use case, but permits it to be simplified when less detail is needed. His "fully dressed" use case structure is;

·         Title: "an active-verb goal phrase that names the goal of the primary actor"

·         Primary Actor

·         Goal in Context

·         Scope

·         Level

·         Stakeholders and Interests

·         Precondition

·         Minimal Guarantees

·         Success Guarantees

·         Trigger

·         Main Success Scenario

·         Extensions

·         Technology & Data Variations List

·         Related Information.

·      In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and goal level.

·      Cockburn recognizes that projects may not always need detailed "fully dressed" use cases. He describes a Casual use case with the fields;

·         Title (goal)

·         Primary Actor

·         Scope

·         Level

·         (Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.

 Design scope icon

Cockburn suggests annotating each use case with a symbol to show the "Design Scope", which may be black-box (internal detail is hidden) or white-box (internal detail is shown). Five symbols are available:

·         Organization (black-box), a filled icon of a house

·         Organization (white-box), an unfilled icon of a house

·         System (black-box), a filled icon of a box

·         System (white-box), an unfilled icon of a box

·         Component, an icon of a screw or bolt.

Other authors sometimes call use cases at Organization level "Business use cases".

Goal level icon

Cockburn suggests annotating each use case with a symbol to show the "Goal Level"; the preferred level is "User-goal" (or colloquially "sea level").

·         Very high summary, an icon of a cloud

·         Summary, an icon of a flying kite

·         User-goal, an icon of waves at sea

·         Subfunction, an icon of a fish

·         Too low, an icon of a seabed clam-shell.

Purpose:

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is too generic to describe the purpose.

Because other four diagrams (activity, sequence, collaboration and Statechart) are also having the same purpose. So we will look into some specific purpose which will distinguish it from other four diagrams.

Use case diagrams are used to gather the requirements of a system including internal and external influences. These requirements are mostly design requirements. So when a system is analyzed to gather its functionalities use cases are prepared and actors are identified.

Now when the initial task is complete use case diagrams are modelled to present the outside view.

So in brief, the purposes of use case diagrams can be as follows:

·         Used to gather requirements of a system.

·         Used to get an outside view of a system.

·         Identify external and internal factors influencing the system.

·         Show the interacting among the requirements are actors.

Actor

·         A use case defines the interactions between external actors and the system under consideration to accomplish a goal.

·         Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or organization, a computer program, or a computer system — hardware, software, or both."

·         Actors are always stakeholders, but many stakeholders are not actors, since they "never interact directly with the system, even though they have the right to care how the system behaves."

·         For example, "the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance" could all be stakeholders but are unlikely to be actors.

·         Similarly, a person using a system may be represented as different actors because he is playing different roles.

·         For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank.

Actors are often working on behalf of someone else. Cockburn writes that "These days I write 'sales rep for the customer' or 'clerk for the marketing department' to capture that the user of the system is acting for someone else." This tells the project that the "user interface and security clearances" should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.

A stakeholder may play both an active and an inactive role: for example, a Consumer is both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product). In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of the system). For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.

Cockburn advises to look for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design (SuD) itself, and finally among the "internal actors", namely the components of the system under design.

Use case Notation

In the Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are represented in a Use Case Diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system block level.

How to draw Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system. So when the requirements of a system are analyzed the functionalities are captured in use cases.

So we can say that uses cases are nothing but the system functionalities written in an organized manner. Now the second things which are relevant to the use cases are the actors. Actors can be defined as something that interacts with the system.

The actors can be human user, some internal applications or may be some external applications. So in a brief when we are planning to draw an use case diagram we should have the following items identified.

·         Functionalities to be represented as an use case

·         Actors

·         Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after identifying the above items we have to follow the following guidelines to draw an efficient use case diagram.

·         The name of a use case is very important. So the name should be chosen in such a way so that it can identify the functionalities performed.

·         Give a suitable name for actors.

·         Show relationships and dependencies clearly in the diagram.

·         Do not try to include all types of relationships. Because the main purpose of the diagram is to identify requirements.

·         Use note when ever required to clarify some important points.

The following is a sample use case diagram representing the order management system. So if we look into the diagram then we will find three use cases (Order, SpecialOrder and NormalOrder) and one actor which is customer.

The SpecialOrder and NormalOrder use cases are extended from Order use case. So they have extends relationship. Another important point is to identify the system boundary which is shown in the picture. The actor Customer lies outside the system as it is an external user of the system.

Where to Use Case Diagrams?

As we have already discussed there are five diagrams in UML to model dynamic view of a system. Now each and every model has some specific purpose to use. Actually these specific purposes are different angles of a running system.

So to understand the dynamics of a system we need to use different types of diagrams. Use case diagram is one of them and its specific purpose is to gather system requirements and actors.

Use case diagrams specify the events of a system and their flows. But use case diagram never describes how they are implemented. Use case diagram can be imagined as a black box where only the input, output and the function of the black box is known.

These diagrams are used at a very high level of design. Then this high level design is refined again and again to get a complete and practical picture of the system. A well structured use case also describes the precondition, post condition, exceptions. And these extra elements are used to make test cases when performing the testing.

Although the use cases are not a good candidate for forward and reverse engineering but still they are used in a slight different way to make forward and reverse engineering. And the same is true for reverse engineering. Still use case diagram is used differently to make it a candidate for reverse engineering.

In forward engineering use case diagrams are used to make test cases and in reverse engineering use cases are used to prepare the requirement details from the existing application.

So the following are the places where use case diagrams are used:

·         Requirement analysis and high level design.

·         Model the context of a system.

·         Reverse engineering.

·         Forward engineering.

Limitations

Limitations of Use cases include:

• Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirments (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
• Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
• Use cases are complex to write and to understand, for both end users and developers.
• As there are no fully standard definitions of use cases, each project must form its own interpretation.
• Some use case relationships, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.
• In Agile, simpler user stories are preferred to use cases.
• Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix.
• Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques.
• Use cases are a starting point for test design, but since each test needs its own success criteria, use cases may need to be modified to provide separate postconditions for each path.