Metapos - Point of Sale

MetaPOS - Point of Sale

Elaboration Phase Analysis and Design

MetaTech, Inc. 18311 Sturbridge Court Tampa, Florida 33647 +1 (813) 991-0177 DISCLOSURE PROTECTION NOTICE

This document and the attachments thereto are the proprietary and confidential information of MetaTech, Inc. Corporation. No part of this document may be duplicated except for the recipient’s own internal use. The recipient of this document agrees to inform its present and future employees and representatives, who receive or have access to this information, of its confidential nature and to instruct each employee and representative that he/she will not disclose any of the information to others except to the extent that any of such information is generally known to, and is available for use by, the public. This document has been prepared based upon limited information received by MetaTech, Inc.

Change History: Version Date Author Reason for Change Version 1.0 February 07, 2003 Kurt Madsen Initial Document

MetaTech, Inc. Confidential February 22, 2000 Page 2 TABLE OF CONTENTS

INTRODUCTION...... 6

BACKGROUND...... 7

ANALYSIS...... 9 Terms Defined...... 9 Business Requirements and Processes...... 9 Point of Sale...... 10 Back Office (You can skip this section)...... 10 System Requirements...... 10 Functional...... 10 Non-Functional...... 10

DESIGN...... 12 Information Perspective...... 13 Persistence Model (Data Dictionary)...... 13 Static Object Model...... 13 Dynamic Object Model...... 13 Infrastructure Perspective...... 13 Interfaces to External Systems...... 14 3rd Party Components Inventory...... 14 MetaTech Components...... 14 Shared System Services...... 15 Shared Business Services (Functional Model)...... 15 Application Perspective...... 15 Component Integration...... 15 High-Level Event Flow...... 16 Build Tree...... 16 System Perspective...... 16 Conceptual View...... 16 Deployment View...... 16 Exception Handling...... 17 Event Logging...... 17 Security...... 17

CONCLUSION...... 18

MetaTech, Inc. Confidential February 22, 2000 Page 3 MetaTech, Inc. Confidential February 22, 2000 Page 4 INTRODUCTION

Audience

This document describes the MetaTech POS product and is intended for technical audiences such as business analysts, programmers, and maintenance staff.

Purpose

This document presents the analysis and design for the MetaTech POS product.

Document Organization

This document is organized around the key questions which must be asked in order to understand the product requirements and the internal solution to meet those requirements. Background (Why) – Explains the history of the project and references the business case. It addresses questions such as the following:  Why is MetaTech POS different from competing products and services?  Who are our potential customers, and what requirements do they have in common? What requirements are different from one customer to the next? Analysis (What) – Presents an implementation independent specification of the system and the problem domain. This section is of primary importance to the project sponsor, end-users, and business analysts. This section is the first half of the Elaboration phase of the Rational Unified Process (a kind of SDLC).  What features and services are essential for phase one?  What features and services are apportioned for future phases?  What are the underlying assumptions and issues? Design (How) – Provides an implementation specific specification of how the product meets the requirements identified in the previous section. This section is of primary importance to technical staff such as programmers and testers. This section is the second half of the Elaboration phase of the Rational Unified Process. Relevant questions include:  How does the architecture provide for internal structure?  How does the product design implement the requirements as defined in the analysis?  How does the system provide for future needs and unforseen requirements?

Relationship to Other Documents

This document depends upon the business case. The user manual depends upon this document. 1. Business Case – Justifies the project from the sponsor’s perspective and is one of the outputs of the inception phase of the system development lifecycle (SDLC). 2. User Manual – Explains how to operate the product from the user’s perspective.

MetaTech, Inc. Confidential February 22, 2000 Page 5 BACKGROUND

Approach

Figure 1. System Development Life Cycle (SDLC) illustrates the system development lifecycle (SDLC) used for the MetaTech POS product development. The focus of this document is the second stage, which is referred to as the Elaboration Phase in the industry-standard Rational Unified Process. Stage II, Elaboration, can be sub-divided into two parts: analysis and design, which were defined in the previous section.

Add parts 1 and 2 of the UOP BSA/400 module here.

Sponsors Concerns

Problems Addressed by the New System

….etc… from the module…

MetaTech, Inc. Confidential February 22, 2000 Page 6 ANALYSIS

The MetaTech POS analysis provides an implementation-independent specification of the system and the problem domain. This section is of primary importance to the project sponsor, end-users, and business analysts. This section is the first half of the Elaboration phase of the Rational Unified Process (a kind of SDLC).

TERMS DEFINED

Term Definition Actor A person or a computer. An actor represents one side of an interaction in a use case. Use Case A set of related scenarios in which two or more actors interact. Use cases can have similarities to processes. For example, a point of sale use case involves a customer, salesman, and a computer who participate in the sale of one or more products. Scenario An instance of an interaction within a use case. For example, the point of sale use case mentioned above can have a normal outcome (i.e., successful transaction) or an exception outcome (i.e., credit card authorization failed). Feature Set A set of related marketable features and capabilities that are usually bundled and sold together. Release An implementation of MetaTech POS with one or more feature sets that is production-ready. Phase One or more work streams that is tied to project funding or a similar delivery-oriented project period from management’s perspective. Framework An architecture strategy in which plug-n-play extensions can be added to reconfigure MetaTech POS to serve unanticipated future needs while maximizing the reuse of common code and data. A framework implements most of the structure for a generic solution, thus permitting rapid delivery for each new feature set. Plug-n-play An interchangeable software module that provides a specific extention solution to a general problem. Taken together, they implement feature sets.

BUSINESS REQUIREMENTS AND PROCESSES

The following requirements and process definitions define the feature set for MetaTech POS release 1.0.

MetaTech, Inc. Confidential February 22, 2000 Page 7 POINT OF SALE

Use Cases (Add your process definitions here)

User Interface

Forms Hierarchy

Navigation

Form Mock-ups

BACK OFFICE (YOU CAN SKIP THIS SECTION)

Use Cases

User and Member Administration

User Interface

SYSTEM REQUIREMENTS

FUNCTIONAL

Monthly Data Archives

System Back-Ups

Contingencies

NON-FUNCTIONAL

Compliance with Industry Standards

MetaTech POS complies with industry electronic commerce standards in the retail industry including:  JPOS – This is the point of sale hardware interface standard for the future of point of sale. JPOS includes the older open point of sale (OPOS) standard.

MetaTech, Inc. Confidential February 22, 2000 Page 8  Java – Java is the programming language for Internet applications that can run on any operating system and hardware platform.  JDBC / ODBC – These standards provide a common programming interface for relational databases that support SQL. The advantage to using these standards is that MetaTech POS is able to work with many different database management systems (DBMS) such as Microsoft Access and MySQL.

MetaTech, Inc. Confidential February 22, 2000 Page 9 DESIGN

The MetaTech POS design provides an implementation-specific specification of how the product meets the requirements identified in the previous section. This section is of primary importance to technical staff such as programmers and testers. This section is the second half of the Elaboration phase of the Rational Unified Process. Note that architecture and design are not the same activities. Architecture refers to the blueprints for underlying structure and construction standards; design refers to the interpretation of those blueprints for the software that is actually constructed. For example, a general plan for a colonial house (architecture) can be reused to build many houses, each with its own individual design. Architecture is of strategic importance in order to grow MetaTech POS to meet unforseen future needs. In the “Art of War,” Sun Tzu said: A victorious strategy is not repeated; the configuration of responses to the enemy are inexhaustible. Just as water configures its flow in accord with the terrain, one who is able to change and transform in accord with the enemy and wrest victory is termed genius. It is important to note that the architecture used by MetaTech POS is called an application framework. An application framework separates a system into a domain-specific infrastructure that solve most of the customer’s problems in a general way and plug-n-play extensions which permit customization to meet specific business needs. This approach separates common infrastructure which is reusable from plug-in extentions that vary from one implementation to the next. The design phase of MetaTech POS can be viewed from the following perspectives: system, technical, integration, information, and application, which are defined as follows: . Information Perspective —Modeling the business’s information, activities, and processes defines the information architecture, which describes the content, behavior, and interaction of the problem domain independent of any technology solution. These concepts are used to build a business model of the problem domain. The information architecture provides a framework for the following information components of the business: subjects, events, roles, associations, rules, and processes. . System Perspective – This is a set of abstractions, services, components, and component relationships that comprise an information system. To enable application developers to understand their role in building the larger system, the system architecture is decomposed and simplified into three distinct domains: . Technical Perspective —The hardware and software products required to implement the business problem define the technical architecture. It describes technology engines and infrastructures that are the foundation of the proposed business solution. A technical architecture defines the services, tools, and technologies to use, and how they will be used. These definitions may include objects that encapsulate several databases, middleware, and other technologies, as well as the development tools to use and how they will be integrated to provide a complete software project support environment. Note that BSA/400 combines the Technical and Integration Perspectives. . Integration Perspective —The application services, system services, and external integration facilities define the integration architecture. An application service is a generalized business or functional capability common to many or all applications (for example, workflow). A system service is a generalized technical capability of a specific computing, network, or software technology (for example, messaging, and database). External system facilities have characteristics MetaTech, Inc. Confidential February 22, 2000 Page 10 of both application and system services, and provide mechanisms to facilitate the integration of external systems. The integration architecture describes the shared technical interfaces provided by an enterprise’s computing and communications infrastructure. The integration architecture defines the building blocks for application development. These building blocks are organized into a set of frameworks that encapsulate common functionality and a set of design patterns. . Application Perspective —The application architecture defines the structure and design of each application that will be developed on top of the system architecture (technical, integration, and information architectures). The application structure is defined by identifying each of the integration and information architecture components that will be used to implement the application. The interactions between these components are also defined. The application structure is frequently specified by defining the tiers (layers) of a distributed computing application. Developers use the service interfaces provided by the integration and information architectures to produce applications within the context of an application architectural model.

INFORMATION PERSPECTIVE

PERSISTENCE MODEL (DATA DICTIONARY)

Approach to Persistence (Object to DBMS Mapping)

Database Schema

STATIC OBJECT MODEL

Class Diagram

DYNAMIC OBJECT MODEL

Interaction and Activity Diagrams

INFRASTRUCTURE PERSPECTIVE

This section identifies all of the pieces of the puzzle, but not how they fit together (that’s the role of the next section). Issues in Platform and Vendor Selection. Explain REUSE, BUY, BUILD

MetaTech, Inc. Confidential February 22, 2000 Page 11 Figure 2. Infrastructure, Components, and Services – SEE BSA/400 website FIRST HANDOUT #4

INTERFACES TO EXTERNAL SYSTEMS

3RD PARTY COMPONENTS INVENTORY

Package Diagrams

METATECH COMPONENTS

Package Diagrams

SHARED SYSTEM SERVICES

SHARED BUSINESS SERVICES (FUNCTIONAL MODEL)

APPLICATION PERSPECTIVE

The application architecture specifies how the various services and resources identified in the Infrastructure View are wired together to implement a feature set. Figure 3 depicts the high-level event flow within MetaTech POS. A key point is that components can be reorganized to implement different applications with workflow used to control event processing and transaction definition.

COMPONENT INTEGRATION

Figure 1 shows how the pieces of the puzzle are wired together to create an application. Note that many applications can be assembled by reusing existing components and services.

MetaTech, Inc. Confidential February 22, 2000 Page 12 Figure 3. High-Level Flow of Events – SEE BSA/400 website FIRST HANDOUT #5

HIGH-LEVEL EVENT FLOW

The flow of events for release 1.0 as illustrated in Figure 3 is as follows: 1. Biller administrator pre-enrolls payers 2. Biller uploads per-payer invoice data 3. MetaTech POS acknowledges receipt of Biller’s data 4. MetaTech POS validates invoice data & acknowledges acceptance to Biller 5. Invoice data is normalized into multi-biller, multi-payer repository 6. Biller schedules promotion of invoice data from staging to production 7. Payer registers with service and optionally assigns payer agents 8. Payer requests outstanding invoices 9. Payer or agent schedules payment instructions on per-invoice basis 10. MetaTech POS batches payment instructions and sends to FIs and payment networks (e.g. ACH) for clearance 11. FIs acknowledge receipt of instructions and paid invoice feed is provided to Biller’s A/R system

BUILD TREE

SYSTEM PERSPECTIVE

This section ties everything together. The primary focus is how the applications are to be configured and deployed into production. The collection of applications comprises the MetaTech POS product.

CONCEPTUAL VIEW

Error: Reference source not found provides a coceptual view of relationships among the major components of MetaTech POS. Note that portions of processing can be distributed across the network, but this is not a requirement for deployment. Process View

DEPLOYMENT VIEW

MetaTech POS can be deployed at a customers’s data center or at a MetaTech data center within which customer replicated -implementations (i.e. customer’s customers) can be hosted. In either case, these hosting and network requirements must be met.

MetaTech, Inc. Confidential February 22, 2000 Page 13 Windows 2000 Stand-Alone

Hardware

Environment and Configuration

Linux Front-End with Windows Back-End

Hardware

Network

Environment and Configuration

EXCEPTION HANDLING

EVENT LOGGING

SECURITY

MetaTech, Inc. Confidential February 22, 2000 Page 14 CONCLUSION

MetaTech, Inc. Confidential February 22, 2000 Page 15