2008 09 OOMD Lab Manual
-
Upload
amit-sangale -
Category
Documents
-
view
114 -
download
0
Transcript of 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
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
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
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
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
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
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
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
Lab Manual
Testing:
(Input/ Output):
Use Case Diagram Elements
Use Case Diagram Connectors
Conclusion: Thus we have studied functional requirements of the system through the
usecase diagram
Assignment No. 3
9
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
Lab Manual
Testing:
(Input/ Output):
11
Lab Manual
Class Diagram Elements
Class Diagram Connectors
Conclusion: Thus we have studied to identify classes , attributes,operations and
relationships between them.
Assignment No. 4
Title of Assignment: Draw an advanced class diagram to depict advanced relationships,
other classifiers like interfaces.
12
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
Lab Manual
Testing:
(Input/ Output):
Class Diagram Elements
Class Diagram Connectors
14
Lab Manual
Conclusion: Thus we have studied advance relationships and notations in class
diagram.
Assignment No. 5
Title of Assignment: Draw one or more Package diagram to organize and manage your large and complex systems as well as complex models
Relevant Theory / Literature Survey: (Brief Theory Expected)
Package diagrams are used to reflect the organization of packages and their elements, and provide a visualization of their corresponding namespaces
15
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
Lab Manual
Conclusion: Thus we have studied how to organize packages and how to show
relationships between them.
Assignment No. 6
Title of Assignment: Draw activity diagrams to display either business flows or like flow charts
Relevant Theory / Literature Survey: (Brief Theory Expected)
Activity diagrams are used to model the behaviors of a system, and the way in which
17
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
Lab Manual
Testing:
(Input/ Output):
Activity Diagram
Activity Diagram
19
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
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
Lab Manual
Testing:
(Input/ Output):
Sequence Diagram Elements
Sequence Diagram Connectors
22
Lab Manual
Conclusion: Thus we have studied the sequence diagram and its advanced notation
(fragments).
Assignment No. 8
Title of Assignment: 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.
23
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
Lab Manual
Testing:
(Input/ Output):
25
Lab Manual
State Machine Diagram Elements
State Machine Diagram Connectors
Conclusion: Thus we have studied how to model behavior of single object using state
machine diagram.
Assignment No. 9
Title of Assignment: Draw component diagram assuming that you will build your
26
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
Lab Manual
Testing:
(Input/ Output):
Component Diagram Elements
Component Diagram Connectors
Conclusion: Thus we have studied how to identify components and how to show
dependencies between them.
28
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
Lab Manual
Testing:
(Input/ Output):
Deployment Diagram Elements
Deployment Diagram Connectors
Conclusion: Thus we have studied to deploy the system using deployment diagram
30
Lab Manual
31