Dependencias y asociaciones

(Imagen: Diapostitivas del curso de IBM)

Existen cuatro opciones para crear un vínculo de comunicación hacia un objeto proveedor:

• Global: El objeto proveedor es un objeto global
• Parámetro: El objeto proveedor es un parámetro de, o el tipo de retorno de una operación en el objeto cliente
• Local: El objeto proveedor es declarado localmente (o sea, creado temporalmente durante la ejecución de la operación)
• Campo: El objeto proveedor es un miembro del objeto cliente
  

Una dependencia es un vínculo de comunicación pasajero. Una dependencia ocurre cuando la visibilidad es global, de parámetro o local.

Es necesario observar cada relación de asociación para determinar si debe permanecer como asociación o transformarse en dependencia. Las asociaciones y las agregaciones son relaciones estructurales (visibilidad de campo). Las relaciones de asociación son realizadas por variables que existen como miembros de la definición de clase. Cualquier otra relación (visibilidad global, local o de parámetro) es una relación de dependencia.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Diseño de subsistemas: Visión General

(Imagen: Diapostitivas del curso de IBM)

El diseño de subsistemas se realiza una vez por subsistema de diseño

Propósito:

• Definir los comportamientos especificados en las interfaces de subsistemas en términos de colaboraciones entre los elementos de diseño contenidos y subsistemas/interfaces externos.
• Documentar la estructura interna del subsistema
• Definir realizaciones entre las interfaces de subsistemas y las clases contenidas.
• Determinar dependencias con otros subsistemas.
  

Artefactos de entrada:

• Subsistemas e Interfaces de Diseño
• Guías específicas del proyecto
• Modelo de diseño
  

Artefactos resultantes:

• Subsistemas e Interfaces de diseño
• Clases de diseño
• Modelo de diseño

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Clases abstractas y concretas

(Imagen: Diapostitivas del curso de IBM)
Una clase que existe sólamente para que sea heredada por otras clases se denomina clase abstracta. Las clases que pueden usarse para instanciar objetos se denominan clases concretas.

Una operación puede marcarse también como abstracta. Esto significa que no puede haber una implementación para la operación en la clase donde se especificó. Una clase que contiene al menos una operación abstracta debe ser una clase abstracta. Las clases que heredan de clases abstractas deben proveer implementaciones para sus operaciones abstractas. De otro modo, las operaciones serían consideradas abstractas dentro de la subclase, por lo que la subclase debería considerarse abstracta también. Las clases concretas tienen implementaciones para todas sus operaciones.

En UML, se designa una clase como abstracta al poner el nombre de la clase en cursiva. Para operaciones abstractas, se coloca la firma de la operación en cursiva. El nombre de un item abstracto puede colocarse también en cursiva.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Ámbito

(Imagen: Diapostitivas del curso de IBM)

El ámbito de un atributo/operación determina si es que el atributo aparece en cada instancia de la clase (ámbito de instancia) o si existe sólo una instancia para todas las instancias de la clase (ámbito de clasificador).

Los atributos y operaciones con ámbito de clasificador se denotan subrayando sus nombres. Si es que no se encuentran subrayados implica que son atributos/ operaciones con ámbito de instancia.

Los atributos con ámbito de clasificador son compartidos entre todas las instancias del tipo del clasificador.

En la mayoría de los casos, los atributos y las operaciones tienen ámbito de instancia. Sin embargo, si existe la necesidad de tener una sóla instancia para una operación, por ejemplo para generar un ID único entre instancias de clase, o para crear una instancia de la clase, debe usarse operaciones con ámbito de clasificador.

Las operaciones con ámbito de clasificador sólo pueden acceder a atributos con ámbito de clasificador.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Descripción del flujo de eventos

(Imagen: Diapostitivas del curso de IBM)

En algunos casos el flujo de eventos no es lo suficientemente claro y no basta con examinar los mensajes que se envían los objetos participantes. Es ahí donde se requiere añadir descripciones adicionales a los diagramas de interacción.

