Normas y 30 de abril

estándares
Proyectos
JAVA
2010
Normativa
desarrollo
Normas y estándares, para el desarrollo de proyectos JAVA, Versión
1.0, Área de Arquitectura, Subgerencia de Operaciones Informáticas proyectos
JAVA, versión
1.0
 Índice

ÍNDICE.......................................................................................................................................................... 2

1. ÍNDICE ILUSTRACIONES ....................................................................................................................... 3

2. DEFINICIÓN DE SOFTWARE, NORMAS Y ESTÁNDARES ......................................................................... 4

3. MODELO DE ARQUITECTURA .............................................................................................................. 6

4. DEFINICIÓN Y DESARROLLO DEL PROYECTO ........................................................................................ 7

5. DIAGRAMA METODOLOGÍA................................................................................................................. 8

5.1. PROCESO DE NEGOCIO ............................................................................................................................ 9

5.2. REGLAS DE NEGOCIO ............................................................................................................................ 10
5.3. REQUISITO FUNCIONAL.......................................................................................................................... 11
5.4. REQUISITO NO FUNCIONAL ..................................................................................................................... 12
5.5. CASOS DE USO .................................................................................................................................... 13
5.6. COMPONENTES DE SOFTWARE................................................................................................................ 14

6. HARDWARE ....................................................................................................................................... 16

6.1. DESARROLLO ....................................................................................................................................... 16

6.2. CERTIFICACIÓN .................................................................................................................................... 16
6.3. PRODUCCIÓN ...................................................................................................................................... 16
6.4. SERVIDOR DE CONTROL DE VERSIONES ...................................................................................................... 16

2
1. Índice Ilustraciones

ILUSTRACIÓN 1: MODELO DE ARQUITECTURA ............................................................................................................... 6

ILUSTRACIÓN 2: METODOLOGÍA ................................................................................................................................. 8

3
2. Definición de Software, normas y estándares

 La definición del estándar a utilizar para proyectos JAVA, es JAVA 6 ó definido como la versión
1.6 JDK.

 Los proyectos a desarrollar deben contemplar su implementación en JBOSS, con visión a ser
implementado en un servidor WEBLOGIC. El uso del servidor Tomcat, queda fuera de la
norma. El desarrollo bajo Tomcat, es de responsabilidad de los ejecutores del proyecto (Jefes
de Proyecto, Jefes de Área, etc.); sin embargo, los desarrollos actuales, basado en este tipo de
servidores, deben ser migrados a las tecnologías mencionadas en este punto. El Área de
Ingeniería se encuentra en todo su derecho a no dar soporte y negar instalaciones de
componentes, si estas no cumplen con la norma establecida.

 Un proyecto JAVA, debe contemplar, el desarrollo de componentes de software reutilizables

para el negocio; esto quiere decir, que cada componente desarrollado, debe tener la cualidad
de ser incorporado a otro proyecto como pieza de software, si este lo requiere, cumpliendo
con el objetivo principal de reutilización.

 La herramienta de construcción de componentes de software (IDE) en JAVA para la Compañía,

contempla: ECLIPSE, JDEVELOPER (integración WEBLOGIC).

 Para fomentar el desarrollo de las buenas prácticas y por ende, la reutilización de software. Se
solicita el profesionalismo y prolijidad en el proyecto, tanto para el desarrollo del
componente, como para la documentación de software y documentación de proyectos,
incorporando: versionamiento, definiendo responsabilidades y otorgar el libre acceso.
Cumpliendo con los criterios básicos de información: rápida, oportuna y legible.

 Los frameworks a utilizar, graficados en el apartado del modelo de Arquitectura, representan

el estándar a utilizar, trabajan multicapa, cubren los requisitos especificados por el negocio y
desarrollo industrial de Software. Cualquier otro framework ó solución a integrar debe ser
presentada y justificada al Área de Arquitectura, para certificarse.

 La utilización del patrón MVC (Model View Controller) en el desarrollo, es parte básica y
fundamental en la construcción de un producto de software de la Compañía. Siendo parte de
la norma.

 La norma indica, la utilización de un DAO (Data Access Objects).

4
 Las funcionalidades de los productos de software desarrollados, deben cumplir con la
siguiente norma:

o Interfaz dinámica para usuarios.

o Para aplicaciones JEE, funcionar sin problemas, sobre los navegadores: Internet
Explorer 7 y 8, Mozilla Firefox versiones (2 y 3), Opera (versión 8 como mínimo),
Google Chrome, Safari.

 Los modelos de datos desarrollados para cualquier Base de Datos, como también, las
solicitudes de acceso, con la finalidad de: leer, explotar, o crear objetos (Stored Procedure,
triggers, etc). Deben ser justificadas y documentadas. La decisión de la base de datos a utilizar
es decisión de Arquitectura, de acuerdo a las necesidades de cada proyecto.

