#Shuaib OODJ Assignment

Asia Pacific University of Technology and Innovation
Module Name and Code: Object Oriented Development with Java (CT038-3.5-2)
Intake Code: UC2F1303IT {NC}
Hand Out Date: September 27th, 2013
Hand in Date: December 9th, 2013
Words Count: 4578 words
Lecturers Name: IMRAN MEDI
CT038-3.5-2
Individual Assignment
1. Table of contents
1.
Table of contents ................................................................................................................................... ii
2.
Table of figures..................................................................................................................................... iv
3.
Table of Tables ...................................................................................................................................... v
4.
Acknowledgment ................................................................................................................................... 6
5.
Abstract .................................................................................................................................................. 6
6.
Introduction ........................................................................................................................................... 6
7.
Description, Justification and Design of the System .......................................................................... 7

7.1.
A.
Use Case Diagram ........................................................................................................................ 8
B.
Use Case Descriptions .................................................................................................................. 9
C.
Activity Diagram (AD) ............................................................................................................... 19
D.
Class Diagram............................................................................................................................. 31
7.2.
8.
System Design .................................................................................................................................. 8
OODJ Features and Concepts Incorporated Into the Solution ....................................................... 32
A.
Classes and Objects .................................................................................................................... 32
B.
Inheritance .................................................................................................................................. 33
C.
Overriding ................................................................................................................................... 33
D.
Packages ..................................................................................................................................... 34
Research Findings Report on Software Design Patterns ............................................................... 35

8.1.
Software Design Pattern ................................................................................................................. 36
8.2.
Usage of Design Pattern ................................................................................................................. 36
8.3.
Why Programmers Care About Design Patterns? .......................................................................... 37
8.4.
When To Use Design Patterns? ...................................................................................................... 37
8.5.
Design Patterns Classification ........................................................................................................ 37
8.6.
Some Types of Design Patterns ..................................................................................................... 37
A.
Singleton Pattern......................................................................................................................... 37
ii
Asia Pacific University
CT038-3.5-2
B.
Factory Method Pattern .............................................................................................................. 38
C.
Facade Pattern............................................................................................................................. 38
D.
Composite Pattern....................................................................................................................... 38
E.
Observer Pattern ......................................................................................................................... 38
8.7.
Software Design Patterns Advantages ........................................................................................... 39
8.8.
Software Design Patterns Disadvantages ....................................................................................... 39
8.9.
Which Design Pattern Suit the EIIMS Study Case and Why? ....................................................... 40
9.
10.
Conclusion ........................................................................................................................................... 44
Reference List ................................................................................................................................... 45
iii
CT038-3.5-2
2. Table of figures
Figure 1: EIIMS Use Case Diagram ............................................................................................................... 8
Figure 2: AD - Add New Customer .............................................................................................................. 19
Figure 3: AD - Add new Job ......................................................................................................................... 20
Figure 4: AD - Add New User ...................................................................................................................... 21
Figure 5: AD - Generate Invoice .................................................................................................................. 22
Figure 6: AD - Job Search ............................................................................................................................ 23
Figure 7: AD - Search For Customer ............................................................................................................ 24
Figure 8: AD - Search For User .................................................................................................................... 25
Figure 9: AD - Update Duties ....................................................................................................................... 26
Figure 10: AD - User Login .......................................................................................................................... 27
Figure 11: AD - View Duties ........................................................................................................................ 28
Figure 12: AD - View Engineers Duties ....................................................................................................... 29
Figure 13: AD - View Statistics .................................................................................................................... 30
Figure 14: EIIMS Class Diagram ................................................................................................................. 31
Figure 15: Users Class .................................................................................................................................. 32
Figure 16: Facade Design Patter Solution Example ..................................................................................... 40
iv
CT038-3.5-2
3. Table of Tables
Table 1: Add New User Use Case Description ............................................................................................... 9
Table 2: Search For User Use Case Description ............................................................................................. 9
Table 3: View Duties Use Case Description................................................................................................. 10
Table 4: Update Duties Use Case Description .............................................................................................. 10
Table 5: Generate Reports Use Case Description ......................................................................................... 10
Table 6: View Engineer Duties Use Case Description ................................................................................. 12
Table 7: View Statistics Use Case Description............................................................................................. 12
Table 8: Generate Reports Use Case Description ......................................................................................... 12
Table 9: Adding New Customer Use Case Description................................................................................ 14
Table 10: Customer Search Use Case Description ....................................................................................... 14
Table 11: New Job Use Case Description..................................................................................................... 15
Table 12: Job Search Use Case Description ................................................................................................. 15
Table 13: View Job Records Use Case Description ..................................................................................... 15
Table 14: View Customer Records Use Case Description ........................................................................... 17
Table 15: Generate Report Use Case Description ........................................................................................ 17
Table 16: Email Report Use Case Description ............................................................................................. 17
v
CT038-3.5-2
4. Acknowledgment
I would like to express my special thanks and gratitude to my Lab lecturer Mr. Imran Medi, which with his
sincere guidance and help throughout the labs I had the chance to do and finish the Object Oriented
Development with Java assignment.
5. Abstract
This assignment is for Object Oriented Development with Java, requested by Mr. Imran Medi. The
assignment aims to develop an Object Oriented system using Java for INSPECT-RICALS, an Electrical
Contractions Company.
6. Introduction
Inspect-Ricals is an Electrical Constructions Company, which provides electrical wiring and installation
services for condominium developers and owners. The company requires a system that helps them
facilitate and manage the inspection process, as well as produce the necessary reports for the benefit of
management and clients. The system will be used by four types of users which are Administrators,
Engineers, Clerks and Managers.
Clerks are responsible for customers and customers order as well as allocating Engineers to specific jobs.
While Engineers are responsible for carrying out the allocated jobs. Manager will have managerial access
to the system to issue and print reports. Admin will have full administrative access to the system including
users management.
Page 6 of 46
CT038-3.5-2
7.Description, Justification and Design of the

