View
57
Download
2
Category
Preview:
DESCRIPTION
dsfdsfdsfdsfdsfdsfds
Citation preview
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
Recommended