Mohit OOAD - List of Practicals - MCA-IV Sem

Q1) Draw a Usecase Diagram, Activity Diagram, Analysis Model and Sequence Diagram (for each usecase).
Write description of each use case for a Simple Answering Machine given below. o Use Case: Leave a Message Actor: Caller Pre-Condition: Room on Tape Post-Condition: New Message o Use Case: Review Messages Primary Path: Review New Messages Alternate Path: No New Messages o Actor: Owner
Use Case: Review Messages Locally o Primary Path: Review New Messages o Alternate Path: No New Messages o Inherit: Review Messages Use Case: Review Messages Remotely o Primary Path: Review New Messages o Alternate Path: No New Messages o Inherit: Review Messages o Uses: Authorize Access Use Case: Authorize Access o Primary Path: User Authorized o Alternate Path: User Not Authorized
Sol:Use case diagram:-
Review caller message
Rakesh sherwal
00711604411
Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
This use case is used to review the message left by caller Owner,Machine Owner reviews the messages
None The caller has left a message to be reviewed Message is reviewed
Delete caller message
This use case is used to delete the message left by caller Owner,machine Caller selects a message Caller deletes the message None Message should be present none
Record greeting
This use case is user to record a greeting for the caller Owner , Machine Owner press the record button Owner records a greeting for caller None None The machine has a greeting message for caller
Play greeting
Brief Description Actors
This use case is used to play a greeting when a caller calls and the owner is unable to answer the call Caller, Machine
Rakesh sherwal
00711604411
Flow of Events Alternative Flow Precondition Post condition
Caller calls the owner Machine plays the message Caller calls the owner None None
Set answer mode
This use case is used to set the answering mode by owner owner, Machine Owner sets the answering mode
None None None
Take caller message
This sue case is used to record the callers message in the machine Caller, Machine Caller calls the owner. Owners provides a message to be recorded. Machine records the message None None None.
Analysis model:-
Rakesh sherwal
00711604411
Sequence diagram:-
Q2) Draw a Use Case Diagram (with use-case description), that shows the system that the requirements are specifying and any interactions with external systems/users, Analysis Model and class diagram based on a set of requirements for a HD TV System. Watch Out! Some of the requirements are non-functional and so wont become use cases. Also, some of the requirements may result in more than one use case.
1. Requirement 1. The user shall be able to turn the system on at the
press of a button either on the system itself, or by means of a remote control.
Rakesh sherwal
00711604411
2. Requirement 2. The user shall be able to change the channel at the
press of a button either on the system itself, or by means of a remote control. 3. Requirement 3. The System shall be tunable to any broadcast channel at the press of a button either on the system itself, or by means of a remote control. 4. Requirement 4. The System shall have a built-in tuner as well as being capable of connecting to an external tuner. 5. Requirement 5. The System shall be able to display HD 1080 progressive scan content at 1,9201,080 resolution in wide-screen mode. 6. Requirement 6. The System shall be able to display HD 1080 interlaced scan content at 1,9201,080 resolution in wide-screen mode. 7. Requirement 7. The System shall be able to display HD 720 progressive scan content at 1,280720 resolution in wide-screen mode. 8. Requirement 8. The System shall be able to display Wide-screen 480 progressive scan content (from DVDs for example) at 852480 resolution in wide-screen mode. 9. Requirement 9. The System shall be able to display Regular Up to 480 line content. 10. Requirement 10. The System shall be connectable to a surround sound system. 11. Requirement 11. The System shall provide an output connection that can be connected to recording equipment, such as a HD-DVD recorder when such systems become available. 12. Requirement 12. The System shall be operable for a minimum of 10,000 hours before maintenance is required. 13. Requirement 13. The System shall be ready for market by the middle of 2020, when there will finally be some decent HD content available. 14. Requirement 14. The System shall abide by the constraints of the Digital Rights Management policies as placed upon it by the
Rakesh sherwal
00711604411
Sol:Use Case Diagram:-
1.
Review caller message
This use case is used to review the message left by caller Owner,Machine Owner reviews the messages
None The caller has left a message to be reviewed Message is reviewed
2.
Delete caller message
This use case is used to delete the message left by caller Owner,machine Caller selects a message Caller deletes the message None Message should be present none
Rakesh sherwal
00711604411
3.
Record greeting Brief Description Actors Flow of Events Alternative Flow Precondition Post condition This use case is user to record a greeting for the caller Owner , Machine Owner press the record button Owner records a greeting for caller None None The machine has a greeting message for caller
4.
Play greeting
Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 5. Set answer mode
This use case is used to play a greeting when a caller calls and the owner is unable to answer the call Caller, Machine Caller calls the owner Machine plays the message Caller calls the owner None None
Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 6. Take caller message
This use case is used to set the answering mode by owner owner, Machine Owner sets the answering mode
None None None
Brief Description Actors Flow of Events Alternative Flow
This sue case is used to record the callers message in the machine Caller, Machine Caller calls the owner. Owners provides a message to be recorded. Machine records the message None
Rakesh sherwal
00711604411
Precondition Post condition
None None.
Analysis model:-
Class diagram:-
Code generation:#ifndef ANSWER_MODE_H_HEADER_INCLUDED_B0857F86 #define ANSWER_MODE_H_HEADER_INCLUDED_B0857F86 //##ModelId=4F7AE1B70213 class answer mode { //##ModelId=4F7AE1C2009C
Rakesh sherwal
00711604411
string answer ring; }; #endif /* ANSWER_MODE_H_HEADER_INCLUDED_B0857F86 */#ifndef ANSWERING_MACHINE_H_HEADER_INCLUDED_B0854EA4 #define ANSWERING_MACHINE_H_HEADER_INCLUDED_B0854EA4 //##ModelId=4F7AE1CB000F class answering machine { }; #endif /* ANSWERING_MACHINE_H_HEADER_INCLUDED_B0854EA4 */ #ifndef CALLER_MESSAGE_H_HEADER_INCLUDED_B0854F00 #define CALLER_MESSAGE_H_HEADER_INCLUDED_B0854F00 //##ModelId=4F7AE20D00FA class caller message { //##ModelId=4F7AE302032C date date; //##ModelId=4F7AE30501D4 string caller; //##ModelId=4F7AE3080222 int reviewed; //##ModelId=4F7AE30F01F4 string message;
}; #endif /* CALLER_MESSAGE_H_HEADER_INCLUDED_B0854F00 */ #include "greeting.h" //##ModelId=4F7AE1F7006D greeting::play() { } #ifndef GREETING_H_HEADER_INCLUDED_B085664F #define GREETING_H_HEADER_INCLUDED_B085664F //##ModelId=4F7AE1E90232 class greeting { public: //##ModelId=4F7AE1F7006D play(); private: //##ModelId=4F7AE1EE01E4 string greeting; }; #endif /* GREETING_H_HEADER_INCLUDED_B085664F */
Rakesh sherwal
00711604411
#ifndef MESSAGE_BOX_H_HEADER_INCLUDED_B0851094 #define MESSAGE_BOX_H_HEADER_INCLUDED_B0851094 //##ModelId=4F7AE1D2008C class message box { //##ModelId=4F7AE1DD0251 int totalmsg; //##ModelId=4F7AE1E103A9 string newmsg; }; #endif /* MESSAGE_BOX_H_HEADER_INCLUDED_B0851094 */ #include "speaker.h" //##ModelId=4F7AE31F006D speaker::play() { } #ifndef SPEAKER_H_HEADER_INCLUDED_B0853B19 #define SPEAKER_H_HEADER_INCLUDED_B0853B19
//##ModelId=4F7AE318031C class speaker { public: //##ModelId=4F7AE31F006D play(); }; #endif /* SPEAKER_H_HEADER_INCLUDED_B0853B19 */ #ifndef PHONE_LINE_H_HEADER_INCLUDED_B0855727 #define PHONE_LINE_H_HEADER_INCLUDED_B0855727 //##ModelId=4F7AE1FD00CB class phone line { //##ModelId=4F7AE2030128 int ring count; }; #endif /* PHONE_LINE_H_HEADER_INCLUDED_B0855727 */
Q3) Draw a Use Case Diagram (write description of each use case), Activity Diagram and Sequence Diagram (for each usecase) for Hurrys Store Stock Control System.
Rakesh sherwal
00711604411
Hurry's require a new point of sale and stock control system for their many stores throughout the UK to replace their ageing mini based systems. A sales assistant will be able to process an order by entering product numbers and required quantities into the system. The system will display a description, price and available stock. In-stock products will normally be collected immediately by the customer from the store but may be selected for delivery to the customer's home address for which there will be a charge. If stock is not available the sales assistant will be able to create a backorder for the product from a regional warehouse. The products will then either be delivered direct from the regional warehouse to the customer's home address, or to the store for collection by the customer. The system will allow products to be paid for by cash or credit card. Credit card transactions will be validated via an online card transaction system. The system will produce a receipt. Order details for in-stock products will be printed in the warehouse including the bin reference, quantity, product number and description. These will be collected by the sales assistant and given to the customer. The sales assistant will be able to make refunds, provided a valid receipt is produced. The sales assistant will also be able to check stock and pricing without creating an order and progress orders that have been created for delivery. The store manager will be able at any time to print a summary report of sales in the store for a given period, including assignment of sales to sales assistants in order to calculate weekly sales bonuses. The stock manager will be able to monitor stock levels and weekly run-rates in order to set minimum stock levels and requisition products which fall below the minimum stock levels or for which demand is anticipated. When the stock arrives it will be booked in by the warehouse person. Stock that has been backordered for collection from the store is held in a separate area and the store manager advised of its arrival. The catalogue of available products will be maintained remotely by marketing from head office. Marketing will also be able to access sales information from each store system.
Sol.:- Use Case Diagram:-
Rakesh sherwal
00711604411
Display stock details System Make Receipt
Process an order Sales Assistant Check Status

