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

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

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

Á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

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

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

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

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

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

Mock: Design and Implementation Mechanisms

(Imagen: Diapostitivas del curso de IBM)

A design mechanism:

A. captures the key aspects of a solution in a way that is implementation-independent
B. specifies the exact implementation of the mechanism and is bound to a certain technology
C. is the same as a design pattern
D. assumes some details fo the implementation environment, but is not tied to a specific implementation.

Durante el análisis arquitectónico se identifican los mecanismos arquitectónicos principales que puede requerirse para la solución de problemas. Es necesario afinar estos mecanismos a incorporarles temas de implementación.

Los mecanismos de diseño asumen ciertos detalles del entorno de implementación, pero no están "amarrados" a una implementación específica (a diferencia de los mecanismos de implementación). Como ejemplos, podemos mencionar:
  • Persistencia: RDBMS, OODBMS, etc.
Los mecanismos de implementación son usados durante el proceso de implementación. Son refinamientos de los mecanismos de diseño, y especifican la implementación exacta del mecanismo. Están vinculados a una tecnología en especial, a un lenguaje de implementación, proveedor, etc. Algunos mecanismos de implementación incluyen el lenguaje de programación actual, base de datos (Oracle, Sybase) y tecnologías de distribución (COM/DCOM, CORBA).

Por lo expuesto, nos quedaríamos con la alternativa D.

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

Pregunta tomada de Elite Certify

Mock: What Is a Connector?



(Imagen: Diapostitivas del curso de IBM)

Which type of mechanism is a connector on a deployment diagram?

A. backup
B. communication
C. transaction
D. computation

Los conectores pueden dibujarse entre nodos. Representan mecanismos de comunicación y pueden ser descritos como medios físicos (por ejemplo, Ethernet, fibra óptica) o por protocolo de software (por ejemplo, TCP/IP, RS-232). Se puede usar un estereotipo para especificar el tipo de conector.

Ahora ya está claro que la B es la respuesta correcta.

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

Pregunta tomada de Elite Certify

Mock: Process-to-Node Allocation Considerations


(Imagen: Diapostitivas del curso de IBM)

What is an important consideration when allocating processes to nodes?
A. minimizing network traffic
B. minimizing power consumption
C. utilizing all available nodes
D. physical distance between nodes

Los procesos deben asignar a dispositivos hardware para su ejecución de modo que se distribuya la carga del sistema.

Si la arquitectura seleccionada implica o requiere un patrón de distribución específico, este debe realizarse.

Los procesos que requieren tiempos de respuesta rápidos deben asignarse a los procesadores más veloces.

Los procesos deben colocarse en los nodos de modo que se minimice el tráfico de red. El tráfico de red, en la mayoría de los casos, es costoso. Los procesos que interactúan con frecuencia deberían ser colocados en el mismo nodo. Los procesos que interactúan ocasionalmente pueden residir en nodos diferentes.

Otras consideraciones:
  • Capacidad del nodo (en términos de memoria y capacidad de procesamiento)
  • Medio de comunicación y ancho de banda (bus, LANs, WANs)
  • Disponibilidad de hardware y vías de comunicación
  • Requerimientos de ruteo para redundancia y tolerancia de fallas
Es un tanto redundante, pero se debe indicar que la A es la respuesta.

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

Pregunta tomada de Elite Certify

Mock: Encapsulating Subsystem Interactions


(Imagen: Diapostitivas del curso de IBM)

Why would you use subsystem interfaces rather than subsystem instances on sequence diagrams?

A. to make it easier to model subsystems during Subsystem Design
B. to make use-case realizations easier to change
C. to ease sequence diagram maintenance when message signatures change
D. To reduce the number of classes needed to implement the subsystem.


Para lograr la sustitución mutua de subsistemas que realizan la misma interfaz, sólamente las interfaces deben ser visibles en los diagramas de interacción; caso contrario todos los diagramas necesitarían cambiarse cuando un subsistema es sustituido por otro.

