Los modelos permiten: Comunicarse con quienes deben conocer el objeto modelado. Analizar alternativas. Validar.

Transcripción

1 Unidad 1 Modelado de sistemas. Principios del modelado. Modelado orientado a objetos. Visión general de El lenguaje Unificado de Modelado UML Constructores básicos de UML. Estructura Estática y Estructura Dinámica de un sistema INTRODUCCIÓN AL MODELADO DE SISTEMAS Para desarrollar software de calidad duradera hay que idear una sólida base arquitectónica que sea flexible al cambio. Hay que disponer de un proceso de desarrollo sólido que pueda adaptarse a las necesidades cambiantes del problema en cuestión y de la tecnología. El modelado es una parte central de todas las actividades que conducen a la producción de software. Un modelo se define como: una simplificación de la realidad. Los modelos permiten: Comunicarse con quienes deben conocer el objeto modelado. Analizar alternativas. Validar.. Construimos modelos para: Comunicar la estructura deseada y el comportamiento del sistema a desarrollar Visualizar y controlar la arquitectura del sistema Comprender mejor el sistema que estamos desarrollando que en algunos casos permite la simplificación y reutilización Para controlar el riesgo. La actividad de construcción de un modelo implica: Establecer hipótesis de manera de simplificar la realidad para resaltar únicamente los aspectos relevantes para el estudio. Realizar la representación del objeto modelado, según la notación elegida. Validar el comportamiento del modelo con respecto al objeto real, y refinarlo de ser necesario. Al modelar se debe tener siempre presente que: No se modela por modelar, se modela para poder construir correctamente. Modelar ahorrará dinero, siempre y cuando se lo haga en forma eficiente. Las reglas que se aplican en la construcción del modelo son para ayudar y no para molestar. Principios del modelado. Podemos considerar cuatro principios básicos de modelado: 1/22

2 1) La elección de que modelos crear tiene una profunda influencia sobre como se acomete un problema y como se da forma a una solución. Hay que elegir bien el modelo. 2) Todo modelo puede ser expresado a diferentes niveles de precisión. 3) Los mejores modelos están ligados a la realidad. 4) Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes. Modelado orientado a objetos: Actualmente el enfoque orientado a objetos forma parte de la tendencia principal para el desarrollo del software porque ha demostrado ser válido en la construcción de sistemas en toda clase de dominios de problemas. En el modelado orientado a objetos el principal bloque de construcción de todos los sistemas software es el objeto o clase. Todo objeto tiene identidad (puede nombrarse o distinguirse de otra manera de otros objetos), estado y comportamiento. Una clase es una descripción de un conjunto de objetos similares. Por ejemplo en una arquitectura de tres capas para un sistema de contabilidad: con una interfaz de usuario, una capa intermedia y una base de datos. En la interfaz de usuario aparecerán objetos concretos tales como botones, menús y cuadros de diálogos. En la base de datos aparecerán objetos tales como tablas que representan entidades del domino del problema, incluyendo clientes, productos y otras. En la capa intermedia aparecerán objetos tales como transacciones y reglas de negocio, así como vistas de más alto nivel de las entidades del problema, tales como clientes, productos y pedidos. Visión general de El lenguaje Unificado de Modelado UML UML es un lenguaje de modelado. Los modelos UML representan tanto la estructura estática como el comportamiento dinámico de un sistema. Es un lenguaje visual que, a los desarrolladores les permite discutir las funcionalidades del sistema y comunicarse con el usuario, obteniendo y validando los requerimientos de los mismos. UML es un lenguaje de propósito general, permite modelar cualquier tipo de aplicación, desde servicios Web hasta sistemas de mantenimiento de datos de una empresa, pasando por aplicaciones para telefonía celular. La sintaxis de UML nos dice como construir nuestros modelos. La semántica nos dice como interpretarlos y nos garantiza, a través de un modelo que todas las personas involucradas comprendan exactamente la información contenida en él. Si un mismo modelo es entregado a dos programadores para su codificación, se espera que el código resultante sea equivalente. 2/22