5
3. Modelo de Arquitectura

Arquitectura mínima para enfrentar un proyecto JAVA

Ilustración 1: Modelo de Arquitectura

 Spring, es un componente que permite integrar soluciones eficientes a la industria, para

implementación de: MVC, DAO, persistencia a base de datos, desarrollo de interfaces.

 Hibernate, es un componente de software, que permite crear y administrar pool de

conexiones a bases de datos, implementando una capa de persistencia de mapeo objeto-
relacional, entre una base de datos común al modelo de objetos de la aplicación y
viceversa.

6
6
4. Definición y desarrollo del proyecto

El proyecto debe contemplar el siguiente proceso documental, en su ciclo de desarrollo:

 Análisis de la propuesta.

 Alcances del proyecto.

 Análisis del negocio, levantamiento de las reglas de negocio y procesos de negocio.

 Análisis de requerimientos y requisitos (desarrollo del DER, desarrollo del DRU,

documento de requisitos de usuario).

 Documentación pre-desarrollo, documentación con UML (utilizar versión 2.0):

o Desarrollo de Casos de Uso: Requisitos y requerimientos, situación de negocio,
incluyendo implementación de la nueva solución.
o Desarrollo de diagramas de Clases.
o Desarrollo de diagramas de Interacción.
o Desarrollo de diagramas de Colaboración.
o Desarrollo de diagramas de Máquinas de Estados.
o Desarrollo de diagramas de Despliegue.
o Desarrollo de diagramas de Implementación.
o Desarrollo de diagramas de Actividades.

 Es importante mencionar para el punto anterior, como norma, la utilización de patrones

de diseño en las soluciones de software propuestas.

 Desarrollo del modelo conceptual, relacionado y justificado con los objetivos de negocio
perseguidos.

Desarrollo y documentación de modelos de datos (MER), modelos lógicos y físicos. Herramientas

a utilizar Oracle Designer hasta que se adquiera producto PowerDesigner.

Con respecto a la certificación de propuestas, Arquitectura se encargará de:

 Analizar (Modelo ER, modelos UML, integridad de datos, rendimiento de la aplicación,

seguridad, etc.).
 Certificar
 Visar (aprobación).

7
  Implementar los componentes que sean necesarios.

5. Diagrama Metodología

Ilustración 2: Metodología

8
5.1. Proceso de Negocio

Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para

lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y
salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser
aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas
resultantes.

Es una colección de actividades estructurales relacionadas que producen un valor para la

organización, sus inversores o sus clientes. Es, por ejemplo, el proceso a través del que una
organización ofrece sus servicios a sus clientes.

Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir
otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de
negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y
generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de
trabajo que efectúan las tareas de una organización. Los procesos poseen las siguientes
características:

 Pueden ser medidos y están orientados al rendimiento. Tienen resultados específicos.

 Entregan resultados a clientes o “stakeholders”.

 Responden a alguna acción o evento específico.

 Las actividades deben agregar valor a las entradas del proceso.

 Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un
negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Las dos
formas principales de visualizar una organización, son la vista funcional y la vista de
procesos.

9
5.2. Reglas de Negocio

Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las políticas, normas,
operaciones, definiciones y restricciones presentes en una organización y que son de vital
importancia para alcanzar los objetivos misionales.

Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente
de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a
3.000".

Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están
embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza
de algunas personas o en el código fuente de programas informáticos.

En los últimos años se viene observando una tendencia a gestionar de forma sistemática y
centralizada las reglas de negocio, de modo que sea fácil y sencillo consultarlas, entenderlas,
utilizarlas, cambiarlas, etc. Para ello se puede utilizar un motor de reglas de negocio. El motor de
reglas de negocio es un sistema que se configura para dar servicio a las necesidades de negocio a
través de la definición de objetos y reglas de negocio, el software se rige por flujos que derivan
responsabilidades a los distintos cargos de la empresa repartiendo así el trabajo equitativamente y
cuantitativamente, cuando, quien y donde tiene que desempeñar la tarea asignada.

Las reglas de negocio son un medio por el cual la estrategia es implementada. Las reglas
especifican - en un nivel adecuado de detalle - lo que una organización debe hacer

10
5.3. Requisito funcional

Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos,
manipulación de datos y otras funcionalidades específicas que muestran cómo los casos de uso
serán llevados a la práctica. Son complementados por los requisitos no funcionales, que se
enfocan en cambio en el diseño o la implementación.

Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los

comportamientos del sistema.

Típicamente, un analista de requisitos genera requisitos funcionales luego de diagramar los casos
de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un
proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos
(casos de uso y requisitos) se complementan en un proceso bidireccional.

Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta
información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para
seguir al mismo durante el desarrollo del producto.

