Uml Lab Manual
Uml Lab Manual
Uml Lab Manual
Lab Manual
For STTP on Object Oriented Software Engineering
TEC,Nerul 1
STTP on OOSE LAB MANUAL
Resource Used:
1) Equipment:
UML tool.
2) Consumables:
Printer.
Theory:
Actors
Actors represent anyone or anything that interact with the system. An actor may
• Only input information to a system
• Only retrieve information from a system
• Both input and retrieve information to and from a system
Typically, the actors are found in the problem statement, and also from
conversation with the customers and domain experts.
There are three types of actors:
1. users of the system,
2. external application systems, and
3. external devices that can independently interact with the system.
Use cases:
Use cases eventually map to the menu option. Use cases represent the functionality
provided by the system. Each individual functionality provided by a system is
captured as a use case.
A use case thus represents a dialog between an actor and the system. A collection of
use cases for a system reflects all the defined ways in which a system can be used.
A use case can be defined as a sequence of transactions performed by a system, that
yields a measurable result of values for a particular actor.
TEC,Nerul 2
STTP on OOSE LAB MANUAL
User-x
Places Request
ServiceProvider
Security System
Maintanence
Agency
OperateSecurity System
TroubleShoot
Lights
OperateLights
OperateAC
STOREREQUEST
Various devices areconnectedtoHACS
InteractionDeviceandreceives the
instructions tobeimplemented.
AC
DATABASE
Actors:
TEC,Nerul 3
STTP on OOSE LAB MANUAL
1. User
2. Service Provider
3. Maintenance Agency
4. Interaction Device
5. Database
6. Lights
Use cases:
1. Places Request
2. Trouble Shoot
3. Send request to interaction devices
4. Store Request
5. Operate Light
Appendix:
1. Stereotype: Stereotypes defines a new model element in terms of another
model element. It is represented by <<stereotypes>>
2. System boundary boxes: We can draw a rectangle around the use cases,
called the System boundary box, to indicate the scope of your system.
3. Abstract use case: Use case, which is inherited, by some use case is called as
abstract use case.
4. Concrete use case: Use case, which is directly inherited by actor, is called as
concrete use case.
Conclusion:
TEC,Nerul 4
STTP on OOSE LAB MANUAL
Use cases define the behavior provided by the system. They are a
central theme for the entire development process. They play a role in a various
stages of the development process as follows:
• During requirements determination, they specify what the
system should do from the user’s point of view.
• During analysis and design, the use cases are realized in a
design model .Use case realizations describe the interaction between various
objects in the design model.
• During implementation, the design model becomes the
implementation specification.
• During testing, the use cases are the basis for identifying test
cases. The system is verified by performing each use case.
• As part of project management, they provide a basis for
planning the iterations.
TEC,Nerul 5
STTP on OOSE LAB MANUAL
Subject: OOSE
Recourses Used:
3) Equipment:
UML tool.
4) Consumables:
Printer.
Theory:
Class diagrams are perhaps the most commonly used diagrams in modeling object-
oriented systems.
A class diagram shows a set of classes and interfaces, and their relationship.
In an object-oriented system, no class can stand in a complete isolation from all the other
classes. Classes share various types of relationship with other classes. In fact, a system is
a collection of various collaborating classes. It is through collaboration between various
classes that a system can achieve its final goal.
A class diagram consists of some logically related classes and interfaces from some
aspects of a system, along with the relationship as well as collaborations between these
classes. The number of classes and interfaces in a non-trivial system is likely to be such
that a single diagram showing all classes and interfaces, and all their relationship, may
not be practical. We, therefore, make a number of classes diagrams, each diagram
representing some specific aspects of a structural relationships and collaborations
between classes. A class may appear in multiple class diagrams.
TEC,Nerul 6
STTP on OOSE LAB MANUAL
TEC,Nerul 7
STTP on OOSE LAB MANUAL
functions associated with this class are: opname(). It is used to send the details of
operation to be performed.
3. SERVICE PROVIDER: This class holds the details of users associated with
their unique PIN along with the services they can access. As this class holds all
the information of the users, we can say that this is the super class of USERS. The
functions associated with this class are: acceptreq(), reqPIN, acceptcmnd,
reporterror().
acceptreq() is used to process the request it receives for the access of a particular
HACS.
reqPIN() sends a request to the user for the PIN.
acceptcmnd processes the request for an operation sent by the user & forwards it
to the HACS Interaction Device.
reporterror() sends a message to the user that the requested task cannot be
performed.
4. HACS Interaction Device: This class holds the IDs for various appliances &
the command that can be processed for a particular device. The various functions
performed by this class are:
5.Lights Controller: This class holds the information of various lights at the
house. The functions it performs are switchON, switchOFF & returnstatus().
Analysis / Conclusion:
Class diagram fully describe the attributes and methods that exist for a class.
For each class that has significant temporal behavior, you can create an activity
diagram or a state chart diagram to describe this behavior.
TEC,Nerul 8
STTP on OOSE LAB MANUAL
Subject: OOSE
Recourses Used:
1) Equipment:
UML tool.
2) Consumables:
Printer.
Theory:
A sequence diagram shows a pattern of interaction among objects, emphasizing the
sequencing of messages. A message is the mechanism by which an object to execute a
certain responsibility.
Normally, we begin drawing a sequence diagram by placing the initiating actor at the left,
and subsequent classes or actors increasingly to the right. Linking the participating
objects or actors by line with an arrow shows a message. The message line originates
from the object or the actor who initiates the message and arrow points to the object or
the actor who is responsible for that message to be executed.
The message line should be labeled with a suitable description of the message being
passed. We can also specify the message.
Interaction between actors should not be shown in a sequence diagram. Since actors are
outside the system, any interaction between them is also outside the system, and therefore
should not be modeled
Sequence diagram demonstrate the behavior of objects in a use case by describing the
objects and the message they loss. The diagrams are read left to right and descending.
Example:The user request access to HACS. The service provider asks for PIN and
device ID. The user enters the information. Then service providers interact with the
interaction device, which checks the status of lights, and switches it according to the
request.
TEC,Nerul 9
STTP on OOSE LAB MANUAL
Reques ts for PIN & the device ID with the required operation
Enter the PIN with the ID of Lights & their required state.
Add Request
Update Request
Appendix:
• Asynchronous message:
The handler return immediately, but the actually work is done in the
background. The sender can move on to other tasks while processing goes
on.
• Synchronous message:
The sender waits until the handler completes (blocks). This is a normal
method call in a single threaded application.
TEC,Nerul 10
STTP on OOSE LAB MANUAL
• Balking:
The receiving object can refuse to accept the message request could
happen if an active objects message queue files.
• Time outs:
The message handler typically blocks, but will return after a
predetermined amount of time, even if the work of handler is not
complete.
Conclusion:
TEC,Nerul 11
STTP on OOSE LAB MANUAL
Subject: OOSE
5) Equipment:
UML tool.
6) Consumables:
Printer.
Theory:
A collaboration diagram is an alternative way of displaying the pattern of interaction
between various objects and actors in a use case. While a sequence diagram emphasizes
the sequencing of communication between objects, a collaboration diagram emphasizes
the organization of the objects participating in iteration.
Collaboration diagram can be used to show how objects in a system interact over multiple
use cases. Collaboration diagram are useful during the exploratory phases of a
development process. Since there is no explicit representation of time in Collaboration
Diagrams, the message are numbered to denote the sending order.
In a collaboration diagram, all interactions between any pair of objects/actors are shown
at the same level.
Collaboration diagram are also relatively easy to draw. They show the
relationship between objects and the order of message passed between them. The objects
are listed as icons and arrow indicates the message being passed between them. The
number next to the message is called sequence numbers. As the name suggests, they
show the sequence of the message as they are passed between the objects. There are
many acceptable sequence-numbering schemes in UML. A simple 1,2,3…format can be
used or for more detailed and complex diagrams a 1,1.1,1.2,1.2.1… schemes can be used.
Example:
The user request access to HACS . The service provider asks for PIN and device ID.
The user enters the information. Then service provider interact with the interaction
device, which checks the status of lights, and switches it according to the request.
TEC,Nerul 12
STTP on OOSE LAB MANUAL
Lights
8: Return Status
11: S end M ess age: (FA ILURE /S UCCE S S )
6: A dd Reques t
10: Switches the required lights according to the reques t. 12: Update Request
Database
Appendix:
TEC,Nerul 13
STTP on OOSE LAB MANUAL
Subject: OOSE
Recourses Used:
1) Equipment:
UML tool.
2) Consumables:
Printer.
Theory:
State chart diagrams model the dynamic behavior of individual classes or any
other kind of object. They show the sequences of states that an object goes through, the
events that cause a transition from one state to another, and the actions that result from a
state change.
State chart diagrams are closely related to activity diagrams. The main difference
between the two diagrams is state chart diagrams are state centric, while activity
diagrams are activity centric. A state chart diagram is typically used to model the
discrete stages of an object’s lifetime, whereas an activity diagram is better suited to
model the sequence of activities in a process.
Each state represents a named condition during the life of an object during which
it satisfies some condition or waits for some event. A state chart diagram typically
contains one start state and multiple end states. Transitions connect the various states on
the diagram. As with activity diagrams, decisions, synchronizations, and activities may
also appear on state chart diagrams.
State
Definition
A state represents a condition or situation during the life of an object during
which it satisfies some condition or waits for some event. Each state represents the
cumulative history of its behavior.
Graphical Depiction
The state icon appears as a rectangle with rounded corners and a name (Wait). It
also contains a compartment for actions:
NewState
Naming
The name of a state should be unique to its enclosing class, or if nested, within the
state. All state icons with the same name in a given diagram represent the same state.
Actions
Actions on states can occur at one of four times:
TEC,Nerul 14
STTP on OOSE LAB MANUAL
· on entry
· on exit
· do
· on event.
An on event action is similar to a state transition label with the following syntax:
event(args)[condition] : the Action
You must add actions through the Action Specification. States may also appear
on activity diagrams.
Start state
A start state (also called an "initial state") explicitly shows the beginning of a
workflow on an activity diagram or the beginning of the execution of a state machine on
a state chart diagram. You can have only one start state for each state machine because
each workflow/execution of a state machine begins in the same place. If you use multiple
activity and/or state chart diagrams to model a state machine, the same start state can be
placed on the multiple diagrams. When you model nested states or nested activities, one
new start state can be created in each context.
Normally, only one outgoing transition can be placed from the start state. However,
multiple transitions may be placed on a start state if at least one of them is labeled with a
condition. No incoming transitions are allowed.
You can label start states, if desired. State Specifications are associated with each start
state.
Graphical Depiction
The start state icon is a small, filled circle that may contain a name (Begin Process):
End State
An end state represents a final or terminal state on an activity diagram or state
chart diagram. Place an end state when you want to explicitly show the end of a
workflow on an activity diagram or the end of a state chart diagram. Transitions can only
occur into an end state; however, there can be any number of end states per context.
You can label end states, if desired. State Specifications are associated with each end
state.
Graphical Depiction
The end state icon is a filled circle inside a slightly larger unfilled circle that may contain
a name (End Process):
State Transition
Definition
A state transition indicates that an object in the source state will perform certain
specified actions and enter the destination state when a specified event occurs or when
certain conditions are satisfied. A state transition is a relationship between two states,
two activities, or between an activity and a state.
TEC,Nerul 15
STTP on OOSE LAB MANUAL
You can show one or more state transitions from a state as long as each transition is
unique. Transitions originating from a state cannot have the same event, unless there are
conditions on the event.
Graphical Depiction
The icon for a state transition is a line with an arrowhead pointing toward the
destination state or activity:
NewState
Naming
You should label each state transition with the name of at least one event that
causes the state transition. You do not have to use unique labels for state transitions
because the same event can cause a transition to many different states or activities.
Only one event is allowed per transition, and one action per event.
Events, conditions and actions must be added by editing the label or through the State
Transition Specification.
Nested States
States may be nested to any depth level. Enclosing states are referred to as super states,
and everything that lies within the bounds of the super state is referred to as its contents.
Nested states are called sub states.
TEC,Nerul 16
STTP on OOSE LAB MANUAL
Subject: OOSE
Recourses Used:
1) Equipment:
UML / OOAD tool.
2) Consumables:
Printer
Theory:
TEC,Nerul 17
STTP on OOSE LAB MANUAL
Switchesthestateof thelightsat
their respectiverequestedstate
Checkswhether therequested
commandissuccessfullyexecuted.
Sendsthefeedbacktothe
H ACSinteractiondevice
Procedure:
Activity diagrams can model many different types of workflows. For example, a
company could use activity diagrams to model the flow for an approval of orders
or to model the paper trail of invoices. An accounting firm could use activity
diagrams to model any number of financial transactions. A software company
could use activity diagrams to model a software development process.
Each activity represents the performance of a group of actions in a
workflow. Once the activity is complete, the flow of control moves to the next
activity or state through a transition. If an outgoing transition is not clearly
triggered by an event, then it is triggered by the completion of the contained
actions inside the activity. A unique activity diagram feature is a swim lane that
defines who or what is responsible for carrying out the activity or state. It is also
possible to place objects on activity diagrams. The workflow stops when a
transition reaches an end state.
You can attach activity diagrams to most model elements in the use
case or logical views. Activity diagrams cannot reside within the
component view
Analysis / Conclusion:
The activity diagram shows use case as it progress from start to finish.
TEC,Nerul 18
STTP on OOSE LAB MANUAL
The activity diagram shows use case as it progress from start to finish.Activity diagrams
are used to show workflow in parallel and conditionally. They are useful when working
out the order and concurrency of a sequential algorithm, when analyzing the steps in a
business process and when working with threads.
Subject: OOSE
Recourses Used:
7) Equipment:
UML tool.
8) Consumables:
Printer.
Theory:
Component:
A component is a physical and replaceable part of a system that conforms to and provides
the realization of a set of interfaces. Graphically, a component is rendered as a rectangle
with tabs.
Names:
Every component must have a name that distinguishes it from other components. A name
is a textual string.
Components and classes:
In many ways, components are like classes. Both have names; both may realize a set of
interfaces; both may participate in a dependency, generalization, and association
relationship; both may be nested; both may have instances; both may be participants in
TEC,Nerul 19
STTP on OOSE LAB MANUAL
interactions. However, there are some significant differences between component and
classes.
Classes represent logical abstractions; components represent physical things that live in
the world of bits.
• Components represent the physical packaging of otherwise logical
components and are at a different level of abstraction.
• Classes may have attributes and operations directly. In general,
components only have operations that are reachable only through their
interfaces.
Kinds of components may be distinguished-
1. Deployment components: These are the components necessary and
sufficient to form an executable system, such as dynamic libraries and
executable.
2. Work Product Components: The components are essentially the residue of
the development process, consisting of things such as source code files
and data files from which deployment component are created.
3. Execution Components: These component are created has a consequences
of an executing system, such as COM+ object, which is instantiated from a
DLL.
Component Diagram:
Example:
The component diagram shows the organization and dependencies among the set of
components of the system. The Home Appliance Control System contains the following
components:
login.dll
TroubleShoot.dll
TEC,Nerul 20
STTP on OOSE LAB MANUAL
Service Provider.exe
HACSInteractionDevice.exe
Database.dll
deviceControllerGUI.exe
update.dll
appliance.dll
Lights
Appendix:
• Component: A component is a physical building block of the system. It is
represented as a rectangle with tabs.
• Interfaces: An interface describes a group of operations used or created
by components.
• Component qualification: System requirements and architecture define
the component that will be required. Reusable components are normally
identified by the characteristics of their interfaces.
• Component adaptation: The existing reusable components must be
adapted to meet the meets of the architecture or discarded and replaced by
other, more suitable components.
• Component Composition: Architectural style plays a key role in the way
in which software components are integrated to form a working system.
• Component Update: When systems are implemented, update is
complicated by the imposition of the organization that developed the
reusable component may be outside the immediate control of the software
engineering corporation.
Conclusion:
TEC,Nerul 21
STTP on OOSE LAB MANUAL
Subject: OOSE
Recourses Used:
1) Equipment:
UML tool.
2) Consumables:
Printer.
Theory:
A deployment diagram shows processors, devices, and connections. Each model
contains a single deployment diagram which shows the connections between its
processors and devices, and the allocation of its processes to processors.
Processor Specifications, Device Specifications, and Connection Specifications enable
you to display and modify the respective properties. The information in a specification is
presented textually; some of this information can also be displayed inside the icons.
You can change properties or relationships by editing the specification or modifying the
icon on the diagram. The deployment diagram specifications are automatically updated.
Processor
A processor is a hardware component capable of executing programs.
Naming
Each processor must have a name. There are no constraints on the processor name
because processors denote hardware rather than software entities.
Graphical Depiction
The icon for a processor is a shaded box:
NewPr
o...
Adornments
You can further define a processor by identifying its processes and specifying the type of
process scheduling it uses. You can set the following adornments in the Processor
Specification. You can display the information in the deployment diagram by selecting an
item from the processor shortcut menu.
TEC,Nerul 22
STTP on OOSE LAB MANUAL
NewPr
o
pr..
.mptive
ee
process1
process2
Scheduling
You can specify the type of process scheduling used by this processor
by setting a scheduling type:
Type Description
Processes
Processes represent single threads of control. Examples include the main program
from a component diagram or the name of an active object from a collaboration diagram.
To add a process to the processor, double-click on <New> in the Processes field to
displays the Process Specification.
Device
A device is a hardware component with no computing power. Each device must
have a name. Device names can be generic, such as "modem" or "terminal."
Graphical Depiction
The icon for a device is a box:
NewD
evice
Connection
A connection represents some type of hardware coupling between two entities. An
entity is either a processor or a device. The hardware coupling can be direct, such as an
RS232 cable, or indirect, such as satellite-to-ground communication. Connections are
usually bi-directional.
Naming
You can optionally label the connection with its name.
TEC,Nerul 23
STTP on OOSE LAB MANUAL
Graphical Depiction
The icon for a connection is a straight line:
NewProcessor NewDevice
TEC,Nerul 24
STTP on OOSE LAB MANUAL
Library manag
Any organization
for better manage
1.Librarian. 2.Cl
Library managem
librarian should b
The Library h
TEC,Nerul 25
STTP on OOSE LAB MANUAL
re n e w a l o f b o o k
is s u e lib ra ry c a rd s
m a n a g e p e o p le u n d e r h im
L ib ra ria n m em ber
re q u e s t o f a b o o k
< < in c lu d e > >
s e a rch b o o k
re tu rn b o o k
lis t n e w a rriva ls p la c e a n o rd er
a s s ig n b o o k id & m e m b e r id
a p p ro ve n e w re g is tra tio n
c le a rk
u p d a te re q u is ite s o ftw a re co lle ctin g fe e s & fin e s
is s u e b o o k
m a in ta in d e c ip lin e & d e co ru m
h e lp e r
fo llo w in s tru ctio n fro m
lib ra ria n & cle a rk
m a in ta in c le a n e s s
TEC,Nerul 26
STTP on OOSE LAB MANUAL
U G s tu d e n t
L ib ra ry L ib ra ria n
m em ber
N a m e : ch a r n a m e : ch a r
m e m .id : ch a r Book
a d d re s s : ch a r Ad d re s s : ch a r
tu p e : ch a r fa cu lty N a m e : ch a r
te l n o : in t L ib Id : in t
p a s s w o rd : s trin g n o o f b o o ks is s u e d : in t a u th o r : ch a r
m a x b o o k lim it : in t e d itio n : s trin g
g e t lib ra ry info ()
ve rify m e m b e r() n a m e : ch a r PG s tu d e nt B o o k id : in t
s e a rch b o o k() a d d re s s : ch a r 1 ..* p rice : in t
p la ce o rd er() p h o n e n o : in t 1 ra ck n o : in t
cre a te tra ns a ctio n () issu e s
p a y b ill() d is p la y b o o k d e ta ils ()
in cre a s e bo o k is s u e d () u p d a te b o o k d e ta ils ()
h a n d le s
d e cre a s e b o o k is s u e d ()
H e lp e r
cle rk N a m e : ch a r
Ad d re s s : c h a r B ill
N a m e : ch a r Ma g a zin e
co n ta ct n o : in t B ill n o : in t R e fe re n ce b o o k
L ib Id : in t
L ib id : in t Am o u n t : in t N a m e : ch a r D a te : in t Jo u rn a l
Ad d re s s : ch a r p a ys
C o n ta ct n o : in t D a te : in t P u b lis h e r : ch a r typ e : ch a r D a te : in t
Ma in ta in cle a n e s s () Me m b e r id : in t e d itio n : ch a r typ e : ch a r
m a in ta in d e co ru m () D is p la y m a g .d e ta ils Pu
() b lis h e r : ch ar
is s u e b o o k()
re tu rn b o o k() cre a te b ill() d is p la y d e ta ils ()
ca lcu la te fin e () u p d a te b ill() re fe rs cre a te s d is p la y jo u rn a l d e ta ils ()
cre a te b ill() p e rfo rm s
Tra n s a ctio n
B o o k id : in t
m e m b er id : in t
is s u e d e tails : ch a r
TEC,Nerul 27
STTP on OOSE LAB MANUAL
proceed if valid
calculate fine
pay fine
update transaction
place order
book issued
<<create transaction>>
TEC,Nerul 28
STTP on OOSE LAB MANUAL
T:Transa
ction
M:Memb
er
1: verify member
4: get member type
12: update mem ber record
2: proceed if valid
C:clerk M:memb
L:libraria er
n
6: <<create>>
3: get issue details
8: 8:add fine and member details
9: pay fine
B:Bill
5: check book returned in valid tim e T:transac
tion
B:Book
TEC,Nerul 29
STTP on OOSE LAB MANUAL
available
issue book request[ member valid ]
issued to
member
not
available
is s u e b o o k
[ va l id m e m b e r ] r e tu rn b o o k
d u e d a te
ve rify
m em ber [ o ve r d u e ]
[ no due ]
p a y fi n e
b o o k is s u e d
[ b o o k a va il a b le ]
in va li d m e m b e r
c h e c k in g a va ila b ili ty
of book
m e m b e r r e tu rn s b o o k
[ b o o k n o t a va ila b l e ]
id le
TEC,Nerul 30
STTP on OOSE LAB MANUAL
Verify member
[valid member]
Request for
issuing book
check availability
of book
[Book not available]
[book available]
check no of book
issued to member
[limit exceeded]
display no more [not valid member]
books used
[not exceeded]
create
transaction
issue book
update book
status
update
member status
TEC,Nerul 31
STTP on OOSE LAB MANUAL
Verify member
[valid member]
Get issue
details
Get member
type
verify book id
[Not exceeded]
[if exceeded]
create bill
calculate fine
Add member
details to bill
collect fine
update book
status
TEC,Nerul 32
STTP on OOSE LAB MANUAL
L ibra ry s ta ff
L ib ra ria n cle rk
D a tab a s e o f libra ry
H e lp e r
B ill
Mem b er
Bo oK
R e fe re n c m a g a zin e
e bo o k s tra n s actio
Faculty s tu d en t
m e m b er n
jo u rn als
TEC,Nerul 33
STTP on OOSE LAB MANUAL
Problem Definition:
TEC,Nerul 34
STTP on OOSE LAB MANUAL
bill. The store does not bear the responsibility for the books damaged during
dispatch.
The store management maintains complete information about the books such
as Book ID, Price , Title , Edition , Year of Publication , Category , author ,
publisher etc. The store management also encourages the development team
to add more features to the project , which shall merge well with
requirements of the bookstore . However , since several competitors ere
expected to go online very shortly and the fact that the management wants to
be the first of the block, it becomes vital that the project is completed within
the stipulated time.
TEC,Nerul 35
STTP on OOSE LAB MANUAL
1)Usecase diagram
Checkout
Billing Of Books
Logs Off
TEC,Nerul 36
STTP on OOSE LAB MANUAL
Class Diagram
O nline B ook S y s
b oo k s : B ook
c urren t cu s t om er
B uy ()
1
F in dA llB ook s () 1
c u rren tb ook
L og in()
1 s ele c tB ook ()
g etbo ok ()
c ontainslogo ff()
1
login()
1
c us tom er
1 * 1 1
P as s w o rd : s trin g
B oo k S S N : d oub le
(f ro m p ri n t) has c us tn am e : s trin g
IS B N : s trin g * c us tid : integ er
n am e : s tring s hip ping add res s : s trin g
t itle : s tring billing adres s : s trin g
y ea r of pub : integer
p ub lis he r : s tring opn am e ()
a utho r : s tring valida te()
p ric e : dou ble getc a rt()
q ua ntity : int bill()
1
g etbo ok info() c us tom e rorde r
ret urnc urre ntb oo k () *
o rd er
1 c u s tid : inte ger
qu antity of book s : intege r
na m e
O rders C reated * s tat us : s trin g
To ta l pric e : float
Tran s ac tion : double
m et hodofpay m ent : s tring
b oo k ordered 1
ad dbook ()
c rea teord er()
printinvoic e()
TEC,Nerul 37
STTP on OOSE LAB MANUAL
Object Diagram
O1:Onlinebooksys c1:customer
Object diagram
Password : xxxxx
SSN : 1234
custname : “xyz”
custid : 123
shipping address :
“abcdefgh”
B1:Book billing adress : “abcdefgh”
ISBN : “b111”
name : “ppp”
title : “xxxxxxx”
year of pub : 1982
publisher : “technova” B1:Book c1:customer
author : “qqqq”
price : 700 ISBN : “a111”
quantity : 1 name : “xyz” Password : xxxxx
title : “xxxxxxx” SSN : 2341
year of pub : 1980 custname : “abcd”
publisher : custid : 231
“technova” shipping address :
author : “zzzz” “abcdefgh”
price : 400 billing adress :
quantity : 1 “abcdefgh”
O1:order
custid : 123
quantity of books : 1
status : “available”
Total price : 575
Transaction : yes
methodofpayment :
cheque
TEC,Nerul 38
STTP on OOSE LAB MANUAL
Sequence diagram
customer order book site
5: Sales info
6: dispatch of books
7: Payment
8: Issuse of receipt
9: Loggs off
TEC,Nerul 39
STTP on OOSE LAB MANUAL
Collaboration diagram
order
customer
6: dispatch of books
site
TEC,Nerul 40
STTP on OOSE LAB MANUAL
Activity diagram
Open home
page
Enter login id
registration and password
delivery and
payment
TEC,Nerul 41
STTP on OOSE LAB MANUAL
State diagram
Visit URL
Select category
Display Selected
Category details
registered
Login
register
Enter loginid
Payment
TEC,Nerul 42
STTP on OOSE LAB MANUAL
Component diagram
Login
Registrar Customer
GUI
(Browser)
Validate
order Book
deployment diagram
TEC,Nerul 43
STTP on OOSE LAB MANUAL
The University conducts many courses and students can register for those courses.
The register university will introduce any new course. Also the register maintains the
curriculum and student details. The examination will be conducted for students and the
degree is issued for students who have completed the course successfully.
TEC,Nerul 44