tema 3 anlisis de sistemas

1
tema 3 análisis de sistemas
enrique barreiro departamento de
informática universidade de vigo escuela
superior de ingeniería informática ingeniería del
software de gestión
2
introducción al análisis

• ingeniería de requisitos
• los casos de uso son una buena herramienta para
  capturar requisitos, pero siempre quedan aspectos
  sin resolver o que son de especial complejidad y
  hay que estudiar posteriormente
• deben mantenerse lo más independientes posibles
  unos de otros, obviando detalles relativos a
  interacciones, concurrencia, recursos
  compartidos,...
• ejemplo Ingresar Dinero y Retirar Dinero son
  dos casos de uso que acceden a la misma cuenta y
  por tanto están relacionados
• deben escribirse utilizando el lenguaje del
  cliente al usarse lenguaje natural se pierde
  poder expresivo y en la captura de requisitos
  pueden quedar sin describir adecuadamente
  detalles que requieren notaciones más formales

3
introducción al análisis

• análisis
• objetivo
• conseguir una comprensión más precisa de los
  requisitos y una descripción de los mismos que
  sea fácil de mantener y ayude a estructurar todo
  el sistema, incluyendo su arquitectura
• diversos enfoques
• estructurado
• prototipado
• orientado a objetos
• se analizan los requisitos descritos durante la
  ingeniería de requisitos
• analizándolos con mayor profundidad se puede
  razonar más sobre los aspectos internos del
  sistema, resolviendo cuestiones sobre
  interacciones de casos de uso, recursos
  compartidos,...
• utilizando el lenguaje de los desarrolladores, lo
  que permite indicar detalles no especificados
  antes (refinar los requisitos)
• se pueden estructurar los requisitos para
  facilitar su comprensión, preparación,
  modificación y mantenimiento

4
introducción al análisis
5
introducción al análisis

• requerimientos cambiantes
• habitual en grandes sistemas
• razones
• muchos usuarios (contradicciones, conflictos de
  intereses,...)
• los que pagan el sistema y los usuarios no suelen
  ser la misma persona, por lo que pueden tener
  requerimientos en conflicto
• el entorno de negocios y técnico cambia nuevo
  hardware, nuevos sistemas, cambios en las
  prioridades del negocio, cambios legislativos,...
• administración de requerimientos
• proceso de comprender y controlar los cambios en
  los requerimientos del sistema
• requerimientos duraderos aquellos relativamente
  estables, derivados de la actividad principal de
  la organización, y relacionados directamente con
  el dominio del sistema. Por ejemplo, en un
  hospital siempre habrá requerimientos referidos a
  pacientes, doctores, enfermeros, medicinas,...
• requerimientos volátiles cambian probablemente
  durante el desarrollo del sistema o después de
  que se haya puesto en explotación. Por ejemplo,
  cambios en las normativas de salud.

6
introducción al análisis

• planificación de la administración de
  requerimientos
• identificación de requerimientos
• proceso de administración del cambio
• análisis del problema y especificación del cambio
• análisis del cambio y evaluación económica
• implementación del cambio
• políticas de rastreo definen la relación entre
  requerimientos y la de éstos y el diseño del
  sistema
• información de rastreo de la fuente
  identificación de quién propone el cambio y la
  razón
• información de rastreo de los requerimientos
  vincula los requerimientos dependientes en el
  RAD. Es necesario para comprobar cómo se ven
  afectados otros requerimientos por el cambio
  propuesto y la magnitud de este impacto.
• información de rastreo del diseño vincula los
  requerimientos a los componentes de diseño
  (clases, métodos, módulos,...) en que serán
  implementados. Necesario para evaluar cómo se ve
  afectado el diseño y la implementación por el
  cambio propuesto.
• ayuda de herramientas CASE

7
el análisis en el proceso unificado

• actividades del análisis en el proceso unificado
• crear el Modelo de Dominio
• refinar el Modelo de Casos de Uso
• refinar la Especificación Complementaria
• refinar el Glosario
• se llevan a cabo a lo largo de varias iteraciones
  en la fase de elaboración

8
modelo del dominio

• artefacto de UML modelo del dominio (o modelo
  conceptual)
• muestra clases conceptuales significativas en un
  dominio del problema, es decir, en el mundo real
• no muestra componentes software, clases software
  u objetos software con responsabilidades
• es el artefacto más importante en un análisis
  orientado a objetos (AOO)
• UML utiliza diagramas de clases para representar
  el modelo del dominio, que muestran
• objetos del dominio o clases conceptuales
• asociaciones entre las clases conceptuales
• atributos de las clases conceptuales
• principal tarea del AOO identificar diferentes
  conceptos en el dominio del problema y documentar
  el resultado en un modelo del dominio
• ejemplo en el dominio de ventas pueden
  identificarse clases conceptuales como Tienda,
  Registro o Venta.
• el modelo del dominio se construye
  incrementalmente a lo largo de varias iteraciones
  en la fase de elaboración

9
modelo del dominio
Modelo del dominio ejemplo de un Diagrama de
Clases
10
modelo del dominio

• pasos en la realización de un modelo del dominio
• identificar y listar las clases conceptuales
  candidatas
• representarlas en un modelo del dominio
• añadir las asociaciones necesarias para registrar
  las relaciones que hay que mantener en memoria
• añadir los atributos necesarios para satisfacer
  los requisitos de información
• importante
• utilizar el vocabulario del dominio al nombrar
  las clases conceptuales y atributos
• excluir las características irrelevantes
• no añadir cosas que no se encuentran en el
  dominio del problema que se está estudiando

11
modelo del dominio

• Los modelos del dominio no son modelos de
  componentes software.
• Elementos que no son adecuados en un modelo del
  dominio
• Artefactos software ventanas, bases de
  datos,...
• Responsabilidades o métodos

12
modelo del dominio

• clases conceptuales
• informalmente una clase conceptual es una idea,
  cosa u objeto
• formalmente puede considerarse en términos de
• símbolo palabras o imágenes que representan una
  clase conceptual
• definición de la clase
• extensión conjunto de ejemplos a los que se
  aplica la clase

símbolo del concepto
venta-3
venta-1
venta-4
definición del concepto
venta-2
Una venta representa el hecho de una transición
de compra. Sucede un día y a una hora.
extensión del concepto
13
modelo del dominio

• identificación de clases conceptuales
• para cada escenario se identifican las clases
  conceptuales relacionadas con él
• mejor especificar en exceso un modelo del dominio
  con muchas clases conceptuales de grano fino
  que especificar por defecto
• estrategias complementarias para identificar
  clases conceptuales
• utilización de una lista de categorías de clases
  conceptuales
• identificación de frases nominales

14
modelo del dominio identificación de clases

• identificación de clases conceptuales mediante
  una lista de categorías
• se utiliza una lista de categorías habituales que
  normalmente merece la pena tener en cuenta

15
modelo del dominio identificación de clases

• análisis del lenguaje natural identificación de
  clases conceptuales mediante frases nominales
• heurística de Abbot (1983)
• identificar nombres y frases nominales en las
  descripciones textuales de un dominio,
  considerándolos como clases conceptuales o
  atributos candidatos
• punto débil imprecisión del lenguaje natural,
  ambigüedades (sinónimos, redundancias,...)
• se realiza a partir de las descripciones
  completas de los casos de uso

16
modelo del dominio identificación de clases

• Escenario principal de éxito (o flujo básico) de
  Procesar Venta.
• El Cliente llega al terminal PDV con mercancías
  y/o servicios que comprar
• El Cajero inicia una nueva venta
• El Cajero introduce el identificador del artículo
• El Sistema registra la línea de venta y presenta
  la descripción del artículo, precio y suma
  parcial. El precio se calcula a partir de un
  conjunto de reglas de precios.El Cajero repite
  los pasos 3-4 hasta que se indique
• El Sistema muestra el total con los impuestos
  calculados
• El Cajero le dice al Cliente el total, y solicita
  el pago
• El Cliente paga y el Sistema gestiona el pago
• El Sistema registra la venta completa y envía la
  información de la venta y el pago al sistema de
  Contabilidad externo (para la contabilidad y las
  comisiones) y al sistema de Inventario (para
  actualizar el inventario).
• El sistema presenta el recibo
• El Cliente se va con el recibo y las mercancías
• Extensiones (o flujos alternativos)
• ...
• 7a. Pago en efectivo
• 1. El Cajero introduce la cantidad de dinero
  entregada en efectivo.
• 2. El sistema muestra la cantidad de dinero a
  devolver y abre el cajón de caja.
• 3. El Cajero deposita el dinero entregado y
  devuelve el cambio al Cliente

17
modelo del dominio identificación de clases
no se menciona de forma explícita, pero en la
descripción se habla de información enviada por
el OficialCampo.Al hablar con el cliente se
descubre que a esta información se la conoce como
informe de emergencia, por lo que se le da ese
nombre a la clase correspondiente
conocimiento del dominio
informar emergencia

• descripción de los objetos y clases
• inicialmente, breve
• documentación de atributos y responsabilidades
  únicamente si son obvios
• una vez que el modelo es estable, la descripción
  de cada clase será tan detallada como sea posible

entrevistas con cliente y usuarios
18
modelo del dominio identificación de clases

• lista de clases conceptuales candidatas del
  dominio
• generada a partir de
• lista de categorías
• análisis de lenguaje natural (frases nominales)
• restringida a los requisitos que se están
  estudiando actualmente
• ejemplo lista de clases candidatas del caso de
  uso Procesar Venta.
• informes por lo general, no se recogen en el
  modelo de dominio porque muestran información
  derivada de otras fuentes, duplicando
  información.
• a discutir es el Recibo una clase conceptual?

19
modelo del dominio identificación de clases

• error habitual al identificar clases candidatas
• considerar como un atributo algo que debería ser
  un concepto
• en caso de duda, debe considerarse un concepto
  separado, puesto que los atributos no deben ser
  muy habituales en un modelo del dominio

NO
SI
En el mundo real, una tienda o un aeropuerto no
se consideran un número o un texto. Estos
términos sugieren una entidad legal, una
organización, y algo que ocupa espacio. Por
tanto, deben ser un concepto.
20
modelo del dominio identificación de clases
Si se consumen todos los ObjetoOrdenador,
desaparecerá del sistema también su precio,
porque se encontraba como atributo en las
instancias que se eliminaron cuando se vendieron.

• clases conceptuales de especificación o
  descripción
• se utilizan para especificar o describir otras
  clases
• una clase EspecificaciónDelArtículo no representa
  un Artículo, sino una descripción de la
  información sobre los artículos
• aunque se vendan todos los elementos
  inventariados, eliminándose las correspondientes
  instancias software de Artículo, permanecerá la
  EspecificaciónDelArtículo
• habituales en entornos de gestión (sistemas de
  compras, ventas, inventarios,...) y fabricación
  (descripciones de los productos fabricados)
• se usan cuando
• se necesita la descripción de un artículo o
  servicio independientemente de la existencia
  actual de algún item de esos artículos o
  servicios
• la eliminación de instancias de las cosas que
  describen provocan pérdida de información que
  necesitaría mantenerse
• reduce información redundante o duplicada

21
modelo del dominio identificación de clases
NO
SI
22
modelo del dominio identificación de clases

• reducción del salto en la representación (salto
  semántico)
