mohit OOAD_List of Practicals_MCA-IV Sem

Q1) Draw a Usecase Diagram, Activity Diagram, Analysis Model and Sequence Diagram (for each usecase). Write description of each use case for a Simple Answering Machine given below.

o Use Case: Leave a Message Actor: Caller Pre-Condition: Room on Tape Post-Condition: New Message o Use Case: Review

Messages Primary Path: Review New Messages Alternate Path: No New Messages o Actor: Owner

• Use Case: Review Messages Locally o Primary Path: Review New Messages o Alternate Path: No New Messages o Inherit:

Review Messages • Use Case: Review Messages Remotely o

Primary Path: Review New Messages o Alternate Path: No New Messages o Inherit:

Review Messages o Uses: Authorize Access • Use Case: Authorize Access o Primary

Path: User Authorized o Alternate Path: User Not Authorized

Sol:-

Use case diagram:-

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


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


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


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


Precondition None

Post condition None

Take caller message

Brief Description This sue case is used to record the caller’s message in the machine


Flow of EventsCaller calls the owner. Owners provides a message to be recorded. Machine records

the message


Precondition None

Post condition None.


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.


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


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


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


Precondition Message should be present

Post conditionnone


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


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


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


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


Flow of EventsCaller calls the owner. Owners provides a message to be recorded. Machine records

the message



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


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:


play();

private:

//##ModelId=4F7AE1EE01E4

string greeting;

};

#endif /* GREETING_H_HEADER_INCLUDED_B085664F */


#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"


speaker::play()

{

}

#ifndef SPEAKER_H_HEADER_INCLUDED_B0853B19

#define SPEAKER_H_HEADER_INCLUDED_B0853B19

//##ModelId=4F7AE318031C

class speaker

