SS ZG514 Object Oriented Analysis and Design

Library Management System

Books and Journals. The library contains both books and journals. It may have several copies of the same book. Some of the books are for short term loans only. All other books may be borrowed by any library member for 3 weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to 6 items at a time, but members of staff may borrow up to 12 items at a time. New books and journals arrive regularly and sometime disposed of; the catalogue needs to be updated. The current years journals are sent away to be bound at the end of each year. Borrowing. It is essential that the system keeps track of when books and journals are borrowed and returned. The system enforces the rules for borrowing given above.

Use Case
Use cases are simply written stories that capture some user-visible function of the system describe interaction between users and the system achieve a discrete goal for the user Use cases are text documents, not diagrams, primarily an act of writing text, not drawing. However, the UML defines a use case diagram to illustrate the names of use cases and actors, their relationships and interactions

USE CASES

An actor is a user of a system in a particular role (an actor can also be an external system) For example. Our system will have an actor BookBorrower representing the person who interacts with the system to borrow a book

A use case is a task which an actor needs to perform with the help of the system, such as Borrow copy of Book.

Use Case Diagram for the Library

Use Case Diagram for the First Iteration

Let us suppose that after discussing priorities with the customers we decide that the first iteration of the system should provide:
Borrow copy of book, Return copy of book, Journal Borrow journal, Return

Relationships Extends Relationship

Used when you have one use case that is similar to another use case but does a bit more Useful for capturing exceptions Used for describing a variation in normal behavior

Includes/Uses Relationship
Used when you have similar behavior across a number of use cases In this case one use case uses another Used when you are repeating yourself in two or more separate use cases and you want to avoid repetition

Fully Dressed Use Case Borrow Book

Pre Conditions Post Conditions Special Requirements

The book must exist The book is borrowed None

Fully Dressed Use Case Borrow Book

10

System Sequence Diagrams (SSDs)

A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output events related to the systems under discussion.

Sequence Diagrams depict the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the system.
11

12

Operation Contracts

System Operations Operations that the system as a black box offers in its public interface Identified while creating SSDs

Entire set of all system operations across all Use Cases defines the System Interface
BITS Pilani, Pilani Campus

14

15

Domain Model Illustrate meaningful conceptual classes in a realworld problem domain

Identify conceptual classes or domain objects Show associations between them Indicate their attributes when appropriate

No operations/methods Visual dictionary

relevant vocabulary of the domain important abstractions information content

Features of a domain model

The following features enable us to express time invariant static business rules for a domain: o Domain classes each domain class denotes a type of object. o Attributes an attribute is the description of a named slot of a specified type in a domain class; each instance of the class separately holds a value. o Associations an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship

Identifying Classes

In the standard jargon of analysis we often talk about the key domain abstractions. Identifying the right classes is one of the main skills of OO development. We start the process of identifying the key domain abstractions using the following approach, which is known as the noun identification technique.

Identifying a list of candidate classes

Identifying Candidate Classes

In this particular case, we discard:
Library, because it is outside the scope of our system Short term loan, because a loan is really an event, which so far as we know is not a useful object in this system Member of the library, which is redundant Week, because it is a measure, not a thing Item, because it is vague (we need to clarify it) Time, because it is outside the scope of the system System, because it is part of the meta-language of requirements description, not a part of the domain Rule, for the same reason

Identifying Candidate Classes

Book Journal Copy (of book) Library member Member of staff

Initial Class Model of the Library

multiplicities

22

Lets Revise our Class Model

Finally, we may notice that MemberOfStaff shares all the same associations that LibraryMember does, and that this agrees with our intuition that a member of staff is a kind of library member. Recording this in the class diagram will clarify our understanding of the situation, that there is a generalization relationship between LibraryMember and MemberOfStaff. Inheritance (MemberOfStaff is a subclass of LibraryMember)

Revised Library Class Model

Sequence Diagram
Consider what happens in the library scenario when a user wishes to borrow a copy of a book. The library member must first check that they are able to borrow a book (i.e., they have borrowing privileges, there exists at least one remaining copy of the book etc.).. Then the copy object must be informed that the library member wishes to borrow the copy of the book.. Finally the copy object must then tell the individual book object that it is out on loan and thus no longer available. We now see how this is recorded in a sequence diagram

Interaction Shown on a Sequence Diagram

Interaction Shown on a Collaboration Diagram

The Gymnastics System

We are about to model a gymnastics scoring system. Our mission is to automate the definition, registration, scoring, and record keeping of a gymnastic season. Here is a quick description of a gymnastics league and one of their contests: A league is a group of teams that compete against each other. Each of these clubs recruits members to participate in the contests. A typical meet consists of several contests held in the course of one day. For example, there may be a women's all-around, a women's individual, a men's all-around, and so on. There may also be junior and senior competitions. When a team enters a meet, it enters all the competitions. For each contest, each team enters the same number of members, who must compete in all parts of the competition. Each competition is a series of events run on different equipment. For example, the women's competitions involve balance beam, vault, high bar, and floor exercise. All pieces of equipment are in operation at the same time; each team's competing gymnasts perform on one piece of equipment and then rotate to the next.

The Gymnastics System

Each event has a judging panel assigned to it. These people are qualified scorers for this event. Each judge rates each gymnast on the event and reports the score to a scorekeeper. The scorekeeper throws out the high and low scores and averages the rest. This is the gymnast's score for the event. The team score is the sum of all gymnasts' scores.
Competition scores are the sum of the scores for each of the events. Meet scores are the sum of the competition scores, and so on. In addition to running the individual meets, the league prepares the schedule of meets for the season, ensures that qualified judges are assigned, registers teams and gymnasts, and publishes seasonal standings.

