Recetario IBM 833-834



Estimados lectores, es de mi agrado informarles que ya soy IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2; así que como es ya tradición, procedo a contarles por lo que tuve que pasar:

Dado que ya tengo unas cuantas certificaciones en desarrollo de aplicaciones, pensé que el paso natural sería incursionar en el mundo de arquitectura de aplicaciones y análisis y diseño de sistemas. Explorando el mercado de certificaciones me encontré la SCEA (Sun Certified Enterprise Architect), la IBM 833-834 (IBM Certified Solution Designer - Object Oriented Analysis and Design) y la OCUP (OMG Certified UML Professional). Como trabajo en un partner de IBM, la IBM 833-834 era de importancia para la compañía, y aparte me salía gratis (si aprobaba, claro); por lo que esa fue mi elección.


Ahora era necesario determinar que leer y que estudiar. Los foristas de Javaranch recomendaban el UML Distilled de Fowler junto a Applying UML and Patterns de Larman. También dejaban bastante en claro que no se trataba de una certificación en UML, sino de Análisis y Diseño Orientado a Objetos desde la perspectiva RUP, por lo que se sugería tambien instalar el Rational Method Componser y ponerse a leer de ahí los temas de Análisis y Diseño según RUP (del los archivos "Help"). Como ven, es bastante material; por lo que comencé con una lectura rápida de UML Distilled (de modo que refrescaba mis nociones de UML) mientras veía como conseguirme el resto de libros.

Es entonces cuando mi jefe me comenta que por un contacto de la universidad tenía acceso al material de varios cursos de IBM. En web de la certificación, IBM te recomienda llevar el curso DEV475: Mastering Object-Oriented Analysis and Design with UML 2.0 como preparación para el examen, y para suerte mía mi jefe tenía la guía de estudio de ese cursito. Terminado el Fowler, procedí a revisar ese material.

La guía de estudio de IBM son las diapositivas del curso junto a notas explicativas al pie. Son catorce capítulos organizados en 3 volúmenes, y cubren todos los objetivos del exámen. Bueno, de los exámenes, porque para certificarte es necesario rendir primero el IBM 833 (Análisis) y luego el IBM 834 (Diseño). Del manual, el volumen I cubría los temas del primer examen y los volúmenes II y III se encargaban del segundo.

El material de IBM es bastante bueno, y hace una buena cobertura de UML, Paradigma Orientado a Objetos y RUP (que son los temas en los que te van a evaluar). He traducido algunas partes que me parecieron importantes, y pueden encontrarlas en el blog. Terminando de leer los tres volúmenes, me puse a buscar mock tests para ver que tan preparado me encontraba. En la web de IBM te dejan algunas preguntas de ejemplo, y Elite Certify ofrece unos mocks un tanto más extensos. Algunas de estas preguntas -junto a la respuesta- se encuentran también posteadas en el blog.

Hasta que llegó el día del exámen. Aprobé el IBM 833 con 83%, en gran medida gracias al material de IBM. Luego de una semana - para recuperar energías- me acerqué a dar el segundo exámen. El IBM 834 lo encontré un tanto más difícil que el primero, ya que fueron más incisivos con los temas de UML y RUP. Gracias a lo leído y a la suerte lo aprobé con 90%.

Esa es la historia. Probablemente, ahora ma anime por el OCUP (aprovechando lo estudiado de UML) o el IBM 839 (para capitalizar lo aprendido de RUP); pero aún no me decido. Antes, es necesario un merecido descanso xD.

Hasta otra!

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