2008 09 OOMD Lab Manual

40
Lab Manual Sr. No. Title of Assignment 1 Choose a System of sufficient complexity and write an SRS for the same. 2 Draw one or more Use Case Diagrams to capture and represent requirements of the system. 3 Draw basic class diagram to identify and describe key concepts like classes, types in your system and their relationships. 4 Draw advanced class diagram to depict advanced relationships, other classifiers like interfaces. 5 Draw one or more Package diagram to organize and manage your large and complex systems as well as complex models. 6 Draw activity diagrams to display either business flows or like flow charts. 7 Draw sequence diagram with advanced notation for your system to show objects and their message exchanges. 8 Draw state machine to model the behavior of single object, specifying the sequence of events that an object goes through during its lifetime in response to events. 9 Draw component diagram assuming that you will build your system reusing existing components along with a few ones. 10 Draw deployment diagram to model the runtime architecture of your system. Assignment No. 1 Title of Assignment: Choose a System and write Software Requirement Specification(SRS) for the same. 1

Transcript of 2008 09 OOMD Lab Manual

Page 1: 2008 09 OOMD Lab Manual

Lab Manual

Sr. No. Title of Assignment

1Choose a System of sufficient complexity and write an SRS for the same.

2Draw one or more Use Case Diagrams to capture and represent requirements of the system.

3Draw basic class diagram to identify and describe key concepts like classes, types in your system and their relationships.

4Draw advanced class diagram to depict advanced relationships, other classifiers like interfaces.

5Draw one or more Package diagram to organize and manage your large and complex systems as well as complex models.

6Draw activity diagrams to display either business flows or like flow charts.

7Draw sequence diagram with advanced notation for your system to show objects and their message exchanges.

8Draw state machine to model the behavior of single object, specifying the sequence of events that an object goes through during its lifetime in response to events.

9Draw component diagram assuming that you will build your system reusing existing components along with a few ones.

10Draw deployment diagram to model the runtime architecture of your system.

Assignment No. 1

Title of Assignment: Choose a System and write Software Requirement Specification(SRS) for the same.

Relevant Theory / Literature Survey: (Brief Theory Expected)

What is a Software Requirements Specification?

An SRS is basically an organization's understanding (in writing) of a customer or potential

client's system requirements and dependencies at a particular point in time (usually) prior to

any actual design or development work. It's a two-way insurance policy that assures that both

the client and the organization understand the other's requirements from that perspective at a

given point in time.

The IEEE 830 standard defines the benefits of a good SRS:

Establish the basis for agreement between the customers and the suppliers on what the

1

Page 2: 2008 09 OOMD Lab Manual

Lab Manual

software product is to do. The complete description of the functions to be performed by the

software specified in the SRS will assist the potential users to determine if the software

specified meets their needs or how the software must be modified to meet their needs

SRS contains functional and nonfunctional requirements only; it doesn't offer design

suggestions, possible solutions to technology or business issues, or any other information

other than what the development team understands the customer's system requirements to be.

What should the SRS address?

From the IEEE standard:The basic issues that the SRS writer(s) shall address are the following:

a) Functionality. What is the software supposed to do? b) External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software? c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.? d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations? e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

OPD System

I. Introductiona) Purpose : Design and development of an Outdoor Patient system.b) Scope : To automate the complete procedure of an OPD in a hospital by using client server architecture based application.c) Definition ,Acronymn, Abbreviation.

Dr. Doctor OPD : Outdoor patient Sys : System

d) Overview : An automated OPD system for a hospital with 200 beds and capacity to handle 300 OPD patients a day. It has 3 access points which are deployed at – the receptionist, the consultancy and the pharmacist end.

II. Specification Requirementa) Functional Requirement :

Name Introduction Input Processing Output

2

Page 3: 2008 09 OOMD Lab Manual

Lab Manual

REGISTRATION MENU

Registers the patient at the hospital.

Patient Id,Name of patient,Address,Telephone No

Register the patient in hospital database

Registrationreceipt

APPOINTMENTMENU

Tracks appointment detail of the document

Patient Id,Genere of disease (if known)

Search Doctor, Search freeTime & Date

Generate appointment report for the patient

CASE HISTORY MENU

Keeps track of case history of the patient

Patient Id,Diagnosis

Updation of case history

Case History

PATIENT’S MENU

Show details of patient to doctor

Patient Id, Diagnosis, Prescription

Update Case History

Generate Patient Report.

PHARMACIST’S MENU

Shows prescribed medicines to pharmacist , performs billing operation

Patient Id Billing Generate Bill

b) External Interface Requirement

Receptionista) New patient get himself registered in patient DB with unique identity number.b) Patient is given unique Patient ID, appointment details and

Information

Doctora) Using unique id, doc accesses case paper of patient.b) Diagnose patient for ailment & update case paper& gives Prescription.

c) Doc may refer to another Docd) Doc can access appointment DB

Pharmacya) Accesses the prescription made by Doctorb) Fills in the prices for the medicines & makes bill.

c) Performance Requirement

3

Page 4: 2008 09 OOMD Lab Manual

Lab Manual

Proper updates Correct billing and schedule Easy data retrieval

d) Design Construction In compliance with Standards Entry only by receptionist at time of admission of patient

e) Attribute In the appointments menu, receptionist solely updates the shedule.The doc

can only view his schedule Cons fee only taken by the receptionist and pharmacy bill paid only at the

pharmacy

f) Other requirement a) Database: Patient’s table,medicines table,doc schedule,paramedics table .

Requirement Analysis DocumentOut Patient System

a) The hospital caters to the following 200 beds 20 or more doctors 300 patients / day

b) When a patient gives his details to the receptionist, the latter performs the following activities:

1) If the patient has a history with the hospital his case is retrieved from the database Appropriate doctor is assigned Consultation fees is collected Bill is generated

2) If the patient is a first timer patient’s details are accepted He is registered with the hospital Patient is provided with an ID

4

Page 5: 2008 09 OOMD Lab Manual

Lab Manual

Appropriate doctor is assigned Consultation fees is collected Bill is generated

3) The paramedic in charge will enter the preliminary details of the patient such as height, weight etc.

4) The doctor has the following role to play get case paper review it (view history, if present) update it with the symptoms ,diagnosis,prescription and notes. Forward prescription with the patient id to the pharmacy

5) The pharmacist will get the prescription along with the patient id Issue appropriate medicines Generate Bill Collect money Print The Bill

Data Dictionary 1) Prescription.

Attribute Name Type Description

PID Numeric Foreign KeyMname String Medicine NameDosage NumericDuration NumericTdate DateTotaltablets NumericCost Numeric

2) Doctor Attribute Name Type Description

DID Numeric Primary KeyName StringSpecialization String

3) Patient Attribute Name Type Description

5

Page 6: 2008 09 OOMD Lab Manual

Lab Manual

PID Numeric Primary KeyName StringPhone NumericAge NumericGender CharacterAddress String

4) Case Paper Attribute Name Type Description

Tdate DateDiagnosis NumericDID Numeric Foreign KeyPID Numeric Foreign key

5)Bill Attribute Name Type Description

Amount NumericPID Numeric Foreign KeyBID Numeric Foreign Key

Testing: Not Applicable

(Input/ Output):

Conclusion: Thus characteristics and need of SRS are studied.

6

Page 7: 2008 09 OOMD Lab Manual

Lab Manual

Assignment No. 2

Title of Assignment: Draw one or more Use Case Diagrams for capturing and representing requirements of the system.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Use Case diagram captures use cases and actor interactions. It describes the functional requirements of the system, the manner that outside things (actors) interact at the system boundary and the response of the system. Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic.

"A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "

7

Page 8: 2008 09 OOMD Lab Manual

Lab Manual

A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play. The connection between actor and use case is a communication association (or communication for short).

Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases. A use case diagram is a collection of actors, use cases, and their communications. A single use case can have multiple actors.

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following figure shows use case diagram for the sales order system.It uses “include”

and “extends” stereotypes.

8

Page 10: 2008 09 OOMD Lab Manual

Lab Manual

Title of Assignment: Draw basic class diagram to identify and describe key concepts like classes, types in your system and their relationships.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact.

The Class diagram captures the logical structure of the system - the classes and things that make up the model. It is a static model, describing what exists and what attributes and behavior it has, rather than how something is done. Class diagrams are most useful to illustrate relationships between classes and interfaces. Generalizations, aggregations, and associations are all valuable in reflecting inheritance, composition or usage, and connections, respectively.UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Relationships between classes are the connecting links.Class diagram has three kinds of relationships.

association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.

aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole.Order has a collection of OrderDetails.

generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The class diagram below models a customer order from a retail catalog. The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.

10

Page 11: 2008 09 OOMD Lab Manual

Lab Manual

Testing:

(Input/ Output):

11

Page 13: 2008 09 OOMD Lab Manual

Lab Manual

Relevant Theory / Literature Survey: (Brief Theory Expected)

Class information: visibility and scopeThe class notation is a 3-piece rectangle with the class name, attributes, and operations. Attributes and operations can be labeled according to access and scope.

Static members are underlined. Instance members are not. The operations follow this form:

<access specifier> <name> ( <parameter list>) : <return type> The parameter list shows each parameter type preceded by a colon. Access specifiers appear in front of each member.

Symbol Access

+ public

- private

# protected

Example :

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram shows an advanced class diagram for shopping system.

13

Page 16: 2008 09 OOMD Lab Manual

Lab Manual

To simplify complex class diagrams, you can group classes into packages. A package is a collection of logically related UML elements. The diagram below is a business model in which the classes are grouped into packages.

Packages appear as rectangles with small tabs at the top. The package name is on the tab or inside the rectangle. The dotted arrows are dependencies. One package depends on another if changes in the other could possibly force changes in the first.

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The diagram below is a business model in which the classes are grouped into packages.

Testing:

(Input/ Output):

 

Package Diagram Elements 

 

Package Diagram Connectors 

16

Page 18: 2008 09 OOMD Lab Manual

Lab Manual

these behaviors are related in an overall flow of the system. The logical paths a process follows, based on various conditions, concurrent processing, data access, interruptions and other logical path distinctions, are all used to construct a process, system or procedure.

 An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram shows an activity diagram for sales system.

18

Page 19: 2008 09 OOMD Lab Manual

Lab Manual

Testing:

(Input/ Output):

  

Activity Diagram  

Activity Diagram

19

Page 20: 2008 09 OOMD Lab Manual

Lab Manual

Elements 

Connectors 

 

  

 

 

 

 

 

 

Conclusion: Thus we have studied how to represent activities and different notations

involved in an activity diagram.

Assignment No. 7

Title of Assignment: Draw a sequence diagram with advanced notation for your system to show objects and their message exchanges.

20

Page 21: 2008 09 OOMD Lab Manual

Lab Manual

Relevant Theory / Literature Survey: (Brief Theory Expected)

A sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence.A Sequence diagram is a structured representation of behavior as a series of sequential steps over time. It is used to depict work flow, message passing and how elements in general cooperate over time to achieve a result.

Each sequence element is arranged in a horizontal sequence, with messages passing back and forward between elements

An actor element may be used to represent the user initiating the flow of events Stereotyped elements, such as boundary, control and entity, may be used to

illustrate screens, controllers, and database items, respectively Each element has a dashed stem called a lifeline, where that element exists and

potentially takes part in the interactions

Sequence diagrams are commonly used as explanatory models for use case scenarios. By creating a sequence diagram with an actor and elements involved in the use case, you can model the sequence of steps the user and the system undertake to complete the required tasks. An element in a Sequence diagram is usually either an actor (the stimulus that starts the interaction) or collaborating elements.

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram shows the sequence diagram for scenario Withdraw money for

ATM System.

21

Page 22: 2008 09 OOMD Lab Manual

Lab Manual

Testing:

(Input/ Output):

  

Sequence Diagram Elements 

 

Sequence Diagram Connectors 

22

Page 24: 2008 09 OOMD Lab Manual

Lab Manual

Relevant Theory / Literature Survey: (Brief Theory Expected)

A State Machine diagram illustrates how an element, often a class, can move between states classifying its behavior, according to transition triggers, constraining guards and other aspects of State Machine diagrams that depict and explain movement and behavior.

A state represents a situation where some invariant condition holds; this condition can be static, ie. waiting for an event, or dynamic, ie. performing a set of activities. State modeling is usually related to classes, and describes the allowable states a class or element may be in and the transitions that allow the element to move there. There are three types of states: simple states, composite states and submachine states.

You can add a sub-machine element to a State Machine diagram. A sub-machine element is a pointer to a child State Machine diagram.

There are two types of history pseudo-states defined in UML, shallow and deep history. A shallow history sub-state is used to represent the most recently active sub-state of a composite state; this pseudo-state does not recurse into this sub-state's active configuration, should one exist. A single connector can be used to depict the default shallow history state, in case the composite state has never been entered.

 A deep history sub-state, in contrast, reflects the most recent active configuration of the composite state. This includes active sub-states of all regions, and recurses into those sub-states' active sub-states, should they exist. At most one deep history and one shallow history can dwell within a composite state

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram illustrates some features of State Machine diagrams. The Saved state is a composite state, and enclosed states are sub-states. Initial and final pseudo-states indicate the entry to and exit from the state machine.

24

Page 25: 2008 09 OOMD Lab Manual

Lab Manual

Testing:

(Input/ Output):

25

Page 27: 2008 09 OOMD Lab Manual

Lab Manual

system reusing existing components along with a few ones.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Component diagram illustrates the pieces of software, embedded controllers, etc. that will make up a system. A Component diagram has a higher level of abstraction than a Class diagram - usually a component is implemented by one or more classes (or objects) at runtime. They are building blocks, such that eventually a component can encompass a large portion of a system.

A component is a code module. Component diagrams are physical analogs of class diagram.

A component is a modular part of a system, whose behavior is defined by its provided and required interfaces; the internal workings of the component should be invisible and its usage environment-independent. Source code files, DLLs, Java beans and other artifacts defining the system may be manifested in components.

 A component may be composed of multiple classes, or components pieced together. As smaller components come together to create bigger components, the eventual system can be modeled, building-block style. By building the system in discrete components, localization of data and behavior allows for decreased dependency between classes and objects, providing a more robust and maintainable design.

Ports define the interaction between a classifier and its environment. Interfaces controlling this interaction can be depicted by using the expose interface toolbox element. Any connector to a port must provide the required interface, if defined. Ports can appear on either a contained part, a class, or on the boundary of a composite structure.

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

The following diagram shows component diagram for sales management system

27

Page 29: 2008 09 OOMD Lab Manual

Lab Manual

Assignment No. 10

Title of Assignment: Draw a deployment diagram to model the runtime architecture of your system.

Relevant Theory / Literature Survey: (Brief Theory Expected)

A Deployment diagram shows how and where the system will be deployed. Physical machines and processors are reflected as nodes, and the internal construction can be depicted by embedding nodes or artifacts. As artifacts are allocated to nodes to model the system's deployment, the allocation is guided by the use of deployment specifications.

Deployment diagrams show the physical configurations of software and hardware.

A deployment specification (spec) specifies parameters guiding deployment of an artifact, as is necessary with most hardware and software technologies. A specification lists those properties that must be defined for deployment to occur. An instance of this specification specifies the values for the parameters; a single specification can be instantiated for multiple artifacts.

 These specifications can be extended by certain component profiles. Examples of standard tagged values that a profile might add to a deployment specification are «concurrencyMode» with tagged values {thread, process, none} or «transactionMode» with tagged values {transaction, nestedTransaction, none}.

 

Design Analysis / Implementation Logic:(Algorithm / Flow Chart / Pseudo Code / UML diagram / DFD as per requirement)

Below is an example Deployment diagram. The two nodes have a TCP/IP communication path indicated. Deployment relationships indicate the deployment of artifacts. Furthermore, a deployment spec defines the process of deployment for the networkScanner artifact. The manifestation relationships reveals the physical implementation of components ReposCustomer and ReposInternalRecords.

  

29

Page 31: 2008 09 OOMD Lab Manual

Lab Manual

31