{

public:


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.


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


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


Precondition Product numbers must be enteredPost Information regarding product is displayed


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


Precondition Payment must be made

Post condition

None

3. Process An Order


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


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.



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.


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.



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 .


Precondition None


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.



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.




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.



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.



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


system.



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.



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.



None


Sequence diagram:-


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.


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



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.


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.


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


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.


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();


//##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


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


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{


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


Sol.:- Use case Diagram:-

restricted section

add question

add category

junior staff

add db

<<include>>senior staff

add survey

<<include>>

person

print

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


Precondition None


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


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


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


Precondition Content has to be sensitive

Post condition None

Class Diagram:-


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(){}


#include "SeniorStaff.h"

//##ModelId=4F7AAACA0272SeniorStaff::AddCategory(){}

//##ModelId=4F7AABBC0132SeniorStaff::AddQuestion(){}

#include "Staff.h"

//##ModelId=4F7AAA8D00C4Staff::AddQuestion(){}

//##ModelId=4F7AAAC20178Staff::AddCategory(){}

//##ModelId=4F7AAB210380Staff::Print(){}

Activity diagram:-


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.:


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


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


Precondition None


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



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.


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.


Precondition None

Post condition Medication is provided


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

print

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


#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


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.


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


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


Actors Manager, Machine

Flow of Events

Theatre manager turns on the machine.


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.


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


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


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


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.


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.


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.


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


Analysis model:-

manager manager interface movie ticket machine ticket slot

money slot

printer

movie print

customer

Class Diagram


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.


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.:


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


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


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


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:


#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.


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


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


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


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


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


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"


//##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


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


#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();


//##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:


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


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


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


phoneActors Telephone OperatorPre-Conditions Product must be available for the salePost-conditions Product is sold and regarding changes are reflected to the



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



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


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


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


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.:-


Print

View Flight Details

Reserve Ticket

Passenger

Cancel Ticket

LogIn

Maintain Flight Details

Reservation Clerk

Generate Report

<<include>>


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


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.


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.



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


6. Generate Report

Brief Description

This use case allows the clerk to generate report of flight and passenger details.


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.


Precondition Generate ReportPost condition None


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(){}


For reservation class:

#include "Reservation Clerk.h"

//##ModelId=4F7869D402A3Reservation Clerk::AddDetails(){}

//##ModelId=4F7869DE01E5Reservation Clerk::GenerateReport(){}

State Diagram


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


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


Load Grades


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


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


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


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


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


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



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


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


#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


{

//##ModelId=4F7AB442003E

string name;

//##ModelId=4F7AB4450251

string address;


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


#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;


string desciption;

};

#endif /* REGISTRAR_H_HEADER_INCLUDED_B08562A8 */

#include "report.h"

//##ModelId=4F7AB53D00CB

report::modify()

{

}

//##ModelId=4F7AB54000BB

report::optimize()

{


}

#ifndef REPORT_H_HEADER_INCLUDED_B0855F9D

#define REPORT_H_HEADER_INCLUDED_B0855F9D

//##ModelId=4F7AB51C030D

class report

{

public:


modify();

//##ModelId=4F7AB54000BB

optimize();

private:

//##ModelId=4F7AB52E00CB

int id;


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


#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()

{

}


Teacher::update()

{

}

//##ModelId=4F7AB4D700AB


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();


update();

//##ModelId=4F7AB4D700AB

viewgrade();

//##ModelId=4F7AB4DA00BB

login();

private:

//##ModelId=4F7AB4BE0167

int id;

//##ModelId=4F7AB4C0031C

string specialisation;

};

#endif /* TEACHER_H_HEADER_INCLUDED_B0855609 */


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


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


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


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


Flow of Events

1. DISPLAY AVAILABLE COURSES.The system displays the available course offerings to the Registrar.


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


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.


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


3. Maintain Curriculum

4. Request Course Roster


ANALYSIS MODEL:

Q15) Draw Usecase Diagram, Analysis Model and Class Diagram with Code Generation for ABC Business center discuss below. Write description of each usecase.

ABC Business center of the city is an event management company. It has 30 seminar rooms, 10 video-conference-meeting halls and 20 rooms meant for


interview. All the rooms and halls are equipped with necessary electronic items (computer, internet, teleconferencing, single gun projector) The organizations situated at various places of the country ca register for their company to conduct seminars, interviews and business meeting. The event registration form is filled online and the same is submitted. The event registration form is filled online and the same is submitted. The event registration system checks for the availability, and books the event. Some of the other services required by the organizations such as invitation printing and distribution, additional seats in the seminar hall, and food management can also be arranged upon request. It also promotes its management staff of customer care division to extend the organization services. Simulate the system to provide online booking and coordinate with other food and infrastructure arrangements. The budget is prepared and submitted to the organization for their acceptance. The organization, which utilizes the services, must pay 20% in advance. Advance amount is adjusted in the final bill.

Sol:-


1. Registration

Brief Description

The Process is started by the Customer.

ActorsPrimary Actors - Customer


Flow of Events

1. Enter the details of requirements.

2. Availability Status will be checked.


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.



Flow of Events

1 Enter the details of requirements.

2 Availability Status will be checked.

3 Staff will be informed.

Alternative Flow

none


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



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.



Flow of Events

Bill is made according to the details of requirements.

Alternative Flow

none


Post condition none

5. Payment

Brief Description

Customer pays 20% of the bill in advance.



Flow of Events

Online Payment Takes place.

Alternative Flow

none


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


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.


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


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.


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.


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.


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




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).


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.


Post condition


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


the grade for a student by entering a new grade.

Alternative Flow



Post condition


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.


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.


Post condition


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


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.


Post condition


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


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.


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


Friend Request/Request Acceptance/Rejection

Unfriend

Photo (Upload/Remove)


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.


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.


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.


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



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


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


Flow of Events

This use case starts when the one wishes to send/receive a message.

Alternative Events

Message not sent/received.


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.


Sol:-

State Transition Diagram:-

Analysis model:-


Class diagram:-


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.


Events

Use Case 3

Use Case Name

Car Returning

Objective Return a car.

Actors Customer,Rental Agency

Pre-Conditions


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.


Use Case 7

Use Case Name

assignment

Objective assignment in case of chauffeur driver car rentals.


Pre-Conditions


Post-conditions

Record the track

Flow of Events

This use case starts when the one wishes to assign in case chauffeur driver car rentals.


Use Case 5

Use Case Name

Car Maintainece

Objective maintenance activities for cars


Pre-Conditions


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


Pre-Conditions


Post-conditions

Record the track

Flow of Events

This use case starts when the one wishes to record the track of drivers


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


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



Documents

mohit OOAD_List of Practicals_MCA-IV Sem