ANJALAI AMMAL - MAHALINGAM ENGINEERING COLLEGE

KOVILVENNI-614 403, THIRUVARUR DISTRICT

NAAC Accredited with “B” Grade
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

LAB MANUAL

Laboratory Course Code : CCS356

Laboratory Course Title :Object Oriented Software Engineering(OOSE)

Semester : VI

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

Course Teacher : Mr. P. Dinesh

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
using UML 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 use case 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: 30 PERIODS
2
Requirements
HARDWARE REQUIREMENTS
Standard PC
SOFTWARE REQUIREMENTS
1. Windows 7 or higher
2. StarUML
3. ArgoUML that supports UML 1.4 and higher
4. Selenium, JUnit or Apache JMeter

3
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 rolein building of that system.
Analysis
1. Analysis emphasizes an investigation of the problem and requirements, rather
than asolution.
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.

Software Engineering
Software Engineering is the process of designing, developing, testing, and maintaining
software. It is a systematic and disciplined approach to software development that aims to create
high-quality, reliable, and maintainable software.

4
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