System
Page 7 of 46
CT038-3.5-2
7.1. System Design

A. Use Case Diagram
Figure 1: EIIMS Use Case Diagram
Page 8 of 46
CT038-3.5-2
B. Use Case Descriptions
Admin Use Cases Descriptions

Table 1: Add New User Use Case Description
Use Case
Add New User
Summary
An Admin user creates and add new users to the

system
Actor
Admin
Pre-condition
Admin must Login
Post-condition
New user is created
Exception
Sequence
Sub Use Case
If user is already existed, the system rejects the

new user.
Login
Table 2: Search For User Use Case Description
Use Case
Search For User
Summary
An Admin user can search in the database for a user
Actor
Admin
Pre-condition
Admin must Login
Post-condition
Admin can edit the user information

Admin can delete a user
Exception
Sequence
Sub Use Case
If user not found, the system shows User Not

Found Message.
Login
Page 9 of 46
CT038-3.5-2
Engineer Use Cases Descriptions

Table 3: View Duties Use Case Description
Use Case
View Duties
Summary
Engineers can view their duties
Actor
Engineer
Pre-condition
Valid Engineer username and password

Clerk assigned new duties to the engineers
Post-condition
Exception
Sequence
Sub Use Case
Print a list of the duties

If no duties assigned to the Engineer, The
system shows No Duties Available message.
Login
Table 4: Update Duties Use Case Description
Use Case
Update Duties
Summary
Engineers can update their duties, to note what have

been done.
Actor
Engineer
Pre-condition
Assigned finished duties
Post-condition
Print a report for the customer
Exception
Sequence
Sub Use Case
---Login
Table 5: Generate Reports Use Case Description
Use Case
Generate Reports
Summary
Generate Reports for engineer duties and the done

duties
Actor
Pre-condition
Engineer
Assigned duties
Assigned finished duties
Post-condition
Exception
--- If no duties assigned, The system shows No

Page 10 of 46
CT038-3.5-2
Sequence
Sub Use Case
Duties Available message.

Login
Page 11 of 46
CT038-3.5-2
Manager Use Cases Descriptions

Table 6: View Engineer Duties Use Case Description
Use Case
View Engineers duties
Summary
Viewing the Engineers assigned duties and the done

