JAVA CODE REVIEW ANALYZER
SYSTEM CONTEXT
1. Description
The System Context work product initially represents the
entire system as a single object or process and identifies the interfaces
between the system and external entities.
Usually shown as a diagram, this representation defines the system and identifies
the information and control flows that cross the system boundary.
The System Context highlights several important
characteristics of the system: users, external systems, batch inputs and
outputs, and external devices.
·
External events to which the system must respond
·
Events that the system generates that affect
external entities
·
Data that the system receives from the outside
world and that must be processed in some way
·
Data produced by the system and sent to the
outside world
The objects within the system boundary define the scope over
which the development team has some control.
The users and systems outside the boundary of the system are those that
affect the system operation and development but are beyond the control of the
developers within the currently defined scope of the project. Due to this
scoping aspect of the work product, during early stages of a project it is
useful to review this work product with the client to assist in delineating
development team and client responsibilities.
Note that the System Context may limit the breadth of its
coverage to emphasize just one class of external interfaces, for example, only
the interfaces to external systems.
Additionally, the
details required at lower levels of elaboration will depend upon what
interfaces are to be subsequently developed.
2.
Purpose
The purpose of this work product is:
·
To provide
the details at an adequate level to allow the creation of the relevant
technical specification.
·
Verify that
the information flows between the solution to be installed and external
entities are in agreement with any business process or context diagrams.
1.1 Impact of Not Having This Work Product
In the early stages of a project, without an agreed-on
context for the system, it is difficult to define the boundaries of the project
effort. There is risk of either
expanding the development effort into areas that are not part of the system or
of overlooking areas that should be developed.
2.1 Reasons for Not Needing This Work Product
The System Context need not be developed in the following
circumstances:
·
The system is not complex and has no external
interface or data conversion requirements.
·
The application being developed is one of a
number of applications within an existing system for which context
documentation already exists.
·
The client or another third party vendor
developed this work product and the content has been shared with the current
project team.
1.
Notation
Several notations can
be used to diagram the component of System Context. Most often they are represented as a level-0
process model, although static object models or functional models can represent
them. Diagrams are generally better than
text for this kind of overview material.
The template below shows information flow into and out of the system.
Note that in an actual diagram instance, each information flow would be labeled
with a descriptive name to help the reader understand the 
Figure 1 Innovation Factory for Telecommunications components with
Input and Output
The sections below describe each of the context interface
touch points. Please refer to the Component Model document of Innovation
Factory for Telecommunications (ARC 108) for more component details.
1.1 IBM HTTP Server
The IBM HTTP Server uses the HTTP protocol to communicate
the Innovation Factory for Telecommunications application that is deployed on
the WAS Portal. The Http Server will be deployed in the Demilitarized zone and
serves the static content to the end client which could be a web browser or any
device that could display HTML and XML.
2.1 Tivoli Directory Services
The Innovation Factory for Telecommunications application
communicates with the Tivoli Directory Services (TDS) to authenticate the user
information. The TDS communicates with the LDAP directory using the LDAP
protocol. The user authentication information and the information about the
various roles that are defined in the application are maintained in the LDAP
directory. The Portal communicates with the TDS using the TCP/IP protocol.
3.1 Wiki
The Portal communicates with the Wiki and retrieves the Wiki
pages of the innovations. Wikis in the current architecture are implemented
using the Media Wiki software. The user action on the Portal Web pages
determines if the Wiki Pages will be retrieved. Wikis also maintain the
documentation of the innovations. The Portal communicates with the Wiki using
the TCP/IP protocol. Wiki communicates with the MySql database to retrieve and
store the Wiki documentation.
4.1 Blogs
The portal communicates with the IBM Lotus Connection’s Blogging software to create new blogs for innovations or retrieve existing blogs. Lotus Connection’s Blogging uses a DB2 database to store the information about the blogs. TCP/IP is
The sections below describe each of the context interface
touch points. Please refer to the Component Model document of Innovation
Factory for Telecommunications (ARC 108) for more component details.
1.1 IBM HTTP Server
The IBM HTTP Server uses the HTTP protocol to communicate
the Innovation Factory for Telecommunications application that is deployed on
the WAS Portal. The Http Server will be deployed in the Demilitarized zone and
serves the static content to the end client which could be a web browser or any
device that could display HTML and XML.
2.1 Tivoli Directory Services
The Innovation Factory for Telecommunications application
communicates with the Tivoli Directory Services (TDS) to authenticate the user
information. The TDS communicates with the LDAP directory using the LDAP
protocol. The user authentication information and the information about the
various roles that are defined in the application are maintained in the LDAP
directory. The Portal communicates with the TDS using the TCP/IP protocol.
3.1 Wiki
The Portal communicates with the Wiki and retrieves the Wiki
pages of the innovations. Wikis in the current architecture are implemented
using the Media Wiki software. The user action on the Portal Web pages
determines if the Wiki Pages will be retrieved. Wikis also maintain the
documentation of the innovations. The Portal communicates with the Wiki using
the TCP/IP protocol. Wiki communicates with the MySql database to retrieve and
store the Wiki documentation.
4.1 Blogs
The portal communicates with the IBM Lotus Connection’s
Blogging software to create new blogs for innovations or retrieve existing
blogs. Lotus Connection’s Blogging uses a DB2 database to store the information
about the blogs. TCP/IP is the
communication protocol that is used by the portal to communicate with Blogging
software.
5.1 Polls
The portal communicates with the IBM Pulse to set up new
polls and to retrieve information about the existing polls. Cloudscape database
is used by the Pulse software to store and retrieve the polling information. In
the current architecture, Polls will be created to capture information about
the web sites on which the polls are set up. Polls can also be used to capture
information about the existing innovations.
6.1 Forums
Forums are used to provide feedback about the trials by
users. The forums are set up using the Jive software. The feedback from the
forums is used to evaluate existing innovations and also for the development of
new innovations. Jive software uses DB2 database to store the information about
the forums. The portal communicates with the Jive software using the TCP/IP
protocol for the retrieval of the forum’s information.
7.1 Profiles
Lotus Connection’s profiles is used for retrieving the
information about the users for new trials.
This software enables a manager to locate the resources with the required
skill sets to test new trials. Profiles uses a DB2 database to store the
profile information.
8.1 Surveys
Surveys along with forums can be used to provide feedback by
the users about the existing trials. The Surveys are setup using the phpESP
software. The phpESP uses mySQL database to store the survey information.
1.
References
Innovation Factory:
An integrated solution for accelerating innovation
Authors: Jeffrey
Coveyduc, Chin Huang, Luis Ostdiek, John Reif
2.
Glossary
|
Term |
Definition |
|
IF |
Innovation
Factory |
|
IT |
Information
Technology |
|
HTTP |
Hyper Text
Transfer Protocol |
|
DRDA |
Distributed
Relational Database Architecture |
|
TCP/IP |
Transfer Control
Protocol/Internet Protocol |
|
CSS |
Cascading Style
Sheets |
|
JSP |
Java Server Pages |
|
SASL |
Simple
Authentication and Security Layer |
|
SSL |
Secure Sockets
Layer |
|
LDAP |
Light Weight
Directory Access Protocol |
|
ACL |
Access
Control Lists |
|
EE |
Enterprise
Edition |
|
HTML |
Hyper Text Markup
Language |
|
MVC |
Model,
View, Controller |
|
WAS |
Websphere
Application Server |
|
HHTPS |
Secure
Hyper Text Transfer Protocol |
|
DSML |
Directory
Service Markup Language |
|
API |
Application
Programming Interface |
*************************************************************************
getDatosCliente
Datos de Entrada.
|
Request |
Tipo |
Descripción |
Mandatorio* |
|
customerID |
String |
Customer
Id para inicio de búsqueda |
X |
Datos de Salida.
|
Response |
Tipo |
Descripción |
|
DatosClienteVO[ ] |
DatosClienteVO |
Objeto
que contiene un listado |
Donde:
DatosClienteVO.get
|
Parámetro |
Tipo |
Descripción |
Ejemplo |
|
dirEnvioFiscal |
String |
Muestra
"Envío" cuando la Dirección es la de Correspondencia y
"Fiscal" cuando es el domicilio fiscal del cliente |
|
|
nombres |
String |
|
|
|
apellidos |
String |
|
|
|
dirFiscal |
String |
|
|
|
rfc |
String |
|
|
|
calle |
String |
|
|
|
num |
String |
Número Exterior
del domicilio de envío, fiscal o instalación |
|
|
municipioColonia |
String |
|
|
|
fechaAplicacionPago |
String |
|
|
|
numReferencia |
String |
|
|
|
fechaRealizacionPago |
String |
|
- |
|
montoPago |
String |
|
- |
|
cr |
String |
|
|
|
formaPago |
String |
|
|
|
banco |
String |
|
|
|
numTransaccion |
String |
|
- |
CoordenadasCartografiaVO
|
Parámetro |
Tipo |
Descripción |
Ejemplo |
|
customerId |
String |
|
|
|
latitude |
String |
|
|
|
longitud |
String |
|
- |
|
calle1 |
String |
|
- |
|
Calle2 |
String |
|
|
|
Calle3 |
String |
|
|
|
Calle4 |
String |
|
|
getBusquedaRentaCuenta
Datos de Entrada.
|
Request |
Tipo |
Descripción |
Mandatorio* |
|
cuenta |
String |
Cuenta
a buscar |
X |
Datos de Salida.
|
Response |
Tipo |
Descripción |
|
RentaCuenta[] |
ResultRentaCuentntaVO |
Objeto
que contiene los datos de la linea fija |
Donde:
RentaCuenta
|
Parámetro |
Tipo |
Descripción |
Ejemplo |
|
nombreCliente |
String |
|
|
|
apellidos |
String |
|
|
|
dnID |
String |
|
- |
|
statusContrato |
String |
|
- |
|
contrato |
String |
|
|
|
customerID |
String |
|
|
|
custCode |
String |
|
|
|
statusCuenta |
String |
|
|
|
tmCode |
String |
|
|
|
dnNum |
String |
|
|
|
dnNum |
String |
|
|
|
idHandset |
String |
|
|
|
tipoServicioOferta |
String |
|
|
|
nombrePlan |
String |
|
|
|
rentaMensual |
String |
|
|
