Systems Analysis & Design

Visual Paradigm

Software required for this course: Visual Paradigm (Community Edition) You must register but it is a free trial version

Link to Visual Pardigm community edition (free): http://www.visual-paradigm.com/download/community.jsp

Visual Paradigm User's Guide: https://www.visual-paradigm.com/support/documents/vpuserguide.jsp

Xtra-vision express URL (Importante: revisar esto para la próxima clase)

Click https://xtra-vision.ie/how-it-works/ link to open resource.

UML

The UML (Unified Modeling Language) is an international industry standard graphical notation for describing software analysis and designs.

Fundamental UML models

There are five fundamental UML models:

• Use case model
• Class model,
• Sequence model
• State model
• Activity diagrams

Use case model

The use case model consists of:

• A use case diagram,
• A set of use case descriptions,
• A set of actor descriptions, and
• A set of scenarios.

A use case diagram

The use case diagram models the problem domain graphically using four concepts:

• The use case,
• The actor,
• The relationship link, and
• The boundary.

UML symbols used to model these concepts:

• A use case: an ellipse labelled with the name of the use case. Conventionally we start each use case name with a verb to make the point that use cases represent processes. So we have 'Maintain customer list' rather than 'Customer list', 'Handle enquiries' rather than 'Enquiries'.

Use case

• An actor: a stick figure labelled with the name of the actor. We capitalize actor names so that they are easy to identify as such (e.g. Administrator, Receptionist). The stick figure icon is used even when the actor is non-human, e.g. another computer system or an organization.

Actor

• A use case relationship: a line linking an actor to a use case. The line shows us which actors are associated with which use cases. This relationship is also known as a communication association.

Use case relationship

• The boundary: a line drawn round the use cases to separate them from the actors and to delineate the area of interest. Can be labelled to indicate the diagram domain. The boundary is often omitted.

Boundary

The use case

What we do when identifying use cases is to divide up the system's functionality into chunks, into the main system activities. What dictates the split is what the user sees as the separate jobs or processes (the tasks he will do using the system).

Identifying use cases from the actors: There are several ways of approaching use case identification. One is to identify the actors, the users of the system, and for each one, to establish how they use the system, what they use it to achieve.

If we look at the interview in Chapter 2 we can see that Annie and Simon start off by talking about issuing bikes, one of the main jobs that make up Annie's working day. Issuing bikes therefore will be one of the use cases. Issuing bikes involves: finding a suitable bike, calculating the hire charge, collecting the money, issuing a receipt and recording details of the customer and the hire transaction.

The interview moves on to discuss dealing with the return of a bike. Annie sees this as a separate job from issuing the bike, it is separated in time and involves a different set of procedures- checking the date and the condition of the bike and returning the deposit.

Identifying use cases from scenarios: Another approach to identifying use cases is to start with the scenarios. We have already mentioned scenarios in Chapter 2 - a scenario describes a series of interactions between the user and the system in order to achieve a specified goal A scenario describes a specific sequence of events, for example what happened when Annie successfully issued a bike to a customer (see Figure 3.3).

Each use case represents a group of scenarios. Scenarios belonging to the same use case have a common goal- each scenario in the group describes a different sequence of events involved in achieving (or failing to achieve) the use case goal. Figures 3.3 and 3-4 describe scenarios belonging to the 'Issue bike' use case; in both cases Annie is trying to issue a bike to a customer.

Use case descriptions

The use case description is a narrative document that describes, in general terms, the required functionality of the use case.