Para facilitar la lectura del diagrama a observadores externos se pueden agregar anotaciones temporales, notas sobre comportamiento condicional o aclaraciones sobre el funcionamiento de operaciones.

Por lo general, el nombre de la operación no basta para explicar porque la operación debe realizarse. Las notas textuales y los scripts en el margen pueden ser necesarios para aclarar un diagrama de interacción. También son necesarios para representar flujos de control como bucles y decisiones. Además, las etiquetas textuales sirven para relacionar puntos de extensión en el caso de uso con ubicaciones específicas en los diagramas de interacción.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Categorizar mecanismos de análisis

(Imagen: Edgar Degas - Ensayo)

Identificar los clientes de cada mecanismo de análisis: Examinar todos los clientes de un mecanismo de análisis dado, observando las características que requiere del mecanismo. Por ejemplo, un número de objetos de análisis pueden hacer uso del mecanismo de persistencia, pero sus requerimientos pueden variar: una clase que tiene mil instancias persistentes tiene requerimientos de persistencia diferentes que una clase con cuatro millones de instancias persistentes. Del mismo modo, una clase cuyas instancias deben proporcionar la data en milisegundos requiere un enfoque diferente al de una clase que accede a la data a través de aplicaciones batch.

Identificar perfiles de características para cada mecanismo de análisis: Pueden existir muchos perfiles de caracterísitcas, que difieran en nivel de performance, seguridadm costo y otros. Cada mecanismo de análisis es diferente, así que a cada mecanismo se le asignarán características diferentes. Muchos mecanismos requieren estimados del número y tamaño de instancias a administrar. El movimiento de grandes cantidades de data a través del sistema crea problemas de performances que hay que tratar.

Agrupar a los clientes de acuerdo al uso de perfiles de características: Identificar un mecanismo de diseño para grupos de clientes que compartan un mecanismo de análisis con un perfil de características similar. Este agrupamiento nos brinda una versión inicial de los mecanismos de diseño. Perfiles de características diferentes pueden originar mecanismos de diseño diferentes que surgen de un mismo mecanismo de análisis.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Pseudo estados

(Imagen: Diapostitivas del curso de IBM)

• Estado inicial: Es el estado en el que se encuentra el objeto cuando es creado. Es obligatorio, y sólo se puede tener un estado inicial.
• Alternativa: Evaluación dinámica de condiciones de guarda. Sólamente el primer segmento tiene un trigger.
• Estado final: Indica el fin de la vida del objeto. Es opcional, y puede haber más de uno.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Modelar transacciones

(Imagen: Edgar Degas - Bailarina con Bouquet de flores)

Las transacciones definen un grupo atómico de invocaciones a operaciones: se realizan todas o ninguna. En el contexto de persistencia, una transacción define un grupo de cambios a un grupo de objetos que o son realizados todos o no se realiza ninguno. Las transacciones brindan consistencia, ya que se aseguran que los objetos pasen de un estado consistente a otro. Si todas las operaciones especificadas en la transacción no se pueden realizar (por lo general porque ocurrió un error), se cancela la transacción y los cambios realizados durante la transacción son revertidos.

Las condiciones de error anticipadas representan flujos de eventos excepcionales en los casos de uso. En otras ocasiones, las condiciones de error ocurren debido a fallas en el sistema. Las condiciones de error deben documentarse en las interacciones. Los errores simples y las excepciones pueden mostrarse en el lugar en el que ocurren, mientras que los errores complejos pueden requerir sus propias interacciones. Los modos de falla de objetos específicos pueden mostrarse en máquinas de estado. El manejo de estos modos de falla puede mostrarse en la interacción donde se presenta la excepción.

Las transacciones se pueden representar textualmente mediante scripts o por mensajes explícitos.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

La vista de despliegue

(Imagen: Diapostitivas del curso de IBM)

