SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM

ENGINEERING LAB

COURSE OBJECTIVES
• To understand the object oriented concepts.
• To understand the concept of UML Diagrams.
• To train in Rational ROSE and Agro UML Tool.
• To capture the requirements specification for an intended software system.
• To draw the UML diagrams for the given specification.
• To map the design properly to code.

SUGGESTED LIST OF EXPERIMENTS

EX-NO-1 Study Experiment – Object Oriented Concepts

Aim:
To study about the object-oriented concepts.

Description:
Basic OO Concepts

Introduction:

Goal of OO: Reduce complexity of software development by keeping details, and

especially changes to details, from spreading throughout the entire program.

This presentation assumes "Basic Class Design" presentation.

Definitions

▪ Client Code - the code that uses the classes under discussion.

▪ Coupling - code in one module depends on code in another module

Change in one forces rewrite (horrible!), or recompile (annoying), of code in the other.

Four key concepts of OOP

1. Abstraction - responsibilities (interface) is different from implementation

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

▪ Distinguish between interface and its behavior vs. the implementation

and its details

▪ A class provides some services, takes on some responsibilities, that are

defined by the public interface. How it works inside doesn't matter.

▪ Client should be able to use just the public interface, and not care about
the implementation.

2. Encapsulation - guarantee responsibilities by protecting implementation from

interference

▪ Developer of a class can guarantee behavior of a class only if the

internals are protected from outside interference. Specifying private
access for the internals puts a wall around the internals, making a clear
distinction between which code the class developer is responsible for,
and what the client developers are responsible for.

3. Inheritance - share interface and/or implementation in related classes

▪ Express commonalities between classes of objects by arranging them

into an inheritance hierarchy. Allows functionality shared between
classes to be written/debugged/maintained in one place, the base class,
and then reused in descendant classes (shared implementation).

▪ More importantly, allows client code to interact with classes in the

hierarchy through an interface specified in the base class of the hierarchy
(shared interface).

4. Polymorphism - decouple client from exact class structure

▪ Allows client code to use classes in an class hierarchy in a way that

depends only on the public interface of the base class. Derived classes
will implement this interface differently, but in ways compatible with the
shared public interface.

General Approach for Designing Classes:

Do the class design work at the level of the public interfaces, not the private
implementations.

I. Don’t get bogged down in implementation details like “I can do with this with a
map container and a deque!”
II. Think only about what the class responsibilities are and what they do in their

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

public interfaces:

✓ Class X is responsible for …., class Y for ….

✓ When an X object needs … it calls the public member function … of

the appropriate Y object with … as parameters, which returns …

III. Try writing pseudo code just for the interactions between class objects through
their public interfaces.

IV. Keep this up until you can’t stand it any more, then make implementation
choices and write the code.

Continue design thinking until you have thought of at least two reasonable ways to
solve each design problem.

I. “Reasonable” here means “not obviously stupid.”

II. Don’t just jump on the first design you think of and hack it out.

III. All designs are imperfect - they all involve trade-offs. They are good in some
ways, bad in others.

IV. A good design is good in the most important ways, and bad in the less important
ways.

V. But there might be more than one good design - just different in the specific
tradeoffs.

VI. You can’t make an intelligent choice if you have only thought of one design -
there could be another, better, simpler one.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

EX-NO-2 Study of UML Diagrams – Aim and Scope of Diagrams

AIM:
General study of UML

DESCRIPTION:
Why is UML important?
Let's look at this question from the point of view of the construction trade. Architects
design buildings. Builders use the designs to create buildings. The more complicated the
building, the more critical the communication between architect and builder. Blueprints are the
standard graphical language that both architects and builders must learn as part of their trade.
Writing software is not unlike constructing a building. The more complicated the
underlying system, the more critical the communication among everyone involved in creating
and deploying the software. In the past decade, the UML has emerged as the software blueprint
language for analysts, designers, and programmers alike. It is now part of the software trade.
The UML gives everyone from business analyst to designer to programmer a common
vocabulary to talk about software design.
The UML is applicable to object-oriented problem solving. Anyone interested in
learning UML must be familiar with the underlying tenet of object-oriented problem solving --
it all begins with the construction of a model. A model is an abstraction of the underlying
problem. The domain is the actual world from which the problem comes. Models consist of
objects that interact by sending each other messages. Think of an object as "alive." Objects have
things they know (attributes) and things they can do (behaviors or operations). The values of an
object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors
(methods or functions) into a single distinct entity. Objects are instances of classes.

UML NOTATION
• Unified Modeling Language.
• Set of notations and conventions used to describe and model an application.
• Universal language for modeling systems.
• Standard notation for OO modeling systems.
• Does not specify methodology to develop an application.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

UML DIAGRAMS

The heart of object-oriented problem solving is the construction of a model. The model
abstracts the essential details of the underlying problem from its usually complicated real world.
Several modeling tools are wrapped under the heading of the UML™, which stands for Unified
Modeling Language™. The purpose of this course is to present important highlights of the
UML.
At the center of the UML are its nine kinds of modeling diagrams, which we describe
here.
• Class Diagram
• Use Case Diagram
• Behavioral Diagram
✓ Interaction Diagram
▪ Sequence Diagram
▪ Collaboration Diagram
✓ State Chart Diagram
✓ Activity Diagram
• Implementation Diagram
✓ Component Diagram
✓ Deployment Diagram
Some of the sections of this course contain links to pages with more detailed
information. And every section has short questions. Use them to test your understanding of the
section topic.

CLASS DIAGRAM
• Shows the static structure of the model.
• Collection of static modeling elements such as classes and their relationships
connected as a graph.
• Provides visual representation of objects, relationships and their structures.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

Class:-
• A class is a set of objects that share a common structure and common behavior.

<Class Name>
<Attributes>
<Operations>

Interface:-
• Specifies the externally-visible operations of a class and/or component.

Association:-
• Model properties of associations.
• The properties are stored in a class and linked to the association relationship.
• Example,

Bank Account Person

Generalization:-
• A generalize relationship is a relationship between a more general class or use case and
a more specific class or use case.
• Example,

Vehicle

Bus Truck Car

USE CASE DIAGRAM

• Set of use cases enclosed by system boundary, communication association between
actors and use cases, and generalization among use cases.
Actors:-
• External factors that interacts with the system from the user's perspective.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

Use Cases:-
• Set of scenarios that describe how actor uses the system.
• Represented as,

Relationship:-
• Communication – communications with the use case normally.
• Uses – Shown by generalization arrow from the use cases.
• Extends – Used when one case does more than another that is similar to it.

BEHAVIOR DIAGRAM
INTERACTION DIAGRAM

• Diagrams that describes how group of objects are collaborated.

SEQUENCE DIAGRAM:
• Describes the behavior of the system through interaction between the system and the
environment in time sequence.
• Two dimensions:
✓ Vertical dimension – represents time.
✓ Horizontal dimension – represents objects.
• Life line – Object's existence during the interaction.

Object 1 Object 2

<Event>

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

COLLABORATION DIAGRAM:
• An interaction diagram that shows the order of messages that implement an operation
or a transaction.
• Collaboration diagrams show objects, their links, and their messages.

Object 1 Object 2
1. <Event >

Object:-
• An object has state, behavior, and identity.
• Objects interact through their links to other objects.
Link:-
• A link is an instance of an association, analogous to an object.
Message:-
• A message is the communication carried between two objects that trigger an event.

STATECHART DIAGRAM
• Models the dynamic behavior of individual classes or any other kind of object.
• Shows the sequences of states, events, and actions.
State:-
• Represents a condition or situation during the life of an object during which it satisfies
some condition or waits for some event.

<State>

Start State:-
• Shows the beginning of workflow.

End state::-
• Represents the final or terminal state.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

ACTIVITY DIAGRAM
• Used for modeling the sequence of activities in a process
• 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.
Activity:-
• Represents the performance of task or duty in a workflow.

<Activity>

Swim lanes:-
• Represents organizational units or roles within a business model.
IMPLEMENTATION DIAGRAM
• Shows the implementation phase of system development.
• Two types of implementation diagrams:
✓ Component diagram
✓ Deployment diagram

COMPONENT DIAGRAM
• Models the physical components in the design.
• A graph of the design’s components connected by dependency relationships.
• Includes concept of packages.
• Package is used to show how classes are grouped together.

DEPLOYMENT DIAGRAM
• Shows the configuration of runtime processing elements and software components.
• It is a graph of nodes connected by communication association.
• Nodes are the components that are connected to other components through
dependencies.
• Used in conjunction with component diagrams to show the distribution of physical
modules.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

EX-NO-3 Study of CASE Tools – StarUML

1. Basic Concepts
• Project is a top-level element stored as a single file.
• Modeling a software system requires describing multiple models because it is not enough to
describe the system with a single perspective, so we typically make multiple models such as
UseCase Model, Design Model, Component Model, Deployment Model, or others in a Project.
• Typically Project is organized as a set of UMLModels, UMLPackages, or UMLSubsystems.
If you want to know more about UML Elements, please refer to OMG UML Specification.

2. Managing Project
• New Project: To create a modeling project, press Ctrl+n or select File | New.
• Open Project: If you have model files (.mdj), you can open it in StarUML. To open a
model file, press Ctrl+o or select File | Open... and then select a file in Open Dialog.
• Open StarUML V1 File: If you have StarUML V1 model files (.uml), you can import by
selecting File | Import | StarUML 1 File (.uml)...
• Save Project: You can save the working project into a file by pressing Ctrl+s or selecting
File |Save. If you want to save as another file, press Ctrl+Shift+s or select File | Save As....
• Close Project: To close working project, select File | Close. If you didn’t saved the project,
you will be asked to save or not.
• Export Fragment: To export a part of the project as a fragment, select File | Export |
Fragment... and then select an element to export in Element Picker Dialog.
• Import Fragment: To import a fragment into the project, select File | Import |
Fragment.... The fragment will be included as a child of the project.
• Delete Diagram: To delete a Diagram:

1. Select a Diagram to delete in Explorer.

2. Press Ctrl+Delete or select Edit | Delete from Model in Menu Bar or Delete from
Model in Context Menu.

3. Generating Codes and Documents

• Generating Documents Artifacts To generate artifacts by template, it must be applicable

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

to current working UML model.

1. Select [Tools]->[StarUML Generator...] Menu
2. Check templates to generate in the ListBox and Click [Next] Button. For requirements model
(Use Case Model) select Requirement
3. In the [Select target path] Page, Select a folder that generated artifacts will be placed and click
[Next] button. If you want to create a new folder, click [New Folder...] button and input name
of the new folder.
4. In the [Generating...] Page, click [Generate] button. You can check the progress of generation
and it will be logged on Logs. If you want to cancel the generation process, click [Cancel] button.
When all artifacts are successfully generated, [Finish] will be enabled and clicking it will finish
the artifact generation. To see generated artifacts, double-click the item that want to see in the
[Generation List] then the generated artifact will be opened.

Generating Codes Artifacts (Convert Class Diagrams to Codes)

1. First go to "Model/Profile..." to set the "profile" used by the project, which determines
which symbols and conventions will be in use. Be sure to include the "C# Profile" in the
project.
2. To generate the C# stub cod go to "Tools" on the main menu, expand "C#", and select
"Generate Code"
3. From this dialog box, select your model, probably named "Model1"and press "Next" •
Choose "Select All" to generate stub code for all the classes in your model/diagram and
then press "Next". • Select a valid output directory and select "Next".
4. In the "Options Setup", be sure to check both "Generate the Documentation by C#Doc" and
"Generate empty JavaC#". All other checkboxes should be unchecked. Then press "Next".
• StarUML will now generate the code stubs from your diagram. Click "Finish" to exit the
dialog. • You can now edit the generated stub code to add functionality to the application.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

EX-NO-4 STUDENT INFORMATION SYSTEM

AIM

To design an object-oriented model for Student information system using StarUML

software.

PROBLEM STATEMENT

The student must register by entering the name and password to login the form. The
admin select the particular student to view the details about that student and maintaining the
student details. This process of student information system is described sequentially through
following steps. The student registers the system. The admin login to the student information
system. He/she search for the list of students. Then select the particular student. Then view the
details of that student. After displaying the student details then logout.

CLASS DIAGRAM

The class diagram is the graphical representation of all classes used in the system. The
class diagram is drawn as rectangular box with three components or compartments like class
name, attributes and operations. The student information system makes use of the following
classes like student, staff, system, DBA and server.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

COLLABORATION DIAGRAM

A Collaboration diagram represents the collaboration in which is a set of objects related

to achieve a desired outcome. In collaboration, the sequence is indicated by numbering the
message several numbering schemes are available. Login, request access, allow access, display,
view details, logout, login, request access, allow access, display, enter profile, enter mark,
provide data, logout, store data, update data.

SEQUENCE DIAGRAM

A Sequence diagram represent the sequence and interaction of a given usecase or

scenario. Sequence diagram capture most of the information about the system. Here the
sequence starts between the student and the system. The second half of interaction takes place
between staff and system then by police and followed by database. The student first login to the
system and then view the details of the details. Staff login to the system enter mark and enter
the details of the student. DBA store and update the details of the student.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

COMPONENT DIAGRAM

Component diagram carries the major living actors of the system. The component
diagram main purpose is to show the structural relationship between components of the
system.The main component of the system is student information system and the other
components of the system are student, staff and DBA.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

USE CASE DIAGRAM

Use case diagram is a graph of actors, a set of use cases, association between the actors
and the use cases and generalization among the cases. Use case diagram is a list of actions or
events. Use case diagram was drawn to represent the static design view of the system. Steps
typically defined the interactions between a role and a system to achieve a goal. The use case
diagram consists of various functionality performed by the actors like student, staff, system,
DBA and server. The use case diagram consists of various functionality like login, display,
enter profile, enter mark, view details, update details, allow access, request access, store details,
logout.

DEPLOYMENT DIAGRAM

Deployment diagram shows the configuration of runtime processing elements and the
software components processes and objects that live in them. Component diagram are used in
conjunction with deployment diagram to show how physical modules code are distributed on
various hardware platform. The processor node in the system is student information system and
the execution environment nodes or device nodes are student, staff and DBA.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

STATE CHART DIAGRAM

A State chart diagram is also called as state machine diagram. The state chart contains
the states in the rectangular boxes and the states are indicated by the dot enclosed. The state
chart diagram describes the behavior of the system. The state chart involves six stages such as
login, enter mark, enter profile, view details, provide details, update details, store details and
logout.

ACTIVITY DIAGRAM

Activity diagram are graphical representation of stepwise login enter marks enter profile

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

view details logout store details update details activities and actions with support for choice,
interaction and concurrency. Here in the activity diagram the student login to the system and
view the details of the student. The staff login to the system for entering the student details and
update the details in the database. The final interaction is the DBA store the details of the
student.

RESULT

Thus the various UML diagrams for student information system were drawn and code
was generated successfully.

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB

SATHYABAMA INSTITUTE OF SCIENCE AND TECHNOLOGY SCHOOL OF COMPUTING

SCSA2401 OBJECT ORIENTED ANALYSIS AND SYSTEM ENGINEERING LAB