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.

Para entender y practicar el UML nos vamos a basar en el ejemplo descrito en el libro «A STUDENT GUIDE TO OBJECT-ORIENTED DEVELOPMENT». The aim of this book is to describe what happens when a computer system is developed for a small business, in this case «the Wheels bike hire company». The approach used is object-orientation, which means that the whole development process is based round the object- a thing or concept that initially represents something in the real world and eventually ends up as a component of the system code.

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.

Annie tells us in the interview that a list of bikes is already held on the computer, but they do not seem to be able to use it to help them in their work. The bike list needs to be stored so that it can be used to answer queries about what bikes Wheels have, whether they are available or on hire, what their deposit and hire charges are and so on. Maintaining this bike list is another use case.

Handling queries is seen by Annie as a separate job from issuing bikes. She often gets people coming into the shop or phoning just to check on the range of bikes available and get an idea of costs. This sometimes leads to a hire, but more often it does not. We can therefore identify Handle enquiries as a separate use case.

It also emerges from the interview that no record is kept of customer details or of what bikes they have hired on previous occasions. This sort of information would be useful for marketing purposes and to simplify dealing with requests for the same bike (see the Problem Definition (Figure 2.6), the Problems and Requirements List (Figure 2.7) and the Interview Summary (Figure 2.8)). Maintain customer list can therefore be identified as a use case.

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.