<<extend>>
<<include>>
<<extend>>
Cash
Payment
<<extend>>
Make Refund Card Payment System Place BackOrder Customer
Assign Sales Store Manager Calculate Weekly Bonus Monitor Weekly Run Rates Print Sales Summary Report Marketing Catalog Maintenance Books Stock Access Sales Information Warehouse Person Stock Manager
<<extend>>
Monitor Stock Levels
Use Case Description 1. Display Stock Details Brief Description Actors Flow of Events Alternative Flow Precondition
Rakesh sherwal
The system displays info to Sales assistant System 1. Sales assistant enters the product numbers and required quantities into system. 2. System displays the description, price and available stock None Product numbers must be entered
00711604411
Post condition 2. Make Receipt Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
Information regarding product is displayed
The System generates receipt of the Order processed System As payment is made the receipt is generated None Payment must be made None
3. Process An Order
Rakesh sherwal
00711604411
The sales assistant initiates this use case. It processes the order. Sales Assistant, System 1. PROCESS AN ORDER The sales assistant processes the order by entering product numbers and required quantities into the system. 2. DISPLAY DETAILS The system displays the description, price and available stock. 3. DELIVER PRODUCT The product can be delivered to the customers home address or be collected by the customer immediately. The product is delivered immediately from the store. 4. MAKE PAYMENT Payments can be made by cash or credit card. Payments are made by cash. 5. PRINT RECEIPT The printer prints the receipt. Order details for in-stock products are printed including bin reference, quantity, product number & description. This receipt is collected by the sales assistant and given to the customer. 1. STOCK UNAVAILABLE This alternative flow step is initiated when the sales assistant initiates the basic flow step DELIVER PRODUCT. The stock is unavailable. So, the sales assistant creates a backorder for the product from a regional warehouse.
Flow of Events
Alternative Flow
2. DELIVER PRODUCT The product will be delivered either directly from the regional warehouse to the customers home address, or to the store for collection by the customer. The use case resumes at the basic flow MAKE PAYMENT. 3. HOME DELIVERY OF THE PRODUCT This alternative flow step is initiated in the basic flow step DELIVER PRODUCT. The customer opts for home delivery. The product is delivered to the customers home address for which extra charges are laid. It resumes at the basic flow step MAKE
Rakesh sherwal
00711604411
PAYMENT 4. PAYMENT BY CREDIT CARD This alternative step is initiated by MAKE PAYMENTS. The user makes the payment by credit card. Credit card is validated via online card transaction system. It resumes at PRINT RECEPT. 5. PAPER ROLL EMPTY This alternative step is initiated by the basic flow step PRINT RECEIPT. The paper roll is empty. The sales assistant puts the new roll and the basic step PRINT RECEIPT is resumed. Precondition Post condition 4. Check Status Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 5. Make Refunds Brief Description Actors Flow of Events The sales assistant makes the refunds to the customer by initiating this use case. Sales Assistant, Customer 1. The customer produces a valid receipt. 2. The refunds are made by the sales assistant. 3. The use case ends.
00711604411
None The order has been processed
The sales assistant will be able to check the status of the available stock. Sales Assistant The sales assistant check the status of the available stock. None None If stock is not available back order is placed.
Rakesh sherwal
Alternative Flow
Invalid Receipt 1. The customer doesnt produce a valid receipt. 2. He is asked for a valid receipt. If he is able to produce a valid receipt, the basic flow step REFUND is resumed. Otherwise the use case ends. Customer has made all the payments. Customer has got refunds.
Precondition Post condition 6. Place Backorder
The sales assistant places the backorder for goods which are not available in the store. Sales Assistant, Store manager 1. The sales assistant places the backorder for goods which are not available in the store. 2. The backorder is placed in the regional warehouse. 3. The use case ends. None None None
7. Calculate Weekly Bonus Brief Description Actors Flow of Events

Rakesh sherwal
The store manager calculates the weekly bonus. Store Manager The store manager calculates the weekly bonus for each sales assistant .
00711604411
Alternative Flow Precondition Post condition
None None None
8. Print Sales Summary Repor Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 9. Books Store Brief Description Actors Flow of Events Alternative Flow Precondition Post condition The store manager would be able to print summary reports by initiating this use case. Store Manager The store manager prints the summary report of sales in the store for a given period. These include assignment of sales to sales assistants as well. None None None
As the new stock level reduces this use case gets executed Warehouse person 1. For minimum stock levels demand is anticipated. 2. As the stock arrives its booked by the warehouse person None Stock levels to be minimum. Stock level is raised.
10. Catalogue Maintenance Brief Description

Rakesh sherwal
The catalogue of the available products is maintained.

00711604411
Actors Flow of Events Alternative Flow Precondition Post condition
Marketing The catalogue of available products is maintained remotely by marketing from head office. None None None
11.Access Sales Information Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
The marketing accesses the sales information. Marketing The Marketing accesses the sales information from each store system. None None None
12. Payment Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 13.Card payment
Rakesh sherwal 00711604411
It specifies the payment to be done. Sales Assistant The payment is included in process order and has two types cash and credit card. None None None
The credit/debit card is the mode of payment for the customer. Customer, Sales Assistant 1. The customer pays for the goods with credit card. 2. The card payment is verified using online transaction system. None None Payment Is Made
14.Cash Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
The cash is the mode of payment for the customer. Customer, Sales Assistant The customer pays for the goods with cash. None None Payment is made
15.Monitor Stock Levels Brief Description Actors Flow of Events The stock manager would monitor the stock levels by initiating this use case. Stock Manager 1. The stock manager will monitor stock levels and weekly run-rates. 2. He set minimum stock levels. 3. He sets requisite for the product that fall below the minimum stock levels or for which the demand is
00711604411
Rakesh sherwal
anticipated. Alternative Flow Precondition Post condition None None None
Sequence diagram:-
Rakesh sherwal
00711604411
System
Sales Assistant
Customer
Store Manager
Stock Manager
wareHouse Person
1: Enters Product Information
2: Display Product details 3: Makes Order 4: Process Order
5: Checks Status 6: Assign Sales 7: Calculate Weekly bonus 8: Monitor Stock levels 9: Books Stock 10: Makes Payment 11: Delivers Order
12: Generates receipt
13: Print Sales Summary
Q4) Identify the Use cases, elaborate every use case as far as necessary. Not everything is specified in these initial requirements. When you need make assumptions, put them explicitly in the document. Draw the Usecase Diagram, Class Diagram and Generate Code using Rational Rose. The drawing editor is an interactive graphics editor. With it, users can create and edit drawings composed of lines, rectangles, ellipses and text Tools control the mode of operation of the editor. Exactly one tool is active at any one time. Two kinds of tools exist: the selection tool and creation tools. When the selection tool is active, existing drawing elements can be selected with the cursor. One or more drawing elements can be selected and manipulated; if several drawing elements are selected, they can be manipulated as if they were a single element. Elements that have been selected in this way are referred to as the current selection. The current selection is indicated visually by displaying the control points for the element. Clicking on and dragging a control point modifies the element with which the control point is associated.
Rakesh sherwal
00711604411
When a creation tool is active, the current selection is empty. The cursor changes in different ways according to the specific creation tool, and the user can create an element of the selected kind. The text creation tool: the position of the first character of the text is determined by where the user clicks the mouse button. The creation tool is no longer active when the user clicks the mouse button outside the text element. The control points for a text element are at the four corners of the region within which the text is formatted. Dragging the control points changes this region. The other creation tools allow the creation of lines, rectangles and ellipses. The appropriate element starts to be created when the mouse button is pressed, and is completed when the mouse button is released. These two events create the start point and the stop point. The line creation tool creates a line from the start point to the stop point. These are the control points of a line. Dragging a control point changes the end point. The rectangle creation tool creates a rectangle such that these points are diagonally opposite corners. These points and the other corners are the control points. Dragging a control point changes the associated corner. The ellipse creation tool creates an ellipse fitting within the rectangle defined by the two points described above. The major radius is one half the width of the rectangle, and the minor radius is one half the height of the rectangle. The control points are at the corners of the bounding rectangle. Dragging a control point changes the associated corner. The specification states nothing about the environment in which the diagram editor will run. We will assume that the program should provide a graphical display of the diagram being created, and that a mouse and keyboard will be used as input devices. Sol.:Use case diagram:-
Use Case Description Rakesh sherwal 00711604411
1. Interface GUI Interface usecase provides interface to the user for interacting with Brief Description the editor. Actors Flow of Events User, Program 1. This usecase Starts when user first start the editor, then Program runs and provide interface to the user. Enough memory or resources is not available is available for the program to run. None Interface is active
Alternative Flow Precondition Post condition 2. Selection Tool
Select tool use case allows the user to select the different drawing Brief Description elements. Actors User 2. Select Element. The user points towards a drawing element and clicks the mouse. 3. Manipulate Element. The system shows the control point of the currently selected element. Multiple Selection At basic flow step CLICK AN ELEMENT, the user presses the multi-select modifier key. The system creates a current selection and adds the currently selected element, if any, to it. o ADD TO CURRENT SELECTION. The user clicks on elements to add elements to the current selection. o SHOW CONTROL POINTS. The user releases the multi-select modifier key; the system shows the control points for the current selection. The use case resumes at basic flow step MANIPULATE CONTROL POINTS.
Flow of Events
Alternative Flow
Rakesh sherwal
00711604411
None None
2. Manipulate elements Brief Description Allows the user to modify the current selection. Actors User 1. DRAG CONTROL POINTS. The user drags anyone of the control points associated with the current selection. 2. REDRAW CURRENT SELECTION. The current selection could consist of lines, rectangles, ellipses and text. Assuming that current selection consists of various drawing elements, each element is redrawn according to the dragged control point. None None None
Flow of Events
Alternative Flow Precondition Post condition 3. Creation Tool
Brief Description allows the user to create various drawing elements Actors User 1. Text tool At basic flow step REDRAW CURRENT SELECTION, the current selection only has a text element. For a text element, the system provides four control points at the four corners of the text region. 2. Line tool At basic flow step REDRAW CURRENT SELECTION, the current selection only has a line element. For a line element, the system provides two control points at the end points of the line. The use case ends. 3. Rectangle tool At basic flow step REDRAW CURRENT SELECTION, the current selection only has a rectangle element. For a rectangle element, the system provides four control points at Rakesh sherwal 00711604411
Flow of Events
the four corners of the rectangle. The system redraws the rectangle according to the dragged control points. The use case ends. 4. Ellipse tool At basic flow step REDRAW CURRENT SELECTION, the current selection only has an ellipse element. For an ellipse element, the system provides four control points at the four corners of the rectangle which fits the ellipse. The use case ends.
CREATE LINE ELEMENT
At basic flow step ACTIVATE CREATION TOOL, the user selects the Line Creation Tool. The system empties the current selection and changes the cursor to Line Creation cursor. o DEFINE THE START/STOP POINTS. The user defines the start and stop points by dragging from the start point to the stop point. o DRAW LINE. The system draws the line between the start point and the stop point. The use case ends.
CREATE RECTANGLE ELEMENT
Alternative Flow
At basic flow step ACTIVATE CREATION TOOL, the user selects the Rectangle Creation Tool. The system empties the current selection and changes the cursor to Rectangle Creation cursor. DEFINE THE END POINTS. The user defines the start and stop points by dragging from the start point to the stop point. DRAW RECTANGLE. The system draws the rectangle by using the start point and the stop point as diagonally opposite corners. The use case ends. CREATE ELLIPSE ELEMENT At basic flow step ACTIVATE CREATION TOOL, the user selects the Ellipse Creation Tool. The system empties the current selection and changes the cursor to Ellipse Creation cursor. DEFINE THE END POINTS. The user defines the start and stop points by dragging from the start point to the stop point. DRAW LINE. 00711604411
Rakesh sherwal
The system draws the ellipse by using the start point and the stop point as the diagonally opposite corners of a rectangle which encloses the ellipse. Precondition Post condition The use case ends.
None None
Class Diagram(Drwaing Tool)
CODE
USER
<user.h>
#ifndef USER_H_HEADER_INCLUDED_AE9676CC #define USER_H_HEADER_INCLUDED_AE9676CC //##ModelId=51121CE6039D class User { public: //##ModelId=5169865A004E Create element(); //##ModelId=516986660043 Select element(); Rakesh sherwal 00711604411
//##ModelId=5169866D0283 manipulate element(); //##ModelId=5169867403D3 redraw element(); private: //##ModelId=51121FDC0380 int UserID; }; #endif /* USER_H_HEADER_INCLUDED_AE9676CC */
<user.cpp> #include "User.h" //##ModelId=5169865A004E User::Create element() { } //##ModelId=516986660043 User::Select element() { } //##ModelId=5169866D0283 User::manipulate element() { } //##ModelId=5169867403D3 User::redraw element() { } TOOL <tool.h> #ifndef TOOL_H_HEADER_INCLUDED_AE9669C0 #define TOOL_H_HEADER_INCLUDED_AE9669C0 //##ModelId=5112201E01BF
class Tool { public: //##ModelId=511220D60379 GetID(); //##ModelId=511220DB03E2 GetName(); //##ModelId=511222C902E1 SelectMultiple(); //##ModelId=511222DD004C ModifyTool(); //##ModelId=5112231E0081 LineTool(); //##ModelId=51122394030F Rectangle Tool(); //##ModelId=5112239C0031 EllipseTool(); //##ModelId=511223A2033D opname(); private: //##ModelId=511220970309 int ToolID; //##ModelId=5112209D006C char ToolName; }; #endif /* TOOL_H_HEADER_INCLUDED_AE9669C0 */ <tool.cpp> #include "Tool.h" //##ModelId=511220D60379 Tool::GetID()
{ } //##ModelId=511220DB03E2 Tool::GetName() { } //##ModelId=511222C902E1 Tool::SelectMultiple() { } //##ModelId=511222DD004C Tool::ModifyTool() { } //##ModelId=5112231E0081 Tool::LineTool() { } //##ModelId=51122394030F Tool::Rectangle Tool() { } //##ModelId=5112239C0031 Tool::EllipseTool() { } //##ModelId=511223A2033D Tool::opname() { }
Drawing Editor
<drawingeditor.h> #ifndef DRAWINGEDITOR_H_HEADER_INCLUDED_AE964103 #define DRAWINGEDITOR_H_HEADER_INCLUDED_AE964103
//##ModelId=511221F402D5 class program { public: //##ModelId=51122234028A GetWidth(); //##ModelId=511222400119 GetHeight(); private: //##ModelId=5112220B02D9 int width; //##ModelId=511222140142 int height; }; #endif /* DRAWINGEDITOR_H_HEADER_INCLUDED_AE964103 */ <drawingEditor.cpp> #include "DrawingEditor.h" //##ModelId=51122234028A program::GetWidth() { } //##ModelId=511222400119 program::GetHeight() { } Q5) Draw Usecase Diagram, Activity Diagram, Analysis Model and write usecase description for the Survey Management System. Draw the Class Diagram and Generate Code for the same. A Survey Institution that performs/manages public surveys. After the raw survey data is collected, a senior staff adds a survey header into the database; senior or junior staff add questions into the survey, may categorize questions, or add a question category. Questions with sensitive content are restricted to senior staff
Sol.:-
Use case Diagram:-
restricted section
<<include>>
senior staff
print add question

<<include>>
add survey
<<extend>>
add category junior staff
person
add db
Use Case Description 1. Add Question Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 2. Add Survey Brief Description Actors Flow of
Rakesh sherwal
The staff adds questions to survey sheet. Senior staff, junior staff 1. After raw data is collected senior staff adds header to database 2. Then the questions are added to survey by the actors None Raw data needs to be collected None
Survey is done on person is created and added by senior staff Senior staff, Person Senior staff performs survey on person and then adds it
00711604411
Events Alternative Flow Precondition Post condition 3. Add Category Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 4. Add DB Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
None None None
The Questions in survey are categorized Senior staff, Junior staff Questions added to survey are categorized None Questions must be added to survey None
The senior staff adds Header to DB as raw data is collected Senior staff, Junior staff Raw data is collected from surveys and then Header is added to the DB by senior staff None Raw data must be collected None
5. Restricted Question Brief Description Actors Flow of Events

Rakesh sherwal
If any sensitive content is found than it is restricted to senior staff Senior staff As soon as any sensitive data is found it is restricted to senior staff
00711604411
Alternative Flow Precondition Post condition Class Diagram:-
None Content has to be sensitive None
Staff
AddQuestion() AddCategory() Print()
JuniorStaff SeniorStaff
RestrictQuestion() AddQuestion() AddHeader() AddSurv ey() 1 AddCategory() AddQuestion()
surveys
*
Person
Add Surv ey()
Code: #include "JuniorStaff.h" //##ModelId=4F7AAA7500F6 JuniorStaff::RestrictQuestion() { } //##ModelId=4F7AAA87038A JuniorStaff::AddQuestion() { } //##ModelId=4F7AAABB0222 JuniorStaff::AddHeader() { } //##ModelId=4F7AAAF70006 JuniorStaff::AddSurvey() {
} #include "Person.h" //##ModelId=4F7AAB0500B0 Person::Add Survey() { } #include "SeniorStaff.h" //##ModelId=4F7AAACA0272 SeniorStaff::AddCategory() { } //##ModelId=4F7AABBC0132 SeniorStaff::AddQuestion() { } #include "Staff.h" //##ModelId=4F7AAA8D00C4 Staff::AddQuestion() { } //##ModelId=4F7AAAC20178 Staff::AddCategory() { } //##ModelId=4F7AAB210380 Staff::Print() { }
Rakesh sherwal
00711604411
Activity diagram:Staff Person
Adds Survey header to database
Add Questions To Survey
Add Question Category yes
Category Exists
Categorize Questions
Sensitive content Restricted To Senior Staff
Prepares Final survey
Takes up survey
Q6) Draw Usecase Diagram, Analysis Model, Class Diagram and Generate Code for Health Care Center. Write usecase description for each usecase Patient Can arrange and cancel appointment with physician using scheduler. Physician decides to Prescribe Medication for Patient. Physician Specifies Drug Info: Medication Name, Dosage Amount, Number Doses & Refills. Computer Cross-Checks for Conflict Between Medication and Current Medications/Medical History Prescription Forwarded Electronically to Pharmacy or Else Printed for Patient.
Rakesh sherwal
00711604411
Sol.:
Arrange Appointment
Patient
Scheduler Cancel Appointment
Prescribe Medication Medical History

