UML tutorial part1 : Business Analysts and System Analysts FAQ

Visual Case Tool - UML Tutorial

Welcome to the Visual Case Tool – UML . An introductory overview to UML (Unified Modeling Language) is given in the following pages with the help of Visual Case. UML is considered to be complex and rich modeling language and this tutorial aims to give you an overview of the most common aspects of this language.

Unified Modeling Language (UML)is a graphical modeling language that is used to enhance the object oriented designs. The language has been standardized so that the artifacts and components can be specified for the development of a software system. UMLS should be considered as a notation and not a process. This is because UML does not provide with a single method or design process, but is considered as a standardized tool that can be used in a design process.

There are in total eight UML diagrams which you can go through in this tutorial. But before we start, download Visual Case(only the trial version - free of charge for 30 days) so to aid in the understanding of the tutorial and for hands – on experience.

The Use Case Diagram

Use case diagram is the first one in the design processes which most of the designers will start to work on while initiating a project. The use case diagram brings out the depiction of the high level user goals which are to be carried out by the system. Such high level user goals may not be necessarily actions or tasks, and on the other hand be specifications for the general systems functionalities.

Use Case

Technically defined, use case is actually a set of scenarios. Each of theses scenarios is actually an order of steps which define the interaction levels between an user and the system. A use case collates all the scenarios which implement a specific user goal.

A use case is a textual description of the scenario steps which are required for ideal or the positive flow and also any alternate scenario possible at each of the steps. Here, there is a sample use case which gives the flow as to how the keyword search is done on the website:

Ideal Flow:

1. The keyword is entered by the customer on the website
2. The search button is clicked by the customer.
3. Search is completed
4. Search results are displayed

Alternative Flow: Search Fails
If the search fails at step 3, Redirect User to search screen at Step 1

With the help of the Visual Case tool which you have downloaded, the use case steps can be specified in the description field. To do so, you will have to right click on a particular use case and elaborate on the properties. A report can then be run by you and even printed or exported to HTML or ASCII text for evaluation and proofreading purposes. In totality, the use case diagram and its report include all of the use case details such as the scenarios and actors required for the system design process.

Actor

The use case diagram is used by the designer to graphically represent the use cases and the involved actors. An actor can be defined as a role which is played by a user in the system. The distinction of a user from an actor (or user role in a system) should be made more clearer. A system user can have different roles according to the action performed and an actor may be the role itself or even another system. An actor can be for e.g - a salesperson, support person, manager and even a web store system. In the physical world, the same user may be performing two roles - a sales person and support person. Hence, while a use case diagram is being modeled, the roles and the action being performed by them should be concentrated on rather than the user or individual.

Associations

While modeling the use case diagram associations are usually drawn between the actors and use cases in order to depict the actor carrying out or performing the use case. There is a one to many relationship between a use case and an actor which can be explained as a use case which can be performed by many of the actors and vice versa.

As depicted in the above diagram, the stick figure shapes in green on the left are actors, the blue ellipses are the use cases, while the connecting lines in between them as the associations. The specifications for the system and user roles are done jointly by the developer and stakeholder while the model is created by the developer alone.

Includes

There are three other links through which the use cases can be related to one another. One of these is the use of “ Include” link which is depicted in the diagram below. The use cases invoice purchase and online purchase include the scenarios which is defined by purchase valuation and hence the <<include>> link. So, this link actually helps to minimize any scenario repetitions in case there are multiple use cases.

Generalization

A ggeneralizationh link is used when a use case describes a variation of another use case. As depicted in the below example, limit exceeded use case is a scenario is which the scenario of online purchase is not acted upon and hence the generalization link is shown from the former to the latter. Use cases which have a generalization link to another use case actually depict an alternative or exceptional scenario to the latter use case. Inspite of the generalization, the final goal remains the same for the use cases.

Extends

In some cases where the behavioral variation is to be described in a controlled manner, then you can define extension points in the extended use case. As given in the below example, search by name is extending search at the extension point of name. The extends link is more controlled in manner in comparison to the generalization link as the former link can be added only at the extension points.

Putting it all Together

While starting on the modeling of a use case, it is vital that the simplicity of the diagram is maintained. Firstly the system actors should be determined and only after that should the use cases being performed be finalized. It depends on you , whether the use case diagram is simple or complex but you should remember that the more simpler and uncluttered it is, the easier it will be for understanding purposes and will be better in capturing the system tasks. With the help of Visual Case tool, a use case can be exploded or drilled into a new use case diagram. For e.g, there may be further specifications which are required for the use case online purchase as we delve into the depth of the design process. A sub-diagram can be created within any of the use cases in order to clarify and understand the sub tasks which are involved. It should be that a use case actually is the representation of a user goal and not any atomic programming operation. The point here is that there should be a simple use case design so as to clarify the user expectations for the system.

photo