3 Constructores básicos de UML Las Entidades representan todo concepto de interés para nuestro sistema. Para la programación Orientada a Objetos son las clases. Las entidades agrupan tanto estructura como comportamiento. Su estructura estará dada por los atributos de la entidad, mientras que el comportamiento se especificará a través de los métodos. Ejemplo: Una entidad Libro cuenta con atributos que reflejan su autor, editorial y cantidad de páginas, mientras que algunos de sus posibles métodos son devolver Autor o Señalador que devuelve la última página leída. En UML las entidades o clases son rectángulos divididos en tres partes: una para el nombre, las otras para los atributos y los métodos u operaciones. Las entidades pueden relacionarse de distintas maneras. Una entidad puede conectarse a otra, depender de otra, puede especializar otra, formar parte de otra, extender el comportamiento de otra. Ejemplo: La entidad Libro está conectada a la entidad Autor ya que un libro puede tener uno o más autores. Las relaciones en los modelos UML se representan mediante distintos tipos de flecha. Vemos el modelo UML para las clases Libro, Autor y la asociación entre ellos. La clase Libro cuenta con Atributos:Autor- Editorial-CantidadDePáginas (integer: número entero) que se indican como privados al anteponer el -. Métodos:señalador y devolverautor La clase Autor cuenta con los atributos de tipo string: nombre y apellido. No tiene especificado ningún método. 3/22

4 La asociación se representa a través de una línea continua entre las clases que vincula. Los asteriscos en los extremos de la asociación indica la multiplicidad de la asociación (un libro puede tener mucho autores y un autor puede escribir muchos libros). Las relaciones nos permiten modelar la manera en que las entidades se comunican o interactúan. Un diagrama es una presentación gráfica de un conjunto de elementos, que la mayoría de las veces se dibuja como un grafo con los nodos (elementos) y arcos (relaciones). Estructura Estática y Estructura Dinámica de un sistema. La manera de agrupar la forma en que interactúan las entidades responden a dos grandes categorías: la estructura estática del sistema y la estructura dinámica del sistema. Un ejemplo de estructura estática del Libro es el que vimos cuando mencionamos sus atributos y métodos. Un ejemplo de comportamiento dinámico sería modelar su estado a lo largo del tiempo: primero en estado Borrador, luego EstadoParaPublicación y una vez publicado por una editorial pasa al estado de Publicado. El siguiente Diagrama de Estados refleja estos distintos estados que atraviesan las instancias de tipo Libro a lo largo de la ejecución del sistema: El pequeño punto negro representa el estado inicial. El punto siguiente al estado Publicado indica el estado final del diagrama de estado. La Estructura estática y la Estructura Dinámica se deben encontrar sincronizadas 4/22

5 5/22

6 Unidad 2 Modelar Clases. Constructores de Clase para UML. Atributos y métodos. Notas. Modelar Relaciones: Generalizaciones. Dependencias. Asociaciones. Modelo Estático Una vez realizada la captura de requerimientos se está en condiciones de iniciar el modelado del sistema, para lo cual en primer lugar se define la estructura estática especificando las principales clases del sistema y delineando en forma global las responsabilidades de lo que aportará cada entidad al desarrollo del sistema. Como resultado de modelado de la estructura estática se espera obtener el Diagrama de clases completo con las interacciones entre ellas. Modelar Clases: Las clases son la pieza fundamental del modelo y de la Programación Orientada a Objetos. Representa la unidad mínima sobre la cual se construirá el sistema. Las clases abstraen estructura y comportamiento. La estructura esta representada por los atributos y el comportamiento por los métodos. Los atributos representan propiedades de la clase. Las operaciones o métodos representan aquellas funcionalidades que pueden proveer las clases. Como vimos en la unidad 1 en el ejemplo de la clase Libro: las clases se definen en rectángulos divididos en tres partes: una para el nombre, las otras para los atributos y los métodos u operaciones. Para los atributos podemos especificar su tipo y su valor inicial. Para los métodos podemos especificar sus parámetros y su tipo de retorno. Una de las dudas que se puede plantear es si una determinada entidad debería ser modelad como clase o como un atributo. Por ejemplo si tenemos una clase Autor con los siguientes atributos: Autor Nombre Apellido Dirección fechadenacimiento teléfono Esta es una opción pero puede ser que según el requerimiento relacionado sea necesario conocer respecto al teléfono si es un número celular o fijo, la compañía, si es un número de teléfono extranjero o no. Se puede considerar esta información como atributo de la clase Autor con lo que tendríamos que nombrarlos como estelefonocelular, estelefonoextranjero o compañiatelefono, si bien se especifica que si es celular o no, el tipo de número y la compañía se refieren al teléfono no son atributos del Autor por lo mas correcto es definirle Telefono como una clase asociado al Autor: 6/22