<<include>> <<include>> <<include>>
Physician
Print Medication
<<extend>>
Specifies Drug Info
Computer
Cross Check For Conflict

<<extend>>
Forward To Pharmacy
1. Arrange Appointment Brief Description Actors Flow of Events Alternative Flow Precondition Post condition Patient arranges appointment with Physician using Scheduler Patient, Physician Patient arranges appointment with physician using scheduler None None Appointment is made
2. Cancel Appointment Brief

Rakesh sherwal
Patient cancels appointment with Physician using Scheduler

00711604411
Description Actors Flow of Events Alternative Flow Precondition Post condition 3. Medical History Brief Description Actors Flow of Events Alternative Flow Precondition Post condition Patient, Physician Patient cancels appointment with physician using scheduler None None Appointment is cancelled
Physician checks medical History to Prescribe Medication Patient, physician Physician checks patients Medical History to prescribe Medication Medication is not prescribed None Prescribe medication
4. Print Medication Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 5. Scheduler
Final Medication is Printed Patient,computer As Cross-Checks for Conflict Between Medication and Current Medications/Medical History Prescription Forwarded Electronically to Pharmacy or Else Printed for Patient . Medication is not printed Cross-checks for conflict between medication and current medications/Medical History prescription None
Arranges and cancels appointment Patient, Physician 1. If patient asks for an appointment and scheduler arranges it with physician when he/she is free. 2. If patient asks for that scheduler cancels his/her appointment None None None
6. Cross check for conflict Brief Description Actors Flow of Events Alternative Flow Precondition Post condition Computer checks the Medication and Current Medication/Medical history prescription. Computer Computer Cross-Checks for Conflict Between Medication and Current Medications/Medical History Prescription Forwarded Electronically to Pharmacy or Else Printed for Patient. None None Forward to pharmacy
7. Forward to pharmacy Brief Description Actors Flow of Events Alternative Flow Precondition
Rakesh sherwal
If cross-check performed by computer results is positive than this use is executed. Computer If cross-check performed by computer results is positive than patient is forwarded to pharmacy. None None
00711604411
Post condition
Medication is provided
Analysis Model:cancel
arranage patient
patient interface
make appointment physician interface physician
drug info dosage amount prescribe madication
history medication
madication name
computer computer interface
cross check for conflict forward to pharmacy
print
Class diagram:-
Rakesh sherwal
00711604411
patient patient id address name disease 1..* arrange() cancel() schedule() madication history() 1..* 1..* 1 scheduler day time type id arrange() cancel() schedule()
physician id name name designation 1 schedule() prescribe() drug info() 1..*
computer id department cross check() print() froward()
1..* pharmacy id name addrass timing 1..* give medicine() drug info()
Code generation:#include "Computer.h" //##ModelId=4F7ACECA0126 Computer::CheckConflicts() { } //##ModelId=4F7ACED300D6 Computer::ForwardToPharmacy() { } //##ModelId=4F7ACEE1013A Computer::PrintMedication() { } #include "Pateint.h" //##ModelId=4F7ACE5D0112 Pateint::MedicalHistory() { }
//##ModelId=4F7ACE6600CC Pateint::GetData() { } //##ModelId=4F7ACE790112 Pateint::SetData() { } //##ModelId=4F7ACE7C01F8 Pateint::GetAppointment() { } #include "Physician.h" //##ModelId=4F7ACE070036 Physician::GetData() { } //##ModelId=4F7ACE0E0086 Physician::SetData() { } //##ModelId=4F7ACE1503CE Physician::PrescribeMedication() { } #include "Scheduler.h" //##ModelId=4F7ACE910036 Scheduler::ArrangeAppointment() { } //##ModelId=4F7ACE9803B0
Scheduler::CancelAppointment() { }
Q7) Draw Usecase Diagram, Activity Diagram and Sequence Diagram (for each usecase) for Movie Ticket Machine problem given below. Write description of each usecase. Implement a simple movie ticket vending machine. The movie theater that will use the machine has only one movie and one show time each day. Every morning, the theater manager will turn on the ticket machine, and it will ask him for the name of the movie and the ticket price that day. It will also ask how many seats are in the theater (so it won't sell too many tickets). When a customer walks up to the ticket machine, he will see the name of the movie, the time, and the ticket price displayed. There is a slot to insert money, a keypad of buttons to enter a number into the "Number of Tickets" field, and a "Buy" button. Printed tickets come out of a slot at the bottom of the machine. Above the ticket slot is a message display (for error messages like "Please enter more money or request fewer tickets" or "SOLD OUT!"). An additional display shows the customer's balance inside the machine. Finally, there is a "Return Change" button so the customer can get his unspent money back. The ticket machine might look something like this:
Sol:Activity diagram:Rakesh sherwal 00711604411
M anage r
Customer
M a c hi ne
Turn On
Add D etails
Buy Ticket
Print Ticket
Display
Return Change
Sequence diagram:Manager Machine Customer
1: Turn On 2: Add Details 3: Display 4: Buy Ticket
5: Return Change
Rakesh sherwal
00711604411
Use Case Description 1. Turn On Brief Description Actors Flow of Events Alternative Flow Precondition Post condition This use case would be used by theatre manager everyday in order to turn on the machine Manager, Machine Theatre manager turns on the machine. None None The machine is ready for adding details. 2. Add Details Brief Description
Rakesh sherwal
This use case would be used by theatre manager every day in order to enter the movie details
00711604411
Actors
Manager, Machine 1. The machine asks him for the name of the movie and the ticket price that day. 2. It also asks for the no of seats in the theatre. 3. Theatre manager enters the name of the movie, the price of the ticket on that day and the number of seats in the theater. None Turn on machine The machine is ready for issuing tickets.
Flow of Events
2. Buy Ticket Brief Description Actors This use case would be used by the customer to buy the movie ticket Customer 1. CHECK INFORMATION The displayed information on the machine is read by the customer. The information includes the name of the movie, the time and the ticket price. 2. ENTER INFORMATION The customer enters the number of tickets he wants to buy in the Number of Tickets field. 3. MAKE PAYMENTS The customer deposits the amount in the respective slot. The system counts the money deposited and updates the balance amount field. 4. PRESS BUY BUTTON The customer presses the Buy button. The machine dispenses the printed tickets which are collected by the customer. 1. Insufficient money This step is initiated at the basic step PRESS BUY
00711604411
Flow of Events
Alternative Flow
Rakesh sherwal
BUTTON. The system displays the message Please enter more money. The user enters the required amount. This step resumes at the basic step MAKE PAYMENTS 2. Request fewer tickets This step is initiated at the basic step PRESS BUY BUTTON. The system displays the message Request fewer tickets. It resumes at ENTER INFORMATION 3. Sold out This step is initiated at the basic step PRESS BUY BUTTON. The system displays the message Sold Out. The use case ends. Precondition Post condition Updated details in machine Update Machine
4. Display
Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 5. Return Change
Rakesh sherwal
This use case would be used by machine to display the details to the customer Machine 1. 2. Customer walks up See the name of the movie, the time and the ticket price displayed
None Add details by Manager None
00711604411
Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 6. Print Ticket Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
Customer initiates this use case to collect the money unspent by him. Machine, Customer PRESS RETURN CHANGE BUTTON The customer presses the RETURN CHANGE button. The machine dispenses out the balance amount. None Some balance amount is left None
This use case is included with the BUY TICKET use case to print the ticket. Customer, Machine (Secondary Actor) Customer buys the ticket and takes its print. None Buy Ticket None
Q8) Draw Usecase Diagram and Analysis Model for Movie Ticket Machine problem given below. Write description of each usecase. Draw the Class Diagram and Generate Code for the same. Implement a simple movie ticket vending machine. The movie theater that will use the machine has only one movie and one show time each day. Every morning, the theater manager will turn on the ticket machine, and it will ask him for the name of the movie and the ticket price that day. It will also ask how many seats are in the theater (so it won't sell too many tickets). When a customer walks up to the ticket machine, he will see the name of the movie, the time, and the ticket price displayed. There is a slot to insert money, a keypad of buttons to enter a number into the "Number of Tickets" field, and a "Buy" button. Printed tickets come out of a slot at the bottom of the machine. Above the ticket slot is a message display (for error messages like "Please enter
more money or request fewer tickets" or "SOLD OUT!"). An additional display shows the customer's balance inside the machine. Finally, there is a "Return Change" button so the customer can get his unspent money back. The ticket machine might look something like this:
Sol.:Class diagram:-
Rakesh sherwal
00711604411
Analysis model:-
money slot
manager
manager interface
movie ticket machine
ticket slot customer
printer movie print
Class Diagram
Manager
Name : String Turn_On() Add_Details() 1
Operates
1
Machine
Dispaly() Return_Change() 1 *
Customer
Name Phone Buy_Ticket()
Code: For customer class: #include "Customer.h" //##ModelId=4F7830DE037D Customer::Buy_Ticket() { } For machine class: #include "Machine.h" //##ModelId=4F7830BA02AB Machine::Dispaly() { } //##ModelId=4F7830BE0175 Machine::Return_Change() { } For manager class: #include "Manager.h" //##ModelId=4F78308A00FD Manager::Turn_On() { } //##ModelId=4F783091016B Manager::Add_Details() { } Q9) Consider a Computer Email System I. Identify actors for email system. Explain the relevance of each actor II. One use case is to get email. List four additional use cases at a comparable level of abstraction. Describe each use case with exceptional flow.
III. Prepare a Usecase Diagram for a computer email system. Write Description
for each use case IV. Draw Class Diagram and Generate Code. V. Identify at least four states for an email object and draw the State Transition Diagram for the same. Sol.:
Use Case Description 1. Login Brief Description Actors Flow of Events Alternative Flow Precondition
Rakesh sherwal
This use case describes how a user login to the Email System Sender, Receiver 1. Enter user id 2. Enter password 3. Login None Sender/Receiver must have an account
00711604411
Post condition 2. Send Email Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 3. Get Email Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
If the use case was successful the actor is logged in to the system. If not, the system state is unchanged.
This use case enables the sender to send an email Sender 1. Log in 2. Write mail 3. Send mail None Sender must log in Save sent mail
This use case enables the receiver to receive the email Receiver 1. Log in 2. Check email 3. Receive mail None 1. Receiver must login 2. Sender must send mail Save mail/ Delete mail/ Reply
4. Add Contacts
Rakesh sherwal
00711604411
Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 5. LogOut Brief Description Actors Flow of Events Alternative Flow Precondition Post condition 6. Print Brief Description Actors Flow of Events Alternative Flow
Rakesh sherwal
This use case enables the receiver/sender to add new contacts Receiver, Sender 1. Log in 2. Add Name 3. Add email id If contact already exist, modify Login Save contact
This use case enables the receiver/sender log out from the system after use Receiver, Sender 1. Log in 2. Add contact/ send/receive email 3. Log out None Login Close system
Use case extended by Get Email, used to print the mail Receiver 1. Log in 2. Get mail 3. Print mail None
00711604411
Get mail None
Class Diagram of Computer Email System

Sender
Name : String ID : String Password : String LogIn() LogOut() SendMail() AddContacts() *
Receiver Sends Mail

* Name ID Password LogIn() LogOut() ReceiveMail() AddContacts()
Email
Subject : String Time : String ComposingDate : Date Sender : String Receiver : String
Code: For sender class: #include "Sender.h" //##ModelId=4F78328501ED Sender::LogIn() { } //##ModelId=4F78328900DF Sender::LogOut() { } //##ModelId=4F78328C01F7 Sender::SendMail() { } //##ModelId=4F783292023D Sender::AddContacts()
{ } For receiver class: #include "Receiver.h" //##ModelId=4F7832E60175 Receiver::LogIn() { } //##ModelId=4F7832EA003F Receiver::LogOut() { } //##ModelId=4F7832ED0319 Receiver::ReceiveMail() { } //##ModelId=4F7832F3000D Receiver::AddContacts() { } For email class: #include "Email.h"
State Diagram of Computer Email System

Add Contacts LogIn Send Email Logout
Get Email
Rakesh sherwal
00711604411
Q10) Consider a software system for supporting a Public Library I. Identify actors for Library System. Explain the relevance of each actor. II. One use case is to boroow a library item. .List three additional use cases at a comparable level of abstraction. Describe each use case with exceptional flow. III. Prepare a Usecase Diagram for a library system. Describe each use case with exceptional flow. IV. Elaborate Library Item as an abstract class with concrete classes class . Generate the code for the same using forward engineering in Rational Rose. V. Identify at least four states of Library item and draw the State Transition Diagram for the same. Sol.:
Use case description:1 Use Case Use Case Name Objective Actors Pre-Conditions
Rakesh sherwal
Login This will allow users to login the system Operator and Librarian All users must have user name and password created for
00711604411
them in the system prior to use case Post-conditions If use case got successful then users are logged on to the system else system state is unchanged Flow of Events This use case starts when the actor wishes to login 1. The system requests that the actors enter their username, password 2. The actors enter their username, password 3. The system validates the entered username, password and logs actor into the system. Alternative If in the basic flow, the actor enters an invalid name, Flow password the system displays an error message. The actor can choose to either return to the beginning of the basic flow or cancel the login, at which point the use case ends
Use Case Use Case Name Objective Actors Pre-Conditions
2 Maintain Student Detail This will allow maintenance regarding students Operator This use case allows to maintain student personal information. This includes adding, updating and deleting passenger information from the system, Post-conditions If use case got successful then student information maintained without any ambiguity Flow of Events This use case starts when the student wishes to use library facility Here while all student activities are tracked. Alternative Flow None
3 Issue Book To issue book to user Operator and bar code reader Book must be available and student record should met the rules to be followed Post-conditions If everything goes right book is issued to the student else book is not issued
Flow of Events
This use case starts when the student wishes have a book then operator maintains record for it and with help of bar code reader issues it to the user Book is not issued
Alternative Flow Use Case Use Case Name Objective Actors Pre-Conditions Post-conditions Flow of Events
4 Return Book This will allow student to return book back to the library Operator and bar code reader Student must have the book to be returned Book is returned to the library This use case starts when the student wishes return a book then operator maintains record for it and with help of bar code reader do the operation. And imposes penalty if required None
Alternative Flow
Use Case Use Case Name Objective Actors Pre-Conditions Post-conditions Flow of Events
5 Maintain catalogue This will allow all the activities in the library to be logged Operator None Every activity is logged This use case starts when anything(book issue\return ,report generation, login etc) happens None
Alternative Flow
Use Case 6 Use Case Name Query Book