duties
Actor
Manager
Pre-condition
Login
Post-condition
Generating reports for engineer duties load
Exception
Sequence
----
Sub Use Case
Login
Table 7: View Statistics Use Case Description
Use Case
View Statistics
Summary
View duties statistics and Generate Report
Actor
Manager
Pre-condition
Done duties by engineers
Post-condition
Generate report
Exception
Sequence
Sub Use Case
If no done duties, System show No done duties

message
Login
Table 8: Generate Reports Use Case Description
Use Case
Generate Reports
Summary
Generate Managerial reports for engineer duties

load
Actor
Pre-condition
Manager
Assigned duties to Engineers
Assigned finished duties by Engineers
Post-condition
Exception
Sequence
--- If no duties assigned, The system shows No

Duties Available message.
Page 12 of 46
CT038-3.5-2
Sub Use Case
Login
Page 13 of 46
CT038-3.5-2
Clerk Use Cases Descriptions

Table 9: Adding New Customer Use Case Description
Use Case
Add new Customer
Summary
Adding new customer to the database
Actor
Clerk
Pre-condition
Customer must not exist already

Unique Customer ID must be generated by the
system
Post-condition
Exception
Sequence
Sub Use Case
New Customer in the database

If customer already exist, system will show
error message
Login
Table 10: Customer Search Use Case Description
Use Case
Customer Search
Summary
Search for Customer in the Database
Actor
Clerk
Pre-condition
Clerk must Login

Customer must exist
Post-condition
Edit customer Information

Delete Customer
Exception
Sequence
Sub Use Case
If no customer found, The system shows

customer not found message.
Login
Page 14 of 46
CT038-3.5-2
Table 11: New Job Use Case Description
Use Case
New Job
Summary
Add new job to the system for customer order
Actor
Clerk
Pre-condition
Customer order call

Assign job to Engineer
Post-condition
New Job added to the database and assigned to

an Engineer
Exception
Sequence
Sub Use Case
If order existed, system shows error message

Login
Table 12: Job Search Use Case Description
Use Case
Job Search
Summary
Search in the Database for an existing job
Actor
Clerk
Pre-condition
Job must exist in the database

Know the Job ID
Post-condition
Exception
Sequence
Sub Use Case
--- If no job is found, System will show job not

found message.
Login
Table 13: View Job Records Use Case Description
Use Case
View Job Records
Summary
Viewing the entire Job records
Actor
Clerk
Pre-condition
Clerk must login
Post-condition
List of all done and new jobs
Exception
Sequence
----
Sub Use Case
Login
Page 15 of 46
CT038-3.5-2
Page 16 of 46
CT038-3.5-2
Table 14: View Customer Records Use Case Description
Use Case
View Customer Records
Summary
Viewing the entire Customers data
Actor
Clerk
Pre-condition
Clerk must login
Post-condition
List of all Customer details data
Exception
Sequence
----
Sub Use Case
Login
Table 15: Generate Report Use Case Description
Use Case
Generate Reports
Summary
Generates PDF Invoice Reports
Actor
Clerk
Pre-condition
Clerk must login

Amount must be entered
File Location must be chosen
Post-condition
Exception
Sequence
Sub Use Case
Generates PDF Report

If no amount is entered or file location is not
chosen the system will show error message
Login
Table 16: Email Report Use Case Description
Use Case
Email Report
Summary
Sends Emails with or without Generated PDF

report to customers
Actor
Clerk
Pre-condition
Clerk must login
Post-condition
Sent Email
Exception
Sequence
If customer email is missing the system will

show error message
Page 17 of 46
CT038-3.5-2
Sub Use Case
Login
Page 18 of 46
CT038-3.5-2
C. Activity Diagram (AD)
Add New Customer
Figure 2: AD - Add New Customer
Page 19 of 46
CT038-3.5-2
Add New Job
Figure 3: AD - Add new Job
Page 20 of 46
CT038-3.5-2
Add New User
Figure 4: AD - Add New User
Page 21 of 46
CT038-3.5-2
Generate Invoice
Figure 5: AD - Generate Invoice
Page 22 of 46
CT038-3.5-2
Job Search
Figure 6: AD - Job Search
Page 23 of 46
CT038-3.5-2
Search For Customer
Figure 7: AD - Search For Customer
Page 24 of 46
CT038-3.5-2
Search For User
Figure 8: AD - Search For User
Page 25 of 46
CT038-3.5-2
Update Duties
Figure 9: AD - Update Duties
Page 26 of 46
CT038-3.5-2
User Login
Figure 10: AD - User Login
Page 27 of 46
CT038-3.5-2
View Duties
Figure 11: AD - View Duties
Page 28 of 46
CT038-3.5-2
View Engineers Duties
Figure 12: AD - View Engineers Duties
Page 29 of 46
CT038-3.5-2
View Statistics
Figure 13: AD - View Statistics
Page 30 of 46
CT038-3.5-2
D. Class Diagram
Figure 14: EIIMS Class Diagram
Page 31 of 46
CT038-3.5-2
7.2. OODJ Features and Concepts Incorporated Into the Solution

