Oop final project documentation jose pagan v2.1

MVP Development Corporation
Event Driven Process Manager
Software Architecture Document
Pre-Design Project Proposal and Work Plan
Project Requirements / Documentation
Design Documentation
Installation Instructions
Version 2.1

MVP Development Corporation Version: 2.1
Software Architecture Document Date: 28/January/2017
EDPMAD
Confidential MVP Development Corporation
2017
Page 2 of 24
Revision History
Date Version Description Author
September 28, 2009 1.0 Initial Design Version José Pagán
November 2, 2009 2.0 First Implementation
Additional classes were added, see revised
Class Diagram in Section 5.1.
Additional Documents were included in the
following Appendices:
I. Pre-Design Project Proposal and
Work Plan
II. Project Requirements / Documentation
III. Design Documentation
IV. Installation Instructions
Jose Pagán
January 28, 2017 2.1 Proofreading José Pagán

EDPMAD
2017
Page 3 of 24
Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Software Description 4
1.3 Tools for Analysis 4
1.4 Scope 4
1.5 Definitions, Acronyms, and Abbreviations 5
1.6 References 5
1.7 Overview 5
2. Architectural Representation 5
3. Architectural Goals and Constraints 7
4. Use-Case View 7
4.1 Use-Case Realizations 7
5. Logical View 9
5.1 Overview 9
6. Process View 12
7. Deployment View 13
8. Implementation View 13
8.1 Overview 13
8.2 Layers 13
9. Size and Performance 14
10. Quality 14
Appendix I – Pre-Design Project Proposal and Work Plan 15
Software Description 15
Tools for Analysis 15
Work Plan 16
Appendix II – Project Design and Documentation 17
Business Rules 17
List of Events 18
Appendix III – Design Documentation 20
Appendix IV – Installation Instructions 23

EDPMAD
2017
Page 4 of 24
Software Architecture Document
1. Introduction
1.1 Purpose
The purpose of this Software Architecture Document is to describe, through the use of diagrams and
descriptions, the architecture of the Event Driven Process Manager application. The document provides a
comprehensive architectural overview of the system, and conveys the significant architectural decisions
which have been made in the development of Event Driven Process Manager. A Pre-design Project
Proposal and Work Plan, Project Requirements / Documentation, Design Documentation, and Installation
Instructions have been included in the Appendices.
This document depicts different aspects of Event Driven Process Manager using a number of different
architectural views based on Philippe Kruchten’s “4+1” View Model of Software Architecture. Each one
of these views is intended for a different audience. For example, the logical view is used by software
architects for functional analysis, while the use case view provides users with a quick understanding of the
functionality of the software.
This document is intended to give architects, developers, software engineers, project managers,
programmers and power users a thorough understanding of the Event Driven Process Manager architecture
to assist in the analysis, reverse engineering and maintenance of the application.
1.2 Software Description
Event Driven Process Manager is a Console based (Win32) single user software application that allows the
user to manage various tasks performed by employees and other participants in an event driven process.
The application processes different types of events, creates an event log, validates that each event complies
with the rules and parameters provided in an Event Category List, and assigns an agent from an Agent List
to each event, if one is available. If the event does not comply with the rules or parameters specified in the
Event Category List, or there is no agent available to handle the event within the required constraints, the
application generates an exception report. The application also generates a Job Status Report once all the
events have been processed.
Event Driven Process Manager is a free open source application written in C Sharp. The program will
process events from an input file or through manual entry. Reports may be sent to the console or to a
printer. The initial release is limited to reading from a file and output to the console.
1.3 Tools for Analysis
MVP Development Corporation used Microsoft Visual Studio 2008, Microsoft SQL 2008 and Microsoft
Visio to create the application and generate diverse diagrams, including some UML diagrams.
1.4 Scope
This Software Architecture Document applies to the Event Driven Process Manager system, including all
its components and connections. The architecture, forms, functions, files, tools, packages and
configuration of the system are all affected by this document.

EDPMAD
2017
Page 5 of 24
1.5 Definitions, Acronyms, and Abbreviations
 Architecture - The way the components of a computer or computer system are organized and integrated.
 Architectural Style – idiomatic patterns of system organization, organizational principles and structures for
certain classes of software.
 Components - a reusable black/grey-box entity (a piece of code) with well-defined interface and specified
behavior which is intended to be combined with other components to form a software system (an
application).
 Connectors – abstractions that allow for a clear separation of the application’s business logic from the
communication middleware.
 UML – The Unified Modeling Language (UML) is an open standard method used to specify, visualize,
construct and document the artifacts of an object-oriented software-intensive system.
1.6 References
 Christine Hofmeister, Robert Nord and Dilip Soni, Applied Software Architecture, Addison-Wesley
Professional (November 14, 1999).
 M. Shaw, D. Garlan (1996). Software Architecture: Perspectives on an Emerging Discipline. Upper Saddle
River, NJ: Prentice Hall.
 Kruchten, P., Architectural Blueprints—The “4+1” View Model of Software Architecture, IEEE Software
12(6), November 1995
 First ECG Software Services, Applying 4+1 View Architecture with UML 2, 2007
 Dusan Balek, Connectors in Software Architectures, Charles University 2002
1.7 Overview
The rest of this Software Architecture Document contains a description of the architectural representations
used (Section 2), the architectural goals and constraints of the system (Section 3), the architectural views of
the system (Sections 4 to 9), size and performance issues (Section 10), and quality issues (Section 11). The
appendices contain a Pre-design Project Proposal and Work Plan, Project Requirements / Documentation,
Design Documentation, and Installation Instructions for the application.
2. Architectural Representation
The system's architecture will be described using Kruchten's 4+1 View Model shown in Figure 1 below.

EDPMAD
2017
Page 6 of 24
Figure 1 - 4+1 View Model
The model consists of 5 views used to represent different layers of the system's architecture. These views are:
i. Logical View (Object Oriented Decomposition) - This view focuses on realizing an application’s
functionality in terms of structural elements, key abstractions and mechanisms, separation of concerns
and distribution of responsibilities. Architects use this view for functional analysis.
ii. Process View (Process Decomposition) - This view considers non-functional aspects such as
performance, scalability and throughput, and addresses the issues of concurrency, distribution and fault
tolerance. It shows the main abstractions from the Logical View executing over a thread as an
operation
iii. Implementation or Development View (Subsystem Decomposition) - This is a view of a system’s
architecture that encompasses the components used to assemble and release a physical system. This
view focuses on configuration management and actual software module organization in the
development environment.
iv. Deployment or Physical View (Mapping Software to Hardware) - This view encompasses the nodes
that form the system’s hardware topology on which the system executes; it focuses on distribution,
communication and provisioning. This view accommodates the non-functional requirements such as
availability, reliability, performance, throughput and scalability, and provides all possible hardware
configurations, and maps the components from the Implementation View to these configurations.
v. Use Case View or Scenarios (putting all together) - In addition to the four views discussed above, this
is the central view for capturing scenarios. The Use Case View encompasses the use cases that
describe the behavior of the system as seen by its end users and other stakeholders. Although
traditionally discussed as the last view, this is the first view created in the system development
lifecycle.

EDPMAD
2017
Page 7 of 24
3. Architectural Goals and Constraints
The objectives of Event Driven Process Manager that have a significant impact on the architecture include:
 Safety, Security and Privacy – the application provides for login and password verification.
Future enhancements may include encryption.
 Off-the-shelf product – Event Driven Process Manager is a standalone, self-contained application.
Future enhancements will include an installer and an internet connection to search for and install
updates.
 Portability, Distribution and Reuse – Event Driven Process Manager is an open source application.
The source code may be easily ported to other platforms or reused in a new application.
 Special Constraints – the software must be user friendly and easy to use. It must have a self-
contained help facility that serves as a user manual.
 Design and Implementation Strategy – The system is written in C# using Visual Studio 2010 for
Windows and uses a Microsoft SQL 2008 database.
4. Use-Case View
This section illustrates the Use-Case view applied to Event Driven Process Manager.
4.1 Use-Case Realizations
The following Use-Case Realizations illustrate the basic functionality of Event Driven Process Manager
from the user’s point of view.

EDPMAD
2017
Page 8 of 24
Use Case View
Actor1
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
«uses»
Process Event File
Print Job Status
Report
Load Event
Categories File
Load Agent List
File
Process Event
(Manual Input)
Add Event
Category
(Manual Input)
Delete Agent
(Manual Input)
Add Agent
(Manual Input)
«uses»
Figure 2 - Use-Case Descriptions
 Process Event File: The user may add and processes events from a file and generate an Event
Processing Report and an Exceptions Report.
 Print Job Status Report: The user may print a status report for each job being worked on, including
a list of events associated with each job, the agent assigned and its corresponding status.
 Load Event Categories File: The user may add event categories to the Event Categories list from a
file.
 Load Agent List File: The user may add agents to the Agent List from a file.

EDPMAD
2017
Page 9 of 24
Features for future development include:
 Add Event Category: The user may add event categories to the Event Category List manually
(through the keyboard).
 Add Agent: The user may add agents to the Agent List manually (through the keyboard).
 Delete Agent: The user may delete agents from the Agent List.
5. Logical View
This section describes the architecturally significant parts of the design model, such as its decomposition
into subsystems and packages. Each significant package is decomposed into classes and class utilities. The
architecturally significant elements and responsibilities are described, as well as important relationships,
operations, and attributes.
5.1 Overview
Software Architecture may be defined based on the implementation of the Perry and Wolfe Equation as:
Software architecture = {Elements, Forms, Rationale/Constraints}
The application was built using the JP.Framework. The main classes of the JP.Framework used in the
application are shown below:

EDPMAD
2017
Page 10 of 24
The JP.Data Class Library also references the Koko.Data.dll in the Koko.Framework. The JP.Data
DataSource.getDataReader method uses the dataSourceCollection and dataProvider classes in the
Koko.Data.dll to connect to the database. The dataProvider executes SQL stored procedures to access
tables in the database.

EDPMAD
2017
Page 11 of 24
Figure 3 below shows a class diagram with the most significant elements of Event Driven Process
Manager.
Figure 3 - Logical View of Event Driven Process Manager in Terms of Classes
The system architecture is organized around the EventCategory Class, a class that contains the variables,
criteria and constraints for events. Additional application classes were created to initialize and load data
into the application, validate events, assign agents, and report exceptions. The application uses lists of the
EventCategory, Job, Agent, Service and Customer classes.
The IEntity class in JP.Data.DataObjects is an interface to force print and loadFields methods on all derived
classes. Separate classes have been created for Login, Error Handling, and Output.
A #define Verbosity directive was used to adjust the trace and error console messaging during operation.
Customer Job Event
CustomerId JobId EventId
CustomerName JobEventList EventDateTime
CustomerAddress JobCustomerId EventCategoryId
CustomerTelephone JobServiceId EventAgentId
CustomerServiceTypeId JobAmountPaid EventJobId
EventCategoryConstraintText
EventCategoryConstraintStatus
EventCategoryConstraintAmount
Service Event Category
ServiceId EventCategoryId Agent
ServiceName EventCategoryProcess AgentId
ServiceDescription EventCategoryName AgentName
ServiceCost EventCategoryDescription AgentAvailableDate
EventCategoryPreviousEvent
EventCategoryNextEvent
EventCategoryDuration
EventCategoryAgentList Constraint
EventCategoryConstraintList ConstraintId
ConstraintCategoryId
ConstraintCategory ConstraintParameter1
ConstraintCategoryId ConstraintParameter2
ConstraintDescription

EDPMAD
2017
Page 12 of 24
6. Process View
The following diagram illustrates the system's decomposition into processes.
Event Input
File
Event
Log List
Event.Get
Event
Categ.
List
Event.Validate
Pass
Fail
Agent
List
Event.
Reportexeption
Event.
AssignAgent
Fail
Job
List
Event.Register
Pass
Output
Interface
Console
Event.
Reportevent
Manual Input
Report
Event
Category List
File
Agent List File
Print Jobs Status
Report
Input
Interface

EDPMAD
2017
Page 13 of 24
7. Deployment View
This program is run on a single PC running under Windows. It requires connection to a Microsoft SQL
2008 database.
8. Implementation View
This section describes the decomposition of the software into layers and subsystems in the implementation
model, and any architecturally significant components.
8.1 Overview
The most significant layers used are Application Management, Security Management, Error Handling, Data
Management and User Interface.
8.2 Layers
The most important classes used in each layer are described below.
Application
Management
A Session class was created to manage the application including various static
methods such as sessionRun, sessionIinitializeLoadData and
sessionProcessEvents. The sessionRun method calls the Login.loginValidate
and Help.helpPrint methods.
Security Management A Login class was created to provide security using the loginValidate method.
The User must login with a valid user name and password before processing.
Error Handling A separate ErrorHandling class was created with the errorHandlingPrintMethod
to handle all try catch exceptions.
Data Management An interface called IEntity was developed to force uniformity among derived
classes such as Agent, Customer, Event, EventCategory and Service. These
concrete entities override the print() and loadFields() methods but must follow
the structure of the virtual class. The loadFields method uses a GetDataReader
class to access the Database.
All DataObjects contain a loadFields method to populate the class by reading
the database. A class called getDataReader is used to pass a DataReader to the
DataObjects. getDataReader uses the dataSourceCollection and dataProvider
classes form the Koko.Framework. The dataProvider executes SQL stored
procedures to access the tables in the database.
All DataObjects contain a print method to print its contents. All print contents
are directed to the Output User Interface to be sent to the console using the
Output.outputPrintLine method.
List classes and List of List classes are used extensively.
All data from the EventDB Database is loaded to the DataObjects at the
beginning of the program using the sessionInitializeLoadData method. These
DataObjects remain open throughout the session to maximize performance.
UI (Presentation Layer) All output is handled by the Output class with the outputPrintLine method.

EDPMAD
2017
Page 14 of 24
9. Size and Performance
The application maintains the entire database in list classes in memory to maximize performance. Large
amounts of memory may be needed for large applications.
10. Quality
The application was developed using a framework and object oriented programming techniques to facilitate
maintenance. Data objects were standardized using the IEntity interface and method overloading was used
to adjust the print and loadFields methods for each class. Encapsulation, inheritance and overloading
techniques were used to maximize code reuse and minimize code generation.
Input and output transition classes were provided to facilitate connecting to different input and output
devices without modifying the application code. The #define directive was implemented to control
Verbosity. Separate class libraries were used for Security, Data, User Interface and Diagnostics, to
facilitate maintenance and future reuse.
The JP.Framework references the Koko.Framework directly, allowing future upgrades to the
Koko.Framework to be incorporated into the JP.Framework.
.

EDPMAD
2017
Page 15 of 24
Appendix I – Pre-Design Project Proposal and Work Plan
This Pre-Design Project Proposal and Work Plan provide a description of the application and tools used in
this project, and an updated Work Plan. For more details about the assumptions made, please refer to the
Software Architecture Document above.
Software Description
Event Driven Process Manager is a Console based (Win32) single user software application that allows the
user to manage various tasks performed by employees and other participants in an event driven process.
The application processes different types of events, creates an event log, validates that each event complies
with the rules and parameters provided in an Event Category List, and assigns an agent from an Agent List
to each event, if one is available. If the event does not comply with the rules or parameters specified in the
Event Category List, or there is no agent available to handle the event within the required constraints, the
application generates an exception report. The application also generates a Job Status Report once all the
events have been processed.
Event Driven Process Manager is a free open source application written in C Sharp. The program will
process events from an input file or through manual entry. Reports may be sent to the console or to a
printer. The initial release is limited to reading from a file and output to the console.
Tools for Analysis
MVP Development Corporation used Microsoft Visual Studio 2008, Microsoft SQL 2008 and Microsoft
Visio to create the application and generate diverse diagrams, including some UML diagrams.

EDPMAD
2017
Page 16 of 24
Work Plan
Feature Week Priority Status
1 Pre-Design Project Proposal 1 1 Done
2 Work Plan 2 1 Done
3 Project Requirements and Documentation 3 2 Done
4 Design Documentation/Framework Guidelines 4 3 Done
5 Framework Infrastructure 5 4 Done
6 Sample Database 6 5 Done
7 Application Design - Basic Functionality for Flow Control
Application Management 8 6 Done
Security Management 9 8 Done
Error Handling 9 8 Done
Data Management 7 6 Done
UI (Presentation Layer) 9 8 Done
8 Additional Event Validation Features
Validation of Agent Availability 11 9 Pending
Validation of Time, Status and Amount Constraints 12 9 Pending
Manual Data Entry and Output to Printer 12 9 Pending
9 Testing 10 9 Done
10 Finalize Design Documentation 10 9 Done

EDPMAD
2017
Page 17 of 24
Appendix II – Project Design and Documentation
Business Rules
Issue Description
Process Flow Processes and related events must be keep in order, since quite
a few of them require that previous events be completed before
they start or are possible.
Process/Event Constraints Each process and/or event may have none, one or many
constraints typically of the following form:
 Date – Time Constraint – the total number of days and/or
hours that the event has before it is considered expired and
not valid anymore. Or it can be used as a date-time to set an
alarm or time to trigger another event that requires some
action.
 Amount Constraint – this is a floating-point value that may be
used to set the full amount of something that must be part of
the event.
 Text Constraint – a string text value that could be used and/or
compared to set the valid and expected value.
 Status Constraint – given a list of possible status values, each
with a specific meaning, including: accepted, requires revision,
archived, dismissed, rejected. The constraint will require
routing the process / event to another process or event.
Next Event When looking at any event, the following or next event must be
known at all times.
Individuals Identities The identity of each individual should be unique and be related
his event capabilities.
Individual Capabilities Each individual is associated with a level of capability that
clarifies the individual to participate in a given event.
Individual Roles A single individual could have various roles within the process /
event flow.
Services Offered Service Description Price
Service A Deluxe Service $10,000
Service B Cheap Service $20,000
Service C Intermediate Service $50,000

EDPMAD
2017
Page 18 of 24
List of Events
Event Note
Process: Request
Request Registration The customer request is registered as soon as the customer fills
in a set of documents.
Request Pre-Review An agent reviews the submitted documentation and accepts,
requires revision to customer, or rejects the registration. If the
submission is rejected, the customer has 2 weeks to resubmit
from registration date.
Customer Payment Customer pays specific amounts based on the request type.
Only if the full amount is paid, the request will be sent to the
following processes and/or events. After customer receives the
pre-approval, the customer will pay a specific amount. He/she
has two months from the initial registration date to pay, else the
registration is canceled and the documentation must be submitted
in full again.
Final Pre-Review Again, agent reviews the submission and accepts or approves it
for further consideration. Upon consideration, the request is
queued for investigation. Note that after the request is queued,
the company has 15 days to start the “Investigation” process.
Process: Investigation
Investigation Notification Upon the de-queuing of a request for consideration by an Agent,
a notification notice must be sent to the requester to alert him/her
about the start of the “Investigation” process.
Inspection Request An agent schedules a Visit with the requester for inspection. The
customer has 30 days to setup the first inspection and get
inspected.
Inspection The agent inspects whatever needs inspection and collects all
needed information and/or photos for further evaluation.
Request Review Agent reviews the documentation submitted, the data collected
during the inspection, and the applicable rules for approval or
rejection, and prepares a document with the decision. The review
should be completed within 3 days after inspection.
Results Notification The customer is notified to personally review the results.
Results Review The Agent and the Customer review the results and agree
whether to proceed with the service. If an agreement is reached,
the service request is queued. The company has 15 days to call
the customer to schedule of the requested service.

EDPMAD
2017
Page 19 of 24
Process: Service
Service Notification Upon the de-queuing of a request for service by an Agent, a
notification notice is required to be sent to the requester to alert
him/her about the start of the “Service” process.
Service Request An agent schedules a Visit with the requester for service. The
customer has 30 days to setup the first service.
Service The agent provides the service and collects all needed
information and/or photos for further approval.
End of Service Notification The collected service documentation is delivered to the customer
for his/her approval. This notification should be submitted to the
customer not later than 1 week after the service has been
completed.

EDPMAD
2017
Page 20 of 24
Appendix III – Design Documentation
The project was designed and built using the JP.Framework, a framework derived from the
Koko.Framework developed by Dr. Eduardo Sobrino. This framework references the Data.dll from the
Koko.Framework and utilizes the dataSourceCollection and dataProvider classes of the Koko.Framework
to create its own dataReader class. The dataProvider executes SQL stored procedures to access the tables
in the database.
The JP.Framework application guidelines are customized for this project based on end user needs.
Application Guidelines
The following lists of guidelines are provided to framework users to ensure maintainability and
consistency in their projects:
Interfaces Use Interfaces to enforce a contract on their users that will specify what
properties and methods should be implemented along with their signature
(name, arguments and parameters). Always use an “I” (i) in front of the name
of the Interface to distinguish it from a class, for example “IDisposable”.
Enumerators When writing an enumerator always reserve the “0” (zero) value for the
“Unknown”. Expect users to use the “Unknown” value on those occasions that
the value is not provided or known at the time they are entering the data.
Destructors Implement a destructor when your class contains unmanaged resources or any
resource that consumes lots of space or holds another resource that is costly to
maintain. For example, on Database Connections.
When a using a class that implements the IDisposable pattern, always call the
Dispose method.
For classes that manage expensive resources, always instantiate them as late
as possible and dispose of them as early as possible.
Private Fields All private fields’ identifiers will begin with “m_” and will continue with the
Camel Notation, for example “m_MyInternalField”.
Methods Arguments All method arguments identifiers will begin with a lowercase word and will
continue with the Camel Notation.
Property Names All public property identifiers will be written using the Camel Notation.
A property should be created for each class field; no class field may be
accessed directly.
Public Fields All public field identifiers will be written using the Camel Notation. Global
variables will begin with “A” or “An” prefixes.
Assemblies All framework dll files are built in the JP.Framework/Assemblies/Debug folder.

EDPMAD
2017
Page 21 of 24
A description of the most important helper classes used is also provided below.
Application
Management
A Session class was created to manage the application including various static
methods such as sessionRun, sessionIinitializeLoadData and
sessionProcessEvents. The sessionRun method calls the Login.loginValidate and
Help.helpPrint methods.
Security Management A Login class was created to provide security using the loginValidate method.
The User must login with a valid user name and password before processing.
Error Handling A separate ErrorHandling class was created with the errorHandlingPrintMethod
to handle all try catch exceptions.
Data Management An interface called IEntity was developed to force uniformity among derived
classes such as Agent, Customer, Event, EventCategory and Service. These
concrete entities override the print() and loadFields() methods but must follow
the structure of the virtual class. The loadFields method uses a GetDataReader
class to access the Database.
All DataObjects contain a loadFields method to populate the class by reading
the database. A class called getDataReader is used to pass a DataReader to the
DataObjects. getDataReader uses the dataSourceCollection and dataProvider
classes form the Koko.Framework. The dataProvider executes SQL stored
procedures to access the tables in the database.
All DataObjects contain a print method to print their contents. All print
content is directed to the Output User Interface and sent to the console using
the Output.outputPrintLine method.
List classes and List of List classes are used extensively.
All data from the EventDB Database is loaded to the DataObjects at the
beginning of the program using the sessionInitializeLoadData method. These
DataObjects remain open throughout the session to maximize performance.
UI (Presentation Layer) All output is handled by the Output class through the outputPrintLine method.
Security Management
User Authentication and Authorization
 Provides select authentication authority.