Objective
This will allow student to query about book from the library Actors Operator and User Pre-Conditions None Post-conditions Information regarding book is provided if it is available else error message is generated Flow of Events Basic details regarding the book to be queried is provided to the system and then database is looked for the details and if not found then error message is generated Alternative Flow None
7 Generate report Report generation Librarian None Report is formed This use case starts when the one wishes to look for the details which can be specific to student, a particular day fo particular item etc None
Alternative Flow
Class Diagram:Rakesh sherwal 00711604411
Code: #include "Admin.h" //##ModelId=4F7A74800186 Admin::Manages Library() { } #ifndef ADMIN_H_HEADER_INCLUDED_B08516B5 #define ADMIN_H_HEADER_INCLUDED_B08516B5 //##ModelId=4F7A747201D4 class Admin { public: //##ModelId=4F7A74800186 Manages Library(); private: //##ModelId=4F7A7477002E
ID; //##ModelId=4F7A747A0280 Name; }; #endif /* ADMIN_H_HEADER_INCLUDED_B08516B5 */ #ifndef ARTICLES_H_HEADER_INCLUDED_B085108E #define ARTICLES_H_HEADER_INCLUDED_B085108E //##ModelId=4F7A75040119 class articles : public Item { }; #endif /* ARTICLES_H_HEADER_INCLUDED_B085108E */ #ifndef BOOKS_H_HEADER_INCLUDED_B0854E36 #define BOOKS_H_HEADER_INCLUDED_B0854E36 //##ModelId=4F7A74FF0242 class books : public Item { }; #endif /* BOOKS_H_HEADER_INCLUDED_B0854E36 */ #ifndef FACULTY_H_HEADER_INCLUDED_B0851E4D #define FACULTY_H_HEADER_INCLUDED_B0851E4D //##ModelId=4F7A7583037A class faculty : public Lib_user { }; #endif /* FACULTY_H_HEADER_INCLUDED_B0851E4D */ #ifndef ITEM_H_HEADER_INCLUDED_B0851A6E #define ITEM_H_HEADER_INCLUDED_B0851A6E //##ModelId=4F7A74E400FA class Item { //##ModelId=4F7A74E90203 ID; //##ModelId=4F7A74F00222 Title; //##ModelId=4F7A74F40280 Author; }; #endif /* ITEM_H_HEADER_INCLUDED_B0851A6E */ #include "Lib_user.h"
//##ModelId=4F7A7534009C Lib_user::take books() { } //##ModelId=4F7A753A0167 Lib_user::payfine() { } //##ModelId=4F7A753D001F Lib_user::returnbook() { } #ifndef LIB_USER_H_HEADER_INCLUDED_B0856AD8 #define LIB_USER_H_HEADER_INCLUDED_B0856AD8 //##ModelId=4F7A750D032C class Lib_user { public: //##ModelId=4F7A7534009C take books(); //##ModelId=4F7A753A0167 payfine(); //##ModelId=4F7A753D001F returnbook(); private: //##ModelId=4F7A7526005D ID; //##ModelId=4F7A75290128 Name; }; #endif /* LIB_USER_H_HEADER_INCLUDED_B0856AD8 */ #include "Librarian.h" //##ModelId=4F7A74C003A9 Librarian::Issuebooks() { } //##ModelId=4F7A74C9037A Librarian::renewal() { } //##ModelId=4F7A74CF0167
Librarian::collectfine() { } //##ModelId=4F7A74D9003E Librarian::collect books() { } #ifndef LIBRARIAN_H_HEADER_INCLUDED_B0855943 #define LIBRARIAN_H_HEADER_INCLUDED_B0855943 //##ModelId=4F7A749100EA class Librarian { public: //##ModelId=4F7A74C003A9 Issuebooks(); //##ModelId=4F7A74C9037A renewal(); //##ModelId=4F7A74CF0167 collectfine(); //##ModelId=4F7A74D9003E collect books(); private: //##ModelId=4F7A74AD00AB ID; //##ModelId=4F7A74B1004E Name; }; #endif /* LIBRARIAN_H_HEADER_INCLUDED_B0855943 */ #include "Library.h" //##ModelId=4F7A745500DA Library::Issue code() { } //##ModelId=4F7A7459037A Library::Main books() { } //##ModelId=4F7A746203B9 Library::Details() { } #ifndef LIBRARY_H_HEADER_INCLUDED_B0851458
#define LIBRARY_H_HEADER_INCLUDED_B0851458 //##ModelId=4F7A7432038A class Library { public: //##ModelId=4F7A745500DA Issue code(); //##ModelId=4F7A7459037A Main books(); //##ModelId=4F7A746203B9 Details(); private: //##ModelId=4F7A743D033C Name; //##ModelId=4F7A744602EE Location; }; #endif /* LIBRARY_H_HEADER_INCLUDED_B0851458 */ #include "operation.h" //##ModelId=4F7A756400EA operation::issue() { } //##ModelId=4F7A756600FA operation::renewal() { } //##ModelId=4F7A756A00BB operation::return() { } //##ModelId=4F7A756C004E operation::fine() { } #ifndef OPERATION_H_HEADER_INCLUDED_B085323E #define OPERATION_H_HEADER_INCLUDED_B085323E //##ModelId=4F7A755500CB class operation { public: //##ModelId=4F7A756400EA issue();
//##ModelId=4F7A756600FA renewal(); //##ModelId=4F7A756A00BB return(); //##ModelId=4F7A756C004E fine(); private: //##ModelId=4F7A755A03D8 book id; }; #endif /* OPERATION_H_HEADER_INCLUDED_B085323E */ #ifndef STUDENT_H_HEADER_INCLUDED_B0851C73 #define STUDENT_H_HEADER_INCLUDED_B0851C73 #include "Lib_user.h" //##ModelId=4F7A75C40109 class Student : public Lib_user { }; #endif /* STUDENT_H_HEADER_INCLUDED_B0851C73 */
State transition diagram:-
Q11) Following requirements are for a product purchase system:

The administrator runs inventory reports. Every time inventory reports are
run, inventory data is loaded from disk. The administrator updates the inventory stock. Every time inventory stock is updated, inventory data is loaded from disk. Also, every time inventory stock is updated, inventory data is saved to a disk. A (general) make-a-sale (hint: meant to be a verb-noun phrase) can be of two specialized kinds: (1) make-a phone order sale; and (2) make-a walkin sale. A sales clerk records the make-a-walk-in sales. A telephone operator, a specialized kind of a sales clerk, handles and records all make-a phone orders. Whenever there is a make-a-sale, the inventory stock is updated. A sale may need to verify a credit card if the purchase is a credit card purchase. A sale may need to verify a check if the purchase is a check purchase.
Draw Use Case Diagram, including all actors, Use Cases, and relationships. Be sure to use the correct notation for all actors, Use Cases, and relationships. Also be sure to label each and every actor, Use Case, and relationship. Draw Analysis Model, Class Diagram and Generate Code. Write description of each usecase. Sol :-
Use case disription:Use Case 1 Use Case Name Run Inventory Report Objective This is done for getting information about the available inventory
Actors Administrator Pre-Conditions Inventory information mus be available on the disk Post-conditions Inventory report is provided to the the concerned actor Flow of Events This use case starts when the administrator wishes to get the inventory report, this initiates the work of loading information from the disk and then report is generated None
Alternative Flow
2 Update This is done for updating information regarding inventory Administrator Inventory information mus be available on the disk to be updated Post-conditions Updation is done successfully Flow of Events This use case starts when the administrator wishes to update the inventory report, this initiates the work of loading information from the disk and then saving it again on the disk after making changes to it None
Alternative Flow
3 Loads This is done for getting data from the disk None Data must be available in the disk Data is loaded from the disk This use case starts when the one wishes to have the inventory information, this initiates the work of loading information from the disk None
00711604411
Alternative
Rakesh sherwal
Flow
Use Case 4 Use Case Name save Objective This is done for saving information about the available inventory Actors None Pre-Conditions None Post-conditions Inventory information is saved on the disk Flow of Events This use case starts when one wishes to save the inventory information , this initiates by making changes to preloaded data and saving it back to the disk None
Alternative Flow
Use Case 5 Use Case Name Make a sale Objective This comes into picture when there is sale for some product Actors Administrator Pre-Conditions Product must be available for the sale Post-conditions Product is sold and regarding changes are reflected to the data on the disk Flow of Events This use case starts when the one wishes to sell a product , when this happens use case update does the work for making changes after selling the product Alternative Flow None
Use Case 6 Use Case Name Make phone order sale Objective This is done for selling product by taking order on the
phone Actors Telephone Operator Pre-Conditions Product must be available for the sale Post-conditions Product is sold and regarding changes are reflected to the data on the disk Flow of Events This use case starts when the one wishes to sell a product , when this happens use case update does the work for making changes after selling the product Alternative Flow None
7 Make walkin sale This is done for selling product Sales Clerk Product must be available for the sale Product is sold and regarding changes are reflected to the data on the disk This use case starts when the one wishes to sell a product , when this happens use case update does the work for making changes after selling the product None
Alternative Flow
8 Purchase This is used when some product is purchased Administrator Product must be available for the purchase If payment made successfully product is purchased else not This use case starts when the one wishes to purchase a product , when this happens payment is asked for and if everything went on successfully then product is purchased Product is not purchased
00711604411
Alternative
Rakesh sherwal
Flow
9 Credit card this is used when chosen mode of payment is credit card None Credit card must be available with the purchaser Payment done via credit card This use case starts when the one wishes to pay by credit card if all the rules are followed then payment is done Payment not done
Alternative Flow
10 Cheque Purchase this is used when chosen mode of payment is cheque None Cheque must be available with the purchaser Payment done via cheque This use case starts when the one wishes to pay by cheque if all the rules are followed then payment is done Payment not done
Alternative Flow
Use Case 11 Use Case Name Verifies Objective this is used when either payment mode is to be verified against the predefined norms Actors None Pre-Conditions None
Post-conditions Conditions are checked for and status is returned to parent use-case Flow of Events This use case starts when the one wishes verify the payment mode against predefined norms. Checks them and returns the status Alternative Flow None
Activity diagram:-
Sequence diagram:-
Rakesh sherwal
00711604411
Q 12) Consider an Online Airline Reservation System. You may want to check airline web sites to give you idea. I. Identify actors for Online Airline Reservation System. Explain the relevance of each actor. II. One use case is to make a Flight Reservation. List four additional use cases at a comparable level of abstraction. Describe each use case with exceptional flow. III. Prepare a Usecase Diagram for an online airline reservation system. Write Usecase description of each usecase. IV. Draw Class Diagram. Elaborate ticket class and Generate Code for the same. V. Identify at least four states of Ticket object and draw the State Transition Diagram for the same. Sol.:Rakesh sherwal 00711604411
LogIn
Maintain Flight Details
Passenger
View Flight Details
Reservation Clerk
Reserve Ticket
Cancel Ticket
Generate Report
<<include>>
Print
Use Case Description 1. LogIn Brief Description Actors This use case describes how a user logs into the Airlines Booking System. Reservation Clerk This use case starts when the actor wishes to login to the airlines booking system. 1. The system requests that the actors enter their username, password, and role. The role can be anyone of the administrator, clerk, travel agent or passenger. 2. The actors enter their username, password and role. 3. The system validates the entered username, password, role and logs actor into the system. Alternative Flow If in the basic flow, the actor enters an invalid name, password or role, the system displays an error message. The actor can choose to either return to the beginning of the
00711604411
Flow of Events
Rakesh sherwal
basic flow or cancel the login, at which point the use case ends. User must have a username, password, and role, created for them in the system, prior to the use case. If the use case was successful the actor is logged into the system. If not, the system state is unchanged.
2. Maintain Flight Details This use case allows the clerk to maintain flight information. This includes adding and updating flight information. Reservation Clerk This use case starts when the clerk add or changes the flight information. The system asks for the flight number and airlines of the flight which is to be added or changed. a. If the given flight number is of a new flight then Add New Flight sub-flow is executed. b. If the given flight number is of an existing flight then Change existing Flight sub-flow is executed. If in update sub-flow, the clerk decides not to update information, the update is cancelled and the basic flow is restarted at the beginning. The clerk must log into the system (authorized login) before this use case begins. If the use case was successful, the flight information is added or updated from the system. Otherwise, the system state is unchanged.
Flow of Events
3. View Flight Details Brief Description Actors Flow of Events

Rakesh sherwal
This use case allows the passenger to view flight information. Passenger This use case starts when the passenger wants to book the tickets and he views all the flight details before booking.
00711604411
Alternative Flow Precondition Post condition 4. Reserve Ticket Brief Description Actors
None Maintain Flight details by the clerk Book required flight ticket.
This use case allows the passenger to reserve or book the flight ticket Passenger This use case starts when the passenger wants to book the tickets. 1. Enters name 2. Enters Flight name 3. No. of passengers 4. Date of travel If no seats available, booking cancelled View Flight details Booking successful
Flow of Events
Alternative Flow Precondition Post condition 5. Cancel Ticket Brief Description Actors Flow of Events Alternative Flow Precondition
Rakesh sherwal
This use case allows the passenger to cancel the booked tickets. Passenger This use case starts when the passenger wants to cancel the tickets. 1. Enters details 2. Cancel If date and time of cancelling passed, cancelling no allowed Ticket booked
00711604411
Post condition 6. Generate Report Brief Description Actors
Refund money
This use case allows the clerk to generate report of flight and passenger details. Reservation Clerk This use case starts when the clerk want to generate reports of the flights 1. Enter flight details 2. Enter passenger details 3. Maintain records None Updated System Print reports
Flow of Events Alternative Flow Precondition Post condition 7. Print Brief Description Actors Flow of Events Alternative Flow Precondition Post condition
This use case is included with the GENERATE REPORT use case to print the ticket. Reservation Clerk Clerk generates report and takes its print if required. None Generate Report None
Rakesh sherwal
00711604411
Class Diagram :Passenger

