CS 4393: Topics in User Interfaces
[Week 9] Use-case driven development and the ICONIX Process

Objectives:

• Understand how use cases can be used for requirements gathering.
• Start to see how use cases and task modeling can be used to develop well-organized implementations.
• Develop problem statements and domain models.
• Use a UML modeling tool.
• Learn to apply the ICONIX process

Programming topic: Use case diagrams, domain models and robustness diagrams in Visual Paradigm

Assignment: Applying the ICONIX process to the photo-analyzer

Reading:

• RS: Chapters 1 through 5
• Top Ten Design Mistakes with Use Cases by Doug Rosenberg and Kendall Scott
• Documenting a use case: What to include and why by Scott Ambler
• Modeling essential use cases: Where you're coming from and where you're going by Scott Ambler
• UML 2 Use Case Diagram Overview by Scott Ambler

Class schedule:

• Monday:
  • Sit with new partner
  • Setup:
  • Make a VisualParadigmProjects directory under c:\EclipseDevelopment
  • Download the Visual Paradigm 5.3 UML license from webCT to this directory
  • Download InternetBookStore.zip into the c:\EclipseDevelopment\VisualPardigm subdirectory and unzip it
  • Open VisualParadigm and browse to set the license file
  • Under File->open
  • Get back exam
  • Introduction to the ICONIX process
  • Domain models
  • Go through mistakes in domain modeling
  • Produce a domain model for photo organizer
• Wednesday:
  • Go through use case analysis examples for Internet bookstore
  • Produce a use case diagram for photo organizer
  • Check requirements against use cases with partner
  • Introduce robustness analysis
• For Friday:
  • Go through examples of bad robustness diagrams
  • Work on photo organizer robustness.

Quote:

Brooks's Law /prov./ "Adding manpower to a late software project makes it later" -- a result of the fact that the expected advantage from splitting work among @Math{N} programmers is @Math{O(N)} (that is, proportional to @Math{N}), but the complexity and communications cost associated with coordinating and then merging their work is @Math{O(N^2)} (that is, proportional to the square of @Math{N}). The quote is from Fred Brooks, a manager of IBM's OS/360 project and author of "The Mythical Man-Month" (Addison-Wesley, 1975, ISBN 0-201-00650-2), an excellent early book on software engineering. The myth in question has been most tersely expressed as "Programmer time is fungible" and Brooks established conclusively that it is not. Hackers have never forgotten his advice; too often, management still does. See also creationism, second-system effect, optimism.

-- The New Hacker's Dictionary

---

Introduction to the ICONIX design process

We will use the ICONIX process to develop software (from Applying Use Case Driven Object Modeling with UML by Doug Rosenberg and Kendall Scott, Addison Wesley, 2001). We assume that we start the process with a problem statement and a (brief) set of functional requirements. As the process proceeds, the functional requirements list may be expanded.

• Requirements analysis:
• Do some mock-ups of the GUIs.
• Define the most important nouns of the problem and start drawing a high-level class diagram (the domain model)
• Identify use cases using use case diagrams
• Organize use cases into groups and capture with a package diagram
• Allocate functional requirements to use cases and domain objects
• Milestone 1: Requirements review
• Preliminary design and analysis:
• Write use case descriptions (basic and alternative courses)
• Do a robustness analysis for each use case and update domain model
• Update class diagram
• Milestone 2: Preliminary design review
• Detailed design:
• Identify messages between objects and associated methods
• Draw sequence diagram with use case text down left size
• Update other diagrams as you work through the text
• Add detailed design information (e.g., visibility, etc)
• Milestone 3: Critical design review
• Implementation:
• Produce diagrams as needed (deployment, component, etc.)
• Write/generate code
• Unit and integration testing
• Perform system and user-acceptance testing using use cases
• Milestone 4: Delivery

The following image (from Fig 1-7 of Applying Use Case Driven Object Modeling with UML by Rosenberg and Scott) summarizes the ICONIX process:


Example: Internet Bookstore

