Ingrese a la arquitectura y el proceso J2EE

En el mundo comercial, utilizamos Java 2 Enterprise Edition (J2EE) para resolver problemas comerciales, desarrollar software comercial o proporcionar servicios por contrato a proyectos de otras empresas. Si una empresa desea construir un sitio web de comercio electrónico utilizando una arquitectura de varios niveles, generalmente involucra a gerentes, arquitectos, diseñadores, programadores, probadores y expertos en bases de datos durante todo el ciclo de vida del desarrollo.

Para que las diferentes partes funcionen de manera eficiente y efectiva, a menudo necesitan un proceso de desarrollo de software. Algunos procesos de desarrollo clásicos incluyen el modelo en cascada, el desarrollo rápido de aplicaciones (RAD) y la programación extrema. En este artículo, nos centraremos en un proceso de ingeniería de software popular, el Rational Unified Process (RUP). RUP proporciona un enfoque disciplinado para asignar tareas y responsabilidades a diferentes roles. Su objetivo garantiza que produzcamos software de alta calidad que satisfaga las necesidades del usuario dentro de un calendario y presupuesto predecibles.

Me gusta usar RUP para el desarrollo de J2EE por tres razones. Primero, RUP está centrado en la arquitectura; desarrolla un prototipo de arquitectura ejecutable antes de asignar recursos para el desarrollo a gran escala. En segundo lugar, RUP es iterativo y se basa en componentes. La línea de base de la arquitectura a menudo incluye un marco o infraestructura para facilitar la adición de componentes a través de iteraciones para personalizar y extender la funcionalidad de un sistema sin afectar al resto del sistema. En tercer lugar, RUP emplea un lenguaje estándar de la industria, UML, para modelar visualmente la arquitectura y los componentes de un sistema. RUP tiene cuatro fases de desarrollo diferentes: inicio, elaboración, construcción y transición. Este artículo, sin embargo, cubre ocho actividades esenciales involucradas en el desarrollo de J2EE desde una perspectiva técnica de una manera que mantiene el enfoque arquitectónico.

I. Análisis de requisitos

El análisis de requisitos describe lo que el sistema debe o no debe hacer para que los desarrolladores y los clientes puedan crear un contrato comercial inicial. Puede documentar los requisitos funcionales en conceptos comerciales, glosarios de dominio, casos de uso y maquetas de interfaz de usuario (UI). Los requisitos no funcionales, como el rendimiento y las transacciones, se especifican en un documento de requisitos complementarios. Puede crear la maqueta de la interfaz de usuario de alto nivel en papel o en HTML, dependiendo de qué tan profundamente esté involucrado en el proyecto.

La Figura 1 muestra dos ejemplos de casos de uso de un sistema de comercio electrónico típico. El viewOrdercaso de uso nos dice que un usuario inicia sesión en un sistema a través de una interfaz web, ve una lista de pedidos y hace clic en un enlace para ver los detalles del pedido de un pedido de compra específico. El addLineItemscaso de uso nos dice que el usuario busca en un catálogo de productos, selecciona productos interesantes y los agrega a una orden de compra.

II. Análisis orientado a objetos

Los analistas generan modelos de dominio de problemas: clases, objetos e interacciones. Su análisis debe estar libre de detalles técnicos o de implementación y debe contener un modelo ideal. El análisis de objetos le ayuda a comprender el problema y adquirir conocimientos sobre el dominio del problema. Debe mantener un modelo de dominio puro sin detalles técnicos porque un proceso empresarial cambia mucho más lentamente que las tecnologías de la información.

Estos dos primeros pasos, análisis de requisitos y análisis orientado a objetos, no son específicos de J2EE; son bastante genéricos para muchas metodologías orientadas a objetos. La Figura 2 muestra un modelo de análisis de objetos de alto nivel de una aplicación de muestra de una tienda de mascotas. Ilustra los conceptos principales que identificamos a partir de casos de uso de análisis de requisitos. Modelamos estos conceptos en objetos e identificamos sus relaciones.

El resultado de los requisitos y los análisis de objetos es el punto de entrada para el desarrollo de la arquitectura J2EE. Para desarrollar una arquitectura, se selecciona una pieza vertical, a menudo una parte crítica, como el modelo de objeto de dominio de pedido, para el diseño, implementación, prueba y despliegue de objetos. (Una pieza vertical, un concepto RUP, es una pequeña porción de un sistema. El punto de partida es un subconjunto de casos de uso, como se muestra en la Figura 1, y modelos de análisis de dominio, como se muestra en la Figura 3. La implementación de una pieza vertical da como resultado un minisistema completamente funcional que incluye todos los niveles, como JavaServer Pages (JSP) de nivel de interfaz de usuario, objetos de negocio de nivel medio como Enterprise JavaBeans (EJB) y, a menudo, bases de datos backend.) Puede aplicar la experiencia obtenida de prototipo a objetos de dominio, y deje que ese conocimiento sirva como una guía de diseño para la etapa de diseño de objetos.