El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y
concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser
descubiertas por interacción con usuarios, inversores y otros expertos en la organización

11
5.4. Requisito no funcional

Un requisito no funcional es, en la ingeniería de sistemas y la ingeniería de software, un requisito

que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus
comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto,
se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.

Los requisitos no funcionales más habituales son la estabilidad, la portabilidad y el costo.

12
5.5. Casos de Uso

En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales
de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más
escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para
conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas
técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a
usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

En el desarrollo del proceso de Casos de Uso, tanto para un desarrollo de programación

estructurado y por sobre todo para un desarrollo de orientación a objetos, es fundamental y
estrictamente necesario desarrollar el proceso de abstracción de los escenarios identificados en
los procesos de negocios, procesos de reglas de negocios y las definiciones de requerimientos,
tanto funcional como no funcionales, pasando por utilización del proceso de entidad.

Todo lo mencionado anteriormente, plasmado bajo los elementos: técnicos, metodológicos de la

ingeniería de requerimientos, para ello, se utilizara la metodología Proceso Unificado de Rational
(Rup) / Proceso Unificado Agil (AUP) utilizando el Lenguaje Unificado de Modelado (UML), recién,
nos llevan a definir y tratar el proceso de la creación de componentes.

En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un
sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio
sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el
comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo
que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un
sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la
especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para
ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en
su ámbito o en él mismo.

13
5.6. Componentes de Software

Los componentes de Software son todo aquel recurso desarrollado para un fin concreto y que
puede formar solo o junto con otros, un entorno funcional requerido por cualquier proceso
predefinido. Son independientes entre ellos, y tienen su propia estructura e implementación. Si
fueran propensos a la degradación debieran diseñarse con métodos internos propios de refresco y
actualización.

El proceso de la creación de componentes, sobre todo para una programación orientada a objetos,
es indispensable y estrictamente necesario la buena definición del proceso orientado a Casos de
Uso; esto es, debido a que el reconocimiento y entendimiento, tanto de objetos de negocios,
como el desenvolvimiento del negocio queda abstraído y reflejado en este proceso.

El proceso de componentes de software nos permite llegar a estudiar y tomar las siguientes
decisiones:

 Definir, incorporar, objetos de negocios en diseño de componentes.

 Definir la utilización de un Data Access Object ( DAO), Object-Relational mapping (ORM), o

un híbrido para el manejo de objetos de datos, por mencionar.

 Definir responsabilidades y participantes, en términos de objetos.

 Definir nuestro Data Source (DS), en función las necesidades de nuestros componentes y
negocio.

 Estrategia de Objetos de negocio, en conjunto con las estrategias de Pattern Design.

Complementando el punto de los pattern design, una vez obtenido el levantamiento de requisitos
y posteriormente a la etapa de casos de uso, como se menciono, se tomará la decisión de integrar
el o los pattern design a la estructura de los componentes, de acuerdo a la necesidad: si son para
estructura, comportamiento, creación ó interacción, tenemos las siguientes alternativas:

14
 Adapter Chain of Responsability Mediator
Abstract factory Composite Mementor
Builder Command Flyweight
Bridge Decorator Observer
Factory method Interpreter State
Prototype Facade Strategy
Singleton Iterator Template method
Visitor Proxy

La definición de la arquitectura de Software para el desarrollo del software está decidida en la

utilización de la Arquitectura Modelo – Vista – Controlador (MVC), siendo una de sus principales
características es que cada componente(modelo, vista, controlador) se tratan como entidades
separadas; esto hace que cualquier cambio producido en el modelo se refleje automáticamente en
cada una de las vista, que es distinto de la identificación y las definiciones del proceso de
componentes de software; por lo tanto, se separa tres partes independientes:

 Modelo, lógica real de la aplicación.

 Vista, lógica de presentación.

 Controlador, lógica operacional del negocio.

Cada una de estas partes, de forma independiente, permite definir la arquitectura de: desarrollo
de la aplicación, de sistema, y la de datos, definiendo los frameworks a utilizar.

La alternativa para el uso de la Arquitectura modelo vista controlador, se presenta bajo la

siguiente tecnología:

Modelo Vista Controlador

Velocity Struts Spring
JPA JSF (Java Server Faces) Hivemind
Hibernate DWR Avalon
Trapestry Ibatis
Myfaces Torque

15
6. Hardware
6.1. Desarrollo

Por definir con área de Ingeniería

6.2. Certificación

Por definir con área de Ingeniería

6.3. Producción

Por definir con área de Ingeniería

6.4. Servidor de control de versiones

Por definir con área de Ingeniería

16