7 Constructores de Clase para UML Diseño de sistemas 2013 Las clases en UML se representan a través de rectángulos con un nombre único que las identifique. Se puede poner el nombre solo que debe ser claro y preciso. Si la clase están en un paquete se pude especificar su nombre completo, esto se indica con el constructor ::, Por ejemplo la clase Computadora está definida dentro del paquete Artefactos por lo que se indicaría así: Artefactos::Computadoras Atributos y Métodos Las clases poseen estructura y comportamiento. En UML la estructura está representada por los atributos y el comportamiento por los métodos. Los atributos representan propiedades de la clase. Las operaciones o métodos representan aquellas funcionalidades que pueden proveer las clases. En UML los atributos se ubican debajo del nombre de la clase, como siguiendo una división en el rectángulo y los métodos se especifican debajo de los atributos. Notas: Son texto en lenguaje natural que sirve para expresar datos extra, restricciones sobre alguna entidad o pueden ser comentarios sobre el comportamiento esperado, o sea se utiliza para cualquier tipo de observaciones. No es un elemento de primer nivel como son las clases por lo que siempre están asociadas a un constructor. Gráficamente se representan con un rectángulo con un extremo doblado. 7/22

8 Modelar Relaciones: Las clases interactúan entre sí, se relacionan unas con otras. Una clase puede heredar comportamiento de otra, puede influir en otra clase o puede depender de ella. Una clase que no interactúa con el resto es signo de un modelado incorrecto, lo mismo podemos decir de una clase que se conecta o interactúa con demasiadas clases. Existen tres grandes tipos de relaciones: generalizaciones que modelan jerarquías, dependencias que modelan relaciones de uso y asociaciones que modelan relaciones estructurales. Generalizaciones. Este tipo de relación une o conecta clases que comparten algunos atributos y comportamiento, mientras que individualmente tiene características exclusivas. Este tipo de relaciones de jerarquía se indican con una flecha desde la subclase a la clase madre que tiene una punta rellena. Ejemplo: Clase Alimentos para Felinos Subclases: Cachorros-Adultos-Mayores Esta relación se conoce como Es-un: el alimento para gatos pequeños es un tipo de alimentos para Felinos. La jerarquía establecida entre las clases está relacionada con los constructores de Herencia y Polimorfismo. Una clase hereda de otra cuando especializa su comportamiento. La clase Cachorro hereda de la clase Alimentos para Felinos. La subclase hereda todos los atributos y operaciones de la clase menos aquellos declarados como privados. Muchas veces las subclases pueden cambiar el comportamiento heredado de la clase optimizando los métodos. Esto se conoce como redefinición de métodos. Una clase es polimórfica cuando durante la ejecución puede cambiar su tipo para aceptar cualquiera de las subclases o clases hijas o clases que hereden de sus clases hijas también. Si una clase hereda de una clase madre tenemos el caso de herencia simple. Si una clase puede heredar de más de una clase se llama herencia múltiple. 8/22

9 Dependencias. Ejemplo: el tipo de alimento correcto para perros depende de la cantidad de antioxidantes y de proteínas. Se representa mediante una línea entrecortada con una dirección que indica de quien a quien es la dependencia. La clase A depende de la clase B entonces los cambios efectuados en B impacta en A. El caso más común de dependencia es cuando una clase usa a otra como el tipo de algún parámetro de sus métodos. Existen tipos especiales de dependencias: de abstracción y de derive o deriva Muchas veces tenemos el mismo concepto modelado desde distintos niveles de abstracción. Por ejemplo para un cajero de un banco especificamos que puede manejar operaciones desde un nivel menor de abstracción, definimos operaciones como ConsultarSaldo pudiendo indicar en UML que ConsultarSaldo es una versión más detallada de Operaciones. Derive: lo utilizamos para marcar que un concepto se puede derivar de otro. Por ejemplo el saldo de una cuenta bancaria deriva de los depósitos y extracciones. Asociaciones Esta es una relación estructural que describe una conexión entre objetos. Gráficamente se muestra como una línea continua que une las clases relacionadas entre si. Multiplicidad: la multiplicidad de una asociación determina cuantos objetos de cada tipo intervienen en la relación. Cada asociación tiene dos multiplicidades (una para cada extremo de la relación). Navegación: Dada una asociación simple entre dos clases como Libro y Biblioteca, es posible navegar de los objetos de un tipo a los del otro. A menos que se indique lo contrario, la navegación a través de una asociación es bidireccional (ambos sentidos). En ocasiones es deseable hacerlas unidireccionales (con restricción de navegación en un único sentido). Ejemplos: 9/22

10 10/22

11 Unidad 3 Diagramas estructurales y de comportamiento. Diagramas de Clases. Composición y objetivos. Interfaces. Herencia. Diagrama de Objetos: Composición y objetivos. Instancias y clases. Diagrama de paquetes. Diagramas de Componentes Diagramas: Un diagrama es una presentación gráfica de un conjunto de elementos, que la mayoría de las veces se dibuja como un grafo con los nodos (elementos) y arcos (relaciones). Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas. Como ningún sistema puede ser comprendido completamente desde una única perspectiva UML define varios diagramas que permiten centrarse en diferentes aspectos del sistema independientemente. Diagramas estructurales Los diagramas estructurales de UML se realizan para visualizar, especificar, construir y documentar los aspectos estáticos de un sistema. Los diagramas estructurales se organizan en líneas generales alrededor de los principales grupos de elementos que se utilizan para modelar un sistema. 1) Diagramas de clases. Clases, interfaces y colaboraciones 2) Diagramas de objetos Objetos 3) Diagramas de componentes Componentes 4) Diagramas de despliegue Nodos. Diagramas de comportamiento. Los cinco diagramas de comportamiento de UML se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema de software que involucran cosas tales como el flujo de mensajes a lo largo del tiempo y el movimiento físico de componentes de una red. Los diagramas de comportamiento estructurales se organizan en líneas generales alrededor de las formas principales en que se puede modelar la dinámica de un sistema: Diagramas de casos de uso Organiza los comportamientos del sistema, ponen todo el peso en la interacción entre los usuarios y el sistema. Diagramas de secuencia Centrados en el orden temporal de los mensajes. Muestra la interacción y comunicación entre objetos a medida que transcurre el tiempo de ejecución, enfocándose en el pasaje de mensajes Diagramas de colaboración Se enfocan en modelar como dos o más clases colaboran entre sí para lograr un objetivo en particular. Diagramas de estados Un diagrama de estados representa una máquina de estados constituida por 11/22

