CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT III

DYNAMIC AND IMPLEMENTATION UML DIAGRAMS

Dynamic Diagrams – UML interaction diagrams – System sequence diagram – Collaboration

diagram – When to use Communication Diagrams – State machine diagram and Modelling –
When to use State Diagrams – Activity diagram – When to use activity diagrams Implementation
Diagrams – UML package diagram – When to use package diagrams – Component and
Deployment Diagrams – When to use Component and Deployment diagrams

3.1 DYNAMIC DIAGRAMS

 There are two kinds of object models: dynamic and static.

 Dynamic models, such as UML interaction diagrams (sequence diagrams or
communication diagrams), help design the logic, the behavior of the code or the method
bodies.
 They tend to be the more interesting, difficult, important diagrams to create. Static
models, such as UML class diagrams, help design the definition of packages, class
names, attributes, and method signatures (but not method bodies)

3.2 UML INTERACTION DIAGRAMS

. The UML includes interaction diagrams to illustrate how objects interact via messages. They
are used for dynamic object modeling. An interaction diagram is a type of UML diagram that is
used to capture the interactive behavior of a system. Interaction diagrams focus on describing the
flow of messages within a system, providing context for one or more lifelines within a system. In
addition, interaction diagrams can be used to represent the ordered sequences within a system
and act as a means of visualizing real-time data via UML. There are two common types:

1. Sequence diagrams.
2. communication diagrams.

Department of CSE Page 76

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.2.1. Sequence diagrams:

Sequence diagrams illustrate interactions in a kind of fence format, in which each new
object is added to the right. A sequence diagram shows object interactions arranged in time
sequence. It depicts the objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the functionality of the scenario.
Sequence diagrams are typically associated with use case realizations in the Logical View of the
system under development. Sequence diagrams are sometimes called event diagrams or event
scenarios.

Figure.3.1 Sequence diagram.

3.2.2.Communication diagrams

Communication diagrams illustrate object interactions in a graph or network format, in

which objects can be placed anywhere on the diagram. communication diagrams is a kind of
interaction diagram, shows how objects interact. A communication diagram is an extension of
object diagram that shows the objects along with the messages that travel from one to another.
In addition to the associations among objects, communication diagram shows the messages the
objects send each other.

Department of CSE Page 77

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Figure 3.2 Communication diagram.

Strength and weakness of sequence VS communication diagrams:

Example: make payment

Figure 3.3 Sequence diagram

Department of CSE Page 78

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Figure 3.4 Communication diagram.

3.2.3. Common UML Interaction Diagram Notation:

3.2.4.Basic Message Expression Syntax

return = message(parameter : parameter Type) : return Type

3.2.6.Singleton Objects

In s singleton pattern there is only one instance of a class instantiated. Singleton object
is marked with a '1' in the upper right corner of the lifeline box.

Department of CSE Page 79

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Figure3.6 Singletons in interaction diagrams.

3.3.BASIC SEQUENCE DIAGRAM NOTATION

3.3.1Messages

Each message between objects is represented with a message expression on a filled-arrowed[3]

solid line between the vertical lifelines (see Figure 15.7). The time ordering is organized from
top to bottom of lifelines.

3.3.2.Focus of Control and Execution Specification Bars

Sequence diagrams may also show the focus of control using an execution specification
bar. The bar is optional.

Figure.3.7 Messages and focus of control with execution specification bar.

Department of CSE Page 80

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.3.3.Reply or Returns

There are two ways to show the return result from a message:

 Using the message syntax returnVar = message(parameter).

 Using a reply (or return) message line at the end of an activation bar.

Figure3.7 Two ways to show a return result from a message

3.3.4.Messages to "self" or "this"

Message being sent from an object to itself by using a nested activation bar.

Figure3.8 Messages to "this."

Department of CSE Page 81

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.3.5. Creation of Instance

Object creation notation is shown in dashed line with filled arrow ( synchronous message), or
open (stick arrow) if an asynchronous call.

Figure 3.9 Instance creation and object lifelines.

3.3.6.Object Destruction

The explicit destruction of an object can be shown with <<destroy>>sterotype message with
larger X.