En un diagrama de interacción, enviar un mensaje a una interfaz significa que cualquier subsistema que realiza la interfaz puede sustituir a la interfaz en el diagrama.

En muchos casos, no existen mensajes salientes de la interfaz, dado que subsitemas diferentes que realizan la interfaz pueden enviar mensajes diferentes. Sin embargo, si se necesita señalar que mensajes deberían ser enviados de cualquier subsistema que realiza la interfaz, esos mensajes pueden originarse de la interfaz en el diagrama de secuencia.

Con este enfoque, nos centramos en los servicios al describir las interacciones, y no en como se implementan los servicios en los elementos de diseño. Esto se conoce como "Diseño por contrato", y es uno de los principios de desarrollo robusto de software usando mecanismos de abstracción y encapsulamiento.

La descripción de como se implementan los servicios es tema de las actividades de Diseño de Subsistemas (para los subsistemas de diseño) y de Diseño de Clases (para las clases de diseño).

Entonces, la B sería nuestra respuesta.

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

Pregunta tomada de Elite Certify

Mock: Define Methods

(Imagen: Edgar Degas - Ensayo de Ballet)

What is the relationship between operation and method?

A. The terms are synonymous
B. An operation describes how a method is implemented
C. A method describes how an operation is implemented
D. There is no relationship

Un método especifica la implementación de una operación. Describe como trabaja la operación: no sólamente qué es lo que realiza.

Un método debe definir:
  • Cómo se implementarán las operaciones
  • Como se implementarán los atributos y como se usarán para implementar las operaciones
  • Como implementarán las operaciones y cómo se usarán para implementar las operaciones.
Los requerimientos varían según la situación. Sin embargo, una especificación de métodos para una clase debe contener lo siguiente:
  • Qué se debe realizar en función a los requerimientos
  • Qué otros objetos y operaciones van a ser utilizados
Si queremos entrar a más detalle:
  • Cómo se implementan los parámetros
  • Algunos algoritmos especiales a utilizar.
En muchos casos el comportamiento requerido para la operación ya está suficientemente definido por el nombre de la operación, su descripción y sus parámetros; por lo que los métodos se implementan directamente en el lenguaje de programación. Cuando la implementación de una operación requiere el uso de un algoritmo específico, o requiere más información que la presente en la descripción de la operación, es necesaria una descripción de método separada.

Por esto, la C es nuestra alternativa.

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

Pregunta tomada de Elite Certify

Mock: Identify Design Elements in Context

(Imagen: Diapostitivas del curso de IBM)

Identify Design Elements is part of which workflow detail?

A. Define a Candidate Architecture
B. Design Components
C. Perform Architectural
D. Refine the Architecture

La imagen mostrada es una versión a la medida del flujo de Análisis y Diseño del Rational Unified Process (RUP). La actividad de Identificar Elementos de Diseño pertenece al detalle del flujo de Refinar la Arquitectura.

En análisis arquitectónico se hizo un intento inicial de definir las capas del sistema, haciéndo énfasis en las capas superiores. En el análisis de casos de uso, se analizaron los requerimientos y las responsabilidades fueron distribuidas entre las clases de análisis.

En la actividad de Identificar Elementos de Diseño, las clases de análisis son refinadas y convertidas en elementos de diseño (clases de diseño y subsistemas).

En el análisis de casos de uso, la principal preocupación era el "qué". Ahora en actividades de arquitectura (como el diseño), nos importa el "cómo". La arquitectura es donde uno toma las decisiones.

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

Pregunta tomada de Elite Certify

Mock: Describe Distribution in Context


(Imagen: Diapostitivas del curso de IBM)

In which OOAD activity is the distribution mechanism identified?

A. Identify design elements
B. Identify design mechanisms
C. Class Design
D. Architectural Analysis

En las actividades de análisis arquitectónico, se identificó como mecanismo de análisis a la distribución. Este mecanismo de análisis fue usado para indicar que clases necesitaban ser distribuidas.