12 Diagramas de actividades estados, transiciones, eventos y actividades. Se utilizan para describir la vista dinámica de un sistema Muestra el flujo de actividades de un sistema. Diagramas de Clases. Composición y objetivos Un diagrama de clase muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Son los primeros en utilizarse al terminar la etapa de requerimientos. Básicamente los diagramas de clases contiene los siguientes elementos: Clases Interfaces Colaboraciones Relaciones de dependencia, generalización y asociación Pueden contener notas y restricciones (extensiones de la semántica de un elemento que permite añadir nuevas reglas o modificar las existentes). Los diagramas de clase pueden contener paquetes o subsistemas, los cuales se utilizan para agrupar los elementos de un modelo en partes más grandes. El objetivo principal de los diagramas de clase es modelar la estructura estática y mostrar las principales relaciones entre las clases. Usos comunes 1-Con un diagrama de clases se define lo que se conoce como vocabulario de un sistema, que se encarga de identificar y relacionar todos sus conceptos. Cualquier funcionalidad del sistema pertenecerá al vocabulario de este y estará presente en los diagramas de clase del sistema. De forma similar las funcionalidades que el sistema no cubrirá no pertenecerán al vocabulario. 2-Para modelar colaboraciones simples. Una colaboración se defines como una sociedad entre clases, interfaces y otros elementos que trabajan para proporcionar un comportamiento cooperativo mayor que la suma de todos los elementos. 3-Para modelar un esquema lógico de base de datos. Interfaces Las interfaces tienen la estructura de una clase: nombre, atributos y métodos. La única diferencia es que para los métodos no se provee ninguna implementación sino que se declara el tipo de retorno, su nombre y los parámetros que indican su tipo. Herencia. La herencia múltiple le permite a una clase heredar comportamiento de dos o más clases madres. Diagrama de Objetos Un diagrama de objetos modela las instancias de los elementos contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. Se utilizan para modelar la vista de diseño estática o la vista de procesos estática de un sistema. Es el modelado de una instantánea del sistema en un momento concreto y la representación de un conjunto de objetos, su estado y sus relaciones. 12/22

13 Diagrama de paquetes. Un paquete en UML consiste en un grupo de diagramas y clases organizados según algún criterio. La organización en paquetes denota prácticamente una organización arquitectónica de un sistema. Un diagrama de paquetes nos permite ver como los principales paquetes de un sistema interactúan. Diagramas de Componentes Los diagramas de componentes reflejan la estructura estática del sistema pero desde un punto de vista físico. Son diagramas avanzados que muestran la estructura estática de la implementación de un sistema. Presenta la interacción entre clases pero no desde el punto de vista lógico, sino desde un punto de vista físico de implementación. Diagramas de despliegue Un diagrama de despliegue muestra un conjunto de nodos y sus relaciones. Se utilizan para describir la vista de despliegue estática de una arquitectura. Por ejemplo una arquitectura cliente/servidor o sistemas distribuidos, 13/22

14 Unidad 4 Requerimientos. Definición, Clasificación. Características. Captura. Ciclo de los requerimientos Diagramas de Casos de Uso: Constructores. Especificación de casos de uso. Relacionar casos de uso. Clasificaciones. Estructura interna de los casos de uso. Describir los casos de uso. Modelado del contexto de un sistema. Modelado de los requisitos de un sistema Requerimientos. Un sistema de software nace como la solución de un problema particular. El éxito del sistema se medirá según cuan bien la solución automatizada resuelva el problema para lo cual es necesario contar con su especificación. Al definir requerimientos, es importante describir al sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados. Definición de requerimientos: Los requerimientos son las condiciones y propiedades que el software debe satisfacer para construir una solución correcta al problema planteado. También podemos definir Un requerimiento es a) una condición o capacidad que precisa un usuario para resolver un problema o lograr un objetivo. b) una condición o capacidad que debe satisfacer o proveer un sistema para cumplir con un determinado contrato, estándar o especificación c) un documento representando una condición o capacidad. Clasificación Los requerimientos pueden ser agrupados en distintas categorías, cada uno tendrá una prioridad dentro del sistema. Los de mayor prioridad son los que se debe respetar sí o sí para que el sistema no fracase. Se pueden clasificar en funcionales y no funcionales. Los requerimientos funcionales son aquellos relativos a las cuestiones que el sistema debe realizar. Afectan directamente a la funcionalidad del sistema, por ejemplo para un sistema que maneja el funcionamiento del cajero de un banco, los requerimiento funcionales podrían ser que se deberá pedir una contraseña numérica de 4 dígitos para ingresar Los requerimientos no funcionales está enfocados en describir cualidades generales del sistema, por ejemplo usabilidad, confiabilidad mantenibilidad o performance. Características de los requerimientos: Un modelo para su especificación contemplará los siguientes puntos: _ Evolución _ Resolución de conflictos _ Trazabilidad _ Asignación de prioridades. Ciclo de los requerimientos: 14/22