Use cases Identified

Use Case Diagram

Schedule Season

Judge

Scoring

<<uses>>

Scheduler

Reg Team Meet

Reg Team Comp

Compute Standings Administrator Assign Judge Change Membership

Key Classes Identified

Candidate Classes Season Meet Event Trial Competition Judge Gymnast Team Club League

Domain Model
Competition Event

contests judging panel Meet

tournament entrants Season

EventJudge scorer judges

performances

Trial

League performances participants Club competing teams Team competitors members Gymnast

The Gymnastics System

Work through micro process to develop first iteration of domain analysis
Identify the classes and objects at a given level of abstraction Identify the semantics of these classes and objects Identify the relationships among these classes and objects Specify the interface and then the implementation of these classes and objects

Naming Relationships
Name relationships and roles Use meaningful concise names A good name is simple and provides significant semantic information

Season

tournament

Meet

Club

+members

Gymnast

Design Class Diagram

-

A design class diagram illustrates the specifications for SW classes and interfaces. Typical information included:
Classes, associations, and attributes Interfaces, with their operations and constants Methods Attribute type information Navigability Dependencies

Discovering Operations/Methods
It is useful to work with object interaction diagrams when discovering operations
Some operations are identified in the conceptual perspective; more are identified in the specification perspective

CASE STUDY: A RESORT RESERVATION SYSTEM

Design the software to handle reservations at Blue Lake Resort. The resort comprises several cottages and two meeting rooms. Cottages can comprise from one to three beds. The first meeting room has a capacity of 20 persons, the second, 40 persons. Cottages can be booked by the night; meeting rooms can be booked by the hour. Rates for cottages are expressed per person, per night; rates for meeting rooms are expressed per hour. Clients can book cottages and meeting rooms in advance by providing a phone number and a valid credit card information. Customers can express preferences for specific cottages. Cancellation of reservations is possible but requires 24 hours notice. An administrative charge applies to all cancellations. Every morning, a summary of the bookings for the previous day is printed out and the related information is erased from the computer; a list of the cottages and meeting rooms that will require cleaning is printed.

USE CASES OF RESORT RESERVATION

Actors in the System -- > Client, Administartor, Receptionist Clients use cases Book a Meeting Room, Book a Cottage, Cancel Booking, Administrator Printing Reports Receptionist Printing Cash Receipts

RESORT RESERVATION
Book a Meeting room Book a Ccttage << ACTOR>>

<< ACTOR>>

Canel Booking
Client Print Reports Print Cash Receipt

Recepti onist

Administartor << ACTOR>>

System Boundary

Identification of Classes
Step 1: identify candidate classes Using nouns: extract objects from the nouns in the requirements Data flow: start with inputs and determine what objects are needed to transform the inputs to the outputs Using the things to be modeled: identify individual or group things such as persons, roles, organizations, logs, reports in the application domain that is to be modeled; map to corresponding classes
26-Oct-13

Noun identification: Case Study Design the software to handle reservations at Blue Lake Resort. The resort comprises several cottages and two meeting rooms. Cottages can comprise from one to three beds. The first meeting room has a capacity of 20 persons, the second, 40 persons. Cottages can be booked by the night; meeting rooms can be booked by the hour. Rates for cottages are expressed per person, per night; rates for meeting rooms are expressed per hour. Clients can book cottages and meeting rooms in advance by providing a phone number and a valid credit card information. Customers can express preferences for specific cottages. Cancellation of reservations is possible but requires 24 hours notice. An administrative charge applies to all cancellations. Every morning, a summary of the bookings for the previous day is printed out and the related information is erased from the computer; a list of the cottages and meeting rooms that will require cleaning is 26-Oct-13 printed.

Keeping the right candidate classes

Having made a tentative list of classes, eliminate unnecessary or incorrect classes according to the following criteria: Redundant classes: nouns that express the same information Irrelevant classes: nouns that have nothing to do with the problem Vague classes: nouns with ill-defined boundaries or which are too broad Attributes: nouns referring to something simple with no interesting behavior, which is simply an attribute of another class Events or operations: nouns referring to something done to the system (sometimes events or operations are to be kept: check if they have state, behavior and identity). Outside the scope of the system: nouns that do not refer to something inside the system
26-Oct-13

Refined list: Case Study

Good classes: Cottage, Meeting room, Client Bad classes: Software, Blue Lake Resort, Bed, Capacity, Night, Hour, Rate, Phone number, Credit card information, Customer, Preference, Cancellation, Notice, Administrative charge, Morning, Day, Information, Computer Dont know: Reservation, Resort, Summary, List

26-Oct-13

RESORT RESERVATION Practice

Domain Model Interaction Diagrams

49

Royal Service Station Requirements - Practice

Royal Service station provides three types of services The system must track bills, the product (parts), and services System to control inventory The system to track credit history, and payments overdue The system applies only to regular repeat customers The system must handle the data requirements for interfacing with other systems The system must record tax and related information The station must be able to review tax record upon demand The system will send periodic message to customers Customers can rent parking space in the station parking lot The system maintains a repository of account information The station manager must be able to review accounting information upon demand The system can report an analysis of prices and discounts The system can not be unavailable for more than 24 hours The system must protect customer information from unauthorized access The system will automatically notify the owners of dormant accounts