En las actividades de identificar elementos de diseño, se definieron los subsistemas, sus interfaces y dependencias. Se definieron también las clases de diseño iniciales y los paquetes a los que pertenecen. Asimismo, se seleccionaron las tecnologías y los mecanismos que dan soporte a la distribución en las actividades de Identificar Mecanismos de diseño.

En las actividades de Describir la arquitectura de ejecución, se identifican los hilos de control independientes y los elemenos de diseño son asignados a estos hilos de control.

En la actividad de Describir la distribución, la arquitectura física es modelada usando nodos y conexiones. Los hilos de control independientes identificados en la actividad de Describir la arquitectura de ejecución son asignados a estos nodos. Describir la distribución es una actividad separada, del mismo nivel que Identificar Elementos de Diseño e Identificar Mecanismos de Diseño.

Si el sistema a desarrollar sólo se ejecutará en un nodo, entonces no hay necesidad para un modelo de despliegue separado. En ese caso, la actividad de Describir la Distribución puede ser obviada.

Según esto, la alternativa sería la D, pero Elite Certify considera que es la B. Lo dejo a su criterio.


Mock: Identifying Design Classes

(Imagen: Diapostitivas del curso de IBM)

When identifying design elements, a simple analysis class will map to a:

A. active class
B. interface
C. design class
D. subsystem

Si la clase de análisis es simple y representa una abstracción lógica, entonces puede corresponderse con una clase de diseño. Por lo general, las clases entity permanecen intactas durante el diseño.

A través de las actividades de diseño, las clases de análisis son transformadas en elementos de diseño (como clases de diseño, paquetes o subsistemas). Algunas clases de análisis pueden dividirse, fusionarse, eliminarse o ser manipuladas. Existe una relación muchos a muchos entre las clases de análisis y los elementos de diseño. Las posibles correspondencias incluyen las siguientes:

  1. Una sóla clase en el modelo de diseño
  2. Una parte de una clase del modelo de diseño
  3. Una clase compuesta en el modelo de diseño (o sea que las partes de este compuesto no fueron modeladas explícitamente en el modelo de análisis)
  4. Un grupo de clases que heredan de la misma clase en el modelo de diseño.
  5. Un grupo de clases relacionadas funcionalmente en el modelo de diseño (por ejemplo, un paquete)
  6. Un subsistema en el modelo de diseño.
  7. Una relación en el modelo de diseño.
  • Una relación entre clases de análisis puede convertirse en una clase en el modelo de diseño.
  • Una parte de una clase de análisis puede corresponderse con hardware, y no ser considerada en el modelo de diseño.
  • Cualquier combinación de las anteriores.

Por lo que la C sería nuestra elección.


Mock: Documenting Architectural Mechanisms (II)

(Imagen: Diapostitivas del curso de IBM)

Which process document describes design mechanisms, any mappings between design mechanism, and the details regarding their use?

A. Software Architecture Document
B. Design Guidelines
C. Vision Document
D. Software Developement Plan

Los patrones de diseño son colaboraciones parametrizadas. Los mecanismos arquitectónicos pueden tratarse como patrones y ser documentados de la misma manera (es decir, como colaboraciones parametrizadas).

Como los patrones, una colaboración parametrizada de un mecanismo arquitectónico tiene un aspecto estructural y un aspecto de comportamiento. La parte estructural consiste en las clases cuyas instancias implementan el mecanismo, así como sus relaciones (la vista estática). El aspecto de comportamiento describe como las instancias colaboran (o sea, intercambian mensajes) para implementar el mecanismo (la vista dinámica).

El rol del arquitecto es construir e integrar los mecanismos, y verificar que estos funcionen. El arquitecto debe imponer los mecanismos para el resto del diseño del sistema. Así, para cada mecanismo arquitectónico debe proveer una vista estática y dinámica, acompañadas por reglas de uso.