Figure3.10 Object destruction.

Department of CSE Page 82

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.3.7. Frames

Frames are regions or fragments of the diagrams; they have an operator or label (such as loop)
and a guard .The [boolean test] guard should be placed over the lifeline to which it belongs.

Figure 3.11 Example UML frame.

The following table summarizes some common frame operators:

3.3.8. Conditional Messages

An OPT frame is placed around one or more messages. Notice that the guard is placed over the
related lifeline.

Department of CSE Page 83

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.3.9.Mutually Exclusive Conditional Messages

An ALT frame is placed around the mutually exclusive alternatives

3.3.10.Iteration Over a Collection

A common algorithm is to iterate over all members of a collection (such as a list or map),
sending the same message to each.

Department of CSE Page 84

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.3.11. Nesting of Frames

Frames can be nested. It is shown in following

3.3.11. System Sequence Diagrams:

A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and
output events related to the systems under discussion. They are input to operation contracts and
most importantly object design.

Figure3.12 SSD for a Process Sale scenario.

Department of CSE Page 85
 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

 The UML includes sequence diagrams as a notation that can illustrate actor interactions
and the operations initiated by them.
 A system sequence diagram is a picture that shows, for one particular scenario of a use
case, the events that external actors generate, their order, and inter-system events.
 All systems are treated as a black box; the emphasis of the diagram is events that cross
the system boundary from actors to systems.

3.4.UML STATE MACHINE DIAGRAMS AND MODELING

 A UML state machine diagram, , illustrates the interesting events and states of an object,
and the behavior of an object in reaction to an event.
 Transitions are shown as arrows, labeled with their event.
 States are shown in rounded rectangles.
 It is common to include an initial pseudo-state, which automatically transitions to another
state when the instance is created.

Figure 3.13. State machine diagram for a telephone

 A state machine diagram shows the lifecycle of an object: what events it experiences, its
transitions, and the states it is in between these events.
 It need not illustrate every possible event; if an event arises that is not represented in the
diagram, the event is ignored as far as the state machine diagram is concerned.

Department of CSE Page 86

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

 Therefore, we can create a state machine diagram that describes the lifecycle of an object
at arbitrarily simple or complex levels of detail, depending on our needs.

3.4.1.Events, States, and Transitions

 An event is a significant or noteworthy occurrence.

 For example A telephone receiver is taken off the hook.
 A state is the condition of an object at a moment in time the time between events.
 For exampleA telephone is in the state of being "idle" after the receiver is placed on the
hook and until it is taken off the hook
 A transition is a relationship between two states that indicates that when an event occurs,
the object moves from the prior state to the subsequent state.
 For exampleWhen the event "off hook" occurs, transition the telephone from the "idle"
to "active" state.

3.4.2. How to Apply State Machine Diagrams?

State-Independent and State-Dependent Objects

 If an object always responds the same way to an event, then it is considered state-
independent (or modeless) with respect to that event.
 For example, if an object receives a message, and the responding method always does the
same thing. The object is state-independent with respect to that message.
 If, for all events of interest, an object always reacts the same way, it is a state-
independent object. By contrast, state-dependent objects react differently to events
depending on their state or mode.

Guideline

 Consider state machines for state-dependent objects with complex behavior, not for state-
independent objects .For example, a telephone is very state-dependent.
 The phone's reaction to pushing a particular button (generating an event) depends on the
current mode of the phone off hook, engaged, in a configuration subsystem, and so forth.

Department of CSE Page 87

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

 In general, business information systems have few complex state-dependent classes.

3.4.3.Modeling State-dependent Objects

Broadly, state machines are applied in two ways:

 To model the behavior of a complex reactive object in response to events.

 To model legal sequences of operationsprotocol or language specifications.This approach
may be considered a specialization of #1, if the "object" is a language, protocol, or
process. A formal grammar for a context-free language is a kind of state machine.

The following is a list of common objects which are often state-dependent, and for which it may
be useful to create a state machine diagram:

3.4.5.Complex Reactive Objects

1. Physical Devices controlled by software