• una de las grandes ventajas de la tecnología de
  objetos
• reducción de la diferencia entre el modo en el
  que el personal involucrado concibe el dominio y
  su representación en el software
• ejemplo
• un pago en el Modelo del Dominio es una clase
  conceptual (un concepto)
• un pago en el Modelo de Diseño es una clase
  software
• no son lo mismo, pero el primero inspiró el
  nombre y definición del segundo

Modelo del Dominio Vista del personal involucrado
de los conceptos más relevantes del
dominio Visualiza los modelos del mundo real.
inspira objetos y nombres en el modelo de diseño
Modelo del Diseño El desarrollador orientado a
objetos se ha inspirado en el dominio del mundo
real al crear las clases software. Visualiza los
componentes software
23
modelo del dominio representar las clases

• representar las clases en un modelo del dominio
• se utiliza la notación de clase de UML

nombre clase
lista de atributos
lista de operaciones (no se suelen reflejar en el
modelo del dominio)
24
modelo del dominio representar las clases
Representación de las clases conceptuales del
Sistema PDV
Registro
Artículo
Tienda
Venta
LineaDeVenta
Cajero
Cliente
Encargado
Pago
CatalogoDeProductos
EspecificacionDelProducto
25
modelo del dominio asociaciones

• asociación
• según UML, una asociación es la relación
  semántica entre dos o más clasificadores que
  implica conexiones entre sus instancias
• se registran las asociaciones
• de las que es necesario conservar el conocimiento
  de la relación durante algún tiempo (por ejemplo,
  la relación entre LíneaPedido y Pedido)
• derivadas de la Lista de Asociaciones Comunes
• importante registrar únicamente asociaciones
  útiles para mantener el diagrama legible
• es más importante dedicar tiempo a localizar las
  clases conceptuales que a identificar las
  asociaciones

26
modelo del dominio asociaciones

• lista de asociaciones comunes
• relación de categorías habituales que,
  normalmente, merece la pena tener en cuenta

relaciones cuya inclusión en el Modelo de Dominio
es especialmente útil
27
modelo del dominio asociaciones

• nombre de las asociaciones
• formato NombreTipo FraseVerbal NombreTipo
  donde la frase verbal crea una secuencia legible
  y con significado en el contexto del modelo
• normalmente la dirección por defecto para la
  lectura de los nombres de asociaciones es de
  izquierda a derecha o arriba abajo

fuente C. Larman, UML y patrones, Prentice Hall,
2002
28
modelo del dominio asociaciones
29
modelo del dominio asociaciones

• multiplicidad
• indica cuántas instancias de una clase A pueden
  asociarse con una instancia de una clase B
• en un momento concreto
• NO a lo largo de un periodo de tiempo
• indica una restricción de diseño que será (o
  podrá ser) reflejada en el software

cero o más muchos
uno o más
de uno a 40
exactamente 5
exactamente 3, 5 u 8
30
modelo del dominio asociaciones

• multiplicidad
• puede existir cualquier tipo de multiplicidad,
  pero en la práctica la mayoría de las
  asociaciones pertenecen a uno de los siguientes
  tipos
• asociación de uno a uno tiene una multiplicidad
  de 1 a cada extremo. Significa que existe
  solamente un vínculo entre instancias de cada
  clase. Por ejemplo, OficialPolicía tiene
  exactamente un NúmeroIdentificación, y éste
  representa a uno y sólo a un OficialPolicía
• asociación de uno a muchos tiene una
  multiplicidad de 1 en un extremo y 0..n en el
  otro (a veces representado con un asterisco)
• asociación de muchos a muchos tiene una
  multiplicidad de 0..n o 1..n en ambos extremos.
  Indica que pueden existir una cantidad arbitraria
  de vínculos entre instancias de las dos clases.
  Es el tipo más complejo de asociación.

31
modelo del dominio asociaciones

• pueden existir dos o más asociaciones entre dos
  clases conceptuales

32
modelo del dominio asociaciones
33
modelo del dominio asociaciones

• navegabilidad
• indica que es posible enviar mensajes en la
  dirección de la flecha en uno de los dos extremos
  de asociación
• no hay que especificarla hasta que el diagrama de
  clases sea estable

En este caso, la clase Asignatura conoce a la
clase Estudiante, pero no al revés.
34
modelo del dominio asociaciones

• asociaciones reflexivas

35
modelo del dominio asociaciones

• agregación
• es un tipo de asociación que se utiliza para
  modelar las relaciones todo-parte entre las
  cosas. El todo se denomina compuesto
• normalmente se identifica en el Modelo de Diseño,
  pero puede ser útil o necesario identificar
  algunas relaciones de agregación en el Modelo del
  Dominio.
• representación en UML un rombo hueco o relleno
  en el extremo del compuesto de una asociación
  todo-parte
• el nombre de la asociación se suele excluir
  porque se piensa normalmente como Tiene-parte

4
1
4
1
Rueda
Coche
1
1
1
1
0..1
0..1
Radio
1
1
Motor
36
modelo del dominio asociaciones

• agregación de composición
• la parte es un miembro de un único objeto
  compuesto y existe una dependencia de existencia
  y disposición de la parte sobre el compuesto
• la multiplicidad en la parte del compuesto sólo
  puede ser 1
• ejemplo en una relación Coche Motor, el motor
  tiene sentido como tal (existe) únicamente si
  está asociado a un coche
• representación en UML un rombo relleno
• agregación compartida
• la multiplicidad en el extremo del compuesto
  puede ser más de uno la parte puede estar
  simultáneamente en muchas instancias del
  compuesto
• se utiliza para conceptos abstractos, no físicos
• representación en UML un rombo hueco

Coche
1
1
1
1
Motor
37
modelo del dominio asociaciones