Los mecanismos, la correspondencia entre ellos, y los detalles concernientes a su uso deben documentarse en las Guías de Diseño específicas al proyecto, y no en el Documento de Arquitectura del Software (SAD). El SAD captura las elecciones de arquitectura hechas para el sistema en base a los requerimientos funcionales y no-funcionales. Las Guías de diseño son para diseños que aún no han sido realizados. En muchas organizaciones, los documentos de guías de diseño existen como un activo organizacional independiente de un proyecto en particular. Las guías representan el conocimiento reutilizable de diseño que posee la organización para un dominio en particular. Pueden requerir cierto afinamiento para ajustarse a un proyecto. Entonces, el SAD es la representación arquitectónica (o una parte significativa de la misma). Las guías de diseño nos muestran como diseñar es una forma muy específica (no conceptual).

Desde mi modesto punto de vista, la respuesta es la B (pero el PDF dice que es la C).


Mock: Package Coupling-Tips


(Imagen: Diapostitivas del curso de IBM)

Given the following configuration:

Package A, which contains class aClass, is in the presentation layer.
Package B, which contains a class bClass and an interface bInterface is in the business layer.
Package C, which contains cClass is in the data layer.

Which is a poor practice?

A. aClass calls a method in bClass.
B. aClass has an attribute of type cClass
C. aClass realizes bInterface
D. bClass realizes bInterface

La asociación entre paquetes es positiva y negativa: positiva, porque la asociación implica reutilización, y negativa, porque la asociación implica dependencias que dificultan los cambios y evolución del sistema. Algunos principios para la asociación de paquetes son:
  • Los paquetes no deberían ser co-dependientes. Por ejemplo, dos paquetes no deben depender el uno del otro. En estos casos, los paquetes necesiten ser reorganizados para eliminar estas dependencias mutuas.
  • Los paquetes de las capas inferiores no deben depender de los paquetes de las capas superiores. Los paquetes sólo deben ser dependientes de paquetes en la misma capa o en la capa inferior inmediata. Para estos casos, la funcionalidad necesita ser re-particionada. Una solución es establecer dependencias en términos de interfaces, y organizar las interfaces en una capa inferior.
  • En general, las dependencias no deben saltarse capas, a menos que el comportamiento dependiente sea común a todas las capas, y la alternativa sea pasar por las capas a través de invocaciones de operaciones.
  • Los paquetes no deben depender de subsistemas, sólamente de otros paquetes o interfaces.
Entonces ya está claro que la alternativa B es la adecuada.

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

Pregunta tomada de Elite Certify

Mock: Use-Case Realization Refinement

(Imagen: Diapostitivas del curso de IBM)

Which task is performed during use-case realization refinement?
A. identify participating classes
B. allocate responsabilities among classes
C. model messages between classes
D. model associated class relationships

Cada realización de caso de uso debe ser afinada para describir las interacciones entre los objetos de diseño participantes. Se debe realizar lo siguiente:
  • Identificar a los objetos que participan en el flujo de eventos del caso de uso. Estos objetos son instancias de clases de diseño y subsistemas, o pueden ser instancias de actores con los que interactúan los objetos participantes.
  • Representar a cada objeto participante en un diagrama de interacción. Los subsistemas se pueden representar como instacias de la interfaz del subsistema.
  • Ilustrar los mensajes intercambiados entre los objetos mediante flechas. El nombre del mensaje debe ser el nombre de la operación invocada. Para mensajes enviados a clases de diseño, la operación es una operación de la clase. Para mensajes enviados a subsistemas, la operación es una operación de la interface.
  • Describir lo que el objeto realiza al recibir el mensaje. Podemos hacer esto anexando un script o nota al mensaje correspondiente. Cuando la persona responsable de la clase del objeto asigne y defina sus operaciones, estas notas o scripts serán las bases de su trabajo.
Para cada realización de caso de uso, se debe ilustrar las relaciones de clase que dan soporte a las colaboraciones modeladas en los diagramas de interacción, creando uno o más diagramas de clases.