Las actividades de describir la distribución se centran en la vista de despliegue.

La imagen que acompaña al post muestra el modelo de Rational para describir la arquitectura de sofware. Para cada vista se muestra al stakeholder interesado y los temas que la vista trata.

La vista de despliegue contiene la descripción de los nodos físicos y como éstos están interconectados, junto a la asignación de hilos de control (de la vista de procesos) a estos nodos físicos.

La vista de despliegue es parte del modelo de despliegue y sólo es necesaria si el sistema es distribuido.

Nota: Todos los procesadores son significativos para la arquitectura, por lo que la vista de arquitectura contiene a todos los procesadores.

La vista de despliegue se representa gráficamente mediante diagramas de despliegue.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Diseño de Clases

(Imagen: Edgar Degas - Miss La La en el Circo Fernando)

• El propósito del diseño de clases es asegurarse que las clases brinden el comportamiento requerido por las realizaciones de casos de uso.
• Las clases deben corresponderse con alguna entidad del lenguaje de programación a utilizar, de modo que esta correspondencia tenga como resultado un código de calidad.
• Una máquina de estados es una herramienta mediante la cúal describimos los eventos que ocasionan las transiciones de estados en un objeto en especial. No todos los objetos requieren máquinas de estado.
• Un estado es una condición en la vida del objeto. Un evento es una ocurrencia específica (en el tiempo y el espacio) de un estímulo, que ocasiona una transición de estados. Una transición es el cambio de un estado original a un estado resultante, producto de un estímulo. Una condición de guardia es una expresión Booleana en función a los atributos del objeto, que permite una transición sólo si su valor es verdadero. Una acción es una ejecución atómica que ocasiona un cambio de estados, o el retorno de un valor. Una actividad es una ejecución no-atómica dentro de una máquina de estados.
• Una dependencia es una relación entre dos objetos. Es una relación no-estructural, mientras que una asociación es una relación estructural.
• Una clase estructurada es una clase que contiene partes o roles, que conforman su estructura y realizan su comportamiento. Un conector modela un vínculo de comunicación entre partes interconectadas.
• Son objetivos del diseño de clases:

1. Identificar clases y relaciones necesarias para dar soporte a la implementación de los mecanismos arquitectónicos.
2. Identificar y analizar las transiciones de estados, en los objetos de clases manejadas por estados.
3. Refinar las relaciones, operaciones y atributos.

Véase también:

• ¿Qué es un conector?
• Definir métodos
  

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Diseño de Subsistemas

(Imagen: Edgar Degas - Cantante con guantes)

• En la actividad de diseño de sub-sistemas, se explora a detalle las responsabilidades de todos los sub-sistemas. Se definen y afinan las clases necesarias para implementar estas responsabilidades y las dependencias del sub-sistema, según sea el caso.
• Las puertas (gates) son puntos de conexión de un mensaje que ingresa o sale de la interacción modelada. Los mensajes dentro de la interacción pueden conectarse con la puerta.
• Si es que un subsistema depende de otro subsistema, la dependencia debe realizarse hacia la interfaz del subsistema requerido, y no en el sub-sistema mismo o cualquier elemento dentro del subsistema. Esto permite la sustitución de elementos de diseño por otros que ofrezca el mismo comportamiento.

Véase también:

• ¿Qué son Puertas?
• Guías para subsistemas
  

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Diseño de Casos de Uso

(Imagen: Edgar Degas - En el café-concert: La canción del perro)

• La actividad de diseño de casos de uso es donde los elementos de diseño (clases de diseño y sub-sistemas) implementan los mecanismos arquitectónicos. Su fin es afinar:

1. Las realizaciones de casos de uso en términos de interacciones
2. Los requerimientos de las operaciones de las clases de diseño
3. Los requerimientos de las operaciones de los sub-sistemas de diseños y/o sus interfaces.

• El encapsulamiento de las interacciones de sub-sistemas significa que:

1. Las interacciones pueden ser descritas en muchos niveles.
2. Las interacciones del sub-sistema pueden ser descritas en su propio diagrama de interacción.

• Las ventajas de encapsular las operaciones de los subsistemas son que las realizaciones de casos de uso:

1. Son menos recargadas
2. Pueden ser creadas antes de la creación del diseño interno de los sub-sistemas
3. Son más genéricas y fáciles de cambiar.

• El propósito de unificar clases y subsistemas es asegurarse que cada elemento de diseño represente un concepto único bien definido, sin responsabilidades sobrepuestas. Es importante unificar las clases identificadas y los subsistemas para asegurar un modelo homogéneo y consistente.

Véase también:

• Puntos clave - Diseño de casos de uso
• Vista General - Diseño de casos de uso
• Refinamiento de Realizaciones de Casos de Uso
• Encapsular interacciones de subsistemas
  

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Describir la distribución

(Imagen: Edgar Degas - Retrato de Miss Cassatt)

• Es en la actividad de describir la distribución donde los procesos definidos en la actividad de "Describir la arquitectura de ejecución" son asignados a nodos físicos.

• Un nodo es un objeto físico que representa un recurso computacional, y por lo general posee memoria y capacidad de procesamiento. Los objetos en tiempo de ejecución y los componentes se ejecutan en nodos.

• Como estereotipos comunes para los nodos tenemos a "Processor" y "Device".

• Los procesos deben ser asignados a dispositivos hardware para ejecutarse, de modo que se distribuya la carga del sistema. Los procesos que requieren tiempos de respuesta cortos deben asignarse a los procesadores más rápidos. Además, debe considerarse:

1. La capacidad del nodo (en términos de memoria y poder de procesamiento)
2. Ancho de banda de los medios de comunicación (bus, LANs, WANs)
3. Disponibilidad del hardware y vías de comunicación

• Es necesario establecer una correspondencia entre la Vista de Implementación y la Vista de Despliegue para ver la distribución de los archivos binarios. Se utiliza un diagrama de despliegue para mostrar a los nodos, interconectados mediante asociaciones. Las asociaciones indican una vía de comunicación entre nodos.

Véase también:

• ¿Qué es despliegue?
• ¿Qué es un nodo?
• Contexto: Describir la distribución
• Consideraciones: Asignación de procesos a nodos
• ¿Qué es un conector?
  

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Describir la arquitectura de ejecución

(Imagen: Edgar Degas - El amateur)

• En la actividad de describir la arquitectura de ejecución, los hilos de control independientes son identificados y los elementos de diseño son asignados a estos hilos de control. Esta actividad se centra en la Vista de Procesos de la arquitectura.

• Un proceso es un entorno de ejecución y espacio en memoria dentro del cual las instancias de clase y los subsistemas residen y se ejecutan. El entorno de ejecución puede ser dividido entre uno o más hilos de control.

• Un hilo de control es un cálculo independiente "corriendo" dentro del entorno de ejecución y espacio en memoria definidos para el proceso que lo contiene.

• Los hilos de control separados son necesarios cuando:

1. Se utilizan varios CPU's y/o nodos
2. Se necesita incrementar la utilización del CPU
3. Se establecen prioridades en las actividades
4. Se quiere una aplicación escalable (para el balance de carga)
5. Mejorar la disponibilidad del sistema.
6. Se busca dar soporte a los subsistemas principales.

• Se recomienda que se modele la Vista de Procesos dentro de la Vista Lógica (o sea, usando clases activas y objetos)

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Identificar mecanismos de diseño

(Imagen: Edgar Degas - Jóvenes espartanos ejercitándose)