15 Los requerimientos surgen desde distintas fuentes, en general se habla del o los clientes del producto. Cada uno de ellos hablará del sistema en distintos niveles de abstracción y bajo diferentes perspectivas. Es muy importante capturar correctamente todos los requerimientos, para lo cual se cuenta con la técnica más utilizada para capturar y especificar requerimientos: los casos de uso. Diagramas de Casos de Uso: Constructores. Especificación de casos de uso Qué son los Casos de Uso? Los casos de uso son una técnica para especificar el comportamiento de un sistema: Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Todo sistema de software ofrece a su entorno aquellos que lo usan una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos alguien o algo hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está ejecutando el caso de uso ingresando pedido. Se define un concepto muy parecido al del caso de uso: el evento. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento Cliente hace Pedido. En este caso el sistema deberá responder al estimulo que recibe el Pedido procesándolo. Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son: 1) Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cómo es el diálogo entre el usuario y el sistema. 2) Los eventos son atómicos : se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema. De esta forma, un caso de uso puede agrupar a varios eventos. 3) Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria. 15/22

16 Unidad 5 Diagramas de interacción: Clasificación Diagramas de secuencia. Elementos básicos de un diagrama de secuencia. Diagrama de colaboración. Patrones. Patrones de diseño. Frameworks Diagramas de interacción: Su objetivo es mostrar y ejemplificar el comportamiento del sistema ante determinadas situaciones específicas. Reflejan una determinada comunicación entre objetos a través del modelado del intercambio de mensajes entre ellos siendo estos la forma en la que los objetos se comunican. Clasificación Para modelar la interacción entre los distintos objetos tenemos dos opciones diferentes según que el factor determinante sea el tiempo o la estructura jerárquica del sistema. Si toda la interacción es guiada por el paso del tiempo es fundamental mostrar el orden en que los distintos mensajes son generados y recibidos, esto se refleja en los diagramas de secuencia. Si modelamos el intercambio de mensajes entre objetos desde el punto de vista de la estructura interna del sistema se utilizan los diagramas de colaboración. El siguiente modelo UML refleja la estructura interna de los diagramas de interacción. Diagramas de secuencia El diagrama de secuencias en UML muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo. 16/22

17 Elementos básicos de un diagrama de secuencia. Un diagrama de secuencia está dividido en dos grandes secciones. En la parte superior se especifican todos los objetos que intervendrán en el escenario a modelar. Esto es similar a especificar los actores que interviene en un determinado caso de uso. De cada uno de los objetos se desprende una línea discontinua que representa el paso del tiempo. La comunicación o intercambio de mensajes se refleja a través de una flecha dirigida que marca el sentido de la comunicación. Cada flecha es etiquetada con el nombre del mensaje, el cual se corresponde con un método definido en un objeto del sistema. Cada flecha que llega a un objeto simboliza la invocación de un método de esa clase. Cada flecha que sale de un objeto simboliza la invocación de un método. Las entidades que intervienen en un diagrama de secuencia no son clases, sino instancias de clases. Como estamos modelando un comportamiento en particular o sea una instancia concreta de ejecución, los elementos que intervienen, son los objetos en sí, y no clases. Sincronización de los modelos Cada objeto que interviene en un escenario debe pertenecer a una de las clases definidas en el diagrama de clases. Cada mensaje que ingresamos se debe corresponder con la definición de un método en el diagrama de clases. 17/22