Lo que nos lleva a señalar a la D como respuesta correcta.

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

Pregunta tomada de Elite Certify

Mock: What Is a Connector?

(Imagen: Diapostitivas del curso de IBM)

In the diagram, what is E1?
A. connector
B. interface
C. ball and socket
D. plug-in

Un conector modela el vínculo de comunicación entre partes interconectadas. Por ejemplo:

  • Conector de montaje: Reside entre dos elementos (partes o puertos) en la especificación de implementación interna de una clase estructurada.
  • Conector de delegación: Reside entre un puerto externo (relay) y una parte interna de la especificación interna de una clase estructurada.

Para los conectores de delegación, las conexiones del entorno al puerto externo son tratadas como entrantes para el elemento interno al otro extremo del conector de delegación.

Por lo que la A sería nuestra alternativa.

Mock: Subsystem Guidelines

(Imagen: Diapostitivas del curso de IBM)

When possible, a subsystem should _____.
A. depend on other interfaces
B. only have dependencies to it, not from it
C. have a small, well-defined set of internal classes exposed as its API
D. run in its own process

Cada subsistema debe ser lo más independiente posible de otras partes del sistema. Debe ser posible modificar las diferentes partes del sistema independientemente de las otras partes. Esto minimiza el impacto de los cambios y facilita las tareas de mantenimiento.

Debe ser posiblr reemplazar cualquier parte del sistema por otra parte, siempre y cuando esta soporte las mismas interfaces. Para asegurar que los subsistemas sean elementos reemplazables en el modelo, es necesario cumplir las siguientes condiciones:

  • Un subsistema no debe exponer sus contenidos. Ningún elemento dentro del subsistema debe tener visibilidad pública. Ningún elemento externo al subsistema debería depender de la existencia de un elemento interno del subsistema.
  • Un subsistema debe depender sólamente de las interfaces de otros elementos del modelo, de modo que no sea dependiente directamente de elementos del modelo externos al subsistema. Una excepción a esta regla es cuando varios subsistemas comparten un grupo común de definiciones de clases, y estos subsistemas importan los contenidos de los paquetes que contienen estas clases comunes. Esto sólo debe realizarse con paquetes en las capas inferiores de la arquitectura, y sólo para asegurarse que las definiciones comunes de clases que deban intercambiarse entre subsistemas sean consistentes.
  • Todas las dependencias al subsistema deben ser dependencias hacia las interfaces del subsistema. Los clientes del subsistema son dependientes de la interfaz (o interfaces) del subsistema, y no de los elementos internos del subsistema. De este modo, un subsistema puede ser reemplazado por otro subsistema que realice las mismas intefaces.

Por lo que inferimos que la alternativa correcta es la A.

Mock: What Are Gates?

(Imagen: Diapostitivas del curso de IBM)

When modeling an internal subsystem interaction, the first message on a sequence diagram should be shown from a _____.
A. gate
B. proxy actor
C. subsystem proxy
D. dummy client class

Una puerta (gate) es parámetro que representa un mensaje que cruza los límites de la interacción o del fragmento de interacción. Los mensajes dentro de la interacción pueden conectarse a la puerta. Si la interacción es referenciada dentro de otra interacción, los mensajes deben conectarse a sus puertas. Cuando se ejecuta la interacción, los mensajes conectados a través de puertas serán entregados apropiadamente.

Una puerta se representa como un punto en el límite de un diagrama de secuencia. El nombre de la puerta es el nombre del mensaje conectado.

Habiendo explicado esto, creo que es obvio que nuestra respuesta es la A.

Mock: Use-Case Design Overview

(Imagen: Diapostitivas del curso de IBM)

What are two inputs to Use Case Design? (Choose two.)
A. Design Use-Case Realization
B. Services Model
C. Analysis Use-Case Realization
D. Subsystem Internal Design Model

El diseño de casos de uso es realizado por el diseñador, una vez por caso de uso.