Problem statement: Provide a system to manage convenient online browsing and shopping for a bookstore that connects with its existing database and inventory management system.

Functional requirements:

• The bookstore shall accept orders over the Internet.
• The bookstore shall provide password protection for all accounts.
• The bookstore shall provide the ability to search the master book catalog.
• The bookstore shall provide different methods of searching including by author, by title, by ISBN and by keyword.
• The bookstore shall provide a secure means of credit card payment.
• The bookstore shall provide a secure means purchase order payment.
• The bookstore shall provide accounts for preauthorized purchase orders.
• The bookstore shall provide electronic links between the Web, database and shipping fulfillment system.
• The bookstore shall provide electronic links between the Web, database and inventory management system.
• The bookstore shall maintain reviews of books and allow anyone to upload review comments.
• The bookstore shall maintain ratings on books, based on customer input.

---

Introduction to UML tools

There are a number of tools such as Rational Rose and Visual Paradigm that support the development of UML specifications of problems. Some of the tools support round-trip engineering. These tools allow you to keep a UML model of a project that is consistent with the code. We are going to user Visual Paradigm Standard Edition 5.3 in class. You are entitled to download a version of Visual Paradigm Standard Edition for use in this class. (You can also use the Community Edition, which has no restrictions, but it prints class diagrams with a VP watermark across the face. (You can always take screen shots.) Since you will be uploading Visual Paradigm projects for turn-in this won't be an issue.

Setup: Download the license files for both the UML tool and the Eclipse SDE and save them in your working directory. You will find the licenses in WebCT in the Licenses area of the Communication section. Bring up Visual Paradigm and load the license. See VP Gallery at http://www.visual-paradigm.com/VPGallery/index.html for a summary of the diagrams and their uses.

In class we will demo the following items:

• Creating a project
• Project properties on the File menu
• Tools -> Modeling -> Options
• Distribute Shapes
• Sweeper
• Use case diagrams
• Use Cases (details and description templates)
• Domain models
• Sequence diagrams

---

Domain modeling

Steps in domain modeling:

• Identify the main conceptual objects that participate in the system
• Identify relationships among objects (generalization and aggregation)
• Draw a high-level class diagram (no fields, attributes or implementation details) to represent this information
In analyzing a high-level statement, the nouns and noun phrases tend to become objects and attributes.

Top ten domain modeling errors:

• Assign multiplicities and other details during initial domain modeling.
• Exhaustively analyze nouns and verbs (resulting in too low-level a specification.
• Assign operations to classes without exploring use cases and sequence diagrams.
• Optimize code for reusability before considering requirements.
• Debate aggregation or composition for each association.
• Presume a specific implementation strategy.
• Use hard-to-understand names for classes.
• Jump to implementation constructs.
• Create one-for-one mapping with database tables.
• Perform "premature patternization".

Exercise: Find the errors in the domain models given in the 5 exercises on the Internet Bookstore.

Exercise: Create a domain model for the photo organizer in Visual Paradigm.

---

Use cases and user roles

Example: User roles for Internet bookstore

• casualSeeker - just wants to see what is available with prices and does not have an account.
• customer - person with an account who actually purchases items.
• shippingClerk - employee who handles the shipping of orders.
• shipper - third party who actually performs delivery
• inventoryClerk - employee in charge of reordering items.
• maintainer - anyone who updates information.
• systemMaintainer - employee who handles problems with the system.
• personalMaintainer - customer who updates personal information.
• customerServer - employee who deals with problems that customers encounter such as lost credentials or identify theft.
• advertiser - company client who wishes to advertise item.
• receivingClerk - employee who receives new stock items and updates inventory.
• paymentClerk - employee who handles accounts payable and accounts receivable.

Example: Use cases for the Internet Bookstore

• identifyingSelf - purpose: gain access to information
• employeeIdentifyingSelf - purpose: gain access to job functions.
• customerIdentifyingSelf - purpose: gain access to own information and allow purchases
• browsing - purpose: just looking around to see what is available
• searching - purpose: find something specific
• searchingByAuthor
• searchingByTitle
• searchingByKeywords
• openingAccount
• managingOrder
• creatingOrder
• trackingOrder - finding out where it is in the process
• cancelingOrder
• placingOrder
• addingToOrder
• viewingOrder
• addingToHoldList
• updatingInventory
• addingItemsToCatalog
• viewingPersonalInformation
• updatingPersonalInformation
• shippingOrder
• reorderingItems
• addingNewItems
Do these use cases cover the requirements?

Iconix process use case:

• Basic course
• Alternative courses
What happens? Then what happens? .... What else could happen?

Top 10 use case modeling errors:

• Write functional requirements instead of usage text.
• Describe attributes and methods rather than usage.
• Write the use cases too tersely.
• Divorce use case from user interface.
• Avoid explicit names for boundary objects.
• Write in passive voice (not user's perspective).
• Describe user interaction but not system response.
• Omit alternative courses.
• Focus on something other than use case (e.g., how you get there).
• Worry about includes and extends
Example: Open Account (Version 1)

Basic course: The Customer enters the required information. The system validates the information and creates a New Account object.

Alternative course: If any data is invalid, the system displays an appropriate error message.

Critique of Version 1:

• Too terse
• No reference to what customer is entering
• No reference to page (boundary object) that Customer is on
• No explanation of the validation
• How should the Customer respond to an serror condition.
Example: Open Account (Version 2)

Basic course: On the New Account Page, the Customer types name, email address, password (twice) and then presses the Create Account button. The system ensures that the Customer has provided valid data and then creates an Account. The system then returns the Customer to the Home Page.

Alternative courses:

• If the Customer did not supply a name, the system displays an error message and a prompt to type name.
• If the Customer provided a badly-formed email address, the system displays message and a prompt to enter email of different form.
• If the Customer provided an insecure password, the system displays an error message and a prompt to enter better password.
• If the Customer did not type password twice, the system displays an error message and prompts for second password entry.

Top 10 requirements review errors
• Don't review requirements at all. (Requirements should be reviewed and prioritized to avoid feature-itis.
• Don't match use case text to desired system behavior and what users want to do.
• Don't use a GUI prototype to validate screen behavior.
• Keep use cases so abstract that no one really knows what they are about.
• Don't make domain model reflect real-world conceptual objects.
• Don't reference domain objects in use cases.
• Don't examine use cases that have no alternative courses.
• Don't question whether all alternative courses have been considered.
• Write use cases in passive voice.
• Write length use cases.

---

Robustness diagrams

Robustness diagrams (from Applying Use Case Driven Object Modeling with UML by Rosenberg and Scott) bridge the gap between text specification and code design:

• Elements:
• Actor
• Boundary object
• Entity object
• Control object
• Rules:
• Actors can only talk with boundary objects
• Boundary objects can only talk with control objects and actors
• Entity objects can only talk with control objects
• Control objects can talk to everything except actors
(See the Robustness Diagram Rules class diagram in the Internet Bookstore Visual Paradigm project.)

Common mistakes in using robustness diagrams (from Applying Use Case Driven Object Modeling with UML by Rosenberg and Scott):

• Violate the rules
• Skip using robustness diagrams to check use case consistency
• Don't put alternative courses on robustness diagram
• Don't use robustness diagrams to check consistency between use case text and class names
• Allocate behavior to entity objects
• Include too many or too few control objects
• Waste time making robustness diagram perfect
• Make robustness diagram too detailed
• Don't perform visual trace between use case text and robustness diagram
• Don't update the static model

---

Use case review

A Use case describes the way real-world actors interact with the system. Use cases can be used both to drive requirements gathering and to object modeling. Use cases are the basis for usage-centered design.

What are actors? An Actor is another that interacts with the system --- a person, other software, a peripheral device, a network, or even time (as represented by a clock).

A use case diagram: is a graphical representation of a collection of use cases. The actors are presented by stick figures. The actors are connected to individual use cases, which are represented by labeled balloons.

Example: Look at the UML 2 Use Case Diagram Overview by Scott Ambler. This web page gives specific examples of use case diagrams, release groups, and using packages.

Use case names: (Kulak and Guiney)

• Use noun-verb (e.g., printLetter)
• Can contain adverbs and adjectives
• Should not be instances of classes
• Should not contain situation-specific or implementation-specific behavior (e.g., create form 104B)
• Should not contain organizational structure (e.g., getAccountingDepartmentSupervisorApproval)

Example: Strong verbs for use case names: merge, remove, defer, register, combine, browse.

Example: Weak verbs for use case names: use, report, process, display.

Example: Strong nouns for use case names: property, price, date, costs.

Example: Weak nouns for use case names: data, form, template.

Example: Critique the list of use case names for photo-organizer.

Unfortunately there is no standard definition or format for use cases. Alistair Cockburn complains in Structuring Use Cases with Goals that he has encountered more than 18 different definitions from experts. Each has its own format.

Use case formats generally fall into 3 levels of detail: informal, semiformal and formal. An informal use case is generally a simple text paragraph. The more formal specifications vary in their format. Essential use cases are technology and implementation independent descriptions of use.

Types of use cases that we will develop: informal, essential, semiformal and formal.

Informal - a clearly stated paragraph (nothing technical) about how the actor uses some aspect of the system.

Essential - dialog format of Constantine and Lockwood with no implementation details and only a basic course.

Semiformal - the Rosenberg and Scott format:

• Name
• Goal
• Precondition
• Basic course
• Extended courses (optional, but usually there are a lot of them)
• Post condition

Formal use-case (from Moving to Use Cases by Daryl Kulak and Eamonn Guiney, ACM Press, 2000)

• Use case name
• Iteration (i.e. facade, filled, focused and finished)
• Summary (one or two sentences)
• Basic course of events (represents a simple, correct, most common path through the program)
• Alternative paths (represents less common paths)
• Exception paths (error paths)
• Extension points (shows points where another use case extends this one)
• Triggers (list of conditions that should be true when actor begins use case)
• Assumptions (things that are assumed true but might not be when use case is performed)
• Preconditions (things that must be in place for interaction to occur)
• Postconditions (things that are satisfied after use case completes successfully)
• Related business rules (relevant written or unwritten rules about the business)
• Author
• Date
Use Case Diagram relationships:
• include (dashed arrow-include) to avoid repetition in two or more use cases.
• generalization (is-a triangular arrow) for variations on normal behavior
• extend (dashed arrow - extend) for variations on normal behavior where you specify extension points (like abstract methods in abstract classes).

---

Use cases for requirements gathering

The discussion in this section is taken from the excellent book: Use Cases: Requirements in Context by Daryl Kulak and Eamonn Guiney. These authors contend that traditional requirements gathering produces large documents that the customers can't understand, so they blindly sign off on them. Often these documents contain conflicts, redundancy, and design assumptions. Worse, requirements are not traceable.

Functional requirements: are what the users need. These can be reflected in use cases.

Nonfunctional requirements: describe hidden aspects of the system that are needed to actually get the job done. They often end with "-ility" (e.g., scalability).

Traceability:

• What requirements are relevant for classes on a class diagram? (Designer)
• What requirements are specific to a particular class? (Developer)
• What requirements are being tested in a particular test case? (Tester)
• How are the requirements reflected in the use? (Documenter)
• What requirements have been changed that require a code modification? (Maintainer)

Four steps in requirements gathering (Kulak and Eamonn)

• Facade - high level description. We will need a problem statement and use case diagrams with informal uses cases. (In the real world, you would need things such as statement of work, risk analysis, business rules, etc. resources are finite and there are other constraints.
• Filled - break out detailed use cases and create filled use cases. Document non-functional requirements (e.g., availability, cost, portability, etc.).
• Focused - separates the essential from the would be nice... how are you going to build your releases
• Finished - add user interface requirements

---