//203 Modelado Estático Diagramas de Clases y Objetos Grupo de Ingeniería del Software y Bases de Datos Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla noviembre 203 Objetivos de este tema Conocer los conceptos del modelado estático mediante diagramas de clases y objetos UML. Ser capaz de realizar un modelo estático de un sistema software a partir de una especificación de requisitos. noviembre 203 Ingeniería de Requisitos IR
//203 Modelo software Modelo estático (modelo conceptual) Describe la estructura y las restricciones de la información que representa el estado del sistema. Modelo de conducta Describe las interacciones del sistema con los Modelo = + actores y cómo evoluciona su estado al interactuar. Modelo estático = Estructura + Restricciones Modelo de conducta = Interacciones externas + Evolución interna noviembre 203 Ingeniería de Requisitos 2 Modelo estático software Estructura Describe la estructura de la información que representa el estado del sistema mediante Diagramas de clases UML Diagramas de objetos UML (escenarios) Restricciones Describen qué estados del sistema son válidos y cuáles no mediante Diagramas de clases UML (mutiplicidades) Restricciones asociadas a elementos de los diagramas de clases UML, que pueden expresarse en lenguaje natural o en OCL (Object Constraint Language). noviembre 203 Ingeniería de Requisitos 3 IR 2
//203 Trazabilidad hacia requisitos Todo elemento de un modelo estático debe estar trazado hacia aquellos requisitos que lo justifican, normalmente requisitos de información y reglas de negocio. class Ejemplo trazabilidad RI-00 - El sistema deberá almacenar la información correspondiente a los usuarios del sistema. En concreto: RF-004 - El sistema deberá enviar automáticamente un email a los usuarios cuando «trace» «trace» Usuario apellidos fechanacimiento email noviembre 203 Ingeniería de Requisitos 4 Trazabilidad hacia requisitos Todo elemento de un modelo estático debe estar trazado hacia aquellos requisitos que lo justifican, normalmente requisitos de información y reglas de negocio. noviembre 203 Ingeniería de Requisitos 5 IR 3
//203 Conceptos del modelado estático Clase entidad Atributo Asociación Rol Multiplicidad Clase asociación Objeto y enlace (instancias de clases y asociaciones) Generalización y especialización Composición y noviembre 203 Ingeniería de Requisitos 6 Representa un concepto relevante del dominio del problema sobre el que el sistema debe almacenar información porque así se ha especificado (o se deduce) en uno o más requisitos (trazas). Se nombran mediante un sustantivo en singular. class Ejemplos de clases Alumno fechanacimiento código Asignatura número fecha tienebeca Matrícula noviembre 203 Ingeniería de Requisitos 7 IR 4
//203 Atributo de una clase entidad Son propiedades asociadas a un concepto relevante del dominio del problema que el sistema debe almacenar porque así se ha especificado (o se deduce) en uno o más requisitos (trazas). Se nombran mediante un sustantivo en singular y sus valores deben ser simples (no estructuras de datos). Pueden ser opcionales ([0..]). class Ejemplos de clases Alumno fechanacimiento código Asignatura número fecha tienebeca Matrícula Normalmente las trazas se establecen a nivel de clase, aunque también puede hacerse a nivel de atributos. noviembre 203 Ingeniería de Requisitos 8 entidades Representa algún tipo de relación entre dos o más conceptos relevantes del dominio del problema que el sistema debe conocer porque así se ha especificado (o se deduce) en uno o más requisitos (trazas). Se nombran mediante un verbo en tercera persona del singular y las preposiciones que hagan falta, formando una frase con sentido al leerla con los roles. class Ejemplo asociación Asignatura código 0.. aparec een 0.. M atríc ula número fecha tienebeca noviembre 203 Ingeniería de Requisitos 9 IR 5
//203 Rol de un extremo de una asociación Papel que juega cada una de las clases que participan en una asociación. Por defecto, es su propio. Es necesario indicarlo en: Asociaciones de una clase consigo misma Cuando existe más de una asociación entre dos clases. class Ejemplos de roles padre 0..2 espadred e Persona Vuelo salida saled e origen Aeropuerto hijo 0.. llegada llegaa destino noviembre 203 Ingeniería de Requisitos 0 Multiplicidad de un extremo de una asociación Dado un objeto de una clase, indica los números mínimo y máximo de objetos de la otra clase con los que puede estar relacionado mediante de la asociación. class Ejemplos de roles espadred e class Ejemplo asociación Asignatura código 0.. aparec een 0.. M atríc ula número fecha tienebeca padre 0..2 Persona Vuelo salida saled e origen Aeropuerto hijo 0.. llegada llegaa destino noviembre 203 Ingeniería de Requisitos IR 6
//203 Multiplicidad de un extremo de una asociación Valores habituales de multiplicidades class Ejemplos de roles 0.. : opcional 0.. : múltiple opcional : equivalente a 0.. espadred e class Ejemplo asociación Asignatura código 0.... : obligatoria.. : múltiple obligatoria : equivalente a.. aparec een 0.. M atríc ula número fecha tienebeca padre 0..2 Persona Vuelo salida saled e origen Aeropuerto hijo 0.. llegada llegaa destino noviembre 203 Ingeniería de Requisitos 2 Restricciones en un extremo de un asociación {nonunique}: indica que se permiten duplicados {ordered}: indica que existe un orden Por defecto, se asume que no se permiten duplicados y que no existe un orden. sin duplicados con duplicados {nonunique} sin orden Conjunto (por defecto) Multiconjunto (bag) con orden {ordered} Conjunto ordenado Secuencia noviembre 203 Ingeniería de Requisitos 3 IR 7
//203 Restricciones entre asociaciones {xor}: indica que los objetos de la clase común a las asociaciones restringidas no pueden tener de más de una de dichas asociaciones. Ejemplo: un participante en un congreso no puede ser autor de una ponencia y a la vez miembro del comité de programa. Participante.. autor esmiembrode miembro {xor} esautorde 0.. 0.. {ordered} Comité de Programa Ponencia noviembre 203 Ingeniería de Requisitos 4 Clase asociación A veces es necesario añadir cierta información a las asociaciones, convirtiéndolas en clases. class Ejemplo clase asociación Empleado class Ejemplo clase asociación Empleado trabajaen trabajaen Proyec to presupuesto Proyec to presupuesto cuántas horas trabaja cada empleado en cada proyecto? Esf uerzo horas noviembre 203 Ingeniería de Requisitos 5 IR 8
//203 Clase asociación Ejemplo: las horas que trabaja un empleado en un proyecto no son una propiedad ni del empleado ni del proyecto, sino de la asociación entre ambos. f : Esfuerzo horas = 20 f3 : Esfuerzo horas = 7,5 e : Empleado trabajaen p : Proyecto trabajaen e2 : Empleado trabajaen f5 : Esfuerzo horas = 2 trabajaen f2 : Esfuerzo horas = 5 p2 : Proyecto trabajaen e3 : Empleado f4 : Esfuerzo horas = 25 noviembre 203 Ingeniería de Requisitos 6 Objeto Cada ocurrencia o instancia de una clase. Enlaces Cada ocurrencia o instancia de una asociación. class Equipos de fútbol Jugador 0.. Equipo noviembre 203 Ingeniería de Requisitos 7 IR 9
//203 Objeto Cada ocurrencia o instancia de una clase. Enlaces Cada ocurrencia o instancia de una asociación. object Equipos de fútbol j : Jugador j :Jugador = "Antoñito" j2 : Jugador j2 :Jugador = "Redondo" e2 : Equipo e :Equipo = "Xerez CD" e : Equipo e2 :Equipo = "Sevilla FC" j3 : Jugador j3 :Jugador = "Kanouté" j4 : Jugador j4 :Jugador = "Negredo" J6 : Jugador = "Luis Fabiano" j5 : Jugador j5 :Jugador = "Jesús Navas" noviembre 203 Ingeniería de Requisitos 8 Extensión de una clase Todas las instancias de dicha clase en el sistema. Extensión de la clase Jugador Extensión de la clase Equipo object Equipos de fútbol j : Jugador j :Jugador = "Antoñito" j2 : Jugador j2 :Jugador = "Redondo" e2 : Equipo e :Equipo = "Xerez CD" e : Equipo e2 :Equipo = "Sevilla FC" j3 : Jugador j3 :Jugador = "Kanouté" j4 : Jugador j4 :Jugador = "Negredo" J6 : Jugador = "Luis Fabiano" j5 : Jugador j5 :Jugador = "Jesús Navas" noviembre 203 Ingeniería de Requisitos 9 IR 0
//203 Composición Asociación especial que representa el concepto de ser-parte-de o estar-compuesto-por, en concreto: Una parte (componente) sólo puede pertenecer a un todo (compuesto). Una parte no puede existir sin pertenecer a un todo. La eliminación del todo implica la eliminación de todas sus partes. Es una relación transitiva y antisimétrica, que puede ser recursiva. class Ejemplo de composición Fac tura.. {ordered} L íneadefac tura noviembre 203 Ingeniería de Requisitos 20 Agregación Composición débil donde puede ocurrir que: Una parte (componente) puede pertenecer a más de un todo (agregado), por lo que su multiplicidad no está restringida a. Una parte puede existir sin pertenecer a un todo. La eliminación del todo no implica necesariamente la eliminación de todas sus partes. class Ejemplos de Polígono 3.. {ordered} Punto Grupo musical.. M úsic o noviembre 203 Ingeniería de Requisitos 2 IR
//203 /especialización A veces, algunos de los conceptos del dominio del problema presentan entre ellos relaciones del tipo es-un, por ejemplo: es-un vehículo es-un es-un camión automóvil motocicleta Estos conceptos suelen tener propiedades comunes, que al modelarlos conceptualmente aparecen como atributos o asociaciones comunes. noviembre 203 Ingeniería de Requisitos 22 /especialización class Ejemplo de generalización espropietariod e Autom óvil matrícula númerobastidor modelo plazas asegurado tieneseguro 0.. Persona propietario propietario 0.. espropietariod e Cam ión matrícula númerobastidor modelo tonelaje ejes asegurado tieneseguro 0.. 0.. propietario espropietariod e M otoc ic leta matrícula númerobastidor modelo cilindrada asegurado tieneseguro Seguro 0.. compañia númeropóliza tipo precio 0.. noviembre 203 Ingeniería de Requisitos 23 IR 2
Generalización Especialización Generalización Especialización //203 /especialización class Ejemplo de generalización Persona Seguro compañia númeropóliza tipo precio 0.. espropietariod e propietario 0.. tieneseguro Autom óvil plazas asegurado Vehíc ulo matrícula númerobastidor modelo M otoc ic leta cilindrada La clase más general (superclase), contiene todas las propiedades (atributos y asociaciones) comunes, que son heredados por las clases más específicas (las subclases). {completa, disjunta} tonelaje ejes Cam ión noviembre 203 Ingeniería de Requisitos 24 /especialización class Ejemplo de generalización Persona Seguro compañia númeropóliza tipo precio Todas las instancias de las subclases se consideran también instancias de la superclase. La generalización es una relación transitiva y antisimétrica. 0.. espropietariod e propietario 0.. tieneseguro Autom óvil plazas asegurado Vehíc ulo matrícula númerobastidor modelo M otoc ic leta cilindrada {completa, disjunta} tonelaje ejes Cam ión noviembre 203 Ingeniería de Requisitos 25 IR 3
//203 /especialización class Ejemplo de generalización Persona Seguro compañia númeropóliza tipo precio 0.. espropietariod e propietario 0.. tieneseguro Autom óvil plazas Vehíc ulo matrícula númerobastidor modelo M otoc ic leta cilindrada {completa, disjunta} implica una partición del conjunto de instancias de la superclase. asegurado {completa, disjunta} Vehículos tonelaje ejes Cam ión Clase abstracta El de las clases abstractas se muestra en cursiva. Automóviles Motocicletas Camiones noviembre 203 Ingeniería de Requisitos 26 /especialización class Ejemplo comunidad universitaria M iem brocu {completa, solapada} Alum no Em pleado {completa, disjunta} PAS PD I noviembre 203 Ingeniería de Requisitos 27 IR 4
//203 La barra (/) indica que algún atributo o asociación puede derivarse (calcularse) a partir de otros. Es necesario añadir las restricciones que indican cómo deben derivarse. { total de factura : total = suma de cantidad precio de todas las líneas de factura.} class Ejemplo de Factura número fechaemisión / total emitidaa Cliente / contienea { contenido de la factura : Los productos que contiene son los productos asociados a las líneas fe factura.} LíneaDeFactura.. cantidad {ordered} precio.. correspondea Producto noviembre 203 Ingeniería de Requisitos 28 Tipos enumerados Definen un tipo que puede ser usado en los atributos de las clases entidades. Los atributos son los posibles valores que pueden tomar los atributos del tipo enumerado. class Notación enumerados «enumerado» Sexo hombre mujer «enumerado» VíaPúblic a calle plaza avenida carretera «enumerado» Categoría infantil aventuras cienciaficción drama noviembre 203 Ingeniería de Requisitos 29 IR 5
//203 Creación de conceptuales Pasos recomendados:. Analizar la información sobre el dominio del problema (glosario) y los requisitos. 2. Identificar posibles entidades y atributos. 3. Identificar posibles asociaciones. 4. Construir incrementalmente el modelo conceptual e identificar las multiplicidades de las asociaciones. 5. Identificar clasificaciones entre entidades con propiedades (atributos y/o asociaciones) comunes. 6. Identificar composiciones entre entidades. 7. Añadir las restricciones que no puedan expresarse gráficamente. 8. Validar con posibles escenarios mediante diagramas de objetos. 9. Registrar todos aquellos problemas semánticos que deban ser aclarados con clientes y usuarios. noviembre 203 Ingeniería de Requisitos 30 Bibliografía C. Larman, UML y Patrones. Ed. Prentice-Hall, 999. Capítulos 9 al 2 C. Larman, UML y Patrones (2ª edición). Ed. Prentice-Hall, 2003. Capítulos 0 al 2 M. Fowler, UML Distilled (3 rd edition). Ed. Addison-Wesley, 2004. Capítulo 3 noviembre 203 Ingeniería de Requisitos 3 IR 6