You are on page 1of 16

Normas y

30 de abril

estándares Proyectos JAVA

2010

Normas y estándares, para el desarrollo de proyectos JAVA, Versión 1.0, Área de Arquitectura, Subgerencia de Operaciones Informáticas

Normativa

desarrollo

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

CASOS DE USO

  • 5.5. ....................................................................................................................................

13

  • 5.6. COMPONENTES DE SOFTWARE

................................................................................................................

14

6.

HARDWARE

.......................................................................................................................................

16

  • 6.1. DESARROLLO .......................................................................................................................................

16

CERTIFICACIÓN

  • 6.2. ....................................................................................................................................

16

PRODUCCIÓN

  • 6.3. ......................................................................................................................................

16

  • 6.4. SERVIDOR DE CONTROL DE VERSIONES

......................................................................................................

16

1.

Índice Ilustraciones

ILUSTRACIÓN 1: MODELO DE ARQUITECTURA

6

ILUSTRACIÓN 2: METODOLOGÍA

8

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).

Las funcionalidades siguiente norma:

de

los

productos de software

desarrollados, deben cumplir con la

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.

3.

Modelo de Arquitectura

Arquitectura mínima para enfrentar un proyecto JAVA

3. Modelo de Arquitectura Arquitectura mínima para enfrentar un proyecto JAVA Ilustración 1: Modelo de Arquitectura

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

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).

Implementar los componentes que sean necesarios.

  • 5. Diagrama Metodología

 Implementar los componentes que sean necesarios. 5. Diagrama Metodología Ilustración 2: Metodología 8

Ilustración 2: Metodología

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.

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

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

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.

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.

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:

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

siguiente tecnología:

uso

de la Arquitectura modelo vista controlador, se

presenta bajo la

Modelo

Vista

Controlador

Velocity

Struts

Spring

JPA

JSF (Java Server Faces)

Hivemind

Hibernate

DWR

Avalon

Trapestry

Ibatis

Myfaces

Torque

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