Propósito:
  • Afinar las las realizaciones de casos de uso en términos de interacciones
  • Afinar los requerimientos de las operaciones de las clases de diseño
  • Afinar los requerimientos de las operaciones de los subsistemas de diseño y/o sus interfaces
Artefactos de entrada:
  • Modelo de análisis
  • Especificaciones suplementarias
  • Casos de uso
  • Realizaciones de casos de uso de análisis
  • Clases de diseño
  • Subsistemas de diseño
  • Modelo de diseño
  • Realizaciones de casos de uso de diseño
  • Interfaces
Artefactos resultantes:
  • Realizaciones de casos de uso de diseño
  • Modelo de diseño

Revisando el listado, ya sólo nos queda seleccionar las alternativas A y C.

Mock: Checkpoints - Use-Case Design

(Imagen: Diapostitivas del curso de IBM)

What are three questions that need to be answered when assessing the correctness and completeness of Use Case Design? (Choose three.)
A. Are the design mechanisms explicitly called out in the sequence diagrams?
B. Do the package/subsystem dependencies correspond to the relationships between the contained classes?
C. Has all behavior been distributed to the correct design elements?
D. Have all the main flows and/or subflows for this iteration been handled?

Debe revisarse el modelo de diseño en su totalidad para detectar problemas el particionado en capas y la distribución de responsabilidades. El propósito de la revisión del modelo como un todo es detectar problemas de gran escala que una revisión a detalle podría obviar.

Hay que verificar que la estructura total del modelo de diseño está bien formada, y detectar problemas de calidad de gran impacto que podrían no ser evidentes al observar los elementos de menor nivel.

Una vez que se ha revisado la estructura del modelo de diseño, es necesario escrutar el comportamiento del modelo. Primero, hay que asegurarse que no se han ignorado comportamientos revisando que todos los escenarios de la iteración actual han sido cubiertos mediante realizaciones de casos de uso. Todos los comportamientos de los flujos relevantes de los casos de uso deben ser descritos mediante realizaciones de casos de uso.

Luego, hay que asegurarse que el comportamiento en las realizaciones de casos de uso esté distribuido adecuadamente entre los elementos del modelo. Hay que asegurarse que las operaciones se usen correctamente, que todos los parámetros sean enviados y que los valores retornados sean del tipo correcto.

Es necesario garantizar que el comportamiento del sistema (expresado en realizaciones de casos de uso) se corresponda con el comportamiento requerido del sistema (expresado en casos de uso). Tambiñén hay que revisar que el comportamiento ha sido colocado adecuadamente en los elementos del modelo.

Los objetos participantes deben estar presentes de modo que realicen todos los comportamientos del caso de uso correspondiente.

Es necesario asegurar que la descripción del flujo de eventos clarifique como los diagramas se relacionan entre ellos.

Lo descrito se corresponde con las alternativas B, C y D.

Mock: What Is a Node?

(Imagen: Diapostitivas del curso de IBM)

Which run-time physical object represents a computational resource that often has memory and processing capability?
A. node
B. class
C. subsystem
D. connector

Los elementos esenciales de un diagrama de despliegue son los nodos y sus conectores. Un nodo es un objeto físico que representa a un recurso computacional, generalmente posee memoria así como capacidad de procesamiento.

Existen dos tipos de nodos en UML 2: Entornos de ejecución y dispositivos:
  • Los dispositivos pueden tener desplegados dentro de ellos software de ejecución que controla la funcionalidad del dispositivo en sí (recurso computacional físico con capacidad de procesamiento). Podemos mencionar a servidores de impresión, servidores de aplicaciones, estaciones de trabajo, dispositivos móviles, dispositivos embebidos, procesadores, etc. Los dispositivos pueden ser complejos y contener a su vez a otros dispositivos.
  • Los entornos de ejecución representan plataformas de ejecución particulares, como sistemas operativos (Win2K, VxWorks, etc), sistemas de gestión de base de datos (DB2), etc.

Con esto, es evidente que la A es la alternativa a elegir.

