1.

1 Introduction of Object Oriented Design

1.2 Object Oriented Design for the new proposed system
1.3 Entity Relationship Diagram
1.4 Test Strategy

1.1 Introduction of Object Oriented Design

1
Object-Oriented Design (OOD) is an activity where we are looking for logical solutions
to solve a problem.

Object-oriented design takes the conceptual model that is the result of object-oriented
analysis, and adds implementation constraints imposed by the environment, the
programming language and the chosen tools, as well as architectural assumptions chosen
as basis of design.

The concepts in the conceptual model are mapped to concrete classes, to abstract
interfaces in APIs and to roles that the objects take in various situations. The interfaces
and their implementations for stable concepts can be made available as reusable services.
Concepts identified as unstable in object-oriented analysis will form basis for policy
classes that make decisions, implement environment-specific or situation specific logic or
algorithms.

The result of the object-oriented design is a detail description how the system can be
built, using objects.

The Unified Modeling Language (UML) has become the standard modeling language
used in object-oriented analysis and design.

1.1.1 Activates of Object Oriented Design

 Refining the use case model to reflect the implementation environment.

 Modeling object interactions and behavior to support the use case scenario.

 Updating the object model to reflect the implementation environment.

1.1.2 Characteristic of Object Oriented Design

2
 • OOD allows programmers to more closely model the real world than ever before.

• OOD is also a methodology which lends itself well to rapid prototyping. Object-
Oriented programs can be built and modified very quickly because OOD provides
the programmer with excellent tools for abstraction.

• OOD produces reusable code. Once objects are built, it is very easy to use them in
future applications so you need not ever reinvent the wheel.

• OOD helps programmers work in dynamic environments. Object-Oriented

programs can be modified quickly and easily as real-world requirements change.

The advantages of the OOD are that it is easier to maintain and objects may be
understood as stand-alone entities. They are appropriate reusable components. For some
system, there may be an obvious mapping from the real world entities to system objects.

An object is an entity which has a state and a defined set of operations which operate on
that state. The state is represented as a set of objects attributes. The operations associated
with the object provide services to other objects (clients) which request these services
when some computation is required. Objects are created according to some object class
definition. An object class definition serves as a template for objects. It includes
declarations of all the attributes and services which should be associated with an object of
that class.

1.2 Object Oriented Design for the new proposed system

3
1.2.1 Class Diagram
Class diagram is the mainstay of object-oriented analysis and design. It shows the classes
of the system, their interrelationships (including inheritance, aggregation, and
association), and the operations and attributes of the classes. Class diagram is used for a
wide variety of purposes, including both conceptual/domain modeling and detailed
design modeling.

1.2.2 Use Case Diagram

4
Use case describes a sequence of actions that provide something of measurable value to
an actor and is drawn as a horizontal ellipse. An actor is a person, organization, or
external system that plays a role in one or more interactions with the system and actors
are drawn as stick figures.
An association between actors and use cases are indicated by solid lines. It exists
whenever an actor is involved with an interaction described by a use case. Associations
are modeled as lines connecting use cases and actors to one another, with an optional
arrowhead on one end of the line. The arrowhead is often used to indicating the direction
of the initial invocation of the relationship or to indicate the primary actor within the use
case.

1.2.2.1 Staff Use Case Diagram:

Explanation of the Staff Use Case Diagram:

5
 1. Scenarios for the staff Log On use case
Main Scenario:
1. The use case starts when staff clicks the Log On button/link.
2. The system requests for the staff user ID and password.
3. Staff enters the staff user ID and password.
4. Staff clicks the “enter” link.
5. The system uses the password authenticator to verify the staff user ID and
password.
6. The system displays appropriate welcome message to the staff and ends the use
case.
Alternate Scenario:
3a. The staff did not enter the required fields.
4a. The system displays error message & request for the user ID and password again.
Alternate Scenario:
5b. The password authenticator could not find the staff user ID.
6b. The system displays error message and requests for the staff user ID and password
again.
Alternate Scenario:
5c. The password authenticator found the staff user ID in the employee table, but the
password entered by the staff does not match the password field in the table.
6c. The system displays error message and request for the staff user ID and password
again.

2. Scenarios for print use case

Main Scenario:
1. Include “Log In” use case.
2. The system responses by displaying print button after the information display in
the monitor.
3. Staff clicks on the print button to get hardcopy for Attendance.
4. The system prints the student information.
1.2.2.2 Student Use Case Diagram:

6
Explanation of the Student Use Case Diagram:
1. Scenarios for Student Scan use case
Main Scenario:

7
 1. Include “Log In” use case from the Staff.
2. The system responses by displaying scanning screen to the student.
3. Student scans the card.
4. Scanner scans the data.
5. Scanner captures the data.
6. The Data Reader read the student ID.
7. Conversion will check weather the student is in Module attendance process or
Exam process.
8. Validator will validate the student ID by passing it to the Database base on the
time of scanning.
9. The system will update the information base on the database.
Alternate Scenario:
3a. The Student didn’t scan the card in correct direction.
4a. The system displays error message & request for the student to scan again.
Alternate Scenario:
3b. The Student scans the card twice at the same time.
4b. The system displays error message and requests for the student to scan again.
Alternate Scenario:
3c. The Student scans the card at invalid time.
4c. The system displays error message and request the student to try again.

2. Scenarios for display use case

Main Scenario:
1. Include “Log In” use case from the Staff.
5. After the system update student information in the database.
6. The system responses by displaying student information in the screen retrieving
from database.
3. Scenarios for print use case
Main Scenario:
1. Include “Log In” use case from the Staff.
7. The system responses by displaying print button after the information display in
the monitor.

8
 8. Student click on the print button to get hardcopy of his information.
9. The system prints the student information.

1.2.3 Sequence Diagram

A Sequence diagram depicts the sequence of actions that occur in a system. The
invocation of methods in each object, and the order in which the invocation occurs is
captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to
easily represent the dynamic behavior of a system.

9
A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the
life of the object that it represents, while on the vertical axis, it shows the sequence of the
creation or invocation of these objects.

1.2.3.1 Staff Log On Sequence Diagram:

Explanation Staff Log On Sequence Diagram:

There are five participants involved. The first participant is actually an actor. Firstly the
actor who is Staff key in the staff ID and password in the Logon page. Then the system
will pass the message to the authenticator and authenticator will pass the message to
Staffs DAO for authenticating the staff ID exists or not. Next the Staffs DAO will find
the staff ID from the Staff database, and then it will create an entity class called Staffs if

10
the ID is exist. Next the authenticator will send the password to this entity class to check
whether the password is matching or not. Staffs will give a reply to the authenticator, and
the entity class will be destroyed after that. If the ID and the password is not match with
the ID and password in the database, the system will prompt an error message and ask for
the ID and password again. Finally authenticator will give a result to the Logon page
whether it is successfully been log on or not.

1.2.3.2 Staff Printing Student information Sequence Diagram:

11
Explanation Staff Printing Student information Sequence Diagram:

There are four participants involved. The first participant is actually an actor. Firstly the
actor who is Staff will check the student information whether it is valid or not. If the
student information is valid the staff will retrieve student information from the Database
and store it in a temper buffer. Then the staff will send to print request where the data in
the buffer will be printed. In case if the student information is not valid the staff will ask
the student to scan the card again. Finally the Printer will print the information
successfully.

1.2.3.3 Student scans Sequence Diagram:

12
Explanation Student scans Sequence Diagram:

There are six participants involved. The first participant is actually an actor. Firstly the
actor who is Student will scan his /here student card in the scanner machine by highlight
the barcode to the machine. Then Data Reader will read Student ID and pass it to the
validator and the validator will check and validated the student ID if it is valid or not by
matching it to the student Database. In both case the monitor will display the result. In
case of matching ID the system will retrieve student information and store it in temp
buffer. Then the Student will be prompt to click the print button so he/she can get a copy
of the information. In case if the Student ID is not valid the system will prompt an error
message and ask for student ID again.
1.3 Entity Relationship Diagram

13
Entity-relationship diagram (ER) is a specialized graphic that illustrates the
interrelationships between entities in a database. We develop our system using MW
access

1.4 Test Strategy

14
Test Strategy is a plan on how to approach testing process. It is like a project charter that
tells the world how going to approach the project.

The purpose of a test strategy is to clarify the major

tasks and challenges of the test
Project.

A good test strategy is:

 Specific
 Practical
 Justified

Different strategies may be applied at different stages of

the testing process. Strategies covered the following:

• Top-down testing
In top down testing an overview of the system is
formulated, without going into detail for any part of
it. Each part of the system is then refined by
designing it in more detail. Each new part may then be refined again, defining it in yet
more detail until the entire specification is detailed enough to validate the model. The
top-down model is often designed with the assistance of "dark boxes" that make it
easier to bring to fulfillment but insufficient and irrelevant in understanding the
elementary mechanisms.

• Bottom-up testing
In bottom-up testing, first the individual parts of the system are specified in great
detail. The parts are then linked together to form larger components, which are in turn
linked until a complete system is formed. This strategy often resembles a "seed"
model, whereby the beginnings are small, but eventually grow in complexity and
completeness.

• Thread testing
• Stress testing
• Back-to-back testing

Defect testing is the establishing of the presence of system defects. The objective of
defect testing is to discover defects in programs. A successful defect test is a test which
causes a program to behave in an anomalous way. The tests show the presence and not

15
the absence of defects. Only exhaustive testing can show a program is free from defects.
However, exhaustive testing is impossible. Tests should exercise a system’s capabilities
rather than its components. Testing old capabilities is more important than testing new
capabilities. Testing typical situation is more important than boundary value cases.

16