Oop final project documentation jose pagan v2.1
2 likes991 views
The document provides an overview of the Event Driven Process Manager software architecture. It describes the software's purpose for managing tasks through event processing. The architecture is organized using Kruchten's "4+1" view model, with sections devoted to the logical view, process view, deployment view, and implementation view. Key classes are also outlined for managing the application, security, errors, and data access through an interface to a SQL database.
![MVP Development Corporation Version: 2.1
Software Architecture Document Date: 28/January/2017
EDPMAD
Confidential MVP Development Corporation
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](https://image.slidesharecdn.com/oopfinalprojectdocumentationjosepaganv2-170129162716/85/Oop-final-project-documentation-jose-pagan-v2-1-23-320.jpg)
Oop final project documentation jose pagan v2.1
- 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
- 2. 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
- 3. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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
- 4. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 5. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 6. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 7. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 8. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 9. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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:
- 10. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 11. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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
- 12. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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
- 13. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 14. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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. .
- 15. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 16. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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
- 17. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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
- 18. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 19. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 20. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 21. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 22. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.
- 23. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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
- 24. MVP Development Corporation Version: 2.1 Software Architecture Document Date: 28/January/2017 EDPMAD Confidential MVP Development Corporation 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.