Phone, car, microwave oven: They have complex and rich reactions to events, and
the reaction depends upon their current mode.
2. Transactions and related Business Objects
How does a business object (a sale, order, payment) react to an event? For
example, what should happen to an Order if a cancel event occurs? And understanding all
the events and states that a Package can go through in the shipping business can help with
design, validation, and process improvement.
3. Role MutatorsThese are objects that change their role.
A Person changing roles from being a civilian to a veteran. Each role is represented
by a state.

3.4.6. Protocols and Legal Sequences

a) Communication Protocols TCP, and new protocols, can be easily and clearly
understood with a state machine diagram. The diagram illustrates when operations are
legal. For example, a TCP "close" request should be ignored if the protocol handler is
already in the "closed" state.

Department of CSE Page 88

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

b) UI Page/Window Flow or NavigationWhen doing UI modeling, it can be useful to

understand the legal sequence between Web pages or windows; this is often complex. A
state machine is a great tool to model UI navigation

c) UI Flow Controllers or SessionsThis is related to UI navigation modeling, but

specifically focused on the server-side object that controls page flow. These are usually
server-side objects representing an ongoing session or conversations with a client. For
example, a Web application that remembers the state of the session with a Web client and
controls the transitions to new Web pages, or the modified display of the current Web
page, based upon the state of the session and the next operation that is received.
d) Use Case System Operations
system operations for Process Sale: makeNewSale, enterItem, should arrive in a legal
order; for example, endSale should only come after one or more enterItem operations.
Usually, the order is trivially obvious, but if complex, a state machine can model this,
treating the use case itself as an object.
e) Individual UI Window Event Handling
Understanding the events and legal sequences for one window or form. For example,
the Edit-Paste action is only valid if there is something in the "clipboard" to paste.

3.4.7.UML State Machine Diagram Notation

Transition Actions and Guards - A transition can cause an action to fire. In a software
implementation, this may represent the invocation of a method of the class of the state machine
diagram.A transition may also have a conditional guardor boolean test. The transition only
occurs if the test passes.

Figure3.14.Transition action and guard notation.

Department of CSE Page 89

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.4.8.Nested States

A state allows nesting to contain sub states; a sub state inherits the transitions of its super state
(the enclosing state). Sub states may be graphically shown by nesting them in a super state box.

Figure3.15 Nested states.

For example, when a transition to the Active state occurs, creation and transition into the
PlayingDialTone substate occurs.

3.4.9.Example: NextGen Use Case State Machine Diagram

There are no really interesting complex reactive objects in the case studies, a state machine
diagram to show legal sequencing of use case operation.

Figure 3.16 sample state machine for legal sequence of use case operations.

Department of CSE Page 90

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.5.ACTIVITY DIAGRAMS

A UML activity diagram shows sequential and parallel activities in a process. They are useful for
modeling business processes, workflows, data flows, and complex algorithms. Activity
diagrams are graphical representations of workflows of stepwise activities and actions with
support for choice, iteration and concurrency. In the Unified Modeling Language, activity
diagrams are intended to model both computational and organizational processes (i.e.,
workflows), as well as the data flows intersecting with the related activities. Although activity
diagrams primarily show the overall flow of control, they can also include elements showing the
flow of data between activities through one or more data stores

3.5.1. Basic UML diagram notations:

Department of CSE Page 91

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.5.2. Signals:

Signals are useful when you need to model events such as time triggering an action or a
cancellation request.

Figure 3.17 Signals.

3.5.3.Rake symbols:

Rake symbol indicates an activity is expanded in another activity diagram also it is called
as action symbol indicates that the activity being invoked is described on another diagram. For

Department of CSE Page 92

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

example, to transform light into video signals, the Operate Camera activity invokes other
activities that perform various subtasks using call behavior actions.

Figure 3.18 An activity will be expanded in another diagram.

Figure 3.19 The expansion of an activity.

Guidelines

 This technique proves most valuable for very complex processes, usually involving many
parties.
Department of CSE Page 93
 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

 If modeling a business process, take advantage of the "rake" notation and sub-activity
diagrams.
 Strive to make the level of abstraction of action nodes roughly equal within a diagram.

3.5.4.Example: NextGen Activity Diagram

