ANJALAIAMMAL-MAHALINGAMENGINEERINGCOLLEGE

KOVILVENNI-614 403, THIRUVARUR DISTRICT

NAAC Accredited
DEPARTMENTOFCOMPUTERSCIENCEANDENGINEERING

LABMANUAL

Laboratory Course Code :CCS356

Laboratory Course Title :Object Oriented Software Engineering(OOSE)

Semester : VI (2024-2025 EVEN)

Branch &Section : CSE ‘A’&‘B’

Course Teacher : Dr.G.Nanthakumar & Mr.R.Arunachalam

Department : CSE

Regulation : 2021

Signature of the faculty Signature of the HOD

 LIST OF EXPERIMENTS
1. Identify a software system that needs to be developed.
2. Document the Software Requirements Specification (SRS) for the identified system.
3. Identify use cases and develop the Use Case model.
4. Identify the conceptual classes and develop a Domain Model and also derive a Class
Diagram from that.
5. Using the identified scenarios, find the interaction between objects and represent them
UsingUML Sequence and Collaboration Diagrams
6. Draw relevant State Chart and Activity Diagrams for the same system.
7. Implement the system as per the detailed design
8. Test the software system for all the scenarios identified as per the usecase diagram
9. Improve the reusability and maintainability of the software system by applying appropriate
design patterns.
10. Implement the modified system and test it for various scenarios
SUGGESTED DOMAINS FOR MINI-PROJECT
1. Passport automation system.
2. Book bank
3. Exam registration
4. Stock maintenance system.
5. Online course reservation system
6. Airline/Railway reservation system
7. Software personnel management system
8. Credit card processing
9. e-book management system
10. Recruitment system
11. Foreign trading system
12. Conference management system
13. BPO management system
14. Library management system
15. Student information system
TOTAL: 45 PERIODS
Requirements
HARDWARE REQUIREMENTS
Standard PC
SOFTWARE REQUIREMENTS
1. Windows 7 or higher
2.Rational Suite
3. ArgoUML that supports UML 1.4 and higher
4. Selenium, JUnit or Apache JMeter
 INTRODUCTION
OBJECT-ORIENTED ANALYSIS AND DESIGN (OOAD)
Object oriented analysis and design is a software engineering approach which models the
system as interacting objects. Each object represents a system entity which plays a vital role
in building of that system.
Analysis
1. Analysis emphasizes an investigation of the problem and requirements, rather than a
solution.
2. “Analysis” is a broad term, best qualified, as in requirements analysis(an investigation of
the requirements) or object-oriented analysis(an investigation of the domain objects)
3. Analysis means do the right thing.
Design
1. The design emphasizes a conceptual solution (in software and hardware) that fulfills the
requirements, rather than its implementation. For example, a description of a database
schema and software objects.
2. Design ideas often exclude low level or “obvious” details.
3. Design means do the thing right.
 CASE tools known as Computer-aided software engineering tools is a kind of
component-based development which allows its users to rapidly develop information systems.
The main goal of case technology is the automation of the entire information systems
development life cycle process using a set of integrated software tools, such as modeling,
methodology and automatic code generation. Component based manufacturing has several
advantages over custom development. The main advantages are the availability of high quality,
defect free products at low cost and at a faster time. The prefabricated components are
customized as per the requirements of the customers. The components used are pre-built, ready-
tested and add value and differentiation by rapid customization to the targeted customers.
However the products we get from case tools are only a skeleton of the final product required
and a lot of programming must be done by hand to get a fully finished, good product.

CHARACTERISTICS OF CASE:
Some of the characteristics of case tools that make it better than customized development are;
It is a graphic oriented tool.
It supports decomposition of process.

Some typical CASE tools are:

Unified Modeling Language
Data modeling tools, and
Source code generation tools

INTRODUCTION TO UML (UNIFIED MODELING LANGUAGE):

The UML is a language for specifying, constructing, visualizing, and documenting the software
system and its components. The UML is a graphical language with sets of rules and semantics.
The rules and semantics of a model are expressed in English in a form known as OCL (Object
Constraint Language). OCL uses simple logic for specifying the properties of a system. The
UML is not intended to be a visual programming language. However it has a much closer
mapping to object-oriented programming languages, so that the best of both can be obtained.
The UML is much simpler than other methods preceding it. UML is appropriate for modeling
systems, ranging from enterprise information system to distributed web based application and
even to real time embedded system. It is a very expensive language addressing all views needed
to develop and then to display system even though understand to use. Learning to apply UML
effectively starts forming a conceptual mode of languages which requires learning.

Three major language elements:

UML basic building blocks
Rules that dictate how this building blocks put together
Some common mechanism that apply throughout the language
The primary goals in the design of UML are:
1. Provides users ready to use, expressive visual modeling language as well so they can develop
and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development processes.
4. Provide formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts.
7. Integrate best practices and methodologies.

Every complex system is best approached through a small set of nearly independent views of a
model. Every model can be expressed at different levels of fidelity. The best models are
connected to reality. The UML defines nine graphical diagrams:
1. Class diagram
2. Use-case diagram
3. Behavior diagram
3.1. Interaction diagram
3.1.1. sequence diagram
3.1.2. collaboration diagram
3.2. state chart diagram
3.3. activity diagram
4. Implementation diagram
4.1 component diagram
4.2 deployment diagram

1. UML class diagram:

The UML class diagram is also known as object modeling. It is a static analysis diagram. These
diagrams show the static structure of the model. A class diagram is a connection of static model
elements, such as classes and their relationships, connected as a graph to each other and to their
contents.

2. Use-case diagram:
The functionality of a system can be described in a number of different use-cases, each of which
represents a specific flow of events in a system. It is a graph of actors, a set of use-cases
enclosed in a boundary, communication, associations between the actors and the use-cases, and
generalization among the use-cases.
3. Behavior diagram:
It is a dynamic model unlike all the others mentioned before. The objects of an object oriented
system are not static and are not easily understood by static diagrams. The behavior of the
class‟s instance (an object) is represented in this diagram. Every use-case of the system has an
associated behavior diagram that indicates the behavior of the object. In conjunction with the
use-case diagram we may provide a script or interaction diagram to show a time line of events.
It consists of sequence and collaboration diagrams.

4. Interaction diagram
It is the combination of sequence and collaboration diagram. It is used to depict the flow of
events in the system over a timeline. The interaction diagram is a dynamic model which shows
how the system behaves during dynamic execution.

5. State chart diagram:

It consists of state, events and activities. State diagrams are a familiar technique to describe the
behavior of a system. They describe all of the possible states that a particular object can get into
and how the object's state changes as a result of events that reach the object. In most OO
techniques, state diagrams are drawn for a single class to show the lifetime behavior of a single
object.

6. Activity diagram:
It shows organization and their dependence among the set of components. These diagrams are
particularly useful in connection with workflow and in describing behavior that has a lot of
parallel processing. An activity is a state of doing something: either a real-world process, or the
execution of a software routine.

7. Implementation diagram:
It shows the implementation phase of the systems development, such as the source code
structure and the run-time implementation structure. These are relatively simple high level
diagrams compared to the others seen so far. They are of two sub-diagrams, the component
diagram and the deployment diagram.

8. Component diagram:
These are organizational parts of a UML model. These are boxes to which a model can be
decomposed. They show the structure of the code itself. They model the physical components
such as source code, user interface in a design. It is similar to the concept of packages.

9. Deployment diagram:
The deployment diagram shows the structure of the runtime system. It shows the configuration
of runtime processing elements and the software components that live in them. They are usually
used in conjunction with deployment diagrams to show how physical modules of code are
distributed on the system.
NOTATION ELEMENTS:
These are explanatory parts of UML model. They are boxes which may apply to describe and
remark about any element in the model. They provide the information for understanding the
necessary details of the diagrams.

Relations in the UML:

These are four kinds of relationships used in an UML diagram, they are:
Dependency
Association
Generalization
Realization

Dependency:
It is a semantic relationship between two things in which a change one thing affects the
semantics of other things. Graphically a dependency is represented by a non-continuous line.
Association:

It is a structural relationship that describes asset of links. A link is being connected among
objects. Graphically association is represented as a solid line possibly including label.

Generalization:
It is a specialized relationship in which the specialized elements are substitutable for object of
the generalized element. Graphically it is a solid line with hollow arrow head parent.

Realization:
It is a semantic relation between classifiers. Graphically it is represented as a cross between
generalization and dependency relationship.

Where UML can be used:

UML is not limited to modeling software. In fact it is expressive to model non-software such as
to show in structure and behavior of health case system and to design the hardware of the
system.

Conceptual model be UML:

UML you need to form the conceptual model of UML. This requires three major elements:
UML basic building blocks.
Rules that dictate how this building blocks are put together.
Some common mechanism that apply throughout the language.

Once you have grasped these ideas, you may be able to read. UML create some basic ones. As
you gain more experience in applying conceptual model using more advanced features of this
language.
Building blocks of the UML:
The vocabulary of UML encompasses these kinds of building blocks.

Use CASE definition:

Description:
A use case is a set of scenarios tied together by a common user goal. A use case is a behavioral
diagram that shows a set of use case actions and their relationships.
Purpose:
The purpose of use case is login and exchange messages between sender and receiver (Email
client).
Main flow:
First, the sender gives his id and enters his login. Now, he enters the message to the receiver id.
Alternate flow:
If the username and id by the sender or receiver is not valid, the administrator will not allow
entering and “Invalid password” message is displayed.

Pre-condition:
A person has to register himself to obtain a login ID.
Post-condition:
The user is not allowed to enter if the password or user name is not valid.
Class diagram:
Description:
A class diagram describes the type of objects in system and various kinds of relationships
that exists among them.
Class diagrams and collaboration diagrams are alternate representations of object models.

During analysis, we use class diagram to show roles and responsibilities of entities that provide
email client system behaviors design. We use to capture the structure of classes that form the
email client system architecture.

A class diagram is represented as:

<<Class name>>
<<Attribute 1>>
<<Attribute n>>
<<Operation ()>>

