h1

Los acordeones para el examen de certificación (Parte 1: UML)

10/03/2007

Wizdoc [Icon By Buuf]

Tips & Tricks: Acordeon SCEA: Seccion 1: Conceptos

A design guru thinks about how to create flexible designs that are maintainable and that can cope with change.

Head First Design Patterns, Freeman et al., Ed. O’Reilly

Pa’ pronto: estoy estudiando para el examen de certificación de arquitecto (Sun Certified Enterprise Architect – SCEA) y se me presentó la oportunidad de tomar, de forma gratuita, la versión beta del SCEA para Java 5. Lo bueno: es de a grapa e incluso si lo trueno me sirve muy bien para diagnosticar mis "áreas de oportunidad"; lo malo: tengo que presentar el examen el próximo 22 de Octubre. Por ello, estoy leyendo varios libritos de documentación de arquitecturas (como el libro Documenting Software Architectures: Views and Beyond por Clemens, et al), las dos guías de estudio que de a wilson me debo chutar (ambas con el título SCEA for J2EE Study Guide, tanto la guía de Sun Microsystems Press así como la de McGraw Hill) y ya viéndome un poco creativo, estoy repasando los EJBs y patrones de diseño (Head First EJB, de Sierra y Bates así como el Head First Design Patterns de Freeman et al)

Así entonces, estoy dejando aquí mis acordeones para que no se me vaya a olvidar el montón de información que debo repasar y/o aprender – jeje, sobre todo temas como la conectividad legada que siendo sinceros, nunca he llegado a implementar mas que por encimita, utilizando IDEs especializados, como el Weblogic Workshop.

Sección 1: Conceptos

  • Dibujar diagramas de UML
  • Interpretar diagramas de UML.
  • Describir el efecto del encapsulamiento, herencia y el uso de interfaces en las características arquitectónicas.
  • Diagrama de Caso de Uso: Representa los procesos dentro del sistema, que son visibles al mundo exterior – a los actores del sistema – que están siendo modelados así como las relaciones entre éstos.
    Diagrama de Caso de Uso

    • La relación includes implica que el primer caso de uso requiere el resultado del caso de uso incluido. En el diagrama para realizar una transacción primero es necesario autenticar al usuario.
    • La relación extends implica que el caso de uso que extiende se está agregando al caso de uso extendido. Esto sirve sobre todo para acomodar nueva funcionalidad. Por ejemplo, en el diagrama mostrado primero se pidió autenticar al usuario y posteriormente se pidió la funcionalidad de bitácora (log) que además de ser un caso de uso independiente, se incluyó en la funcionalidad de la autenticación.
    • La generalización (no mostrada en el diagrama pero que es una línea sólida con un triángulo vacío apuntando a la superclase) puede usarse para denotar especialización de casos de uso. Por ejemplo, podríamos desprender dos casos de uso llamados "Bitácora usuarios" y "Bitácora de transacciones" para denotar dos casos que se desprenden de la bitácora simple.
  • Diagramas de Clases/Paquetes/Objetos:
    Diagrama de Clases

    • La Agregación (Rombo vacío que parte del "contenedor") es equivalente a un "tiene un" donde ambas clases tienen un ciclo de vida independiente. Por ejemplo, un curso tiene estudiantes; puede darse de baja un curso sin eliminar a los estudiantes y un estudiante puede darse de baja de un curso sin eliminar al curso.
    • La Composición (Rombo negro que parte del "contenedor") es equivalente a un "esta compuesto por" donde las clases están estrechamente relacionadas; ambas desaparecen si alguna se elimina. Por ejemplo la relación pedido – embarque: un pedido de libros a Amazon puede tener varios embarques; si elimino un embarque desaparece ese pedido (pues debe recotizarse), e igualmente si elimino el pedido ya no hay embarques.
    • Como en los diagramas Entidad-Relación, las asociaciones son A (N A’s por cada B) >>> (N B’s por cada A) B. Por ejemplo: Empresa 1 >>> 1..* Empleado equivale a decir "por cada empresa hay 1 a N empleados; por cada empleado hay una y sólo una empresa".
  • Diagramas de Actividad/Estado: El diagrama de actividad captura el flujo de procesos del sistema; éste consiste de actividades, acciones, transiciones y estados inicial y final. Asimismo se presenta de forma general con columnas (swimlanes) que dividen los diferentes componentes que interactúan en dicho diagrama. Por otro lado, el diagrama de estados representa los cambios de estado de los objetos del sistema en respuesta a eventos generados desde el exterior.
    • Los eventos de un diagrama de estados se etiquetan de la siguiente manera: evento[condición o guardia]/actividad.
  • Misceláneos
    • Las clases abstractas son generalizadas (son siempre superclases de alguna otra).
    • Las interfaces son realizadas o implementadas (se denota por un conector con flecha cerrada vacía apuntando a la interfaz y línea punteada).
    • Encapsulamiento: Esconder – encapsular – los detalles de implementación de una clase de los objetos que le envían mensajes. El efecto principal del uso de esta técnica de POO es "agregar un nivel de abstracción" en la interacción entre clases. De esta manera, se logra mayor flexibilidad, extensibilidad y un menor acoplamiento en los componentes del sistema. Un buen ejemplo es la interfaz java.util.Iterator implementada en el Java Collections Framework: al pedir la implementación de Iterator a una lista nos devuelve un elemento de tipo java.util.Iterator pero la verdadera implementación de éste puede ser una clase dependiente de sistema (por ejemplo en el caso del JDK 1.4 la implementación verdadera de la funcionalidad del iterador se realiza mediante la clase BCSIterator pero nunca nos damos cuenta).
    • Herencia: Relación "es un". Las "subclases" son versiones más especializadas de una "superclase", heredando atributos y métodos de aquella e introduciendo sus propios atributos y métodos. Esto tiene como consecuencia la reutilización de código así como la especialización de componentes para tareas específicas.
    • Interfaces: Son clases especiales que definen un comportamiento particular que deberá ser implementado por aquellas clases que realizan dicha clase. Es la implementación de los lenguajes de programación orientados a objetos al encapsulamiento y en el caso particular de Java, al problema de la herencia múltiple.
  • 2 comentarios

    1. ta bien


    2. Es bueno pero deberías colocar mas ejemplos



    Responder

    Introduce tus datos o haz clic en un icono para iniciar sesión:

    Logo de WordPress.com

    Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

    Imagen de Twitter

    Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

    Foto de Facebook

    Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

    Google+ photo

    Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

    Conectando a %s

    A %d blogueros les gusta esto: