Modelado Estructural F E B R E R O,

Transcripción

1 Modelado Estructural F E B R E R O,

2 Modelado Estructural Sirve para describir los diferentes tipos y relaciones estáticas existentes entre los diferentes objetos de un sistema. A la hora de desarrollar software, debemos modelar correctamente el sistema previamente al desarrollo, pudiendo incorporar el patrón o los patrones de diseño que nos ayuden a optimizar la solución a un determinado problema.

3 Modelado Estructural Usa: Diagramas de clases, normalmente están formados por Clases, Interfaces y Relaciones (de dependencia, de realización, de generalización, de asociación -agregación y composición-, etc). Diagramas de casos de uso, que describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Diagramas de Secuencia, que muestran la secuencia de intercambio de mensajes, datos u operaciones del sistema o de ciertos componentes en un momento dado.

4 Diagrama de Clases Sirven para modelar las clases de un sistema, incluyendo el modelado de patrones Forman parte de la denominada vista estática del diseño del sistema

5 Diagramas de Clases Se usan para dar forma a distintos aspectos: Vocabulario del Sistema (identificar clases para abstracciones relevantes del problema). Colaboraciones (identificar clases e interfaces cuya interacción produzca el comportamiento deseado). Esquema lógico de Bases de Datos.

6 Diagramas de Clases Pueden presentar diferentes perspectivas o fines: Modelado conceptual, en el que se representan los conceptos del dominio en cuestión del problema. Diagrama de especificación, en el cual representamos los distintos tipos de entidades que se representan en una interfaz. Diagrama de implementación, donde se representan las clases tal y como serán implementadas.

7 Diagramas de Clases Elementos Clases Interfaces Asociaciones

8 Clases Unidad básica que encapsula la descripción abstracta de una agrupación de objetos y define los atributos y los métodos de esa serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objeto el suyo propio). Las clases se representan por cuadrados o rectángulos, con el nombre de la clase y, según sea necesario, los atributos y operaciones, todo ello en compartimentos diferenciados.

9 Clases Atributos: Lo normal para representar los atributos de una clase es mostrar su nombre y valor, pero también puede mostrarse su valor inicial, privacidad + Indica atributos públicos; # Indica atributos protegidos; - Indica atributos privados u otras propiedades.

10 Clases Operaciones: Las operaciones o métodos también se muestran al menos con su nombre, pudiendo mostrar sus parámetros y valores de retorno, así como su privacidad.

11 Clase (Ejemplo)

12 Interfaces Son clases abstractas, por lo que no puede haber objetos o instancias que sean creadas directamente a partir de ellas, por lo que contendrán métodos u operaciones, pero no atributos. Esto hace que haya clases que sí pueden heredarse de las interfaces pudiendo así instanciar objetos que realicen las operaciones recogidas en las interfaces.

13 Asociaciones Representa una relación entre clases Aporta la semántica y la estructura de las conexiones y relaciones entre objetos Son los mecanismos que permiten a los objetos comunicarse entre sí. Pueden especificar el propósito de la asociación, pudiendo ser unidireccionales o bidireccionales. En cada extremo de la asociación se incluye un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario.

14 Asociaciones En UML, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores no negativos, con un asterisco (*) representando el infinito en el lado máximo.

15 Herencia (Especialización/ Generalización): Esta relación indica que una subclase hereda los métodos y atributos especificados por una superclase, la subclase además de contar con sus propios métodos y atributos, tendrá los atributos y métodos visibles de la superclase. Se representa por una línea terminada en un triángulo en el lado de la superclase. Asociaciones

16 Asociaciones Agregación: Usada cuando se requiere componer objetos cuyo tipo sea la unión de otros tipos definidos por el desarrollador. Se representa por una línea terminada en un rombo blanco en el lado del agregador.

17 Asociaciones Composición: Es un caso de agregación, pero con una relación más potente, de forma que el agregador no tiene sentido sin el agregado. Se representa por una línea terminada en un rombo negro en el lado del agregador.

18 Asociación: Representada por una línea que une las clases, permite asociar objetos que colaboran entre si. No es una relación fuerte, por lo que el tiempo de vida de un objeto no depende del otro. Asociaciones

19 Dependencia o Instanciación: Se denota por una flecha punteada y su uso más habitual es denotar la dependencia que tiene una clase de otra. Asociaciones

20 Asociaciones

21 Diagrama de Casos de Uso Describen las relaciones y las dependencias entre un grupo de acciones que se pueden realizar en el sistema y los actores participantes en dicho proceso. No están pensados para representar el diseño en sí del sistema, por lo que no puede describir sus elementos internos. Sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el cliente, siendo muy útiles para determinar las características necesarias que tendrá el sistema Describen qué es lo que debe hacer el sistema, pero no la forma en que lo hace.

22 Casos de Uso Describe un grupo de actividades del sistema que produce un resultado concreto y tangible, siempre desde el punto de vista de los actores. Son descriptores de las interacciones típicas entre los usuarios y el sistema, representando el interfaz externo del mismo y especificando qué requisitos de funcionamiento debe tener.

23 Casos de uso Reglas: Cada caso de uso está relacionado como mínimo con un actor. Cada caso de uso es un iniciador de una secuencia más amplia de acciones del sistema. Por lo tanto, cada caso de uso lleva al desarrollo de un resultado relevante con valor intrínseco.

24 Casos de Uso Los casos de uso pueden tener relación con otros casos de uso: Include: Especifica una situación en la que un caso ocurre dentro de otro. Extends: Señala que un caso de uso será extendido por otro en algún momento de la ejecución. Generalización: Un caso de uso hereda las características del "Super Caso", de forma similar a la herencia de clases.

25 Casos de Uso Actor Es una entidad externa al sistema que interacciona con él mediante un caso de uso. Pueden ser gente real, otras computadoras o sistemas o algún evento externo. Representan los diferentes roles de los posibles usuarios del sistema y no a personas o máquinas en concreto.

26 Casos de Uso

27 Diagrama de Secuencia Muestran la forma o secuencia en que se invocan las acciones, métodos o paso de mensajes entre ciertos componentes del sistema en un momento dado. Ponen especial énfasis en el orden y el momento en que se envían los mensajes a los objetos, representándose visualmente la creación de objetos en el tiempo. Los objetos están representados por líneas intermitentes verticales (emulando al eje temporal), con el nombre del objeto en la parte más alta. Estos mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación (o método) y los parámetros.

28 Diagrama de secuencia Si se pretende que el diagrama sea una herramienta para el desarrollador, es importante que los nombres de clases, objetos, métodos y argumentos se correspondan con los nombres que llevarán en el propio código. Puede mostrar cómo se van creando los objetos, teniendo en cuenta que el paso del tiempo se propaga hacia abajo en el diagrama.

29 Diagrama de Secuencia