• identificación de la agregación
• si hay duda, se descarta
• se debe mostrar una agregación
• cuando el tiempo de vida de la parte está ligado
  al tiempo de vida del compuesto (existe una
  dependencia de creación eliminación de la parte
  en el todo).
• cuando existe un ensamblaje obvio todo-parte
  físico o lógico
• cuando alguna propiedad del compuesto se propaga
  a las partes, como la ubicación
• cuando las operaciones que se aplican sobre el
  compuesto se propagan a las partes, como la
  destrucción, movimiento o grabación

CatalogoDeProductos
EspecificacionDelProducto
1..n
1..n
1
1
38
modelo del dominio asociaciones

• generalización
• actividad de identificar elementos comunes entre
  los conceptos y definir las relaciones de
  superclase (concepto general) y subclase
  (concepto especializado). Así, los conceptos se
  representan en jerarquías de clases.
• superclase conceptual su definición es más
  general y abarca más que la definición de una
  subclase
• subclase conceptual debe ser un miembro del
  conjunto de la superclase, es decir, es un tipo
  de superclase
• todos los miembros del conjunto de una subclase
  conceptual son miembros del conjunto de su
  superclase

PAGO
Pago con cheque
Pago en efectivo
Pago a crédito
Un Pago representa la transacción de transferir
dinero para una compra de una parte a
otra. PagoACredito es una transferencia de
dinero por medio de una institución de crédito
que autoriza la operación. Por tanto, Pago es
una definición más amplia y general que la de
PagoACredito.
fuente C. Larman, UML y patrones, Prentice Hall,
2002
39
modelo del dominio asociaciones

• jerarquía de clases
• las declaraciones sobre las superclases se
  aplican a las subclases
• regla del 100 el 100 de la definición de la
  superclase conceptual se debe de poder aplicar a
  la subclase. La subclase debe ajustarse al 100
  de los atributos y asociaciones de la superclase

El diagrama indica que todos los Pagos tienen una
cantidad y que se asocian con una Venta
fuente C. Larman, UML y patrones, Prentice Hall,
2002
40
modelo del dominio asociaciones
41
modelo del dominio asociaciones

• cuando dividir una clase conceptual en subclases
• cuando la subclase tiene atributos adicionales de
  interés
• cuando la subclase tiene asociaciones adicionales
  de interés
• cuando el concepto de la subclase funciona, se
  maneja, reacciona o se manipula de manera
  diferente a la superclase o a otras subclases, de
  alguna manera que es interesante.
• cuando el concepto de la subclase representa una
  cosa animada (animal, maquinaria,...) que se
  comporta de manera diferente a la superclase o a
  otras subclases, de alguna manera que resulta
  interesante poner de manifiesto en el modelo del
  dominio.

42
modelo del dominio asociaciones

• cuando definir una superclase conceptual
• cuando las subclases potenciales representan
  variaciones de un concepto similar
• cuando las subclases se ajustarán a las reglas
  del 100 y la regla Es-Un-Tipo-De
• cuando todas las subclases tienen un mismo
  atributo que se puede expresar en la superclase
• cuando todas las subclases tienen la misma
  asociación que se puede unir y relacionar con la
  superclase
• jerarquías de clases y herencia en el software
• la herencia
• es un mecanismo software para hacer que las
  características de la superclase se apliquen a
  las subclases
• es un concepto que no se utiliza en el Modelo del
  Dominio, pero sí cuando se pasa al Modelo de
  Diseño y Modelo de Implementación
• las jerarquías de clases conceptuales del Modelo
  del Dominio pueden reflejarse o no en el Modelo
  de Diseño, dependiendo de las características del
  lenguaje y otras cuestiones

43
modelo del dominio asociaciones
Sistema PDV Clases de Pago
fuente C. Larman, UML y patrones, Prentice Hall,
2002
44
modelo del dominio asociaciones
Sistema PDV Clases de ServicioAutorización
fuente C. Larman, UML y patrones, Prentice Hall,
2002
45
modelo del dominio asociaciones

• clases conceptuales abstractas
• útil identificarlas pues se restringe las clases
  que pueden tener instancias concretas y por tanto
  se clarifican las reglas del dominio del
  problema
• regla general
• si cada miembro de una clase C debe ser también
  un miembro de una subclase, entonces las clase C
  se denomina clase conceptual abstracta.

46
modelo del dominio asociaciones

• clases asociación
• en un modelo del dominio, si una clase C puede
  tener simultáneamente muchos valores para el
  mismo tipo de atributo A, no se colocará este
  atributo en C, sino en otra clase asociada con C.
• ejemplo
• una Persona puede tener muchos números de
  teléfono. Se colocará el número de teléfono en
  otra clase, como NúmeroTeléfono o
  InformaciónDeContacto, y se asocian muchas de
  estas clases a Persona.
• guía
• hay un atributo relacionado con una asociación
• el tiempo de vida de las instancias de la clase
  asociación depende de la asociación
• existe una asociación muchos-a-muchos entre dos
  conceptos, e información asociada con la propia
  asociación

fuente C. Larman, UML y patrones, Prentice Hall,
2002
47
modelo del dominio asociaciones
48
modelo del dominio atributos

• atributo
• es un valor de datos lógico de un objeto
• se incluyen aquellos atributos para los que los
  requisitos indican la necesidad de registrar su
  información
• ejemplo un recibo recoge la información de una
  venta, incluyendo fecha y hora. La dirección
  quiere conocer fecha y hora de las ventas. Por
  tanto, la clase Venta necesita los atributos
  fecha y hora
• notación UML se muestran en el segundo
  compartimento del rectángulo de la clase. Los
  tipos se muestran opcionalmente

49
modelo del dominio atributos