Relationship used:
A change in one element affects the other
Generalization:
It is a kind of relationship
State chart:
Description:
The state chart diagram made the dynamic behavior of individual classes.
State chart shows the sequences of states that an object goes through events and state
transitions.
A state chart contains one state „start‟ and multiple „end‟ states.
The important objectives are:
Decision:
It represents a specific location state chart diagram where the work
flow may branch based upon guard conditions.
Synchronization:
It gives a simultaneous workflow in a state chart diagram. They visually define forks and joints
representing parallel workflow.
Forks and joins:
A fork construct is used to model a single flow of control.
Every work must be followed by a corresponding join.
Joints have two or more flow that unit into a single flow.

State:
A state is a condition or situation during a life of an object in which it satisfies condition or
waits for some events.
Transition:
It is a relationship between two activities and between states and activities.
Start state:
A start state shows the beginning of a workflow or beginning of a state machine on a state chart
diagram.
End state:
It is a final or terminal state.
Activity diagram
Description:
Activity diagram provides a way to model the workflow of a development process. We can also
model this code specific information such as class operation using activity diagram. Activity
diagrams can model different types of diagrams. There are various tools involved in the activity
diagram.
Activity:
An activity represents the performance of a task on duty. It may also represent the execution of
a statement in a procedure.
Decision:
A decision represents a condition on situation during the life of an object, which it satisfies
some condition or waits for an event.
Start state:
It represents the condition explicitly the beginning of a workflow on an activity.
Object flow:
An object on an activity diagram represents the relationship between activity and object that
creates or uses it.
Synchronization:
It enables us to see a simultaneous workflow in an activity.
End state:
An end state represents a final or terminal state on an activity diagram or state chart diagram.

Sequence diagram:
Description:
A sequence diagram is a graphical view of scenario that shows object interaction in a time
based sequence what happens first what happens next. Sequence diagrams are closely related to
collaboration diagram.
The main difference between sequence and collaboration diagram is that sequence diagram
show time based interaction while collaboration diagram shows objects associated with each
other.
The sequence diagram for the e-mail client system consists of the following objectives:
Object:
An object has state, behavior and identity. An object is not based is referred to as an instance.
The various objects in e-mail client system are:
User
Website
Login
Groups
Message icon:
A message icon represents the communication between objects indicating that an action will
follow. The message icon is the horizontal solid arrow connecting lifelines together.

Collaboration diagram:
Description:
Collaboration diagram and sequence diagrams are alternate representations of an interaction. A
collaboration diagram is an interaction diagram that shows the order of messages that
implement an operation or a transaction. Collaboration diagram is an interaction diagram that
shows the order of messages that implement an operation or a transaction.

Collaboration diagram shows object s, their links and their messages. They can also contain
simple class instances and class utility instances.
During, analysis indicates the semantics of the primary and secondary interactions. Design,
shows the semantics of mechanisms in the logical design of system.
Toggling between the sequence and collaboration diagrams

When we work in either a sequence or collaboration diagram, it is possible to view the

corresponding diagram by pressing F5 key.
ExNo.1 IDENTIFY A SOFTWARE SYSTEM THAT NEEDS TO BE DEVELOPED
AIM
To develop a problem statement for the suggested domain of mini-project.

PROBLEM STATEMENT
A problem statement is a clear concise description of the issue(s) that need(s) to be
addressed by a problem solving team. It is used to center and focus the team at the beginning,
keeps the team on track during the effort, and is used to validate that the effort delivered an
outcome that solves the problem statement. It has a specific form:
 Vision - What is the problem? This should explain why the team is needed
 Issue Statement - one or two sentences that describe the problem using specific issues.
It is not a "lack of a solution" statement.
 Method - the process that will get followed to solve the problem.
The primary purpose of a problem statement is to focus the attention of the problem solving
team. However, if the focus of the problem is too narrow or the scope of the solution too
limited, the creativity and innovativeness of the solution can be stifled. A good problem
statement should answer these questions:
1. What is the problem? This should explain why the team is needed.
2. Who has the problem or who is the client/customer? This should explain who needs
the solution and who will decide the problem has been solved.
3. What form can the resolution be? What is the scope and limitations (in time, money,
resources, and technologies) that can be used to solve the problem?

5
RESULT

Thus the problem statement for the given mini-project is created.

6
 Ex No.2 (a) PROJECT CREATION USING USING STARUML
AIM
To create a project using starUML
StarUML
StarUML is an open-source modeling software that supports the Unified Modeling Language
(UML) framework. It provides several types of diagrams and lets users generate code in multiple
languages. With its help, developers can create designs, concepts, and coded solutions. However, users
should note that this isn’t a simple program and is aimed at expert developers.
StarUML free download is designed to help users get an overview of their solution before its
completion. The tool also supports complex modeling through Model Driven Architecture (MDA)
and third-party plugins.
PROCEDURE
Creating New Project

In order to work on a new software development, a new project must be created. You may start with a
completely empty project or with a new project that has been initialized according to a specific
approach.

Procedure for Creating New Project #1 – New Project:

1. Select the [File] -> [New Project] menu.

2. A new project is created with the default approach selected by the user. Depending on the
approach, profiles and/or frameworks may be included/loaded

Procedure for Creating New Project #2 – Select New Project Dialog Box:

1. Select the [File] -> [Select New Project…] menu.

2. A list of the available approaches will be displayed in the Select New Project dialog box. Select
one from the list and click the [OK] button.
3. A new project is created and initialized according to the selected approach. Depending on the
approach, profiles and/or frameworks may be included/loaded.

Opening Project

In order to work on a saved project, the project file must be opened. If the project includes more than
one unit, all the related units will also be loaded with the project.

Procedure for Opening Project:

1. Select the [File] -> [Open…] menu.

7
 2. At the Open Project dialog box, select a project file (.UML) and click the [Open] button.

Saving Project

Procedure for Saving Project:

1. Select the [File] -> [Save] menu.

2. If the project file name has not been specified, the Save Project dialog box appears. Enter the
file name and click the [Save] button

Procedure for Saving Project as another File:

1. Select the [File] -> [Save As…] menu.

2. At the Save As dialog box, enter the new file name and click the [Save] button.
3. The project is saved as another file.

Closing Project:

1. Select the [File] -> [Close] menu.

2. If the project has not been saved after changes were made, the user will be prompted to save
the changes. The user can select yes, no, or cancel.

8
RESULT

Thus a new project, users and new groups are created and the privileges are assigned for the project
created and connected in starUML

9
Ex No.2 (b) CREATION OF SOFTWARE REQUIREMENT SPECIFICATION

AIM
To Document the Software Requirements Specification (SRS) for the identified system

REQUIREMENT ANALYSIS
The purpose of system requirement analysis is to obtain a through and detailed
understanding of business needs as defined in project organization and captured in business
case and to break if down into discrete requirements, which are then clearly defined, reviewed
and agree upon with the customers and decision makers. During the system requirement
analysis the framework for the application is developed and providing the foundation for
future design and development efforts.
Requirement analysis is also called as requirement engineering which is the process of
determining user expectation for new or modified project. These features are called
requirement it must be quantifiable. In software engineering such requirement are often
called as functional specification.

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

INTRODUCTION
Passport Automation System is an interface between the Applicant and the Authority
responsible for the Issue of Passport. It aims at improving the efficiency in the Issue of
Passport and reduces the complexities involved in it to the maximum possible extent.
PURPOSE
If the entire process of 'Issue of Passport' is done in a manual manner then it would take
several months for the passport to reach the applicant. Considering the fact that the number
of applicants for passport is increasing every year, an Automated System becomes essential
to meet the demand. So this system uses several programming and database techniques to
elucidate the work involved in this process. As this is a matter of National Security, the
system has been carefully verified and validated in order to satisfy it.

SCOPE
The System provides an online interface to the user where they can fill in their personal details.
10
 The authority concerned with the issue of passport can use this system to reduce his workload
and process the application in a speedy manner. Provide a communication platform between the
applicant and the administrator Transfer of data between the Passport Issuing Authority and the
Local Police for verification of applicant's information.
System Features and Requirements
FUNCTIONALREQUIREMENTS
Functional requirements are the requirements that the end user specifically demands as basic
facilities that the system should offer .All these functionalities need to be necessarily
incorporated into the system as a part of the contract.
These are represented or stated in the form of input to be given to the system, the operation
performed and the output expected. They are the requirements stated by the user which one can
see directly in the final product, unlike the non-functional requirements.
Example:
 What are the features that we need to design for this system?
 What are the edge cases we need to consider, if any, in our design?
NONFUNCTIONALREQUIREMENTS

Non functional requirements, which help ensure that a product will work the way users and
other stakeholders expect it to, can be just as important as functional ones.
These may include:

 Performance requirements
 Safety requirements
 Security requirements
 Usability requirements
 Scalability requirements

SOFTWARE INTERFACE
1. Front End Client - The applicant and Administrator online interface is built using
Microsoft Visual Basic 6.0.
2. Back End–MS Access database
HARDWARE INTERFACE
The server is directly connected to the client systems. The client systems have access to
the database in the server.

11
RESULT
Thus the requirements specification, requirement views and packages for the project
created in rational administrator using rational requisite pro is analyzed successfully.

12
 UNIFIED MODELING LANGUAGE
DESIGN
Design has the great impact on the overall success of the software development
projects. A large pay off is associated with creating a good design up from before writing a
single code, while this is due to all programming classes and objects understand approach
even more good design usually simplifies the implementation and maintenance. During design
phase we must evaluate the model to actual objects that can be perform the required tasks.
There is a shift in emphasis from the application domain to implementation. The classes
during analysis provides as a framework for design phases.
MODELING
Building a model for a software system prior to its construction is as essential as having a
blueprint for building a large building. Good models are essential for communication among
project teams. A modeling language must include
 Model elements-fundamental modeling concepts and semantics.
 Notation-visual rendering of model elements.
 Guidelines-expression of usage within the trade

The use of visual notation to represent or model a problem can provide us several benefits
relating to clarity, familiarity, maintenance and simplification.
UNIFIED MODELING LANGUAGE
The Unified Modeling Language (UML) is a language for specifying, visualizing,
constructing, and documenting the artifacts of software systems and its components. The
UML is a graphical language with sets of rules and semantics. The rules and semantics of a
model are expressed in English, in a form known as object constraint language (OCL). OCL is a
specification language that uses simple logic for specifying the properties of a system. The
UML is not intended to be a visual programming language in the sense of having all the
necessary visual and semantic support to replace programming languages.
UML DIAGRAMS
UML defines nine graphical diagrams
 Use-case diagram
 Class diagram

13
  Behavior Diagram
 Interaction Diagram
 Sequence Diagram
 Collaboration diagram
 State chart diagram
 Activity diagram
 Implementation diagram
 Component diagram
 Deployment diagram.
StarUML
StarUML is open-source modeling software that supports the Unified Modeling Language
(UML) framework.
It provides several types of diagrams and lets users generate code in multiple languages. With
its help, developers can create designs, concepts, and coded solutions. However, users should
note that this isn’t a simple program and is aimed at expert developers.

StarUML free download is designed to help users get an overview of their solution before its
completion.

The tool also supports complex modeling through Model Driven Architecture (MDA) and third-
party plugins.

While it may not be suitable for beginners, StarUML stands out amongst its competitors like
ArgoUML, CASE Studio, and Rationale.

14
Ex No.3 UML- USE CASE DIAGRAM

AIM
To identify Use Cases and develop the Use Case model for the identified requirements
using starUML
USE CASE DIAGRAM
A use-case diagram is a graph of actors, a set of use cases enclosed by a system
boundary, communication (participation) associations between the actors and the usecases,
and generalization among the use cases. It shows the relationship among the actors and use
cases within a system .Use case diagram is used during the analysis phase of a project. They
separate the system into actors and use cases. Actor represents the roles that can be played by
user of the system. Use case describes the behavior of the system.
1. Use cases. A use case describes a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.
2. Actors. An actor is a person, organization, or external system that plays a role in one
or more interactions with your system. Actors are drawn as stick figures.
3. Associations. Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved with an
interaction described by a use case.
4. System boundary boxes (optional).A rectangle around the use cases is called the
system boundary box and is used to indicate the scope of the system.
5. Packages (optional). Packages are UML constructs that enable you to organize model
elements (such as use cases) into groups.
RELATIONSHIPS IN USE CASE DIAGRAM
Three relationships are supported among use cases by the UML standard, which
describes graphical notation for these relationships.
1. Include(<<include>>)
A given use case may include another. The first use case often depends on the
outcome of the included use case. This is useful for extracting truly common behaviors
from multiple use cases into a single description.

15
 2. Extend(<<extend>>)
A given use case, (the extension) may extend another. This relationship
indicates that the behavior of the extension use case may be inserted in the extended
use case under some conditions. This can be useful for dealing with special cases, or in
accommodating new requirements during system maintenance and extension.
3. Generalization
A generalization/ specialization relationship exists among use cases. A given use
case may be specialized form of an existing use case. The notation is a solid line ending in a
hollow triangle drawn from the specialized to the more general use case. This resembles the
object- oriented concept of sub-classing, in practice it can be both useful and effective to factor
common behaviors, constraints and assumptions to the general use case, describe them once,
and deal same as except details in the specialized cases.
PROCEDURE
1. Identify distinct actors and use cases.
2. The external actors are placed to the left of the use case and the internal actors to the
right.
3. Open starUML enterprise edition and right click on the project then select usecase
view to create a new workspace for the diagram.
4. Name the diagram and draw the diagram using the symbols present in starUML
enterprise edition according to the identified actors and use cases
5. Draw the relationship between the use cases and actors as extend, include and
generalization types using the symbols.

16
RESULT
Thus the use case diagram is drawn successfully using starUML for the identified
requirements.

17
Ex No.4 UML-CLASS DIAGRAM

AIM
To identify conceptual classes and develop a domain model with UML Class diagram
using starUML.
CLASS DIAGRAM
In the Unified Modeling Language (UML), a class diagram is a collection of static
modeling elements, such as classes and their relationships, connected as a graph to each other
and to their contents; their internal structures, and their relationships to other classes.
A class is drawn as a rectangle with three components separated by horizontal
lines. The top name compartment holds the class name, other general properties of the class,
such as attributes, are in the middle compartment, and the bottom compartment holds a list
of operations. Either or both the attribute and operation compartments may be suppressed.
A separator line is not drawn for a missing compartment if a compartment is
suppressed; no inference can be drawn about the presence or absence of elements in it. The
class name and other properties should be displayed in up to three sections. A stylistic
convention of UML is to use an italic font for abstract classes and a normal (roman) font for
concrete classes.
PROCEDURE
1. Identify the classes that are taking part in the diagram.
2. Open the starUML and select logical view.
3. Select class diagram, specify the attributes, operations or methods.
4. Create the class diagram for the project.
5. Explicitly denote the relation between classes by generalizations, associations,
multiplicities and cardinalities.
6. Save the file.

18
RESULT
Thus the class diagram is drawn successfully using starUML for the identified
requirements.

19
Ex No.5 UML- SEQUENCE AND COLLABORATION DIAGRAMS

AIM
To draw sequence and collaboration diagrams for the identified scenarios and the
Interaction between objects using starUML.

INTERACTION DIAGRAM
Sequence diagram describes the behavior of the system by viewing the
interaction between the system and its environment. It represents the class at
the top and their lifetime, their interactions as relations.
A collaboration diagram, also called a communication diagram or interaction diagram,
is an illustration of the relationships and interactions among software objects in the Unified
Modeling Language (UML).

PROCEDURE
SEQUENCE DIAGRAM
1. Identify the initiator of the process.
2. Associate each actor with a class whether it uses or provides services.
3. Each actor is represented as a rectangle.
4. The sequence of flow is denoted by the name of the operations to be done.
5. The actors are separated by vertical dashed lines and sequence flow is indicated
through arrows.
6. Open the starUML enterprise edition.
7. Select logical view and sequence diagram.
8. Create the sequence diagrams, showing the interaction between the objects and
environmental.
9. Save the file.
COLLABORATION DIAGRAM
1. Select first an element where a new Communication Diagram to be contained as a child.
2. Select Model | Add Diagram | Communication Diagram in Menu Bar or select Add Diagram
| Communication Diagram in Context Menu.

20
RESULT
Thus the sequence and the collaboration diagrams for the identified scenarios and the
interaction between objects are drawn successfully using starUML for the requirements.

21
Ex No.6 (a) UML-STATE CHART DIAGRAM

AIM
To draw the state chart diagram for the identified requirements using starUML

STATE CHART DIAGRAM

A State chart diagram describes a state machine. State machine can be defined as a
machine which defines different states of an object and these states are controlled by external
or internal events. State chart diagram is used to describe the states of different objects in its
life cycle. So the emphasis is given on the state changes upon some internal or external events.
These states of objects are important to analyze and implement them accurately. States can be
identified as the condition of objects when a particular event occurs. The state chart
diagram shows the sequence of states that an object goes through during its life
in response to outside message. Set of values that describe an object at a
specific point in time.
PROCEDURE
1. Identify important objects to be analyzed.
2. Identify the states.
3. Identify the events.
4. Open the starUML enterprise edition.
5. Select logical view and state chart diagram.
6. Create state transition diagram for project.
7. Use the tools and draw the overall diagram.
8. Save the file.

22
RESULT
Thus the state chart diagram is drawn for the identified requirements successfully
using starUML for the requirements.

23
Ex No.6 (b) UML-ACTIVITY DIAGRAM

AIM
To draw activity the diagram for the identified requirements using starUML

ACTIVITY DIAGRAM
An activity diagram is a variation or special case of a state machine, in which the states
are activities representing the performance of operations and the transitions are triggered by
the completion of the operations. Unlike state diagrams that focus on the events occurring to a
single object as it responds to messages, an activity diagram can be used to model an entire
business process. The purpose of an activity diagram is to provide a view of flows and what is
going on inside a use case or among several classes.
An activity is shown as a round box, containing the name of the operation. When an
operation symbol appears within an activity diagram or other state diagram, it indicates the
execution of the operation. Executing a particular step within the diagram represents a state
within the execution of the overall method. It may be applied to any purpose such as
visualizing the steps of a computer algorithm, but is considered especially useful for
visualizing business workflows and processes, or use cases. Some of the outstanding notation
includes parallel activities, swim lanes, and action-object flow relationship. An activity
diagram allows the reader to see the system execution and how it changes direction based
upon different conditions and stimuli.
PROCEDURE
1. Identify the activities, association, conditions and constraints.
2. Name the correct alternative types.
3. It is essential for the diagram to have a start and end points.
4. Open the necessary tools from starUML and select usecase view.
5. Select activity diagram and create activity diagram for requirements of project using
the tools.
6. Save the file.

24
RESULT
Thus the activity diagram is drawn successfully using starUML for the requirements.

25
Ex No.7 IMPLEMENTATION OF THE SYSTEM AS PER THE DETAILED DESIGN

AIM:

To implement the user interface layer, domain layer and technical services layer for
the given project.

USER INTERFACE LAYER

This layer provides the user interface (UI) within a composite application. To increase
user productivity, user interfaces should support easy adoption. The limitations on the UI
design resulting from the capabilities of the underlying components should not be seen as
constraints, but rather as some help to provide consistent UIs.
User interfaces consume Web services either from the business logic layer or the back-
end layer to retrieve and update data. They do not contain any business logic. UI and business
logic decoupling is implemented by using services of the business logic layer only. User
interfaces are integrated in the overall composite process by being wrapped into a callable
object.
DOMAIN LAYER
A domain layer also known as the business logic layer (BLL) is a software engineering
practice of compartmentalizing. The business logic layer is usually one of the tiers in a
multitier architecture. It separates the business logic from other modules, such as the data
access layer and user interface. By doing this, the business logic of an application can often
withstand modifications or replacements of other tiers. For example, in an application with a
properly separated business logic layer and data access layer, the data access layer could be
rewritten to retrieve data from a different database, without affecting any of the business
logic. This practice allows software application development to be more effectively split into
teams, with each team working on a different tier simultaneously.
TECHNICAL SERVICES LAYER
The Infrastructure Layer may be partitioned into different levels (high-level or low-
level technical services). Though, it is not unusual that developers only consider the
persistence (data access) and therefore only talk about the Persistence Layer or the Data
Access Layer (instead of an Infrastructure Layer or Technical services Layer).In other words,