Mock: What is Deployment?

(Imagen: Diapostitivas del curso de IBM)

Which is an artifact?
A. database server
B. RSx Model
C. Java source file
D. J2EE EAR file

El despliegue el la asignación -o correspondencia- de artefactos de software a nodos físicos durante la ejecución.

Los artefactos son las entidades que son desplegadas en los nodos físicos, o sea procesos asignados a computadoras.

Los artefactos modelan entidades físicas: archivos, ejecutables, tablas de bases de datos, páginas web, etc.

Los nodos modelan recursos computacionales. Pueden ser computadoras, unidades de almacenamiento, etc.

Entonces, si han desarrollado antes aplicaciones J2EE, sabrán que la D es la respuesta correcta.

Mock: Documenting Architectural Mechanisms

(Imagen: Diapostitivas del curso de IBM)

Design mechanisms can be documented via a "mechanism" stereotyped use case.
Which three are typically included within this "mechanism" use case? (Choose three.)
A. one or more sequence diagrams that illustrate the behavioral aspect of the design mechanism
B. one or more class diagrams that illustrate the structural aspect of the design mechanism
C. classes, operations, attributes, or relationships stereotyped as "role" to indicate the element should be regarded as a placeholder for the actual design element
D. a use-case diagram indicating the mechanisms actors

Una forma de documentar los mecanismos es crear un paquete de Mecanismos Arquitectónicos en el paquete de Modelo de Diseño de la Vista Lógica. Cada mecanismo puede representarse por un caso de uso con el estereotipo de "mechanism". Las clases y diagramas de interacción del mecanismo deben adjuntarse al caso de uso con el estereotipo de "mechanism".

Existe también la necesidad de definir que elementos son concretos y cúales son roles que el diseñador debe asignar para aplicar un mecanismo. Una manera de modelar esta situación es mediante el estereotipo "role" en cualquier cosa (clase, operación, relación, atributo) que deba ser reemplazado posteriormente por un elemento de diseño. Esta convención nos facilita la aplicación del mecanismo dado que identificamos más fácilmente los elementos que el diseñador debe definir. Las clases concretas que dan soporte al mecanismo residen el capas del modelo de diseño. Las clases con el estereotipo de "role" residen el paquete de Mecanismos Arquitectónicos (o en un sub-paquete).

Por lo que es imperativo escoger las alternativas A, B y C.


Pregunta tomada del sample test para IBM 834

Mock: Subsystems and Interfaces

(Imagen: Diapostitivas del curso de IBM)

Which statement is true about design subsystems?
A. They encapsulate some of the behavior.
B. They represent an independent capability with clear interfaces.
C. They model a single implementation variant.
D. They can only contain classes.

Un subsistema es un elemento de modelamiento que tiene la semántica de un paquete, dado que puede contener a otros elementos del modelo, y la semántica de una clase, dado que posee comportamiento. Un subsistema realiza una o más interfaces, que definen el comportamiento que puede realizar.

Un subsistema puede representarse como un paquete UML con el esterotipo "subsystem".

Una interfaz es un elemento de modelamiento que define un conjunto de comportamientos (un grupo de operaciones) que son ofrecidos por un clasificador del modelo (o una clase, o un subsistema o un componente). Un clasificador puede realizar una o más interfaces. Una interfaz puede ser realizada por uno o más clasificadores.

Las interfaces no son clases abstractas, ya que las clases abstractas permiten implementar un comportamiento por defecto para alguno de sus métodos. Las interfaces no proveen de ningún comportamiento por defecto.

Las interfaces se representan como clases con el estereotipo "interface".

La realización es una relación semántica entre dos clasificadores. Un clasificador sirve como un contrato que el otro clasificador accede a llevar a cabo.

La relación de realización puede ser modelada como una línea no contínua que termina en una flecha apuntando al clasificador-contrato.

Esto nos lleva a pensar que la alternativa B es correcta.


Pregunta tomada del sample test para IBM 834