Name : String Age : Integer Phone : Integer Address : String 1 Reserve Ticket() Cancel Ticket() View Details() *
Reservation Clerk Deals With

* Name : String ID : String Pwd : String AddDetails() GenerateReport() *
Books
Flight
F_No : String Name : String Time : String Date : Date NoOfSeats : Integer
Code:For flight class: #include "Flight.h" For passenger class: #include "Passenger.h" //##ModelId=4F7869A1004A Passenger::Reserve Ticket() { } //##ModelId=4F7869AA0072 Passenger::Cancel Ticket() { } //##ModelId=4F7869AF0202 Passenger::View Details() { }
For reservation class: #include "Reservation Clerk.h" //##ModelId=4F7869D402A3 Reservation Clerk::AddDetails() { } //##ModelId=4F7869DE01E5 Reservation Clerk::GenerateReport() { } State Diagram
LogIn Add Flight Details
View Flight Details
Reserve Ticket
Q13)
Generate Report
Consider a system with which teachers can record and update grades of students. Teachers should also be able to distribute report cards. Here is a complete list of the requirements for the system: A teacher can record grades. Whenever grades are recorded, they are also saved to disk. A teacher can update grades. Whenever grades are updated, the existing grade is loaded. Then the updated grade is saved to disk. A teacher, a registrar, and/or a student can view grades.
Whenever any of these people view grades, they must always log on to the
system. If their log on fails, they must re-authenticate their user name and password. A part-time student is a kind of student. A registrar can generate report cards. A teacher can distribute report cards. Draw Use Case diagram, including all actors, Use Cases, and relationships. Be sure to use the correct notation for all actors, Use Cases, and relationships. Also be sure to label each and every actor, Use Case, and relationship. Draw Analysis Model, Class Diagram and Generate Code. Write description of each usecase.
Sol:-
Use Case Description Use Case Use Case Name Objective Actors PreConditions
Rakesh sherwal
1 Record Grade This helps to store grades of the student Teacher None
00711604411
Postconditions Flow of Events
Grades are stored on the disk This use case starts when the teacher wishes to record the grades of the students , for doing so data is saved to the disk None
Alternative Flow
Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events
2 Save to disk This helps to store data on the disk None Data is present to be saved Data is saved This use case starts when there is data to be saved on the disk , after saving the data use case terminates
Alternative Flow
None
Use Case Use Case Name Objective Actors PreConditions Postconditions

Rakesh sherwal
3 Load Grades This loads data ffrom the disk None Data is present to be restored Data is loaded in the memory from the disk
00711604411
Flow Events
of
This use case starts when there is data to be restored from the disk , after loading the data use case terminates None
Alternative Flow
Use Case Use Case Name Objective Actor PreConditions Postconditions Flow of Events
4 Update This helps to update grades of the students None Data is present to be updated Data is updated This use case starts when there is data to be updated, for doing so data from the disk is loaded in to the memory , changes are made and then saved back to the disk None
Alternative Flow Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events Alternative Flow
Rakesh sherwal
5 View Grades This helps to get information of grades of the students Student, Teacher and Registrar Grades must be available to be looked Grades are provided This use case starts when one wants to look grades , for doing so disk is accessed and provided to intended user None
00711604411
6 Login This will allow users to login the system Student, Teacher and Registrar All users must have user name and password created for them in the system prior to use case If use case got successful then users are logged on to the system else system state is unchanged This use case starts when the actor wishes to login 1. The system requests that the actors enter their username, password 2. The actors enter their username, password 3. The system validates the entered username, password and logs actor into the system. If in the basic flow, the actor enters an invalid name, password the system displays an error message. The actor can choose to either return to the beginning of the basic flow or cancel the login, at which point the use case ends
Alternative Flow
7 Generate report This is used for report generation Registrar Grades must be available Report is generated This use case starts when one wants to see the report, for doing so disk is accessed and report is generated
Use Case Use Case Name

Rakesh sherwal
8 Distribute report
00711604411
Objective Actors PreConditions Postconditions Flow of Events
This is used for report distribution Teacher Grades must be available Report is distributed This use case starts when one wants to see the report, for doing so disk is accessed and report is generated
Alternative Flow
None
Analysis diagram:-
Rakesh sherwal
00711604411
teacher
student name enrollment no
subjects
batch
disk interface
disk
teacher interface
record grades
update grades student
ragistar
ragistar interface
student interface distribute report card
username
log in
password
view grades generate report card
Class diagram:teacher name subjects qualification record grades() update grades() view greades() distribute report card() 1
login system username password login() logout() authentication failed()
student name roll no batch username password view grades() login() logout()
registar name username password dept login() logout() genrate report card()
Code generation:Rakesh sherwal 00711604411
#include "Marksheet.h"
//##ModelId=4F7AB4AA0203 Marksheet::update() { }
//##ModelId=4F7AB4AC0186 Marksheet::addgrade() { } #ifndef MARKSHEET_H_HEADER_INCLUDED_B0850CF8 #define MARKSHEET_H_HEADER_INCLUDED_B0850CF8
//##ModelId=4F7AB46C005D class Marksheet { public: //##ModelId=4F7AB4AA0203 update();
//##ModelId=4F7AB4AC0186 addgrade();
private: //##ModelId=4F7AB477038A int is;
//##ModelId=4F7AB47A034B char listofgrades[];
}; #endif /* MARKSHEET_H_HEADER_INCLUDED_B0850CF8 */ #ifndef PERSON_H_HEADER_INCLUDED_B0851932 #define PERSON_H_HEADER_INCLUDED_B0851932
//##ModelId=4F7AB43C02BF class Person
Rakesh sherwal
00711604411
{ //##ModelId=4F7AB442003E string name;
//##ModelId=4F7AB4450251 string address;
//##ModelId=4F7AB4480399 date dob;
//##ModelId=4F7AB44E03B9 Long phnno;
//##ModelId=4F7AB46300CB char gender;
};
#endif /* PERSON_H_HEADER_INCLUDED_B0851932 */ #include "Registrar.h"
//##ModelId=4F7AB50E0109 Registrar::login() { }
//##ModelId=4F7AB510005D Registrar::viewgrade() { }
//##ModelId=4F7AB51302CE Registrar::generate report() { } #ifndef REGISTRAR_H_HEADER_INCLUDED_B08562A8
Rakesh sherwal
00711604411
#define REGISTRAR_H_HEADER_INCLUDED_B08562A8 #include "Person.h"
//##ModelId=4F7AB4FC03A9 class Registrar : public Person { public: //##ModelId=4F7AB50E0109 login();
//##ModelId=4F7AB510005D viewgrade();
//##ModelId=4F7AB51302CE generate report();
private: //##ModelId=4F7AB50202EE int id;
//##ModelId=4F7AB5060242 string desciption;
};
#endif /* REGISTRAR_H_HEADER_INCLUDED_B08562A8 */ #include "report.h"
//##ModelId=4F7AB53D00CB report::modify() { }
//##ModelId=4F7AB54000BB report::optimize() {
Rakesh sherwal
00711604411
} #ifndef REPORT_H_HEADER_INCLUDED_B0855F9D #define REPORT_H_HEADER_INCLUDED_B0855F9D
//##ModelId=4F7AB51C030D class report { public: //##ModelId=4F7AB53D00CB modify();
//##ModelId=4F7AB54000BB optimize();
private: //##ModelId=4F7AB52E00CB int id;
//##ModelId=4F7AB5310119 string descrption;
};
#endif /* REPORT_H_HEADER_INCLUDED_B0855F9D */ #include "student.h"
//##ModelId=4F7AB4EF0251 student::viewgrade() { }
//##ModelId=4F7AB4F60138 student::login() { } #ifndef STUDENT_H_HEADER_INCLUDED_B085349B
Rakesh sherwal
00711604411
#define STUDENT_H_HEADER_INCLUDED_B085349B #include "Person.h"
//##ModelId=4F7AB4DE0271 class student : public Person { public: //##ModelId=4F7AB4EF0251 viewgrade();
//##ModelId=4F7AB4F60138 login();
private: //##ModelId=4F7AB4E3034B int rollno;
//##ModelId=4F7AB4E900DA string course;
};
#endif /* STUDENT_H_HEADER_INCLUDED_B085349B */ #include "Teacher.h"
//##ModelId=4F7AB4CF007D Teacher::recordgade() { }
//##ModelId=4F7AB4D500CB Teacher::update() { }
//##ModelId=4F7AB4D700AB
Rakesh sherwal
00711604411
Teacher::viewgrade() { }
//##ModelId=4F7AB4DA00BB Teacher::login() {} #ifndef TEACHER_H_HEADER_INCLUDED_B0855609 #define TEACHER_H_HEADER_INCLUDED_B0855609 #include "Person.h"
//##ModelId=4F7AB4B302EE class Teacher : public Person { public: //##ModelId=4F7AB4CF007D recordgade();
//##ModelId=4F7AB4D500CB update();
//##ModelId=4F7AB4D700AB viewgrade();
//##ModelId=4F7AB4DA00BB login();
private: //##ModelId=4F7AB4BE0167 int id;
//##ModelId=4F7AB4C0031C string specialisation;
}; #endif /* TEACHER_H_HEADER_INCLUDED_B0855609 */
Rakesh sherwal
00711604411
Q14) Draw Use Case Diagram, Sequence Diagram (for each use case) and Analysis Model for ESU University. Extend the analysis model to the Class Design and Generate Code. Write description of each use case.

The ESU University wants to computerize their registration system The Registrar sets up the curriculum for a semester o One course may have multiple course offerings Students select 4 primary courses and 2 alternate courses Once a student registers for a semester, the billing system is notified so the student may be billed for the semester Students may use the system to add/drop courses for a period of time after registration Professors use the system to receive their course offering rosters Users of the registration system are assigned passwords which are used at logon validation Use Case Diagram:-
Sol:-
Use Case Description 1.Log In The Login use case is used by Student, Professor and Registrar to allow the actor to initiate other use cases. Primary Actors - Student, Professor, Registrar
00711604411

