Showing posts with label uml. Show all posts
Showing posts with label uml. Show all posts

Wednesday, May 6, 2009

Shopping Cart Web Application - Design - Part 2

Introduction
In this article we define the classes the shopping cart application is going to use. We also build a sequence diagram for one of our use cases.

Before we get started
I created the diagrams using ArgoUML. It is a UML modeling tool that you can download for free. If you download and install ArgoUML you should also be able to open the ShoppingCart modeling project I created.

What we will cover
  • Class diagrams
  • Sequence diagrams

Level
  • Introductory

Class Diagrams
A class diagram is used to describe the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.
Figure 1 – shopping cart class diagram

The Shopping Cart Class Diagram defines the following classes:

1. Business Objects (Domain Model)
A domain model can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships. The model identifies the relationships with other entities within the system as well as their methods and attributes.  The following two classes make up our domain model:
  • Basket
  • Item

2. Business Delegate
For simplicity the shopping cart application classes that handle the business logic reside within the web application. Although this is not always the case, more often than not the business logic resides outside of the web application. The Business Delegate pattern can be used to hide the underlying implementation details of the business service, such as lookup and access details. Our application doesn’t apply the business delegate pattern but I do feel it us important to mention it. The classes that handle the business logic are:
  • ShoppingService
  • ShoppingManager

3. View classes
The view classes represent the user interface views of our application. There is also a helper class that manages all the calls made to the Shopping Manager service class. These classes are modeled after the View Helper design pattern: 
  • Items
  • Checkout
  • ShoppingViewHelper
The above mentioned class diagrams are very high level and intended for beginners. I would encourage you to search the web for more in depth tutorials. Here are a few more examples:

Sequence Diagrams
A sequence diagram shows how processes operate with each other and in what order. 
  • The vertical lines in sequence diagrams represent different processes or objects that make up a system.
  • The horizontal arrows are messages exchanged between the different processes and objects in the order in which they occur.
Sequence diagrams are used to look at the behavior of several objects within a single use case. They are useful to identify any architectural or logical problems at an early stage.
I wouldn’t recommend doing a sequence diagram for every use case, only the real important ones.
Figure 2 – find items sequence diagram
Once again I highly recommend you take the time to search the web for further reading as well as for you to apply what you have learnt in your own projects. Here is another introduction to sequence diagrams:

Friday, May 1, 2009

Shopping Cart Web Application - Analysis - Part 1

Introduction
Welcome to the first tutorial I have written in this series of learning how to develop Java web applications. I will be using the same application throughout this series so I thought what better way to kick start this series than to start at the beginning. Before any code is written it is a good idea to understand what is required from us. In this tutorial we are going to define what those requirements are and then we will package those requirements in an industry recognized format and standard known as UML use cases.

What we will cover
  • Define business requirements
  • Specify the use cases for our application based on the requirements
  • Write use case specification for one of our use cases

Level
  • Introductory

Overview
The shopping cart application will be an online shopping store. I have decided that our store will be called “Scooby Doo's Little Shop of Horrors”. A visitor to the website will be able to browse a number of different ingredients and add them their virtual shopping basket so that ultimately they can create their very own custom made Scooby Dooby Monster Sandwich. Yeah I bet that just wet your appetite.

Requirements
  1. User must be able to browse items that the store is selling.
  2. Each item should have at least a price associated to it as well as a name and a description. Would be nice if it had an image. 
  3. The user should be able to enter in the quantity of how many items he / she wants to purchase (for now this can be optional). 
  4. There should be a link / button next to the item so that the user can add this item to their shopping cart. 
  5. There should be a checkout link / button that the user can click on at any time. This link will take the user to the checkout page. 
  6. When the user clicks on the checkout link he / she must be redirected to another page where the items the user has added to the shopping cart are displayed, along with their name, description and price. A total price of how much all items cost must also be displayed. 
  7. On the checkout page the user must be able to confirm payment. On clicking this link the user is taken to a confirmation page that says: “Thank you. You order has been processed.” This page should also have a link that takes the user back to the home page where they can start a new order if they so choose. 

Use Case Diagram
Our next step will be to identify the use cases that make up our application. A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system. A use case diagram is used to graphically represent the overview of the use cases. A use case diagram models the behavior of a system and helps to capture the requirements. It identifies the interactions between the system and its actors, and defines the scope of the system. 

There are two main components used within use case diagrams:
  • Actor - Represents a role of a user that interacts with the system. The user can be a human user, an organization, a machine, or another external system.
  • Use case - Describes a function that a system performs to achieve the user's goal. A use case must yield an observable result that is of value to the user of the system.
 
The use cases and actors shown in a use case diagram describe what the system does and how the actors use it, but not how the system operates internally. To relate an actor and a use case, you can create an association relationship to indicate the connection between the two model elements.

For our shopping cart application I have identified the following use cases based on the business requirements:
  • Show items – Display a list of items for sale
  • Add item to shopping cart – Add an item to the shopping cart
  • Checkout – Display the list of items added to the shopping cart along with the total cost
  • Process payment – Empty the shopping cart and display a meaningful message thanking the user for their payment 



Figure 1 – shopping cart use case diagram

For further reading I would encourage you to search on the internet for more use case diagram tutorials, two examples would be: 


The above diagram was created using ArgoUML. You can download it and use it for free. There is also an Eclipse plugin but I haven’t been too impressed with it and find the standalone IDE much better to use. Having said that I wouldn’t say it is a great tool either. I have tried a few free tools available but haven't been completely satisified in finding a tool that can be used to build most diagrams. 

ArgoUML have a manual with some pretty good advice in terms of UML design and project development principles. I highly recommend you take the time to read it: 

 
Use Case Specification
Once the use cases have been identified it is time to flesh out the detail for each one. This is done in a use case specification document. Some software development processes do not require anything more than a simple use case to define requirements. However, some other development processes require detailed use cases to define requirements. 

There is no standard template for documenting use cases. I would encourage you to use templates that work for you and your company. A typical specification would have the following sections:
  • Use case name
  • Version
  • Goal
  • Summary
  • Actors
  • Preconditions
  • Triggers
  • Basic course of events
  • Alternative paths
  • Post conditions
  • Business rules
  • Notes
  • Author and date

I created a very basic Shopping Cart - Add Item Use Case Specification document, you can download it from here.