o Operating System - Windows based authentication
o Database Management System
o Directory Services (LDAP)
Windows based authorization is being used to access the EventDB database.

EDPMAD
2017
Page 22 of 24
Data Encryption
 Encrypt / Decrypt
 Hashing
Encryption will be done in future development.
Error Handling (Diagnostics)
 Error Logging (to a File or System Log) – Validation errors are concatenated into a string and sent to
the output device after each event is processed.
 Exception Handling strategy - provide specific classes to trap issues. All exception handling through
try/catch should always include the “General” exception to trap “System.Exception” instances.
 Create the User Feedback strategy when an exception happens and is trapped by the Framework.
Data Management
While working with Databases, the following technologies are commonly used to work the needed
connectivity, request submission, error / exception management and results gathering:
ODBC Object Database Connectivity
OLEDB Object Linked and Embedded Database (Connectivity)
ADO Access Database Object
DAO Direct Data Object
JDBC Java Database Connectivity
CLI Class Library Interface
.Net Providers Manage providers available in .Net
 Provide a Collection of DataSources that will store connection strings that will be targeted to a
provider and accessed in the application by a Key. This class should provide the necessary connection
string encryption without the developer having to be concerned with the security issue.
 The Framework should provide a Data Layer that has a Class that resolves the connection to the
database once the Connection String is provided, ideally using a single method.
The JP.Framework uses the dataSourceCollection and dataProvider classes in the Koko.Framework.

EDPMAD
2017
Page 23 of 24
Appendix IV – Installation Instructions
The application has been created in C# using a framework named JP.Framework. JP.Framework must be installed
in the same directory as the Koko.Framework as it references the Koko.Data.dll in its JP.Data Class Library.
The sample datatabase tables are included in an Excel Spreadsheet named Data Structures 7. To load the Database,
create a database in Microsoft SQL 2008 and load the tables using the Import and Export Data (32 bit) utility. The
connection string in the JP.Data.DataSource.getDataReader must be updated with the proper server and database
names. A stored procedure must be created for each table in the database using the following stored procedure
names:
Sample stored procedure script is provided below:
USE [EventDb]
GO
/****** Object: StoredProcedure [dbo].[Agent$_Select] Script Date: 11/01/2009
23:08:44 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: <Author,,Name>
-- Create date: <Create Date,,>
-- Description: <Description,,>
-- =============================================
CREATE PROCEDURE [dbo].[Agent$_Select]
-- Add the parameters for the stored procedure here
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
select * from Agent$
END

EDPMAD
2017
Page 24 of 24
The level of verbosity in the application may be reduced by deleting the #define Verbosity directive at the beginning
of the Application Program.
Once the application is executed, it requests a user id and a password. Enter Sob for id and OpenK for password.
Next, the program will display a help screen. Press enter to execute. The program loads the database into lists of
Jobs, Event Categories, Customers and Agents. It then processes the events from the EventInputFile$ located in the
database. At the end of processing, enter Return to see the updated Job Report.

Oop final project documentation jose pagan v2.1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Oop final project documentation jose pagan v2.1

Similar to Oop final project documentation jose pagan v2.1 (20)

Recently uploaded

Recently uploaded (20)

Oop final project documentation jose pagan v2.1