1 MODELADO ESTRUCTURAL BASICOERNESTO GOMEZ VARGAS
2 CONTENIDO CLASES RELACIONES MECANISMOS COMUNES DIAGRAMASDIAGRAMA DE CLASES.
3 CLASES Atributos, operaciones, Responsabilidades.Nombres: Cada Clase debe tener un Nombre que lo diferencie de las otras clases. Se puede usar los dos puntos para separar la clase del paquete que la contiene.
4 CLASES Atributos, operaciones, Responsabilidades. AtributosUn atributo es una propiedad de la clase identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de la propiedad. Una clase puede tener cualquier numero de atributos o no tener nada. Se utiliza los dos puntos para separa el nombre del atributo del tipo de dato que puede tener.
5 CLASES Atributos, operaciones, Responsabilidades. Operaciones.Una operación es la implementación de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento. reiniciar() ponerAlarma (t:temperatura) Valor():Tempeatura
6 CLASES Atributos, operaciones, Responsabilidades. Responsabilidades.Una responsabilidad es un contrato o una obligación de una clase. Al un nivel mas abstracto , estos atributos y operaciones son simplemente las características por medio de las cuales se lleva a cabo las responsabilidades de las clases.
7 ---determinar el riesgo de un pedido de un clienteCLASES Atributos, operaciones, Responsabilidades. Responsabilidades. AgenteFraudes ---determinar el riesgo de un pedido de un cliente
8 CLASES Modelado del vocabulario de un Sistema.Identificar las cosas que utilizan los usuarios o programadores para describir el problema o la solución. Para cada abstracción hay que identificar un conjunto de responsabilidades. Hay que asegurar un reparto de responsabilidades entre las clases. Hay que proporcionar los atributos y operaciones necesarios en cada clase para cumplir estas responsabilidades.
9 CLASES Modelado de la distribución de responsabilidades de un sistema.Hay que identificar un conjunto de responsabilidades para cada clase. Dividir las clases con demasiadas responsabilidades en abstracciones mas pequeñas Introducir clases con abstracciones muy pequeñas en otras mas grandes. Identificar la forma en que las clases se colaboran entre si.
10 CLASES Modelado de Cosas que no son Software.Usar Estereotipos para especificar la nueva semántica y proporcionar una representación Visual. Si lo que esta modelando es algun tipo de hardware , hay que considerar modelarlo como un nodo.
11 RELACIONES Modelado de Dependencias Simples.El tipo más común de relación de dependencia es la conexión entre una clases que solo utiliza a otra clase como parámetro de una operación. Hay que crear una dependencia que vaya desde la clase con la operación hasta la clase utiliza como parámetro de la operación.
12 RELACIONES Modelado de la herencia simple.Dado un conjunto de clases, hay que buscar responsabilidades, atributos y operaciones comunes a dos o más clases. Hay que elevar estas responsabilidades , atributos y operaciones comunes a una clase mas general. Hay que especificar que las clases más especificas heredan de las clases mas generales a través de una relación de generalización
13 RELACIONES Modelado de relaciones Estructurales.Para cada par de clases, si es necesario navegar desde los objetos de una hasta los objetos de la otra, hay que especificar una relación entre las dos. Esta es una asociación dirigida por datos. Para cada par de Clases, si los objetos de una clase necesitan interactuar de alguna forma con los objetos de la otra como parámetros de operación, hay que especificar una relación entre las dos. Esta es una asociación dirigida por el comportamiento.
14 RELACIONES Modelado de relaciones Estructurales.Para cada una de estas asociaciones hay que especificar la multiplicidad (especialmente cuando no sea *, que es el valor por defecto), así como los nombre de rol (Si esto ayuda a explicar el modelo). Si una de las clases de la asociación es, desde un punto de vista estructural o de organización , un todo comparado con las clases en el otro extremo, que parecen las partes, hay que marcarla como una agregación.
15 MECANISMO COMUNES EstereotiposUml proporciona un lenguaje para elementos estructurales, elementos de comportamiento, elementos de agrupación y elementos de anotación. No obstante a veces se desea introducir nuevos elementos relacionados con el vocabulario de un dominio y que parezcan bloques de construcción primitivos. En su forma mas sencilla, un estereotipo se representa como un nombre entre comillas tipográficas, se puede definir un icono para el estereotipo.
16 MECANISMO COMUNES Valores Etiquetados.Todo elemento en UML tiene su propio conjunto de propiedades: Las clases tienen nombre, atributos y operaciones; las asociaciones tienen nombres y dos o mas extremos, con los estereotipos, se pueden añadir nuevos elementos a UML con los valores etiquetados se puede añadir nuevas propiedades.
17 MECANISMO COMUNES Restricciones.Todo en UML tiene su propia semántica, con las restricciones en UML se puede añadir nueva semántica o modificar las reglas existentes. Una restricción especifica condiciones que deben cumplirse para que el modelo este bien formado.
18 MECANISMO COMUNES Restricciones.
19 MECANISMO COMUNES Restricciones.
20 MECANISMO COMUNES
21 MECANISMO COMUNES Modelado de los Comentarios.Hay que colocar el comentario como una nota adyacente al elemento al que se refiere. Se puede conectar la nota al elemento con una relación de dependencia. No se hace necesario visualizar el comentario en todos los lugares donde se hace visible el elemento.
22 MECANISMO COMUNES Modelado de los Comentarios.Si el comentario es largo o incluye algo mas complejo que simple texto, hay que considerar ponerlo en un documento externo y enlazar o incluir este documento en una nota adjunta al modelo. Conforme evoluciona el modelo, hay que mantener aquellos comentarios que recogen decisiones significativas que no se pueden inferir del propio modelo.
23 MECANISMO COMUNES Modelado de nuevos bloques de Construcción.Asegurarse que no existe ya algo en UML para expresar lo que se desea. Si se esta convencido de que no hay forma de expresar la semántica hay que identificar el elemento primitivo de UML mas cercano a lo que se desea modelar y definir un estereotipo para ese elemento.
24 MECANISMO COMUNES Modelado de nuevos bloques de Construcción.Hay que especificar las propiedades comunes y la semántica que caen fuera del elemento básico que se esta estereotipando, definiendo un conjunto de valores etiquetados y restricciones para el estereotipo. Definir un nuevo símbolo para el estereotipo.
25 MECANISMO COMUNES Modelado de nuevas propiedades.Primero se debe asegurar de que no existe en UML una forma de expresar lo que se desea. Si no hay forma de expresar la semántica se añade la propiedad( En paquetes un valor etiquetado con la versión)
26 DIAGRAMAS Modelado de las diferente Vistas de un sistema.Definir que vistas se necesitan para expresar mejor la arquitectura del sistema e identificar los riesgos técnicos del proyecto. Para Cada una de las vistas decidir que artefactos se necesitan crear para capturar los detalles esenciales.
27 DIAGRAMAS Modelado de las diferente Vistas de un sistema.Como parte del proceso de planificación decidir cuales de estos diagramas se pondrán bajo algún tipo de control formal. Dejar un hueco para los diagramas que se desecharan.
28 DIAGRAMAS
29 DIAGRAMAS
30 DIAGRAMAS
31 DIAGRAMAS
32 DIAGRAMAS
33 DIAGRAMAS
34 DIAGRAMAS Modelado de los diferentes niveles de abstracción.Hay que considerar las necesidades de las personas que utilizaran el diagrama y comenzar con un determinado modelo. Si se va usar el modelo para hacer una implementación, harán falta diagramas a un nivel de abstracción, que tendrán que revelar muchos detalles.
35 DIAGRAMAS Modelado de los diferentes niveles de abstracción.Según donde se ubique el nivel de abstracción, hay que crear un diagrama ocultando o revelando las siguientes características. Bloques de construcción y sus relaciones. Adornos: Revelar los esenciales. Flujo: Considerar los mensajes esenciales. Estereotipos: Revelar los esenciales.
36 DIAGRAMAS Modelado de los diferentes niveles de abstracción.Al modelar un sistema a diferentes niveles de abstracción, se producen cuatro situaciones. Casos de uso y su realización: (Colaboraciones). Colaboraciones y su realización: (sociedad de Clases). Componentes y su diseño: (Correspondencia entre el modelo de implementación y el modelo de diseño). Nodos y sus componentes:(Correspondencia entre el modelo de despliegue y el modelo de implementación).
37 DIAGRAMAS Modelado de Vistas Complejas.Convencerse de que no es posible presentar la información a un nivel de abstracción mas detallado. Considerar la agrupación de algunos elementos en paquetes o en colaboraciones de mayor nivel. Usar notas y colores como señales visuales para atraer la señal del lector. Imprimir el diagrama y colgarlo en una pared.
38 DIAGRAMAS DE CLASES Usos comunes.Para modelar el vocabulario del sistema. Para modelar Colaboraciones simples. Para modelar un esquema lógico de la base de datos.
39 DIAGRAMAS DE CLASES Modelado de colaboraciones simples.Identificar los mecanismos que se quieren modelar. Un mecanismo es una función o comportamiento de la parte del sistema que se esta modelando. Para cada mecanismo, hay que identificar las clases, interfaces y otras colaboraciones que participen en esta colaboración.
40 DIAGRAMAS DE CLASES Modelado de Colaboraciones simples.Hay que usar escenarios para recorrer la interacción entre estos elementos. Hay que asegurarse de rellenar estos elementos con contenido. Para las clases repartir de manera equilibrada las responsabilidades.
41 DIAGRAMAS DE CLASES Modelado de un esquema lógico de base de datos.Identificar las clases del modelo cuyo estado trascender el tiempo de vida de las aplicaciones. Hay que hacer un diagrama de clases y marcar estas clases como persistentes. Hay que expandir los detalles estructurales de estas clases, especificar al detalle los atributos y centrar la atención en la asociaciones y la cardinalidad.
42 DIAGRAMAS DE CLASES Modelado de un esquema lógico de base de datos.Hay que buscar patrones comunes que complican el diseño físico de la base de datos como asociaciones cíclicas, uno a uno, n-arias. Hay que considerar el comportamiento de las clases persistentes expandiendo las operaciones que sean importantes para el acceso a los datos y la integridad de los datos.