26
the other kind of technical services are not always being explicitly thought of as being part of
any particular layer.
PROCEDURE
1. Create class diagram and component diagram for the given project using starUML
2. Right click on component diagram and select the software needed to generate code.
3. Right click on class diagram and assign created component with this class.
4. Generate code from tool menu and create a form. Then a window appears with
provision to type coding.
5. Type the coding and execute the form.

RESULT
Thus the user interface, domain and technical services layer for the given project was
developed and tested for the given project.
27
Ex No.8 CREATION OF TEST PLAN AND TEST CASES
AIM
To create Test the software system for all the scenarios identified as per the use case diagram

TEST PLAN AND TEST CASES

A test plan documents the strategy that will be used to verify and ensure that a product
or system meets its design specifications and other requirements. A test plan is usually
prepared by or with significant input from test engineers. A test case is a set of conditions
under which a tester will determine whether an application, software system or one of its
features is working as it was originally established for it to do. The mechanism for
determining whether a software program or system has passed or failed such a test is known
as a test oracle.

PROCEDURE
Test Plan Document:
1. Test plan document contains all the catalog information of test strategies, objectives, schedule,
estimations and resources required to complete the project.
2. A “Test Case” refers to the actions required to verify a specific feature or functionality in
software testing.
Test Case Design Template:
Test Case Description: Test Steps: Expected Pre Pass/Fail: Remarks:
ID: Results: Requisites:

28
RESULT

Thus new test plan, test case, test case folder are created successfully.

29
Ex No.9 IMPROVE THE REUSABILITY AND MAINTAINABILITY OF THE SOFTWARE
SYSTEM BY APPLYING APPROPRIATE DESIGN PATTERNS

AIM
To improve the reusability and maintainability of the software system by applying
appropriate design patterns.

Pattern
Pattern is a named and well-known problem/solution pair that can be applied in
new contexts, with advice on how to apply it in novel situations and discussion of its trade-
offs implementations, variations, and so forth.
Naming a pattern, design idea, or principle has the following advantages:
• It supports chunking and incorporating that concept into our understanding and
memory.
• It facilitates communication.
GRASP patterns
 Creator  Pure Fabrication
 Information Expert  Indirection
 Low Coupling  Polymorphism
 Controller  Protected variations
 High Cohesion
A. Name: Creator
Problem: Who should be responsible for creating a new instance of some class?
Solution: Assign class B the responsibility to create an instance of class A if one of these is true
• B contains or aggregates A (in a collection)
• B records A
• B closely uses A
• B has the initializing data for A that will be passed to A when it is created
B is a creator of A objects.
If more than one option applies, usually prefer a class B which aggregates or contains class A.
B. Name: Information Expert
Problem: What is a general principle of assigning responsibilities to objects?

30
Solution: Assign a responsibility to the information expert - the class that has the information
necessary to fulfill the responsibility.
C. Name: Low Coupling
Problem: How to support low dependency, low change impact, and increased reuse?
Solution: Assign a responsibility so that coupling remains low. Use this principle to evaluate
alternatives
D. Name: High Cohesion
Problem: How to keep objects focused, understandable, and manageable, and as a side effect,
support Low Coupling?
Solution: Assign responsibilities so that cohesion remains high. Use this to evaluate
alternatives.
E. Name: Controller
Problem: What first object beyond the UI layer receives and coordinates ("controls") a system
operation?
– A controller is the first object beyond the UI layer that is responsible for
receiving or handling a system operation message.
– System operations were first explored during the analysis of SSD.
– These are the major input events upon our system.
Solution: Assign the responsibility to a class representing one of the following choices:
– Represents the overall "system," a "root object," a device that the software is
running within, or a major subsystem these are all variations of a facade
controller.
– Represents a use case scenario within which the system event occurs, often
named <UseCase Name>Handler, <UseCase Name> Coordinator, or
<UseCase Name> Session .
• Use the same controller class for all system events in the same use case
scenario.
• A session is an instance of a conversation with an actor.

31
RESULT
Thus the reusability of the software system by applying appropriate design pattern
have been maintained and improved.

32
Ex No.10 IMPLEMENT THE MODIFIED SYSTEM AND TEST IT FOR VARIOUS
SCENARIOS

AIM:
To implement the modified system as per the identified design patterns and test it for
various scenarios.
USER INTERFACE LAYER
This layer provides the user interface (UI) within a composite application. To increase
user productivity, user interfaces should support easy adoption. The limitations on the UI
design resulting from the capabilities of the underlying components should not be seen as
constraints, but rather as some help to provide consistent UIs.
User interfaces consume Web services either from the business logic layer or the back-
end layer to retrieve and update data. They do not contain any business logic. UI and business
logic decoupling is implemented by using services of the business logic layer only. User
interfaces are integrated in the overall composite process by being wrapped into a callable
object.
DOMAIN LAYER
A domain layer also known as the business logic layer (BLL) is a software engineering
practice of compartmentalizing. The business logic layer is usually one of the tiers in a
multitier architecture. It separates the business logic from other modules, such as the data
access layer and user interface. By doing this, the business logic of an application can often
withstand modifications or replacements of other tiers. For example, in an application with a
properly separated business logic layer and data access layer, the data access layer could be
rewritten to retrieve data from a different database, without affecting any of the business
logic. This practice allows software application development to be more effectively split into
teams, with each team working on a different tier simultaneously.
TECHNICAL SERVICES LAYER
The Infrastructure Layer may be partitioned into different levels (high-level or low-
level technical services). Though, it is not unusual that developers only consider the
persistence (data access) and therefore only talk about the Persistence Layer or the Data
Access Layer (instead of an Infrastructure Layer or Technical services Layer).

33
RESULT
Thus the modified system as per the identified design pattern is implemented and
tested for various scenarios.

34
 CONTENT BEYOND THE SYLLABUS
Ex No.11 UML- PACKAGE DIAGRAM

AIM
To draw the partial layered, logical architecture diagram with UML package diagram
notation for identified the user interface, domain objects, and technical services.

PACKAGE DIAGRAM

A package is a grouping of model elements. Packages themselves may contain other

packages. A package may contain both subordinate packages and ordinary model elements.
The entire system can be thought of as a single high-level package with everything else in it.
All UML model elements and diagrams can be organized into packages. Package diagrams are
used to illustrate the layers. In the UML , a layer is simply a package.
A package is represented as a folder, shown as a large rectangle with a tab attached to
its upper left corner. If contents of the package are not shown, then the name of the package is
placed within the large rectangle. If contents of the package are shown , then the name of the
package may be placed on the tab .The contents of the package are shown within the large
rectangle. The logical architecture, describes the system in terms of its conceptual
organization in layers, packages, major frameworks, classes, interfaces, and subsystems.
PDs can be used to show groups of classes in Class Diagrams (CDs), groups of
components or processes in Component Diagrams (CPDs), or groups of processors in
Deployment Diagrams (DPDs).
There are three types of layer. They are
 User interface layer -graphical interface; windows.
 Domain layer -software objects representing domain concepts that fulfill application
requirements.
 Technical services layer -general purpose objects and subsystems that provide
supporting technical services, such as interfacing with a database or error logging.
These services are usually application-independent and reusable across several
systems.

35
PROCEDURE
1. Select the starUML enterprise edition.
2. Select the logical view and open the class diagram, from the tools displayed in the class
diagram window select the package tool.
3. Using the package tool the outer layer package and the inner software package along
with the dependencies between the packages are drawn.
4. Save the file.

36
RESULT
Thus the partial layered, logical architecture diagram with UML package diagram
notation for identified the user interface, domain objects, and technical services package
diagram is drawn using starUML.

37
Ex No.12 COMPONENT AND DEPLOYMENT DIAGRAMS

AIM
To draw component and deployment diagrams for the identified requirements using
starUML.

COMPONENT AND DEPLOYMENT DIAGRAMS

Component diagram is a special kind of diagram in UML It does not describe the
functionality of the system but it describes the components used to make those
functionalities. So from that point component diagrams are used to visualize the physical
components in a system. These components are libraries, packages, files etc. It can also be
described as a static implementation view of a system. Static implementation represents the
organization of the components at a particular moment. A single component diagram cannot
represent the entire system but a collection of diagrams are used to represent the whole.
Deployment diagrams are used for describing the hardware components where
software components are deployed. Component diagrams and deployment diagrams are
closely related. Deployment diagrams shows how components are deployed in hardware. A
deployment diagram consists of nodes. Nodes are nothing but physical hardware used to
deploy the application.
PROCEDURE
COMPONENT DIAGRAM
1. Identify the files used in the system, libraries, other artifacts relevant to the application
and the relationships among the artifacts.
2. Visualize the components of a system.
3. Construct executables by using forward and reverse engineering.
4. Describe the organization and relationships of the components.
5. Select starUML and open the specific project.
6. Select component view of the project and draw the diagram along with the
dependencies using appropriate tools.
7. Save the diagram

38
DEPLOYMENT DIAGRAM
1. Identify the node and Relationships among nodes
2. Visualize hardware topology of a system.
3. Describe the hardware components used to deploy software components.
4. Describe runtime processing nodes.
5. Select starUML and open the specificproject.

6. Select deployment view of the project and draw the diagram along with the device
node and environment node using the appropriate tools.

7. Save the diagram

39
RESULT
Thus the component and the deployment diagrams are drawn successfully
using starUML.
40
41