Object-Oriented Programming (OOP) refers to programming using objects rather than using actions and
using data rather than using logic (Wang, 2002). Data in OOP grouped as self-sustained objects, thus
allows programmers to re-use into any four main OOP concepts (Nirosh, 2013).
A. Classes and Objects
Classes are the blueprints that describe objects in details; they are a simple representation of objects.
Classes define the state and the behavior of real-world objects by composing three things, a class name,
attributes and behaviors or operations (Nirosh, 2013).
In my Solution I used Classes which are User, AdminUser, ClerkUser, EngUser and ManagementUser.
Each class represents a type of user that exists within the system and each class combine data and methods
related to the class user.
Figure 15: Users Class
Objects are a representation of a real-world things that have state such as name, color, etc. and behavior
such as eating, walking, etc. Java OOP objects stores the state in fields or and exposes the behavior
through methods or functions (Oracle, n.d.).
In my solution, objects of classes where created to represent different users instance.
public class C_AddNewJob_Form extends javax.swing.JFrame {
ClerkUser CU = new ClerkUser();
public class E_Eng_Form extends javax.swing.JFrame {

EngUser ENU = new EngUser();
Page 32 of 46
CT038-3.5-2
B. Inheritance
Inheritance in OOP refers to the process where a class of objects acquires properties from another class. In
Java inheritance can be done through the use of one of the two keywords extends or implements (Wang,
2002). The Main class in the inheritance is called the super class or the parent class, and the second class is
the child class or the subclass.
In my solution code inheritance where used between the parent class User class and the other child classes
which are AdminUser Class, ClerkUser Class, EngUser Class and ManagementUser Class.
public class ManagementUser extends Users{
...
...
}
public class A_AddUser_Form extends javax.swing.JFrame {
...
...
}
C. Overriding
Overriding or method overriding is an instance method in the subclass with the same signature (name,
number and the type of its parameters) and return type as of the super class (Deitel & Deitel, 2002).
Although the super class has the method, it was overridden in the subclass.
In my solution code, overriding was used to override the Login method in the parent class User with the
Login method in the other child classes.
Super Class Method (Parent Class)
public class Users {

...
public int Login(String Uname, String Pword, String Fname) throws
FileNotFoundException{
...
}
}
Page 33 of 46
CT038-3.5-2
Subclass Method (Child Class)
public class AdminUser extends Users{

public static String AdminUsername;
@Override
public int Login(String Uname, String Pword, String Fname) throws
FileNotFoundException{
...
...
}
}
D. Packages
In Java, packages are used to group related types (classes, interfaces and annotations) which provide access
protection and name space management thus leads to preventing naming conflict, control access and make
searching and using classes, interfaces and annotations much easier (Tutorials Point, n.d.).
In my solution code, Packages were used to collect Classes in Classes package, and all GUI interfaces in
the gui package.
package classes;
package gui;
Page 34 of 46
CT038-3.5-2
8.Research Findings Report on

Software Design Patterns
Page 35 of 46
CT038-3.5-2
8.1. Software Design Pattern

In Software Engineering, the term Design Patterns refers to a reusable solution for a given problem that
occurs constantly and commonly in software design. It is not a finished or final designed code solution
which could be translated into source code or machine code. It is just a template or a blueprint of how to
solve a given problem in many different situations (Gamma et al., 1994).
Software Design Patterns are used by experienced Object-oriented software designers and it represents the
best practiced. Software Design Patterns are solutions for general problems that faced software designers
during software development.
Every design pattern has four essential elements which are Pattern Name, Problem, Solution and
Consequence. Pattern Name is a handle used for describing the design problem, its solutions and its
consequences. Pattern Name makes design at higher level of abstraction possible and enhances
communications (Gamma et al., 1994).
The Problem element of the design pattern describes when to apply the pattern and explains the problem
with its context. It might describe a specific design problem or object structure. The problem might have a
list of preconditions which must be met before it makes sense to apply the pattern (Gamma et al., 1994).
The Solution element of the design pattern describes all the elements which make up the design,
relationships, responsibilities and collaborations. The solution does not describe any specific
implementation for the problem, it is just an abstract description for the design problems and how the
pattern will solves it (Gamma et al., 1994).
The consequences element of the design pattern is the results of applying and implementing the pattern in
the problem. Consequences are critical to evaluate the design alternatives, understand the costs and
understand the benefits of applying the pattern. The consequences include the impacts on the systems
flexibility, extensibility and portability (Gamma et al., 1994).
8.2. Usage of Design Pattern

In software development, design patterns have two essential usages for the developers which are:
Best Practice: Design Patterns evolved over the past 40 years which led to provide the developers
with the best solutions for any specific problems. (Tutorials Point, n.d.)
Standard Platform for the Developers: Design Patterns provide standard and unified common
template which are specific to a particular scenario (Tutorials Point, n.d.).
Page 36 of 46
CT038-3.5-2
8.3. Why Programmers Care About Design Patterns?

During the past few years design patterns became widely used and accepted between Software engineers
and developers. The reason behind that is that designing and developing applications which conforms to
any pattern facilitates the reusability of the source code as well as provides better methods for addressing
problems.
8.4. When To Use Design Patterns?

Design Patterns are solutions to constant software problems, thus the use of design patterns depends on
how often the problem occurs, the steps needed for the solution as not all problems requires all the steps, as
well as whether the software developer is more interested in the existence of the solution or the solution
complete derivation
8.5. Design Patterns Classification

Software Design Patterns are classified into three categories, the Creational Patterns, the Structural
Patterns and the Behavioral Patterns. The Creational Patterns are any design patterns that provide a way to
create objects and hides the creation logic instead of instantiate objects by directly using new operators.
This makes the program more flexible in deciding which of the objects need to be created for the intended
use case. Some of the Creational Patterns which are known to the developers are Singleton Pattern and
Factory Method Pattern (Tutorials Point, n.d.).
The Structural Patterns are any patterns that concern the classes and objects compositions. The Structural
Patterns uses the concepts of inheritance to create interfaces and define how to compose objects to get new
functionalities. Some of the Structural Patterns which are known to the developers are Composite Pattern
and Facade Pattern (Tutorials Point, n.d.).
The Behavioral Patterns are any patterns which specifically concerns with the communication that is
between the objects. Some of the Behavioral Patterns which are known to the developers are Visitor
Pattern and Iterator Pattern (Tutorials Point, n.d.).
8.6. Some Types of Design Patterns

A. Singleton Pattern
Singleton Pattern is one of the creational category patterns and it is designed to restrict all the classes to
have only one instance or object of the class at a time that is accessible in many different parts and
throughout the system (Tutorials Point, n.d.).
Page 37 of 46
CT038-3.5-2
Singleton Pattern is one of the simplest design patterns, and it involves only one class that is responsible of
instantiating itself for two reasons. The first reason is to ensure that only one instance or object of the class
is created which is essential when only one object is needed to coordinate actions throughout the system,
while the second reason is providing a global point of access to the instance or the object (OODesign,
n.d.).
B. Factory Method Pattern
Factory Method Pattern or known as Virtual Constructor is another pattern of the creational category
patterns and it is designed to replace the class constructors and abstracting the process of object generating
thus leading to determine the type of instantiated object at run-time (Code Project, n.d.).
In another words, Factory Method Pattern defines an interface to create an object, and leaves the object
type to the subclasses, thus in run-time the creation defers to the type of object according to the subclasses
needs (OODesign, n.d.).
C. Facade Pattern
In general Facade or Faade means an exterior side of a building; the word comes from the French
language in which it means frontage or face. In Design Patterns, Facade or Faade Design Pattern is a
software design pattern under the Structural Patterns category and it is mainly designed to hide the
complexity of a system by adding and providing an interface to the client in which the client access the
system through the interface (Tutorials Point, n.d.).
Faade design pattern is usually used by software developers when an easier, unified and a simpler
interface are required in order to hide the system complexity from the users and make it easier to be used.
D. Composite Pattern
Composite Pattern in Software Design Patterns is another pattern under the Structural Patterns category.
The Composite Pattern used when a need to handle a group of objects as the same way as we handle a
single object. It composes objects into tree structure to represents both the part and the whole hierarchy
(Tutorials Point, n.d.).
E. Observer Pattern
Observer Pattern in Software Design Patterns is one of the behavioral category patterns and it is used
whenever there is one to many relationships between objects in order to notify the dependent objects
automatically whenever any object is modified (Tutorials Point, n.d.).
Page 38 of 46
CT038-3.5-2
8.7. Software Design Patterns Advantages

Design Patterns offers a lot of advantages for both the software developers as well as for the regular users.
Some of these advantages are:
Software Reusability: Patterns promotes software reusability as the pattern is designed and
created once but used and reused many times. Thus reducing production costs and saves a lot of
time by eliminating redesign (International Business Machines Corp. (IBM), 2004).
Limitless: Patterns can be shared within a project, within a company or across many companies.
There are no limitations on patterns except on how the pattern was designed and the intention of the
pattern creator (International Business Machines Corp. (IBM), 2004).
Expert Knowledge: Patters captures the expert knowledge and design logic and makes it widely
available through different patterns (Gamma et al., 1994).
Ease Object-Oriented Transition: Design Patterns helps developer to ease the transition from
structural programming concept to Object-oriented programming concept (Gamma et al., 1994).
8.8. Software Design Patterns Disadvantages

Nonetheless, Design Patterns shows few drawbacks and disadvantages on both the software developers as
well as for the regular users. Some of these drawbacks are:
Complexity: Implementing Design Pattern solution within a system is known to be difficult and
add complexity to the system code thus requires the knowledge of an expert software developer
(Gamma et al., 1994).
Memory Consumption: Design Patterns offer generalized format design as a solution, thus
consumes a lot of memory during the runtime (Gamma et al., 1994).
No Pattern Testing Methodology: All Software Design Patterns have no automated testing
methodology but can only be validated and discussed by experienced experts (Gamma et al., 1994).
Increase Source Code Size: implementing a design pattern adds indirect amount of code which
can lead to an increased Source Code Size (Gamma et al., 1994).
Page 39 of 46
CT038-3.5-2
8.9. Which Design Pattern Suit the EIIMS Study Case and Why?
In my opinion, choosing a design pattern that could fit into the Electrical Constructions Company InspectRicals software system solution is a bit tricky. Nonetheless if I were a Software Engineer I would choose
one design pattern and implement it fully within the Inspect-Ricals software system solution.
The obvious pattern I would choose is the Facade or Faade Design Pattern. From the Faade Design
Pattern description that was written above, what Facade Design Pattern used for is hiding the complexity
of a system by adding and providing an interface to the client in which the client access the system through
the interface (Tutorials Point, n.d.). Assuming that the Electrical Constructions Company staffs are nontechnical, an easier, unified and a simpler interface is required in order to operate the software system.
Thus implementing the Facade design pattern will provide that easy, unified and simple interface.
The Faade Design Pattern could be used to create an interface called Users, and then create concrete
classes implementing the Users interface. These classes are AdminUser, ClerkUser, EngUser and
ManagementUser. After that create a faade class to have the users login, below is a class diagram and
sample code illustrating the point:
Figure 16: Facade Design Patter Solution Example
Page 40 of 46
CT038-3.5-2
Step 1: Create the Users interface
public interface Users {

public int Login();
}
Step 2: Create the concrete classes implementing the Users interface.
public class AdminUser implements Users{

@Override
public int Login() {
System.out.println("Admin User");
return 0;
}
}
public class ClerkUser implements Users {
@Override
System.out.println("Clerk User");
return 0;
}
}
public class EngUser implements Users {
@Override
System.out.println("Engineer User");
return 0;
}
}
public class ManagerUser implements Users{
@Override
System.out.println("Manager User");
return 0;
}
}
Page 41 of 46
CT038-3.5-2
Step 3: Create the facade class UserLogin.
public class UserLogin {

private Users Admin_User;
private Users Eng_User;
private Users Clerk_User;
private Users Manager_User;
public UserLogin(){
Admin_User = new AdminUser();
Eng_User = new EngUser();
Clerk_User = new ClerkUser();
Manager_User = new ManagerUser();
}
public int AdminUser_Login(){
Admin_User.Login();
return 0;
}
public int ManagerUser_Login(){
Manager_User.Login();
return 0;
}
public int ClerkUser_Login(){
Clerk_User.Login();
return 0;
}
public int EngUser_Login(){
Eng_User.Login();
return 0;
}
}
Page 42 of 46
CT038-3.5-2
Step 4: Use the UserLogin facade class to allow various user login.
public class FacadePatternDemo {

public static void main(String[] args) {
UserLogin User_System_Login = new UserLogin();
String args1 = null;
Scanner scan = new Scanner(System.in);
System.out.println("Write User Type:\n");
args1 = scan.next();
if(args1.equals("Administrator")){
User_System_Login.AdminUser_Login();
}else if(args1.equals("Engineer")){
User_System_Login.EngUser_Login();
}else if(args1.equals("Clerk")){
User_System_Login.ClerkUser_Login();
}else if(args1.equals("Management")){
User_System_Login.ManagerUser_Login();
}
}
}
Results
Page 43 of 46
CT038-3.5-2
9. Conclusion
In conclusion, the assignment consists of documentation and an application system. The documentation
consists of two parts; the first part is the Description, Justification and Design of the System, which
contains a detailed description of EIIMS system logical designs that includes Use Case Diagram and
descriptions, Activity Diagram and Class Diagram. The second part consist of an Advance research on
Software Design Pattern and its usage, the advantages and disadvantages of Software Design Pattern,
categories and types of Software Design Pattern and which design pattern will suit the EIIMS case if
implemented.
The application system that was created is a GUI system, built according to the EIIMS case study. The
system comprises from 4 types of users with different access level, these users are Admin, Management,
Clerk and Engineer. The Admin can add and manage users, Management user can view reports and
statistics, Engineer user can view and update their duties as well as generate reports, while the Clerk user
can add and manage new customers, place new order and assign an engineer to the order, edit and delete
orders as well as other authorities such as generate invoice for the customers.
During the coding of the system I faced some problems on how to deal with classes and objects created in
the system, how to pass data and information from one form to another as well as from one method to
another. Faced issues on how to deal with text files, how to read, edit, delete, update and save from and to
text files. Nonetheless, Generating PDF report was the most problematic for me as it is my first time
dealing with PDF reports within the application coding.
However, I learnt some new ways on how to handle files, how to generate PDF reports and most
importantly how to utilize Object-Oriented Programing concepts into creating an application system that is
much more dynamic and maintainable than the normal structural programing concepts. Gained new skills
while doing this assignment such as the ability to implement a singleton pattern in a project and use its
benefits to enhance the project.
Page 44 of 46
CT038-3.5-2
10.Reference List
Code Project, n.d. Factory Method Pattern. [Online] Available at:

http://www.codeproject.com/Articles/570183/Factory-Method-Pattern [Accessed 20th November 2013].
Deitel, P.J. & Deitel, H.M., 2002. Java How to Program. 4th ed. USA: Prentice Hall.
Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1994. Design Patterns: Elements of Reusable ObjectOriented Software. 1st ed. UK: Addison-Wesley.
International Business Machines Corp. (IBM), 2004. Benefits of using patterns. [Online] Available at:
http://publib.boulder.ibm.com/infocenter/rsdvhelp/v6r0m1/index.jsp?topic=%2Fcom.ibm.xtools.pttrn.auth
or.doc%2Ftopics%2Fc_benefits_ptrns.html [Accessed 17th November 2013].
Nirosh, L.W., 2013. Introduction to Object Oriented Programming Concepts (OOP) and More. [Online]
Available at: http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-ProgrammingConcep [Accessed 27th November 2013].
OODesign, n.d. Factory Method Pattern. [Online] Available at: http://www.oodesign.com/factory-methodpattern.html [Accessed 20th November 2013].
OODesign, n.d. Singleton Pattern. [Online] Available at: http://www.oodesign.com/singleton-pattern.html
[Accessed 19th November 2013].
Oracle, n.d. What Is an Object? [Online] Available at:
http://docs.oracle.com/javase/tutorial/java/concepts/object.html [Accessed 27th November 2013].
Tutorials Point, n.d. Composite Pattern. [Online] Available at:
http://www.tutorialspoint.com/design_pattern/composite_pattern.htm [Accessed 25th November 2013].
Tutorials Point, n.d. Design Pattern Overview. [Online] Available at:
http://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm [Accessed 17th November
2013].
Tutorials Point, n.d. Facade Pattern. [Online] Available at:
http://www.tutorialspoint.com/design_pattern/facade_pattern.htm [Accessed 19th November 2013].
Page 45 of 46
CT038-3.5-2
Tutorials Point, n.d. Java - Packages. [Online] Available at:

http://www.tutorialspoint.com/java/java_packages.htm [Accessed 22nd November 2013].
Tutorials Point, n.d. Observer Pattern. [Online] Available at:
http://www.tutorialspoint.com/design_pattern/observer_pattern.htm [Accessed 26th November 2013].
Wang, P.S., 2002. Java with Object-Oriented Programming With Infotrac. 2nd ed. Pacific Grove: Course
Technology PTR.
Page 46 of 46

#Shuaib OODJ Assignment

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

#Shuaib OODJ Assignment

Caricato da

Copyright:

Formati disponibili

Asia Pacific University of Technology and Innovation

Table of contents ................................................................................................................................... ii

Table of Tables ...................................................................................................................................... v

Description, Justification and Design of the System .......................................................................... 7

Use Case Diagram ........................................................................................................................ 8

Use Case Descriptions .................................................................................................................. 9

Activity Diagram (AD) ............................................................................................................... 19

System Design .................................................................................................................................. 8

OODJ Features and Concepts Incorporated Into the Solution ....................................................... 32

Classes and Objects .................................................................................................................... 32

Research Findings Report on Software Design Patterns ............................................................... 35

Software Design Pattern ................................................................................................................. 36

Usage of Design Pattern ................................................................................................................. 36

Why Programmers Care About Design Patterns? .......................................................................... 37

When To Use Design Patterns? ...................................................................................................... 37

Design Patterns Classification ........................................................................................................ 37

Some Types of Design Patterns ..................................................................................................... 37

Asia Pacific University

Factory Method Pattern .............................................................................................................. 38

Observer Pattern ......................................................................................................................... 38

Software Design Patterns Advantages ........................................................................................... 39

Software Design Patterns Disadvantages ....................................................................................... 39

7.Description, Justification and Design of the

7.1. System Design

Figure 1: EIIMS Use Case Diagram

B. Use Case Descriptions

Admin Use Cases Descriptions

Add New User

An Admin user creates and add new users to the

Admin must Login

New user is created

If user is already existed, the system rejects the

Table 2: Search For User Use Case Description

Search For User

An Admin user can search in the database for a user

Admin must Login

Admin can edit the user information

If user not found, the system shows User Not

Engineer Use Cases Descriptions

Engineers can view their duties

Valid Engineer username and password

Print a list of the duties

Table 4: Update Duties Use Case Description

Engineers can update their duties, to note what have

Assigned finished duties

Print a report for the customer

Table 5: Generate Reports Use Case Description

Generate Reports for engineer duties and the done

--- If no duties assigned, The system shows No

Asia Pacific University

Duties Available message.

Manager Use Cases Descriptions

View Engineers duties

Viewing the Engineers assigned duties and the done

Generating reports for engineer duties load

Sub Use Case

Table 7: View Statistics Use Case Description

View duties statistics and Generate Report

Done duties by engineers

If no done duties, System show No done duties

Table 8: Generate Reports Use Case Description

Generate Managerial reports for engineer duties

--- If no duties assigned, The system shows No