Tips Modelos Plex_2

ARQUITECTURA BASADA EN MODELOS PLEX Tips de modelado con Plex Versión 01.04

PDF created with pdfFactory trial version www.pdffactory.com

Fecha de Modificación 04-08-2000 01-01-2002 20-01-2003 07-06-2004 10-12-2009

Versión V1.00 V1.01 V1.02 V1.03 V1.04

REVISIONES Descripción de la modificación Documento base Revisión Patterns Revisión Vistas Revisión J2EE Revisión pública

Autor Lic. Lic. Lic. Lic. Lic.

Darío Darío Darío Darío Darío

Fabini Fabini Fabini Fabini Fabini

TABLA DE CONTENIDOS 1.

INTRODUCCIÓN .................................................................................................................................. 3

2.

MODELOS ............................................................................................................................................. 4 2.1

3.

MDA ................................................................................................................................................ 5

ARQUITECTURA DE UN SISTEMA................................................................................................... 5 3.1 ROL DEL MODELO .............................................................................................................................. 7 3.1.1 Fundacional .............................................................................................................................. 7 3.1.2 Layer......................................................................................................................................... 7 3.1.2.1 3.1.2.2

3.1.3 3.1.4 3.1.5 4.

FB_PATTERN y FB_OBASE .............................................................................................................. 7 FB_FIELDS......................................................................................................................................... 8

Plantilla .................................................................................................................................... 8 Canónico................................................................................................................................... 8 Negocio..................................................................................................................................... 8

ORGANIZACIÓN INTERNA DE LOS MODELOS ............................................................................ 8 4.1 ENTIDAD ........................................................................................................................................... 8 4.1.1 Entidad simple........................................................................................................................... 9 4.1.2 Entidad compuestas................................................................................................................... 9 4.2 APLICACIÓN ...................................................................................................................................... 9 4.3 UTILIDAD ........................................................................................................................................ 10 4.4 FACADE ........................................................................................................................................... 10 4.5 GESTOR ........................................................................................................................................... 11 4.6 ESQUEMA DE GENERACIÓN............................................................................................................... 11 4.7 ADMINISTRACIÓN DEL CAMBIO ........................................................................................................ 12 4.7.1 Ambientes................................................................................................................................ 12

5.

VISTAS ESTRUCTURALES DEL MODELO.................................................................................... 13 5.1 5.2 5.3

6.

VISTA DE CASO DE USO .................................................................................................................... 14 VISTA ESTÁTICA .............................................................................................................................. 15 VISTA DE GESTIÓN DE MODELOS ....................................................................................................... 15

DISCUSIÓN ......................................................................................................................................... 16 6.1

MODELOS POR CAPA J2EE ............................................................................................................... 16

Plantilla: HPGD Base.dot Documento: TIPS Modelos Plex.doc

PDF created with pdfFactory trial version www.pdffactory.com

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

ARQUITECTURA BASADA EN MODELOS PLEX

Resumen: Cuando se trabaja con un equipo de desarrollo multidisciplinario donde intervienen muchos integrantes (más de 20) con formación heterogenia y a su vez en un esquema distribuido la aplicación de una metodología de trabajo es central para lograr una calidad aceptable del producto y una productividad acorde al crecimiento del orden de magnitud. En este trabajo se presenta un conjunto de tips útiles para diseñar la arquitectura de un sistema utilizando PLEX como herramienta central. Esta aproximación introduce algunos conceptos que deben ser analizados por los Arquitectos Plex a la hora de iniciar un proyecto con cierta complejidad para palpitar un camino andado. Este trabajo no pretende ser una guía de modelado, simplemente enumera una serie de tips logrados a lo largo de años de experiencia con PLEX, de hecho la misma fue desarrollada antes de utilizar la librería de Patterns.

1. PRESENTACIÓN Seguramente mucho de nosotros tenemos nuestro propia forma de modelar con Plex basada en nuestra experiencia. En esta oportunidad quiero compartir un trabajo que resume nuestra experiencia a lo largo de unos cuantos años, en donde inicialmente comenzamos 3 desarrolladores trabajando sobre 5 modelos Plex hasta alcanzar más de 70 modelos totalmente integrados con un equipo de 14 desarrolladores, realizando en el medio 4 cambios de versiones de Plex, recompilando en algunos caso la totalidad de las funciones. Este enfoque no consideraba un equipo de desarrollo distribuido por lo cual decidí presentarlo como una nueva entrada, pero seguramente la línea a seguir es la que propone Lucio en su entrada “Colaboración remota” con Plex. Adjunto este link (http://www.pdfcoke.com/doc/23933185/TIPS-Modelos-Plex-2) con el trabajo a los efectos de ir estableciendo algunos problemas a considerar: • • • • • • • • • •

Recambio continuo de desarrolladores, requiere modelos legibles e intuitivo. Debemos diseñar para testing Los modelos deben ser “testeables” como una caja negra. La generación y compilación de un modelo debe ser inmediata y correcta. Los contratos entre modelos deben ser claros La documentación debe estar integrada al modelo Plex. La vida útil de un modelo trasciende la etapa tecnológica actual, refactorización continua. Las técnicas de modelado deben ir de la mano con Plex, lograremos buenos resultados. Estar preparado para el cambio continuo de plataformas. Estar preparados para el cambio continuo de versiones de modelos Plex y terceras partes.

Seguramente si esto es de interés seguiremos desarrollando y ampliando experiencia dentro de este grupo.

2. INTRODUCCIÓN El proyecto de reingeniería de los proceso administrativos de un Hospital de Alta Complejidad que se inicia en 1996, eligiéndose como plataforma principal DB2 sobre AS400 y como herramienta de desarrollo Plex (formalmente CA Plex ex Obsydian, Cool:Plex, AdvantagePlex, AllFusion Plex). Como resultado final, luego de más de 10 años, se a logrando implementar por completo la capa administrativa del sistema, incluyendo la administración de socios del plan de salud. Por otro lado, en el año 2000 se inicia el desarrollo de la capa clínica (HCE) sobre una arquitectura Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página 3 de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

J2EE (no Plex), surgiendo la necesidad de integrar el sistema administrativo y clínico (SAH-HCE). La capa de integración también se desarrolla sobre una arquitectura J2EE iniciando un desafío de comunicación con las aplicaciones Plex. La interoperabilidad se realizó utilizando una interfaz HL7 construida sobre un modelo desarrollado totalmente en Plex En la actualidad el sistema administrativo soporta 1500 tablas y 5300 vistas, organizadas en 8 bibliotecas del AS400 que consumen mas de 300GB de espacio (2 años contables en línea), con tablas que en algunos casos superan los 18 millones de registros y 9GB. Al sistema acceden más de 1000 usuarios diariamente con un promedio de 650 conexiones (OBSYTCP) diarias con picos de 800 conexiones y 400 usuarios simultáneos con picos de hasta 800 (cada usuario ingresa a más de una aplicación generando más de una conexión). En este contexto el sistema tiene una tasa diaria superior a 500.000 transacciones (tomadas al final de la línea, ítems de asientos contables, transacciones reales son muchas más). La totalidad del sistema administrativo esta desarrollado con Plex, contando con 177 aplicaciones (.exe) organizadas en 12 modelos abstractos y 59 modelos de negocio, que son mantenidos por 7 desarrolladores Plex Señor (part-time), utilizando ClassLibs ( OBASE sobre un "layer" interno) y PatternLibs en los últimos desarrollos, también sobre un layer interno. Los módulos de Turnos, Facturación y Cajas fueron implementados también en variante WinNT sobre SQLServer. Inicialmente el equipo de desarrollo estuvo integrado por 16 desarrolladores Plex, 4 analistas de negocio y 1 arquitecto, además de un equipo separado de implemetadores (responsables del testing y capacitación al usuario final) de 12 personas. Durante este proyecto se migraron 3 veces todos los modelos a versiones actualizadas de Plex que por lo general requerían recopilación. También durante el mismo se cambiaron 4 AS400 hasta el actual (System i) que ya no es, solo un AS. Este contexto trae como resultado este y otros trabajos realizados por el equipo de desarrollo para llevar adelante una metodología ordena en la construcción de los sistemas.

3. MODELOS Un modelo Plex es un conjuntos de objetos relacionados que definen un sistema o parte de un sistema (subsistema). El desarrollo de un sistema informático estará compuesto por un conjunto de modelos, la forma en que diseñamos la partición de los modelos dará a la arquitectura mayor o menor flexibilidad. Cuando definimos modelos en Plex debemos considerar los principios de programación de software como modularidad, cohesión, ocultamiento de la información, abstracción de datos, portabilidad, refactorización, diseño evolutivo, diseño planificado, etc. En esta vista de la arquitectura, los modelos se ven como componentes que ofrecen servicios público y objetos los cuales serán usados por otros modelos clientes. Esto establece un vínculos entre dos modelos a nivel de servicios, donde, un modelo servidor ofrecerá servicios que consume un modelo cliente. Los objetos también pueden ser referenciados externamente, esto establece una relación de uso entre los modelos, que debe ser administrada. Haciendo referencia a Martin Fowler, en ¿Ha muerto el diseño? “ para algunas personas que sólo han tenido un contacto breve con la Programación Extrema, pareciera que la XP convoca a la muerte del diseño de software. No solamente se ridiculiza a la actividad de diseño como "Big Up Front Design", sino que técnicas como UML, framework flexibles e incluso patrones son menospreciados o simplemente ignorados. De hecho la XP involucra mucho diseño, pero lo hace de una manera diferente a la de los procesos de software establecidos. La XP ha rejuvenecido la noción de diseño evolutivo con prácticas que permiten a la evolución ser una estrategia de diseño viable. También brinda nuevos retos y habilidades pues los diseñadores necesitan aprender cómo hacer diseño simple, cómo usar refactorización para mantener el diseño limpio y cómo usar patrones en un estilo evolutivo.” el mundo de hoy requiere de procesos ágiles donde los modelos deben estar preparados para una evolución continua, sufriendo refactorizaciones e incorporando nueva funcionalidad día a día, manteniendo un diseño adaptable, flexible y robusto administrando el impacto. Plex nos ayuda Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página 4 de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

mucho en este concepto si lo utilizamos de una manera razonable, pero debemos trabajar para eso y diseñar planificando mucho en como vamos a testear nuestras componentes de software, sino vamos a estar mucho más tiempo testeando nuestro software que codificando. 3.1 MDA Los conceptos de MDA deben ser considerados siempre que trabajemos con Plex. Ideas centrales en MDA n Separar la especificación de la funcionalidad del sistema, de su implementación sobre una plataforma en una tecnología específica. n Controlar la evolución desde modelos abstractos a implementaciones tendiendo a aumentar el grado de automatización.

4. ARQUITECTURA DE UN SISTEMA Un sistema complejo esta formado por un gran número de módulos, en este diagrama cada paquete corresponde con un modelo, los modelos abstractos se estereotipan como “Framework”. El resto de los modelos desde el punto de vista de la intercomunicación son presentados con “Fachadas” pero cada uno internamente implementa las componentes del sistema. Cada modelo debe ser visto como una componente en si misma que expone un conjunto de servicios bien definidos que pueden ser usados por otros modelos, abstrayendo por completo la forma en que se resuelve el problema concentrándonos en el “que” y no en el “como”, tomando todos los beneficio que este diseño presupone.

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página 5 de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

Un diseño modular debería posibilita probar el sistema utilizando distintas estrategias, Plex tiene elementos y herramientas que nos posibilitan realizar diseños modulares abstrayendo la complejidad, a continuación se listan algunas técnicas de testing que hay que tener presente desde el momento mismo que realizamos el diseño. Testing Funcional Testing de Regresión Testing de Compatibilidad

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página 6 de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

Testing de Performance Testing de Stress Testing de Unidades de Código Testing de Caja Blanca Testing de Usabilidad

4.1 ROL DEL MODELO En un primer nivel de abstracción, centramos el diseño definiendo el rol que juega cada modelo en nuestra arquitectura. Este primer nivel conforma el modelo base que clasifica los modelos según el papel que desempeña en la arquitectura.

Figura 1: Modelo de roles 4.1.1 FUNDACIONAL Los modelos fundacionales son aquellos provistos por Plex que definen las base de los patterns que se usan para modelar. Extendiendo esta definición, cualquier modelo de terceras partes que presente patterns de “nivel alto”, será considerado un modelo fundacional ( Ej: Websydian, WebClient) 4.1.2 LAYER Es un modelo que aporta muy poca funcionalidad, simplemente construye una capa intermedia entre los modelos fundacionales (Plex o terceras partes) y los modelos de negocio. Esta capa permite realizar una personalización de los patterns provistos por los modelos fundacionales dirigiendo de esta manera la construcción de los modelos de negocio, unificando criterios dentro del equipo y dotándolo de escudo protector. Esta capa brinda flexibilidad en los siguientes aspectos: • Diseño de GUI: se establece un estándar en el diseño de la interfaz del usuario, especificando colores, teclas rápidas, componentes, etc. • Control de errores: un error heredados de los modelos fundacionales puede ser corregido en este nivel garantizando el funcionamiento en todo el sistema. • Organizacional: proveer patrones de arquitectura que dirigen la organización interna de los modelo para que el equipo de desarrollo trabaje de forma unificada. Ejemplo de esto, son Conectores, Estructura de entidad, Estructura de aplicaciones, Esquema de compilación, Seguridad, etc. 4.1.2.1 FB_PATTERN Y FB_OBASE Modelo Layer que especializa los patterns de STORAGE y FOUNDATION por un lado y las librerías de OBASE por el otro. Esta especialización se acerca un poco mas al modelo de implementación que usará el equipo de desarrollo, estableciendo de forma segura la combinación de patterns Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página 7 de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

fundacionales que serán usado para modelar las componentes del negocio. En este nivel se definen principalmente los patterns core que serán usados con la especialización correspondiente, el mecanismos de seguridad que usaran las funciones y la estructuras de las aplicaciones con su correspondiente mecanismo de actualización (patches) si consideramos un deploy distribuido. 4.1.2.2 FB_FIELDS Modelo Layer que estandariza los campos usados por el equipo de desarrollo. Este modelo es homólogo al modelo FIELDS de Plex agregando los campos comunes al dominio del modelo de negocios que se esta diseñando. Este modelo conforma el diccionario de datos que utilizaran los modelos de negocio dentro de la industria. 4.1.3 PLANTILLA Este modelo Plex es usado como plantilla base para la generación de los nuevos modelos que utilizará el equipo de desarrollo permitiendo unificar principalmente: • Diagramas personalizados (Ej. Diagrama de Caso de Usos, ver mas adelante en Vista de caso de uso) • Nombres iniciales de niveles y variantes 4.1.4 CANÓNICO El modelo canónico, es un modelo de testing que acompaña a la metodología, el cual tiene implementado los “casos de testing” que cubren todos los patrones utilizados por el equipo de desarrollo, los denominados “patterns core”. La premisa que alienta este modelo es que “si la implementación del modelo es válida entonces todos los modelos de negación que usan este estándar son válidos” El modelo canónico es el modelo piloto cuando hay un cambio de versión de Plex, en este caso es fundamental primero implementar este modelo en las variantes que tenemos desarrolladas y ejecutar los casos de test diseñados para este propósito. Otra utilización de este modelo es cuando se requiere experimentar implementaciones en variantes diferentes, entonces trabajamos con los ajustes sobre este modelo. 4.1.5 NEGOCIO Los modelos de negocio son los que diseñan las componentes del negocio y integran las partes fundamentales de nuestro sistema. Dentro de los modelos de negocio hay que considerar los modelos “industriales” que son frameworks que definen conjuntos de patrones de negocios que son soluciones comunes dentro de la industria que estamos analizando, estos son nuestros propios patrones en el nivel de nuestro dominio de aplicaciones (Ej. Factura, Cuenta Corriente, Contacto, Cliente, Producto, Proveedor, etc). Este modelo se diseña siguiendo el estándar que define la estructura interna del modelo que nos permite desarrollar una construcción ordenadas de las componentes del modelo.

5. ORGANIZACIÓN INTERNA DE LOS MODELOS Para que todo el equipo de desarrollo trabaje de forma unificada los modelos deben seguir un lógica que estructura los objetos. Esto esta fuertemente relacionado con la riqueza con que se definen las relaciones de los objetos dentro de Plex. El principio básico que seguimos es considerar al objeto Entidad como una clase. Las funciones del modelo siempre estarán en el scope de una Entidad, el nombre de esta entidad representa de alguna manera la clase y las funciones sus métodos. 5.1 ENTIDAD La estructura de las entidad sigue la línea de de Plex (tanto para Patterns como para OBASE), como venimos manteniendo, las entidades las veremos como clases que representa objeto del negocio o componentes (objetos control). Cada entidad define sus funciones clasificándolas en fron-end (App) back-end (App BKE) y eventualmente un nivel para testing (App test).

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página 8 de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

5.1.1 ENTIDAD SIMPLE Una entidad contendrá en su scope un conjuntos de objetos tales como funciones front-end, funciones back-end, tabla, vistas, etc. Estos objetos estarán organizados siguiendo un estándar que permita al equipo de desarrollo comprender fácilmente donde definir cada objeto. Al igual que el modelo la entidad, vista como una componente, expondrá un conjunto de funciones como servicios públicos que podrán ser usado por otras funciones del modelo.

Figura 2: Entidad Simple 5.1.2 ENTIDAD COMPUESTAS Una entidad compuesta representa una componente o clase mucho más compleja, la cual contiene como parte otras entidades que a su vez pueden contener mas entidades. El modelo estructural es el mismo, la entidad raíz tendrá las funciones con los servicios público de la componente. Cuando diseñamos este tipo de entidades, conceptualmente nos puede ser de utilidad analizar Structural Patterns de Design Patterns de GoF para adoptar soluciones útiles. 5.2 APLICACIÓN El modelo tendrá una clase APLICACIÓN (una Entidad simple) con los ejecutables del modelo y las funciones de alto nivel que implementa los casos de uso principales.

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página 9 de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

Figura 3: Entidad APLICACIÓN 5.3

UTILIDAD

Todas las funciones de nuestro modelo deben estar en el scope de una entidad con su correspondiente estructura. Estas entidades modelan clases que agrupan funciones con una fuerte cohesión. 5.4

FACADE

Facade expone las funciones públicas que el modelo expone como servicios para ser usadas por otros modelos clientes. ( GoF Facade Pattern).

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página

10

de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

Figura 4 : Entidad FACADE 5.5 GESTOR En el gestor tendremos los servicios externos que el modelo requiere para su funcionamiento, permitiendo adaptar una interfaz externa a nuestro modelo e independizarnos de la implementación del servicio. (GoF Proxy Pattern, Adapter ). El componente Gestor agrupa los servicios externos separados por modelo, de forma de tener bien visible los contratos (dependencias) con el resto de los modelos que utilizamos.

Figura 5: Entidad GESTOR

5.6 ESQUEMA DE GENERACIÓN El esquema de generación es una herramienta fundamental cada vez que queremos realizar una Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página

11

de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

compilación completa del sistema, la cual debería hacerse periódicamente. Este esquema esta construido con un objeto Plex (Subjec Area o Pakcage) que contienen todos los objetos que deben ser compilados para la implementación del modelo. Las funciones externas al modelo que son usadas son provistas por el modelo servidor ya compiladas (.dll, .pnl, .lib) a partir de acá se genera y compila todo el esquema de generación, se crean los EXE y finalmente es el sistema debe salir andando, compilando exactamente lo que es necesario. El siguiente es un modelo, donde se prefija con FT que corresponde el identificador del modelo host.

Funciones externas al modelo que requieren compilación local (si es necesario) Cada una de las funciones suite App BKE de cada entidad. Cada una de las funciones suite App de cada entidad

Cada una de las Table de cada entidad

Solamente los MDI que Cada una de las View de cada

deben ser construidos como .EXE

entidad. Esto permite genera las view y las funciones del back-end scopeadas

Figura 6: Esquema de generación Notar que la estructuras de las entidades encaja perfectamente en la estructura del Esquema de Generación manteniendo separado los objetos de acuerdo a su capa de generación. 5.7 ADMINISTRACIÓN DEL CAMBIO Las administración de los cambios en nuestro modelo es fundamental para tener una pista adecuada de la evolución de nuestro sistema. Organizar los objetos que fueron cambiados en cada “release” de forma que entendamos claramente cual fue el impacto del cambio es de mucha utilidad a la hora que aparecen los problemas. En esta área Plex nos proporciona una potente herramienta que es el versionado de modelos, tips especiales deben seguirse en este aspecto. A esto le tenemos que sumar algunas técnicas para complementarlo, como por ejemplo, cada objeto que modificamos será organizado dentro de una lista (subject area, package, list) en la cual describimos el impacto del cambio; los objetos “deprecatados” serán renombrado usando un estándar y no serán borrados. 5.7.1 AMBIENTES Los ambientes que utilizaremos a lo largo de un proyecto juegan un papel fundamental y acá no podemos pedirle mucho a Plex, esto debe ser un estándar en el que debemos trabajar por fuera de Plex. Debemos organizarnos de forma que podamos trabajar, al menos, en tres grupos: Desarrollo, Prueba y Producción. Un cuarto grupo es opcional y corresponde al de Capacitación. Lógicamente, el más importante de los ambientes, es el de Producción que es donde nuestro sistema está funcionando, los demás ambientes deben estar estrictamente homologados a este, sino de poco servirán las pruebas del grupo de QA. Los cambios son agrupados de forma tal que podamos armar un pequeño proyecto el cual va cumpliendo sus fases de desarrollo, prueba, capacitación e implementación. Este mecanismo permite mantener un paralelismo de forma que cuando un proyecto pasa a prueba, otro proyecto puede iniciar el desarrollo y esto se puede repetir en cada una de las demás fases, considerando siempre la devolución de problemas. Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página

12

de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

El mecanismo nos debería asegurar que una única compilación se mantiene a lo largo de todo el ciclo.

6. VISTAS ESTRUCTURALES DEL MODELO Hay una “lista corta” de vistas que se usa en los textos generales de Arquitectura de Software (AS) y una “lista larga” que gira en torno de UML, el cual especifica nueve clases de diagramas correspondientes a ocho vistas, como se indica en el cuadro. Es difícil creer que esto se encuentra “unificado” de alguna manera. Cuando los promotores de UML hablan de arquitectura, cambian su modelo de vistas por uno que se refiere no a puntos de perspectiva o a incumbencias de los participantes, sino a niveles de abstracción; pero aún así, como se ha visto, su definición de arquitectura difiere de la definición estándar. Con Plex podemos desarrollar una serie de diagramas muy útiles que nos permite documentar nuestro modelo refiriéndonos a algunas vistas de las definidas por la AS.

Figura 7: Vistas de la arquitectura

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página

13

de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

6.1 VISTA DE CASO DE USO Modelo de caso de uso usando diagramas personalizados de Plex. Cada actor se mapea a un MDI (.exe) y los Casos de Uso (UC) a funciones en el scope del MDI. En este oportunidad cada UC se describe fuera del modelo pero podría utilizarse las facilidades de Help que tienen los objetos del modelo para realizar una descripción apropiada del UC. Esto tiene una aplicabilidad útil cuando la metodología de desarrollo es conducida por casos de uso.

Figura 8: Modelo de Casos de Uso en Plex

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página

14

de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

6.2 VISTA ESTÁTICA El diagrama de entidad-relación muestra una de las mas interesantes vistas de nuestro modelo, en nuestra metodología es considerado fundamental.

Figura 9: Modelo de entidades y relaciones en Plex 6.3 VISTA DE GESTIÓN DE MODELOS Como herramienta fundamenta para la gestión de modelos se tiene a Plex pero orden interno de los modelos presentan diferentes vistas que nos permiten llevar adelante una gestión adecuada de nuestro modelo.

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página

15

de

16

Arquitectura Basada en Modelos Plex Tips de modelado con Plex

Versión 01.04 Fecha: 10/Dic/09

7. DISCUSIÓN 7.1 MODELOS POR CAPA J2EE Son muchas las discusiones en torna a la organización interna de un modelo desarrollado con Plex pero tal vez las mas ricas tendrían que girar en torno a las consideraciones relacionada con las nuevas tecnologías, como es J2EE. En una “arquitectura de capas” como se plantea en J2EE, uno se pregunta que será más adecuado si hacer que los modelos Plex respeten las capas de la arquitectura o las capas estén modeladas internamente en cada entidad y por transitividad en cada modelo. Esta última forma de organizar los objetos es la tradicional que se origina con los modelos Fundacionales de Plex, en esta línea podemos considerar modelar las capas dentro de un modelo Plex o analizar la primera de las propuestas, que gira en torno a definir un modelo con la capa de Acceso a Datos, otro modelo para la Lógica del Negocio y una tercera para la Lógica de Presentación, a su vez esto particionado según la arquitectura del negocio. Esto como para empezar, pero podríamos considerar más capas.

Referencia bibliográfica [Bro75] Frederick Brooks Jr. The mythical man-month. Reading, Addison-Wesley, 1975. [Fow01] Martin Fowler. “Is design dead?”. XP2000 Proceedings, http://www.martinfowler.com/articles/designDead.html [GoF95] Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Design Patterns: Elements of reusable objectoriented software. Reading, Addison-Wesley, 1995. [RJB00] Jamers Rumbaugh, Ivar Jacobson, Grady Booch. El lenguaje unificado de modelado. Manual de Referencia. Madrid, Addison-Wesley, 2000. [OOSE92] Ivar Jacobson's Object-Oriented Software Engineering (OOSE) http://cs-exhibitions.uni-klu.ac.at/index.php?id=448

Confidencial

KlonIT, 2009

PDF created with pdfFactory trial version www.pdffactory.com

Página

16

de

16