Use Case Diagram

Use case diagrams, which realise a behavioural aspect of the model. The behavioural view has an emphasis on functionality, rather than the control and logical timing of the system. The use case diagram represents the highest level of abstraction of a view that is available in the UML and it is used, primarily, to model requirements and contexts of a system. Use case diagrams are arguably the easiest diagram to get wrong in the UML.

There are a number of reasons for this:

  • The diagrams themselves look very simple, so simple in fact that they are often viewed as being a waste of time.
  • It is very easy to go into too much detail on a use case model and to accidentally start analysis or design, rather than very high-level requirements and context modelling.
  • Use case diagrams are very easy to confuse with data flow diagrams as they are often perceived as being similar. This is because the symbols look the same since both use cases (in use case diagrams) and processes (in a data flow diagram) are represented by ellipses. In addition, both use cases and processes can be decomposed into lower-level elements.
  • Information on the practical use of use cases is surprisingly sparse, bearing in mind that many approaches that are advocated using theUMLare use case driven. In addition, much of the literature concerning use case diagrams is either incorrect or has major parts of the diagrams missing!

An actor represents the role of somebody or something that somehow interacts with the system.

The system boundary is used when describing the context of a system. Many texts and tools ignore the use of the system boundary or say that it is optional without really explaining why. Think of the system boundary as the context of the system and its use becomes quite clear and very useful.

There are three basic types of ‘Relationship’ which are ‘Extends’, ‘Includes’ and ‘Association’. An ‘Association’ crosses a ‘System boundary’ and, wherever this happens, it means that an interface must exist. The ‘Extends’ relationship allows atypical characteristics of a use case to be defined via an ‘Extension point’ that will actually define these conditions explicitly.

Figure 5.66. Graphic representation of elements of a use case diagram

 

One of the problems that many people have with using use case diagrams is how to tie them into the rest of the system model. It is not uncommon to be presented with a beautiful set of use case diagrams and then to be presented with a wonderful system model with no relationships whatsoever between the two!

 

Examples and modelling

Use case diagrams have two main uses: modelling contexts and modelling requirements. Although these two types of use should be related, they are distinctly different. For a full description of using use case diagrams, see Chapter 7. This section will concentrate purely on the mechanics and practical use of use case diagrams. In addition, there are two types of context that can be modelled with regard to systems engineering: the system context and the business context. The first two example models show a business context and a system context for the ongoing chess game example.

 

Figure 5.68 shows the business context for the chess game. The business context shows the business requirements of the organisation and identifies actors (see the discussion on stakeholders in Chapter 7) that are associated with the business requirements. The business requirements that have been identified are as follows:

  • ‘make money’, which is a business requirement that will be present on almost all business contexts in the world. This may seem obvious, but when asking for funding for a project the response from management is, invariably, ‘make a business case and then we’ll look at it’. By identifying the business requirements of your organisation, it is possible to start justifying expenditure for future projects.
  • ‘ensure quality’ is a nonfunctional requirement that will impact on everything that the organisation does. This is particularly true when organisations are trying to obtain, or have already obtained, some form of standard accreditation.
  • ‘make games’ is basically what the organisation does, which has two subtypes: ‘make chess’ and ‘make draughts’.
  • ‘make chess’ is the main business requirement that the system used so far in this book has been concerned with. We can now see, however, how the requirement ‘make chess’ will help the organisation ‘make money’, which is very important. • ‘make draughts’ is shown simply to indicate that the company may make more than one type of game.

The actors that have been identified for the system must each have some sort of association with at least one use case. If an actor exists that does not have an association with a use case, there is something seriously wrong with the model.

 

Figure 5.69 shows the system context, rather than the business context. It is important that these two contexts can be related in order to justify why a particular project should exist.

Figure 5.69 shows the system context for the chess game. The use cases that have been identified are, at this level, very simple and very high level. The use case ‘play chess’ represents the main use of the chess system that is being developed. The second use case, ‘teach chess’, shows the secondary function of the chess system, which is to teach a ‘Learner’ how to play chess. One argument that is often levelled at use case diagrams is that they are too simple and fail to add anything to a project. However, no matter how simple, a good use case diagram can contribute to a project in several ways:

  • They can be traced back to a business context to help justify a project. Quite often it is the case that a simple one-sentence description is required to sum up a whole project and a good system context will show exactly that.
  • They can give a very simple overview of exactly what the project is intended to achieve and for whom.
  • They can form the basis of lower-level, decomposed use case diagrams that add more detail.