• Los mecanismos de análisis nos proveen de un grupo de servicios conceptuales que son utilizados por los objetos de análisis. Nos ofrecen una manera conveniente de comportamientos complejos por los que nos preocuparemos más adelante, pero que están fuera del alcance de las actividades de análisis.
• Un patrón codifica una porción de conocimiento específico producto de la experiencia práctica. Los patrones son un ejemplo de como un buen modelamiento soluciona problemas reales.
• Un framework difiere de un patrón de análisis o de diseño en escala y alcance. Los frameworks son una solución esquemática a un problema en particular, sin hacer énfasis en detalles específicos.
• El propósito de categorizar los mecanismos de análisis es afinar la información recolectada. Los pasos para realizarla son:

1. Identificar los clientes de cada mecanismo de análisis
2. Identificar perfiles de características para cada mecanismo de análisis
3. Agrupar los clientes de acuerdo al uso de los perfiles de características
4. Proceder ascendentemente y realizar un inventario de los mecanismos de implementación que se tienen a disposición

Véase también:

• Documentar mecanismos arquitectónicos
• Documentar mecanismos arquitectónicos (II)
• Mecanismo de diseño y mecanismos de implementación
  

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Identificar elementos de diseño

(Imagen: Edgar Degas - Retrato de la familia Belleli)

• En la actividad de identificación de elementos de diseño, las clases de análisis son afinidas con el fin de obtener elementos de diseño: clases de diseño y subsistemas.
• Una interfaz es un elemento de modelado que define un conjunto de comportamientos (un grupo de operaciones) que son ofrecidos por un elemento clasificador (que puede ser una clase, un subsistema o un componente)
• Un subsistema provee interfaces por medio de las cúales se accede a los comportamientos que provee. Los paquetes no proveen comportamiento, son simples contenedores de objetos que sí poseen comportamiento.
• Los subsistemas son elementos de diseño "reemplazables": dos subsistemas (o clases, según sea el caso) que realizan la misma interfaz son intercambiables.
• Los subsistemas soportan múltiples variantes de implementación. Los subsistemas pueden usarse al modelar una o varias variantes de implementación. Hay dos maneras de encontrar subsistemas- descendente, como en Análisis Arquitectónico y en Diseño, y ascendente, como se hace en el diseño de casos de uso.
• La división en capas nos provee de un particionamiento lógico de los paquetes dentro de capas estableciendo ciertas reglas en lo concerniente a la relación entre capas.
• Al particionar, se debe tratar de evitar dependencias circulares, dado que hacen imposible la reutilización de un paquete sin su paquete dependiente.

Véase también:

• Subsistemas e Interfaces
• Tips para asociación de paquetes
• Identificar clases de diseño
• Contexto: Identificar elementos de diseño
• Vista General: Identificar elementos de diseño
  

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Análisis de casos de uso

(Imagen: Edgar Degas - Bailarina de catorce años)

• Es en el análisis de casos de uso donde identificamos las clases iniciales de nuestro sistema.
  

• Una realización de casos de uso describe como un caso de uso es realizado dentro del modelo de diseño en términos de colaboraciones de objetos.
  

• Las clases de análisis nos proveen de una forma de capturar los comportamientos solicitados, de modo que se pueda realizar una exploración inicial de la composición del sistema y de su modo de acción. Los tres estereotipos de análisis son: Entity, boundary y control.
  

• Es necesario examinar las clases para verificar que tengan responsabilidades consistentes. Cuando las responsabilidades de la clase divergen, es necesario dividir la clase en dos o más clases. Luego de esto, se tienen que sincronizar los diagramas de interacción.

• También hay que asegurarse que no existan dos clases con responsabilidades similares.

• La multiplicidad nos permite saber los límites máximos y mínimos de relaciones que un objeto dado puede tener con objetos de otras clases; y si es que estas asociaciones son obligatorias.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Análisis arquitectónico

(Imagen: Edgar Degas - At the races)

• El propósito del análisis arquitectónico es definir una arquitectura inicial para el sistema basada en la experiencia ganada de sistemas similares o dominios de problema semejantes.

• Un paquete es un mecanismo de uso general para organizar elementos en grupos.