Rakesh sherwal
Secondary Actors - None LOGIN PROMPT. The ESU Registration System prompts the user to enter a username and password. ENTERS USERNAME/PASSWORD. The user enters the username and password and selects Login. CHECK USERNAME/PASSWORD. The ESU Registration System (RS) first checks whether the user exists or not. If it exists, then it checks whether the password for the user matches or not. The username is found and the password matches. LOGIN USER. The user is logged in as Registrar, Professor or Student depending on the user account used to log in and given the related privileges.
WRONG USERNAME/PASSWORD
Flow of Events
Alternative Flow
At basic flow step CHECK USERNAME/PASSWORD, the user enters either an inexistent username or the password for the username entered doesnt match. The system then displays a message The username or password is incorrect. Please try again. The use case resumes at LOGIN PROMPT. User must have a username, password, and role, created for them in the system, prior to the use case. If the use case was successful the actor is logged into the system. If not, the system state is unchanged.
2. Maintain schedule The Maintain Schedule use case is used by a student to register for a semester. Students select 4 primary courses and 2 alternate courses.
Primary Actors - Student Secondary Actors Billing System 00711604411
Brief Description
Actors
Rakesh sherwal
Flow of Events
1. DISPLAY COURSE OFFERINGS. The ESU-RS provides the student with a list of course offerings. 2. SELECT COURSES. The student selects 4 primary courses and 2 alternate courses. 3. REGISTER COURSES. The student registers the courses with the system. 4. NOTIFY BILLING SYSTEM. The system saves the registration information for the user, and sends this information to the Billing System. EXIT WITHOUT REGISTERING At basic flow steps DISPLAY COURSE OFFERING and SELECT COURSES, the user is allowed to exit the system. Doing so, the system saves any selected courses without registering them. The use case exits.
The user has logged in as a Student. The student has registered for the semester.
Alternative Flow
3. Maintain Curriculum The use case Maintain Curriculum is used by Registrar to setup the course offerings for the semester.
Primary Actors - Registrar
Brief Description Actors Flow of Events
Secondary Actors - None
1. DISPLAY AVAILABLE COURSES. The system displays the available course offerings to the Registrar.
00711604411
Rakesh sherwal
2. SELECT COURSES TO BE OFFERED. The Registrar selects the courses which are to be offered in the current semester. 3. PUBLISH CURRICULUM. The Registrar publishes the curriculum. EXIT WITHOUT PUBLISHING At all the basic flow steps, the user is allowed to exit the system. Doing so, the system saves any selected courses without publishing them. The use case exits.
The user is logged in as Registrar. The courses offered in the semester are published.
Alternative Flow
4. Request Course Roster The Request Course Roster is initiated by Professor to get his/her course schedule.
Primary Actors - Registrar
Secondary Actors - None
Flow of Events
1. DISPLAY COURSES. The ESU-RS displays a list of courses which are to be taught by the professor. 2. SELECT A COURSE. The professor selects one of the courses from the list. 3. DISPLAY SCHEDULE. The system displays the schedule of the course. None.
Alternative Flow
Rakesh sherwal
00711604411
The user is logged in as professor The logged in Professor is provided with his/her course schedule.
Sequence Diagram:1. Login
2. Maintain schedule
3. Maintain Curriculum
4. Request Course Roster
Rakesh sherwal
00711604411
ANALYSIS MODEL:
Q15) Draw Usecase Diagram, Analysis Model and Class Diagram with Code Generation for ABC Business center discuss below. Write description of each usecase. ABC Business center of the city is an event management company. It has 30 seminar rooms, 10 video-conference-meeting halls and 20 rooms meant for
interview. All the rooms and halls are equipped with necessary electronic items (computer, internet, teleconferencing, single gun projector) The organizations situated at various places of the country ca register for their company to conduct seminars, interviews and business meeting. The event registration form is filled online and the same is submitted. The event registration form is filled online and the same is submitted. The event registration system checks for the availability, and books the event. Some of the other services required by the organizations such as invitation printing and distribution, additional seats in the seminar hall, and food management can also be arranged upon request. It also promotes its management staff of customer care division to extend the organization services. Simulate the system to provide online booking and coordinate with other food and infrastructure arrangements. The budget is prepared and submitted to the organization for their acceptance. The organization, which utilizes the services, must pay 20% in advance. Advance amount is adjusted in the final bill. Sol:-
Use Case Description 1. Registration Brief Description Actors Flow of Events

Rakesh sherwal
The Process is started by the Customer. Primary Actors - Customer Secondary Actors - None 1. Enter the details of requirements. 2. Availability Status will be checked.
00711604411
3. Then registration will be complete. Alternative Flow Precondition Post condition none none Authenticated Customer
2. Extra services Extra Services which the customer may want. Like invitation printing & distribution, additional seats, food management. Primary Actors - Customer Actors Secondary Actors - None 1 Enter the details of requirements. 2 Availability Status will be checked. 3 Staff will be informed. none Authenticated Customer none
Brief Description
Flow of Events Alternative Flow Precondition Post condition
3. Extended Organization Services
Brief Description
Extra Organisational work to be done in order to fulfill the extra services.
Rakesh sherwal
00711604411
Primary Actors - Customer Actors Flow of Events Alternative Flow Precondition Post condition none Extra Services are demanded by the customer none Secondary Actors - None Orders are given to the staff.
4. Budget Preparation Brief Description Actors Bill is prepared by the administrator. Primary Actors - Customer Secondary Actors - None Bill is made according to the details of requirements. none Authenticated Customer none
Flow of Events Alternative Flow Precondition Post condition 5. Payment Brief Description Actors
Customer pays 20% of the bill in advance. Primary Actors - Customer Secondary Actors - None
Rakesh sherwal
00711604411
Flow of Events Alternative Flow Precondition Post condition none none
Online Payment Takes place.
Registered Customer
Q16) Draw Usecase Diagram, Analysis Model and Class Diagram with Code Generation for Student Information System discuss below. Write description of each usecase. System automates the student information system. Student can register for the degree existing in the college and view Course catalogue. It permits the student to register for the course in each semester. Information about each course such as course curriculum, Professor who handles, department that offers course and prerequisite to attend the course will be listed. A student will do 4 courses in each semester on his choice. He must submit with 4 primary and 2 alternative choices of the course. Course will be offered when it is chosen by maximum of 25 studens and minimum of 15 students. A course offered by less than the prescribed minimum will be cancelled. The alternative choices are taken into consider in that case. Students change their course within week time of the commencement of the semester. Performance of the student in assignment and continuous internal assessments aer recorded electronically and it can be viewed at any time. It also maintains the fee collection details of the student.
Sol.:use case diagram:-
Rakesh sherwal
00711604411
Use case description:1. Registration This use case describes how a user logs into the Course Registration System. Student, professor & register. This use case starts when the actor wishes to log into the Course Registration System. 1. The system requests that the actor enter his/her name and password. 2. The actor enters his/her name and password. 3. The system validates the entered name and password and logs the actor into the system.
Invalid Name/Password If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends. none If the use case was successful, the actor is now logged into the system. If not, the system state is unchanged.
Alternative Flow
2. Registration for course This use case allows a Student to register for course offerings in the current semester. The Student can also update or delete course selections if changes are made within the add/drop period within a week of beginning of the semester. The Course Catalog provides a list of all the course offerings for the current semester. Student This use case starts when a Student wishes to register for course offerings, or to change his/her existing course schedule. 1. The system requests that the Student specify the function he/she would like to perform (either Create a Schedule, Update a Schedule, or Delete a Schedule). 2. Once the Student provides the requested information, one of the sub flows is executed.
Brief Description
Actors Flow of Events
If the Student selected Create a Schedule, the Create a Schedule subflow is executed. If the Student selected Update a Schedule, the Update a Schedule subflow is executed. If the Student selected Delete a Schedule, the Delete a Schedule subflow is executed. Invalid Name/Password If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends. The Student must be logged onto the system before this use case begins. If the use case was successful, the student schedule is created, updated, or deleted. Otherwise, the system state is unchanged.
Alternative Flow
Precondition
Post condition
3. View report card This use case allows a Student to view his/her report card for the previously completed semester. Student This use case starts when a Student wishes to view his/her report card for the previously completed semester. 1. The system retrieves and displays the grade information for each of the course offerings the Student completed during the previous semester.
2. When the Student indicates that he/she is done viewing the grades, the use case terminates. Alternative Flow The system cannot find any grade information from the previous semester for the Student, a message is displayed. Once the Student acknowledges the message, the use case terminates. The Student must be logged onto the system before this use case begins. The system state is unchanged by this use case.
4. Maintain Student Information This use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying, and deleting Students from the system. Registrar This use case starts when the Registrar wishes to add, change, and/or delete professor information in the system. 1. The system requests that the Registrar specify the function he/she would like to perform (either Add a Professor, Update a Professor, or Delete a Professor) Flow of Events 2. Once the Registrar provides the requested information, one of the sub flows is executed. If the Registrar selected Add a Professor, the Add a Professor subflow is executed. If the Registrar selected Update a Professor, the Update a Professor subflow is executed. If the Registrar selected Delete a Professor, the Delete a Professor subflow is executed.
Brief Description
Actors
Rakesh sherwal
00711604411
Alternative Flow
If, in the Update a Student or Delete a Student sub-flows, a student with the specified id number does not exist, the system displays an error message. The Registrar can then enter a different id number or cancel the operation, at which point the use case ends. The Registrar must be logged onto the system before this use case begins. If the use case was successful, the student information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.
Precondition
Post condition
5. Maintain Professor Information This use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system Registrar This use case starts when a Student wishes to view his/her report card for the previously completed semester. Flow of Events 1. The system retrieves and displays the grade information for each of the course offerings the Student completed during the previous semester. 2. When the Student indicates that he/she is done viewing the grades, the use case terminates. Alternative Flow Precondition
Rakesh sherwal
The system cannot find any grade information from the previous semester for the Student, a message is displayed. Once the Student acknowledges the message, the use case terminates. The Student must be logged onto the system
00711604411
before this use case begins. Post condition If the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.
6. Select Courses to Teach This use case allows a Professor to select the course offerings from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester. proffessor This use case starts when a Professor wishes to sign up to teach some course offerings for the upcoming semester. 1. The system retrieves and displays the list of course offerings the professor is eligible to teach for the current semester. The system also retrieves and displays the list of courses the professor has previously selected to teach. 2. The professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcoming semester. 3. The system removes the professor from teaching the de-selected course offerings. 4. The system verifies that the selected offerings do not conflict (i.e., have the same dates and times) with each other or any course offerings that the professor has previously signed up to teach. If there is no conflict, the system updates the course offering information for each offering the professor selects (i.e., records the professor as the instructor for the course offering).
Brief Description
Alternative Flow
the professor is not eligible to teach any course offerings in the upcoming semester, the system will display an error message. The professor acknowledges the message and the use case ends. The Student must be logged onto the system before this use case begins. If the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.
7. Submit Grades This use case allows a Professor to submit student grades for one or more classes completed in the previous semester. Professor, student This use case starts when a Professor wishes to submit student grades for one or more classes completed in the previous semester. 1. The system displays a list of course offerings the Professor taught in the previous semester. 2. The Professor selects a course offering. 3. The system retrieves a list of all students who were registered for the course offering. The system displays each student and any grade that was previously assigned for the offering. 4. For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The system records the students grade for the course offering. If the Professor wishes to skip a particular student, the grade information can be left blank and filled in at a later time. The Professor may also change
the grade for a student by entering a new grade. Alternative Flow The system cannot find any grade information from the previous semester for the Student, a message is displayed. Once the Student acknowledges the message, the use case terminates. The Student must be logged onto the system before this use case begins. If the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.
8. Close Registration This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering. Registrar This use case starts when the Registrar requests that the system close registration. 1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar, and the use case terminates. The Close Registration processing cannot be performed if registration is in progress. 2. For each course offering, the system checks if a professor has signed up to teach the course offering and at least three students have registered. If so, the system commits the course offering for each schedule that contains it.
Brief Description
3. For each schedule, the system levels the schedule: if the schedule does not have the maximum number of primary courses selected, the system attempts to select alternates from the schedules list of alternates. The first available alternate course offerings will be selected. If no alternates are available, then no substitution will be made. 4. For each course offering, the system closes all course offerings. If the course offerings do not have at least three students at this point (some may have been added as a result of leveling), then the system cancels the course offering. The system cancels the course offering for each schedule that contains it. 5. The system calculates the tuition owed by each student for his current semester schedule and sends a transaction to the Billing System. The Billing System will send the bill to the students, which will include a copy of their final schedule. there is no professor signed up to teach the course offering, the system will cancel the course offering. The system cancels the course offering for each schedule that contains it. The Student must be logged onto the system before this use case begins. If the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.
Alternative Flow
Generate Fees Receipt This use case allows a Registrar to accept the fees and generate the fees receipt of the student who has taken admission and submitted the fees for which the courses opted were available Registrar
00711604411

