Assignment Number: 1

Title: Concept Document (Requirement Definition Document)

Problem Statement : To develop system requirement definition document for the target
system.

Description:
This document should address issues:
1. Problem Identification
 Cause: It is the cause behind the problem.
 Symptom: The symptom seen which indicate the existence of the problem
 Effect: Net Effect of the problem in the current system.
2. Problem Definition
3. Problem Statement
 Context: It is the thing that has given rise to the problem. This can be treated as
the cause behind the problem.
 Problem: Description of the recurring issue indicating demand of the system
under consideration.
 Solution: Resolution of problem indicating the impact of the problem on user /
stakeholder

1
Assignment Number : 2

Title :System Requirements Specification

Problem Statement : To develop system requirement specification document for the

target system.

System Requirement Specification Outline

Introduction
The purpose of this document is to collect, analyze and define high-level needs and
features of the <<System Name>>. It focuses on the capabilities needed by the
stakeholders, and the target users, and why these needs exist. The details of how the
<<System Name>> fulfils these needs are detailed in the use-case and supplementary
specifications.
[The introduction of the Vision should provide an overview of the entire
document. It should include the purpose, scope, definitions, acronyms,
abbreviations, references and overview of this Vision.]
Purpose
[Specify the purpose of the system.]
Scope
[A brief description of the scope of the system; what Project it is associated with,
and anything else that is affected or influenced by this document.]
Definitions, Acronyms and Abbreviations
[This subsection should provide the definitions of all terms, acronyms, and
abbreviations required to interpret properly the Vision. This information may be
provided by reference to the project Glossary.]
References
[This subsection should provide a complete list of all documents referenced
elsewhere in the SRS. Each document should be identified by title, report number
(if applicable), date, and publishing organization. Specify the sources from which
the references can be obtained. This information may be provided by reference to
an appendix or to another document.]
Overview
[This subsection should describe what the rest of the SRS contains and explain
how the document is organized.]

Current System
2.1 History[Survey the history for the project under consideration]
2.2 Comparison of Existing System

3. Proposed System

2
.1. Problem Statement
[Provide a statement summarizing the problem being solved by this project. The
following format may be used:]
The problem of (describe the problem)
affects (the stakeholders affected by the
problem).
The impact of which (what is the impact of the
is problem).
A successful (list some key benefits of a
solution would successful solution).

Product Position Statement

[Provide an overall statement summarizing at the highest level, the unique
position the product intends to fill in the marketplace. The following format may
be used:]
For (target customer)
Who (statement of the need or
opportunity)
The (product name) is a (product category)
That (statement of key benefit - that is -
compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary
differentiation)
[A product position statement communicates the intent of the application and the
importance of the project to all concerned personnel.]
Product Overview
Product perspective
[Indicate whether product is self-contained, independent]
Summary of Capabilities
[Summarize the major benefits and features the product will provide. For
example, a Vision document for a customer support system may use this part to
address problem documentation, routing and status reporting without mentioning
the amount of detail each of these functions requires.
Organize the functions so the list is understandable to the customer or to anyone
else reading the document for the first time. A simple table listing the key benefits
and their supporting features might suffice. For example:]

3
 Customer Support System
Customer Benefit Supporting Features
New support staff can quickly Knowledge base assists support
get up to speed. personnel in quickly identifying
known fixes and workarounds
Customer satisfaction is Problems are uniquely itemized,
improved because nothing falls classified and tracked throughout
through the cracks. the resolution process. Automatic
notification occurs for any aging
issues.
Management can identify Trend and distribution reports
problem areas and gauge staff allow high level review of problem
workload. status.
Distributed support teams can Replication server allows current
work together to solve database information to be shared
problems. across the enterprise
Customers can help Knowledge base can be made
themselves, lowering support available over the Internet. Includes
costs and improving response hypertext search capabilities and
time. graphical query engine

Assumptions & Dependencies

[List each of the factors that affect the features stated in the Vision document. List
assumptions that, if changed, will alter the Vision document. For example, an
assumption may state that a specific operating system will be available for the
hardware designated for the software product. If the operating system is not
available, the Vision document will need to change.]

Functional requirement
Objectives
Feature Set (Critical)
Precedence & Priority
Nonfunctional requirement
Stakeholder and User Descriptions
[To effectively provide products and services that meet your stakeholders’ and
users' real needs, it is necessary to identify and involve all of the stakeholders as
part of the Requirements Modeling process. You must also identify the users of
the system and ensure that the stakeholder community represents them
adequately. This section provides a profile of the stakeholders and users involved
in the project and the key problems that they perceive to be addressed by the
proposed solution. It does not describe their specific requests or requirements

4
 (these are captured in a separate stakeholder requests artifact). Instead it provides
the background and justification for why the requirements are needed.]
Stakeholder Summary
[Present a summary list of all the identified stakeholders:]
Name Represents Role
Name the Briefly describe what they Briefly describe the role they
stakeholder represent with respect to the are playing in the development.
type. development. i.e. Ensure this….

User Summary
[Present a summary list of all the identified users:]
Name Description Stakeholder
Name the user Briefly describe what they List how the user is
type represent with respect to the represented by the
system. stakeholders.
i.e. Represented by
Stakeholder1

User environment
[Detail the working environment of the target user. Here are some suggestions:
• Number of people involved in completing the task? Is this changing?
• How long is a task cycle? Amount of time spent in each activity? Is this
changing?
• Any unique environmental constraints: mobile, outdoors, in-flight, etc.?
• Which systems platforms are in use today? Future platforms?
• What other applications are in use? Does your application need to integrate
with them?
This is where extracts from the Business Model could be included to outline the
task and workers involved etc…]
Key Stakeholder / User Needs
[List the key problems with existing solutions as perceived by the stakeholder.
Clarify the following issues for each problem:
• What are the reasons for this problem?
• How is it solved now?
• What solutions does the stakeholder want?

5
 It is important to understand the relative importance the stakeholder places on
solving each problem. Ranking and cumulative voting techniques indicate
problems that must be solved versus issues they would like addressed.
Need Priority Concerns Current Solution Proposed Solutions
Broadcast
messages

3.2 Hardware Considerations

3.2.1 System requirements

3.2.2 Environments requirements

3.3 Error Handling & System modifications

3.4 Security Issues

Assignment Number : 3

6
Title : Use Case Diagram

Problem Statement : To specify the behavior of the target system and interaction with it
using use case diagrams. Use Case diagram should encompass
a) Actors (External Users)
b) The transactions (Use Cases)
c) The event responses related to transactions with external agents.
d) System boundaries indicating scope of system.

Description:

1. Business Analysis
The Use Case technique captures information about how a system or business currently
works or should work. Although not a true object-oriented approach, the Use Case
technique helps you build scenarios which model the processes of the system. It is an
excellent way to lead into object-oriented analysis of systems.

2. A Use Case for Every Scenario

Typically, Use Case diagrams are modeled for every scenario in the system or business.
Each Use Case can be defined simply with text describing the scenario. You may also
define the scenario with the sequence of steps performed within it or with the conditions
that exist before the scenario begins or after it completes.

3. Actors as External Agents

An actor is considered an external agent to a system: someone or something that requests
a service from the system or acts as a catalyst for something in the system to occur. UML
specifies that the actor is a class of objects, not a particular instance of a class (or object).
The actor is represented as a class with a stereotype of actor.

4. Organization of Use Case Diagrams

During business analysis of the system, you can develop one Use Case diagram that acts
as the system Use Case, and draw packages on this Use Case to represent the various
business domains of the system. For each package, you may create a child Use Case
diagram. On each child Use Case diagram, you can draw all of the Use Cases of the
domain, with actor interactions, and use the System symbol to further refine the
categorization of the Use Cases. The extends and uses relationships can be used to
eliminate redundant modeling of scenarios.

5. When to Stop Decomposing Use Case Diagrams

When you have arrived at the lowest Use Case level, you can create a Child Sequence
diagram (and accompanying Collaboration diagram) for the Use Case. With these
Sequence and Collaboration diagrams, you can model the implementation of the scenario.

6. The sections of a use case:

7
 Section Purpose
Name Download manager
Description To develop a download manager that allows searching,
downloading, uploading
Actors The list of actors associated with the use case.
Preconditions A list of the conditions, if any, that must be met before a use case
may be invoked.
Post conditions A list of conditions, if any, that will be true once the use case
finishes successfully.
Basic course of The main path of logic an actor follows through a use case. It
action describes how the use case works in normal course.
Alternate courses The infrequent paths of logic in a use case, paths that are the result
of action of an alternate way to work, an exception, or an error condition.
Change History Details when the use case is modified, why and by whom.

7. An actor is considered an external agent to a system; someone or something that

requests a service from the system, or acts as a catalyst for something in the system to
occur. UML specifies that the actor is a class of objects, not a particular instance of a
class (or object). The actor is defined as a class with a stereotype of actor.

8. The actor is graphically represented as a stick figure. The actor is defined as a class
with stereotype actor. Once drawn on a Use Case diagram, the stereotype actor is
automatically applied to the underlying class definition.

9. How to identify actors?

Actors are always external to the system being modeled; they are never part of the
system. When you are doing essential use case modeling, your goal is to use actors to
model roles and not the physical, real world people, organization or systems. Following
queries are useful for tracing the actors in the use case diagram (by Schneider and
winters(1998); Leffingwell and widrig(2000))
1. Who is the main customer of your system?
2. Who obtains information from this system?
3. Who provides information to the system?
4. who installs the system?
5. Who operates and shuts down the system?
6. What other systems interacts with this system?
7. does anything happen automatically at preset time?
8. Who will supply, use, remove information from the system?

8
10. How to identify the use cases?
Following queries suggested by Constantine and Lockwood (1999) are useful in tracing
potential use cases :
1. What are users in this role trying to accomplish?
2. To fulfill this role, what do users need to be able to do?
3. What are the main tasks of the user in this role?
4. What information do users in this role need to examine, create, or change?
5. What do users in this role need to inform the system about?

11. The Extends line is drawn between Use Cases on a Use Case diagram. An Extends
line from Use Case One to Use Case Two signifies that an instance of Use Case Two may
include the behavior specified by Use Case One, subject to certain conditions specified in
the extension. The Extends relation is considered a special case of an inheritance
relationship, and thus the Extends line itself looks like an inheritance line, with an
<<Extends>> stereotype notation added to it.

12. The Uses line is drawn between Use Cases on a Use Case diagram. A Uses line from
Use Case One to Use Case Two signifies that an instance of Use Case One also includes
the behavior specified by Use Case Two. The Uses relation is considered a special case of
an inheritance relationship, and thus the Uses line itself looks like an inheritance line,
with a <<Uses>> stereotype notation added to it.

13. Application of use case diagrams :

A. To model the context of the system.
Modeling the context of a system involves drawing a line around the whole system and
asserting which actors lie outside the system and interacts with it.
To model context of the system make use of following steps :
1. Identify the actors that surround the system by considering which groups require help
from the system to perform their tasks; which groups are needed to execute systems’
function; which groups interacts with external hardware or other software systems;
and which groups perform secondary functions for administration and maintenance.
2. Organize actors that are similar to one another in a generalization and/or
specialization hierarchy.
3. Where it aids understandability, provide a stereotype for each such actor.
4. Populate a use case diagram with these actors and specify the paths of communication
from each actor to the systems’ use cases.
B. To model the requirements of the system.
Modeling the requirements of a system involves specifying what that system should do
(from a point of view of outside the system), independent of how that system should do
it. In this manner, a use case diagram lets you view the whole system as a black box; you
can see what’s outside the system and you can see how that system reacts to the things
outside, but you can’t see how that system works on the inside.

9
To model requirements of a system make use of following steps:
1. Establish the context of the system by identifying the actors that surround it.
2. For each actor, consider the behavior that each expects or requires the system to
provide.
3. Name these common behaviors as use cases.
4. Factor common behavior into new use cases that are used by others; factor variant
behavior into new use cases that extend more main line flow.
5. Model these use cases, actors and their relationships in use case diagram.
6. Adorn these use cases with notes that assert nonfunctional requirements; you may
have to attach some these to the whole system.

15. Validation Techniques:

When you create use case diagrams in UML, remember that it is just a graphical
presentation of the static use case view of the system. This means that no single use case
diagram need capture everything about a systems’ use case view.
Following is list of the points that should be verified for use case diagrams:
1. Whether the use case diagram is focused on communicating one aspect of a systems’
static use case view?
2. Whether use case diagram contains only those use cases and actors that are essential
to understand that aspect?
3. Whether use case diagram is consistent about exposing only those adornments that
are essential to understand?
4. Whether use case diagram isn’t minimalist about misinforming the reader about
semantics that are important?
5. Whether use case diagram layout is simple with minimum line crossing?
6. Whether use case diagram isn’t containing too many kinds of relationships?
7. Whether time ordering of the use cases isn’t indicated in use case diagram?
8. Whether use cases are not treated as functions?
System
9. Whether there are no arrowheads on the associations?
T ask_1 T ask_2
If answers to all the above queries are yes then the use case diagram is well structured use
case diagram.
Actor_1 Actor_2

System Context Diagram T ask_3 T ask_4

10
System Requirement Capture Diagram
System

Requirement_1 Reuirement_2
<<extend>>
Actor_1 Actor_2

<<include>>
<<include>>

Requirement_3 Requirement_4

Assignment Number: 4

11
Title : Activity Diagram

Problem Statement : To specify the dynamic behavior of the target system.

Activity Diagram should encompass
a) Initial state
b) Action
c) Sub-activity
d)Fork and join
e) Final State

Description :
1. Intended for applications that need control flow or object/data flow models For
example: business process modeling and workflow.

2. Action
An action is used for anything that does not directly start another activity graph, like
invoking an operation on an object, or running a user-specified action.
However, an action can invoke an operation that has another activity graph as a
method (possible polymorphism).

3. Sub-activity
A sub-activity (state) starts another activity graph without using an operation.
Used for functional decomposition, non-polymorphic applications, like many
workflow systems.
The invoked activity graph can be used by many sub-activity states.

4. Action/Subactivity (Dynamic Concurrency)

Applies to actions and subactivities.
Not inherited from state machines.
Invokes an action or subactivity any number of times in parallel, as determined by an
expression evaluated at runtime. Expression also determines arguments.
Upper right-hand corner shows a multiplicity restricting the number of parallel
invocations.
Outgoing transition triggered when all invocations are done.
Currently no standard notation for concurrency expression or how arguments are
accessed by actions. Attach a note as workaround for expression. Issue for UML 2.0.

5. Class/ State
A special sort of step (state) that represents the availability of a particular kind of
object, perhaps in a particular state.
No action or subactivity is invoked and control passes immediately to the next step
(state).
Places constraints on input and output parameters of steps before and after it.

6. Condition:

12
 Decision point and merge are inherited from state machines. For modeling
conventional flow chart decisions.

7. Synch state
is inherited from state machines but used mostly in activity graphs. Provides
communication capability between parallel processes.

8. Forks and joins

Forks and joins do not require composite states. Synch states may be omitted for the
common case (unlimited bound and one incoming and outgoing transition).

9. Swimlanes :
Swimlanes are the notation for partitions. They do not provide domain-specific
semantics. Tools can generate swimlane presentation from domain-specific
information without partitions.

10. When to Use activity Diagram

Use activity diagrams when the behavior you are modeling...
• does not depend much on external events.
• mostly has steps that run to completion, rather than being interrupted by
events.
• requires object/data flow between steps.
• is being constructed at a stage when you are more concerned with which
activities happen, rather than which objects are responsible for them
(except partitions possibly).

11. Modeling Tips

• Control flow and object flow are not separate. Both are modeled with state
transitions.
• Dashed object flow lines are also control flow.
• You can mix state machine and control/object flow constructs on the same
diagram (though you probably do not want to).
• Activity diagrams inherit from state machines the requirement for well-structured
nesting of composite states.
• This means you should either model as if composite states were there by matching
all forks/decisions with a correspond join/merges …
• Check that the diagram can be translated to one that is well-nested.
• This insures that diagram is executable under state machine semantics.

Activity Diagram

13
 Telesale
Customer Accounting Warehouse
s

Request
Return Get
Return
Number
Ship
Item
Receive
Item

Item
[returned]
Restock
Item

Credit Item
Account [available]

Activity Diagram Continued…

14
 Customer Telesales Accounting Warehouse

Request
Return

Get Return
Number

Ship Item

Item Receive
Item
[returned]

Restock
Item

Credit Item
Account [available]

15
Assignment Number : 5

Title : Sequence Diagram

Problem Statement : To depict the dynamic behavior of the target system using
sequence diagram The model should depict:
a) Discrete, distinguishable entities(class).
b) Events (Individual stimulus from one object to another).
c) Conditional events and relationship representation.

Description:

A. To model flow of control by time ordering (sequence diagram) :

1. Set the context for interaction, whether it is a system, subsystem, operation, class or
scenario of a use case or collaboration.
2. Set the stage for the interaction by identifying which objects play a role in the
scenario. Lay them out on the sequence diagram from left to right, placing the more
important objects to the left and their neighboring objects to the right
3. Set the lifeline for each object. In most cases, object will persist through entire
interaction. For those objects that are created and destroyed during the interaction, set
their lifelines and explicitly indicate birth and deaths.
4. Starting with the message that initiates this interaction, lay out each subsequent
message from top to bottom between the lifeline, showing each message’s property,
as necessary to explain the semantics of the interaction.
5. If you need to visualize the nesting of messages or the points in time when actual
computation is taking place, adorn each object’s lifeline with its focus of control.
6. If you need to specify time or space constraints, adorn each message with a timing
mark and attach suitable time or space constraint.
7. If the flow of control is to be specified more formally, attach preconditions and
postconditions to each message.

 A sequence diagram is a graphical view of a scenario that shows object interaction in

a time-based sequence¾what happens first, what happens next. Sequence diagrams
establish the roles of objects and help provide essential information to determine class
responsibilities and interfaces. This type of diagram is best used during early analysis
phases in design because they are simple and easy to comprehend. Sequence
diagrams are normally associated with use cases.
 Sequence diagrams are closely related to collaboration diagrams and both are
alternate representations of an interaction. There are two main differences between
sequence and collaboration diagrams: sequence diagrams show time-based object
interaction while collaboration diagrams show how objects associate with each other.

 A sequence diagram has two dimensions: typically, vertical placement represents

time and horizontal placement represents different objects.

16
 The following tools located on the sequence diagram toolbox enable you to model
sequence diagrams:

a. Object

b· Message Icons

c· Focus of Control

d. Message to Self

e· Note

f· Note Anchor

 An object has state, behavior, and identity. The structure and behavior of similar
objects are defined in their common class. Each object in a diagram indicates some
instance of a class. An object that is not named is referred to as a class instance.

 If you use the same name for several object icons appearing in the same collaboration
or activity diagram, they are assumed to represent the same object; otherwise, each
object icon represents a distinct object. Object icons appearing in different diagrams
denote different objects, even if their names are identical. Objects can be named three
different ways: object name, object name and class, or just by the class name itself.

 A message icon represents the communication between objects indicating that an

action will follow. The message icon is a horizontal, solid arrow connecting two
lifelines together. The following message icons show three different ways a message
icon can appear: message icon only, message icon with sequence number, and
message icon with sequence number and message label.

 Each message icon represents a message passed between two objects, and indicates
the direction of message is going. A message icon in a collaboration diagram can
represent multiple messages. A message icon in a sequence diagram represents
exactly one message.

 You may specify the name of a message through the message specification, or by
right-clicking on the message icon to display the shortcut menu of a message.

 You can adjust the position of a message icon by selecting it and dragging it to a new
location. This action moves the icon, the names of any operations, and the sequence
numbers to the new location.

 You can reposition the message labels by selecting one and dragging to a new
location. This action moves the message labels only; the message icon is not moved.

17
 You can enhance a message by attaching a script to the message. The script will
remain aligned with the message regardless of any changes in the position of the
message. Scripts are attached to a message by clicking Edit >
 Attach Script.

 The default message synchronization icon is "simple." To change the synchronization

type, select a type from the synchronization field in the message specification. The
following synchronization types are supported:

· Simple

· Synchronous

· Balking

· Timeout

· Asynchronous

· Procedure Call

· Return
 A Message to Self is a tool that sends a message from one object back to the same
object. It does not involve other objects because the message returns to the same
object. The sender of a message is the same as the receiver.

Validation Techniques :

A. Sequence diagram :
1. Identify the scope of the sequence diagram. Identify what you are trying to model.
Identify the basic course of action for single use case.
2. Check the sequence of the objects and their lifelines.
3. Check the ordering of the messages from top to bottom.
4. Check the preconditions and postconditions to be appropriate.

18
Sequence Diagram

Traveler : Booking System Client Account DBMS Airline Reservation System

change flight itinerary
get customer account

get itinerary
present itinerary

select segment

present detailed info

update information
available flight

:
:

19
Assignment Number : 6

Title : State Chart Diagram

Problem Statement : To depict the state transition with the life history of objects of a
given class model. The model should depict :
a)Possible ways the object can respond to events from other objects.
b)Determine of start, end, transition states.

Description :
1. The state diagram depicts the behavior of the system over time. It is typically drawn
for every class in the system that contains significant dynamic behavior.
2. The behavior of the class is modeled in terms of what states it is in at various times,
what actions it performs while in various states and when it transits from state to state
based on events in the system.
3. States represents the conditions of objects at certain points in time. Events represents
the incidents that cause objects to move from one state to another.
4. Each transition is labeled with the event that causes the transition. Actions occur
when an object arrives in a state.
5. State
A state symbol represents a state that an object is in at a particular time. While in the
state, the object satisfies some condition, performs some action, or waits for some event.
The state symbol is drawn as a rounded box containing the following information:
State name.Operation performed by the state preceded by the phrase do:Entry action
preceded by the phrase entry/Internal actions of the state exit action preceded by the
phrase exit/.
Initial State:The initial state symbol is represented by a large black circle. Its label
usually contains initial conditions. A transition line is drawn from the initial state symbol
to the next state.
Final State: The final state symbol is represented by a circle surrounding a bullet.
6.An object that performs two or more tasks at the same time is modeled in a state
diagram by showing the concurrent substates that it is in. Control is split into the
concurrent substates, and merges later when all substates have executed.
Concurrent activities within a single composite, or superstate are shown by partitioning
the superstate into regions with dotted lines.

General format of statechart diagram :

Initiate → Stimulus → Event → Transition → Source → Target

Transitions :
A transition is a relationship between two states indicating that an object in the first state
will perform certain actions and enter the second state when a specified state occurs and
specified conditions are satisfied.On such a change of state, the transition is said to fire.

20
Until the transition fires, the object is said to be in the source state and after it fires it is in
the target state.

A transition has five parts:

Source state : The state affected by the transition; if an object is in source state, an
outgoing transition may fire when the object may receive the event trigger of the
transition and if the guard condition is satisfied.
Event trigger : The event whose reception by the object in the source state makes the
transition eligible to fire, providing its guard condition is satisfied.
Guard condition : A boolean expression that is evaluated when the transition is triggered
by the reception of the event trigger. If the expression evaluates true, the transition is
eligible to fire; if the expression evaluates false, the transition doesn’t fire and if there is
no other transition that could be triggered, event is lost.
Actions : These are executable atomic computations that may directly act upon the object
that owns the state machine and indirectly act on other objects that are visible to the
object.
Target state : The state is a active after the completion of the transition.

Substates :
A substate is a state that is nested inside another one.
Sequential substates : It partitions the state space of the composite state into disjoint
states. These are most commonly found in nesting substates.
History states : A history state allows a composite state that contains sequential substates
to remember the last substate that was active in it prior to the transition from the
composite state. In this way the dynamic aspects of an object whose current behavior
depends on its past can be modeled.
Concurrent substates : These allow specifying two or more state machines that execute in
parallel in the context of enclosing object.

Steps for modeling reactive objects :

1. Choose the context for the state machine, whether it is a class, a use case or the
system as a whole.
2. Choose the initial and final states for the object. State the pre and post-conditions of
initial and final states.
3. Decide on the stable states of the object by considering the conditions in which the
object may exist for some identifiable period of time.
4. Decide on meaningful partial ordering of stable states over life time of the object.
5. Decide on events that may trigger a transition from state to state.
6. Check that all the states are reachable under some combination of events.
7. Check that no state is a dead end from which no combination of events will have
transition of the object out of that state.
Steps for modeling lifetime of an object :

• Set the context for the state machine, whether it is a class, a use case or the system as
a whole.

21
 1. If the context is a class or a use case, collect the neighboring classes,
including any parents of the class and any classes reachable by associations or
dependencies. These neighbors are candidate targets for actions and tentative for
inclusion in the guard condition.
2. If the context is the system as a whole, behavior of the system should be
emphasized.
• Establish the initial and final states for the object.
• Decide on the events to which the object may respond.
• Identify the initial / creation state.
• Identify the final states.
• Identify as many “real world” states as possible.
• Identify potential substates.
• Identify transitions leaving a state.
• Identify the target state to which a transition leads.

Validation techniques:
Steps for validating statechart diagrams :
1. Check the diagram for simplicity. (unwanted states/transitions are eliminated)
2. Check whether the diagram is deeply nested and understandable.
3. Check the crossing of transitions.

Reference Terms:
• A state machine specifies the sequence of states an object goes through during its
lifetime in response to events, together with its response to those events.
• A state is a condition or situation in the life of object during which it satisfies some
condition, performs some activity or waits for some events.
• An event is a specification of a significant occurrence that has a location in time and
space. In the context of state machines an event is an occurrence of a stimulus that
can trigger a state transition.
• A transition is a relation between two states indicating that an object in the first state
will perform certain actions and enter the second state when a specified event occurs
and specified condition satisfied.

Section of State Chart:

1. State description :

State Name Entry Exit do Action

2. Event description :

Event From State To state Guard

Condition

22
bid [value < 100] /reject

bid [value >= 200] /sell

Selling Happy

bid [(value >= 100) & (value < 200)] /sell

Unhappy

STATECHART DIAGRAM for Withdrawal Transaction

23
Assignment No: 7
Title: CRC Cards

Problem Statement: To prepare Class Collaboration-Responsibility (CRC) cards for the

Conceptual classes traced from System analysis phase.

CRC Technique:

CRC (Class-Responsibility-Collaborator) Card Modeling is a simple yet powerful object-

oriented analysis technique. CRC modeling often includes the users, analysts, and
developers in a modeling and design process, bringing together the entire development
team to form a common understanding of an OO development project.
It is one of many tools that should be used in the collaborative design of a system.
Kent Beck and Ward Cunningham first introduced CRC cards at OOPSLA ’89 in their
paper “A Laboratory for Teaching Object-Oriented Thinking”. Originally their purpose
was to teach programmers the object-oriented paradigm. The technique has since been
refined to become valuable beyond the education curriculum.
A CRC Model is a collection of cards (usually standard index cards or larger) that are
divided into three sections.
1. Class
2. Responsibility
3. Collaborator
The back of the CRC card is often used for a more detailed description of the class.
Along with any other notes captured during the CRC session. Many times these include
the actual attributes of the class.
Class
A Class represents a collection of similar objects. Objects are things of interest in the
system being modeled. They can be a person, place, thing, or any other concept important
to the system at hand. The Class name appears across the top of the CRC card.
Responsibility
A Responsibility is anything that the class knows or does. These responsibilities are
things that the class has knowledge about itself, or things the class can do with the
knowledge it has.
For example, a person class might have knowledge (and responsibility) for its name,
address, and phone number. In another example an automobile class might have
knowledge of its size, its number of doors, or it might be able to do things like stop and
go. The Responsibilities of a class appear along the left side of the CRC card.
Collaborator
A Collaborator is another class that is used to get information for, or perform actions for
the class at hand. It often works with a particular class to complete a step (or steps) in a
scenario. The Collaborators of a class appear along the right side of the CRC card. The
CRC team is comprised of different types of people involved in the project. The overall
size of the CRC team is important, and active participants should be limited to 6.

24
Interaction between active participants grows experientially with the number candidates.
There are generally three types of skill sets for active participants in the CRC session.
1. Domain Users
2. OO Design Analyst
3. Facilitator
Additional non-active participants can include a scribe and observers.
Domain Users (3-5 people)
These members of the CRC team are the users of the system being designed. They should
have a good amount of business domain knowledge for which the system is being
modeled.
Good domain users also have the following characteristics:
• Know the business being modeled.
• Think logically.
• Good communication skills.
• Are willing to invest the time in systems designs.
OO Design Analyst (1-2 people)
These members of the CRC team are analysts or developers familiar with OO
methodologies and techniques. Generally the design analysts have responsibilities on the
project well beyond the CRC modeling sessions.
These may include fleshing out the CRC cards to create a formal object model, and
interpreting the CRC collaborators to document the OID’s (Object Interaction Diagrams).
Good Design analyst have the following characteristics:
• Understand the CRC modeling process and methodology.
• Understand the OO modeling process and methodology.
• Experience developing OO systems.
Facilitator (1 person)
This is the member who runs the CRC session. This person is perhaps the most important
member of the team. It is the facilitator’s responsibility to keep the CRC session
progressing forward.
This may include acting as an intermediary when collaboration debates occur, and
generally making sure that the session is on track with regards to the agenda.
Good facilitators have the following characteristics:
• Good meeting skills.
• Understand the CRC modeling process and methodology.
• Understand the OO modeling process and methodology.

25
Scribe (1-2 people)
This is the member responsible for documenting any business logic and discussion that
isn’t captured on the CRC Cards themselves. Often analysis logic on why a process is the
way it is discovered within a CRC session, and should be captured and documented.
This documentation is often rolled back into the requirements and business case
documents, as well as used by the design analysts to further the systems object model.
Good scribes have the following characteristics:
• Listen extremely well.
• Good written communications skills
• Can identify business logic
Observers (0-N people)
These are members who aren’t directly participating in the CRC session. They are
generally other users of the system, or other project team members. It is important that
the facilitator ensure that these people are not active during the CRC session.
Good observers have the following characteristics:
• Know how to contain opinions during the modeling session, i.e.
shut-up.
Explaining the CRC Technique
The facilitator should begin by explaining the purpose of the CRC session. Remember
that scenario execution is at the heart of the CRC session. An explanation of the CRC
cards, as well as some sample CRC cards themselves can be created.
The concept of role playing techniques should be covered. Role-playing involves acting
out what a class does in order to facilitate the scenario execution. A person who owns a
particular card should 'become' that class when control of the scenario is passed to them.
This is often done by holding the card in the air while the class has control of the
execution. This way, a card is an object while being held in the air, and a card is a class
while resting on the table.
Selecting a Scenario
One scenario should be selected to begin the CRC session. Often an initial brainstorming
time can be set aside at the beginning of the session to discuss and identify an appropriate
scenario.
The scenario chosen should be well documented and very specific. Any related scenario's
should be modeled separately. Often it is desirable to choose an easy scenario to begin
with.
If there are already use-case’s diagrams or descriptions for the problem domain, a good
scenario is any 'normal coarse' through one of these 'use cases'. Using just the ‘normal
coarse’ ensures that the session focuses on one particular scenario, and not the entire use
case.
Creating Initial CRC Card(s)
Initial CRC cards can be created for any class identified during the scenario selection.
CRC cards are also created for existing classes in the system. Often these classes are the
result of an existing legacy system.

26
Further brainstorming is an option depending on the experience level of the CRC session
participants.).
Arranging the CRC Cards
As CRC cards are created, they are often placed on a centralized table for all participants
to see. Once collaborations are established between classes, the arrangement of the
classes can be moved so that collaborating classes are in close proximity to each other.
The more that two classes collaborate throughout the session, the closer they should be
placed to each other.
In the initial stages of the CRC session, you can expect that the location of the classes on
the table move quite frequently. This is typical of card placement, and will settle down
after collaboration become more established.
It is often helpful to put the busy cards towards the center of the table, and those less busy
cards around the outside perimeter. While the importance of card placement is subtle,
beware of just choosing a card location because there is empty space on the table.
If the table fills up quickly during a scenario execution, the quite possibly the scenario
chosen is overly complicated, or is not the primary coarse through a 'use case'.

The CRC Interview

It is often useful to start the session using the interview technique, or new employee
technique. The interview technique involves identifying a scenario, then identifying a
user that asks a ‘starting’ class to perform the scenario. The class in turns asks questions
(interviews) the requester (user) to get enough information to perform the task.
The user can respond with the information, or respond that the class should know that
information. The class can create a responsibility, or collaborate with other classes to get
the information it requires.
Finding Classes
A Class represents a collection of similar objects. Objects are things of interest in the
system being modeled. They can be a person, place, thing, or any other concept important
to the system at hand.
There are many ways to identify classes. One of the easiest to start with is noun
extraction. Noun extraction identifies all of the Nouns in a problem statement and/or use-
case scenario. The nouns extracted make excellent candidate classes.
Other ways to identify classes are to look for items that interact with the system, or things
that are part of the system. Ask if there is a customer of the system, and identify what the
customer interacts with. Screens and reports represent interface classes, but for the sake
of a CRC session, a single GUI class can represent these.
If a class can’t be named with less than three words, then it’s probably not a class but a
responsibility of another class.
Finding Responsibilities
A Responsibility is anything that the class knows or does. These responsibilities are
things that the class has knowledge about itself, or things the class can do with the
knowledge it has.

27
To compliment the 'Noun Extraction' technique above is verb extraction. Verb extraction
identifies all of the verbs in a problem statement and/or use-case scenario. These are
usually good indicators of actions that must be performed by the classes of the system.
Other techniques included asking what the class knows, and what information must be
stored about the class to make it unique. Ask what the class does, and then flesh out how
the class might do it.
Finding Collaborators
Collaboration occurs when a class needs information that it doesn’t have. Classes know
specific things about themselves. Very often to perform a task a class needs information
that it doesn't have. Often it's necessary to get this information from another class, in the
form of collaboration.
Collaboration can also occur if a class needs to modify information that it doesn’t have.
One property of information that a class knows about itself is the ability to update the
information. Often a class will want to update information that it doesn't have. When this
happens, the class will often ask another class, in the form of a collaboration, to update
the information for it.
Generally for a collaboration to occur, one class is the initiator. In other words, there has
to be a starting point for collaboration. Often times the initiating class is doing very little
work beyond initialing the collaboration itself.
Facilitation Tips
CRC Definitions
It is often helpful to write CRC definitions on flip chart paper and post them in plain view
around the room. These definitions can include an example of the CRC card, both blank
and a completed example.
Scenario Execution
Always go back to the original scenario being modeled when questions arise. The entire
CRC session should always focus on the scenario being executed.
OO Terminology
Keep the technical OO terminology to a minimum. Always talk in terms of the users
domain and business knowledge.
Low Tech
Always keep the CRC session low-tech (i.e. Index cards, flip chart paper, etc.). Using
low-tech techniques is one of the success factors of CRC sessions.
Keep it Fun
Keep the atmosphere fun and playful. This is one of the reasons for using role-playing
techniques.
Set Expectations
New users to CRC modeling should not expect immediate results. As sessions continue,
they become easier. Expect the first few classes and collaborations to be followed by lots
of discussion. It’s up to the facilitator to regulate this efficiently.

28
A class that is never instantiated into an object. Abstract Class
An interesting property of a class. Usually in the
Attribute
form of a value.
A representation of a collection of similar
objects. Classes are often objects, representing a Class
person, place, or thing.
A class that provides information or performs an
Collaborator
action for another class.
An instance of a particular class. While a class
may represent people, an object represents one Object
particular person.
Anything a class knows or does. Responsibility
A class that may become a permanent class in
Candidate Class
the system after further analysis.

Class Responsibility Collaboration Template:

Class Name
Class Type
Characteristics
Superclass
Subclass
Variables
Services
Responsibilities Collaborators

29
Assignment Number: 8

Title: Class Diagram

Problem Statement: To develop logical static structure of target system with the help of
Class diagram. The model should depict
a) Relationship between classes (inheritance, Assertion, Aggregation,
Instantiation)
b) Identification of objects and their purpose.
c) Roles / responsibilities entities that determine system behavior.

Description:
 A class is a set of objects that share a common structure and common behavior (the
same attributes, operations, relationships and semantics). A class is an abstraction of
real-world items. When these items exist in the real world, they are instances of the
class and are referred to as objects.
For each class that has significant temporal behavior, you can create an activity
diagram or a statechart diagram to describe this behavior.
Graphical Depiction
A class icon is drawn as a 3-part box, with the class name in the top part, a list of
attributes (with optional types and values) in the middle part, and a list of operations
(with optional argument lists and return types) in the bottom part.

Inheritance Techniques:
• Look at the similarities
• Look for existing classes
• Follow sentence rule (IS A, IS A KIND OF, IS LIKE A).
• Avoid implementation inheritance.
• Any kind of class can inherit from any other kind.
• Beware of multiple inheritances.
• Beware of inheritance based only on common data attributes.
• Superclasses should know nothing of their subclasses.
• A subclass should inherit everything.

Aggregation Techniques:
• Apply sentence rule (PART OF).
• It should be a part in the real world.
• You should be interested in both whole and part.

30
• Show multiplicity and roles.
• The majority of the interaction is from the whole to the part.
• Aggregation is inherited.
Attributes and Methods:

Approach towards attributes:

Getter: A method to obtain the value of a data attribute of an object or class.
Setter: A method that sets a value of a data attribute of an object or class.
• Assign private visibility to all attributes.
• Update attributes only in their setter methods
• Directly access attributes only in getter methods
• Always invoke a setter method for an attribute to update its value, even within the
class where it is defined.
• Always invoke a setter method for an attribute to obtain its value, even within the
class where it is defined.
• Implement simple validation logic for an attribute in its setter method.

UML Attributes visibility

Visibility symbol description proper usage
public + It can be accessed by any other method in Don’t make
any other object or class attributes public.
Protected # It can be accessed by any method in the Don’t make
class in which it is declared or by any attributes protected.
method defined in subclasses of that class
private - It can only be accessed by method in the All attributes should
class in which it is declared, but not in the be private.
subclasses.

UML Method visibility

Visibility symbol description proper usage
public + It can be invoked by any other method in accessible outside
any other object or class class hierarchy
Protected # It can be invoked by any method in the Accessible within
class in which it is declared or by any class hierarchy.
method defined in subclasses of that class
private - It can only be invoked by method in the Access is specific to
class in which it is declared, but not in the a class.
subclasses.

 A class diagram is a picture for describing generic descriptions of possible systems.

Class diagrams and collaboration diagrams are alternate representations of object
models. Class diagrams contain classes and object diagrams contain objects, but it is

31
 possible to mix classes and objects when dealing with various kinds of metadata, so
the separation is not rigid.

 Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data
structures or message-passing structures.

 Class diagrams contain icons representing classes, interfaces, and their relationships.
You can create one or more class diagrams to depict the classes at the top level of the
current model; such class diagrams are themselves contained by the top level of the
current model. You can also create one or more class diagrams to depict classes
contained by each package in your model; such class diagrams are themselves
contained by the package enclosing the classes they depict; the icons representing
logical packages and classes in class diagrams.

 You can change properties or relationships by editing the specification or modifying

the icon on the diagram. The associated diagrams or specifications are automatically
updated.

During: Use-Class Diagrams To:

Analysis Show common roles and responsibilities of the entities that provide the
system's behavior.

Design Capture the structure of the classes that form the system's architecture.

 An association provides a pathway for communication. The communication can be

between use cases, actors, classes or interfaces. Associations are the most general of
all relationships and consequentially the most semantically weak. If two objects are
usually considered independently, the relationship is an association

Graphical Depiction
An association relationship is an orthogonal or straight solid line with an arrow at one
end:

Naming
The association name and its stereotype is typically a verb or a verb phrase and is
used to identify the type or purpose of the relationship.

Understanding the Client/Supplier Roles of Associations

The rules regarding the client and supplier roles of associations are listed in their
order of precedence:

If an association is an aggregation, the diamond end is the client. Navigability on

either end of the association will not affect the client role of the aggregation. For
instance, the diamond will still be the client if you set both ends to "not navigable" or

32
 if you set the end with the aggregate diamond to an arrowhead. The diamond will
take precedence to navigability if there is at least one end is not navigable.
The end opposite to the aggregation diamond in an aggregation association can act as
a client if it can navigate to the end with the diamond. This does not contradict the
first rule because the item connected to the end opposite to the diamond can navigate
to the diamond and, therefore, it is a client by definition.
If the association is not an aggregation, then the navigability will determine the client
and supplier end. For a uni-directional association, the client is the end opposite to
the arrowhead and the supplier is the end with the arrow. For a bi-directional
association, either end can be both client and supplier at the same time.
An association can be both a client and a supplier at the same time subject to the
restrictions mentioned in the first three rules.
If the association is not an aggregation and both ends are not navigable, it is neither a
client nor a supplier."
Adornments
You can assign a variety of adornments and properties to association relationships
through the Association Relationship Specification. They include: derived, name
direction, documentation, roles, cardinality, navigability, aggregate, static, friend,
access, containment, association and role constraints, link elements, and qualifiers.
 Cardinality:
Cardinality specifies how many instances of one class may be associated with a single
instance of another class. You can indicate cardinality for classes and relationships.
When you apply a cardinality adornment to a class, you are indicating the number of
instances allowed for that class.
When you apply a cardinality adornment to a relationship, you are indicating the number
of links allowed between one instance of a class and the instances of the another class.

Valid Values
The following cardinality values apply to both classes and relationships. Values are
presented in lower-bound upper bound format. Literals stand for any number and must
be typed in using the appropriate specification. Literals are not available on the pull down
or shortcut menu.
Value Description
0..0 Zero
0..1 Zero or one
0..n Zero or more
1..1 One
1..n One or more
n Unlimited number
<literal> Exact number (Example: 21)
<literal>..n Exact number or more (Example: 21..n indicating 21 or more)
<literal>..<literal> Specified range (Example: 21..45)

33
<literal>..<literal>, <literal> Specified range or exact number (Example: 21..45)
<literal>..<literal>, <literal>..<literal> Multiple specified ranges
(Example: 21..45, 50..60)
Class Cardinality
You can specify cardinality for a class or parameterized class. The default cardinality is
"n." To set a specific cardinality value for the class, type the applicable value(s) in the
Cardinality field of the specification. Class cardinality is not displayed on the diagram.

Relationship Cardinality
You can set a specific cardinality value for either one or both roles on the applicable
relationship specification. To set the cardinality for Role A, type a value in the
Cardinality field of the RoleA Detail tab. To set the cardinality for RoleB, type a value in
the Cardinality field of the RoleB Detail tab.
The default cardinality is "unspecified." A cardinality of "n" is displayed as a "*" on the
class diagram.

A dependency is a relationship between two model elements in which a change to one

model element will affect the other model element. Use a dependency relationship to
connect model elements with the same level of meaning. Typically, on class diagrams, a
dependency relationship indicates that the operations of the client invoke operations of
the supplier.

You can connect model elements with dependencies on any diagram except state machine
diagrams and object diagrams. For example, you can connect a use case to another use
case, a package to another package, and a class to a package. Dependencies are also used
on component diagrams to connect model elements.

Validation Techniques:
A well-structured class diagram:

• Is focused on communicating one aspect of a system’s static design view.

• Contains only elements that are essential to understand that aspect.
• Provides detail consistent with its level of abstraction, with only those adornments
that are essential to understand.
• Is not so minimalist that it misinforms the reader about important semantics.

34
 Class_1 Class_2

+ Attribute List : int

"Operation List" persistent

persistent Associati o
2..*

Class_3 Class_4 Class_5 Class_6

+ Attribute List : int + Attribute List : int

"Operation List" "Operation List"

persistent persistent

persistent persistent

Class_7 Class_8

Dependency_1

persistent persistent

35
Assignment Number: 9

Title: Component Diagrams

Problem Statement: To represent physical module that provides occurrence of classes or

other logical elements identified during analysis and design of system using Component
diagram. The model should depict allocation of classes to modules.

Description:

Component Diagrams:

 Component diagrams provide a physical view of the current model. A component

diagram shows the organizations and dependencies among software components,
including source code components, binary code components, and executable
components. These diagrams also show the externally-visible behavior of the
components by displaying the interfaces of the components. Calling dependencies
among components are shown as dependency relationships between components and
interfaces on other components. Note that the interfaces actually belong to the logical
view, but they can occur both in class diagrams and in component diagrams.

Component diagrams contain:

· Component packages

· Components

· Interfaces

· Dependency relationships

 You can create one or more component diagrams to depict the component packages
and components at the top level of the component view, or to depict the contents of
each component package. Such component diagrams belong to the component
package that they depict.

 A component represents a software module (source code, binary code, executable,

DLL, etc.) with a well-defined interface. The interface of a component is represented
by one or several interface elements that the component provides. Components are
used to show compiler and run-time dependencies, as well as interface and calling
dependencies among software modules. They also show which components
implement a specific class.

36
 A system may be composed of several software modules of different kinds. Each
software module is represented by a component in the model. To distinguish different
kinds of components from each other, stereotypes are used.

Naming:
Typically, a component name is the name of a file that the component represents. Each
component is also assigned a programming language.

Relationships:
You can draw a dependency relationship from a component to another component. This
type of dependency relationship means that the classes contained in the client component
can inherit from, contain instances of, use, and otherwise depend on classes that are
exported from the supplier component.
You can draw a dependency relationship from a component to an interface of another
component, which means that the client component uses the operations of the other
component. You can also draw a realize relationship from a component to an interface of
another component, which means that the client component provides the operations of the
other component.

Graphical Depiction:
A component icon is drawn as a large rectangle with two smaller rectangles attached to
its left side. An interface circle attached to the component icon means that the component
supports that particular interface. That is, there is no explicit relationship arrow between a
component and its interfaces.

 Component Package Specification :

A Component Package Specification enables you to display and modify the properties of
a component package. Similarly, a Component Specification and a Class Specification
enables you to display and modify the properties of a component and an interface,
respectively. The information in these specifications is presented textually. Some of this
information can also be displayed inside the icons representing component packages and
components in component diagrams, and interfaces in class diagrams.

You can change properties of, or relationships among, component packages, components,
and interfaces by editing the specification or modifying the icon on the diagram. The
affected diagrams or specifications are automatically updated.

 Dependency Relationship:
The dependency relationship indicates that one entity in a component diagram uses the
services or facilities of another.
Dependencies in the component diagram represent compilation dependencies. The
dependency relationship may also be used to show calling dependencies among
components, using dependency arrows from components to interfaces on other
components.

37
Draw a dependency relationship between two classes, or between a class and an interface,
to show that the client class depends on the supplier class/interface to provide certain
services, such as:

The client class accesses a value (constant or variable) defined in the supplier
class/interface.

· Operations of the client class invoke operations of the supplier class/interface.

· Operations of the client class have signatures whose return class or arguments are
instances of the supplier class/interface.

A dependency is a relationship between two model elements in which a change to one

model element will affect the other model element. Use a dependency relationship to
connect model elements with the same level of meaning. Typically, on class diagrams, a
dependency relationship indicates that the operations of the client invoke operations of
the supplier.

You can connect model elements with dependencies on any diagram except state machine
diagrams and object diagrams. For example, you can connect a use case to another use
case, a package to another package, and a class to a package. Dependencies are also used
on component diagrams to connect model elements.

 Component Packages:
Component packages represent clusters of logically related components, or major pieces
of your system. Component packages parallel the role played by logical packages for
class diagrams. They allow you to partition the physical model of the system.

Naming:
Typically, a component package name is the name of a file system directory.

Relationships:
A component package can have dependencies with other component packages,
components, and interfaces.

Graphical Depiction:
The component package is a folder shaped icon:

A Component Specification enables you to display and modify the properties and
relationships of each component in the current model. The same specification form is
used for all component stereotypes.

 Package :

38
A package is a general-purpose model element that organizes model elements into
groups. A system may be thought of as a single, high-level package, with everything else
in the system contained in it. You can also turn packages into controlled units.

Graphical Depiction:
A package is a folder shaped icon:
Relationships:
You can draw a dependency relationship from a package to another package. This type of
dependency relationship means that the classes contained in the client package can inherit
from, contain instances of, use, and otherwise depend on classes that are exported from
the supplier package. You can also draw a realization relationship from a package to an
interface.

Adornments:
If a package contains a number of common classes that are used by most packages in the
model, you can apply the global adornment to the lower-left corner of the package icon
instead of placing icons representing these common classes in many top-level diagrams.

To indicate a global package, click on the Global check box on the Detail tab of the
Package Specification.

Subprogram components correspond to subroutine declarations. Subprograms generally

contain single or grouped subroutines; they do not contain class definitions.

Task components represent packages with independent threads of control. If tasks are
compiled differently than regular packages, you can allocate a class definition to a task.

39
Figure 1. UML 2.x component diagram.

40
Assignment Number: 10

Title: Architecture Diagram

Problem Statement: To represent deployment view of the system

Description:

1. Models the run time Architecture of the system

2. Describes the mapping of the system to processing nodes
3. Deployment Diagrams show:
Nodes: computational resources (e.g. processors)
Relationships: means of communication among nodes (e.g., network)
Common network configurations use three-tier architecture
Clients (user interactions)
Database functionality
Business/application logic
4. client/server –> special case of three-tier architecture where business/application
logic is relocated to one of the other tiers
5. DEPLOYMENT MODEL — DESIGN ISSUES
• Which nodes are involved, and what are their capacities in terms of processing
power and memory size?
• What types of connections are between the nodes, and what communication
protocols will be used?
• What are the characteristics of the connections and communication protocols
(e.g., bandwidth, availability, quality, etc.)?
• Is there any need for redundant processing capacity, fail-over nodes, process
migration, keeping backup data, etc.?

41
Figure 1. UML 2.x Deployment diagram.

42