• Las capas son usadas para encapsular límites conceptuales entre diferentes tipos de servicios y proveer abstracciones útiles que faciliten la comprensión del diseño. Algunas capas típicas son: capa de aplicación, capa específica del negocio, middleware y software del sistema.

• Los mecanismos de análisis capturan aspectos clave de la solución de manera independiente de la plataforma. Podemos mencionar aquí a los mecanismos de manejo de persistencia, de comunicación entre procesos, de manejo de errores, de notificación, de mensajes, etc.

• Las actividades de las disciplinas de requerimientos y de modelado del negocio nos permiten descubrir conceptos clave que el sistema debe ser capaz de procesar. Estos conceptos se manifiestan como abstracciones de diseño principales. Debido a que este trabajo ya se encuentra realizado, no es necesario repetir la identificación de abstracciones principales durante el análisis de casos de uso.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Requerimientos: Visión general

(Imagen: Edgar Degas - La toilette)

• Los artefactos de la disciplina de requerimientos de RUP incluyen: el modelo de casos de uso, el glosario y las especificaciones suplementarias.

• Cada caso de uso en el modelo muestra paso a paso como el sistema interactúa con los actores y qué realiza exactamente el sistema en el caso de uso. La especificación de casos de uso es el documento donde están presentes todas las propiedades del caso de uso.

• Un modelo de casos de uso describe los requerimientos funcionales del sistema en términos de casos de uso. Es un modelo de la funcionalidad deseada del sistema y su entorno.

• Un actor representa un conjunto coherente de roles que los usuarios asumen al interactuar con los casos de uso.

• Un caso de uso es una secuencia de acciones que realiza el sistema para obtener un resultado observable que es de valor para un actor en especial. Los casos de uso incluyen flujo de eventos, relaciones, pre-condiciones y post-condiciones.

• Cada caso de uso posee una red de flujos de eventos, donde un escenario es una instancia de un flujo de eventos específico.

• La especificación suplementaria contiene los requerimientos que no se relacionan con un caso de uso específico.

• El glosario define una terminología común para todos los modelos. Es utilizado para facilitar la comunicación entre los expertos del dominio y los desarrolladores.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más

Análisis y Diseño: Visión General

(Imagen: Edgar Degas- Músicos de Orquesta)

Supuestamente, debería publica el post de visión general de la disciplina de requerimientos, pero me lo dejé olvidado en el trabajo xD, así que mejor voy avanzando con lo de análisis y diseño. ¡Prometo regularizar el lunes!

El propósito de la disciplina RUP de análisis y diseño es: Transformar los requerimientos en un diseño del sistema, iniciar el desarrollo de una arquitectura robusta para el sistema y adaptar el diseño para que se corresponda con el entorno de implementación, de modo que tenga un alto desempeño.

Los artefactos de entrada para la disciplina de análisis y diseño son: el modelo de casos de uso, el glosario y la especificación suplementaria. Los artefactos de salida son el modelo de diseño, el modelo de datos y el documento de arquitectura.

Las vistas 4+1 de la arquitectura y sus roles son: Vista de casos de uso (funcionalidad), Vista Lógica (Estructura), Vista de Implementación (administración del software), Vista de Procesos (desempeño, escalabilidad y rendimiento) y Vista de Despliegue (topología del sistema, entrega, comunicación de instalación)

El análisis se centra en comprender el problema. Hace énfasis en un diseño idealizado, el comportamiento, la estructura del sistema, los requerimientos funcionales y produce un modelo pequeño

El diseño se centra en comprender la solución. Hace énfasis en las operaciones y los atributos, el desempeño, está cercano al código final, muestra ciclos de vida de los objetos, refleja los requerimientos no funcionales y produce un modelo grande.

La arquitectura de un sistema implica una serie de decisiones significativas acerca de la organización de un sistema software. La arquitectura puede ser vista como un conjunto de decisiones clave de diseño. La arquitectura es un conjunto de restricciones para el sistema.

Basado en el material del curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0

Leer más