• tipos de atributos
• en el modelo de dominio deben usarse
  preferiblemente
• atributos simples no deben ser conceptos de
  dominio complejos (Venta, Aeropuerto, ...)
• tipos de datos
• principalmente booleano, fecha, número, string y
  hora
• otros Dirección, Color, Teléfono, NIF, Código
  Postal,...
• importante relacionar las clases conceptuales
  con una asociación, no con un atributo. En caso
  de duda, se debe optar por usar una clase
  conceptual antes que un atributo.
• durante el diseño y la implementación podrán
  aparecer nuevos atributos que referencian a otros
  objetos software complejos, pero que no tienen
  sentido en el Modelo de Dominio

destino es un concepto complejo
Peor
Mejor
50
modelo del dominio atributos

• tipos de datos como clases
• un atributo que puede considerarse como un tipo
  de dato primitivo puede representarse como una
  clase si
• está compuesto de secciones separadas (número de
  teléfono, nombre de persona,...)
• hay operaciones asociadas con él, como algoritmos
  de validación (NIF, número de la Seguridad
  Social,...)
• tiene otros atributos (el precio de una oferta
  puede tener una fecha de comienzo y otra de fin)
• es una cantidad con una unidad de medida (la
  cantidad de un pago tiene una unidad monetaria)
• es una abstracción de uno o más tipos con estas
  cualidades (un identificador de artículo en el
  dominio de ventas es una generalización de tipos
  como el Código de Producto Universal UPC- o el
  Número de Artículo Europeo EAN -)
• ejemplo en el sistema de Punto de Venta las
  clases ArticuloID, Direccion y Cantidad son tipos
  de datos pero se pueden considerar como clases
  independiente debido a sus características
• representación como clase independiente o en el
  compartimento de atributos de la clase,
  dependiendo de la utilización del modelo del
  dominio y la importancia de los conceptos en el
  dominio

Correcto
Correcto
fuente C. Larman, UML y patrones, Prentice Hall,
2002
51
modelo del dominio atributos

• cantidades y unidades de los atributos
• la mayoría de las cantidades numéricas llevan
  unidades asociadas no deben representarse
  únicamente como números
• ejemplos precio, velocidad, peso ...
• solución representar la cantidad como una clase
  conceptual aparte con una unidad asociada

no es útil
Incorrecto
Correcto
variación Dinero es una especialización de
Cantidad cuya unidad es una moneda
las cantidades son valores de datos simples, por
lo que es adecuado representarlas en la sección
de atributos
fuente C. Larman, UML y patrones, Prentice Hall,
2002
52
modelo del dominio
fuente C. Larman, UML y patrones, Prentice Hall,
2002
53
modelo del dominio utilización de paquetes

• los modelos de dominio se pueden dividir en
  paquetes cuando han crecido demasiado
• los paquetes incluyen conceptos fuertemente
  relacionados
• mejora la comprensión
• permite realizar tareas de análisis en paralelo,
  de tal forma que diferentes equipos o personas
  analizan diferentes subdominios
• notación de paquetes en UML
• paquete se representa por una carpeta
• pueden mostrarse dentro de un paquete otros
  paquetes subordinados
• un elemento pertenece al paquete donde está
  definido, pero puede ser referenciado en otros
  paquetes, utilizando el formato
  NombrePaqueteNombreElemento

54
modelo del dominio utilización de paquetes
Relación de dependencia indica que los elementos
del paquete dependiente (Ventas) conocen o están
acoplados de algún modo con los elementos del
paquete destino (Elementos Básicos).
Una clase referenciada en un paquete
fuente C. Larman, UML y patrones, Prentice Hall,
2002
55
modelo del dominio utilización de paquetes
fuente C. Larman, UML y patrones, Prentice Hall,
2002
56
modelo del dominio utilización de paquetes

• cómo dividir el Modelo del Dominio
• se deben poner juntos en paquetes los elementos
  que
• se encuentran en el mismo área de interés (están
  estrechamente relacionados por conceptos u
  objetivos)
• están juntos en una jerarquía de clases
• participan en los mismos casos de uso
• están fuertemente asociados
• consejo
• utilizar un paquete Dominio que será el raíz de
  todos los elementos relacionados con el modelo
  del dominio
• utilizar un paquete Elementos Básicos, o
  Conceptos Comunes, para englobar todos los
  elementos compartidos, comunes a otros elementos,
  básicos,...

57
modelo de casos de uso contratos de las
operaciones

• casos de uso normalmente son suficientes para
  describir el comportamiento del sistema
• sin embargo, a veces se necesita una descripción
  más detallada del comportamiento del sistema se
  utilizan los contratos
• describen el comportamiento detallado del sistema
  en función de los cambios de estado de los
  objetos del Modelo del Dominio después de la
  ejecución de una operación del sistema
• se definen contratos para las operaciones del
  sistema (las que ofrece en su interfaz pública
  para gestionar los eventos del sistema entrantes
• las operaciones se identifican descubriendo los
  eventos del sistema

58
modelo de casos de uso contratos de las
operaciones
Estos eventos de entrada del sistema invocan
operaciones del sistema. El evento del sistema
crearNuevaVenta invoca una operación del sistema
denominada crearNuevaVenta y así
sucesivamente. Es similar a cuando en la
programación orientada a objetos un mensaje xyz
invoca el método xyz.
fuente C. Larman, UML y patrones, Prentice Hall,
2002
59
modelo de casos de uso contratos de las
operaciones

• secciones del contrato

60
modelo de casos de uso contratos de las
operaciones

• escritura de contratos
• sólo deben hacerse en algunas operaciones
• son útiles cuando los detalles y complejidad de
  los cambios de estado requeridos son difíciles de
  capturar en los casos de uso (pueden dar lugar a
  un caso de uso excesivamente detallado)
• guía para hacer contratos
• identificar las operaciones del sistema a partir
  de los DSS
• construir un contrato para las operaciones
• para describir las postcondiciones utilizar las
  siguientes categorías
• creación y eliminación de instancias
• modificación de atributos
• formación y rotura de asociaciones
• escribir en pasado se creó una LineaDeVenta
• IMPORTANTE reflejar el establecimiento de
  relaciones entre objetos
• La LineaDeVenta se asoció con la Venta

61
modelo de casos de uso contratos de las
operaciones
62
modelo de casos de uso contratos de las
operaciones
63
modelado de comportamiento no trivial

• diagramas de estado
• representan el comportamiento del sistema desde
  la perspectiva de un solo objeto, mostrando la
  dependencia entre el estado de un objeto y su
  reacción ante los mensajes u otros eventos
• permiten
• identificación de nuevos casos de uso
• construir una descripción formal del
  comportamiento del objeto
• sólo se construyen diagramas de estado de los
  objetos que tienen una vida extendida y un
  comportamiento no trivial
• pueden existir diagramas anidados de nivel más
  bajo que modelan las transiciones de estado de
  forma más detallada. En el ejemplo, podría haber
  un diagrama de nivel más bajo que modelara los
  cambios de estado de Incidente mientras está
  Activo

fuente Ingeniería del Software Orientado a
Objetos, B.Bruegge, A.H. Dutoit, p. 153
64
modelado de comportamiento no trivial

• componentes del diagrama de estados
• estado lo constituyen todos los datos que
  encapsula un objeto en un momento determinado, y
  se representa como una caja con esquinas
  redondeadas
• transición mediante flechas se representa el
  cambio de un estado a otro
• evento provocan las transiciones entre estados,
  y normalmente se trata de la recepción de un
  mensaje por parte del objeto. Se representa
  escribiendo el mensaje en la flecha de transición
• marca de creación un punto negro indica el
  estado inicial del objeto
• marca de destrucción un punto negro rodeado por
  un anillo significa que el objeto ha alcanzado el
  final de su vida y será destruido
• acción representa un mensaje que envía el objeto
  como respuesta a uno recibido, es decir, una
  acción como respuesta a un evento

65
modelado de comportamiento no trivial
66
tarjetas CRC

• tarjetas CRC (Clase, Responsabilidades y
  Colaboraciones)
• no forman parte de UML pero aportan una gran
  utilidad
• identificación de clases y asociaciones
• identificación de navegabilidad de las
  asociaciones
• localización temprana de posibles problemas de
  cohesión y acoplamiento
• una tarjeta CRC consta de
• nombre de la clase
• responsabilidades de la clase
• describen a alto nivel el propósito de la
  existencia de la clase
• normalmente una clase no debe tener más de tres o
  cuatro responsabilidades. Si tiene más, habría
  que plantearse describirla de forma más concisa o
  dividirla la clase porque su cohesión es baja
• colaboradores de la clase
• ayudan a ejecutar cada responsabilidad
• si hay demasiados es que existe un excesivo
  acoplamiento

67
tarjetas CRC

• utilización de las tarjetas CRC
• se recorren los casos de uso, resolviendo cómo el
  modelo de clases proporciona la funcionalidad
  requerida por los casos de uso y si hay elementos
  olvidados
• importante se representa la comunicación entre
  objetos, no entre clases
• una técnica útil es
• asignación a cada miembro del equipo de una o más
  responsabilidades de las tarjetas CRC
• comprobación de la completitud del diseño
  representando diversos escenarios de los casos de
  uso relevantes
• las tarjetas se reparten
• la petición inicial se le da a una persona cuyas
  tarjetas CRC representan una clase cuyas
  responsabilidades incluyen la realización de un
  escenario
• si en la implementación figurada de ese escenario
  la clase necesita la asistencia de uno de sus
  colaboradores, solicitará a la persona que tenga
  la tarjeta CRC correspondiente un mensaje
  solicitando que ejecute una operación
• esa operación debería formar parte de las
  responsabilidades de la tarjeta CRC de la clase
  que ha recibido la petición
• si no existe esa responsabilidad, o está asignada
  a otra clase, es que el diseño es defectuoso o
  incompleto hay que cambiar la clase, crear
  nuevas responsabilidades o cambiar las
  colaboraciones
• mejora la colaboración en el equipo al participar
  todos en el diseño
• pueden utilizarse para hacer un borrador del
  diagrama de clases

68
ejercicio Diagrama de Clases

• En una biblioteca un usuario puede tener
  prestados o reservados un máximo de 3 copias de
  libros o revistas simultáneamente. Si un libro no
  se encuentra disponible cuando lo desea el
  usuario, puede realizar una reserva (de un libro,
  pero no de una copia concreta del libro). Las
  revistas no se pueden reservar.
• El sistema registra quien es el bibliotecario que
  ha prestado una determinada copia de un libro,
  pero no quien ha prestado una revista.
• Los libros se identifican por su ISBN y las
  revistas por el ISSN. Cada copia de cada libro y
  revista tiene un código de registro.

69
análisis estructurado
ANÁLISIS ESTRUCTURADO (De Marco, Gane y Sarson,
Page-Jones, Ward y Mellor, Yourdon,...) Finales
70s
DISEÑO ESTRUCTURADO (Constantine,
Yourdon,...) Mediados 70s
MODELADO DE DATOS
MODELADO FUNCIONAL
MODELADO DE COMPORTAMIENTO
70
diagramas de flujo de datos (DFD)

• FLUJOS DE DATOS
• Representan datos en movimiento mediante flechas
• Convenciones
• No hay datos distintos con el mismo nombre
• Representan conocimiento
• No hay nombres en la entrada y salida de
  almacenamientos
• No representan flujos de control

PROCESOS Muestran una parte del sistema que
transforma datos de entrada en datos de
salida Se describen con una sola frase sencilla
verbo-objeto
PROCESO 1
PROCESO 2
1
2
ENTIDAD EXTERNA
datoA
datoB
datoC
ENTIDADES EXTERNAS Muestran origen y destino de
los datos Persona, organización o sistema que
permanece fuera del contexto del
sistema Proporcionan información sobre la
conexión del sistema con el mundo exterior
ALMACENAMIENTO DE DATOS Representa un conjunto
de datos en reposo. Representa archivos, bases de
datos,... Debe tener entradas y salidas
71
diagramas de flujo de datos (DFD)

• Reglas generales de elaboración de los DFDs
• Escoger nombres con significado saldo_cliente,
  Imprimir Nómina, ...
• Numerar los procesos
• Evitar DFDs excesivamente complejos
• Asegurar la consistencia de los DFDs
• Procesos sin entradas o sin salidas
• Flujos y procesos no etiquetados
• Almacenamientos sólo de lectura o escritura
• Utilización de herramientas CASE
• No mostrar flujo o información de control

72
diagramas de flujo de datos (DFD)

• Los DFDs por niveles
• Subdivisión cuando el sistema es demasiado
  grande cada proceso se despliega en otro DFD
  formado por distintos procesos.
• Diagrama de contexto delimitación del dominio
  del sistema
• Nivel inferior primitivas funcionales (procesos
  que no se despliegan en DFDs)
• Convenciones de los DFDs por niveles
• Equilibrado y descomposición paralela de datos y
  funciones
• Convenciones numéricas
• Diagrama de contexto el proceso se numera con un
  0
• Diagrama de nivel 0 los procesos se numeran 1,
  2, 3, ...
• Otros diagramas numeración de 1 en adelante
  precedido por el número del proceso padre (por
  ejemplo, el DFD 1 es el hijo del proceso 1 y sus
  procesos se numeran 1.1, 1.2, 1.3, ...
• Almacenamientos locales un almacenamiento se
  muestra en un DFD en el primer nivel donde se usa
  como interface entre dos procesos
• Fuente y destino de los datos
• Límite aconsejado de la división 7 procesos
• Primitivas funcionales

73
diagramas de flujo de datos (DFD)
74
diagramas de flujo de datos (DFD)
75
diagramas de flujo de datos (DFD)
76
diagramas de flujo de datos (DFD)
TÉRMINOS
LOCALES ltdiferencia díasgt es ltCurso Público
Programadogt.fecha_comienzo fecha_hoy ltCurso
Público Inminentegt es un ltCurso Público
Programadogt con ltdiferencia díasgt entre 0 y
10 FUNCIÓN Para cada ltCurso Público
Inminentegt Para cada ltReservagt Si
Instrucciones Asistencia Enviadas No
entonces Producir Instrucciones
Asistencia Establecer Instrucciones
Asistencia Enviadas a Si

• Miniespecificación
• Descripción precisa de lo que hace una primitiva
  funcional
• Debe ser rigurosa y comprensible para el lector
  (analista, usuario y diseñador)
• La definición del comportamiento real del sistema
  está en las miniespecs. Los DFDs representan la
  organización y el mapa.
• Componentes de la miniespecificación
• El proceso nombre del proceso correspondiente en
  el DFD
• Inputs de flujos de datos
• Outputs de flujo de datos
• Inputs de datos almacenados entidades,
  relaciones o atributos leídos por el proceso
• Outputs de datos almacenados entidades,
  relaciones o atributos creados, borrados o
  actualizados por el proceso
• Términos locales especifican operaciones y
  comparaciones disponibles sólo en la miniespec
• Función lógica usada por el proceso, y que se
  suele representar en lenguaje estructurado
• Reglas
• Deben contener sólo los datos usados por el
  proceso que describen
• Deben utilizar o producir todos los flujos de
  datos indicados en el proceso
• Deben ser comprensibles para el usuario
• Deben ser completas y sin ambigüedades (es decir,
  dos personas diferentes que comprueben la
  miniespec con los mismos datos deben obtener la
  misma respuesta)

PROCESO Producir instrucciones de asistencia
FLUJOS DE DATOS (INPUTS)
FLUJOS DE DATOS (OUTPUTS) instruccionesde
asistencia
INPUTS DE DATOS ALMACENADOS ltCurso Público
Programadogt.fecha_comienzo ltLocalizacióngt.direccio
nes ltLocalizacióngt.id ltCursogt.nombre ltEstudiantegt.
nombre ltEmpresagt.dirección
OUTPUTS DE DATOS ALMACENADOS ltReservasgt.instru
cciones asistencia enviadas
77
diccionario de datos

• Diccionario de datos listado organizado de
  todos los datos pertinentes al sistema, con
  definiciones rigurosas y precisas que permiten al
  analista y al usuario entender las entradas,
  salidas, almacenamientos y cálculos intermedios.
• Utilidad
• Describe el significado de los flujos y almacenes
  de los DFDs
• Describe la composición de datos compuestos (por
  ejemplo, datos de un cliente) que se pueden
  descomponer en datos más elementales (nombre,
  DNI, dirección,...), tanto de los que se mueven
  por el sistema como de los almacenados.
• Especifica los valores y unidades relevantes de
  datos elementales en los flujos de datos y
  almacenamientos.
• Describe los detalles de las relaciones entre
  almacenes que se reflejan en un diagrama
  entidad-relación.

EJEMPLOS nombre título_cortesía nombre
(segundo_nombre) apellido título_cortesía
Sr. Srta. Sra. Dr. Prof. nombre
carácter legal segundo nombre carácter
legal apellido carácter legal carácter
legal A-Z a-z 0-9 -
78
diccionario de datos

• Especificación de los flujos de datos en el
  Diccionario de Datos. Tipos de flujos de datos
• Múltiple el flujo está compuesto de flujos que
  existen en diferentes momentos de tiempo. Se usan
  para simplificar diagramas de alto nivel.
• Grupo el flujo está compuesto de otros flujos
  que existen en el mismo momento de tiempo. Pueden
  contener otros flujos.
• Elemento el flujo es un dato único, simple.
  Estos flujos son bien un atributo de una entidad
  o un mensaje.
• Par de diálogo el flujo tiene dos nombres
  primero un iniciador y segundo un flujo de
  respuesta. Ambos deben ser grupos o elementos con
  su propia especificación de flujo de datos.

79
diccionario de datos

• Especificación de entidades y relaciones del DER
  en el Diccionario de Datos
• Especificación de entidad. A cada entidad le
  corresponde una especificación, que contiene
• Significado
• Atributos
• Identificadores (atributos clave)
• Especificación de relación. A cada relación le
  corresponde una especificación, que contiene
• Entidades participantes
• Significado de la relación
• Tipo de participación de las entidades
  (obligatoria u opcional)
• Cardinalidad

80
modelado de datos
Cuestiones relevantes del modelado de datos -
Cuales son las entidades (objetos de datos)
primarios que va a procesar el sistema? - Cual
es la composición de cada entidad y qué atributos
la describen? - Qué relaciones existen entre las
entidades?
Necesidad de organizar la información - Ayuda a
entender y nombrar la información - Evita la
redundancia - Asegura la corrección, validación y
completitud - Su organización refleja la política
del negocio
- Profesor - Estudiante - Curso programado
ENTIDADES conjunto de información compuesta
(categorías o cosas que son descritas por la
información)
- El profesor IMPARTE un curso programado - El
alumno SE MATRICULA de un curso programado
RELACIONES asociaciones entre las entidades
COMPONENTES DE LA INFORMACIÓN
ATRIBUTOS definen las propiedades de una
entidad. Se pueden usar para - Nombrar -
Describir - Referenciar Cada ocurrencia de la
entidad tiene un valor para cada atributo
- Número de estudiantes - Fecha de comienzo -
Dirección
Cardinalidad cantidad de ocurrencias de una
entidad que se relacionan con las de otra
entidad. Tipos 11 (1 marido ---gt 1
esposa) 1N (1 madre --gt N hijos) MN (1 tío
--gt N sobrinos, 1 sobrino --gt N tíos)
81
diagrama entidad-relación

• Diagrama Entidad-Relación (DER)
• Propuesto por Chen (1977) para el diseño de bases
  de datos relacionales
• Muestra categorías importantes de información
• Muestra asociaciones relevantes entre categorías
• La política del negocio determina qué es o no es
  relevante
• independiente del procesamiento (transformación)
  de datos
• componentes
• entidades
• atributos
• relaciones

Materia
ENTIDAD
RELACIÓN
cubre
ENTIDAD ASOCIATIVA
Localización
SUPERTIPO
aula
Curso
Curso programado
ATRIBUTO
código
SUBTIPO
Curso programado público
Curso programado interno
82
diagrama entidad-relación

• Entidad
• representación de cualquier composición de
  información compuesta que necesite el sistema
• composición de información todo lo que tiene un
  número de propiedades o atributos diferentes
• Pueden ser
• cosas (informes, pantallas,...)
• entidades externas (productores o consumidores
  de información)
• sucesos (una alarma)
• unidades de una organización (departamento,
  empresa,...)
• ...
• Ejemplos
• edad valor sencillo (no es una entidad)
• persona incorpora edad, peso, altura,... (es
  una entidad)
• Algunas guías
• Las entidades deben nombrarse con sustantivos
• Debe ser posible reconocer ocurrencias
  individuales de la entidad
• Cada entidad debe tener atributos
• La entidad es de interés al sistema y al negocio

CURSO
AVIÓN
EMPLEADO
LIBRO
83
diagrama entidad-relación

• Atributos
• definen propiedades de una entidad
• se usan para
• nombrar una ocurrencia de la entidad
• describir la entidad
• hacer referencias a ocurrencia en otra tabla
• uno o varios atributos se definen como
  identificador (clave para encontrar una
  instancia de la entidad)

color
ID propietario
matrícula
COCHE
modelo
fabricante
carrocería
84
diagrama entidad-relación

• Relaciones
• las entidades se relacionan unas con otras
• una persona posee un coche
• un curso se imparte en un aula
• un cliente solicita un producto
• se definen por el contexto del problema analizado
• para que exista deben existir previamente las
  ocurrencias de las entidades
• Se nombran con frases verbales.
• Se pueden nombrar en los dos sentidos
• el profesor puede impartir un curso
• el curso puede ser impartido por un profesor

85
diagrama entidad-relación
ejemplos de relaciones entre entidades
86
diagrama entidad-relación

• Entidad y tablas
• una entidad encapsula sólo datos
• no hay referencia a operaciones sobre los datos
• se puede representar como una tabla
• encabezamientos tabla atributos del objeto
• cuerpo tabla ocurrencias de la entidad

PROPIETARIO
enlaza una entidad a otra, en este casoCoche a
Propietario
atributos identificativos
atributos descriptivos
atributo de referencia
ID propietario
identificador
color
ID propietario
Matrícula
COCHE
modelo
item
fabricante
carrocería
87
diagrama entidad-relación

• Cardinalidad
• cantidad de ocurrencias (items, instancias) de la
  entidad X que están relacionadas con la entidad Y
• define el número máximo de relaciones de
  entidades que pueden participar en una relación
• ejemplos