Rakesh sherwal
This use case starts when the Registrar requests that the system generates fees receipt. Flow of Events 1. The system asks for the roll number of the student. 2. It then checks for which courses the student has opted. 3. The fees receipt is generated according to the courses opted for. There is no student enrolment number, the system will cancel the receipt generation. The Student must be logged onto the system before this use case begins. If the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.
Alternative Flow Precondition Post condition Analysis model:-
4 primary choice
register for course
2 alternative choice
internal assignment submit course
student
student inetrface view course performance of student is recorded system interfce
system
change course
login
choosen by min 15 student
viewed grades
choosen by min 15 student
maintains fee
offer course professor professor interface less then minimum cancel course
attend the course
Rakesh sherwal
00711604411
Activity diagram:Student
student
professor
professor
course
course
system
system
view course
offer course
register for course
attend the course
do 4 course
submit 2 alternative choice 2 alternative choice
15 student<
change course
course offer
course cancel
performance
recored
thier assignment
internal assignment view grades
maintains fee details
Q17) Consider a Social Networking Website. The aim of the site is to let people network socially over the Internet. A user can register with the site. On doing so, he is connected with all other registered users of this site. To begin networking, he must search for names through a general search. The system will display the public record of the user under the name. He can select a particular user and invite him to become a friend. On acceptance of the request, the latters record will be visible in the Friends List of the user and vice versa. The user can send and receive messages that can be of two types: public and private. A public message, when sent, will be visible to all the registered users browsing the public message list, whereas a private message will be visible only to the recipient. A registered user can upload his photographs and delete previously uploaded photographs. For the persons who do not have any knowledge of this site, an email can be sent, providing information of this site. User can also delete an already added friend from his friend list. He is also allowed to send group messages to a group of friends.
Consider only client side functional requirements and answer the followings Draw Usecase Diagram, Sequence Diagram (for each usecase) and Analysis Model using Rational Rose. Write description for each usecase. Sol.:
Register
Search
Rakesh sherwal
00711604411
Friend Request/Request Acceptance/Rejection
Unfriend
Photo
(Upload/Remove)
Rakesh sherwal
00711604411
Message
Use Case Description :Use Case Use Case Name Objective

Rakesh sherwal
1 Register A user can register with the site. On doing so, he is

00711604411
connected with all other registered users of this site. Actors PreConditions Postconditions Flow of Events Alternative Events Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events Alternative Events Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events Alternative
Rakesh sherwal
User User must be available to the network To become registered user This use case starts when the one wishes to become registered user. Not registered user.
2 Search To begin networking, he must search for names through a general search. Registered User To search the friend He can select a particular user and invite him to become a friend. This use case starts when the one wishes to search the person on site. Search not done. 3 Friend Request On acceptance of the request, the latters record will be visible in the Friends List of the user Registered user User must be registered. Can send and receive messages. This use case starts when the one wishes to make friends. Do not want to make friends.
00711604411
Events Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events Alternative Events Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events Alternative Events Use Case Use Case Name
Rakesh sherwal
4 Delete photo Delete previously uploaded photographs registered user Photographs must be there. None This use case starts when the one wishes to delete photographs Photographs not deleted.
5 Upload Photo A registered user can upload his photographs registered user None Photographs must be present This use case starts when the one wishes to upload photographs Photographs not uploaded.
6 Receive Message
00711604411
Objective Actors PreConditions Postconditions Flow of Events Alternative Events Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events Alternative Events Use Case Use Case Name Objective Actors PreConditions Postconditions
Rakesh sherwal
The user can receive messages Registered User Message must be there to receive. Message must be received. This use case starts when the one wishes to receive a message. Message not received.
7 Send Message The user can send messages Registered User Message must be there to send. Message must be sent. This use case starts when the one wishes to send a message. Message not sent.
8 Private message a private message will be visible only to the authenticated registered user Registered user. Message must be there to send/receive Message must be sent/received
00711604411
Flow Events
of
This use case starts when the one wishes to send/receive a message. Message not sent/received. 9 Public Message A public message, when sent, will be visible to all the registered users browsing the public message list Registered user Message must be there to send/receive Message must be sent/received This use case starts when the one wishes to send/receive a message. Message not sent/received.
Alternative Events Use Case Use Case Name Objective Actors PreConditions Postconditions Flow of Events Alternative Events
Q18.Draw a State Transition Diagram to depict the following: A telephone can be idle or active. Initially it is idle. When it is lifted off the hook by a valid subscriber, the dial tone starts playing and the telephone becomes active. When it is active, the dial tone plays, or it can be in the midst of dialing, or in the midst of connecting, or in the midst of talking. When the first digit is punched, the dial tone stops playing and the process of dialing begin. When all digits are punched it starts to connect. When the phone is lifted by the other party, both parties can talk b) Draw Analysis model and class diagram with code generation using forward engineering for personal investment management system (PIMS) given below Many people invest their money in a number of securities (shares). Generally, an investor has multiple portfolios of investments, each portfolio having investments in many securities. From time to time an investor sells or buys some securities and gets dividends for the securities. There is a current value of each security-many sites give this current value. It is proposed to build a personal investment management system (PIMS) to help investors keep track of their investments as well as on the overall portfolios. The system should also allow an investor to determine the net-worth of the portfolios.
Rakesh sherwal
00711604411
Sol:State Transition Diagram:-
Analysis model:-
Rakesh sherwal
00711604411
Class diagram:-
Rakesh sherwal
00711604411
Q19) a) Consider a car rental application. The rental agency has multiple offices/ locations where customer can test drive and then select a car for rental (local or to outstation). The period of rental, terms and conditions for rental is flexible. Software has to take responsibility for loaning cars, keeping track of availability of cars, return of cars, billing, maintenance activities for cars and keeping track of drivers availability and assignment in case of chauffeur driver car rentals. Draw use case diagram and Analysis model for above application taking advantage of full UML notation for use case diagrams. Write description for each usecase Sol:-
a) Car rental application Use Case Use Case Name Objective Actors PreConditions Postconditions Flow Events of 1 Car Tracking keeping track of availability of cars Rental Agency Cars must be available to the agency Record the track This use case starts when the one wishes to check the avaibality of cars Track not maintained.
00711604411
Alternative
Rakesh sherwal
Events
Use Case Use Case Name Objective Actors PreConditions Postconditions Flow Events of
3 Car Returning Return a car. Customer,Rental Agency Cars must be available to the agency Maintain the record of returned car. This use case starts when the one wishes to record status of car. Record not maintained.
Alternative Events
4 Billing To create the bill of rental cars Rental Agency, Customer Cars must be given to the customer Bills can be printed. This use case starts when the one wishes to create bills for issuances of rental cars. Bills not maintained.
Alternative Events
Rakesh sherwal
00711604411
5 Car Maintainece maintenance activities for cars Rental Agency Cars must be available to the agency Record the Activites This use case starts when the one wishes to maintenance activities for cars Maintenance not done.
Alternative Events
7 assignment assignment in case of chauffeur driver car rentals. Rental Agency Cars must be available to the agency Record the track This use case starts when the one wishes to assign in case chauffeur driver car rentals. Assignment not made.
Alternative Events
Rakesh sherwal
00711604411
8 Print Bill To print the bill of rental cars Rental Agency, Customer Cars must be given to the customer and bill must be prepared Bill must be given to the customer This use case starts when the one wishes to print bills for rental cars. Bills not printed.
Alternative Events
6 Drivers Track keeping track of drivers availability Rental Agency Cars must be available to the agency Record the track This use case starts when the one wishes to record the track of drivers Track not maintained.
Alternative Events
Rakesh sherwal
00711604411
Analysis diagram:-
b) The purchasing department handles purchase requests from other departments in the company. People in the company who initiate the original purchase request are the "customers" of the purchasing department. A case worker within the purchasing department receives that request and monitors it until it is ordered and received. Case workers process the requests for purchasing products under $1,500, write a purchase order, and then send it to the approved vendor. Purchase requests over $1,500 must first be sent out for a bid from the vendor that supplies the product. When the bids return, the case worker selects one bid. Then, the case worker writes a purchase order and sends it to the approved vendor. Draw Activity Diagram for the case study given above
Activity Diagram:-
Rakesh sherwal
00711604411
Q20) a) A
simple digital watch has a display and two buttons to set it, the A button and the B button. The watch has two modes of operation, display time and set time. In the display time mode, the watch displays hours and minutes, separated by a flashing colon. The set time mode has two sub modes, set hours and set minutes. The A button selects modes. Each time it is pressed, the mode advances in the sequence: display, set hours, set minutes, display, etc. Within the sub modes, the B button advances the hours or minutes once each time it is pressed. Buttons must be released before they can generate another event. Prepare a state diagram of the watch.
State diagram:-
Rakesh sherwal
00711604411
Rakesh sherwal
00711604411

Mohit OOAD - List of Practicals - MCA-IV Sem

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mohit OOAD - List of Practicals - MCA-IV Sem

Uploaded by

Copyright:

Available Formats

Q1) Draw a Usecase Diagram, Activity Diagram, Analysis Model and Sequence Diagram (for each usecase).

Sol:Use case diagram:-

Review caller message

None The caller has left a message to be reviewed Message is reviewed

Delete caller message

Brief Description Actors

Flow of Events Alternative Flow Precondition Post condition

Set answer mode

None None None

Take caller message

press of a button either on the system itself, or by means of a remote control.

2. Requirement 2. The user shall be able to change the channel at the

Sol:Use Case Diagram:-

Review caller message

None The caller has left a message to be reviewed Message is reviewed

Delete caller message

None None None

Brief Description Actors Flow of Events Alternative Flow

Precondition Post condition

Sol.:- Use Case Diagram:-

Display stock details System Make Receipt

Process an order Sales Assistant Check Status

Make Refund Card Payment System Place BackOrder Customer

Monitor Stock Levels

Information regarding product is displayed

Brief Description Actors

None The order has been processed

Precondition Post condition 6. Place Backorder

7. Calculate Weekly Bonus Brief Description Actors Flow of Events

Alternative Flow Precondition Post condition

None None None

10. Catalogue Maintenance Brief Description

The catalogue of the available products is maintained.

Actors Flow of Events Alternative Flow Precondition Post condition

anticipated. Alternative Flow Precondition Post condition None None None

1: Enters Product Information

2: Display Product details 3: Makes Order 4: Process Order

12: Generates receipt

13: Print Sales Summary

Use Case Description Rakesh sherwal 00711604411

Alternative Flow Precondition Post condition 2. Selection Tool

Precondition Post condition

Alternative Flow Precondition Post condition 3. Creation Tool

Class Diagram(Drwaing Tool)

Use case Diagram:-

print add question

add category junior staff

None None None

5. Restricted Question Brief Description Actors Flow of Events

Alternative Flow Precondition Post condition Class Diagram:-

None Content has to be sensitive None

Activity diagram:Staff Person

Adds Survey header to database

Add Questions To Survey

Add Question Category yes

Sensitive content Restricted To Senior Staff

Prepares Final survey

Scheduler Cancel Appointment

Prescribe Medication Medical History

Specifies Drug Info

Cross Check For Conflict

2. Cancel Appointment Brief