TABLE OF CONTENTS

S.NO. DATE EXPERIMENT TITLE PAGE MARKS SIGN.

NO.
5
1 2O.O2.24 Identify a software system that needs
to be developed
7
2(a) 19.O3.24 Project creation using staruml
13
2(b) 19.03.24 Creation of software requirement
specification
19
3 UML-use case diagram
28.03.24
24
4 UML-class diagram
16.04.24
27
5 UML sequence and collaboration
28.04.24
diagram

32
6(a) 28.04.24 UML-state chart diagram
35
6(b) 28.04.24 UML-activity diagram
38
7 Implement the system as per the
28.04.24
detailed design
45
8 29.04.24 Creation of test plan and test cases
49
9 Improve the reusability and
29.04.24
maintainability of the software
system by applying appropriate
design patterns
Implement the modified system and 54
10 29.04.24 test it for various scenarios

62
11 29.04.24 UML - package diagram

66
12 29.04.24 Component and deployment diagrams

1
 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
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 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.

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 Date : 20.02.24 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 STARUML

Date :19.03.24

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.

7
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.

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.

8
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.

9
Creating New Project

Opening Project

1
Procedure for saving project

Closing Project

1
RESULT

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

1
 Ex No: 2 (b) CREATION OF SOFTWARE REQUIREMENT

SPECIFICATION Date : 19.03.24

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

The Software Requirements Specification (SRS) outlines the requirements for developing a Book Bank
System. This system aims to streamline book lending processes within educational institutions. By
automating tasks like borrowing, returning, and inventory management, it enhances efficiency and user
experience. This document details functional and non-functional requirements, guiding the development
process to ensure the system meets stakeholders' needs. Key stakeholders include administrators,
librarians, and users. The system intends to revolutionize book management, providing a user-friendly
and efficient solution.

1
PURPOSE

The Book Bank System is designed to streamline book lending processes within educational institutions.
Its primary purpose is to improve efficiency by automating tasks such as book borrowing, returning, and
inventory management. By providing a user-friendly interface, the system enhances the overall
experience for students, faculty, and administrators alike. It ensures accurate tracking of book inventory,
minimizing instances of lost or misplaced books. Promoting accountability, the system records
transactions and user activity, fostering transparency in lending operations. Additionally, it increases
accessibility to books through online search and reservation capabilities. By capturing data on book usage
patterns, the system enables informed decision-making for resource allocation. Overall, the Book Bank
System serves as a comprehensive solution to effectively manage book resources and enhance the
educational experience.

SCOPE
The Book Bank System facilitates efficient book lending in educational institutions through user
management, inventory tracking, borrowing and returning features, reservation system, administrative
tools, integration with existing systems, robust security measures, and user-friendly interface. It aims to
enhance accessibility, streamline operations, ensure accountability, and provide scalability while offering
ongoing support and maintenance services.

System Features and Requirements

FUNCTIONAL REQUIREMENTS
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?

1
 NON FUNCTIONALREQUIREMENTS

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.

1
RESULT
Thus the requirements specification, requirement views and packages for the project created and
executed successfully.

1
 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.

1
UML DIAGRAMS
UML defines nine graphical diagrams
 Use-case diagram
 Class diagram
 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.

1
 Ex No:3 UML- USE CASE
DIAGRAM Date :28.03.24

AI
M
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 use cases,
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.

1
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.

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.

2
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 use case 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.

2
OUTPUT

USE CASE DIAGRAM

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

2
 Ex No:4 UML-CLASS DIAGRAM
Date :16.04.24

AI
M
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.

2
OUTPUT

CLASS DIAGRAM

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

2
 Ex No: 5 UML- SEQUENCE AND COLLABORATION
DIAGRAMS Date :28.04.24

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 c l a s s 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.

2
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.

2
OUTPUT

SEQUENCE DIAGRAM

2
COLLABORATION DIAGRAM

3
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.

3
 Ex No:6 (a) UML-STATE CHART DIAGRAM
Date :28.04.24

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 t h e sequence of states that an object goes through during its life in response
to outside message.

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.

3
OUTPUT

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

3
 Ex No:6 (b) UML-ACTIVITY
DIAGRAM Date :28.04.24

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.
3
OUTPUT

ACTIVITY DIAGRAM

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

3
Ex No:7 IMPLEMENTATION OF THE SYSTEM AS PER THE DETAILED

DESIGN Date:28.04.24

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.

3
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,
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.

3
OUTPUT

4
BOOK BANK MANAGEMENT SYSTEM

4
4
4
4
RESULT
Thus the user interface, domain and technical services layer for the given
project was developed and tested for the given project.

4
Ex No: 8 CREATION OF TEST
PLAN Date : 29.04.24 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:

4
OUTPUT

4
RESULT

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

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

DATE:29.04.24

AI
M
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. N
ame: Creator
Problem: Who should be responsible for creating a new instance of e class?
som A if one of
Solution: Assign class B the responsibility to create an instance of
class these is true
• B contains or aggregates A (in a collection)
• B closely uses A
• B has the initializing data for A that will be passed to A
If more than one option applies, usually prefer a class B which
4
 aggregates or contains class A.

B. Name: Information Expert

Problem: What is a general principle of assigning responsibilities to objects?

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 <Use Case Name>Handler, <Use Case

5
 Name> Coordinator, or
<Use Case 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.

OUTPUT

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

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

DATE:29.04.24

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.

5
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).

5
OUTPUT

5
LOGIN PAGE FOR STUDENTS

5
MEMBERSHIP FORM FOR BOOK BANK

5
BOOK ISSUE FOR 1ST YEAR

BOOK ISSUE FOR 2ND YEAR

5
ADMINISTRATOR LOGIN PAGE

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

6
 CONTENT BEYOND THE SYLLABUS

Ex No:11 UML- PACKAGE DIAGRAM

Date :29.04.24

AI
M
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.

6
  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.

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.

6
OUTPUT

PACKAGE DIAGRAM

6
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.

6
 Ex No:12 COMPONENT AND DEPLOYMENT
DIAGRAMS Date :29.04.24

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.

6
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

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 specific project.
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

6
COMPONENT DIAGRAM

6
DEPLOYMENT DIAGRAM

6
RESULT
Thus the component and the deployment diagrams are drawn
successfully using starUML.