The accelerator pedal hides from the driver the complex

1. CHAPTER -4 SYSTEM DESIGN
4.1. Introduction
In this chapter, we embark on a comprehensive exploration of the foundation elements crucial to
the development of an efficient and robust engineering college department placement system.
Eexamination into the intricacies of design issues specific to the system, we address fundamental
concerns such as reusability, scalability, and adaptability to future changes. Introducing the
concept of design patterns, we provide invaluable insights into reusable and proven solutions for
common software design challenges. Display the blueprints of our system, we navigate through
the Class Diagram and Database Model, exploring the intricacies of the Entity Relationship
Diagram (ERD), Persistence Modeling, and the essential process of Mapping with Normalization.
Navigating the terrain of Subsystem Decomposition, we break down the system into manageable
and interconnected components. Focusing on the system's external interactions and deployment
environment, we detail the Deployment Diagram and unravel the layers of the System
Architecture, encompassing both the overall system architecture and the nuanced details of
architectural patterns and styles. The chapter concludes by delving into User-Interface (UI)
Design, exploring the principles and considerations that underpin the creation of an intuitive and
user-friendly interface, and unfolding the dynamics of UI Flow Diagramming, providing a visual
narrative of the user's interaction with the placement system. This comprehensive exploration sets
the stage for subsequent chapters, where these design principles and frameworks will be translated
into the tangible development of the placement system.
4.2. Design issues for your system
The issues of designing the system is to implement automated student department placement for
WCU collage of engineering and technology and to show the direction how the system is built and
to obtain clear and enough information needed to drive the actual implementation of the system.
The design issues are derived from the non-functional requirements of the system, which were
stated in chapter two of this document. They describe the qualities of the system. These goals
consider the following criteria.
 Security: - the system should be secured, that means not allow other users or unauthorized
users to access data that has no the right to access it. User’s account is created by the
system administrator, so, no one can’t create an account by themselves and use the system.
But person who has an account can login to the system using his/her username and
password and use the system.
 Modifiability: - the system should be modifiable for further modification and
enhancement of the application.

2.  Performance: - WCU collage of engineering and technology student department
placement system should respond fast with high throughput that is it should perform
retrieving placement information, choosing field of study, updating student’s placement
and generating report as quickly as possible.
 Availability: - this system should always be available for access at 24 hours, 7 days a
week unless in the occurrence of any major system malfunctioning, the system should be
available in all working days, so that the placement process is not severely affected.
 End user: - The system should have simple and understandable graphical user interface
such as forms and buttons, which have descriptive names. It should give reliable response
for each request.
 Error handling: - When the users interact with the system errors may appear. In addition
to the operating system error handling mechanism we use exception handler during
implementation. To control these inaccuracies, the system will generate different
messages.
 Reliability: - Online student’s department placement system should be reliable i.e. the
ability to perform as intended, in spite of apparently random hardware and software
failures.
 Fault Tolerance: - The system should be able to give response (error message) when the
user enters incorrect input. This recommends the user to enter correct input.
 Dependability: - The system needs not to be highly dependable as it is expected to be
used by unprofessional users.
4.3. Design patterns
Design patterns of system involves considering various aspects such as user interactions, data
management, and system extensibility. Here's a more specific breakdown of design patterns that
could be applied to different components of the system:
Model-View-Controller (MVC):- Separate the system into three main components - Model
(student data, placement rules), View (user interface for interaction), and Controller (handles user
input, processes placement).Facilitates modular development, making it easier to update or replace
components independently.
Repository Pattern: - Use a repository to manage the storage and retrieval of student and
department data. Implement specific repositories for different data entities. Abstracts the data
access logic, allowing for easier maintenance and potential changes in the data storage mechanism.
Strategy Pattern: - Employ the strategy pattern for placement algorithms. Allow different
algorithms (strategies) for placing students based on various criteria. Enables easy switching

3. between placement strategies, and supports the addition of new strategies without modifying
existing code.
Command Pattern: - Use the command pattern for handling user requests related to placements.
Each command object encapsulates a specific action. Allows for the queuing of requests, logging,
and the possibility of undoing operations.
State Pattern:-Apply the state pattern to manage the different states of the placement process
(e.g., registration, evaluation, and placement).simplifies state transitions and avoids complex
conditional statements, improving maintainability.
Factory Method Pattern: - Implement a factory method to create instances of placement-related
objects, such as placement algorithms or evaluators. Provides a consistent way to create objects,
making it easier to extend or modify the system.
Composite Pattern: - Apply the composite pattern to represent departments and students as
composite objects, allowing for uniform treatment. Simplifies the handling of individual students
or departments and their groups.
Chain of Responsibility Pattern: - Implement the chain of responsibility to process placement
requests through a series of handlers, each responsible for a specific task.
Supports the decoupling of request senders and receivers, and allows for flexible request handling.

4. 4.4. Class Diagram
Figure 4.1: Class Diagram

5. 4.5. Database Model
4.5.1 Entity Relationship Diagram (ERD)
Figure 4.2: Entity Relationship Diagram

6. 4.6. Subsystem Decomposition
Subsystem decompositions will help to reduce the complexity of the system. The subsystems can
be considered as packages holding related classes/objects. The student department placement
system is divided in to six subsystem decomposition with their function. Those are:
 User account management subsystem: - This subsystem is responsible for handling user
information that is managed by system administrator.
 Create account
 Delete account
 Update account
 Assign role
 Placement subsystem: - This subsystem is responsible for handling placement
information stored in the system.
 Choose department
 View placement
 Complaint subsystem decomposition: - This subsystem is responsible for handling
students request of file complaint and manage complaint request.
 File complaint
 Manage complaint
 Post placement subsystem:-This subsystem is responsible for providing information
about announcement placement and view placement.
 Post placement
 View placement
 Department management subsystem: - This subsystem is responsible for handling
departments detail information.
 Approve department cutting point
 Approve department holding capacity

7. Figure 4.3: Subsystem Decomposition
4.7. Deployment Diagram
Deployment diagrams model the physical architecture of a system, and it shows the relationships
between the software and hardware components in the system and the physical distribution of the
processing.

8. Figure 4.4: Deployment Diagram
4.8. System Architecture
4.8.1. Overall system architecture.
The adoption of a three-tier architecture for our Student Department Placement System stems from
a strategic consideration of its inherent advantages in terms of modularity, scalability,
maintainability, and enhanced system performance. In a three-tier model, the separation of
presentation, application/business logic, and data layers allows for a modular and organized
development approach. The presentation layer is dedicated to user interface interactions, ensuring

9. a user-friendly experience for students and administrators. Meanwhile, the application/business
logic layer concentrates on processing essential tasks related to placement, promoting consistency
and efficient decision-making. The data layer manages information storage and retrieval,
contributing to data integrity and security.
One of the primary reasons for choosing three-tier architecture lies in its simplicity, which
facilitates easier maintenance and updates. Unlike more complex architectures with additional
layers, the three-tier model strikes a balance between granularity and practicality, ensuring that the
system remains agile and responsive to changing requirements. Additionally, the modular design
of three-tier architecture enhances scalability, enabling us to scale each layer independently based
on specific needs. This adaptability is crucial as our department's placement requirements may
evolve over time, and the system needs to accommodate these changes seamlessly.
The three-tier architecture supports optimized system performance. With clear boundaries between
layers, the distribution of tasks allows for more efficient processing and faster response times. The
separation of concerns in a three-tier model also facilitates better security implementations, as
security measures can be targeted and applied at each layer, minimizing potential vulnerabilities.
Overall, the adoption of a three-tier architecture aligns with our objectives of building a robust,
scalable, and secure Student Department Placement System that can evolve with the dynamic
nature of academic and placement processes.

10. Figure 4.5: Proposed system architecture