18 Recursividad: Se plantea cuando un objeto posee una operación que se invoca a sí misma. Por ejemplos supongamos que un objeto de nuestro sistema es una calculadora y que una de sus operaciones sea el cálculo del interés compuesto para un período que incluya otros, esta operación tendrá que invocarse a sí misma varias veces. Representación de mensajes: Diagrama de colaboración Un Diagrama de colaboración se basa en la organización de los elementos y no en el orden temporal de los mensajes o sea no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia de mensajes. Un Diagrama de colaboración muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común. Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace". Los elementos que conforman un diagrama de colaboración son: 1) Los Objetos que intervienen en la funcionalidad a modelar. 2) Los vínculos (asociaciones, composición, herencia ) entre ellos. 18/22

19 3) Los mensajes entre ellos, ubicados generalmente como etiquetas sobre los vínculos. El orden principal en los diagramas de colaboración está dado por el flujo de control que generalmente es secuencial, por lo que son útiles para modelar transformaciones de datos por en etapas sucesivas. Para modelar un diagrama de colaboración el primer paso consiste en incluir los objetos, luego se incluyen los vínculos Vemos un ejemplo La relación entre el autor y el libro es la relación tradicional que se encuentra en un diagrama de objetos. El comportamiento dinámico se da en el mensaje agregarlibro, etiquetado con el número de secuencia 1, donde se muestra como el método de la clase Biblioteca es invocado y como resultado de su ejecución el libro pasa a formar parte de esta. En un mismo mensaje pueden darse varias invocaciones a métodos. Por ejemplo si un socio que desea consultar un libro y si es de su agrado retirarlo de la biblioteca, para establecer un orden entre estos métodos (consultar y retirar) se establecerá un número que establece el orden de ejecución. Vemos un ejemplo con múltiples mensajes en cada vínculo: En los diagramas de colaboración el propósito más importante es mostrar como los objetivos que llevan a cabo una determinada actividad están relacionados entre sí. Comparación entre diagramas 19/22

20 En la siguiente tabla se resumen los objetivos y diferencias de los diagramas de interacción: Tipo de Diagrama Elementos Foco Secuencia Instancias Mensajes Línea de tiempo Colaboración Instancias Vínculos Mensajes Número de secuencia Orden temporal de los mensajes Organización y estructura interna de los objetos Los escenarios mostrados en los diagramas de interacción se corresponden con los casos de uso de mayor prioridad del sistema y ayudan a validar los requerimientos. Patrones. En todos los sistemas bien estructurados se utilizan patrones. Un patrón proporciona una solución común a un problema común en un contexto dado. Un mecanismo es un patrón de diseño que se aplica a una sociedad de clases. Los patrones de diseño especifican la estructura y el comportamiento de una sociedad de clase Un framework es típicamente un patrón arquitectónico que proporciona una plantilla para aplicaciones dentro del dominio, especifican la estructura y el comportamiento de un sistema completo. Al diseñar un sistema, la experiencia y las convenciones, llevan a aplicar formas comunes de resolver problemas comunes. Por ejemplo si se está construyendo un sistema que interactúa mucho con el usuario, una forma de organizarlas abstracciones es utilizar un patrón modelo-vista-control, con el cual se separan de forma clara los objetos (el modelo) su presentación (la vista) y los agentes que los mantiene sincronizados (el control). Utilizando los patrones en un sistema se hace que este sea más comprensible y fácil de modificar y mantener. Los patrones ayudan a visualizar, especificar, construir y documentar los artefactos (piezas de información en un desarrollo de software) de un sistema con gran cantidad se software. Cuando se implementa un sistema se puede especificar que patrones 20/22

21 se incorporan para que en caso de reutilizar o adaptar el sistema más tarde los patrones estén claramente identificados. 21/22

22 Unidad 6 Proceso Unificado. Descripción del Proceso Unificado. Proceso Unificado de Desarrollo Software (RUP) Fases. Iteración. Flujos de trabajo del proceso. Utilizando el material suministrado (Anexo C de El Lenguaje Unificado de Modelado ): definir Proceso Unificado Racional, sus característica, las fases e iteraciones. Flujos de trabajo del proceso. 22/22