Figure 3.20. Modeling the Process Sale use case with an activity diagram.

3.5.5.Activity Diagrams in the UP

 Activity diagrams are espically applicable within the business Modelling discipline of the
UP.
 The purpose of Business Modeling is to understand and communicate "the structure and
the dynamics of the organization in which a system is to be deployed".
 A key artifact of the Business Modeling discipline is the Business Object Model .
 Business Object Model visualizes how a business works, using UML class, sequence,
and activity diagrams.
 Thus, activity diagrams are especially applicable within the Business Modeling discipline
of the UP.

Department of CSE Page 94

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.6.When to Use Activity Diagram

 Activity Diagrams describe how activities are coordinated to provide a service which can
be at different levels of abstraction.
 Typically, an event needs to be achieved by some operations, particularly where the
operation is intended to achieve a number of different things that require coordination, or
how the events in a single use case relate to one another, in particular, use cases where
activities may overlap and require coordination.
 It is also suitable for modeling how a collection of use cases coordinate to represent
business workflows

1) Identify candidate use cases, through the examination of business workflows

2) Identify pre- and post-conditions (the context) for use cases
3) Model workflows between/within use cases
4) Model complex workflows in operations on objects
5) Model in detail complex activities in a high level activity Diagram

3.7.PACKAGE DIAGRAMS

 UML package diagrams are often used to illustrate the logical architecture of a system-
the layers,subsystems,packages etc.,
 A layer can be modeled as a UML package.
 A UML package diagram provides a way to group elements. A UML package can group
anything:classes,other packages, use cases etc.

Package: Package is a namespace used to group together elements that are semantically related
and might change together.

3.7.1.Basic notations in package diagram:

package:

Department of CSE Page 95

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

Use a tabbed folder to illustrate packages.Name of the package can be written on the tab or
inside the folder.

Visibility:Visibility markers signify who can access theInformation contained within the
package.

 Private visibility: attribute/operation is not accessible to anything outside the package.

 Public visibility: allows an attribute or an operation to be viewed by other packages.
 Protected package: attribute/operation is only visible to package that inherit it.

Dependency: Dependency defines a relationship in which changes to one package will affect
another package.

In addition to the standard UML Dependency relationship, there are two special types of
dependencies defined between packages:

 package import
 package merge

A package import is a relationship between an importing namespace and a package, indicating

that the importing namespace adds the names of the members of the package to its own
namespace. By default, an unlabeled dependency between two packages is interpreted as a
package import relationship. In this relationship, elements within the target package will be
imported into the source package.

Department of CSE Page 96

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

A package merge is a directed relationship between two packages, that indicates that the contents
of the two packages are to be combined. It is very similar to Generalization in the sense that the
source element conceptually adds the characteristics of the target element to its own
characteristics resulting in an element that combines the characteristics of both .In this
relationship, if an element exists within both the source package and the target package, then the
source element's definition will be expanded to include the target element's definition.

3.7.2. Example:

Figure 3.21 Layers shown with UML package diagram notation.

When to use package diagrams:

1. It is used in large scale systems to picture dependencies between major elements in

the system
2. Package diagrams represent a compile time grouping mechanism.

Department of CSE Page 97

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

3.8.DEPLOYMENT DIAGRAMS

 A deployment diagram shows the assignment of concrete software artifacts (such as

executable files) to computational nodes (something with processing services).
 It shows the deployment of software elements to the physical architecture and the
communication (usually on a network) between physical elements.

3.8.1.Example:

Figure3.22Deployment diagram

The basic element of a deployment diagram is a node, of two types:

1) device node (or device) A physical (e.g., digital electronic) computing resource
with processing and memory services to execute software, such as a typical
computer or a mobile phone.
Department of CSE Page 98
 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

2) execution environment node (EEN) This is a software computing resource that

runs within an outer node (such as a computer) and which itself provides a service
to host and execute other executable software elements. For example: an
operating system ,a virtual machine ,a database engine, Web browser,a workflow
engine,a servlet container.
 The normal connection between nodes is a communication path, which may be labeled
with the protocol. These usually indicate the network connections.
 A node may contain and show an artifacta concrete physical element, usually a file. This
includes executables such as JARs, assemblies, .exe files, and scripts.
 It also includes data files such as XML, HTML, and so forth.
 A deployment diagram usually shows an example set of instances (rather than classes).
 A concrete instances are shown with an underline under their name, and the absence of an
underline signifies a class rather than an instance.

3.8.2.When to use deployment diagrams:

 Deployment diagrams are mainly used by system engineers.

 These diagrams are used to describe the physical components (hardware), their
distribution, and association.
 Deployment diagrams can be visualized as the hardware components/nodes on which the
software components reside.
 Software applications are developed to model complex business processes. Efficient
software applications are not sufficient to meet the business requirements.
 Business requirements can be described as the need to support the increasing number of
users, quick response time, etc.
 To meet these types of requirements, hardware components should be designed
efficiently and in a cost-effective way
 .Now-a-days software applications are very complex in nature.
 Software applications can be standalone, web-based, distributed, mainframe-based and
many more.
 Hence, it is very important to design the hardware components efficiently.
 Deployment diagrams can be used −

Department of CSE Page 99

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

1) To model the hardware topology of a system.

2) To model the embedded system.
3) To model the hardware details for a client/server system.
4) To model the hardware details of a distributed application.
5) For Forward and Reverse engineering.

3.9.COMPONENT DIAGRAMS

 A component represents a modular part of a system that encapsulates its contents and
whose manifestation is replaceable within its environment.
 A component defines its behavior in terms of provided and required interfaces. As such,
a component serves as a type, whose conformance is defined by these provided and
required interfaces.

The modeling and design intent is to emphasize

1) that the interfaces are important, and

2) it is modular, self-contained and replaceable.

The second point implies that a component tends to have little or no dependency on other
external elements (except perhaps standard core libraries); it is a relatively stand-alone module.

Figure3.23 UML components.

Department of CSE Page 100

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

A good analogy for software component modeling is a home entertainment system; we expect to
be able to easily replace the DVD player or speakers. They are modular, self-contained,
replaceable, and work via standard interfaces.

3.9.1.When to Use Component Diagrams?

 Component diagrams are special type of UML diagrams used for different purposes.
 These diagrams show the physical components of a system. To clarify it, we can say that
component diagrams describe the organization of the components in a system.
 Organization can be further described as the location of the components in a system.
These components are organized in a special way to meet the system requirements.
 Before implementing the application, these components are to be organized. This
component organization is also designed separately as a part of project execution.
 Component diagrams are very important from implementation perspective.
 Thus, the implementation team of an application should have a proper knowledge of the
component details
 Component diagrams can be used to –
1) Model the components of a system.
2) Model the database schema.
3) Model the executables of an application.
4) Model the system's source code

POSSIBLE TWO MARKS

1.What is an activity diagram?

A UML activity diagram shows sequential and parallel activities in a process. They are useful for
modeling business processes, workflows, data flows, and complex algorithms. Basic UML
activity diagram notation illustrates an action, partition, fork, join, and object node. In essence,
this diagram shows a sequence of actions, some of which may be parallel. Most of the notation is
self-explanatory;

2.What is meant by System Sequence Diagrams? APRIL/MAY-2011

Department of CSE Page 101

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case,
the events that external actors generate their order, and inter-system events. All systems are
treated as a black box; the emphasis of the diagram is events that cross the system boundary from
actors to systems.

System behavior is a description of what a system does, without explaining how it does it. One
Part of that description is a system sequence diagram. Other parts include the Use cases, and
system contracts(tobediscussedlater).

4. What is meant by Inter-System SSDs?

SSDs can also be used to illustrate collaborations between systems, such as between the Next
Gen POS and the external credit payment authorizer. However, this is deferred until a later
iteration in the case study, since this iteration does not include remote systems collaboration. 4.
Define System Events and the System Boundary.

5. How to Naming System Events and Operations?

System events (and their associated system operations) should be expressed at the level of intent
rather than in terms of the physical input medium or interface widget level.

It also improves clarity to start the name of a system event with a verb Thus "enter item" is better
than "scan" (that is, laser scan) because it captures the intent of the operation while remaining
abstract and noncommittal with respect to design choices about what interface is used to capture
the system event.

6. What is meant by interaction diagram?

The term interaction diagram is a generalization of two more specialized UML diagram types;
both can be used to express similar message interactions: . Collaboration diagrams . Sequence
diagrams

Department of CSE Page 102

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

7. What is meant by link?

A link is a connection path between two objects; it indicates some form of navigation And
visibility between the objects is possible . More formally, a link is an instance of an association.
For example, there is a link or path of navigation from a Register to a Sale, along which
messages may flow, such as the make 2 Payment message.

8. What is meant by Messages?

Each message between objects is represented with a message expression and small arrow
indicating the direction of the message. Many messages may flow along this link. A sequence
number is added to show the sequential order of messages in the current thread of control.

9. How to create an instance?

Any message can be used to create an instance, but there is a convention in the UML to use a
message named create for this purpose. If another (perhaps less obvious) message name is used,
the message may be annotated with a special feature called a UML stereotype, like so: «create».
The create message may include parameters, indicating the passing of initial values. This
indicates, for example, a constructor call with parameters in Java.

10.Define Events, States, and Transitions. APRIL/MAY-2011

An event is a significant or noteworthy occurrence. For example: A telephone receiver is taken

off the hook. A state is the condition of an object at a moment in time—the time between events.
For example:

• A telephone is in the state of being "idle" after the receiver is placed on the hook and until it Is
taken off the hook. A transition is a relationship between two states that indicates that when an
event occurs, the Object moves from the prior state to the subsequent state. For example: •
When the event "off hook" occurs, transition the telephone from the "idle" to "active" state.

Department of CSE Page 103

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

11. What is meant by State chart Diagrams?

A UML state chart diagram, illustrates the interesting events and states of an object, and the
behavior of an object in reaction to an event. Transitions are shown as arrows, labeled with their
event. States are shown in rounded rectangles. It is common to include an initial pseudo-state,
which automatically transitions to another state when the instance is created.

12. State chart Diagrams in the UP?

There is not one model in the UP called the "state model." Rather, any element in any model
(Design Model, Domain Model, and so forth) may have a state chart to better understand or
communicate its dynamic behavior in response to events. For example, a state chart associated
with the Sale design class of the Design Model is itself part of the Design Model.

13. Utility of Use Case State chart Diagrams.

- Hard-coded conditional tests for out-of-order events - Use of the State pattern (discussed in a
subsequent chapter) - disabling widgets in active windows to disallow illegal events (a desirable
approach) - A state machine interpreter that runs a state table representing a use case State chart
diagram.

14. List out the types of Events.

-External event Internal event Temporal event

15. Define External event.

External event—also known as a system event, is caused by something (for example, an actor)
outside our system boundary. SSDs illustrate external events. Noteworthy external events
precipitate the invocation of system operations to respond to them.
- When a cashier presses the "enter item" button on a POS terminal, an external event has
occurred.

Department of CSE Page 104

 CS8592/OBJECT ORIENTED ANALYSIS AND DESIGN

16. Define internal event.

Internal event—caused by something inside our system boundary. In terms of software, an

internal event arises when a method is invoked via a message or signal that was sent from
another internal object. Messages in interaction diagrams suggest internal events. - When a Sale
receives a make Line item message, an internal event has occurred.

17. Define temporal event.

Temporal event—caused by the occurrence of a specific date and time or passage of time. In
terms of software, a temporal event is driven by a real time or simulated-time clock.

-Suppose that after an end Sale operation occurs, a make Payment operation must occur within
five minutes, otherwise the current sale is automatically purged.

PART B QUESTIONS

1.What is the purpose of state chart diagrams?How to draw state chart diagram?Explain

2.Discuss about UML deployment and component diagrams.Draw the diagrams for banking
application?

3.Explain UML activity diagram with example?

3.Explain about sequence diagram?

PART C

1.Draw the UML diagrams for the following applications:

a)ATM system

b)Library management system.

2.Draw the UML diagram for Airline reservation systems.

3.Construct the Sequence diagram for NEXTGEN POS.

Department of CSE Page 105