Laboratory Manual: Object Oriented Software Engineering
Laboratory Manual: Object Oriented Software Engineering
Laboratory Manual: Object Oriented Software Engineering
ACADEMIC YEAR-2013-14
DEPARTMENT OF COMPUTER ENGINEERING
LABORATORY MANUAL
Department
Of
Computer Engineering
PROF. R.SINGH
Semester : - VI
(Affiliated to Mumbai University, Mumbai and Approved by AICTE, New
Delhi)
Academic Year:
Name
Subject
Department
Semester Branch
Certificate
University of Mumbai
Branch : Computer Semester : VI
Class : T.E. Engineering
REFERENCES :
1. Timothy C. Lethbridge,Robert Laganiere “Object Oriented Software
Engineering- A Practical software development using UML and Java
“,Tata McGraw Hill,New Delhi.
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
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.
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.
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:
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.
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.
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.
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.
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
1.Outlin
The logical place to start walking through some of the UML diagrams is
by looking at activity diagrams.
2.Theory
Example:
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 flow of events to create Activity Diagram.
5. Exercises
a. Perform each of the following tasks using RSA
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
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.
<<Exception>>
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
Example:
3. CASE Tools
Rational Software Architect
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
SEQUENCE DIAGRAM
1. Outline
Sequence diagrams show object interactions arranged in a time sequence.
2. Theory
Sequence diagrams are, therefore, good for showing what’s going on, for
driving out
Example:
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
Rational Software Architect
4. In-Class Demo
Explain the same example in class. Identify all use case and create a sequence
diagram for each one.
5. Exercises
a. Perform each of the following tasks using RSA
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
COLLABORATION DIAGRAM
1. Outline
2. Theory
Example:
3. CASE Tools
Rational Software Architect
4. In-Class Demo
Explain the same example in class. Identify the objects and find their interaction
with each other.
5. Exercises
a. Perform each of the following tasks using RSA
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
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
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.
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
Rational Software Architect
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
a. Perform each of the following tasks using RSA
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
COMPONENT DIAGRAM
1. Outline
2. Theory
Component:
Names:
Every component must have a name that distinguishes it from other components.
A name is a textual string.
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.
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.
Example:
3. CASE Tools
Rational Software Architect
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
DEPLOYMENT DIAGRAM
1. Outline
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
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
Example:
3. CASE Tools
Rational Software Architect
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.
Problem Definition:
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.
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.
Checkout
Billing Of Books
Logs Off
Class Diagram
Sequence diagram
customer order book site
5: Sales info
6: dispatch of books
7: Payment
8: Issuse of receipt
9: Loggs off
Collaboration diagram
order
customer
6: dispatch of books
site
Activity diagram
Open home
page
Enter login id
registration and password
delivery and
payment
State diagram
Visit URL
Select category
Display Selected
Category details
registered
Login
register
Enter loginid
Payment
Component diagram
Login
Registrar Customer
GUI
(Browser)
Validate
order Book
deployment diagram