Laboratory Manual: Object Oriented Software Engineering

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA.
ACADEMIC YEAR-2013-14
DEPARTMENT OF COMPUTER ENGINEERING
LABORATORY MANUAL
Department
Of
Computer Engineering
PROF. R.SINGH
Object Oriented Software

Engineering
Semester : - VI
(Affiliated to Mumbai University, Mumbai and Approved by AICTE, New
Delhi)
Academic Year:
Name
Subject
Department
Roll No. Division
Semester Branch
Batch Exam No.

(Affiliated to Mumbai University, Mumbai and Approved by AICTE, New
Delhi)
Certificate
This is to certify that Mr./Ms._______________________

Roll no: _____Division:____ has completed term work
in the subject of _____________________________ for the
semester _____ of the academic year _________________.
Faculty InchaRG HOD Principal

Aims and objectives

1. To improve quality and result 100%
2. Practical facility and well equipment.
3. Internet facility.
4. Well teaching staff.
5. To provide department library facility.
6. To provide department study facility.
7. By giving personal attention towards students.
University of Mumbai
Branch : Computer Semester : VI
Class : T.E. Engineering
Subject : Object Oriented Software Engineering (OOSE)

Periods per Week Lecture 04
(each 60 min) Practical 02
Tutorial --
Hours Marks
Evaluation System Theory 03 100
Practical and Oral -- 50
Oral -- --
Team Work -- 25
Total 03 175
PREREQUISITES : Computer Network
Modu Contents Hou

le rs
1 1.1Software life cycle models : Waterfall ,RAD ,Spiral,Open – 04
source. Agile process.
1.2Understanding software process.
1.2.1 Process metric
1.2.2 CMM levels
2 2.1 Planning & Estimation 08

2.1.1 Product metrics
2.1.2 Estimation – LOC ,FP,COCOMO Models
2.2 Project management
2.2.1 Planning
2.2.2 Scheduling
2.2.3 Tracking
3 3.0 Workflow of Software Life cycle 22
3.1 Requirement Workflow
3.1.1 Functional ,Nonfunctional
3.1.2 Characterristics of Requirements
3.1.3 Requirement Elicitation Techniques
3.1.4 Requirement Documentation- Use case specification .
Activity Diagram.
3.2 Analysis Workflow
3.2.1 Static Analysis
3.2.1.1 Identifying Object – Methods of identifying objects
and types- Boundary Control Entry
3.2.1 Dynamic Analysis
3.2.1.1 Identifying Interaction – Sequence and
Collaboration diagrams ,State chart diagram.
3.3 Design Workflow
3.3.1 System Design Concept- Coupling and Cohesion
3.3.2 Architectural Styles
3.3.3 Identifying Subsystems and Interfaces
3.3.4 Design Patterns
4 4.1 Implementation Workflow 08
4.1.1 Mapping models to Code.
4.1.2 Mapping Object Models to Database Schema.
4.2 Testing
4.2.1 FTR – Walkthrough and Inspection
4.2.2 Unit Testing ,Integration,System and Regression
Testing .
4.2.3 User Acceptance Testing
5 5.1 Software Configuration Management 03
5.1.1 Managing and controlling Changes
5.1.2 Managing and controlling Versions.
6 6.1 Maintenance 03
6.1.1 Types of Maintenance
6.1.2 Maintenance Log and Detect reports .
6.1.3 Reverse and re-engineering.
TEXT BOOKS:
1. Bernd Bruegge ,”Object Oriented Software Engineering “,Second Edition
,Pearson Education
2. Stephan R. Schach, “Object Oriented Software Engineering”, Tata McGraw
Hill.
3. Roger Pressman,”Software Engineering “,Sixth edition, Tata McGraw Hill.
REFERENCES :
1. Timothy C. Lethbridge,Robert Laganiere “Object Oriented Software
Engineering- A Practical software development using UML and Java
“,Tata McGraw Hill,New Delhi.
TOPICS FOR EXPERIMENT

1. At least two review assignments covering object oriented concepts.
2. Coding Assignments on Mapping models to Code
3. A full – fledged mini project in which a student will design an application
using OOAD case tool covering all the workflows with UML
Documentation .
4. Assignments on Design Patterns.
5. Working Assignments using Project Management tools .
6. Study of Configuration Management tool.
TERM WORK
Term work shall consist of at least 10 Assignments /programming assignments
and one written test.
Marks :
1.Attendence (Theory and Practical) 05 marks
2. Laboratory Work (Experiments and Journal ) 15 marks
3.Test (at least one ) 10 marks
The final certification and acceptance of TW ensures the satisfactory performance

of laboratory work and Minimum Passing in the term work.
PRACTICAL /ORAL EXAMINATION
A practical /oral examination is to be conducted based on the above syllabus.
List of Lab Assignments
Sr. No. Lab Assignment Hours

Introduction and Project Definition 2 Hours
1 ( Problem Statement) Project Planning
Software requirement Specification and Use

2 Hours
2 Case Diagram (for Course Registration
System)
3 Flow of Events and Activity Diagram 2 Hours

(for Course Registration System)
OO Analysis: Discovering Classes and

4 Creating Class Diagram 2 Hours
Interaction Diagram: Sequence and

Collaboration Diagram
5 2 Hours
State Transition Diagram
Component and Deployment Diagram

6 2 Hours
7 Mapping Model to code by converting above 2 Hours

diagrams into code
8 Requirement Workflow of student’s own 2 Hours

project
9 2 Hours
Analysis Workflow of student’s own project
10 Implementation Workflow of student’s own 2 Hours

project
11 Report and Project Submission 2 Hours

1. Introduction and Project
Definition
Experiment 1:
Aim:- Introduction and Project Definition
1. Outline
• Introduction to the lab plan and objectives.
• Project definition.
2. Theory
The software engineer is a key person analyzing the business, identifying
opportunities for improvement, and designing information systems to implement these
ideas. It is important to understand and develop through practice the skills needed to
successfully design and implement new software systems.
2.1 Introduction
• In this lab you will practice the software development life cycle (project
management, requirements engineering,systems modeling, software design,
prototyping, and testing) using CASE tools within a team work environment.
• UML notation is covered in this lab as the modeling language for analysis and design.
2.2 Tools Used in the Lab

• SWE lab is one of the most challenging of all labs. Developing a complete
software application requires from each of you a good level of know-how of various tools.
• There are some tools which will be taught, but there are some which are
assumed you already know, if you don’t, then you learn should it individually.
o MS Source Safe: for configuration management
o MS Project: for project planning/management
o Rational Rose: for UML diagrams (object oriented analysis and design)
o Rational Requisite Pro: for software requirement specification (SRS)
documentation.
o WinRunner: for testing software
2.3 Software Engineering Lab Objectives

• Learn the software life cycle phases (project management, requirements
engineering, software design, prototyping and testing).
• Practice the software phases using a project.
• Learn a number of CASE tools and use them in a project within a team work environment.
• Get familiar with UML (modeling language for analysis and design).
3. CASE Tools
No tools are used for this lab.
4. In-Class Example
Some examples of problem definition will be presented in the class.
5. Exercises
• Form groups of 3/4 students (with one of them as a leader).
• Brainstorm and list 5 suitable project titles.
• Present these to the class.
• Choose one of the projects from your list.
• Try to write (a hypothetical) project definition for it.
• Present it to the instructor/class.
6. Deliverables
• Form teams of 4 students for the term project.
• Suggest / research a project and write a project definition/problem statement.
7. Problem Statement for Course Registration System

As the head of information systems for Wylie College you are tasked with
developing a new student registration system. The college would like a new client-
server system to replace its much older system developed around mainframe
technology. The new system will allow students to register for courses and view
report cards from personal computers attached to the campus LAN. Professors will
be able to access the system to sign up to teach courses as well as record grades.
Due to a decrease in federal funding, the college cannot afford to replace the entire
system at once. The college will keep the existing course catalog database where
all course information is maintained. This database is an Ingres relational database
running on a DEC VAX. Fortunately the college has invested in an open SQL
interface that allows access to this database from college’s Unix servers. The
legacy system performance is rather poor, so the new system must ensure that
access to the data on the legacy system occurs in a timely manner. The new system
will access course information from the legacy database but will not update it. The
registrar’s office will continue to maintain course information through another
system.
At the beginning of each semester, students may request a course catalogue
containing a list of course offerings for the semester. Information about each
course, such as professor, department, and prerequisites, will be included to help
students make informed decisions.
The new system will allow students to select four course offerings for the
coming semester. In addition, each student will indicate two alternative choices in
case the student cannot be assigned to a primary selection. Course offerings will
have a maximum of ten students and a minimum of three students. A course
offering with fewer than three students will be canceled. For each semester, there is
a period of time that students can change their schedule. Students must be able to
access the system during this time to add or drop courses. Once the registration
process is completed for a student, the registration system sends information to the
billing system so the student can be billed for the semester. If a course fills up
during the actual registration process, the student must be notified of the change
before submitting the schedule for processing.
At the end of the semester, the student will be able to access the system to
view an electronic report card. Since student grades are sensitive information, the
system must employ extra security measures to prevent unauthorized access.
Professors must be able to access the on-line system to indicate which
courses they will be teaching. They will also need to see which students signed up
for their course offerings. In addition, the professors will be able to record the
grades for the students in each class.
8. Project Planning and Management
Project management is the process of planning and controlling the development of a

system within a specified timeframe at a minimum cost with the right functionality.
8.1 Risk Management

• Risk management is concerned with identifying risks and drawing up plans to
minimize their effect on a project.
• A risk is a probability that some adverse circumstance will occur.
• Project risks which affect schedule or resources.
• Product risks which affect the quality or performance of the software being
Developed.
• Business risks which affect the organization developing the software.
8.2 Risk Management Process

• Risk identification: identify project, product and business risks.
• Risk analysis: assess the likelihood and consequences of these risks.
• Risk planning: draw up plans to avoid or minimize the effects of the risk.
• Risk monitoring: monitor the risks throughout the project.
8.3 CASE Tools

• Microsoft Project is the clear market leader among desktop project
management applications.
• Primavera Project Planner: multi-project, multi-user project, and resource
planning and scheduling.
• SureTrak Project Manager: resource planning and control for small-to-medium
sized projects.
• According to the Gartner Group, it accounts for about two-thirds of all project
management software sales.
MS Project Jump Start Live Demo
8.4 In-Class Demo

Now you will learn how to apply the above mentioned methods to draw a Gantt chart
or Activity chart for the project. Please refer to Lab 3 slides which explain the process
in detail with some examples.
8.5 Exercises
Create a series of tasks leading to completion of a project of your choice.
For your project, you need to:
• Set start or ending dates.
• Develop a list of tasks that need to be completed.
• Establish any sub tasks and create links.
• Create any links between major tasks.
• Assign a specific amount time for each task.
• Assign resources for each task.
• Create task information for each item you put into the list.
8.6 Deliverables
You should create a plan and time schedule for your term project.
Experiment 2:
Aim:-Software requirement Specification and Use Case Diagram

(for ATM SYSTEM)
1. Outline
• Review of the requirements engineering process.
• Write requirements and specifications.
• RequisitePro tutorial.
• Software Requirement Specification (SRS).
2. Theory
A requirement is a statement of a behavior or attribute that a system must possess for
the system to be acceptable to a stakeholder. Software Requirement Specification
(SRS) is a document that describes the requirements of a computer system from the
user's point of view. An SRS document specifies:
• The required behavior of a system in terms of: input data, required processing,
output data, operational scenarios and interfaces.
• The attributes of a system including: performance, security, maintainability,
reliability, availability, safety requirements and design constraints.
Requirements management is a systematic approach to eliciting, organizing and
documenting the requirements of a system. It is a process that establishes and
maintains agreement between the customer and the project team on the changing
requirements of a system.
Requirements management is important because, by organizing and tracking the
requirements and managing the requirement changes, you improve the chances of
completing the project on time and under budget. Poor change management is a key
cause of project failure.
2.1 Requirements Engineering Process

Requirements engineering process consists of four phases:
• Requirements elicitation: getting the customers to state exactly what the
requirements are.
• Requirements analysis: making qualitative judgments and checking for
consistency and feasibility of requirements.
• Requirements validation: demonstrating that the requirements define the
system that the customer really wants.
• Requirements management: the process of managing changing requirements
during the requirements engineering process and system development, and
identifying missing and extra requirements
Software Requirements
Specification
Course Registration System
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
Object Oriented Software Engineering
The SRS Report includes the following documents which you have to create in
Requisite Pro.
1) Vision and Feature Document
2) Stakeholders request and needs Documents
3) Glossary Document
4) Use case specification Document
5) Supplementary requirement Document
6) Business Rule Document
7) Risk Document
8) Requirement Management plan Document
3. CASE Tools
RequisitePro is a powerful, easy-to-use requirements management tool that helps
teams manage project requirements comprehensively, promotes communication
and collaboration among team members, and reduces project risk. It thereby
increases the chances of delivering a product that the client wants and does so in
a timely manner. RequisitePro offers the power of a database and Microsoft
Word and is integrated with other Rational Suite products.
4. In-Class Demo
An overview of the basic features of RequisitePro will be presented. In the
exercise section you will practice and apply what you have learned in the
tutorial.
5. Exercises
a. Perform each of the following tasks using RequisitePro:
o Create a new project.
o Create a new package.
o Create and add some requirements within RequisitePro.
o Create a requirement document.
o Create a new view.
6. Deliverables
• You should show that you have successfully performed all the tasks listed in
exercise 5.
• Also during the requirement phase of your term project, you should use
RequisitePro to manage your requirements.
G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 16

Aim:-Use Case Diagram for Course Registration System
1.Outlin
 Learn to find out Actors from Problem Statement.
 Learn to find out Use-Cases from Problem Statement.
 Create association between use cases and actors.
2.Theory
Actors
Actors represent anyone or anything that interact with the system. An
actor may
 Only input information to a system
 Only retrieve information from a system
 Both input and retrieve information to and from a system
Typically, the actors are found in the problem statement, and also
from conversation with the customers and domain experts.
There are three types of actors:
1. users of the system,
2. external application systems, and
3. external devices that can independently interact with the system.
In UML, an actor is represented stickman symbol, as shown below:
Use cases:
Use cases eventually map to the menu option. Use cases represent the
functionality provided by the system. Each individual functionality
provided by a system is captured as a use case.
A use case thus represents a dialog between an actor and the system. A
collection of use cases for a system reflects all the defined ways in which
a system can be used.

A use case can be defined as a sequence of transactions performed by a

system, that yields a measurable result of values for a particular actor.
In UML, a use case is represented as an oval, as shown below:
Use case Diagram:

A use case diagram is a interaction view of a some or all the actors, use
cases and their interactions identified for a system. Each system typically
has a main use case diagram, which is a picture of the system boundary
(actors) and the major functionality provided by the system (use cases).
Other use case diagrams may be created as needed. Some examples are:
 A diagram showing all the use cases for a selected actor.
 A diagram showing all the use cases being implemented in an
interaction.
 A diagram showing all the use cases and all its relationship.
Example:


Actors:
 Student
 Professor
 Registrar
 Course Catalog
 Student Database
 Professor Database
 Billing System
Use cases:
 Login
 View Report Card
 Register for course
 Select Course to teach
 Submit Grades
 Maintain Professor information
 Maintain student information
 Close Registration
3. CASE Tools
Rational Software Architect
4. In-Class Demo
Explain the same example in class. Discuss the Problem Statement with Students
and find out actors and use cases to create Use-Case Diagram.
5. Exercises
a. Perform each of the following tasks using RSA
 Create a new project.
 Create a new package and name it as Actor
 Add the actor names involved in Project
 Create a new package and name it as Use cases
 Add the use case names involved in Project.
 Add diagram Use Case Diagram
 Drag and Drop actors and use cases to create a use case Diagram.
6. Deliverables
• You should show that you have successfully performed all the tasks listed in
exercise 5.
• Also during Use caseModelling of your term project, create a Global View of
use case Diagram.

Experiment 3
Aim:- Activity Diagram for Course Registration System
1.Outlin
The logical place to start walking through some of the UML diagrams is
by looking at activity diagrams.
2.Theory
Activity diagrams provide a way to model the workflow of a business

process. You can also use activity diagrams to model code-specific information
such as a class operation. Activity diagrams are very similar to a flowchart
because you can model a workflow from activity to activity.
An activity diagram is basically a special case of a state machine in which
most of the states are activities and most of the transitions are implicitly
triggered by completion of the actions in the source activities. The main
difference between activity diagrams and state charts is activity diagrams are
activity centric, while state charts are state centric. An activity diagram is
typically used for modeling the sequence of activities in a process, whereas a
state chart is better suited to model the discrete stages of an object’s lifetime.
Activities represented as rounded rectangles. Activities are typically
action states – states that transition automatically to the next state after the
action is complete. The filled in circle represents the start of the activity
diagram – where the flow of control starts. Transitions shown as arrows show
how you move from activity to activity. Synchronization bars show how
activities happen in parallel. I can guard a transition that says “I want you to go
to this activity only if this condition is true,” and I can show you where it stops.
You can attach activity diagrams to most model elements in the use case
or logical views.
Example:

3. CASE Tools
4. In-Class Demo
Explain the same example in class. Discuss the Problem Statement with Students
and find out flow of events to create Activity Diagram.
5. Exercises
 Add the Activity Diagram in existing Use case Modeling
6. Deliverables
• Also during Use case Modeling of your term project, create a Activity Diagram.

Experiment No: 4
Aim:-Discovering Classes and Creating Class Diagram for

Course Registration System
1. Outline
Class diagrams are created to provide a picture or view of some or all of
the classes in the model.
2. Theory
CLASS :
A CLASS IS a description of a group of objects with common
properties (attributes), common behavior (operations), common relationships
to other objects, and common semantics. Thus, a class is a template to create
objects. Each object is an instance of some class and objects cannot be
instances of more than one class.
Class Diagram
Class diagrams are perhaps the most commonly used diagrams in modeling
object-oriented systems.
A class diagram shows a set of classes and interfaces, and their relationship.
In an object-oriented system, no class can stand in a complete isolation from
all the other classes. Classes share various types of relationship with other
classes. In fact, a system is a collection of various collaborating classes. It is
through collaboration between various classes that a system can achieve its
final goal.
Classes should be named using the vocabulary of the domain.

For example, the CourseOffering class may be defined with the following
characteristics:
Attributes - location, time offered
Operations - retrieve location, retrieve time of day, add a student to the
offering .
Each object would have a value for the attributes and access to the
operations specified by the CourseOffering class.

Stereotypes and Classes :

As like stereotypes for relationships in use case diagrams. Classes can also
have stereotypes. Here a stereotype provides the capability to create a new
kind of modeling element.
Here, we can create new kinds of classes. Some common stereotypes
for a class are entity Class, boundary Class, control class, and exception.
Notations of these stereotypes :
<<Exception>>
control Class Boundary Class Entity Class
Identification of classes :
The Rational Unified Process facilitates finding the classes for a
system under development by looking for boundary, control, and entity
classes.
Entity Classes
• An entity class models information and associated behavior that is
generally long lived.
• This type of class may reflect a real-world entity or it may be needed
to perform tasks internal to the system.
They are typically independent of their surroundings; that is, they are not
sensitive to how the surroundings communicate with the system. The nouns
and noun phrases used to describe the responsibility may be considered for
identification purpose.

<<entity Class>>
COurse Offering
CourseOffering
Boundary Classes :
Boundary classes handle the communication between the system
surroundings and the inside of the system. They can provide the interface to
a user or another system (i.e., the interface to an actor). They constitute the
surroundings dependent part of the system.
<<Boundary class>>
RegistrationForm
RegistrationForm
Control Classes:
• Control classes model sequencing behavior specific to one or more
use cases.
• Control classes coordinate the events needed to realize the behavior
specified in the use case.
• Control classes typically are application-dependent classes.
• The control class is responsible for the flow of events in the use case.
<<control class>>
Registration
RegistrationManag Manager
er

Representing classes in a Class Diagram

The complete UML notation for a class diagram is a rectangle with three
compartments. The first compartment has an optional stereotype and the
class name. The second compartment can be used to show the attributes of a
class, while the third compartment is used for listing the responsibilities of
operations of the class. Only the first compartment is mandatory, the next
compartments are optional, and often omitted.
Including all attributes and operations for a class diagram may not only be
unnecessary in most contexts, but it may also clutter up the diagram and
make them difficult to use. UML also allows you to render some selected
attributes and operations in the respective compartments.
Example:

CLASS DIAGRAM WITH INHERITANCE

3. CASE Tools
4. In-Class Demo
Explain the same example in class. Find out classes with different stereotypes
and use it in the CLASS DIAGRAM.
5. Exercises
 Open with the Analysis Modelling.
 Create Entity classes stereotypes
 Create Boundary classes stereotypes
 Create Controller classes stereotypes
 Use appropriate relationships, inheritances and multiplicity.
 Add class Diagram in Analysis Modeling
 Drag and drop the classes and add above relationships.
6. Deliverables
• Also during Analysis Modeling of your term project, create a class Diagram.

Experiment No: 5
Aim:- Interaction Diagram: Sequence and Collaboration Diagram

SEQUENCE DIAGRAM
1. Outline
Sequence diagrams show object interactions arranged in a time sequence.
2. Theory
A sequence diagram shows a pattern of interaction among objects,

emphasizing the sequencing of messages. A message is the mechanism by
which an object to execute a certain responsibility.
Normally, we begin drawing a sequence diagram by placing the initiating
actor at the left, and subsequent classes or actors increasingly to the right.
Linking the participating objects or actors by line with an arrow shows a
message. The message line originates from the object or the actor who initiates
the message and arrow points to the object or the actor who is responsible for
that message to be executed.
The message line should be labeled with a suitable description of the
message being passed. We can also specify the message.
Interaction between actors should not be shown in a sequence diagram. Since
actors are outside the system, any interaction between them is also outside the
system, and therefore should not be modeled
Sequence diagram demonstrate the behavior of objects in a use case by
describing the objects and the message they loss. The diagrams are read left to
right and descending.
From an analysis point of view, sequence diagrams are very powerful in
helping drive requirements; especially requirements that are hard to find. User
interface requirements, for instance, are notorious because you always seem to
get requirements that are just not testable. A common UI requirement like this is
“this system shall be user friendly.”
One of the benefits of these types of diagrams is that every line coming
from an actor that represents a person, tells you that something in your UI has to
provide a capability needed by that person. In other words, you can use sequence
diagrams to drive out testable user interface requirements.

Sequence diagrams are, therefore, good for showing what’s going on, for
driving out
Example:
Sequence Diagram for the use case add a student to course
Above diagram shows how a student successfully gets added to a course. The student
(let’s call him Joe) fills in some information and submits the form. The form then talks
to the manager and says “add Joe to Math 101.” The manager tells Math 101 that it has
to add a student. Math 101 says to Section 1 “are you open?” In this case, Section 1
replies that they are open, so Math 101 tells section 1 to add this student. Again,

sequence diagrams are great tools in the beginning because they show you and your
customer step-by-step what has to happen.
3. CASE Tools
4. In-Class Demo
Explain the same example in class. Identify all use case and create a sequence
diagram for each one.
5. Exercises
 Add the Sequence Diagram in existing Interaction Diagrams.
 Add the every activity for a specific use case by using Timeline coming from
every actor.
 In this way draw sequence diagram for every use case.
6. Deliverables
• Create a Sequence Diagrams as one of the interaction diagram

Experiment No: 5
Aim:- Interaction Diagram: Sequence and Collaboration Diagram

COLLABORATION DIAGRAM
1. Outline
Collaboration diagram emphasizes the organization of the objects

participating in iteration.
2. Theory
A collaboration diagram is an alternative way of displaying the pattern of

interaction between various objects and actors in a use case. While a sequence
diagram emphasizes the sequencing of communication between objects, a
collaboration diagram emphasizes the organization of the objects participating in
iteration.
Collaboration diagram can be used to show how objects in a system interact
over multiple use cases. Collaboration diagram are useful during the exploratory
phases of a development process. Since there is no explicit representation of
time in Collaboration Diagrams, the message are numbered to denote the
sending order.
In a collaboration diagram, all interactions between any pair of
objects/actors are shown at the same level.
Collaboration diagram are also relatively easy to draw. They show the
relationship between objects and the order of message passed between them. The
objects are listed as icons and arrow indicates the message being passed between
them. The number next to the message is called sequence numbers. As the name
suggests, they show the sequence of the message as they are passed between the
objects. There are many acceptable sequence-numbering schemes in UML. A
simple 1,2,3…format can be used or for more detailed and complex diagrams a
1,1.1,1.2,1.2.1… schemes can be used.

Example:
The benefit of collaboration diagrams is if I want to see all of the messages

that go between two objects for a particular use case or scenario. Especially in
the case of a big, long scenario where the real estate is smaller, it’s easier to see
these messages on a collaboration diagram. The thing to remember here, is that a
collaboration diagram is just a different view of a scenario and you can go back
and forth between sequence diagrams and collaboration diagrams to get the view
that best illustrates your point.

Occasionally, you might hear the phrase “interaction diagrams.” Sometimes

people will collectively refer to a collaboration diagram and a sequence diagram
as an interaction diagram.
3. CASE Tools
4. In-Class Demo
Explain the same example in class. Identify the objects and find their interaction
with each other.
5. Exercises
 Add the collaboration diagram in existing Interaction Diagrams.
 Add the object related to every sequence for a specific use case by using the
sequence numbering scheme in UML.
 In this way draw collaboration diagram for every use case.
6. Deliverables
• Create a Collaboration Diagrams as one of the interaction diagram

Aim :- Interaction Diagram: Sequence and Collaboration Diagram

( for Course Registration System)

1. Outline
A state transition diagram shows the life history of a given class.
2. Theory
It shows the events that cause a transition from one state to another, and the
actions that result from a state change.
State chart diagrams model the dynamic behavior of individual classes or any
other kind of object. They show the sequences of states that an object goes
through, the events that cause a transition from one state to another, and the
actions that result from a state change.
State chart diagrams are closely related to activity diagrams. The main
difference between the two diagrams is state chart diagrams are state centric,
while activity diagrams are activity centric. A state chart diagram is typically
used to model the discrete stages of an object’s lifetime, whereas an activity
diagram is better suited to model the sequence of activities in a process.
Each state represents a named condition during the life of an object during which
it satisfies some condition or waits for some event. A state chart diagram
typically contains one start state and multiple end states. Transitions connect the
various states on the diagram. As with activity diagrams, decisions,
synchronizations, and activities may also appear on state chart diagrams.
State
Definition
A state represents a condition or situation during the life of an object during
which it satisfies some condition or waits for some event. Each state represents
the cumulative history of its behavior.
Graphical Depiction
The state icon appears as a rectangle with rounded corners and a name (Wait). It
also contains a compartment for actions:

NewState
Naming
The name of a state should be unique to its enclosing class, or if nested, within
the state. All state icons with the same name in a given diagram represent the
same state.
Actions
Actions on states can occur at one of four times:
· on entry
· on exit
· do
· on event.
An on event action is similar to a state transition label with the following syntax:
event(args)[condition] : the Action
You must add actions through the Action Specification. States may also appear
on activity diagrams.
Start state
A start state (also called an "initial state") explicitly shows the beginning of a
workflow on an activity diagram or the beginning of the execution of a state
machine on a state chart diagram. You can have only one start state for each
state machine because each workflow/execution of a state machine begins in the
same place. If you use multiple activity and/or state chart diagrams to model a
state machine, the same start state can be placed on the multiple diagrams. When
you model nested states or nested activities, one new start state can be created in
each context.
Normally, only one outgoing transition can be placed from the start state.
However, multiple transitions may be placed on a start state if at least one of
them is labeled with a condition. No incoming transitions are allowed.
You can label start states, if desired. State Specifications are associated with
each start state.
Graphical Depiction
The start state icon is a small, filled circle that may contain a name (Begin
Process):
End State
An end state represents a final or terminal state on an activity diagram or state
chart diagram. Place an end state when you want to explicitly show the end of a

workflow on an activity diagram or the end of a state chart diagram. Transitions

can only occur into an end state; however, there can be any number of end states
per context.
You can label end states, if desired. State Specifications are associated with
each end state.
Graphical Depiction
The end state icon is a filled circle inside a slightly larger unfilled circle that may
contain a name (End Process):
State Transition
Definition
A state transition indicates that an object in the source state will perform certain
specified actions and enter the destination state when a specified event occurs or
when certain conditions are satisfied. A state transition is a relationship between
two states, two activities, or between an activity and a state.
You can show one or more state transitions from a state as long as each
transition is unique. Transitions originating from a state cannot have the same
event, unless there are conditions on the event.
Graphical Depiction
The icon for a state transition is a line with an arrowhead pointing toward the
destination state or activity:
NewState
Naming
You should label each state transition with the name of at least one event that
causes the state transition. You do not have to use unique labels for state
transitions because the same event can cause a transition to many different states
or activities.
Transitions are labeled with the following syntax:

event (arguments) [condition] / action ^ target.sendEvent (arguments)
Only one event is allowed per transition, and one action per event.

Events, conditions and actions must be added by editing the label or through the
State Transition Specification.
Nested States
States may be nested to any depth level. Enclosing states are referred to as super
states, and everything that lies within the bounds of the super state is referred to
as its contents. Nested states are called sub states.
Example:

3. CASE Tools
4. In-Class Demo
Explain the same example in class. Identify the objects and classes and find out
all the states and action with that state.
5. Exercises
 Add the State diagram in existing Interaction Diagrams.
 Add the object related to every sequence for a specific use case by using the
gragical depiction in UML.
 In this way draw State diagram for every use case.
6. Deliverables
• Create a State Transition Diagrams as one of the interaction diagram

Experiment No:6
Aim:- Component and Deployment Diagram

COMPONENT DIAGRAM
1. Outline
Component diagram is used to model the static implementation view of a

system.
2. Theory
Component:
A component is a physical and replaceable part of a system that conforms to and

provides the realization of a set of interfaces. Graphically, a component is
rendered as a rectangle with tabs.
Names:
Every component must have a name that distinguishes it from other components.
A name is a textual string.
Components and classes:
In many ways, components are like classes. Both have names; both may
realize a set of interfaces; both may participate in a dependency, generalization,
and association relationship; both may be nested; both may have instances; both
may be participants in interactions. However, there are some significant
differences between component and classes.
Classes represent logical abstractions; components represent physical
things that live in the world of bits.
Components represent the physical packaging of otherwise logical
components and are at a different level of abstraction.
Classes may have attributes and operations directly. In general, components
only have operations that are reachable only through their interfaces.

Kinds of components may be distinguished-
1) Deployment components: These are the components necessary and

sufficient to form an executable system, such as dynamic libraries and
executable.
2) Work Product Components: The components are essentially the residue of
the development process, consisting of things such as source code files and
data files from which deployment component are created.
3) Execution Components: These component are created has a consequences
of an executing system, such as COM+ object, which is instantiated from a
DLL.
Component Diagram:
Component diagrams illustrate the organizations and dependencies
among software components
A component may be
– A source code component
– A run time components or
An executable component
A component diagram shows a set of components and their relationships.
Graphically, a components diagram is a collection of vertices and arcs.
A components diagram is just a special kind of diagram and shares the same
common properties as do all other diagrams-a name and graphical contents that
are a projection into a model. What distinguishes a component diagram from all
other kinds of diagrams is its particular content.
Component diagram commonly contain
 Components
 Interfaces
 Dependency, generalization, association and realization relationships.
. Component diagram may also contain packages or subsystem, both of

which are used to group elements of your model into larger chunks. Sometimes
you’ll want to place instances in your component diagrams, as well,
especially when you want to visualize one instances of a family of component-
based system.

Example:

3. CASE Tools
4. In-Class Demo
Explain the same example in class. Identify the objects classes and Components
by using above concepts.
5. Exercises
a. Perform each of the following tasks using RSA.
 Add the Component diagram in Rational Software Architect.
 Arrange the appropriate components in diagram to complete Component
Diagram
6. Deliverables
Create a Component Diagram which lead to Deployment Diagram for Client Side

Aim:-Component and Deployment Diagram

DEPLOYMENT DIAGRAM
1. Outline
A deployment diagram shows processors, devices, and connections

regarding the project
2. Theory:
. Each model contains a single deployment diagram which shows the
connections between its processors and devices, and the allocation of its
processes to processors.
Processor Specifications, Device Specifications, and Connection Specifications
enable you to display and modify the respective properties. The information in a
specification is presented textually; some of this information can also be
displayed inside the icons.
You can change properties or relationships by editing the specification or
modifying the icon on the diagram. The deployment diagram specifications are
automatically updated.
Processor
A processor is a hardware component capable of executing programs.
Naming
Each processor must have a name. There are no constraints on the processor
name because processors denote hardware rather than software entities.
Graphical Depiction
The icon for a processor is a shaded box:
NewPr
o...
Adornments
You can further define a processor by identifying its processes and specifying
the type of process scheduling it uses. You can set the following adornments in
the Processor Specification. You can display the information in the deployment
diagram by selecting an item from the processor shortcut menu.

NewPr
o...
preemptive
process1
process 2
Scheduling
You can specify the type of process scheduling used by this processor by setting
a scheduling type:
Type Description
Preemptive (default) Higher-priority processes that are ready to execute

can preempt lower-priority processes that are
currently executing.
Nonpreemptive The current process continues to execute until it

relinquishes control.
Cyclic Control passes from one process to another.
Executive An algorithm controls process scheduling.
Manual Processes are scheduled by the user outside of the

system.
Processes represent single threads of control. Examples include the main

program from a component diagram or the name of an active object from a
collaboration diagram. To add a process to the processor, double-click on
<New> in the Processes field to displays the Process Specification.
Device
A device is a hardware component with no computing power. Each
device must have a name. Device names can be generic, such as "modem" or
"terminal."
Graphical Depiction
The icon for a device is a box:

NewD
evice
Connection
A connection represents some type of hardware coupling between two
entities. An entity is either a processor or a device. The hardware coupling can
be direct, such as an RS232 cable, or indirect, such as satellite-to-ground
communication. Connections are usually bi-directional.
Naming
You can optionally label the connection with its name.
Graphical Depiction
The icon for a connection is a straight line:
NewProcessor NewDevice
 The deployment diagram shows the configuration of run-time processing

elements and the software processes living on them.
 The deployment diagram visualizes the distribution of components
across the enterprise.
Example:

3. CASE Tools
4. In-Class Demo
Explain the same example in class. Identify the run time Processors and
Processes to distribute the Components across the Project.
5. Exercises
a. Perform each of the following tasks using RSA.
 Add the Deployment diagram in Rational Software Architect as End Diagram
for the client Side.
 Arrange the appropriate components in diagram to complete Deployment
Diagram
6. Deliverables
Create a Deployment Diagram which is delivered to the Client Side.

Online Book Store
Problem Definition:
A popular bookstore wants to expand its business by going online . The

bookstore has several outlets which are very popular and crowded . However
customers face the problem of going to the store and locating books
manually . The management feels that hosting a website which cater to the
needs of these customers , will reduce crowding at the outlets , while
actually increasing business. Since many more customers may like to access
the online store . This will also lead to higher customer satisfaction because
customers can order books from the comfort of their home or office , Further
more , the store can manage its transactions efficiently.
The store maintains books according to categories viz. Medical Science ,

Fiction , Philosophy etc. Books are also identified by the Title , Author and
Pubpblisher , Customers should be able to browse books by any of the above
classification, Realizing the importance of a comprehensive customer
database the management is keen to provide convenient registration facilities
. This should permit the store to capture important information including
contact details, professional background , preferred categories publishers
authors etc. The online store should provide each registered surfer with a
login id and a password . Only registered users shall be given the facility to
buy books.
The store allows customers to purchase unlimited copies of a book , subject

to availability . Customers should be able to browse the site when
convenient and select the books for purchase . They should also be able to
hand in the selected books for billing ar any point . For purchase of 5 to 10
copies of a book the store gives a discount of 5 % and for purchase of more
than 10 copies , a discount of 10% is given . The store charges 2 % of the
bill as delivery charge.
If they so desire , customers should be able to continue browsing after

billing and buy more books as described above. On billing, the customers
should be given the full details of the invoice, including invoice no, Items
bought, amount of purchase etc. Books purchase by a customer should be

dispatched within a week from receipt of payment along with the appropriate
bill. The store does not bear the responsibility for the books damaged during
dispatch.
At present , Inventory is being managed by a legacy system . Upgrade to

include inventory within the web based system is not immediately
visualized. Hence the Online system should generate invoices for all ordered
items and need not check for inventory.
Further, the online Bookstore should provide for maintenance of details of

books, book categories, publishers, and authors . Maintenance should
include any addition, deletion and modification carried out.
The store management maintains complete information about the books such
as Book ID, Price , Title , Edition , Year of Publication , Category , author ,
publisher etc. The store management also encourages the development team
to add more features to the project , which shall merge well with
requirements of the bookstore . However , since several competitors ere
expected to go online very shortly and the fact that the management wants to
be the first of the block, it becomes vital that the project is completed within
the stipulated time.

1)Use case diagram
Request for registration

Registrar
Issue of Login Id and Password
Browse the Site
Add Products to the shopping Cart

Customer
View Shopping Cart

System User
Checkout
Display Shipping Cart,Billing maintainance of books

Adress <<extends>> <<extends>> <<extends>>
Confirms order And Payment addition

method deletion
modification
Process Order
Check For Discount
Billing Of Books
Issue Of Electronic Receipt
Logs Off

Class Diagram


Sequence diagram
customer order book site
1: Browse ,select products
2: Validate Id and password
3: Registration and orders
4: check status of availability
5: Sales info
6: dispatch of books
7: Payment
8: Issuse of receipt
9: Loggs off

Collaboration diagram
order
customer
6: dispatch of books
4: check status of availability

1: Browse ,select products
3: Registration and orders
7: Payment
book 9: Loggs off
5: Sales info
2: Validate Id and password

8: Issuse of receipt
site

Activity diagram
Open home
page
select category select product
buy the product
check for new check for

user existing user
Enter login id
registration and password
delivery and
payment

State diagram
Visit URL
Select category
Display Selected
Category details
Choose the product
Buy the {registered ==False} Register

products
registered
Login
register
Enter loginid
Payment

Component diagram
Login
Registrar Customer
GUI
(Browser)
Validate
order Book
deployment diagram
Apache Tomcat v4.1 Oracle 9i

client(browser)
lan odbc


Laboratory Manual: Object Oriented Software Engineering

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Laboratory Manual: Object Oriented Software Engineering

Uploaded by

Copyright:

Available Formats

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA.

Object Oriented Software

Roll No. Division

Batch Exam No.

This is to certify that Mr./Ms._______________________

Faculty InchaRG HOD Principal

Aims and objectives

Subject : Object Oriented Software Engineering (OOSE)

PREREQUISITES : Computer Network

Modu Contents Hou

2 2.1 Planning & Estimation 08

TOPICS FOR EXPERIMENT

The final certification and acceptance of TW ensures the satisfactory performance

Sr. No. Lab Assignment Hours

Software requirement Specification and Use

3 Flow of Events and Activity Diagram 2 Hours

OO Analysis: Discovering Classes and

Interaction Diagram: Sequence and

Component and Deployment Diagram

7 Mapping Model to code by converting above 2 Hours

8 Requirement Workflow of student’s own 2 Hours

10 Implementation Workflow of student’s own 2 Hours

11 Report and Project Submission 2 Hours

2.2 Tools Used in the Lab

2.3 Software Engineering Lab Objectives

7. Problem Statement for Course Registration System

Project management is the process of planning and controlling the development of a

8.1 Risk Management

8.2 Risk Management Process

8.3 CASE Tools

8.4 In-Class Demo

Aim:-Software requirement Specification and Use Case Diagram

2.1 Requirements Engineering Process

Version 1.0 approved

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 16

Aim:-Use Case Diagram for Course Registration System

In UML, an actor is represented stickman symbol, as shown below:

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 17

A use case can be defined as a sequence of transactions performed by a

In UML, a use case is represented as an oval, as shown below:

Use case Diagram:

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 18

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 19

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 20

Aim:- Activity Diagram for Course Registration System

Activity diagrams provide a way to model the workflow of a business

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 21

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 22

Aim:-Discovering Classes and Creating Class Diagram for

Classes should be named using the vocabulary of the domain.

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 23

Stereotypes and Classes :

control Class Boundary Class Entity Class

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 24

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 25

Representing classes in a Class Diagram

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 26

CLASS DIAGRAM WITH INHERITANCE

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 27

G. M. VEDAK INSTITUTE OF TECHNOLOGY, TALA. 28

Aim:- Interaction Diagram: Sequence and Collaboration Diagram

A sequence diagram shows a pattern of interaction among objects,