WOLKITE UNIVERSITY

COLLAGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF SOFTWARE ENGINEERING

Course title: Software Architecture and Design

Course code: Seng 5232
Project Name: Student Union Voting System

Name ID No
1. Bisrat Jenbere NSR/0385/12
2. Ebisa Girma NSR/0474/12
3. Elsabet Awraris NSR/0515/12
4. Isayas Malkamu NSR/0791/12

Mr. Seifu D.
Course Instructor
 SYSTEM OVERVIEW
The Student Union Voting System is the software system allows voters (students) to vote online
without having to go to an election site, while maintaining their privacy and security. It is critical
to select the president and other executive managers who will lead the various sectors of the
student union at the University.

The System has the following functions.

✓ Register: The system will allow to register candidate, chairperson and voters based on their
perspective web page.
✓ Login: The system allows administrator, candidate, chairperson and voters to login after
they are registered.
✓ Post announcement: The system generate reposts like candidate information, election date,
registration date, election result so as to aware for all members of the campus.
✓ Manage user: The administrator controls accounts of actors in the system such as creates,
delete, update and search the account to the chairperson, candidate and delete accounts of
voter from database after election.
✓ View result: The system will allow all user to view posted information after election is
completed.
✓ Approve chairperson: The system allows administrator to approve chairperson of the
campus.
✓ Evaluate: - chairperson of election committee can evaluate the candidate and fill the value
of candidate that he gets from test, certificate, strategic plan and defense from 40%.
✓ Logout: The system shall allow administrator, chairperson and voters can logout to the
system
✓ View notice: all user of the system is capable to see the notice that released on the system

SYSTEM ARCHITECTURE
The purpose of designing is to show the direction of how the system will build and to obtain
clear information needed to drive the actual implementations of the system. The architectural
pattern of our system is 3-tier architecture model. Those are presentation tier, application tier and
data tier. After the selection of architectural pattern, we perform the system decomposition into
different sub system. Those subsystems are Administrator, Voter, Chairperson and Candidate.
with each subsystem there are different components. After all we explain the rational for
selecting 3-tier architecture model for our system.

Architectural Design
The system is consisting of 3-tier architecture model. The presentation layer is client layer and
top most layer of the application. This is the layer we see when we use this system. it is the
interface to the system. it is the interface to the system which takes information from the user.
The main advantage of functionality of this is to communicate with the application layer. This
layer passes the information which given in terms of keyboard action and mouse click to the
application layer. Example when user want to login into the system first sees two text box and
login button to enter user name and password and click on login. Business logic layer: it is
application layer which interacts with data layer and sends information retrieved from database
toward to presentation layer. it acts as the mediator between presentation layer and data layer.
From above example once, the user clicks on login button application layer interacts with the
database and send information towards to presentation layer. The third one is data layer which
used to store data entered by the user. In general client of the system use browser to access the
system using the internet.in this case when the user enters input and takes certain action
application server process client request to interacting with the database server.

Figure 1: System architecture

4+1 view model
Logical view: The logical view is concerned with the functionality that the system provides to
end-users. We depict by using class diagram.

Figure 2: Class Diagram

Process view: The process view deals with the dynamic aspects of the system, explains the
system processes and how they communicate, and focuses on the run time behavior of the system.
The process view addresses concurrency, distribution, integrator, performance, and scalability,
etc. We depict by using sequence diagram.
Figure 3: sequence Diagram
Development view: The development view illustrates a system from a programmer’s perspective
and is concerned with software management. This view is also known as the implementation
view. We depict by using component diagram.
Figure 4: Component Diagram
Physical view: The physical view depicts the system from a system engineer’s point of view. It is
concerned with the topology of software components on the physical layer as well as the physical
connections between these components. This view is also known as the deployment view. We
depict by using deployment diagram.

Figure 5: Deployment Diagram

Scenarios: The description of an architecture is illustrated using a small set of use cases, or
scenarios, which become a fifth view. The scenarios describe sequences of interactions between
objects and between processes. They are used to identify architectural elements and to illustrate
and validate the architecture design. They also serve as a starting point for tests of an architecture
prototype. We depict by using use case diagram.

Figure 6: Use Case

Decomposition and Description
System decomposition is the process of dividing the system into manageable subsystems from
the analysis model of the system. The goal of the system decomposition is to reduce the
complexity of design model and to distribute the class of the system in to large scale and
cohesive components. Components are generally units of computation or data stores in the
system. A component has a name, which is generally chosen to represent the role of component
or the function it performs. The different components of a system are likely to interact while the
system is in operation to provide the service expected of the system.in our system the following
subcomponent is available.

Administrator subsystem፡ responsible for handling action that administrator performs.

• Login

• Manage User

• Approve chairperson

• Post announcement

Voter subsystem-- responsible for handling action that voter performs.

• Register

• Login

• Cast vote

• View result

Chairperson

• Register

• Login

• Approve candidate

• Evaluate
 • Post result

• Post announcement

Candidate

• Register

• View result

Figure 2: Subsystem Decomposition

Design Rational
Benefits of three-tier architecture:

Again, the chief benefit of three-tier architecture its logical and physical separation of
functionality. Each tier can run on a separate operating system and server platform - e.g., web
server, application server, database server - that best fits its functional requirements. And each
tier runs on at least one dedicated server hardware or virtual server, so the services of each tier
can be customized and optimized without impact the other tiers.

Faster development: Because each tier can be developed simultaneously by different teams, an
organization can bring the application to market faster, and programmers can use the latest and
best languages and tools for each tier.

Improved scalability: Any tier can be scaled independently of the others as needed.

Improved reliability: An outage in one tier is less likely to impact the availability or
performance of the other tiers.

Improved security: Because the presentation tier and data tier can't communicate directly, a
well-designed application tier can function as a sort of internal firewall, preventing SQL
injections and other malicious exploits.

DATA DESIGN
Data designing illustrates the types of data that are stored in the system, the relationships
between them and the ways that data can be grouped or organized.

Data Description

The data description activity translates these elements of the requirements model into data
structures at the software component level and, when necessary, a database architecture at the
application level. It describes for the system persistent data will be stored by the system and the
data management infrastructure required for it. This section typically includes the description for
data schemes, the selection of database, and description of the encapsulation of the database.
Figure 3: Data Design

Component Design

This section describes all components by the decomposition of subsystems into component and
the file organization of the code. This includes an overview of package and components in the
package, its dependencies with other, and its expected usage. Here, use UML diagram of
components in the package.
Figure 4: component diagram