It is also worth remembering that just because a use case diagram looks simple, it does not mean that it took somebody two minutes to create and did not involve much effort. This is only true when it comes to realising the model using a CASE tool, but even the most simple of diagrams may take many hours, days or even months of work.

Remember that what is being visualised here is the result of requirements capture, rather than the actual work itself.

Figure 5.70 shows how a single requirement may be taken and modelled in more detail, by decomposing the requirement into lower-level requirements. It shows the ‘teach chess’ requirement that has been decomposed into three lower-level requirements: ‘read set up’, ‘indicate move’ and ‘show thinking’. Each of these requirements is a component requirement of the higher-level requirement that is indicated by the special type of association ‘«includes»’, which shows an aggregation-style relationship.

 

The second special type of association is also shown here and is represented by the stereotype ‘«extends»’. The ‘«extends»’ relationship implies that the associated use case somehow changes the functionality of what goes on inside the higher-level use case. In the example here, the extending use case is ‘indicate error’, that extends the functionality of ‘indicate move’ in the event that something untoward happens and forces ‘indicate move’ to behave in a different way.

 

Figure 5.71 shows what a use case diagram should not look like, which is a mistake that is very easy to make.

The model in Figure 5.71 shows how a model should not be created as it defies the objectives of use case diagrams. There are several points to consider here:

  • The definition of a use case is that it must yield some observable result to an actor. In the example shown here, the decomposed use cases do not yield any observable result to the actors – they are modelled at too low a level.
  • Remember that the aim of modelling requirements is to state a user’s needs at a high level and not to constrain the user with proposed solutions. The example shown here has done exactly that and has started down the design road – which is inappropriate at this level.
  • The diagram is turning into a dataflow diagram by starting at the highest level and decomposing until the problem is solved. Use cases are not the same as dataflow diagrams, despite appearances, and should not be used as such.
About these ads
    • expertester
    • March 14th, 2010

    http://www.karonaconsulting.com/downloads/UseCases_IncludesAndExtends.pdf

    document (in pdf) yg menerangkan perbezaan includes dan extends in great detail. Recommended.

    • expertester
    • March 15th, 2010

    Another very good information regarding use case. Exception vs Extension.

    http://www.agilemodeling.com/artifacts/systemUseCase.htm

    • expertester
    • March 15th, 2010

    Wikipedia pun citer use case template in detail LOL:

    http://en.wikipedia.org/wiki/Use_case

    • expertester
    • March 15th, 2010

    Use cases describe the system from the user’s point of view.

    Use cases describe the interaction between one or more actors (an actor that is the initiator of the interaction may be referred to as the ‘primary actor’) and the system itself, represented as a sequence of simple steps. Actors are something or someone which exists outside the system (‘black box’) under study, and that take part in a sequence of activities in a dialogue with the system to achieve some goal. Actors may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor.[1]

    • expertester
    • March 15th, 2010

    A system use case is normally described at the system functionality level (for example, create voucher) and specifies the function or the service that the system provides for the user. A system use case will describe what the actor achieves interacting with the system. For this reason it is recommended that a system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). Generally, the actor could be a human user or another system interacting with the system being defined.

    A use case should:
    Describe what the system shall do for the actor to achieve a particular goal.
    Include no implementation-specific language.
    Be at the appropriate level of detail.
    Not include detail regarding user interfaces and screens. This is done in user-interface design.

    • rose
    • July 7th, 2010

    i want the use case diagram for bio informatics.(software project management lab) & give the basic concet of bio informatics.

  1. I leave a response when I especially enjoy a article
    on a blog or I have something to contribute to the conversation.

    Usually it’s a result of the passion displayed in the article I read. And on this article Use Case Diagram | My CS231. I was actually excited enough to create a comment :-P I do have 2 questions for you if you don’t mind.
    Could it be just me or does it give the impression like some of these responses appear as if they are coming
    from brain dead folks? :-P And, if you are posting on other
    online sites, I would like to follow you. Could you list all of your shared pages like your twitter feed,
    Facebook page or linkedin profile?

  2. For hottest news you have to visit the web and on internet I found this web
    page as a finest website for newest updates.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: