martes, 4 de diciembre de 2012
ANALISIS DE SISTEMAS Y DISEÑO UML
UML
· 2. Metodología Orientada a Objeto UML [ UML ] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo : no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión , por poner un ejemplo. Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.
· 3. Categorías de Diagramación En UML existen 2 tipos de diagramas, clasificados según su utilidad dentro del diseño de sistemas. Por un lado, los de análisis, diseño y procedimientos Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado: Diagrama de clases Diagrama de componentes Diagrama de objetos Diagrama de estructura compuesta (UML 2.0) Diagrama de despliegue Diagrama de paquetes Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado: Diagrama de actividades Diagrama de casos de uso Diagrama de estados Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: Diagrama de secuencia Diagrama de colaboración Diagrama de tiempos (UML 2.0) Diagrama de vista de interacción (UML 2.0)
· 4. Jerarquía de Diagramas
· 5. Creación de Diagramas Diagramas de cajas de uso: Son responsables de documentar los macrorequisitos del sistema. Sus símbolos principales son el actor y el óvalo de la caja de uso. Diagrama de actividades: Versión UML del diagrama de flujo. Se usan para analizar los procesos y problemas. Diagrama de Clases: Se usan para mostrar las clases de un sistema y las relaciones entre ellas. Una sola clase puede mostrarse en más de un diagrama, no es necesaria mostrar todas las clases en un solo diagrama monolítico. Diagrama de Interacción: Existen 2 tipos de diagramas de interacción: la secuencia y la colaboración. El primero, muestra las clases a lo largo de la parte superior y los mensajes enviados entre esas clases , modelando un solo flujo a través de los objetos de sistemas. El segundo, usan las mismas clases y mensajes pero organizados en una disposición espacial. Diagramas de Estado: Muestran como cambian los objetos mediante el inicio y fin de los procesos de sistemas. Diagrama de Componentes: Muestra los subsistemas que llevan a hacer el producto final
· 6. Creación de Diagramas Hallar Alimentos Caja de Usos Salir de la Cueva Irse de Cacería Buscar Alimento Evitar los Depredadores Regresar a la Cueva Diagrama de Actividades Sustento Agua Alimento Actor Diagrama de Clases 1) 2) 3)
· 7. Creación de Diagramas Actor Canasta Fuego Adquirir Alimento Vaciar Alimento Caminar a La Cueva Abrir Tomar Alimento Cocinar Alimento Trasladar el Alimento Alimento Cocinado Comer Diagrama de Secuencia Diagrama de Colaboración 5) 1: Reunir Alimento 3: Caminar a la cueva 8: Comer Alimentos 2: Vaciar 4: Abrir 8: Tomar Alimento 6: Cocinar Alimento 7: Retirar Alimentos Reposo Buscar Comida Hambre Salir de la Cueva Seguro para Comer No tiene hambre Tiene hambre 4) 6) Fuego Canasta Actor
· 8. Modelado de Datos UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.
· 9. Análisis de datos Casos de Uso Los Casos de Uso describen bajo la forma de acciones del comportamiento de un sistema Definen los límites del sistema y las relaciones entre el sistema y el entorno. Son descripciones de la funcionalidad del sistema independientes de la implementación. Equivalen a los Diagramas de Flujo de Datos del Enfoque Estructurado. Particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo. Están basados en el lenguaje natural, es decir, es accesible por los usuarios. Actores Principales: personas que usan el sistema. Secundarios: personas que mantienen o administran el sistema. Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interactúa.
· 10. Construcción de un Diagrama de Uso de Caso UML define cuatro tipos de relación en los Diagramas de Casos de Uso: Comunicación Inclusión Extensión Herencia Parámetros para la construcción de un caso de uso: Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada Caso de Uso. Preguntas clave: cuáles son las tareas del actor? qué información crea, guarda, modifica, destruye o lee el actor? debe el actor notificar al sistema los cambios externos? debe el sistema informar al actor de los cambios internos? La descripción del Caso de Uso comprende: el inicio: cuándo y qué actor lo produce? el fin: cuándo se produce y qué valor devuelve? la interacción actor-caso de uso: qué mensajes intercambian ambos? objetivo del caso de uso: qué lleva a cabo o intenta? cronología y origen de las interacciones repeticiones de comportamiento: qué operaciones son iteradas? situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso?
PROCESO UNIFICADO
Proceso Unificado
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.
Características
Iterativo e Incremental
El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.
Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
Diagrama ilustrando como el énfasis relativo en las distintas disciplinas cambia a lo largo del proyecto.
Dirigido por los casos de uso
En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.
Centrado en la arquitectura
El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.
Enfocado en los riesgos
El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.
Lenguaje unificado de modelado
El Lenguaje unificado de modelado no es el sucesor de la oleada de metodos de analisis y diseno orientados a objetos que surgio a finales de la decada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los metodos de Booch, Rumbaugh, Brühl (OMT) y Jacobson, pero su alcance ha llegado a formar parte fundamental de la Ingeniería de Software tras su estandarización en 1997 con el OMG (Object Management Group o Grupo de administracion de objetos).
¿Por qué analizar y diseñar?
En resumidas cuentas, la cuestion fundamental del desarrollo del software es la escritura del código. Después de todo, los diagramas son solo imagenes bonitas. Ningun usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, Pag 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qué lo hará y como le ayudara a usted cuando llegue el momento de escribir el codigo. No existe una evidencia empirica adecuada que demuestre si estas tecnicas son buenas o malas; Pero lo que si es cierto es que es de considerable ayuda para las etapas de mantenimiento en proyectos de mediana/avanzada envergadura.
DIAGRAMA HIPO
DIAGRAMAS HIPO
(En inglés, Hierarchy-Input-Process-Output) fueron desarrollados por IBM como esquemas de representación para un desarrollo jerárquico de arriba a abajo y como una ayuda de documentación para productos comercializados. Un conjunto de diagramas HIPO contiene una tabla visual de contenido, un conjunto de diagramas generales y un conjunto de diagramas de detalles.
1. La tabla visual de contenido es el directorio del conjunto de diagramas en el paquete; consta de un directorio con estructura de árbol (o de gráfica),
un resumen de los contenidos de cada diagrama general, y una explicación de los símbolos utilizados.
2. Los diagramas generales especifican los procesos de un sistema en forma funcional; cada diagrama describe las entradas, los pasos de proceso y las salidas para la función en cuestión; un diagrama general puede indicar la localización de los diagramas de detalles subordinados necesarios.
3. Los diagramas de detalle permiten crear para cada módulo la realización de un diagrama funcional . Por ejemplo validar transacciones
METODOLOGIA DEL PROTOTIPO
MODELO DEL PROTOTIPO
El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interactúa el hombre y la máquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.
El paradigma de construcción de prototipos tiene tres pasos:
· Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las áreas donde es obligatorio más definición
· Construir y revisar la maqueta (prototipo).
· El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software
· Este modelo es útil cuando
· El cliente no identifica los requisitos detallados
· El responsable del desarrollo no está seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-máquina
Etapas para la elaboración del Modelo de Prototipo
Ciclo de Vida de un Sistema basado en Prototipo
Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación, su cara externa, pero dicha interfaz está fija, estática, no procesa datos. El prototipo no tiene desarrollada una lógica interna, sólo muestra las pantallas por las que irá pasando la futura aplicación.
Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que satisface los requisitos y necesidades que se han entendido claramente. Realiza, por tanto, un un proceso real de datos, para contrastarlo con el usuario. Se va modificando y desarrollando sobre la marcha, según las apreciaciones del cliente. Esto ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el software está constantemente variando, pero, a la larga, genera un producto más seguro, en cuanto a la satisfacción de las necesidades del cliente.
Cuando un prototipo se desarrolla con el sólo propósito de precisar mejor las necesidades del cliente y después no se va a aprovechar ni total ni parcialmente en la implementación del sistema final se habla de un prototipo desechable.
Para que la construcción de prototipos sea posible se debe contar con la participación activa del cliente.
Ciclo de Vida del prototipo
Ventajas del Modelo de Prototipo
Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.
Desventajas del Modelo de Prototipo
Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo más seguro es que el desarrollador haya hecho compromisos de implementación para hacer que el prototipo funcione rápidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que esté escrito en un lenguaje de programación inadecuado.
ciclo de vida de un sistema
CICLO DE VIDA DEL DESARROLLO DE SISTEMAS
1.- IDENTIFICACION DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS.
En la primera etapa se requiere que el analista observe de forma objetiva lo que ocurre en una empresa, luego en conjunto con los demas integrantes de la organización hará notar los problemas.
Las oportunidades son aquellas situaciones que el analista considera que pueden perfeccionarse mediante el uso de sistemas y en la identificacion de objetivos, el analista deberá descubrir lo que la empresa intenta realizar, y luego, estará en posibilidad de determinar si el uso de sistemas apoyaría a la empresa para alcanzar sus metas.
2.-DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN.
Para identificar los requerimientos de información dentro de la empresa, pueden utilizarse diversos instrumentos, los cuales incluyen el muestreo, la entrevista, los cuestionarios y la observación.
En esta etapa el analista hace todo lo posible para identificar que información requiere el usuario para desempeñar sus tareas.
3.- ANALISIS DE LAS NECESIDADES DEL SISTEMA.
En esta fase, se analizan las decisiones por realizar, que son donde las condiciones alternativas, acciones y reglas de accion podrian determinarse.
Existen tres metodos para el analisis de las decisiones:
- El lenguaje estructurado.
- Las tablas de decision.
- Los arboles de decision.
En sistemas, cada problema es único; y en consecuencia, nunca habra sólo una solución correcta.
4.-DISEÑO DEL SISTEMA RECOMENDADO.
En esta fase, se utiliza toda la información que se recolectó con anterioridad, y se elabora el diseño lógico del sistema. Una parte del diseño lógico del sistema es el diseño de la interfaz con el usuario.
La etapa del diseño tambien incluye el diseño de los archivos o la base de datos que almacenará los datos requeridos por quien toma las decisiones en la organización.
5.-DESARROLLO Y DOCUMENTACIÓN DEL SOFTWARE.
En esta fase, el analista trabaja con los programadores para desarrollar todo el software original que sea necesario. Dentro de las técnicas estructuradas para el diseño y documentación del software se tienen: el método HIPO, los diagramas de flujo, los diagramas de Warnier y el pseudocódigo.
En esta fase el analista del sistema transmite al programador todos los requerimientos de programación que necesitan para desarrollar el sistema.
6.- PRUEBAS Y MANTENIMIENTO DEL SISTEMA.
El sistema de información debe probarse antes de utilizarlo y el costo es menor si se detectan los problemas antes de la entrega del sistema. El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboración con el analista del sistemas.
El mantenimiento del sistema y de su documentación empiezan justamente en esta etapa; y despues, esta función se realizara de forma rutinaria a lo largo de toda la vida del sistema.
7.- IMPLEMENTACIÓN Y EVALUACIÓN DEL SISTEMA.
En esta última etapa, el analista ayuda a implementar el sistema y esto incluye el adiestramiento que el usuario requerirá, y la evaluacion del sistema toma parte en cada una de las etapas, pero uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el sistema desarrollado.
EL CICLO DE VIDA DE UN SISTEMA INFORMATICO
Requerimientos
Esta fase fundamental para que la estrategia informática encaje dentro de las metas de la empresa, ya que en ella se cumplen las funciones del modelaje del negocio y planificación de sistemas; esto con el fin de proyectar las estrategias del negocio y determinar de esta forma sus requerimientos de información.
Durante esta fase se desarrolla un modelo del área estudiada, donde se representa: Los procesos que se llevan a cabo, la información utilizada por ellos y las reglas políticas y practicas de la empresa relacionada con estos procesos.
Este modelo permite proyectar las estrategias, procesos y flujos de datos de la empresa al igual que las interrelaciones entre procesos y datos, con el fin de desarrollar un plan de sistema de información capaz de guiar el desarrollo de un sistema que permita dar soporte al area en estudio en el cumplimiento de sus objetivos.
El Plan de Sistemas debe contener:
• Los sistemas que requiere el área del negocio, así como sus bases de datos y la información que intercambiaran o compartieran.
• Descripción detallada de cada sistema y aplicación incluyendo sus objetivos funcionales y sus bases de diseño.
• Todo hardware y software que serán utilizados para el funcionamiento requeridos por el área de negocio (incluyendo las redes)
• Métodos de desarrollo para cada sistema como lo es adquisición de paquetes, nuevo desarrollo o actualizaciones
• Esquema de los problemas actuales del area de negocio y de las posibles mejoras que se puedan realizar en cada sistema
• Análisis de los beneficios que se espera derivar de los sistemas que conforman la arquitectura
El plan de sistemas de información es uno de los factores más importantes para el departamento de informática o sistemas ya que constituye la guía para emprender los proyectos que requiera el cliente, reclutar y adiestrar al personal necesario y la adquisición e instalación de hardware y software necesarios.
Durante esta fase se desarrolla un modelo del área estudiada, donde se representa: Los procesos que se llevan a cabo, la información utilizada por ellos y las reglas políticas y practicas de la empresa relacionada con estos procesos.
Este modelo permite proyectar las estrategias, procesos y flujos de datos de la empresa al igual que las interrelaciones entre procesos y datos, con el fin de desarrollar un plan de sistema de información capaz de guiar el desarrollo de un sistema que permita dar soporte al area en estudio en el cumplimiento de sus objetivos.
El Plan de Sistemas debe contener:
• Los sistemas que requiere el área del negocio, así como sus bases de datos y la información que intercambiaran o compartieran.
• Descripción detallada de cada sistema y aplicación incluyendo sus objetivos funcionales y sus bases de diseño.
• Todo hardware y software que serán utilizados para el funcionamiento requeridos por el área de negocio (incluyendo las redes)
• Métodos de desarrollo para cada sistema como lo es adquisición de paquetes, nuevo desarrollo o actualizaciones
• Esquema de los problemas actuales del area de negocio y de las posibles mejoras que se puedan realizar en cada sistema
• Análisis de los beneficios que se espera derivar de los sistemas que conforman la arquitectura
El plan de sistemas de información es uno de los factores más importantes para el departamento de informática o sistemas ya que constituye la guía para emprender los proyectos que requiera el cliente, reclutar y adiestrar al personal necesario y la adquisición e instalación de hardware y software necesarios.
Fase II - Análisis / Diseño
El objetivo de esta fase es desarrollar el diseño arquitectónico de los sistemas, utilizando los requerimientos obtenidos en la primera fase. En el diseño arquitectónico se engloban dos componentes: los datos y los procesos, los cuales serán analizados y diseñados desde una perspectiva conceptual a una física, dentro de las cuatros actividades que se encuentran en esta fase.
• Actividades dentro de la fase de Análisis/Diseño.
• Analizar y Diseñar Proceso: Las operaciones del negocio y los requerimientos de funcionamiento definidos en la primera fase, se toman en cuenta con el propósito de determinar la forma en que debe funcionar el sistema.
• Analizar y Diseñar Los Datos: Con los requerimientos de información definidos en la fase I se debe organizar los distintos modelos de datos que nos ayuden a diseñar la base de datos que hagan falta para que el sistema funcione de acuerdo al modelo de funcionamiento.
• Diseñar y Organizar Los Componentes Físicos: Todo componente físico como (pantallas, base de datos) que hagan posible el funcionamiento del sistema de acuerdo al modelo de funcionamiento.
• Planificar El Desarrollo De Los Componentes Físicos: actividad en la cual planificamos la forma en que pueden ser construidos e implementados los componentes físicos de una forma rápida y productiva.
En esta fase de análisis / diseño puede incluirse una sub.-fase de evaluación de paquetes. Esta se pudiese realizar si en los requerimientos se estableció adquirir un paquete de aplicaciones en lugar de completar un diseño arquitectónico.
• Actividades dentro de la fase de Análisis/Diseño.
• Analizar y Diseñar Proceso: Las operaciones del negocio y los requerimientos de funcionamiento definidos en la primera fase, se toman en cuenta con el propósito de determinar la forma en que debe funcionar el sistema.
• Analizar y Diseñar Los Datos: Con los requerimientos de información definidos en la fase I se debe organizar los distintos modelos de datos que nos ayuden a diseñar la base de datos que hagan falta para que el sistema funcione de acuerdo al modelo de funcionamiento.
• Diseñar y Organizar Los Componentes Físicos: Todo componente físico como (pantallas, base de datos) que hagan posible el funcionamiento del sistema de acuerdo al modelo de funcionamiento.
• Planificar El Desarrollo De Los Componentes Físicos: actividad en la cual planificamos la forma en que pueden ser construidos e implementados los componentes físicos de una forma rápida y productiva.
En esta fase de análisis / diseño puede incluirse una sub.-fase de evaluación de paquetes. Esta se pudiese realizar si en los requerimientos se estableció adquirir un paquete de aplicaciones en lugar de completar un diseño arquitectónico.
Fase III – Construcción
Dentro de esta fase de construcción existen actividades separadas en cinco sub.-fases:
• DESARROLLO DE INFRAESTRUCTURA
Durante esta fase se desarrollará y organizará la infraestructura que permita cumplir las tareas de construcción en la forma más productiva posible.
• ADAPTACIÓN DE PAQUETE
Uno de los objetivos centrales de esta subfase es conocer al máximo detalle posible el funcionamiento del paquete, este asegurará que el paquete será utilizado con el máximo provecho, tanto desde el punto de vista del negocio, como de la utilización de recursos. Cada componente del paquete será revisado en forma exhaustiva por el equipo Analista – Usuario, con el fin de conocer y comprender todos los aspectos del paquete.
• DESARROLLO DE UNIDADES DE DISEÑO INTERACTIVAS
Las unidades de diseño interactivas, son procedimientos que se cumple o se ejecutan a través de un dialogo usuario – sistema.
Las actividades de esta subfase tienen como objetivo central:
• Especificar en detalle las tareas que debe cumplir la unidad de diseño
• Desarrollar componentes
• Realizar las pruebas unitarias y las pruebas de integración a nivel de la unidad de diseño.
• DESARROLLO DE UNIDADES DE DISEÑO BATCH
En esta sub.-fase se preparan especificaciones hechas utilizando una combinación de técnicas como flujo gramas, diagramas de estructuras, tablas de decisiones etc. Cualquiera que se utilice será útil para que la especificación sea clara y se logre el propósito de que el programador comprenda y pueda programar y probar los programas correspondientes.
• DESARROLLO DE UNIDADES DE DISEÑO MANUALES
Las actividades de esta subfase tienen como objetivo central desarrollar todos los procedimientos administrativos que rodearán y gobernarán la utilización de los componentes computarizados desarrollados en la fase de diseño detallado y construcción.
• DESARROLLO DE INFRAESTRUCTURA
Durante esta fase se desarrollará y organizará la infraestructura que permita cumplir las tareas de construcción en la forma más productiva posible.
• ADAPTACIÓN DE PAQUETE
Uno de los objetivos centrales de esta subfase es conocer al máximo detalle posible el funcionamiento del paquete, este asegurará que el paquete será utilizado con el máximo provecho, tanto desde el punto de vista del negocio, como de la utilización de recursos. Cada componente del paquete será revisado en forma exhaustiva por el equipo Analista – Usuario, con el fin de conocer y comprender todos los aspectos del paquete.
• DESARROLLO DE UNIDADES DE DISEÑO INTERACTIVAS
Las unidades de diseño interactivas, son procedimientos que se cumple o se ejecutan a través de un dialogo usuario – sistema.
Las actividades de esta subfase tienen como objetivo central:
• Especificar en detalle las tareas que debe cumplir la unidad de diseño
• Desarrollar componentes
• Realizar las pruebas unitarias y las pruebas de integración a nivel de la unidad de diseño.
• DESARROLLO DE UNIDADES DE DISEÑO BATCH
En esta sub.-fase se preparan especificaciones hechas utilizando una combinación de técnicas como flujo gramas, diagramas de estructuras, tablas de decisiones etc. Cualquiera que se utilice será útil para que la especificación sea clara y se logre el propósito de que el programador comprenda y pueda programar y probar los programas correspondientes.
• DESARROLLO DE UNIDADES DE DISEÑO MANUALES
Las actividades de esta subfase tienen como objetivo central desarrollar todos los procedimientos administrativos que rodearán y gobernarán la utilización de los componentes computarizados desarrollados en la fase de diseño detallado y construcción.
Fase IV – Pruebas
Esta fase, da inicio luego de que las diferentes unidades de diseño han sido desarrolladas y probadas por separado. Durante su desarrollo, el sistema se emplea de forma experimental para asegurar que el software no falle, es decir que funcione deacuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga, y de esta forma poder detectar cualquier anomalía, antes de que el sistema sea puesto en marcha y se dependa de el. Para evaluar el desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de prueba:
• Funcional: Prueba desde el punto de vista de los requerimientos funcionales.
• De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeño.
• De Integración: Prueba de interfaces.
• De Aceptación Técnica: Prueba de manejo de condiciones extremas.
Si el Sistema cumple de forma satisfactoria con estos niveles mencionados anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptación final, durante el cual, el sistema comenzará a funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptación.
Finalizado el Periodo de Aceptación, se le dará al sistema la aprobación final, para que pase a ser el sistema oficial.
• Funcional: Prueba desde el punto de vista de los requerimientos funcionales.
• De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeño.
• De Integración: Prueba de interfaces.
• De Aceptación Técnica: Prueba de manejo de condiciones extremas.
Si el Sistema cumple de forma satisfactoria con estos niveles mencionados anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptación final, durante el cual, el sistema comenzará a funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptación.
Finalizado el Periodo de Aceptación, se le dará al sistema la aprobación final, para que pase a ser el sistema oficial.
Fase V - Producción / Mantenimiento
“Una vez que un sistema pasa a formar parte de la vida diaria de la empresa, cada programa, cada procedimiento y cada estructura de datos se convierte en una pieza del negocio que, como tal, deberá funcionar en forma constante, exacta y confiable. L a operación del negocio ahora dependerá del funcionamiento del sistema, por lo que las tareas de mantenimiento cobran vital importancia.
Durante la fase de mantenimiento, se ponen en práctica todas las políticas y los procedimientos destinados a garantizar la operación continúa de los de los sistemas y a asegurar su uso efectivo, con el fin, de que éstos se constituyan en una verdadera herramienta de apoyo al logro de los objetivos estratégicos de la empresa
Durante la fase de mantenimiento, se ponen en práctica todas las políticas y los procedimientos destinados a garantizar la operación continúa de los de los sistemas y a asegurar su uso efectivo, con el fin, de que éstos se constituyan en una verdadera herramienta de apoyo al logro de los objetivos estratégicos de la empresa
lunes, 3 de diciembre de 2012
MODELADO Y DISEÑO ORIENTADO A OBJETOS
Introducción a la Orientación a ObjetosConceptos fundamentales.
Presentación del método
Beneficios de las técnicas O.O.
· Reusabilidad del software
· Mayor flexibilidad para realizar mantenimiento y modificaciones del software
· Disminuye el gap semántico proveyendo una representación consistente en todo el ciclo de vida
· Mejor interacción entre el usuario/analista/diseñador.
· Más apropiado para abordar problemas más complejos.
Tres enfoques de organización para comprender el mundo· Diferenciación de la experiencia en Objetos y Atributos
· Distinción entre el todo y sus partes
· Formación y distinción de clases de objetos.
Concepto de Objeto y Clase.
ObjetoDefinición 1: Un objeto es algo real o abstracto acerca del cual almacenamos datos y métodos que manipulan dichos datos (Martín/Dell)Definición 2: Encapsulado de datos, operaciones que tratan dichos datos, y que observa un estado interno, que posee identidad (se distingue por su existencia misma y no por sus atributos). Cada objeto es una instancia de la clase a la que pertenece.
ClaseUna clase es un grupo de objetos con propiedades (atributos) similares, comportamiento común (operaciones), relaciones comunes entre objetos, y semántica común (Raumbaugh).
Comunicación por mensajesLos objetos de un sistema se comunican entre sí a través de mensajes. El mensaje es enviado por un objeto emisor y recibido por un objeto destino o receptor. Un mensaje invoca una o más operaciones en el objeto receptor.
Principios fundamentales
Abstracción
EncapsulamientoMecanismo que permite ocultar los detalles de implementación de un objeto. Permite empaquetar en una unidad los datos y las funciones que operan sobre dichos datos.
HerenciaRelación entre clases de objetos que permite incluir (rehusar) los atributos y operaciones definidas en otra clase más general de la cual se hereda o deriva.
PolimorfismoLa misma operación es resuelta de diferente forma según el objeto que recibe el mensaje.
Conceptos Adicionales
Agregación Composición de un objeto por otros. Es una relación más débil que la que existe entre el atributo y el objeto al cual pertenece, y más fuerte que una asociación.
ConcurrenciaPropiedad que distingue un objeto activo de otro inactivo. (Booch)
PersistenciaEs la propiedad de un objeto cuya existencia trasciende el tiempo y/o el espacio (ej. el objeto continua existiendo luego de que su creador deja de existir / la ubicación de un objeto se mueve a un espacio de direcciones diferente de aquella donde fue creada).
Visibilidad capacidad de restringir el acceso a atributos y servicios de un objeto. Particularmente importante en el diseño e implementación. (ej. C++: público / protegido / privado)
Modelos utilizados.
Modelo de Estructura de ObjetosEl modelo de estructura de Objetos (OSM) es el modelo central. Contiene las clases de objetos requeridas para construir la aplicación y las relaciones entre ellas. Se construye a través de un proceso aditivo durante todo el ciclo de desarrollo del sistema.
Modelo de Secuencias de TransaccionesEl modelo de procesos de negocios (BPM) describe los procesos que se llevan a cabo en la organización. Se lo utiliza para analizar la organización y comprender sus procesos, parte de los cuales (o todos), serán soportados por el sistema a desarrollar. El modelo de secuencia de transacciones (TSM) parte de la especificación de alto nivel del BPM y lo traslada en requerimientos para la aplicación. El TSM se corresponde conceptualmente con lo USE-Cases de Jacobson (OOSE).
Diagramas de Interacción de ObjetosLos diagramas de interacción de objetos muestran las interacciones entre objetos requeridas para proveer al usuario los servicios descriptos en el TSM.
Diagramas de Flujo de ActividadLos diagramas de flujo de actividad son utilizados para analizar y presentar flujos de actividad complejos en los procesos de negocio y en las secuencias de transacciones (secuencias, iteraciones, y decisiones).
Modelo de ciclo de vida de objetosEl modelo de ciclo de vida de objetos es utilizado para describir como un objeto cambia de estados en el tiempo y que eventos producen dichos cambios de estado.
Modelo global del sistemaEl modelo global del sistema es utilizado para dividir el sistema en unidades de diseño manejables. Es una herramienta para manejar la complejidad de desarrollo de grandes sistemas. Especifica la interfaces entre las unidades de diseño.
Modelo de Estructura de Objetos (OSM)
Conceptos y propósito del modelo de estructura de objetosEl OSM es el modelo fundamental que provee un medio uniforme para modelar el sistema desde la captura de requerimientos en la etapa inicial del análisis hasta la implementación, atravesando todo el ciclo de desarrollo del sistema.
Este modelo identifica:
las clases de objetos en la aplicación
como las clases de objetos se asocian unas con otras
como se comunican los objetos
los detalles de cada clase de objetos, incluyendo atributos y operaciones
Durante el proceso de análisis y diseño, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el nivel necesario para la implementación es alcanzado.
Todos los demás modelos capturan detalles que alimentan es modelo.
El desarrollo de OSM es un proceso aditivo, diferenciándose esto del enfoque transformacional característico de otros métodos como el estructurado, donde los DFD del análisis son transformados en diagramas de estructura durante el diseño, con los consiguientes problemas que esto acarrea.
Durante el ciclo de desarrollo se aportan los siguientes elementos al modelo:
Análisis del Negocio: se reconocen objetos claves del negocio y generan las abstracciones en las clases apropiadas (objetos entidad).Análisis de Requerimientos: se identifican asociaciones estructurales entre objetos y nuevas clases (entidad).Diseño lógico: Se incorporan todas las clases necesarias para la aplicación incluyendo los objetos de interfaz y de control.Diseño Físico: se incorporan todos los detalles remanentes para la implementación física de cada clase de objetos.Componentes del modelo de estructura de objetos.El componente básico del OSM es la clase de objetos.
Se distinguen tres tipos de clases:
Objetos Entidad
Objetos de Interfaz
Objetos de Control.
Para cada clase identificada se describen:
Operaciones
Atributos
Restricciones
Adicionalmente el OSM describe las asociaciones entre objetos o clases de objetos. Se distinguen los siguientes tipos de asociaciones:
Relaciones Estáticas
Herencia
Agregación
Comunicación por mensajes
Objetos entidadRepresentan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representan la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Ejemplos de objetos entidad pueden ser empleado, alumno, etc.
Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Objetos InterfaceRepresentan los objetos técnicos requeridos para vincular la aplicación con el entorno. Representan el vínculo a través del cual el sistema recibe o suministra datos e información al entorno. Típicamente incluyen interfaces con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones.
Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Objetos de controlContienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes.
Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Clases abstractas y concretasUna clase de la cual pueden generarse instancias particulares (objetos), se denomina clase concreta.
Una clase abstracta es aquella que no instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones, y restricciones, reutilizadas a través de la herencia por múltiples clases concretas.
En el diagrama de estructura de objetos una clase abstracta se representa con un rectángulo punteado.
OperacionesUna operación define un servicio ofrecido por un objeto junto con la información que debe suministrarse cuando es invocado (nombre, argumentos de entrada/salida).
También puede contener una especificación de método, el cual especifica una implementación para la operación.
Notación: Durante la etapa de Análisis o Diseño lógico pueden utilizarse típicamente texto libre o pseudocódigo. Durante el Diseño físico dichas especificaciones son trasladadas en un lenguaje de programación específico como ser C++, Java, Visual Basic, etc. Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son llamadas operaciones implícitas. Las operaciones implícitas más importantes son Crear, Destruir, Leer, y Actualizar. Una operación implícita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales.
La identificación y especificación de operaciones es una tarea clave durante el Diseño Lógico.
AtributosSon valores de datos asociados a los objetos de una clase al cual describen.
Están fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto.
La decisión de cuando un ítem debe considerarse como atributo o como clase varía de sistema en sistema, dependiendo de su semántica en el dominio de problema. Lo que en un sistema se modela como atributo en otro puede modelarse como una clase.
Cada atributo identificado debe ser atómico en el sentido de que debe ser tratado como una unidad. En tal caso puede ser un valor simple o grupo de valores tratados siempre como unidad (ej. dirección).
Debe notarse que las clases no se modelan en formas normales. La decisión sobre la estructura de datos subyacente a utilizar se difiere hasta el Diseño Físico.
Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definición estándar sobre formato, longitud y dominio de valores para atributos del mismo tipo.
RestriccionesLas restricciones pueden especificarse sobre los valores que un atributo o relación pueden tomar.
La implementación de las restricciones puede realizarse de diferentes formas:
reglas de validación durante los procesos de entrada de datos (user inputs)
database-level triggers
lógica de control contenida en una o más operaciones.
Relaciones EstáticasLas relaciones estáticas describen como los objetos se asocian unos con otros en la misma forma que en el modelo entidad-relación. Identifican así mismo dependencias entre objetos, cuando un objeto requiere de la existencia de otro ya sea de la misma clase o de otra.
Las relaciones estáticas se establecen usualmente entre objetos de tipo Entidad.
Al igual que los atributos, las relaciones modelan información sobre un objeto (cosas que un objeto debe conocer sobre sí mismo). Estas son propiedades de un objeto. Los atributos son valores de datos. Las relaciones son valores que referencian otros objetos.
Una relación estática se representa en el diagrama de estructura de objetos como una línea sólida entre las clases de objetos, con símbolos de cardinalidad en sus extremos.
Las relaciones pueden etiquetarse para identificar el propósito de la asociación. El diseñador puede optar por:
un nombre para cada dirección de la relación
un nombre para una dirección de la relación
un solo nombre que representa ambas direcciones de la relación
sin nombre
Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir, solo dos clases de objetos, no necesariamente distintas, participan en la relación.
Es posible que entre el mismo par de clases exista más de una relación.
La cardinalidad identifica el número máximo y mínimo de instancias de una clase (objetos) que participan en una relación dada, en el mismo sentido que lo hacen en el modelo entidad-relación.
En el diagrama de estructura de objetos utilizaremos la notación de pata-de-gallo para especificar cardinalidades, aunque puede utilizarse otras como ser pares ordenados, flechas (Bachmann), etc.
Pueden observase las siguientes cardinalidades:
Mínimo 1 - Máximo 1.
Mínimo 0 - Máximo 1.
Mínimo 1 - Máximo N.
Mínimo 0 - Máximo N.
Ejemplo:HerenciaLa herencia es el mecanismo a través del cual los atributos, operaciones, y restricciones definidas para una clase, denominada superclase, pueden ser heredados (reutilizados) por otra clase denominadas subclases.
La herencia utiliza el principio "es un tipo de...".
Una subclase puede redefinir atributos u operaciones heredadas. Adicionalmente, una subclase puede definir nuevos atributos, operaciones, y restricciones.
Se distingue entre herencia simple y múltiple. La herencia simple se da cuando una subclase hereda de una única superclase. En el caso de la herencia múltiple, una subclase puede heredar de varias superclases. La decisión de soportar herencia simple o múltiple ha dado lugar a largos debates conceptuales y metodológicos.
En el actual enfoque, Mainstream Objects de Ed.Yourdon, solo se soporta Herencia Simple.En el diagrama de estructura de objetos, la relación de herencia se representa de la siguiente manera:
EjemploAgregaciónLa agregación es un tipo de asociación fuerte, donde los objetos de una clase se componen de objetos de otra(s) clase(s). Se diferencia de las relaciones estáticas en la fuerza semántica del vínculo. En una relación de agregación un objeto compone otro. En la relación estática existe un vínculo pero no una composición.
La agregación es la aplicación del principio "el todo y sus partes...".
En el diagrama de estructura de objetos, la relación de agregación se representa de la siguiente manera:
EjemploComunicación por mensajesLas asociaciones por comunicación pueden utilizarse para mostrar que objetos de una clase se comunican con objetos de otra clase o de la misma.
Una asociación por comunicación corresponde al conjunto de mensajes que son enviados por los objetos de una clase a los objetos de otra clase o de la misma.
Típicamente, la asociación por comunicación es la única asociación existente entre objetos de los tres diferentes tipos.
En el diagrama de estructura de objetos, la asociación por comunicación se representa de la siguiente manera:
Técnicas Avanzadas de Modelado de Estructura de ObjetosVisibilidad: define que objetos puede acceder y utilizar los atributos y operaciones de un objeto dado. Público: todos
Protegido: solo desde el objeto mismo y operaciones definidas en subclases
Privado: solo desde el objeto mismo
Atributos identificadores: son atributos o grupos de atributos que identifican unívocamente un objeto de una clase. Se corresponde con el concepto de claves del modelo E-R.Atributos derivados: son atributos cuyo valor puede obtenerse a partir de los valores de otros atributos.Relaciones derivadas: relaciones transitivas que se derivan de otras relaciones estáticas. En el diagrama de estructura de objetos las relaciones derivadas se representan de la siguiente manera:
Relaciones Ordenadas: los objetos del extremo "muchos" de una relación se presentan en forma ordenada. Es particularmente útil para especificar que los objetos componentes de un agregado están ordenados. Por ordenado, entendemos que los objetos componentes serán accedidos en una secuencia específica predefinida. En el diagrama de estructura de objetos las relaciones ordenadas se representan de la siguiente manera:
Atributos y operaciones de clase: definen el comportamiento de la clase misma más allá del comportamiento de sus instancias. Los atributos de clase son utilizados para registrar datos comunes a todos los objetos (instancias) de una misma clase.
Las operaciones de clase actúan sobre la clase misma como un objeto. El caso típico son las operaciones Crear y Destruir.
Modelado de Procesos de Negocios y Secuencias de Transacciones.
18.1 Conceptos y propósito del modelo de p. de negocios y sec. de trans.Los requerimientos para una aplicación de negocios deben basarse en las actuales actividades del negocio, que la aplicación deberá soportar.
El Modelo de Procesos de Negocios (BPM) es usado durante el análisis del negocio (análisis del sistema actual) y provee un medio para describir el negocio.
El Modelo de Secuencia de Transacciones (TSM) es usado durante el análisis de requerimientos del negocio y provee un medio para describir la funcionalidad requerida de la aplicaciones para soportar los procesos de negocios.
El enfoque en los procesos de negocio durante el análisis del negocio provee el punto de partida para determinar qué se requiere de la aplicación.
Durante el análisis de requerimientos decidimos qué parte de los procesos de negocio deben computarizarse y describimos dichos requerimientos usando una o más secuencias de transacción (determinación de las fronteras de automatización).
Las secuencias de transacciones modelan que es lo que el usuario requiere de la aplicación (su contenido funcional).
Las secuencias de transacciones proveen la navegabilidad desde los requerimientos del usuario a los objetos y operaciones que implementan dicha funcionalidad.
Las secuencias de transacciones proveen también un medio adecuado para comunicarse con el usuario en un leguaje y nivel de abstracción que él pueda comprender con facilidad.
Como parte del proceso de Diseño Lógico, las secuencias de transacciones son analizadas para identificar como los objetos y sus operaciones proveen la funcionalidad requerida por una secuencia de transacciones.
Posteriormente, durante el proceso de testeo de la aplicación, sirven de base para definir casos de testeos.
Proceso de NegocioUn proceso de negocios es una colección de actividades que toman uno o más tipos de entrada, y crea una salida de valor para el cliente.
Un proceso de negocios describe desde el comienzo al fin la secuencia de eventos requeridos para producir un resultado de negocio significativo.
El cliente puede ser externo o interno a la organización.
Los procesos de negocio típicamente atraviesan los límites de la organización y de sus departamentos internos, evitando la clásica visión de compartimentos estancos. Por este motivo, cualquier modificación drástica a un proceso de negocio implica un cambio en la estructura organizacional.
Como identificar y definir procesos de negocio?· Se identifican los productos/servicios significantes de los que es responsable el negocio y se asocia cada uno de ellos a uno o más procesos de negocios.
· Se identifican las entradas y eventos disparadores que inician cada proceso de negocio y se da un nombre a cada PN.
· Cada PN se describe especificando las actividades de alto nivel que se requieren para producir los productos y servicios.
Secuencia de TransaccionesEl concepto de secuencia de transacciones es muy similar al concepto de Caso de Uso introducido por Jacobson en su metodología OOSE y de amplia difusión actualmente.
Una secuencia de transacciones es conceptualmente similar a un proceso de negocio. La diferencia radica en su alcance. El proceso de negocio se utiliza para comprender y modelar el funcionamiento de la empresa (negocio). Las secuencias de transacciones se utilizan para modelar los requerimientos funcionales de la aplicación que soportará determinados procesos de negocios.
Los procesos de negocio son trasladados en secuencias de transacciones durante el análisis de requerimientos.
El alcance de una secuencia de transacciones es el mismo de un proceso de negocios o de un subproceso muy significativo.
Una secuencia de transacciones puede implicar más de un usuario y función y puede extenderse en el tiempo, esto es no tener resolución inmediata.
El proceso de identificar requerimientos del usuario y secuencias de transacciones puede asistirse con la prototipación de interfaces.
Como identificar y definir secuencias de transacciones?· Identificación a través de actores
· Identificar los actores que se comunicarán con el sistema.
· Para cada actor considerar:
· Cuales son las principales tareas del actor
· Qué accesos (lectura o escritura) requiere el actor del sistema
· Cuando el actor informará al sistema acerca de cambios fuera del sistema
· Cuando el actor será informado de cambios a través del sistema
· Identificación a través de eventos
Consiste en identificar a que eventos externos o temporales debe ser capaz de responder el sistema:
2.1 Confeccionar la lista de eventos.
2.2 Asociar una secuencia de transacciones para cada evento identificada.
Componentes y Herramientas de modelado de procesos de negocios y secuencias de transaccionesPara modelar y documentar procesos de negocios y secuencias de transacciones se utilizan los mismos diagramas y documentos:
· Diagrama de secuencia de transacciones (TSD)
· Descripción textual
· Diagrama de Interacción de Objetos (OID)
· Diagrama de Flujo de Actividad (AFD)
Diagrama de Secuencia de Transacciones (TSD)
Actores
Borde del sistemaSecuencia de Transacción o Proceso de Negocio
Evento
Comunicación entre Actor y Sec.Trans.
Secuencia comúnDescripción Textual: componentes
1) Abstracto: breve descripción del proceso de negocios o secuencia de transacciones.2) Contexto del Negocio: Especifica el resultado de la ST o PN. (productos/servicios)
el cliente de la ST o PN
el valor que gana el cliente con la ST o PN
el evento que inicia la ST o PN
entradas requeridas por la ST o PN
descripción de alto nivel de la ST o PN
requerimientos especiales que controlan la ejecución de la ST o PN
3) Camino estándar y alternativoEs una descripción secuencial de todas las actividades que deben realizarse para alcanzar el resultado.
No se describe el proceso de excepciones.
Para una ST describe las actividades de los actores y que debe hacer la aplicación en orden de servir dichas actividades.
Para un PN describe las actividades de alto nivel del proceso y quién las realiza.
Los caminos alternativos se describen separadamente pero pertenecen a la misma ST o PN. Describen casos inusuales de procesamiento y manejos de excepciones o errores. Esta separación se realiza para facilitar el modelado y lectura de los caminos estándar.
Para modelar y diagramar los caminos estándar y alternativos se utilizan los diagramas de interacción de objetos (OID) y los diagramas de flujo de actividad (AFD).
4) ActoresEn el BPM representan los profesionales del negocio y sistemas de computación involucrados en producir un producto o servicio.
En el TSM representan agentes externos que interactúan con la aplicación. Pueden representar usuarios humanos o interfaces con otros sistemas.
Cada actor es usado para modelar un rol. Un rol puede ser desempeñando por un usuario individual o grupo de usuarios.
Subdivisión de procesos de negociosLos PN pueden ser subdivididos en subprocesos. Las dos formas principales para realizar esto son:
Especialización: del PN en distintos tipos que producen el mismo resultado pero tienen diferentes conjuntos de actividades.Particionamiento: del PN a lo largo del eje de tiempo en una secuencia de subprocesos.Modelado de Interaccion de Objetos
Conceptos y propósito del modelado de interacción de objetos.Objetivo: El modelo de interacción de objetos modela la manera en que colaboran los objetos de un sistema para proveer la funcionalidad descrita en una secuencia de transacciones. Su utilidad primaria se da durante la etapa de diseño lógico.
Interacción de Objetos: se produce cuando un objeto envía un mensaje a otro con el objetivo de utilizar (requerir) la funcionalidad de la operación invocada por el objeto receptor del mensaje. El modelo de interacción de objetos provee el enlace las descripciones de las secuencias de transacciones y las especificaciones de operaciones elementales a nivel de objetos.
Asisten en la identificación de clases de objetos y operaciones requeridas, considerando como una determinada funcionalidad debe distribuirse en operaciones de diferentes clases de objetos (responsabilidades de objetos), y como los objetos deben colaborar para proveer la funcionalidad descrita en las secuencias de transacciones.
La herramienta de modelado fundamental para el modelado de interacción de objetos es el diagrama de interacción de objetos (OID). Normalmente se usa un OID para cada secuencia de transacciones concentrándose en el camino estándar.
Utilización del modelado de interacción de objetosModelado de Procesos de Negocios: es una técnica adicional que puede utilizarse para comprender un proceso de negocios en particular. Se considera al sistema como una "caja negra". Se lo representa como un actor (interface de máquina).Análisis de Requerimientos: No es muy utilizado. El propósito de esta etapa es definir requerimientos, no diseñar.Diseño lógico: Se utiliza un OID para cada secuencia de transacciones definida en el análisis de requerimientos, para determinar con claridad que clases, operaciones y responsabilidades se necesitan. Se mira dentro de la "caja negra" (tal como se la ve en el modelo de proceso de negocio) y se determina que objetos participan para implementar la funcionalidad requerida del sistema.Herramientas de modelado.
Diagrama de interacción de objetos para un proceso de negocios
Elementos:· Actores en la parte superior del diagrama. Pueden ser humanos o sistemas vistos como cajas negras.
· Una línea vertical asociada a cada actor.
· Requerimientos o eventos enviados por un actor a otro. Se representan por flechas. Se utilizada una sola flecha para representar el estímulo y la respuestra implícita.
· Etiquetas en el márgen izquierdo representando links a actividades de un diagrama de flujo de actividades.
Diagrama de interacción de objetos para una secuencia de transacciones
Elementos· Barra vertical a la izquierda representa el límite del sistema.
· Se acompaña con la descripción narrativa de la secuencia de transacciones a la izquierda.
· Una flecha proveniente desde el límite representa un requerimiento externo generado por un actor. Es conveniente que los requerimientos / respuestas de este tipo se representen por flechas individuales.
· Operaciones: se representan por rectángulos alargados sobre los ejes correspondientes a los objetos que las realizan. Permite visualizar que mensajes dispara una operación. La longitud de la barra no representa duración.
· Actividades: bloques de eventos que siempre ocurren en una determinada secuencia. Dichas actividades que pueden ocurrir en paralelo, condicional, o iterativamente, pueden modelarse con un diagrama de flujo de actividad asociado.
Casos Especiales· Invocación de Operaciones "in-self"
A menudo una operación de un objeto invoca a otra operación de la misma clase. Esto puede representarse de la siguiente forma:
· Múltiples objetos de una misma clase
Se representa la clase más de una vez.
· Secuencias comunes
Usualmente se dibujan diagramas por separado para las secuencias comunes y su invocación se representa con una flecha punteada.
Diagrama de flujo de actividad. Los OID no muestran decisiones, iteraciones, o la posibilidad de que partes del procesamiento puedan realizarse en secuencias aleatorias o concurrentemente. Una manera de describir esto es con descripciones textuales en el margen izquierdo del OID, o utilizando diagramas de flujo de actividad (AFD). Los AFD son un tipo particular de los clásicos flowcharts.
Actividad: es una secuencia de interacciones entre objetosEl alcance de una actividad queda normalmente definido por el hecho de que una secuencia de interacciones dada es condicional, iterativa, o pueda ocurrir antes o después de otras secuencias de interacciones.
Simbología de los diagramas de flujo de actividad
ObservacionesUna AFD puede incluir actividades que no estén en un camino estándar pero que aparezcan en un camino alternativo.
Pueden existir actividades sin interacciones asociadas que se utilizan para clarificar la lógica del flujo.
Puede utilizarse un AFD sin OID asociado simplemente para describir la lógica del flujo en un camino estándar/alternativo.
Técnicas avanzadas de modelado.Generalmente, un OID es utilizado para modelar cada secuencia de transacciones. Es posible más de un OID por secuencia de transacciones y se describen a continuación dos enfoques alternativos:
Usando AFD para modelar operaciones del sistemaLos AFD pueden ser utilizados en combinación con los OID. En un AFD cada bloque normalmente representa un grupo de eventos que ocurren siempre en la misma secuencia. Otra opción es mostrar un bloque en un AFD para representar cada posible estímulo externo para una secuencia de transacciones. Tal estímulo externo (u operación del sistema) puede ocurrir a menudo en secuencias aleatorias o en secuencias alternativas. Un OID puede desarrollarse para cada uno de tales bloques u operaciones del sistema.
Sin embargo se recomienda utilizar un OID simple para toda la secuencia de transacciones siempre que sea posible, debido a que esto brinda una visión general para todo el proceso requerido.
Diagramas de interacción de objetos, secuencias de transacciones y escenariosGeneralmente se desarrolla un solo OID por cada secuencia de transacciones. Este diagrama muestra un caso general omitiendo caminos alternativos inusuales. No muestra un escenario de ejecución que pueda ocurrir en una ocasión específica. En casos complicados, puede ser útil desarrollar OIDs alternativos representando los caminos alternativos típicos.
Modelo de Ciclo de Vida de Objetos
Conceptos y propósito del modelo de ciclo de vida de objetos.El modelo de ciclo de vida de objetos se utiliza para describir los aspectos dinámicos de los objetos.
El modelo de ciclo de vida de objetos modela lo que ocurre dentro de los objetos de una clase: estados, cambios de estado, y eventos que producen dichos cambios de estado.
El estado de un objeto de una clase está dado por el conjunto de valores de sus atributos en un instante dado de tiempo.
Durante su ciclo de vida, desde que son creados hasta que son destruidos, los objetos atraviesan por diferentes estados.
La importancia de estudiar el ciclo de vida de los objetos y de sus estados, se debe a que muchos objetos exhiben comportamientos estado-dependientes.
Es especialmente importante reconocer comportamientos de objetos que son dependientes del tiempo y del estado previo, ya que pueden agregar una complejidad considerable a la aplicación.
Ciertas operaciones y/o atributos pueden ser válidos solo en ciertos estados.
Sólo deben modelarse los estados de un objeto que son relevantes al dominio de problema que se está modelando.
Las transiciones de estados de un objeto son causadas por la recepción de un evento interno o externo al sistema.
El estado que asume un objeto luego de recibir un evento depende del estado actual, del evento recibido, y opcionalmente del valor de una condición de guarda.
Cuando un objeto recibe un evento ejecuta una acción (que corresponde con una operación) asociada con una transición.
Al fin o durante la ejecución de dicha acción, el objeto produce el cambio de estado. Puede darse que el estado final sea el mismo que el inicial.
Utilización del modelo de ciclo de vida de objetosSiempre que se agrega una nueva clase al OSM es importante examinar se la misma presenta estados significantes para los objetos de la misma. Si es así puede utilizarse el modelo de ciclo de vida en orden de comprender correctamente el ciclo de vida de dichos objetos.
El modelo de ciclo de vida es útil en las etapas de análisis del negocio y de requerimientos para obtener una clara comprensión del ciclo de vida de los objetos claves descubiertos y de los caminos estándar y alternativos involucrados.
Herramientas de modelado. Diagrama de ciclo de vida de objetos. La herramienta que se utiliza para modelar el ciclo de vida de objetos es el diagrama de ciclo de vida de objetos (OLD). Un OLD se aplica solo a una clase de objetos.
El OLD representa:
como los objetos son creados
como los objetos son destruidos
como los objetos cambian a través del tiempo
que estados típicamente asume un objeto
que eventos causan cambios de estado
que acciones realiza un objeto cuando recibe un evento que produce un cambio de estado.
Componentes del OLD
Técnicas avanzadas de modelado.
Modelo Global del Sistema
Conceptos y propósito del modelo del modelo global del sistema.El modelo global del sistema posibilita tener una visión general del modelo de estructura de objetos del sistema, asistiendo en el manejo de la complejidad.
Las principales razones para utilizar un modelo global del sistema son:
Posibilita el particionamiento de una tarea de análisis o desarrollo. Para grandes sistemas, subsistemas pueden ser asignados a diferentes equipos o subproyectos.
Puede utilizarse para definir unidades de entrega, p.e., unidades funcionales (módulos) que deban entregarse al usuario en sucesivas fechas de liberación, o componentes de producto.
Puede utilizarse para definir unidades distribuibles.
Puede utilizarse para validar el diseño de un sistema y asegurar que está bien diseñado para soportar el cambio.
Incluye un diagrama (el diagrama de visión general del sistema) que puede utilizarse para producir una visión general de un modelo del análisis o de un subsistema, asistiendo con la presentación de un modelo o subsistema a un nivel de visión general.
Una característica importante del modelo global es que permite el modelado de interfaces entre subsistemas. Esto se logra modelando los servicios que un subsistema ofrece para ser utilizados por otro subsistema.
ConceptosEl modelo global implica la subdivisión del espacio de problema en componentes. En un enfoque de desarrollo orientado a objetos, esto se alcanza agrupando clases de objetos. El modelado orientado a objetos difiere aquí de las técnicas estructuradas, en que en estas, los subsistemas usualmente agrupan funciones, no objetos.
Las secuencias de transacciones no necesariamente residen en un único subsistema. Pueden requerir el soporte de objetos pertenecientes a más de un subsistema o componente.
El espacio del problema y sus componentesDurante la etapa de análisis del negocio, el espacio del problema es el dominio del negocio, y podemos optar por dividir dicho dominio en áreas sujetos. Cada área sujeto contiene clases de objetos semánticamente relacionadas unas a otras, vinculadas con el mismo sujeto.
Durante el desarrollo, el espacio del problema es el sistema o subsistema que se construye. Esto también puede ser subdividido en submodelos o subsistemas.
Los submodelos son utilizados principalmente con propósitos de presentación.
Los subsistemas son definidos por razones técnicas como ser: definición de unidades de distribución, y definición de módulos, importante para validar y preservar la mantenibilidad del sistema.
Otro uso del particionamiento es la subdivisión arquitectural, la cual es particularmente importante durante el diseño físico. Se recomienda la división de todo sistema en seis subsistemas arquitecturales:
El componente dominio de problema: es el más importante y en el cual nos concentramos durante el análisis de requerimientos y el diseño lógico.
El componente de interfaz humana: introducido en el diseño lógico.
El componente de interfaz externa: introducido durante el diseño lógico.
El componente de administración de datos: introducido durante el diseño físico.
El componente de administración de tareas: introducido durante el diseño físico.
El componente de servicio de utilidades: introducido durante el diseño físico.
Definición del alcance de un subsistemaBásicamente, las clases de objetos que tienen un alto grado de interdependencia y sirven a un propósito común, deben asignarse al mismo subsistema.
Usualmente, jerarquías de herencia y agregación, deben ser asignadas completamente a un subsistema.
Debe notarse que si existen objetos que son requeridos por diferentes subsistemas, entonces dichos objetos no deben asignarse a un subsistema.
ServiciosUn subsistema provee sus servicios vía una interface, la cual es un conjunto de operaciones que los clientes de un subsistema pueden utilizar.
Es útil estas operaciones en servicios. Cada servicio agrupa operaciones relacionadas que tienen un propósito común, por ejemplo, dibujar figuras, manejo de e-mail, etc.
Los servicios provistos por un subsistema a otro, o a actores, pueden identificarse determinando que comunicaciones son posibles entre subsistemas, y agrupar estas en servicios. Es conveniente que esto se realice durante el diseño lógico, cuando las operaciones han sido definidas.
Los subsistemas pueden vincularse en relaciones cliente-servidor o compañero-a-compañero. En este último caso, un subsistema puede ser cliente y servidor a la vez.
Particiones verticales y horizontalesUn sistema puede ser particionado horizontalmente (en capas) o verticalmente. Las particiones verticales son usadas para subdividir la funcionalidad de la aplicación, mientras que las particiones horizontales son particularmente útiles para aislar las aplicaciones de capas de software de menor nivel como ser sistemas operativos, bases de datos o hardware. Este enfoque por capas (layers) asegura la portabilidad de una aplicación.
En el siguiente ejemplo el dominio de problema se divide en cuatro particiones verticales. El componente de administración de datos es una partición horizontal, la cual existe para aislar a la aplicación del software de base de datos utilizada.
Diagrama de Modelo Global del Sistema
Componentes del diagramaActor: personas que interactúan con el subsistema o interfaces con otros subsistemas.Bordes del sistema: se representan con un rectángulo en línea gruesa. Los actores se dibujan fuera del rectángulo, y los subsistemas dentro.Subsistema: se representan con un rectángulo redondeado.Servicios: se representan como semicírculos dentro del rectángulo correspondiente al subsistema.Actor usando un servicio: se representa como una flecha que vincula al actor con el servicio que usa.Conceptos avanzados
Uso de Clases de Objetos para encapsular subsistemasEs posible encapsular la funcionalidad de un sistema utilizando object wrapper (envoltura). Esto puede ser muy útil para permitir la utilización de un sistema no orientado a objetos desde un sistema orientado a objetos. Esto se realiza definiendo un objeto interface el cual puede llamarse para invocar las funciones provistas por el sistema encapsulado. Solo dicho objeto interface necesita conocer el funcionamiento interno del sistema que encapsula.
También es posible utilizar una clase de objetos para encapsular el acceso a un sistema orientado a objetos. Si no se utiliza esto, todos los mensajes provenientes del exterior del subsistema, deben dirigirse directamente a la clase de objetos correspondiente dentro del mismo, lo que implica que los actores que necesiten utilizar la funcionalidad del subsistema, deban conocer la estructura interna del mismo.
Utilizando un objeto interfaz, se oculta la complejidad interna del subsistema y es posible definir una interfaz sencilla para los clientes externos.
Ciclo de Desarrollo Orientado a ObjetosEn los capítulos anteriores se introdujeron los conceptos fundamentales del paradigma de orientación a objetos, como así también los modelos fundamentales que se utilizarán en la presente metodología de OOAD.
En los próximos capítulos se examinará el proceso de desarrollo orientado a objetos, es decir que actividades deben llevarse a cabo, que tareas deben realizarse, y que entregables deben producirse en cada etapa.
En esta unidad se realiza una presentación a nivel general que se desarrolla en detalle en las unidades siguientes.
Fases del ciclo de desarrollo O.O.Este enfoque un ciclo de vida tradicional compuesto por las siguientes etapas:
Definición del proyecto y planificación: aquí es donde se define el alcance y límites del proyecto. Se realizan los estudios de factibilidad y relaciones costo/beneficio.Análisis
Análisis del Negocio: aquí es donde se modela el negocio o parte del mismo en orden de comprender la naturaleza del mismo, como se realizan actualmente las actividades, y como los usuarios desean que se realicen en el futuro. Provee una comprensión preliminar de áreas específicas del negocio a ser informatizadas. Esta etapa también es conocida como estudio del sistema actual en otras metologías.Análisis de requerimientos del sistema: aquí es donde se establece con claridad las capacidades requeridas para el nuevo sistema a ser desarrollado. Estas capacidades son documentadas de modo tal que los desarrolladores tengan una especificación clara sobre la que trabajar y para validar los resultados obtenidos.Diseño
Diseño Lógico: aquí es donde los desarrolladores del sistema identifican los componentes de software/hardware necesarios para satisfacer los requerimientos, como así también especifican las relaciones arquitecturales entre dichos componentes. El diseño lógico debe evitar detalles técnicos específicos requeridos para mapear el diseño en un entorno de implementación específico.Diseño Físico: aquí es donde se toman decisiones técnicas considerando arquitecturas de hardware específicas, sistemas de bases de datos, lenguajes de programación, utilización de paquetes de middleware o paquetes GUI, etc. Aquí también se toman decisiones con respecto a características de implementación como ser arquitectura cliente/servidor, distribución de objetos, etc.Construcción
Desarrollo: aquí es donde un diseño físico es implementado en un lenguaje de programación, o entorno específico de desarrollo.Prueba: se realizan testes del software para validar su correcto funcionamiento y detectar fallas que deban ser depuradas.Documentación: desarrollo de documentación técnica sobre la aplicación, manual de usuario, manual de procedimiento, etc.Aprobación
Operación y MantenimientoUso de los distintos modelos.A continuación se sumariza el uso de los distintos modelos en las diferentes etapas del ciclo de desarrollo:
Análisis del NegocioModelo de Estructura de Objetos: es utilizado para identificar y modelar los objetos del dominio del negocio (objetos entidad). Preguntas fundamentales son: "Qué objetos necesitamos en orden de realizar los procesos de negocio identificados?", "Qué deben conocer estos objetos, y que deben ser capaces de realizar?", "Cómo interactúan estos objetos entre sí?".Modelo de procesos de negocios y secuencias de transacciones: pueden utilizarse para describir los procesos del negocio en una forma compatible con la descripción de secuencias de transacciones de la siguiente fase de análisis de requerimientos.Modelo de Ciclo de Vida de Objetos: pueden proveer una mayor comprensión sobre el comportamiento dinámico de los objetos del negocio, durante su vida. Su utilización dependerá de la complejidad de los objetos del negocio en estudio, y en algunos casos puede ser innecesaria su utilización.Análisis de RequerimientosModelo de estructura de Objetos: contiene únicamente objetos entidad, y se agrega mayor detalle al modelo describiendo relaciones, herencia, agregación, atributos y restricciones aplicables a las clases de objeto entidad identificada.Secuencias de Transacción: son utilizadas para describir la funcionalidad esperada del sistema.Modelo de Ciclo de Vida de Objetos: se utiliza para aquellos objetos con ciclos de vida complejos.Modelo Global del Sistema: es utilizado para sistemas grandes cuando se necesite particionar en subsistemas.Diseño LógicoSecuencias de Transacciones: definidas en la etapa anterior, son examinadas aquí para determinar objetos interfaz y de control donde es apropiado.Diagramas de Interacción de Objetos: se dibuja uno por cada secuencia de transacción describiendo eventos e interacciones entre objetos necesarios para soportar la secuencia de transacción.Operaciones: son definidas con descripciones informales de su comportamiento.Diagramas de Ciclo de Vida: son creados y extendidos donde sean necesarios.Modelo Global: se definen subsistemas y se dibujan diagramas globales donde sea requerido con propósitos organizacionales, manejo de complejidad, y presentación.Diseño FísicoDurante la etapa de diseño físico se llevan a cabo las siguientes actividades:
El entorno para el sistema debe ser determinado, y las decisiones tomadas inicialmente deben finalizarse. Esto incluye determinación de lenguaje de programación, sistema operativo, Dbms, s.o. de red, hardware, tipo de interface de usuario, librerías de clases, frameworks, y patrones de diseño.
La administración de tareas y distribución de objetos/funciones debe finalizarse.
La definición de tipos de atributos debe finalizarse.
Se implementan las relaciones (p.e. en forma de punteros)
Decisiones relativas a implementación de restricciones debe finalizar, dependiendo del lenguaje de programación, GUI-builder, y/o Dbms utilizados.
Debe finalizarse la interface de usuario.
Deben tomarse decisiones sobre el manejo de persistencia de objetos, involucrando posiblemente un mapeo entre objetos y Dbms relacionales. Esto puede implicar la implementación de una "capa de acceso" en el sistema, o bien puede manejarse con un producto comercial.
Se desarrollan objects wrappers para todos los componentes no orientados a objetos que serán utilizados por la aplicación.
Se realiza la codificación de todas las operaciones que deban realizarse.
El rol de las versiones en un proceso de desarrollo aditivoEl proceso de OOAD descripto aquí es aditivo, esto significa que los resultados de cada fase son utilizados como entrada para la siguiente fase, donde se realizan actualizaciones y extensiones. Esto contrasta con otros enfoques como el estructurado que es carácter transformacional, donde los DFD del análisis son transformados en Diagramas de Estructura durante el diseño.
Debido a esta naturaleza aditiva del proceso, es técnicamente innecesario retener versiones de resultados de las primeras fases del desarrollo. Sin embargo muchas veces por cuestiones contractuales u organizacionales se retienen copias de los modelos del análisis de requerimientos. A menudo, este modelo representa un contrato entre los usuarios y los desarrolladores. El modelo se retiene en orden de proveer un mecanismo para validar que el sistema entregado cumple con las especificaciones iniciales.
Arquitectura de Seis ComponentesComo se ha mencionado, es útil y común dividir sistemas grandes y complejos en subsistemas para facilitar su desarrollo. Pero además es útil dividir un sistema de cualquier tamaño en subsistemas basados en consideraciones arquitecturales que son específicamente relevantes durante la fase de diseño físico de la aplicación.
El presente enfoque de desarrollo orientado a objetos recomienda la siguiente arquitectura de seis componentes:
Componente Dominio de Problema (PDC)
Componente de Interacción Humana (HIC)
Componente de Interfaces Externas (EIC)
Componente de Administración de Datos (DMC)
Componente de Administración de Tareas (TMC)
Componente de Servicio de Utilidades (USC)
En la unidad de Diseño Físico se discuten en detalle cada uno de estos componentes.
Análisis del Negocio El análisis del negocio es utilizado para modelar parte o toda la empresa, en orden de comprender la naturaleza del negocio y como se llevan a cabo sus procesos.
El análisis del negocio se concentra en dos aspectos:
Modelado de los Objetos que soportan el negocio (business objects)
Modelado de los Procesos del Negocio (business processes)
Actividades del Análisis del NegocioLas siguientes actividades son llevadas a cabo durante el análisis del negocio:
Identificación de los Objetos del Negocio. Son los objetos más importante del tipo entidad. Otros objetos entidad adicionales son agregados durante el análisis de requerimientos y durante el diseño lógico.
Modelado del ciclo de vida para cada objeto del negocio que tenga un ciclo de vida complejo relevante al problema a manejar.
Modelado de los procesos de negocio. Implica la identificación de los procesos de negocio y la obtención de una comprensión de alto nivel de los flujos de trabajo (workflows: secuencias de actividades y eventos) de dichos procesos, y de los agentes (humanos o máquinas) que interactúan para alcanzar un resultado significativo.
Chequeo de consistencia y validación del modelo producido.
El alcance del análisis del negocio (dominio del negocio o dominio del problema) normalmente se determina durante la fase de definición del proyecto.
Modelado de Objetos del NegocioEl modelado de objetos del negocio es la primera definición del modelo de estructura de objetos para la aplicación.
El modelado de objetos puede realizarse en simultáneo con el modelado de procesos de negocios. Sin embargo se recomienda comenzar modelando los objetos ya que son la esencia de este enfoque.
El modelo de estructura de objetos producido en esta fase será extendido en fases subsiguientes. Sin embargo es muy similar al de la fase de análisis de requerimientos. Las principales diferencias residen en:
El alcance de los objetos del negocio suele ser mayor, pues puede involucrar objetos de negocio que no son relevante al sistema computarizado.
El modelo de objetos del negocio suele ser menos detallado. Usualmente solo objetos del la realidad son modelados. Durante el análisis de requerimientos, objetos menos obvios (p.e. clases que representan eventos) son identificados.
En el análisis del negocio, el modelo contiene los objetos del negocio, sus principales atributos y relaciones estáticas relevantes. Durante el análisis de requerimientos, pueden agregarse objetos entidad adicional, con un conjunto de atributos más detallado y las operaciones básicas para los objetos del modelo.
La definición de jerarquías de herencia y estructuras de agregación se difieren hasta el análisis de requerimientos.
Pasos en el modelado de objetos de negocioEl modelado de objetos de negocio incluye los siguientes pasos:
· Determinar objetos del negocio candidatos
· Abstraer los objetos candidatos en clases y definir el propósito de cada clase de objetos.
· Determinar las relaciones estáticas entre los objetos del negocio.
· Nominar dichas relaciones y asignar cardinalidades.
Qué modelar?Los objetos pueden ser identificados respondiendo la pregunta: "Qué cosas (reales o abstractas) considera la empresa y sobre la que guarda datos?".
El énfasis en esta etapa es identificar objetos de la realidad (personas, lugares, cosas o eventos) que están dentro del dominio del negocio.
Modelado de Ciclo de Vida de ObjetosEl principal propósito del modelado de ciclo de vida de objetos es asistir en la comprensión de objetos con ciclos de vida complejos.
Es importante reconocer cualquier comportamiento del objeto que sea dependiente del tiempo y del estado del mismo, ya que esto agrega complejidad a la aplicación.
El uso de diagramas de ciclo de vida facilita la comprensión y comunicación con usuarios.
Cuando modelar ciclos de vida?Debe dibujarse diagramas de ciclos de vida solo para objetos que poseen comportamientos dependientes del tiempo y de su estado interno. Para determinar esto, debe tomarse cada clase de objetos y analizarla por separado. Deben identificarse los eventos que pueden afectar a un objeto de la clase y determinar si la reacción a dichos eventos puede variar según el estado interno del objeto.
Como modelar ciclos de vida de objetosEl modelado de ciclos de vida incluye los siguientes pasos:
· Determinar cuándo debe modelarse el ciclo de vida para una clase de objetos, según lo expuesto en el punto anterior.
· Identificar el primer estado del objeto.
· Identificar que evento lleva a un objeto a su estado inicial (usualmente la creación del mismo).
· Identificar los eventos que pueden causar transiciones de estado desde el primer estado, y a que otros estados puede cambiar el objeto. Identificar que actividades se llevan a cabo durante la transición de estado.
· Identificar el estado final del objeto.
Básicamente el alcance del modelado de ciclo de vida de objetos es el mismo para la actividad de análisis del negocio como para el análisis de requerimientos.
Modelado de Procesos de Negocio.El modelado de procesos de negocio es usado para comprender y documentar las actividades de alto nivel realizadas por los profesionales del negocio para alcanzar los objetivos del dominio del negocio.
Esta comprensión de alto nivel de cómo trabaja la empresa es necesaria como un paso preliminar para asegurar que las parte del negocio afectada por la aplicación en desarrollo es comprendida antes de que el análisis de requerimientos sea llevada a cabo.
Pasos del modelado de procesos de negocio· Identificar los procesos de negocio.
· Subdivisión de los procesos de negocio. Los procesos de negocio pueden subdividirse identificando especializaciones o particionándolos a lo largo del tiempo en subprocesos.
· Descripción de los procesos de negocio. La descripción de un proceso de negocio implica la descripción de la naturaleza del mismo como de las actividades que lo constituyen.
Identificación de procesos de negocioLos procesos de negocio pueden identificarse de dos maneras:
· Considerar Quién es el Cliente, y Qué productos o servicios requiere. Verificar que dichos productos/servicios sean de valor para el cliente. La producción de dichos productos/servicios implicarán uno o más procesos de negocio.
· Considerar que eventos la empresa debe ser capaz de tratar, y que procesos implican el tratamiento de dichos eventos.
Como describir procesos de negocioLos siguientes mecanismos pueden utilizarse para describir procesos de negocio:
· Una identificación del evento inicial y del producto(s) o servicio(s) del proceso de negocios.
· Una descripción textual de las actividades involucradas en el proceso de negocio.
· Una descripción de la secuencia de interacciones entre agentes (humanos o máquinas) que es requerida para producir el producto/servicio requerido. Para esta descripción pueden utilizarse diagramas de interacción de objetos.
· Una descripción de los caminos de ejecución involucrados en el proceso, mostrando los puntos en los cuales se inician dichos caminos: alternativos, actividades paralelas, e iteraciones. Para esto se pueden utilizar diagramas de flujo de actividad.
Análisis de RequerimientosEl proceso de análisis de requerimientos debe producir una definición clara de los requerimientos para el nuevo sistema desde la cual puedan trabajar los desarrolladores y contra la cual puedan validarse los resultados.
Durante el análisis del negocio se producen un modelo de la forma en que actualmente funciona la empresa. Durante el análisis de requerimientos, se modela cómo la empresa operará utilizando el nuevo sistema.
Un objetivo adicional del análisis de requerimientos es proveer a los profesionales del negocio de la oportunidad de cambiar la manera en que actualmente funciona la empresa.
El punto de arranque el análisis de requerimientos depende del contexto en el cual una aplicación es desarrollada. Cuando el dominio del negocio para la aplicación es pequeño y bien comprendido, entonces la fase de análisis del negocio es muy breve. El análisis de requerimientos parte de los modelos del análisis del negocio que contienen muy poco detalle. En este caso es casi como partir desde cero
Cuando se ha realizado un análisis del negocio extenso, entonces los modelos obtenidos constituyen la base sobre la cual se continúa trabajando realizando los agregados y extensiones pertinentes.
Actividades del Análisis de RequerimientosDurante el análisis de requerimientos se llevan a cabo las siguientes actividades:
· Definición de secuencias de transacciones basadas en los procesos de negocio.
· Expansión o definición del modelo de estructura de objetos para objetos entidad.
· Dibujo de diagramas de ciclo de vida para objetos entidad.
· Particionamiento del espacio de problema.
El proceso de producción de la especificación de requerimientos comprende dos corrientes principales:
El análisis de la funcionalidad requerida del nuevo sistema. Esto se documenta utilizando secuencias de transacción.
El análisis de la estructura de objetos entidad para soportar dicha funcionalidad. Esto es documentado utilizando el modelo de objetos.
Estas dos actividades pueden realizarse en paralelo, y no existe un criterio estricto sobre qué modelo debe desarrollarse antes.
Para sistemas "intensivos en datos", el modelado de las relaciones de objetos y atributos es particularmente importante.
Para sistemas "algorítmicamente intensivos" o en proyectos de reingeniería de negocios, el modelado de la funcionalidad, representado por secuencias de transacción en combinación con un modelo de objetos, puede ser más importante.
Definición de secuencia de transacciones.El modelado de secuencias de transacciones incluye los siguientes pasos:
· Identificación de las secuencias de transacciones requeridas.
· Definición del contexto del negocio.
· Descripción del camino estándar.
· Descripción de caminos alternativos.
Identificación de secuencias de transaccionesIdentificación a través de actoresIdentificar los actores que se comunicarán con el sistema. Los actores pueden ser personas humanas o interfaces con otros sistemas.
Para cada actor identificado considerar que es lo que actor realizará con el sistema, utilizando secuencias de transacciones para describir esto. Tal como lo sugiere Jacobson es útil considerar:
Cuáles son las principales tareas del actor
Qué accesos (lectura o escritura) requiere el actor del sistema
Cuando el actor informará al sistema acerca de cambios fuera del sistema
Cuando el actor será informado de cambios a través del sistema
Identificación a través de eventosConsiste en identificar a que eventos externos o temporales debe ser capaz de responder el sistema. Para ello se siguen los siguientes pasos:
Confeccionar la lista de eventos. Cada evento externo al cual el sistema debe responder es listado, incluyendo eventos temporales.
Asociar una secuencia de transacciones para cada evento identificado. Inicialmente se asocia una secuencia de transacción por cada evento. Puede haber más de una respuesta para un evento. En tal caso se requiere una secuencia de transacciones para cada respuesta.
Relación entre actores y eventos externosEl enfoque de particionamiento por eventos describe eventos del negocio los cuales se originan a menudo fuera de la compañía. El generador de dichos eventos, a menudo no se comunica en forma directa con el sistema, sino que lo hace a través de un actor que hace de agente o intermediario. Por lo tanto, el actor que inicia una secuencia de transacciones lo hace en respuesta a un evento, no es él quién lo origina.
Sin embargo hay casos, como los cajeros automáticos, en los cuales el actor es quién origina el evento.
Uso de Diagramas de Secuencias de TransaccionesLos actores y secuencias de transacciones identificados pueden documentarse utilizando diagramas de secuencias de transacciones. Estos diagramas muestran el actor que inicia la interacción con el sistema.
Alcance de una secuencia de transaccionesUna secuencia de transacciones debe cubrir una secuencia de eventos lógica u cohesiva. Es posible que dicho flujo de eventos se extienda en el tiempo por varios días.
Para decidir el alcance de una secuencia de transacciones pueden seguirse los siguientes criterios:
· La secuencia de transacciones debe tener el alcance tan grande como sea posible manejarla (en orden de asegurarnos de que la secuencia de procesamiento completa es manejada satisfactoriamente). El proceso de negocios completo es el alcance por defecto para la secuencia de transacciones.
· Cuando se necesite subdividir la secuencia de transacciones para poder tener unidades razonables para manejar, debemos elegir unidades que el usuario acepte y perciba como realizando un objetivo de interés desde el punto de vista del negocio. Estas unidades pueden corresponderse con las mayores opciones del menú de la aplicación o comandos del sistema.
El alcance de una secuencia de transacciones debe realizar una tarea la cual el profesional del negocio la reconozca como una unidad cohesiva. Esto difiere de la perspectiva funcional donde las acciones son empaquetadas en comandos del sistema u opciones de menú pero sin referenciar la secuencia en la que deben utilizarse dichas opciones.
Una secuencia de transacciones describe acciones en la secuencia en que se usan, sin especificar si estas acciones deben empaquetarse en una única función del sistema o en varias.
Descripción de caminos estándar y alternativosLos caminos estándar y alternativos son descritos utilizando descripciones las descripciones textuales explicadas en el capítulo dedicado al modelado de procesos de negocios y secuencias de transacciones.
En la secuencia de transacciones se describe que es lo que el sistema debe hacer, como interactuará con los actores, y cuál es el contexto del negocio para dicha interacción. La secuencia de transacciones como se logra esto dentro del sistema. Esto es descripto en el modelo de estructura de objetos donde se especifican operaciones elementales a nivel de objeto.
Los caminos alternativos son descriptos separadamente por un número de razones. Una razón es que esto permite que se lea en camino estándar sin distracciones por los detalles de casos inusuales o manejo de errores. Otra razón es que la separación del camino estándar de los alternativos ayuda al desarrollador a concentrarse en los tratamientos principales del procesamiento normal de las transacciones.
Ejemplos de funcionalidad que puede ser descripta como caminos alternativos son:
Partes opcionales de la secuencia de transacciones
Cursos alternativos de eventos que rara vez ocurren
Sub-cursos separados que solo se ejecutan en ciertos casos
Manejo de errores
Identificación y definición de secuencias comunesSecuencias que son comunes a varias secuencias de transacciones pueden ser identificadas y descriptas como secuencias de transacciones separadas, llamadas secuencias comunes. Tanto las secuencias de transacciones y las secuencias comunes pueden utilizar secuencias comunes, para describir caminos estándar como alternativos.
A menudo las secuencias comunes se asocian con jerarquías de herencia, tanto de clases de objetos como de actores. A menudo las secuencias de transacciones individuales describen lógica que se aplica a las subclases de objetos mientras que la secuencia común describe lógica que se aplica al nivel de superclase y por lo tanto es común a todas las subclases.
Jerarquías de actoresLos actores representan roles de usuarios. En casos donde diferentes tipos de actores comparten capacidades comunes, puede ser útil definir jerarquías de actores. Por ejemplo, un administrador y un usuario normal del sistema pueden tener ciertas capacidades comunes las que pueden modelarse utilizando una superclase de actor. Cada actor hereda de la superclase actor.
Las jerarquías de actores son necesarias cuando se encuentra lógica común en dos secuencias de transacciones distintas que se comunican con dos actores diferentes. Cuando se separa esta lógica común en una secuencia común, ésta necesita comunicarse con los dos diferentes actores. Dichos actores juegan un rol idéntico con respecto a la secuencia común, y puede considerarse como un único actor frente a esta secuencia común. En este caso es conveniente definir una superclase actor desde la que los dos actores originales heredan y con quienes la secuencia común se comunica.
Modelando interfaces de usuario e interfaces externasEn los puntos donde los actores inician o se comunican con secuencias de transacciones, existe a menudo intercambio de datos. El actor suministra datos al sistema, o el sistema brinda datos al actor.
Es importante identificar que datos son pasados. Estos datos pueden ser descriptos utilizando clases de objetos interface (que se corresponde con pantallas, ventanas, reportes, etc.). Es necesario identificar clases de objetos interfaces cuyos datos son suministrados a los actores o recibidos desde ellos.
El proceso de definición de interfaces puede asistirse con el modelado de prototipos. Sin embargo debe aclararse que el modelado final de los objetos interfaces debe posponerse hasta la etapa de diseño lógico.
Expandiendo el modelo de estructura de objetosEl principal objetivo del modelado de estructura de objetos en esta fase es producir un modelo completo de objetos entidad. Dependiendo en cuan detallado fue el análisis del negocio, puede que solo sea necesario expandir y refinar el modelo de estructura de objetos.
Pasos en el modelado de estructura de objetos para el análisis de requerimientos· Determinar los objetos entidad candidatos y agregarlos al modelo.
· Agregar relaciones estáticas entre objetos entidad.
· Completar la definición básica para cada objeto entidad:
Definiendo el conjunto básico de atributos
Definiendo atributos de identificación
Definiendo restricciones
Identificando operaciones donde se requieran
· Agregar estructuras de herencia para los objetos entidad
· Agregar estructuras de agregación para los objetos entidad
· Refinar las relaciones estáticas tomando en cuenta las estructuras de herencia y agregación.
Definición de ciclos de vida de objetosCada vez que se agrega una nueva clase al modelo de estructura de objetos, debe examinarse si no es necesario dibujar un diagrama de ciclo de vida para dicha clase.
Uso de diagramas de modelo globalLos diagramas de modelado global tienen dos usos durante el análisis de requerimientos, ambos vinculados con el manejo de la complejidad:
particionamiento del espacio de problema para sistemas muy grandes
representación de requerimientos del sistema a un nivel general (diagrama de contexto)
Diseño lógicoEl propósito del diseño lógico es producir un modelo de diseño completo para el sistema relativamente libre de restricciones detalladas de implementación.
Relaciones entre el diseño lógico y físicoEl objetivo del diseño lógico es producir un diseño que requiera pequeños cambios durante el diseño físico para ser implementado. El objetivo de esto es obtener un modelo de implementación "portable" a diferentes escenarios de implementación (estilos de interfaces, lenguajes, Dbms, sistemas operativos, hardware, etc.).
Sin embargo se recomienda que antes de empezar el diseño lógico se tomen ciertas decisiones estratégicas incluyendo:
Sistema de computación a utilizar
Base de datos
Interface de usuario
Lenguaje de programación
Librería de clases a utilizar
Trabajos planeados para ejecutar en modo batch
Criterios de performance
Estrategias con respecto al manejo de errores, administración de memoria (garbaje collection)
Requerimientos de distribución esperados
Actividades realizadas durante el diseño lógicoLas siguientes actividades se llevan a cabo durante el diseño lógico:
Identificación de objetos interface y de control
Identificación de operaciones
Uso de diagramas de interacción de objetos para validar el diseño
Refinado del modelo de estructura de objetos
Refinado del modelo de ciclo de vida de objetos
Definición de subsistemas
Muchas actividades del diseño lógico toman las secuencias de transacciones como punto de partida. El análisis de las secuencias de transacciones es utilizado para identificar que objetos de interfaz y de control deben agregarse al modelo de objetos. Dibujando diagramas de interacción de objetos individuales para cada secuencia de transacciones se asiste en la identificación de operaciones de las clases de objetos.
Identificación de Objetos de interfaces y de Control
Como identificar objetos interfazLos objetos interfaz pueden identificarse siguiendo los siguientes pasos:
· Asignar un objeto interfaz central por cada combinación secuencia de transacción / actor / dispositivo. Por ejemplo un supervisor de almacén puede utilizar una interface GUI para controlar movimientos de stock y una impresora para imprimir detalles de movimientos. Para estas actividades se pueden identificar dos objetos interfaz.
· Para una interfaz GUI, asignar un objeto interfaz por ventana. Los objetos interface se comunican con el objeto interface central identificado en el punto 1. No es conveniente identificar objetos interfaz para cada componente individual de la ventana (botones, listas, etc.), ya que esto es manejado normalmente por los constructores de interfaces (ej., Visual Basic).
· Para otro tipo de dispositivos, puede ser útil identificar un objeto interface central el cual maneja el tipo particular de salida, y definir objetos interfaz adicionales para variantes específicas. Por ejemplo puede definirse un objeto interfaz central para manejar todos los requerimientos de impresión, con objetos interfaz asociados para tipos individuales de impresoras (de matriz, láser, etc.).
· Objetos interfaz pueden modelar protocolos de comunicación por capas como el modelo ISO. Un objeto interfaz se define por cada capa, el cual se comunica solo con objetos de la capa superior e inferior inmediata.
· La agregación puede utilizarse con los objetos interfaz. Por ejemplo, algunos dispositivos son mejor considerados como compuestos. Un ejemplo es un cajero automático compuesto de una lectora de tarjeta magnética, una pantalla, un dispensador de dinero, y una impresora.
· Puede definirse herencia para objetos interfaz. Esto puede ser útil en casos donde un actor tiene un conjunto de capacidades que es un superconjunto de capacidades de otro actor.
· Una vez que los objetos interface han sido definidos, los objetos interface centrales pueden revisarse para detectar similitudes en, en cuyo caso pueden combinarse.
Una vez que los objetos interfaces han sido identificados, es necesario considerar que atributos y operaciones los objetos requieren. El tipo de comportamiento asignado a los objetos interface son los que:
requieren información desde el exterior del sistema
presentan información al exterior del sistema
cambia si el comportamiento del usuario cambia
es dependiente del tipo de dispositivo
A menudo existen objetos interfaz con ciclos de vida complejos en orden de manejar ingresos de datos alternativos, o diferentes secuencias de navegación. En tales casos es conveniente utilizar diagramas de ciclo de vida.
Los detalles de cómo la interface de usuario debe aparecer se finaliza durante el diseño lógico usando un constructor GUI y objetos interfaz en combinación.
Como identificar objetos de controlLos objetos de control contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni a objetos interfaz. Son por lo tanto identificados luego que estos dos tipos de objetos.
Los objetos de control son generalmente temporales y su duración se extiende solo durante la secuencia de transacciones.
La lógica contenida en un objeto de control puede ser lógica de control de sistema, requerida si se está desarrollando un sistema de computación. También puede ser lógica de la aplicación. A menudo es útil utilizar objetos de control para encapsular la lógica de control de secuencias de transacciones.
Los objetos de control pueden identificarse inicialmente asignando un objeto de control por cada secuencia de transacción. Luego que se ha asignado el comportamiento a los objetos entidad e interfaz, puede darse que todo el comportamiento haya sido satisfactoriamente asignado, sin dejar requerimientos para el objeto de control. Pero si existe comportamiento que no pertenece naturalmente ni a los objetos entidad ni de control, este debe permanecer en el objeto de control.
El tipo de comportamiento que puede ser asignado a un objeto de control puede ser:
comportamiento que no cambia si el vecindario del objeto cambia
comportamiento que no cambia sustancialmente si el comportamiento de los objetos entidad varía
comportamiento que afecta a más de un objeto entidad
lógica dependiente del estado
lógica de control para una secuencia de transacciones
Los objetos de control se vinculan con los actores a través de objetos interfaz. Los objetos de control a menudo actúan como un conjunto de buffers entre los objetos entidad y los de control.
Los objetos de control que son demasiado complejos y de baja cohesión funcional deben dividirse. En contraposición si existen varios objetos de control que tiene alta cohesión funcional entre ellos, deben combinarse.
Los objetos de control pueden tener asociados atributos, que normalmente son privados.
La decisión de cuando considerar algunos objetos que contienen cálculos requeridos en el dominio de problema (p.e. cálculo de impuestos, índices, etc.) como objetos de control o entidad puede ser arbitraria. Como regla se puede tomar, que aquellos objetos que tienen atributos y deben ser persistentes, deben considerarse del tipo entidad. Los que no contienen atributos y son temporales, se consideran como de control.
Debe tenerse la precaución de no utilizar objetos de control para separar funciones de datos, ya que esto va en contra del principio de encapsulamiento de la orientación a objetos.
Método de identificación 1: considerando roles y responsabilidades para cada clase de objetosAcorde con Wirfs-Brock, cada clase de objetos debe tener un rol o función simple y coherente claramente definido. En soporte de dicho rol, un objeto toma ciertas responsabilidades y comportamiento que es lógico que otros objetos esperen de él. Las operaciones que un objeto tiene le permiten cumplir con sus responsabilidades.
Las responsabilidades y por lo tanto las operaciones, son identificadas analizando los requerimientos del sistema representados en las secuencias de transacciones.
Habiendo identificado los primeros objetos entidad, interface, y control, podemos ahora considerar cada secuencia de transacciones en orden de identificar que operaciones deben asignarse a cada clase de objetos.
Para realizar esto es conveniente utilizar un diagrama de estructura de objetos que contenga las clases relevantes a la secuencia de transacciones que se analiza.
Alternativamente, las responsabilidades pueden identificarse utilizando el enfoque llamado de "lista de compra". Usando este enfoque, el analista identifica operaciones considerando cada clase de objetos de una en vez y considerando "¿de qué es responsable este objeto, y qué deseo realizar con estos datos?".
Cuando una clase de objetos es claramente responsable de un comportamiento en particular requerido por una secuencia de transacciones, la operación debe asignarse a dicha clase. Cuando no existe una clara responsabilidad perteneciente a una clase en particular se puede hacer lo siguiente:
Asignar la responsabilidad a la clase que más se adecue
Distribuir la responsabilidad en más de una clase
Introducir un objeto de control y asignar la operación al objeto de control
Cuál es la mejor opción depende del contexto y del juicio del diseñador. La asignación correcta de operaciones es un factor clave en un sistema bien diseñado y mantenible.
Método de identificación 2: Interacción de objetos requerida para soportar cada secuencia de transaccionesLas interacciones de objetos requeridas para soportar una secuencia de transacciones puede modelarse usando diagramas de interacción de objetos. Normalmente se utiliza un diagrama de interacción de objetos por cada secuencia de transacción o por cada camino (estándar o alternativo) de la secuencia de transacción.
El punto de entrada para el desarrollo de un diagrama de interacción de objetos se extrae del diagrama de estructura de objetos. Esto debe incluir todos los objetos entidad relevantes para la secuencia de transacciones y los objetos interfaz y de control que se asignan a la secuencia de transacción.
El primer paso es considerar que interacción de objetos se requiere para describir la funcionalidad de la secuencia de transacción. Estas interacciones de objetos son llamadas eventos.
Una secuencia de transacciones es iniciada por un evento. Un evento puede ser externo o temporal. Los eventos externos son generados por actores. Los eventos temporales son disparados cuando se alcanza un instante de tiempo determinado (fecha, hora, proceso periódico).
Si para identificar las secuencias de transacciones se utiliza el enfoque de particionamiento por eventos, entonces los eventos de negocio ya se tienen disponibles. Si el generador del evento de negocio interactúa directamente con el sistema (como en un cajero automático), entonces este evento, su generador, y el objeto que recibe inicialmente el evento, pueden introducirse en el diagrama de interacción. Si el generador del evento de negocio no interactúa directamente con el sistema, entonces el evento que inicia la secuencia de transacciones es el evento en el cual un actor interno a la empresa reacciona al evento de negocio iniciando una interacción con el sistema.
Siguiendo el evento inicial, eventos internos son agregados al diagrama de interacción de objetos para representar la comunicación entre objetos que se requiere para soportar la secuencia de transacciones. Un evento interno es un mensaje por un objeto a otro invocando la ejecución de una operación.
Otros eventos pueden ser enviados o recibidos desde los actores que interactúan con la secuencia de transacciones.
Método de identificación 3: Analizando ciclos de vida de objetosLos diagramas de ciclo de vida deben revisarse para identificar operaciones. Cada evento mostrado en un diagrama de ciclo de vida causa la invocación de una operación en el objeto que recibe el evento. La revisión de los diagramas de ciclo de vida no revelan todas las operaciones, ya que en estos diagramas normalmente solo se modelan los eventos que producen cambios de estado.
Especificación de la semántica y sintaxis de las operacionesDebe definirse la semántica de cada operación identificada. El nombre, la sintaxis, y la semántica deben proveer toda la información que un usuario de la operación necesito para decidir cuándo utilizarla o no.
La especificación de la semántica puede expresarse en forma de texto, tablas de decisión, pseudocódigo, etc. Deben especificarse las precondiciones y pos condiciones de las operaciones como parte de la definición.
También debe especificarse la sintaxis de la operación, los argumentos de entrada / salida requeridos. Puede definirse el tipo y dominio de cada argumento, como así también si es opcional o mandatorio.
Operaciones de claseUna operación puede ser definida como operación de clase. Una operación de clase es una operación que es invocada por la clase misma no por las instancias. Tales operaciones pueden por ejemplo retornar información estadística sobre los objetos instanciados de dicha clase (promedios, totales, etc.). Un objeto particular puede ser creado durante el diseño físico si el lenguaje utilizado no soporta operaciones de clase.
Herencia de operaciones
Operaciones concretas, abstractas, y templadosEn cualquier clase concreta, las operaciones definidas deben siempre tener una implementación. Sin embargo, en las clases abstractas (de las cuales no se generan instancias) la implementación de una operación no es obligatoria, ya que las mismas pueden ser implementadas en las subclases.
Los siguientes tipos de operación pueden especificarse para clases abstractas:
Operación abstracta: Una operación abstracta no tiene un método de implementación. Solo se definen la sintaxis y semántica de la operación.Operación templado: Una operación templado es una operación concreta que se implementa en términos de una o más operaciones abstractas.Operación concreta: Una operación concreta es aquella para la que se especifica completamente su implementación.Redefiniendo operaciones heredadasCuando una clase de objetos hereda una operación concreta de una superclase y la utiliza sin modificarla, no debe agregarse ninguna definición para la operación en la subclase.
Normalmente solo debería necesitarse especificaciones adicionales en la subclase en los siguientes casos:
Adición de una implementación para una operación abstracta.
Extensión de una operación para agregar comportamientos específicos de la subclase.
Redefinición de los tipos de argumentos y dominio de los mismos.
Optimización del código de la operación.
Redefiniendo el modelo de estructura de objetos
Adición y remoción de clases de objetosLas clases de objetos descubiertas durante el análisis de requerimientos son llevadas al diseño lógico y objetos de control e interfaz adicionales son agregados.
En aplicaciones complejas puede necesitarse cambiar el nivel de abstracción en que las clases de objetos son vistas. Por ejemplo, desde el punto de vista del análisis de requerimientos, puede ser claro que un número de objetos similares son requeridos y que cada uno debe ser descripto como una subclase de una superclase. Desde el punto de vista del diseño lógico, puede determinarse que solo es necesario la superclase en el diseño final.
Identificación de AtributosDurante el diseño lógico, los atributos para cada clase de objetos deben ser completamente identificados. Se especifican las restricciones de acceso determinado atributos públicos, protegidos, y privados. También aquí se determinan atributos derivados.
Definición de persistencia de atributosLos objetos entidad son usualmente persistentes mientras que los interface o de control no. Deben identificarse objetos entidad que no son persistentes, y los interface y control que si lo son.
SubsistemasSubsistemas pueden haber sido definidos en etapas previas o pueden definirse durante el diseño lógico. En el caso en que ya hayan sido definidos con anterioridad, igualmente es conveniente revisarlos en esta etapa luego de que las clases han sido convenientemente definidas, para verificar que los subsistemas definidos en verdad representan unidades coherentes.
Durante el diseño lógico las principales razones para definir subsistemas son:
Para definir unidades de entrega, unidades funcionales que se entregarán al usuario en diferentes momentos.
Para definir unidades de distribución.
Para definir módulos que garanticen la robustez del diseño del sistema.
Con propósitos de validación, para chequear la calidad del diseño del sistema.
Con propósitos de presentación.
Diseño FísicoEl propósito del diseño físico es agregar los detalles técnicos dependientes de la plataforma requerida para construir el sistema a partir del diseño lógico.
Las principales actividades del diseño físico son:
· Establecimiento de la arquitectura del sistema
· Implementación de las clases del dominio del problema del sistema
· Construcción de la interface de usuario
· Diseño e implementación del componente de administración de datos
· Diseño de la integración con sistemas existentes (legacy systems)
Arquitectura del sistema.La arquitectura del sistema es la organización general del sistema en componentes (o subsistemas).
Como se ha mencionado, es útil y común dividir sistemas grandes y complejos en subsistemas para facilitar su desarrollo. Pero además es útil dividir un sistema de cualquier tamaño en subsistemas basados en consideraciones arquitecturales que son específicamente relevantes durante la fase de diseño físico de la aplicación.
Un sistema puede particionarse vertical y horizontalmente (en capas). Las particiones verticales son utilizadas para subdividir la funcionalidad de la funcionalidad, en tanto que las particiones horizontales son utilizadas particularmente para aislar dependencias del sistema operativo, base de datos, o hardware. La subdivisión en capas horizontales asiste en el salvaguardo de la portabilidad del sistema.
Las particiones verticales deben estar débilmente acopladas y trabajar en configuración cliente/servidor o peer-to-peer. Las capas horizontales están en una relación cliente-servidor, donde las capas más bajas (servidores) suministran servicios a las capas superiores (clientes).
La arquitectura del sistema puede diagramarse utilizando diagramas de visión general. Estos diagramas muestran subsistemas y los servicios que se proveen mutuamente.
El presente enfoque de desarrollo orientado a objetos recomienda la siguiente arquitectura de seis componentes:
Componente Dominio de Problema (PDC)Representa la parte del sistema que corresponde con el dominio del problema (mundo real). Consiste de todos los objetos entidad y de control identificados durante las fases previas.
Componente de Interacción Humana (HIC)Consiste de todos los objetos requeridos para la implementación de la interface de usuario. Se corresponde con los objetos intefaz con usuarios humanos identificados durante las fases previas.
Componente de Interfaces Externas (EIC)Consiste de todos los objetos intefaz con usuarios no humanos, como ser sistemas externos, dispositivos, impresoras, etc.
Componente de Administración de Datos (DMC)Provee la infraestructura para el almacenamiento y recuperación de los objetos persistentes en algún medio de almacenamiento.
Componente de Administración de Tareas (TMC)Se encarga de administrar concurrencia cuando es necesaria. La utilización de este componente es muy rara en sistemas administrativos, siendo de utilidad solo en algunos sistemas en tiempo real.
Componente de Servicio de Utilidades (USC)
Provee servicios de utilidad general que pueden ser requeridos por todos los demás componentes.
Componente Dominio de Problema (PDC)Este componente representa la parte del mundo real (dominio de problema) del sistema. Este componente no debe ser afectado por dependencias del harware, sistema operativo, sistema de interfaz, o base de datos.
Este componente comprende todas clases de objetos entidad y control definido durante las fases previas, pudiéndose extender con clases específicas de la implementación.
El diseño físico implica la implementación de las clases y la especificación formal de las operaciones. Para esto es conveniente trabajar con lenguajes orientados a objetos que soportan todas las características y permiten una traslación directa de las clases a las construcciones del lenguaje.
Los principales puntos a considerar durante la implementación de las clases del PDC son:
elección de tipos y estructuras de datos
implementación de relaciones
implementación de ciclos de vida
implementación de restricciones
implementación de atributos y relaciones derivadas
manejo de errores
Componente de Interacción Humana (HIC)
Componente de Administración de Datos (DMC)Las clases del DMC proveen la infraestructura para el almacenamiento y recuperación de objetos en un sistema de manejo de datos (DBMS o sistema de archivos). La separación de estas clases en un componente específico permite aislar al sistema de la dependencia de un sistema de manejo de datos específico.
La implementación en bases de datos puede contemplar diferentes tecnologías, sin embargo las más importantes son las relacionales (RDBMS) y las orientadas a objetos (ODBMS). Los RDBMS no permiten almacenar en forma directa objetos lo cual obliga a realizar una capa de traslación, sin embargo actualmente para aplicaciones con grandes volúmenes de datos son los más maduros y robustos. Por otro lado la tecnología de ODBMS si bien se integra mejor a un sistema orientado a objetos, todavía se encuentra en evolución y es considerada por algunos inmadura para soportar aplicaciones críticas.
Los principales pasos en la construcción del DMC son:
· Mapeo de clases persistentes en las estructuras de datos del sistema de administración de datos (p.e. tablas de un RDBMS)
· diseño de las clases de objeto para manejar las transformaciones y para interfacear con el DBMS.
· diseño detallado de la interacción de objetos necesaria para soportar el almacenamiento y recuperación de objetos persistentes.
Arquitectura del DMC
Diseño de base de datos relacionalPara cada objeto persistente debe identificarse un identificador unívoco (object ID) (clave primaria). La aplicación misma es responsable de la generación y administración de este object ID. Para la generación de este object ID pueden utilizarse atributos de identificación definidos durante el diseño lógico.
Los atributos compuestos deben separarse en sus componentes atómicos.
Las relaciones estáticas entre clases pueden realizarse atravez de la implementación de claves foráneas.
En general, se tienen tres alternativas para el mapeo de relaciones:
· Cualquier relación (cualquiera sea su cardinalidad) puede siempre mapearse como una tabla separada en la cual cada fila contiene un par de object IDs y se corresponde con una instancia de la relación.
· Relaciones uno-a-muchos o uno-a-uno, pueden mapearse incluyendo claves foráneas en una de las tablas relacionadas.
· Para relaciones uno-a-uno existe una tercera alternativa que consiste en combinar las tablas relacionadas en una sola.
Para el mapeo de agregaciones, se aplican las mismas reglas que para las relaciones estáticas, ya que en realidad son un caso particular de las mismas.
Para el mapeo de jerarquías de herencia existen tres alternativas:
· Cada clase de la jerarquía es mapeada a una tabla separada. Todas comparten un mismo object ID, y tienen una columna para cada atributo propio de la clase.
· Cada clase no abstracta en la jerarquía es mapeada a una tabla separada que contiene una columna adicional para cada atributo heredado.
· Todas las clases en la jerarquía son mapeadas a un única tabla agregándose columnas para todos los atributos de la jerarquía.
Componente de Interface Externa (EIC)
Componente de Administración de Tareas (TMC)
Componente de Servicios de Utilería (USC)
Suscribirse a:
Entradas (Atom)