mohit ooad_list of practicals_mca-iv sem
TRANSCRIPT
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:-
Rakesh sherwal 00711604411
Review caller message
Brief Description This use case is used to review the message left by caller
Actors Owner,Machine
Flow of EventsOwner reviews the messages
Alternative Flow None
Precondition The caller has left a message to be reviewed
Post conditionMessage is reviewed
Delete caller message
Brief Description This use case is used to delete the message left by caller
Actors Owner,machine
Flow of EventsCaller selects a message
Caller deletes the message
Alternative Flow None
Precondition Message should be present
Post condition none
Record greeting
Brief Description This use case is user to record a greeting for the caller
Actors Owner , Machine
Flow of EventsOwner press the record button
Owner records a greeting for caller
Alternative Flow None
Precondition None
Post condition The machine has a greeting message for caller
Play greeting
Brief DescriptionThis use case is used to play a greeting when a caller calls and the owner is unable to
answer the call
Rakesh sherwal 00711604411
Actors Caller, Machine
Flow of EventsCaller calls the owner
Machine plays the message
Alternative Flow Caller calls the owner
Precondition None
Post condition None
Set answer mode
Brief Description This use case is used to set the answering mode by owner
Actors owner, Machine
Flow of EventsOwner sets the answering mode
Alternative Flow None
Precondition None
Post condition None
Take caller message
Brief Description This sue case is used to record the caller’s message in the machine
Actors Caller, Machine
Flow of EventsCaller calls the owner. Owners provides a message to be recorded. Machine records
the message
Alternative Flow None
Precondition None
Post condition None.
Rakesh sherwal 00711604411
Analysis model:-
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 won’t 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,920×1,080 resolution in wide-screen mode.
6. Requirement 6. The System shall be able to display HD 1080 interlaced scan content at 1,920×1,080 resolution in wide-screen mode.
7. Requirement 7. The System shall be able to display HD 720 progressive scan content at 1,280×720 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 852×480 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
Brief Description This use case is used to review the message left by caller
Actors Owner,Machine
Flow of EventsOwner reviews the messages
Alternative Flow None
Precondition The caller has left a message to be reviewed
Post conditionMessage is reviewed
2. Delete caller message
Brief Description This use case is used to delete the message left by caller
Actors Owner,machine
Flow of EventsCaller selects a message
Caller deletes the message
Alternative Flow None
Precondition Message should be present
Post conditionnone
Rakesh sherwal 00711604411
3. Record greeting
Brief Description This use case is user to record a greeting for the caller
Actors Owner , Machine
Flow of EventsOwner press the record button
Owner records a greeting for caller
Alternative Flow None
Precondition None
Post conditionThe machine has a greeting message for caller
4. Play greeting
Brief DescriptionThis use case is used to play a greeting when a caller calls and the owner is unable to answer the
call
Actors Caller, Machine
Flow of EventsCaller calls the owner
Machine plays the message
Alternative Flow Caller calls the owner
Precondition None
Post conditionNone
5. Set answer mode
Brief Description This use case is used to set the answering mode by owner
Actors owner, Machine
Flow of EventsOwner sets the answering mode
Alternative Flow None
Precondition None
Post condition None
6. Take caller message
Brief Description This sue case is used to record the caller’s message in the machine
Actors Caller, Machine
Flow of EventsCaller calls the owner. Owners provides a message to be recorded. Machine records
the message
Alternative Flow None
Rakesh sherwal 00711604411
Precondition None
Post conditionNone.
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 Hurry’s 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
Catalog Maintenance
Access Sales Information
Marketing
Warehouse Person
Books Stock
Calculate Weekly Bonus
Print Sales Summary Report
Monitor Stock Levels
Monitor Weekly Run RatesStock
Manager
Store Manager
Assign Sales
Place BackOrder
Check Status
Make Refund
Sales Assistant
Card Payment System
Cash
Customer
Payment
<<extend>>
<<extend>>
Display stock details
Process an order <<include>>
Make Receipt
<<extend>>
System
<<extend>>
Use Case Description
1. Display Stock Details
Brief Description
The system displays info to Sales assistant
Actors System
Flow of Events
1. Sales assistant enters the product numbers and required quantities into system.
2. System displays the description, price and available stock
Alternative Flow None
Precondition Product numbers must be enteredPost Information regarding product is displayed
Rakesh sherwal 00711604411
condition
2. Make Receipt
Brief Description
The System generates receipt of the Order processed
Actors System
Flow of Events
As payment is made the receipt is generated
Alternative Flow None
Precondition Payment must be made
Post condition
None
3. Process An Order
Rakesh sherwal 00711604411
Brief Description
The sales assistant initiates this use case. It processes the order.
Actors Sales Assistant, System
Flow of Events
1. PROCESS AN ORDER
The sales assistant processes the order by entering product numbers and required quantities into the system.
2. DISPLAY DETAILSThe system displays the description, price and available stock.
3. DELIVER PRODUCTThe product can be delivered to the customer’s home address or be collected by the customer immediately. The product is delivered immediately from the store.
4. MAKE PAYMENTPayments 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.
Alternative Flow
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.
2. DELIVER PRODUCT
The product will be delivered either directly from the regional warehouse to the customer’s 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 customer’s 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 NonePost condition
The order has been processed
4. Check Status
Brief Description
The sales assistant will be able to check the status of the available stock.
Actors Sales AssistantFlow of Events
The sales assistant check the status of the available stock.
Alternative Flow None
Precondition NonePost condition
If stock is not available back order is placed.
5. Make Refunds
Brief Description
The sales assistant makes the refunds to the customer by initiating this use case.
Actors Sales Assistant, Customer
Flow of Events
1. The customer produces a valid receipt.2. The refunds are made by the sales assistant.3. The use case ends.
Rakesh sherwal 00711604411
Alternative Flow
Invalid Receipt 1. The customer doesn’t 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.
Precondition Customer has made all the payments.Post condition
Customer has got refunds.
6. Place Backorder
Brief Description
The sales assistant places the backorder for goods which are not available in the store.
Actors Sales Assistant, Store manager
Flow of Events
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.
Alternative Flow None
Precondition NonePost condition
None
7. Calculate Weekly Bonus
Brief Description The store manager calculates the weekly bonus.
Actors Store ManagerFlow of Events
The store manager calculates the weekly bonus for each sales assistant .
Alternative Flow None
Precondition None
Rakesh sherwal 00711604411
Post condition
None
8. Print Sales Summary Repor
Brief Description
The store manager would be able to print summary reports by initiating this use case.
Actors Store Manager
Flow of Events
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.
Alternative Flow None
Precondition NonePost condition
None
9. Books Store
Brief Description
As the new stock level reduces this use case gets executed
Actors Warehouse person
Flow of Events
1. For minimum stock levels demand is anticipated.2. As the stock arrives its booked by the warehouse
personAlternative Flow None
Precondition Stock levels to be minimum.Post condition
Stock level is raised.
10. Catalogue Maintenance
Brief Description The catalogue of the available products is maintained.
Actors MarketingFlow of Events
The catalogue of available products is maintained remotely by marketing from head office.
Alternative Flow None
Rakesh sherwal 00711604411
Precondition NonePost condition
None
11.Access Sales Information
Brief Description The marketing accesses the sales information.
Actors MarketingFlow of Events
The Marketing accesses the sales information from each store system.
Alternative Flow None
Precondition NonePost condition
None
12. Payment
Brief Description It specifies the payment to be done.
Actors Sales Assistant
Flow of Events
The payment is included in process order and has two types cash and credit card.
Alternative Flow None
Precondition NonePost condition
None
13.Card payment
Brief Description
The credit/debit card is the mode of payment for the customer.
Actors Customer, Sales AssistantFlow of Events
1. The customer pays for the goods with credit card.2. The card payment is verified using online transaction
Rakesh sherwal 00711604411
system.
Alternative Flow None
Precondition NonePost condition
Payment Is Made
14.Cash
Brief Description The cash is the mode of payment for the customer.
Actors Customer, Sales AssistantFlow of Events
The customer pays for the goods with cash.
Alternative Flow None
Precondition NonePost condition
Payment is made
15.Monitor Stock Levels
Brief Description
The stock manager would monitor the stock levels by initiating this use case.
Actors Stock Manager
Flow of Events
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 anticipated.
Alternative Flow None
Precondition NonePost condition
None
Rakesh sherwal 00711604411
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 Order4: 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
13: Print Sales Summary
12: Generates receipt
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:-
Rakesh sherwal 00711604411
Use Case Description
1. Interface GUI
Brief DescriptionInterface usecase provides interface to the user for interacting with the editor.
Actors User, Program
Flow of Events1. This usecase Starts when user first start the editor, then Program
runs and provide interface to the user.
Alternative FlowEnough memory or resources is not available is available for the program to run.
Precondition None
Post condition Interface is active
2. Selection Tool
Brief DescriptionSelect tool use case allows the user to select the different drawing elements.
Actors User
Flow of Events
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.
Alternative Flow
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.
Rakesh sherwal 00711604411
Precondition None
Post condition None
2. Manipulate elements
Brief Description Allows the user to modify the current selection.
Actors User
Flow of Events
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.
Alternative Flow None
Precondition None
Post condition None
3. Creation Tool
Brief Description allows the user to create various drawing elements
Actors User
Flow of Events 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 the four corners of the rectangle.
The system redraws the rectangle according to the dragged control
Rakesh sherwal 00711604411
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.
Alternative Flow 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
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.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.
The use case ends.
Rakesh sherwal 00711604411
Precondition None
Post condition None
Class Diagram(Drwaing Tool)
CODE
USER
<user.h>#ifndef USER_H_HEADER_INCLUDED_AE9676CC#define USER_H_HEADER_INCLUDED_AE9676CC
//##ModelId=51121CE6039Dclass User{ public: //##ModelId=5169865A004E Create element();
//##ModelId=516986660043 Select element();
//##ModelId=5169866D0283 manipulate element();
Rakesh sherwal 00711604411
//##ModelId=5169867403D3 redraw element();
private: //##ModelId=51121FDC0380 int UserID;
};
#endif /* USER_H_HEADER_INCLUDED_AE9676CC */
<user.cpp>#include "User.h"
//##ModelId=5169865A004EUser::Create element(){}
//##ModelId=516986660043User::Select element(){}
//##ModelId=5169866D0283User::manipulate element(){}
//##ModelId=5169867403D3User::redraw element(){}
TOOL
<tool.h>#ifndef TOOL_H_HEADER_INCLUDED_AE9669C0#define TOOL_H_HEADER_INCLUDED_AE9669C0
//##ModelId=5112201E01BFclass Tool{ public: //##ModelId=511220D60379
Rakesh sherwal 00711604411
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=511220D60379Tool::GetID(){}
//##ModelId=511220DB03E2
Rakesh sherwal 00711604411
Tool::GetName(){}
//##ModelId=511222C902E1Tool::SelectMultiple(){}
//##ModelId=511222DD004CTool::ModifyTool(){}
//##ModelId=5112231E0081Tool::LineTool(){}
//##ModelId=51122394030FTool::Rectangle Tool(){}
//##ModelId=5112239C0031Tool::EllipseTool(){}
//##ModelId=511223A2033DTool::opname(){}
Drawing Editor
<drawingeditor.h>#ifndef DRAWINGEDITOR_H_HEADER_INCLUDED_AE964103#define DRAWINGEDITOR_H_HEADER_INCLUDED_AE964103
//##ModelId=511221F402D5class program{
Rakesh sherwal 00711604411
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=51122234028Aprogram::GetWidth(){}
//##ModelId=511222400119program::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
Rakesh sherwal 00711604411
Sol.:- Use case Diagram:-
restricted section
add question
add category
junior staff
add db
<<include>>senior staff
add survey
<<include>>
person
<<extend>>
Use Case Description1. Add Question
Brief Description
The staff adds questions to survey sheet.
Actors Senior staff, junior staff
Flow of Events
1. After raw data is collected senior staff adds header to database
2. Then the questions are added to survey by the actorsAlternative Flow None
Precondition Raw data needs to be collected
Post condition None
2. Add Survey
Brief Description
Survey is done on person is created and added by senior staff
Actors Senior staff, PersonFlow of Events
Senior staff performs survey on person and then adds it
Alternative Flow None
Precondition None
Rakesh sherwal 00711604411
Post condition None
3. Add Category
Brief Description
The Questions in survey are categorized
Actors Senior staff, Junior staffFlow of Events
Questions added to survey are categorized
Alternative Flow None
Precondition Questions must be added to survey
Post condition None
4. Add DB
Brief Description
The senior staff adds Header to DB as raw data is collected
Actors Senior staff, Junior staffFlow of Events
Raw data is collected from surveys and then Header is added to the DB by senior staff
Alternative Flow None
Precondition Raw data must be collected
Post condition None
5. Restricted Question Brief Description
If any sensitive content is found than it is restricted to senior staff
Actors Senior staffFlow of Events
As soon as any sensitive data is found it is restricted to senior staff
Alternative Flow None
Precondition Content has to be sensitive
Post condition None
Class Diagram:-
Rakesh sherwal 00711604411
Staff
AddQuestion()AddCategory()Print()
SeniorStaff
AddCategory()AddQuestion()
JuniorStaff
RestrictQuestion()AddQuestion()AddHeader()AddSurvey()
Person
Add Survey()
*
1
*
1
surveys
Code:#include "JuniorStaff.h"
//##ModelId=4F7AAA7500F6JuniorStaff::RestrictQuestion(){}
//##ModelId=4F7AAA87038AJuniorStaff::AddQuestion(){}
//##ModelId=4F7AAABB0222JuniorStaff::AddHeader(){}
//##ModelId=4F7AAAF70006JuniorStaff::AddSurvey(){}#include "Person.h"
//##ModelId=4F7AAB0500B0Person::Add Survey(){}
Rakesh sherwal 00711604411
#include "SeniorStaff.h"
//##ModelId=4F7AAACA0272SeniorStaff::AddCategory(){}
//##ModelId=4F7AABBC0132SeniorStaff::AddQuestion(){}
#include "Staff.h"
//##ModelId=4F7AAA8D00C4Staff::AddQuestion(){}
//##ModelId=4F7AAAC20178Staff::AddCategory(){}
//##ModelId=4F7AAB210380Staff::Print(){}
Activity diagram:-
Rakesh sherwal 00711604411
Adds Survey header to database
Add Questions To Survey
Categorize Questions
Category Exists
yes
Add Question Category
Prepares Final survey
Sensitive content Restricted To Senior Staff
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.
Sol.:
Rakesh sherwal 00711604411
Forward To Pharmacy
Cross Check For Conflict
<<extend>>
Computer
Arrange Appointment
Cancel Appointment
Prescribe Medication Physician
Scheduler
Specifies Drug Info
<<include>>
Print Medication
<<extend>>
<<include>>
Patient
Medical History
<<include>>
1. Arrange Appointment
Brief Description
Patient arranges appointment with Physician using Scheduler
Actors Patient, PhysicianFlow of Events
Patient arranges appointment with physician using scheduler
Alternative Flow None
Precondition None
Post condition Appointment is made
2. Cancel Appointment
Brief Description
Patient cancels appointment with Physician using Scheduler
Actors Patient, PhysicianFlow of Events
Patient cancels appointment with physician using scheduler
Alternative Flow None
Precondition None
Rakesh sherwal 00711604411
Post condition Appointment is cancelled
3. Medical History
Brief Description
Physician checks medical History to Prescribe Medication
Actors Patient, physician Flow of Events
Physician checks patient’s Medical History to prescribe Medication
Alternative Flow Medication is not prescribed
Precondition None
Post condition Prescribe medication
4. Print Medication
Brief Description
Final Medication is Printed
Actors Patient,computer
Flow of Events
As Cross-Checks for Conflict Between Medication and Current Medications/Medical History Prescription Forwarded Electronically to Pharmacy or Else Printed for Patient .
Alternative Flow Medication is not printed
PreconditionCross-checks for conflict between medication and current medications/Medical History prescription
Post condition None
5. Scheduler
Brief Description
Arranges and cancels appointment
Actors Patient, Physician
Flow of Events
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
Alternative Flow None
Rakesh sherwal 00711604411
Precondition None
Post condition None
6. Cross check for conflict
Brief Description
Computer checks the Medication and Current Medication/Medical history prescription.
Actors Computer
Flow of Events
Computer Cross-Checks for Conflict Between Medication and Current Medications/Medical History Prescription Forwarded Electronically to Pharmacy or Else Printed for Patient.
Alternative Flow None
Precondition None
Post condition Forward to pharmacy
7. Forward to pharmacy
Brief Description
If cross-check performed by computer result’s is positive than this use is executed.
Actors ComputerFlow of Events
If cross-check performed by computer result’s is positive than patient is forwarded to pharmacy.
Alternative Flow None
Precondition None
Post condition Medication is provided
Rakesh sherwal 00711604411
Analysis Model:-
patient
physician
arranage cancel
make appointment
physician interface
drug info
madication name
dosage amount
patient interface
history medication
prescribe madication
forward to pharmacy
cross check for confl ict
computer
computer interface
Class diagram:-
1..*
1..*
computer
iddepartment
cross check()print()froward()
scheduler
daytimetypeid
arrange()cancel()schedule()
physician
idnamenamedesignation
schedule()prescribe()drug info()
1..*
1..*1..*
1..*
patient
patient idaddressnamedisease
arrange()cancel()schedule()madication history()
1
1..*
1
1..*
11..*
11..*
pharmacy
idnameaddrasstiming
give medicine()drug info()
1..*
1..*
Code generation:-
Rakesh sherwal 00711604411
#include "Computer.h"
//##ModelId=4F7ACECA0126Computer::CheckConflicts(){}
//##ModelId=4F7ACED300D6Computer::ForwardToPharmacy(){}
//##ModelId=4F7ACEE1013AComputer::PrintMedication(){}
#include "Pateint.h"
//##ModelId=4F7ACE5D0112Pateint::MedicalHistory(){}
//##ModelId=4F7ACE6600CCPateint::GetData(){}
//##ModelId=4F7ACE790112Pateint::SetData(){}
//##ModelId=4F7ACE7C01F8Pateint::GetAppointment(){}
#include "Physician.h"
//##ModelId=4F7ACE070036
Rakesh sherwal 00711604411
Physician::GetData(){}
//##ModelId=4F7ACE0E0086Physician::SetData(){}
//##ModelId=4F7ACE1503CEPhysician::PrescribeMedication(){}
#include "Scheduler.h"
//##ModelId=4F7ACE910036Scheduler::ArrangeAppointment(){}
//##ModelId=4F7ACE9803B0Scheduler::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.
Rakesh sherwal 00711604411
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:-
Turn On
Add Details
Buy Ticket
Print Ticket
Display
Return Change
MachineCustomerManager
Sequence diagram:-
Rakesh sherwal 00711604411
Manager Machine Customer
1: Turn On
2: Add Details3: Display
4: Buy Ticket
5: Return Change
Use Case Description1. Turn On
Brief Description
This use case would be used by theatre manager everyday in order to turn on the machine
Rakesh sherwal 00711604411
Actors Manager, Machine
Flow of Events
Theatre manager turns on the machine.
Alternative Flow None
Precondition None
Post condition The machine is ready for adding details.
2. Add Details
Brief Description
This use case would be used by theatre manager every day in order to enter the movie details
Actors Manager, Machine
Flow of Events
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.
Alternative Flow None
Precondition Turn on machine
Post condition The machine is ready for issuing tickets.
2. Buy Ticket
Brief Description
This use case would be used by the customer to buy the movie ticket
Actors CustomerFlow of Events
1. CHECK INFORMATIONThe 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 INFORMATIONThe customer enters the number of tickets he wants to
Rakesh sherwal 00711604411
buy in the ‘Number of Tickets’ field.
3. MAKE PAYMENTSThe customer deposits the amount in the respective slot. The system counts the money deposited and updates the ‘balance amount’ field.
4. PRESS BUY BUTTONThe customer presses the ‘Buy’ button. The machine dispenses the printed tickets which are collected by the customer.
Alternative Flow
1. Insufficient money
This step is initiated at the basic step ‘PRESS BUY 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 Updated details in machine
Post condition Update Machine
4. Display
Brief This use case would be used by machine to display the
Rakesh sherwal 00711604411
Description details to the customerActors Machine
Flow of Events
1. Customer walks up
2. See the name of the movie, the time and the ticket price displayed
Alternative Flow None
Precondition Add details by Manager
Post condition None
5. Return Change
Brief Description
Customer initiates this use case to collect the money unspent by him.
Actors Machine, Customer
Flow of Events
PRESS ‘RETURN CHANGE’ BUTTONThe customer presses the ‘RETURN CHANGE’ button. The machine dispenses out the balance amount.
Alternative Flow None
Precondition Some balance amount is left
Post condition None
6. Print Ticket
Brief Description
This use case is included with the BUY TICKET use case to print the ticket.
Actors Customer, Machine (Secondary Actor)Flow of Events Customer buys the ticket and takes its print.
Alternative Flow None
Precondition Buy Ticket
Post condition 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.
Rakesh sherwal 00711604411
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:-
manager manager interface movie ticket machine ticket slot
money slot
printer
movie print
customer
Class Diagram
Rakesh sherwal 00711604411
CustomerNamePhone
Buy_Ticket()
ManagerName : String
Turn_On()Add_Details()
Machine
Dispaly()Return_Change()
*1 *111 11
Operates
Code:For customer class:#include "Customer.h"
//##ModelId=4F7830DE037DCustomer::Buy_Ticket(){}
For machine class:
#include "Machine.h"
//##ModelId=4F7830BA02ABMachine::Dispaly(){}//##ModelId=4F7830BE0175Machine::Return_Change(){}
For manager class:
#include "Manager.h"//##ModelId=4F78308A00FDManager::Turn_On(){}
//##ModelId=4F783091016BManager::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.
Rakesh sherwal 00711604411
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
This use case describes how a user login to the Email System
Actors Sender, Receiver
Flow of Events
1. Enter user id
2. Enter password
3. LoginAlternative Flow None
Precondition Sender/Receiver must have an account
Rakesh sherwal 00711604411
Post condition
If the use case was successful the actor is logged in to the system. If not, the system state is unchanged.
2. Send Email
Brief Description This use case enables the sender to send an email
Actors Sender
Flow of Events
1. Log in
2. Write mail
3. Send mailAlternative Flow None
Precondition Sender must log inPost condition Save sent mail
3. Get Email
Brief Description This use case enables the receiver to receive the email
Actors Receiver
Flow of Events
1. Log in
2. Check email
3. Receive mailAlternative Flow None
Precondition1. Receiver must login2. Sender must send mail
Post condition Save mail/ Delete mail/ Reply
4. Add Contacts
Brief Description
This use case enables the receiver/sender to add new contacts
Rakesh sherwal 00711604411
Actors Receiver, Sender
Flow of Events
1. Log in
2. Add Name
3. Add email idAlternative Flow If contact already exist, modify
Precondition Login
Post condition Save contact
5. LogOut
Brief Description
This use case enables the receiver/sender log out from the system after use
Actors Receiver, Sender
Flow of Events
1. Log in
2. Add contact/ send/receive email
3. Log outAlternative Flow None
Precondition Login
Post condition Close system
6. Print
Brief Description Use case extended by Get Email, used to print the mail
Actors Receiver
Flow of Events
1. Log in
2. Get mail
3. Print mailAlternative Flow None
Precondition Get mail
Post condition None
Rakesh sherwal 00711604411
Class Diagram of Computer Email SystemSenderName : StringID : StringPassword : String
LogIn()LogOut()SendMail()AddContacts()
ReceiverNameIDPassword
LogIn()LogOut()ReceiveMail()AddContacts()
** **
Sends Mail
EmailSubject : StringTime : StringComposingDate : DateSender : StringReceiver : String
Code:
For sender class:
#include "Sender.h"//##ModelId=4F78328501EDSender::LogIn(){}
//##ModelId=4F78328900DFSender::LogOut(){}
//##ModelId=4F78328C01F7Sender::SendMail(){}
//##ModelId=4F783292023DSender::AddContacts(){}
For receiver class:
Rakesh sherwal 00711604411
#include "Receiver.h"//##ModelId=4F7832E60175Receiver::LogIn(){}
//##ModelId=4F7832EA003FReceiver::LogOut(){}
//##ModelId=4F7832ED0319Receiver::ReceiveMail(){}
//##ModelId=4F7832F3000DReceiver::AddContacts(){}
For email class:#include "Email.h"
State Diagram of Computer Email System
LogIn
Add Contacts
Send Email
Get Email
Logout
Q10) Consider a software system for supporting a Public Library I. Identify actors for Library System. Explain the relevance of each actor.
Rakesh sherwal 00711604411
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:-
Use Case1
Use Case Name LoginObjective This will allow users to login the systemActors Operator and Librarian Pre-Conditions All users must have user name and password created for
them in the system prior to use casePost-conditions If use case got successful then users are logged on to the
system else system state is unchangedFlow of Events This use case starts when the actor wishes to login
Rakesh sherwal 00711604411
1. The system requests that the actors enter their username, password2. The actors enter their username, password3. The system validates the entered username, password and logs actor into the system.
Alternative Flow
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
Use Case 2Use Case Name Maintain Student DetailObjective This will allow maintenance regarding studentsActors Operator Pre-Conditions 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 facilityHere while all student activities are tracked.
Alternative Flow
None
Use Case 3Use Case Name Issue BookObjective To issue book to userActors Operator and bar code readerPre-Conditions Book must be available and student record should met the
rules to be followedPost-conditions If everything goes right book is issued to the student else
book is not issuedFlow 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
Alternative Book is not issued
Rakesh sherwal 00711604411
Flow
Use Case 4Use Case Name Return BookObjective This will allow student to return book back to the libraryActors Operator and bar code readerPre-Conditions Student must have the book to be returnedPost-conditions Book is returned to the library
Flow of Events 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
Alternative Flow
None
Use Case 5Use Case Name Maintain catalogueObjective This will allow all the activities in the library to be loggedActors Operator Pre-Conditions NonePost-conditions Every activity is logged
Flow of Events This use case starts when anything(book issue\return ,report generation, login etc) happens
Alternative Flow
None
Use Case 6Use Case Name Query BookObjective This will allow student to query about book from the
libraryActors Operator and UserPre-Conditions None
Rakesh sherwal 00711604411
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
Use Case 7Use Case Name Generate reportObjective Report generationActors LibrarianPre-Conditions NonePost-conditions Report is formed
Flow of Events 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
Alternative Flow
None
Class Diagram:-
Rakesh sherwal 00711604411
Code:
#include "Admin.h"
//##ModelId=4F7A74800186Admin::Manages Library(){}#ifndef ADMIN_H_HEADER_INCLUDED_B08516B5#define ADMIN_H_HEADER_INCLUDED_B08516B5
//##ModelId=4F7A747201D4class Admin{ public: //##ModelId=4F7A74800186 Manages Library();
private: //##ModelId=4F7A7477002E
Rakesh sherwal 00711604411
ID; //##ModelId=4F7A747A0280 Name;};
#endif /* ADMIN_H_HEADER_INCLUDED_B08516B5 */#ifndef ARTICLES_H_HEADER_INCLUDED_B085108E#define ARTICLES_H_HEADER_INCLUDED_B085108E
//##ModelId=4F7A75040119class articles : public Item{};#endif /* ARTICLES_H_HEADER_INCLUDED_B085108E */#ifndef BOOKS_H_HEADER_INCLUDED_B0854E36#define BOOKS_H_HEADER_INCLUDED_B0854E36//##ModelId=4F7A74FF0242class books : public Item{};#endif /* BOOKS_H_HEADER_INCLUDED_B0854E36 */#ifndef FACULTY_H_HEADER_INCLUDED_B0851E4D#define FACULTY_H_HEADER_INCLUDED_B0851E4D
//##ModelId=4F7A7583037Aclass faculty : public Lib_user{};#endif /* FACULTY_H_HEADER_INCLUDED_B0851E4D */#ifndef ITEM_H_HEADER_INCLUDED_B0851A6E#define ITEM_H_HEADER_INCLUDED_B0851A6E//##ModelId=4F7A74E400FAclass Item{ //##ModelId=4F7A74E90203 ID; //##ModelId=4F7A74F00222 Title; //##ModelId=4F7A74F40280 Author;};#endif /* ITEM_H_HEADER_INCLUDED_B0851A6E */#include "Lib_user.h"
Rakesh sherwal 00711604411
//##ModelId=4F7A7534009CLib_user::take books(){}//##ModelId=4F7A753A0167Lib_user::payfine(){}//##ModelId=4F7A753D001FLib_user::returnbook(){}#ifndef LIB_USER_H_HEADER_INCLUDED_B0856AD8#define LIB_USER_H_HEADER_INCLUDED_B0856AD8//##ModelId=4F7A750D032Cclass 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=4F7A74C003A9Librarian::Issuebooks(){}//##ModelId=4F7A74C9037ALibrarian::renewal(){}
//##ModelId=4F7A74CF0167
Rakesh sherwal 00711604411
Librarian::collectfine(){}//##ModelId=4F7A74D9003ELibrarian::collect books(){}#ifndef LIBRARIAN_H_HEADER_INCLUDED_B0855943#define LIBRARIAN_H_HEADER_INCLUDED_B0855943//##ModelId=4F7A749100EAclass 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=4F7A745500DALibrary::Issue code(){}//##ModelId=4F7A7459037ALibrary::Main books(){}//##ModelId=4F7A746203B9Library::Details(){}#ifndef LIBRARY_H_HEADER_INCLUDED_B0851458
Rakesh sherwal 00711604411
#define LIBRARY_H_HEADER_INCLUDED_B0851458//##ModelId=4F7A7432038Aclass 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=4F7A756400EAoperation::issue(){}//##ModelId=4F7A756600FAoperation::renewal(){}//##ModelId=4F7A756A00BBoperation::return(){}//##ModelId=4F7A756C004Eoperation::fine(){}#ifndef OPERATION_H_HEADER_INCLUDED_B085323E#define OPERATION_H_HEADER_INCLUDED_B085323E//##ModelId=4F7A755500CBclass operation{ public: //##ModelId=4F7A756400EA issue();
Rakesh sherwal 00711604411
//##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=4F7A75C40109class Student : public Lib_user{};#endif /* STUDENT_H_HEADER_INCLUDED_B0851C73 */
State transition diagram:-
Q11) Following requirements are for a product purchase system:
Rakesh sherwal 00711604411
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 walk-in 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 1Use Case Name Run Inventory ReportObjective This is done for getting information about the available
inventory
Rakesh sherwal 00711604411
Actors AdministratorPre-Conditions Inventory information mus be available on the diskPost-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
Alternative Flow
None
Use Case 2Use Case Name UpdateObjective This is done for updating information regarding inventoryActors AdministratorPre-Conditions Inventory information mus be available on the disk to be
updatedPost-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
Alternative Flow
None
Use Case 3Use Case Name LoadsObjective This is done for getting data from the diskActors NonePre-Conditions Data must be available in the diskPost-conditions Data is loaded from the disk
Flow of Events This use case starts when the one wishes to have the inventory information, this initiates the work of loading information from the disk
Alternative None
Rakesh sherwal 00711604411
Flow
Use Case 4Use Case Name saveObjective This is done for saving information about the available
inventoryActors NonePre-Conditions NonePost-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 pre-loaded data and saving it back to the disk
Alternative Flow
None
Use Case 5Use Case Name Make a saleObjective This comes into picture when there is sale for some
productActors AdministratorPre-Conditions Product must be available for the salePost-conditions Product is sold and regarding changes are reflected to the
data on the diskFlow 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 6Use Case Name Make phone order saleObjective This is done for selling product by taking order on the
Rakesh sherwal 00711604411
phoneActors Telephone OperatorPre-Conditions Product must be available for the salePost-conditions Product is sold and regarding changes are reflected to the
data on the diskFlow 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 7Use Case Name Make walkin saleObjective This is done for selling product Actors Sales ClerkPre-Conditions Product must be available for the salePost-conditions Product is sold and regarding changes are reflected to the
data on the diskFlow 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 8Use Case Name PurchaseObjective This is used when some product is purchasedActors AdministratorPre-Conditions Product must be available for the purchasePost-conditions If payment made successfully product is purchased else
notFlow of Events 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
Alternative Product is not purchased
Rakesh sherwal 00711604411
Flow
Use Case 9Use Case Name Credit cardObjective this is used when chosen mode of payment is credit cardActors NonePre-Conditions Credit card must be available with the purchaserPost-conditions Payment done via credit card
Flow of Events This use case starts when the one wishes to pay by credit card if all the rules are followed then payment is done
Alternative Flow
Payment not done
Use Case 10Use Case Name Cheque PurchaseObjective this is used when chosen mode of payment is chequeActors NonePre-Conditions Cheque must be available with the purchaserPost-conditions Payment done via cheque
Flow of Events This use case starts when the one wishes to pay by cheque if all the rules are followed then payment is done
Alternative Flow
Payment not done
Use Case 11Use Case Name VerifiesObjective this is used when either payment mode is to be verified
against the predefined normsActors NonePre-Conditions None
Rakesh sherwal 00711604411
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
View Flight Details
Reserve Ticket
Passenger
Cancel Ticket
LogIn
Maintain Flight Details
Reservation Clerk
Generate Report
<<include>>
Use Case Description
1. LogIn
Brief Description
This use case describes how a user logs into the “Airlines Booking System”.
Actors Reservation Clerk
Flow of Events
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 basic flow or cancel the login, at which point the use case
Rakesh sherwal 00711604411
ends.
PreconditionUser must have a username, password, and role, created for them in the system, prior to the use case.
Post condition
If the use case was successful the actor is logged into the system. If not, the system state is unchanged.
2. Maintain Flight Details
Brief Description
This use case allows the clerk to maintain flight information. This includes adding and updating flight information.
Actors Reservation Clerk
Flow of Events
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.
Alternative Flow
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.
PreconditionThe clerk must log into the system (authorized login) before this use case begins.
Post condition
If the use case was successful, the flight information is added or updated from the system. Otherwise, the system state is unchanged.
3. View Flight Details
Brief Description
This use case allows the passenger to view flight information.
Actors Passenger
Flow of Events
This use case starts when the passenger wants to book the tickets and he views all the flight details before booking.
Alternative Flow None
Rakesh sherwal 00711604411
Precondition Maintain Flight details by the clerk
Post condition Book required flight ticket.
4. Reserve Ticket
Brief Description
This use case allows the passenger to reserve or book the flight ticket
Actors Passenger
Flow of Events
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 travelAlternative Flow If no seats available, booking cancelled
Precondition View Flight details
Post condition Booking successful
5. Cancel Ticket
Brief Description
This use case allows the passenger to cancel the booked tickets.
Actors Passenger
Flow of Events
This use case starts when the passenger wants to cancel the tickets.
1. Enters details
2. CancelAlternative Flow If date and time of cancelling passed, cancelling no allowed
Precondition Ticket booked
Post condition Refund money
Rakesh sherwal 00711604411
6. Generate Report
Brief Description
This use case allows the clerk to generate report of flight and passenger details.
Actors Reservation Clerk
Flow of Events
This use case starts when the clerk want to generate reports of the flights
1. Enter flight details
2. Enter passenger details
3. Maintain recordsAlternative Flow None
Precondition Updated System
Post condition Print reports
7. Print
Brief Description
This use case is included with the GENERATE REPORT use case to print the ticket.
Actors Reservation ClerkFlow of Events Clerk generates report and takes its print if required.
Alternative Flow None
Precondition Generate ReportPost condition None
Rakesh sherwal 00711604411
Class Diagram :-
PassengerName : StringAge : IntegerPhone : IntegerAddress : String
Reserve Ticket()Cancel Ticket()View Details()
Reservation ClerkName : StringID : StringPwd : String
AddDetails()GenerateReport()
1 *
FlightF_No : StringName : StringTime : StringDate : DateNoOfSeats : Integer
1
*
1 *
**
Deals With
1 *
*
*
Books
Code:-
For flight class:#include "Flight.h"
For passenger class:
#include "Passenger.h"
//##ModelId=4F7869A1004APassenger::Reserve Ticket(){}
//##ModelId=4F7869AA0072Passenger::Cancel Ticket(){}
//##ModelId=4F7869AF0202Passenger::View Details(){}
Rakesh sherwal 00711604411
For reservation class:
#include "Reservation Clerk.h"
//##ModelId=4F7869D402A3Reservation Clerk::AddDetails(){}
//##ModelId=4F7869DE01E5Reservation Clerk::GenerateReport(){}
State Diagram
Rakesh sherwal 00711604411
LogIn Add Flight Details
View Flight Details
Reserve Ticket
Generate Report
Q13) 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
Rakesh sherwal 00711604411
Use Case 1Use Case Name
Record Grade
Objective This helps to store grades of the studentActors TeacherPre-Conditions
None
Post-conditions
Grades are stored on the disk
Flow of Events
This use case starts when the teacher wishes to record the grades of the students , for doing so data is saved to the disk
Alternative Flow
None
Use Case 2Use Case Name
Save to disk
Objective This helps to store data on the diskActors NonePre-Conditions
Data is present to be saved
Post-conditions
Data is saved
Flow of Events
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 3Use Case Name
Load Grades
Rakesh sherwal 00711604411
Objective This loads data ffrom the diskActors NonePre-Conditions
Data is present to be restored
Post-conditions
Data is loaded in the memory from the disk
Flow of Events
This use case starts when there is data to be restored from the disk , after loading the data use case terminates
Alternative Flow
None
Use Case 4Use Case Name
Update
Objective This helps to update grades of the studentsActor NonePre-Conditions
Data is present to be updated
Post-conditions
Data is updated
Flow of Events
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
Alternative Flow
None
Use Case 5Use Case Name
View Grades
Objective This helps to get information of grades of the studentsActors Student, Teacher and RegistrarPre-Conditions
Grades must be available to be looked
Post-conditions
Grades are provided
Rakesh sherwal 00711604411
Flow of Events
This use case starts when one wants to look grades , for doing so disk is accessed and provided to intended user
Alternative Flow
None
Use Case 6Use Case Name
Login
Objective This will allow users to login the systemActors Student, Teacher and RegistrarPre-Conditions
All users must have user name and password created for 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 login1. The system requests that the actors enter their username, password2. The actors enter their username, password3. The system validates the entered username, password and logs actor into the system.
Alternative Flow
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
Use Case 7Use Case Name
Generate report
Objective This is used for report generationActors RegistrarPre-Conditions
Grades must be available
Post-conditions
Report is generated
Flow of Events
This use case starts when one wants to see the report, for doing so disk is accessed and report is generated
Rakesh sherwal 00711604411
Use Case 8Use Case Name
Distribute report
Objective This is used for report distributionActors TeacherPre-Conditions
Grades must be available
Post-conditions
Report is distributed
Flow of Events
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
student name enrollment no batchsubjects diskdisk interface
passwordusername
view grades
teacher
record grades
update grades
teacher interface
student
student interfacedistribute report card
ragistar
log in
generate report card
ragistar interface
Class diagram:-
teacher
namesubjectsqualification
record grades()update grades()view greades()distribute report card()
student
nameroll nobatchusernamepassword
view grades()login()logout()
*
11
*login system
usernamepassword
login()logout()authentication failed()registar
nameusernamepassworddept
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
Sol:-Use Case Diagram:-
Use Case Description
1.Log In
Brief Description
The Login use case is used by Student, Professor and Registrar to allow the actor to initiate other use cases.
Actors Primary Actors - Student, Professor, Registrar
Rakesh sherwal 00711604411
Secondary Actors - None
Flow of Events
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.
Alternative Flow
WRONG USERNAME/PASSWORD
At basic flow step CHECK USERNAME/PASSWORD, the user enters either an inexistent username or the password for the username entered doesn’t match. The system then displays a message “The username or password is incorrect. Please try again.”
The use case resumes at LOGIN PROMPT.
PreconditionUser must have a username, password, and role, created for them in the system, prior to the use case.
Post condition
If the use case was successful the actor is logged into the system. If not, the system state is unchanged.
2. Maintain schedule
Brief Description
The Maintain Schedule use case is used by a student to register for a semester. Students select 4 primary courses and 2 alternate courses.
ActorsPrimary Actors - Student
Secondary Actors – Billing System
Rakesh sherwal 00711604411
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.
Alternative Flow
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.
Precondition The user has logged in as a Student.
Post condition
The student has registered for the semester.
3. Maintain Curriculum
Brief Description
The use case “Maintain Curriculum” is used by Registrar to setup the course offerings for the semester.
ActorsPrimary Actors - Registrar
Secondary Actors - None
Flow of Events
1. DISPLAY AVAILABLE COURSES.The system displays the available course offerings to the Registrar.
Rakesh sherwal 00711604411
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.
Alternative Flow
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.
Precondition The user is logged in as Registrar.
Post condition
The courses offered in the semester are published.
4. Request Course Roster
Brief Description
The Request Course Roster is initiated by Professor to get his/her course schedule.
ActorsPrimary 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.
Alternative Flow
None.
Rakesh sherwal 00711604411
Precondition The user is logged in as professor
Post condition
The logged in Professor is provided with his/her course schedule.
Sequence Diagram:-1. Login
2. Maintain schedule
Rakesh sherwal 00711604411
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
Rakesh sherwal 00711604411
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
The Process is started by the Customer.
ActorsPrimary Actors - Customer
Secondary Actors - None
Flow of Events
1. Enter the details of requirements.
2. Availability Status will be checked.
Rakesh sherwal 00711604411
3. Then registration will be complete.
Alternative Flow
none
Precondition Authenticated Customer
Post condition none
2. Extra services
Brief Description
Extra Services which the customer may want. Like invitation printing & distribution, additional seats, food management.
ActorsPrimary Actors - Customer
Secondary Actors - None
Flow of Events
1 Enter the details of requirements.
2 Availability Status will be checked.
3 Staff will be informed.
Alternative Flow
none
Precondition Authenticated Customer
Post condition none
3. Extended Organization Services
Brief Description
Extra Organisational work to be done in order to fulfill the extra services.
Actors Primary Actors - Customer
Secondary Actors - None
Rakesh sherwal 00711604411
Flow of Events
Orders are given to the staff.
Alternative Flow
none
Precondition Extra Services are demanded by the customer
Post condition none
4. Budget Preparation
Brief Description
Bill is prepared by the administrator.
ActorsPrimary Actors - Customer
Secondary Actors - None
Flow of Events
Bill is made according to the details of requirements.
Alternative Flow
none
Precondition Authenticated Customer
Post condition none
5. Payment
Brief Description
Customer pays 20% of the bill in advance.
ActorsPrimary Actors - Customer
Secondary Actors - None
Flow of Events
Online Payment Takes place.
Alternative Flow
none
Rakesh sherwal 00711604411
Precondition Registered Customer
Post condition none
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
Brief Description
This use case describes how a user logs into the Course Registration System.
Actors Student, professor & register.
Flow of Events
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.
Rakesh sherwal 00711604411
Alternative Flow
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.
Precondition none
Post condition
If the use case was successful, the actor is now logged into the system. If not, the system state is unchanged.
2. Registration for course
Brief Description
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.
Actors Student
Flow of Events
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. If the Student selected “Create a
Rakesh sherwal 00711604411
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.
Alternative Flow
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.
PreconditionThe Student must be logged onto the system before this use case begins.
Post condition
If the use case was successful, the student schedule is created, updated, or deleted. Otherwise, the system state is unchanged.
3. View report card
Brief Description
This use case allows a Student to view his/her report card for the previously completed semester.
Actors Student
Flow of Events
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.
Rakesh sherwal 00711604411
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.
PreconditionThe Student must be logged onto the system before this use case begins.
Post condition
The system state is unchanged by this use case.
4. Maintain Student Information
Brief Description
This use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying, and deleting Students from the system.
Actors Registrar
Flow of Events
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)
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.
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.
PreconditionThe Registrar must be logged onto the system before this use case begins.
Post condition
If the use case was successful, the student information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.
5. Maintain Professor Information
Brief Description
This use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system
Actors Registrar
Flow of Events
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.
Rakesh sherwal 00711604411
PreconditionThe Student must be logged onto the system 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
Brief Description
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.
Actors proffessor
Flow of Events
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).
Rakesh sherwal 00711604411
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.
PreconditionThe Student must be logged onto the system 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.
7. Submit Grades
Brief Description
This use case allows a Professor to submit student grades for one or more classes completed in the previous semester.
Actors Professor, student
Flow of Events
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 student’s 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
Rakesh sherwal 00711604411
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.
PreconditionThe Student must be logged onto the system 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.
8. Close Registration
Brief Description
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.
Actors Registrar
Flow of Events
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.
Rakesh sherwal 00711604411
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 schedule’s 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.
Alternative Flow
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.
PreconditionThe Student must be logged onto the system 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.
Generate Fees Receipt
Brief Description
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
Actors Registrar
Rakesh sherwal 00711604411
Flow of Events
This use case starts when the Registrar requests that the system generates fees receipt.
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.
Alternative Flow
There is no student enrolment number, the system will cancel the receipt generation.
PreconditionThe Student must be logged onto the system 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.
Analysis model:-
4 primary choice2 alternative choice
choosen by min 15 student
choosen by min 15 student
less then minimum
internal assignment
viewed grades
maintains fee
systemperformance of student is
recordedsystem interfce
professor
offer course
cancel course
student
register for course
view course
change course login
submit course
student inetrface
professor interface
attend the course
Rakesh sherwal 00711604411
Activity diagram:-
Student professor course system
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 latter’s 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.
Rakesh sherwal 00711604411
view course
register for course
2 alternative choice
2 alternative choice
change course
performance
thier assignment
internal assignment
attend the course
offer course
do 4 course
submit
15 student<
course offer
course cancel
recored
view grades
maintains fee details
systemcourseprofessorstudent
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 1
Use Case Name
Register
Objective A user can register with the site. On doing so, he is connected with all other registered users of this site.
Rakesh sherwal 00711604411
Actors User
Pre-Conditions
User must be available to the network
Post-conditions
To become registered user
Flow of Events
This use case starts when the one wishes to become registered user.
Alternative Events
Not registered user.
Use Case 2
Use Case Name
Search
Objective To begin networking, he must search for names through a general search.
Actors Registered User
Pre-Conditions
To search the friend
Post-conditions
He can select a particular user and invite him to become a friend.
Flow of Events
This use case starts when the one wishes to search the person on site.
Alternative Events
Search not done.
Use Case 3Use Case Name
Friend Request
Objective On acceptance of the request, the latter’s record will be visible in the Friends List of the user
Actors Registered userPre-Conditions
User must be registered.
Post-conditions
Can send and receive messages.
Flow of Events
This use case starts when the one wishes to make friends.
Alternative Events
Do not want to make friends.
Rakesh sherwal 00711604411
Use Case 4
Use Case Name
Delete photo
Objective Delete previously uploaded photographs
Actors registered user
Pre-Conditions
Photographs must be there.
Post-conditions
None
Flow of Events
This use case starts when the one wishes to delete photographs
Alternative Events
Photographs not deleted.
Use Case 5
Use Case Name
Upload Photo
Objective A registered user can upload his photographs
Actors registered user
Pre-Conditions
None
Post-conditions
Photographs must be present
Flow of Events
This use case starts when the one wishes to upload photographs
Alternative Events
Photographs not uploaded.
Use Case 6
Use Case Name
Receive Message
Objective The user can receive messages
Rakesh sherwal 00711604411
Actors Registered User
Pre-Conditions
Message must be there to receive.
Post-conditions
Message must be received.
Flow of Events
This use case starts when the one wishes to receive a message.
Alternative Events
Message not received.
Use Case 7
Use Case Name
Send Message
Objective The user can send messages
Actors Registered User
Pre-Conditions
Message must be there to send.
Post-conditions
Message must be sent.
Flow of Events
This use case starts when the one wishes to send a message.
Alternative Events
Message not sent.
Use Case 8
Use Case Name
Private message
Objective a private message will be visible only to the authenticated registered user
Actors Registered user.
Pre-Conditions
Message must be there to send/receive
Post-conditions
Message must be sent/received
Rakesh sherwal 00711604411
Flow of Events
This use case starts when the one wishes to send/receive a message.
Alternative Events
Message not sent/received.
Use Case 9Use Case Name
Public Message
Objective A public message, when sent, will be visible to all the registered users browsing the public message list
Actors Registered userPre-Conditions
Message must be there to send/receive
Post-conditions
Message must be sent/received
Flow of Events
This use case starts when the one wishes to send/receive a message.
Alternative Events
Message not sent/received.
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 1
Use Case Name
Car Tracking
Objective keeping track of availability of cars
Actors Rental Agency
Pre-Conditions
Cars must be available to the agency
Post-conditions
Record the track
Flow of Events
This use case starts when the one wishes to check the avaibality of cars
Alternative Track not maintained.
Rakesh sherwal 00711604411
Events
Use Case 3
Use Case Name
Car Returning
Objective Return a car.
Actors Customer,Rental Agency
Pre-Conditions
Cars must be available to the agency
Post-conditions
Maintain the record of returned car.
Flow of Events
This use case starts when the one wishes to record status of car.
Alternative Events
Record not maintained.
Use Case 4
Use Case Name
Billing
Objective To create the bill of rental cars
Actors Rental Agency, Customer
Pre-Conditions
Cars must be given to the customer
Post-conditions
Bills can be printed.
Flow of Events
This use case starts when the one wishes to create bills for issuances of rental cars.
Alternative Events
Bills not maintained.
Rakesh sherwal 00711604411
Use Case 7
Use Case Name
assignment
Objective assignment in case of chauffeur driver car rentals.
Actors Rental Agency
Pre-Conditions
Cars must be available to the agency
Post-conditions
Record the track
Flow of Events
This use case starts when the one wishes to assign in case chauffeur driver car rentals.
Rakesh sherwal 00711604411
Use Case 5
Use Case Name
Car Maintainece
Objective maintenance activities for cars
Actors Rental Agency
Pre-Conditions
Cars must be available to the agency
Post-conditions
Record the Activites
Flow of Events
This use case starts when the one wishes to maintenance activities for cars
Alternative Events
Maintenance not done.
Alternative Events
Assignment not made.
Use Case 8
Use Case Name
Print Bill
Objective To print the bill of rental cars
Actors Rental Agency, Customer
Pre-Conditions
Cars must be given to the customer and bill must be prepared
Post-conditions
Bill must be given to the customer
Flow of Events
This use case starts when the one wishes to print bills for rental cars.
Alternative Events
Bills not printed.
Use Case 6
Use Case Name
Drivers Track
Objective keeping track of drivers availability
Actors Rental Agency
Pre-Conditions
Cars must be available to the agency
Post-conditions
Record the track
Flow of Events
This use case starts when the one wishes to record the track of drivers
Rakesh sherwal 00711604411
Alternative Events
Track not maintained.
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