El modelo lógico: definición y planeamiento de aplicaciones

El segundo paso de un proceso de diseño de aplicaciones COM+ consiste en dividir el modelo conceptual en los niveles lógicos de la arquitectura de tres niveles: el nivel de presentación o los servicios de usuario; el nivel intermedio, o los servicios empresariales; y la capa de datos o los servicios de datos. Si no está familiarizado con la arquitectura de tres niveles, consulte Uso de un modelo de arquitectura de Three-Tier.

Para comenzar este proceso, examine el modelo conceptual de sustantivos y verbos. Los nombres a menudo se pueden traducir en objetos de negocio (clases) y los verbos asociados a ellos pueden traducirse en acciones (métodos de las clases). Aunque puede ser difícil definir todos los nombres como objetos de negocio, las omisiones o los errores se volverán obvios en el momento en que complete el modelo lógico.

La mayoría de los objetos empresariales terminarán en el nivel de servicios empresariales, con los objetos restantes divididos entre los objetos de la interfaz de usuario en el nivel de servicios de usuario y los objetos de datos en el nivel de servicios de datos. Al crear un modelo lógico mediante la arquitectura de tres niveles, tenga en cuenta lo siguiente:

• Algunos de los nombres del diseño conceptual no representarán datos físicos reales, pero pueden representar una acción en el sistema o el rol de un objeto de negocio en el sistema. Un objeto de negocio también puede ser un servicio que realiza algún tipo de control del sistema, como un identificador de inicio de sesión para la seguridad.
• Evite crear objetos empresariales vagos "leyendo entre las líneas" en el modelo conceptual. Estos objetos empresariales pueden no ser correctos y debe considerarlos cuidadosamente antes de incluirlos en el modelo lógico. Si aparecen correctos, agréguelos al modelo conceptual explícitamente.
• Evite crear objetos empresariales que expresen la misma información o función; la duplicación puede ser costosa en términos de velocidad y rendimiento de la aplicación.
• Determinar las dependencias de objetos. Algunos nombres del modelo conceptual pueden ser simplemente atributos de otros objetos empresariales. Decida si el atributo puede existir de forma independiente. Si es así, debe convertirse en su propio objeto de negocio; si no es así, debe combinarse con el objeto de negocio adecuado.
• Evite crear objetos empresariales que intenten hacer demasiado. La sobrecarga de objetos empresariales puede significar más tiempo dedicado a separar el código más adelante y puede ser un dolor de cabeza de mantenimiento. No se deben combinar objetos distintos en el modelo conceptual; deben permanecer separados objetos de negocio. Puede controlar cualquier similitud mediante código para delegar sus funciones comunes en un objeto de negocio.
• Quite los objetos de negocio que no se usan en ningún escenario de uso. Si los objetos están diseñados para dar cabida al crecimiento futuro, considere la posibilidad de implementarlos una vez completada la aplicación inicial.

En este punto, puede empezar a pensar en términos de los equipos y el código. A partir de estos servicios empresariales, determine la funcionalidad de visualización y entrada que necesita para proporcionar como servicios de usuario. Defina qué tablas y procedimientos almacenados deben proporcionarse como servicios de datos. Para completar el modelo lógico, defina las interfaces de cada servicio e incluya definiciones de cada campo de datos y sus reglas de validación. Incluya también todas las funciones, su sintaxis y sus parámetros.

La definición de servicio o objeto no debe incluir ningún aspecto de la implementación física. La intención es proporcionar una guía clara para que los generadores de componentes lógicos funcionen desde y para permitir a otros programadores codificar fragmentos de la aplicación que pueden usar el componente antes de que se complete realmente. En el diseño del modelo lógico, debe documentar cada pantalla, función y objeto. No continúe con el modelo físico o la implementación hasta que cumpla estos criterios. Si continúa mientras el modelo conceptual y el modelo lógico no están de acuerdo, tendrá problemas graves más adelante en el ciclo de desarrollo.

El desarrollo incremental de una aplicación COM+ es común. Esto implica crear un subconjunto de los componentes finales conocidos y probarlos a través de cada capa de la aplicación: cliente, negocio y niveles de datos, a través del almacenamiento de datos. Este modelo de trabajo proporciona información sobre los requisitos adicionales por parte del cliente y las consideraciones de implementación. A menudo, este modelo de trabajo se prueba en un solo equipo.

Temas relacionados

El modelo conceptual: requisitos de la aplicación

El modelo físico: arquitectura de la aplicación

Uso de un modelo de arquitectura de Three-Tier