SS ZG514Object 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 year’s 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, Borrow journal, Return

Journal

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

8

9

Pre Conditions The book must exist

Post Conditions The book is borrowed

Special Requirements None

Fully Dressed Use Case Borrow Book

10

Fully Dressed Use Case Borrow Book

11

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.

12

BITS Pilani, Pilani Campus

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

Operation Contracts

14

15

Domain Model

• Illustrate meaningful conceptual classes in a real-world 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

22

multiplicitiesmultiplicities

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 SystemWe 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

Reg Team Meet Reg Team Comp

Assign Judge

Scheduler

ScoringJudge

Compute Standings

Change Membership

Administrator

<<uses>>

Key Classes Identified

Candidate Classes

• Season• Meet• Event• Trial• Competition• Judge• Gymnast• Team• Club• League

Domain Model

Season

Meet

tournament

Competition

contests

Event

EventJudge

judging panel

Trial

performances

scorer

League

judges

Team

entrants

Club

participants

competing teams

Gymnastcompetitors

performances

members

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 Meettournament

Club Gymnast+members

• 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

Design Class Diagram

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

Seasonend : Datestart : Date

Attendeeaddress : Stringname : String

Meetdate : Datesite : Locationtitle : String

registerClub()

1

1..*

1

1..*

tournament

Clubname : String

Competition

enterteam()individualScore()

1

1..*

1

1..*contests

Membershipfrom : Dateto : Date

1*

1+affiliate

*

Team*

*

+entrants

+participant

*

1

*

1

*

competing teams

EventType

is_qualified()

Leaguename : String

1

1..*

1

1..*participants

Event

addJudge()score()individualScore()teamScore()

*1

*1 kind

1 1..*1 1..*

GymnastbirthDate : Dategender : Booleanname : String

*

1

*+members

1

**+competitors

**

Trial

overallScore()addScore()score()

1

*

1

*

performances

*

1

*

1

performances

EventJudge

is_assigned()score()

*

*

+qualified scorer*

*

1

*

1

*judges

*

*

*

*

judging panel

**

+scores

*

+scorer

*

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

• Client’s use cases Book a Meeting Room, Book a Cottage, Cancel Booking,

• Administrator Printing Reports • Receptionist Printing Cash Receipts

RESORT RESERVATION

Client

<< ACTOR>>

Receptionist

Book a Meeting room

Book a Ccttage

Canel Booking

Print Reports

Print Cash Receipt

System Boundary

<< ACTOR>>

<< ACTOR>>

Administartor

Identification of Classes

• Step 1: identify candidate classesUsing nouns: extract objects from the nouns in

the requirementsData 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

Apr 17, 2023

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.

Apr 17, 2023

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.

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

Apr 17, 2023

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

• Don’t know: Reservation, Resort, Summary, List

Apr 17, 2023

49

RESORT RESERVATION - Practice

Domain ModelInteraction Diagrams

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