ingeniería del software de gestión. tema 3

tema 3 – análisis de sistemas

enrique barreirodepartamento de informática

universidade de vigo

escuela superior de ingeniería informáticaingeniería del software de gestión


© enrique barreiro alonsouniversidade de vigo - departamento de informática


2 / 92

introducción al análisis

ingeniería de requisitoslos 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 / 92


análisisobjetivo:

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 enfoquesestructuradoprototipadoorientado 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

Ingeniería derequerimientos

Análisis

Modelo de casosde uso

:Modelo

Modelo deanálisis:Modelo

Diseño

Modelo dediseño

:Modelo




4 / 92


Comparación del modelo de casos de uso con el modelo de análisis

Define realizaciones de casos de uso y cada una de ellas representa el análisis de un caso de uso del modelo de casos de uso

Define casos de uso que se analizarán con más profundidad en el modelo de análisis

Esboza cómo llevar a cabo la funcionalidad dentro del sistema, incluida la funcionalidad significativa para la arquitectura; sirve como una primera aproximación al diseño

Captura la funcionalidad del sistema, incluida la funcionalidad significativa para la arquitectura

No debe contener redundancias, inconsistencias,... entre los requisitos

Puede contener redundancias, inconsistencias,... entre los requisitos

Utilizado fundamentalmente por los desarrolladores para comprender cómo debería darse forma al sistema, es decir, cómo debería ser diseñado e implementado

Utilizado fundamentalmente como contrato entre el cliente y los desarrolladores sobre qué debería y qué no debería hacer el sistema

Estructurado por clases y paquetesEstructurado por los casos de uso

Vista interna del sistemaVista externa del sistema

Descrito con el lenguaje del desarrolladorDescrito con el lenguaje del cliente

Modelo de análisisModelo de casos de uso




5 / 92


requerimientos cambianteshabitual en grandes sistemas

razonesmuchos 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 conflictoel entorno de negocios y técnico cambia: nuevo hardware, nuevos sistemas, cambios en las prioridades del negocio, cambios legislativos,...

administración de requerimientosproceso 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 / 92


planificación de la administración de requerimientosidentificación de requerimientos

proceso de administración del cambioanálisis del problema y especificación del cambioanálisis del cambio y evaluación económicaimplementació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óninformació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 / 92

el análisis en el proceso unificado

actividades del análisis en el proceso unificadocrear 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 / 92

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 realno muestra componentes software, clases software u objetos software con responsabilidadeses 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 conceptualesasociaciones entre las clases conceptualesatributos 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 / 92

modelo del dominio

ArtículoLineaDeVentacantidad

10..1

Registra-venta-de

Pagocantidad

Ventafechahora

1

1..nContenida-en

1

1

Pagada-mediante

Tienda

direccióntienda

1

*

Almacenado-en

Registro

1

1

Capturada-en

1.. *

1

Alberga

1

1..n

1

*

1.. *

1

1

1

1

1

10..1

concepto u objeto del dominio

asociación

atributos

Modelo del dominio: ejemplo de un Diagrama de Clases




10 / 92

modelo del dominio

pasos en la realización de un modelo del dominio1. identificar y listar las clases conceptuales candidatas

2. representarlas en un modelo del dominio

3. añadir las asociaciones necesarias para registrar las relaciones que hay que mantener en memoria

4. añadir los atributos necesarios para satisfacer los requisitos de información

importante:utilizar el vocabulario del dominio al nombrar las clases conceptuales y atributosexcluir las características irrelevantesno añadir cosas que no se encuentran en el dominio del problema que se está estudiando




11 / 92

modelo del dominio

Venta

fechahora

imprimir()

BaseDeDatosVentas

ComponenteActiveX

Son artefactos software o clases software, por lo que no forman parte del 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

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 / 92

modelo del dominio

clases conceptualesinformalmente: 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 conceptualdefinición de la claseextensión: conjunto de ejemplos a los que se aplica la clase

Una venta representa el hecho de una transición de compra. Sucede un día y a una hora.

Una venta representa el hecho de una transición de compra. Sucede un día y a una hora.

venta-1

venta-2

venta-3

venta-4

símbolo del concepto

definición del concepto

extensión del concepto

Venta

fechahora




13 / 92

modelo del dominio

identificación de clases conceptualespara 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 conceptualesidentificación de frases nominales

Identificar clases conceptuales candidatas

Representar las clases en un modelo del dominio

Añadir las asociac iones necesarias

Añadir los atributos necesarios




14 / 92

modelo del dominio: identificación de clases

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

......

SistemaAutorizaciónPagoCréditoControlDeTraficoAereo

otros sistemas informáticos o electromecánicos externos al sistema

ArtículoPasajero

cosas en un contenedor

Tienda, AlmacénAvión

contenedores de otras cosas

CajeroPiloto

roles de la gente

LineaDeVentalíneas de la transacción

Venta, PagoReserva

transacciones

Tiendalugares

EspecificacionDelProductoDescripcionDelVuelo

especificaciones, diseños o descripciones de las cosas

RegistroAvión

objetos tangibles o físicos

EjemplosCategoría de clase conceptual




15 / 92


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 / 92


Escenario principal de éxito (o flujo básico) de Procesar Venta.

1. El Cliente llega al terminal PDV con mercancías y/o servicios que comprar2. El Cajero inicia una nueva venta3. El Cajero introduce el identificador del artículo4. 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 reglasde precios.El Cajero repite los pasos 3-4 hasta que se indique

5. El Sistema muestra el total con los impuestos calculados6. El Cajero le dice al Cliente el total, y solicita el pago7. El Cliente paga y el Sistema gestiona el pago8. 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).

9. El sistema presenta el recibo10. 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 Cliente4. El Sistema registra el pago en efectivo

Escenario principal de éxito (o flujo básico) de Procesar Venta.

1. El Cliente llega al terminal PDV con mercancías y/o servicios que comprar2. El Cajero inicia una nueva venta3. El Cajero introduce el identificador del artículo4. 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 reglasde precios.El Cajero repite los pasos 3-4 hasta que se indique

5. El Sistema muestra el total con los impuestos calculados6. El Cajero le dice al Cliente el total, y solicita el pago7. El Cliente paga y el Sistema gestiona el pago8. 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).

9. El sistema presenta el recibo10. 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 Cliente4. El Sistema registra el pago en efectivo




17 / 92

entrevistascon clientey usuarios

Controlador InformeDeEmergencia

OficialCampo Incidente

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

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

descripción de los objetos y clasesinicialmente, 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

informaremergencia

Ubicación Descripción del caso de uso

1. El OficialCampo activa la función Informar Emergencia en su PDA.

2. El sistema COMUNICA responde presentando un formulario al OficialCampo. El formulario incluye un menú de tipos de emergencia (incendio, accidente, disturbios,...) y campos para introducir la ubicación, descripción del incidente, petición de recursos,...

3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la situación de emergencia y solicitar recursos específicos. Una vez que ha llenado el formulario, el OficialCampo lo envía oprimiendo el botón “Enviar Informe” y en ese momento se le notifica al Controlador

4. Al Controlador se le notifica un nuevo informe de incidente mediante un cuadro de diálogo desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos llamando al caso de uso AbrirIncidente. Toda la información contenida en el formulario del OficialCampo se incluye automáticamente en el Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al OficialCampo.

5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada.







Estación OficialCampo

Estación Controlador

















conocimientodel dominio

conocimientodel dominio




















18 / 92


lista de clases conceptuales candidatas del dominiogenerada a partir de

lista de categoríasanálisis de lenguaje natural (frases nominales)

restringida a los requisitos que se están estudiando actualmenteejemplo: 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?

...CatálogoDeProductos

EncargadoPago

ClienteVenta

CajeroTienda

LíneadeVentaArtículo

EspecificaciónDelProductoRegistro




19 / 92


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

Venta

tiendaVenta

Tienda

direcciónteléfono

Vuelo

destino

Aeropuerto

nombreVuelo

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.

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 / 92


clases conceptuales de especificación o descripciónse utilizan para especificar o describir otras clasesuna 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 serviciosla eliminación de instancias de las cosas que describen provocan pérdida de información que necesitaría mantenersereduce información redundante o duplicada

Artículo

artículoIDnumeroSeriedescripciónprecio

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.

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.

ObjetoOrdenador : ArtículoObjetoOrdenador :

ArtículoObjetoOrdenador :

Artículo




21 / 92


EspecificaciónDelProducto

descripciónprecioartículoID

Artículo

numeroSerien1

describe

n1

Artículo

artículoIDnumeroSeriedescripciónprecio

Vuelofechanumerohora

Aeropuertonombre

1

n

vuela a

1

n

Vuelo

fechahora

DescripcionVuelo

numeron1 n1

descrito por

Aeropuerto

nombre

1

n

describe vuelos a

1

n

NO SI




22 / 92


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 softwareno son lo mismo, pero el primero “inspiró” el nombre y definición del segundo

Pago

cantidad

Venta

fechahora

1 11 1

Pagada-mediante

Pago

cantidad : Dinero

getDevolucion() : Dinero

Venta

fecha : Datehora : Tiempo

getTotal() : Dinero1 1

pagada mediante

1 1

Modelo del DominioVista del personal involucrado de los conceptos más relevantes del dominioVisualiza los modelos del mundo real.

inspira objetos y nombres en el modelo de diseño

Modelo del DiseñoEl desarrollador orientado a objetos se ha inspirado en el dominio del mundo real al crear las clases software.Visualiza los componentes software




23 / 92

modelo del dominio: representar las clases

representar las clases en un modelo del dominio

se utiliza la notación de clase de UML





Persona

nombre : NombreidEmpleado : Integercargo : String

obtenerFoto()obtenerInformaciónDeContacto()obtenerRegistrosPersonales()

nombre clase

lista de atributos

lista de operaciones (no se suelen reflejar en el modelo del dominio)




24 / 92

modelo del dominio: representar las clases

Registro Artículo Tienda Venta

LineaDeVenta Cajero Cliente Encargado

Pago CatalogoDeProductos

EspecificacionDelProducto

Representación de las clases conceptuales del Sistema PDV




25 / 92

modelo del dominio: asociaciones

asociaciónsegú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

Pago

cantidad

Venta

fechahora

1 11 1

Pagada-mediante

multiplicidad

nombre de la asociación

Flecha de dirección de lectura. Normalmente se excluye.








26 / 92


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

Venta-RegistroReserva-ListaPasajeros

A se conoce/registra/recoge/informa/captura en B

Departamento-TiendaMantenimiento-CompañíaAerea

A es una subunidadorganizativa de B

LíneaDeVenta-VentaTrabajoMantenimiento-RegistroDeMantenimiento

A es una línea de una transacción o importe de B

DescripciónDelArtículo-ArtículoDescripciónDelVuelo-Vuelo

A es una descripción de B

DescripciónArtículo-CatálogoVuelo-PlanificaciónVuelo

A está contenido lógicamente en B

Registro-Tienda, Artículo-EstanteríaPasajero-Avión

A está contenido físicamente en B

LineaDeVenta-VentaEtapaVuelo-RutaVuelo

A es una parte lógica de B

Caja-RegistroAla-Avión

A es una parte física de B

EjemplosCategoría

Cajero-TiendaPiloto-CompañíaAerea

A es miembro de B

Venta-Cliente, Venta-TiendaSalida-Vuelo

A es un evento relacionado con B

Registro-TiendaAvión-CompañíaAerea

A es propiedad de B

LíneaDeVenta-LíneaDeVentaCiudad-Ciudad

A está al lado de B

Pago-VentaReserva-Cancelación

A es una transacción relacionada con otra transacción B

Cliente-PagoPasajero-Billete

A está relacionado con una transacción B

Cliente-CajeroAgenteReservas-Pasajero

A se comunica con B

Cajero-RegistroPiloto-Avión

A utiliza o gestiona B

EjemplosCategoría

relaciones cuya inclusión en el Modelo de Dominio es especialmente útil

relaciones cuya inclusión en el Modelo de Dominio es especialmente útil




27 / 92


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

PagoVenta

11

Pagada-mediante

Tienda

Registro

1 1

Captura

1..*

1

Alberga

1..*

1

111 1

CompañíaAerea

Vuelo Avión

1n

Persona

1..n

1

n1n1

Supervisa

n1

Emplea

1..n

1

Asignado-a

n1

Asignado-a

1n

fuente: C. Larman, UML y patrones, Prentice Hall, 2002




28 / 92


PÓLIZASPÓLIZAS




29 / 92


multiplicidadindica cuántas instancias de una clase A pueden asociarse con una instancia de una clase B

en un momento concretoNO a lo largo de un periodo de tiempo

indica una restricción de diseño que será (o podrá ser) reflejada en el software

Clase*

Clase1..*

Clase1..40

Clase5

Clase3,5,8

cero o más; muchos

uno o más

de uno a 40

exactamente 5

exactamente 3, 5 u 8




30 / 92


multiplicidadpuede 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.

OficialPolicía NúmeroIdentificación

11 11

Asegurado Automóvil1..*1 1..*1

+propiedad+propietario

Autor Libro

**

escribe

**




31 / 92


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

Vuelo Aeropuerto

1n

1n

Vuela-a

1n

Vuela-desde 1n




32 / 92


Registro-TiendaA es propiedad de B o informe de B

LineaDeVenta-LineaDeVentaA está al lado de B

Pago-VentaA es una transacción relacionada con otra transacción B

Cliente-PagoCajero-Pago

A está relacionado con una transacción B

Cliente-CajeroA se comunica con B

Cajero-RegistroEncargado-RegistroEncargado-Cajero, aunque probablemente no es aplicable

A utiliza o gestiona B

No aplicableA es una subunidad organizativa de B

Cajero-TiendaA es miembro de B

(completa) Venta-Tienda(actual) Venta-Registro

A se conoce/registra/recoge/informa/captura en B

LíneaDeVenta-VentaA es una línea de una transacción o informe de B

EspecificacionDelProducto-ArticuloA es una descripción de B

EspecificacionDelProducto-CatalogoDeProductosCatalogoDeProductos-Tienda

A está contenido lógicamente en B

Registro-Tienda, Artículo-Tienda

A está contenido físicamente en B

LineaDeVenta-VentaA es una parte lógica de B

Registro-CajaA es una parte física de B

EjemplosCategoría




33 / 92


navegabilidadindica 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

AsignaturaEstudianteestá cursando

En este caso, la clase Asignatura conocea la clase Estudiante, pero no al revés.




34 / 92


asociaciones reflexivas

Persona

2*

Crea+padre

+hijo

2*




35 / 92


agregaciónes 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

Rueda

Motor

Coche 41

1

1

Radio0..1

1

1

1

41

0..1

1




36 / 92


agregación de composiciónla 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 compartidala 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

1

Coche

1

1

1

Motor

DiagramaUML

ElementoUML*

*

*

*




37 / 92


identificación de la agregaciónsi 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ógicocuando alguna propiedad del compuesto se propaga a las partes, como la ubicacióncuando las operaciones que se aplican sobre el compuesto se propagan a las partes, como la destrucción, movimiento o grabación

Venta LineaDeVenta

1..n1 1..n1

CatalogoDeProductos EspecificacionDelProducto1..n1 1..n1




38 / 92


generalizaciónactividad 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

cantidad : Dinero

PagoEnEfectivo PagoACredito PagoConCheque

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.

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.

Pago en efectivo Pago con cheque

Pago a crédito

PAGO





39 / 92


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

Venta

fechahora

1

1

Pago

cantidad : Dinero


Pagada-mediante

El diagrama indica que todos los Pagos tienen una cantidad y que se asocian con una Venta

El diagrama indica que todos los Pagos tienen una cantidad y que se asocian con una Venta





40 / 92





41 / 92


cuando dividir una clase conceptual en subclasescuando 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.

Pagos: no aplicableBiblioteca: no aplicableInvestigación de Mercado: Hombre, subclase de Persona, se comporta de manera diferente a la Mujercon respecto a los hábitos de compras

El concepto de la subclase representa una cosa animada (personal, maquinaria, animal...) 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

Pagos: PagoACredito, subclase de Pago, se gestiona de manera diferente a otros tipos de pagos en el modo de autorizarloBiblioteca: Software, subclase de RecursoPrestable, requiere un depósito antes de que pueda prestase

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

Pagos: PagoACredito, subclase de Pago, asociada con una TarjetaDeCreditoBiblioteca: Vídeo, subclase de RecursoPrestable, asociada con un Encargado

La subclase tiene asociaciones adicionales de interés

Pagos: no aplicableBiblioteca: Libro, subclase de RecursoPrestable, tiene un atributo ISBN

La subclase tiene atributos adicionales de interés

EjemplosMotivación de la subclase conceptual




42 / 92


cuando definir una superclase conceptualcuando 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 softwarela herencia

es un mecanismo software para hacer que las características de la superclase se apliquen a las subclaseses 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ónlas 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 / 92

superclase justificada por atributos comunes y asociaciones

Pago

cantidad : Dinero

Ventafechahora

PagoEnEfectivo PagoACredito

TarjetaDeCredito Cheque

PagoConCheque

11

11Pagada-mediante

n

1

n

1

Identifica-crédito-con

1

1

1

1

Pagado-con

cada subclase de Pago se maneja de manera diferente

asociaciones adicionales


Sistema PDV: Clases de Pago





44 / 92


Sistema PDV: Clases de ServicioAutorización

PagoACrédito

ServicioAutorizaciónCrédito

n

1

PagoConCheque

ServicioAutorizaciónCheques

n

1

ServicioAutorizac ión

Tienda

n

1

Autoriza-pagos-de

n

1

Autoriza

n

1

Autorizan

1

Superclase justificada por atributos comunes y asociaciones

Asociaciones adicionales





45 / 92


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.

la clase abstracta se representa en cursiva

Pagocantidad : Dinero





46 / 92


clases asociaciónen 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íahay un atributo relacionado con una asociaciónel tiempo de vida de las instancias de la clase asociación depende de la asociaciónexiste una asociación muchos-a-muchos entre dos conceptos, e información asociada con la propia asociación





47 / 92


Empresa Persona

**

Empleo

salario

**

Emplea

Una persona podría tener empleos en varias empresas




48 / 92

modelo del dominio: atributos

atributoes 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 fechay hora

notación UML: se muestran en el segundo compartimento del rectángulo de la clase. Los tipos se muestran opcionalmente





Venta

fechahoraInicio : Hora

atributos




49 / 92


tipos de atributosen 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 horaotros: 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

Vuelo AeropuertoVuela-a

Vuelo

destino

destino es un concepto complejo

destino es un concepto complejo

Peor

Mejor




50 / 92


tipos de datos como clasesun 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

EspecificaciónDelProducto ArticuloID

11 11

Tienda Dirección

11 11

EspecificaciónDelProductoid : ArticuloID

Tienda

dirección : Dirección

Correcto

Correcto





51 / 92


cantidades y unidades de los atributosla 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

Pago Cantidadcantidad : Número

1n

UnidadnombreMoneda

1n

Tiene-importe

1n

Está-en

1n

Pago

cantidad : Cantidad

Pagocantidad : Dinero

Pagocantidad : Número

no es útilno es útil

Incorrecto

Correcto

las cantidades son valores de datos simples, por lo que es adecuado representarlas en la sección de atributos

las cantidades son valores de datos simples, por lo que es adecuado representarlas en la sección de atributos

variación: Dinero es una especialización de Cantidad cuya unidad es una moneda

variación: Dinero es una especialización de Cantidad cuya unidad es una moneda





52 / 92

modelo del dominio

EspecificacionDelProducto

descripciónprecioarticuloID

CatalogoDeProductos

1..n1

Articulo

Encargado

LineaDeVenta

cantidad

1n

1..n

0..1

Tiendadirecciónnombre

n

1

n1

Pago

cantidad

Venta

fechahora

1

1..n

1

n

1

1

Cliente

1

1

Registro1..n

1

1111

Cajero

1

1

1

1

11

1

1Pagada-mediante

1

1

Iniciada-por Registra-ventas-en

Iniciado-por1..n

1Alberga

Abastece

n1

Capturada-en11

1

n

Registra-completas

Contenida-en

1

1..n Utilizado-porn

11..n1

Contiene

Descrita-por

1n

1..n

0..1

Registra-venta-de





53 / 92

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 UMLpaquete: 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 NombrePaquete::NombreElemento




54 / 92


Elementos Básicos

Dominio

Ventas

V e n t a s

Una clase referenciada en un paquete

Una clase referenciada en un paquete

Elementos Básicos

Tienda Registro1..*1

tiene

1..*1

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).

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).





55 / 92


Productos

Productos

Dominio

Pagos

Transacciones de Autorización

Básico

Ventas





56 / 92


cómo dividir el Modelo del Dominiose 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 clasesparticipan en los mismos casos de usoestán fuertemente asociados

consejoutilizar un paquete Dominio que será el raíz de todos los elementos relacionados con el modelo del dominioutilizar un paquete Elementos Básicos, o Conceptos Comunes, para englobar todos los elementos compartidos, comunes a otros elementos, básicos,...




57 / 92

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 / 92


: Sistema: Cajero

crearNuevaVenta()

introducirArticulo(artID, cantidad)

descripción, total

*[más artículos]

finalizarVenta()

total con impuestos

realizarPago(cantidad)

cambio devuelto, recibo

Estos eventos de entrada del sistema invocan operaciones del sistema.

El evento del sistema crearNuevaVentainvoca una operación del sistema denominada crearNuevaVenta y asísucesivamente.

Es similar a cuando en la programación orientada a objetos un mensaje xyzinvoca el método xyz.

Estos eventos de entrada del sistema invocan operaciones del sistema.

El evento del sistema crearNuevaVentainvoca una operación del sistema denominada crearNuevaVenta y asísucesivamente.

Es similar a cuando en la programación orientada a objetos un mensaje xyzinvoca el método xyz.





59 / 92


secciones del contrato

Describen cambios en el estado de los objetos del Modelo del Dominio.

Los cambios de estado del Modelo del Dominio comprenden:

la creación y eliminación de instancias,

formación o rotura de asociaciones (enlaces UML) y

modificaciones en los atributos

No son acciones que se ejecuten durante la operación.

Postcondiciones

Suposiciones relevantes sobre el estado del sistema o de los objetos del Modelo del Dominio antes de la ejecución de la operación.

No se comprobará en la lógica de esta operación, se asume que son verdad y son suposiciones no triviales de relevancia para ellector

Precondiciones

(opcional) Casos de uso en los que pueden tener lugar esta operación

Referencias cruzadas

Nombre de la operación y parámetrosOperación




60 / 92


escritura de contratossó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 contratos1. identificar las operaciones del sistema a partir de los DSS2. construir un contrato para las operaciones 3. para describir las postcondiciones utilizar las siguientes

categoríascreación y eliminación de instanciasmodificación de atributosformació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 / 92


-Se creó una instancia de LineaDeVenta ldv (creación de instancias)

- ldv se asoció con la Venta actual (formación de asociaciones)

- ldv.cantidad pasó a ser cantidad (modificación de atributos)

- ldv se asoció con una EspecificaciónDelProducto, en base a la coincidencia del articuloID (formación de asociaciones)

Postcondiciones

Hay una venta en cursoPrecondiciones

Caso de uso: Procesar VentaReferencias cruzadas

introducirArtículo(articuloID:ArticuloID, cantidad:integer)Operación




62 / 92


-Se creó una instancia de Pago p (creación de instancias)

- p.cantidadEntregada pasó a ser cantidad (modificación de atributos)

- p se asoció con la Venta actual (formación de asociaciones)

- La Venta actual se asoció con la Tienda (formación de asociaciones)

Postcondiciones

Hay una venta en cursoPrecondiciones

Caso de Uso: Procesar VentaReferencias cruzadas

realizarPago(cantidad:Dinero)Operación




63 / 92

Incidente

númeroInforme : IntegertipoEmergencia : (incendio, tráfico, otro)ubicación : Stringdescripción : StringcantRecursosAsignados : Integerfecha : Date

modelado de comportamiento no trivial

diagramas de estadorepresentan 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

permitenidentificación de nuevos casos de usoconstruir 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

Activo

Inactivo Cerrado

Archivado

cantRecursosAsignados == 0

se envían todos los informes

cuando incidente.fecha > 1 año

fuente: Ingeniería del Software Orientado a Objetos, B.Bruegge, A.H. Dutoit, p. 153




64 / 92


componentes del diagrama de estadosestado: 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

en préstamo

entry/ libro.devuelto(self)

en la estantería

entry/ libro.prestado(self)

devolver()

tomarPrestado()




65 / 92


inactivo

enfriando

calentando

inicio final

tempAlcanzada

apagardemasiadoCaliente

( tempDeseada ) demasiadoFrío( tempDeseada )

tempAlcanzada

demasiadoCaliente( tempDeseada )

demasiadoFrío( tempDeseada )

estado

transición

evento

Climatizador

en preparación

activo

inicio

encender( )

preparado




66 / 92

tarjetas CRC

tarjetas CRC (Clase, Responsabilidades y Colaboraciones)

no forman parte de UML pero aportan una gran utilidad

identificación de clases y asociacionesidentificación de navegabilidad de las asociacioneslocalización temprana de posibles problemas de cohesión y acoplamiento

una tarjeta CRC consta denombre de la claseresponsabilidades de la clase

describen a alto nivel el propósito de la existencia de la clasenormalmente 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 claseayudan a ejecutar cada responsabilidadsi hay demasiados es que existe un excesivo acoplamiento

Copia

Mantener los datos sobre las copias prestadas actualmente

Atender peticiones para tomar prestados y devolver copias

ColaboradoresResponsabilidades

SocioBiblioteca

Libro

Mantener los datos sobre una copia determinada de un libro.

Informar del correspondiente Librocuando es prestado y devuelto.


Copia

CopiaMantener los datos sobre un libro.

Saber si hay copias disponibles para tomar prestadas.


Libro




67 / 92

tarjetas CRC

utilización de las tarjetas CRCse 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 CRCcomprobación de la completitud del diseño representando diversos escenarios de los casos de uso relevantes

las tarjetas se repartenla petición inicial se le da a una persona cuyas tarjetas CRC representan una clase cuyas responsabilidades incluyen la realización de un escenariosi 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ónesa operación debería formar parte de las responsabilidades de la tarjeta CRC de la clase que ha recibido la peticiónsi 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 / 92

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 / 92

análisis estructurado

DISEÑO ESTRUCTURADO(Constantine, Yourdon,...)Mediados 70’s

DISEÑO ESTRUCTURADO(Constantine, Yourdon,...)Mediados 70’s

ANÁLISIS ESTRUCTURADO(De Marco, Gane y Sarson, Page-Jones,Ward y Mellor, Yourdon,...)Finales 70’s

ANÁLISIS ESTRUCTURADO(De Marco, Gane y Sarson, Page-Jones,Ward y Mellor, Yourdon,...)Finales 70’s

DICCIONARIODE DATOS

Diagrama de Flujo de

Datos

Diagrama deTransición de Estados

Diagrama Entidad-Relación

Descripc

i ón de e

ntidad

esEspecificaci ón de procesos

Especificación de control

MODELADO DE DATOSMODELADO DE DATOS MODELADO FUNCIONALMODELADO FUNCIONAL

MODELADO DE COMPORTAMIENTOMODELADO DE COMPORTAMIENTO




70 / 92

diagramas de flujo de datos (DFD)

ENTIDADEXTERNA PROCESO 1 PROCESO 2

Almacenamientode datos

datoA datoB

datoC

FLUJOS DE DATOS

Representan datos en movimiento mediante flechasConvenciones:• 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

1 2

ALMACENAMIENTO DE DATOS

Representa un conjunto de datos en reposo.Representa archivos, bases de datos,...Debe tener entradas y salidas

ENTIDADES EXTERNAS

Muestran origen y destino de los datosPersona, organización o sistema que permanece fuera del contexto del sistemaProporcionan información sobre la conexión del sistema con el mundo exterior




71 / 92


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 salidasFlujos y procesos no etiquetadosAlmacenamientos sólo de lectura o escrituraUtilización de herramientas CASE

No mostrar flujo o información de control




72 / 92


Los DFDs por nivelesSubdivisió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 sistemaNivel inferior: primitivas funcionales (procesos que no se despliegan en DFDs)

Convenciones de los DFDs por nivelesEquilibrado y descomposición paralela de datos y funciones

Convenciones numéricas:Diagrama de contexto: el proceso se numera con un 0Diagrama 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 datosLímite aconsejado de la división: 7 procesosPrimitivas funcionales




73 / 92


0Sistemade Pedidos de Inventario

CLIENTE PROVEEDOR

DIRECCIÓNENTIDADTARJETA CRÉDITO

Pago_Cliente

Pedido Cliente

Pedido_Proveedor

Pago_Proveedor

Producto_Stock

Factura_Proveedor

Petición_Comprobación_CréditoDetalles_Crédito

Políticas_Ventas_y_Cuotas

Informe_Ventas

Factura_Cliente

Envío_Cliente

Devolución_Cliente

Devolución_Cliente

Confirmación_Pedido

Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

Sample Yourdon process modelc:\ecwin\samples\yddfd\context.dfdSales Order ProcessingFeb-16-1993Wayne McDonaldDec-12-1993EasyCASE




74 / 92


1

RECIBIRPEDIDO

Productos Devueltos

2

ENVIARPEDIDO

4

RECIBIRDEVOLUCIONES

5GENERARINFORMES VENTAS

3

GESTIONARSTOCKStock

Detalles_Pedido

Clientes

Representante Ventas

Cliente

Pago_Cliente

Pedido ClientePedido_Proveedor

Pago_Proveedor

Producto_Stock

Factura_Proveedor

Petición_Comprobación_Crédito

Detalles_Crédito

Informe_Ventas

Factura_Cliente

Envío_Cliente

Devolución_Cliente

Reintegro_Cliente

Producto_DevueltoNúmero_Empleado

Cliente

Detalles_Pedido

Producto_DevueltoDirección_Envío

Nombre_Empleado_y_Supervisor

Políticas_Ventas_y_Cuotas


Dirección_Factura


Sample Yourdon process modelc:\ecwin\samples\yddfd\dfd0.dfdProcess OrdersFeb-18-1993Wayne McDonaldDec-12-1993EasyCASE




75 / 92


1.1OBTENERINFORMACIÓN CLIENTE

1.2OBTENERITEMS PEDIDO

1.3

COMPROBARSTOCK

1.4

CONFIRMARCRÉDITO

1.5

CONFIRMARPEDIDO

Clientes

Detalles Pedido

Stock

Representante Ventas

Pago_Cliente

Info_Pedido

Petición_Comprobación_Crédito

Detalles_Crédito

Número_Empleado

Cliente

Items_Pedido_Cliente

Info_Cliente

Item_Línea_Pedido

Número_PedidoItem_Línea_Pedido

Item_Línea_Pedido

Estado_Item_Pedido

Item_Línea_Pedido

Crédito_OK


Forma_Pago_Cliente


Sample Yourdon process modelc:\ecwin\samples\yddfd\dfd1.dfdTake OrderFeb-23-1993Wayne McDonaldDec-12-1993EasyCASE




76 / 92

TÉRMINOS LOCALES<diferencia días> es

<Curso Público Programado>.fecha_comienzo – fecha_hoy<Curso Público Inminente> es un <Curso Público Programado>

con <diferencia días> entre 0 y 10

FUNCIÓN

Para cada <Curso Público Inminente>Para cada <Reserva>

Si Instrucciones Asistencia Enviadas = “No” entoncesProducir Instrucciones AsistenciaEstablecer Instrucciones Asistencia Enviadas a “Si””

TÉRMINOS LOCALES<diferencia días> es

<Curso Público Programado>.fecha_comienzo – fecha_hoy<Curso Público Inminente> es un <Curso Público Programado>

con <diferencia días> entre 0 y 10

FUNCIÓN

Para cada <Curso Público Inminente>Para cada <Reserva>

Si Instrucciones Asistencia Enviadas = “No” entoncesProducir Instrucciones AsistenciaEstablecer 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 DFDInputs de flujos de datosOutputs de flujo de datosInputs de datos almacenados: entidades, relaciones o atributos leídos por el procesoOutputs de datos almacenados: entidades, relaciones o atributos creados, borrados o actualizados por el procesoTérminos locales: especifican operaciones y comparaciones disponibles sólo en la miniespecFunció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 describenDeben utilizar o producir todos los flujos de datos indicados en el procesoDeben ser comprensibles para el usuarioDeben 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<Curso Público Programado>.fecha_comienzo<Localización>.direcciones<Localización>.id<Curso>.nombre<Estudiante>.nombre<Empresa>.dirección

OUTPUTS DE DATOS ALMACENADOS <Reservas>.instrucciones asistencia enviadas




77 / 92

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.

Notación

= está compuesto de

+ y

( ) opcional (puede estar o no presente)

n{ }m iteración

** comentario

@ identificador (campo clave) de unalmacenamiento

| separa opciones alternativas

Notación

= está compuesto de

+ y

( ) opcional (puede estar o no presente)

n{ }m iteración

** comentario

@ identificador (campo clave) de unalmacenamiento

| separa opciones alternativas

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 |’ | - | |

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 / 92


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.

FLUJO DE DATOS Instrucciones_ReservaSIGNIFICADO Las instrucciones notificadas por el cliente concernientes a la

reserva de un curso.ESTRUCTURA múltipleFLUJOS DEDATOSCONTENIDOS

Reserva_Provisional,Reserva_en_Firme,Cancelación_Estudiante

FLUJO DE DATOS Reserva_ProvisionalSIGNIFICADO Reserva no confirmada para una plaza en un curso. Las reservas

provisionales se asumen como canceladas si no se recibe unaReserva_en_Firme del cliente en el momento de comenzar el curso

ESTRUCTURA grupoCOMPOSICIÓN Datos_Cliente

+ Datos_Empresa_Cliente+ (Tratamiento_Estudiante)+ Nombre_Estudiante+ Identificación_Curso

FLUJO DE DATOS Nombre_EstudianteESTRUCTURA elementoENTIDAD ESTUDIANTECOMPOSICIÓN {Carácter_Alfabético}30

FLUJO DE DATOS Petición_Sumario_ReservaFLUJO DE DATOS Sumario_ReservaSIGNIFICADO Diálogo relativo a la gestión sobre reservasESTRUCTURA par de diálogo

FLUJO DE DATOS Petición_Sumario_ReservaSIGNIFICADO Petición para conocer el número de estudiantes matriculados en los

cursos en la fecha actualESTRUCTURA grupoCOMPOSICIÓN 1{Identificación_Curso}

FLUJO DE DATOS Sumario_ReservaSIGNIFICADO Relación del número de matriculados en los cursosESTRUCTURA grupoCOMPOSICIÓN 1{Identificación_Curso + Reservas_Totales} + Fecha_Actual




79 / 92


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:

SignificadoAtributosIdentificadores (atributos clave)

Especificación de relación. A cada relación le corresponde una especificación, que contiene:

Entidades participantesSignificado de la relaciónTipo de participación de las entidades (obligatoria u opcional)Cardinalidad

Ejemplo ENTIDAD:

ENTIDAD CURSOSIGNIFICADO Cada CURSO es un seminario estándar que puede ser programado

para llevarse a cabo en determinadas fechas o bajo demanda declientes específicos

ATRIBUTOS Identificación_CursoNombre_CursoDuración_CursoNúmero_Máximo_Estudiantes

IDENTIFICADORES Identificación_CursoNombre_Curso

Ejemplo RELACIÓN

RELACIÓN cubreENTIDADESPARTICIPANTES

CURSO cubre MATERIA

SIGNIFICADO Un CURSO cubre una determinada MATERIA si en su desarrollo setrata ésta con una cierta profundidad

PARTICIPACIÓN CURSO: opcionalMATERIA: opcional

CARDINALIDAD CURSO 1:NMATERIA 1:N




80 / 92

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?

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

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

COMPONENTES DELA INFORMACIÓNCOMPONENTES DE

LA INFORMACIÓN

ENTIDADES: conjunto de información compuesta (categorías o cosas que son descritas por la información)

ENTIDADES: conjunto de información compuesta (categorías o cosas que son descritas por la información)

RELACIONES: asociaciones entre las entidadesRELACIONES: asociaciones entre las entidades

ATRIBUTOS: definen las propiedades de una entidad. Se pueden usar para:- Nombrar- Describir- ReferenciarCada ocurrencia de la entidad tiene un valor para cada atributo

ATRIBUTOS: definen las propiedades de una entidad. Se pueden usar para:- Nombrar- Describir- ReferenciarCada ocurrencia de la entidad tiene un valor para cada atributo

- Profesor- Estudiante- Curso programado

- Profesor- Estudiante- Curso programado

- El profesor IMPARTE un curso programado- El alumno SE MATRICULA de un curso programado

- El profesor IMPARTE un curso programado- El alumno SE MATRICULA de un curso programado

- Número de estudiantes- Fecha de comienzo- Dirección

- 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: 1:1 (1 marido ---> 1 esposa)1:N (1 madre --> N hijos)M:N (1 tío --> N sobrinos, 1 sobrino --> N tíos)

Cardinalidad: cantidad de ocurrencias de una entidad que se relacionan con las de otra entidad.

Tipos: 1:1 (1 marido ---> 1 esposa)1:N (1 madre --> N hijos)M:N (1 tío --> N sobrinos, 1 sobrino --> N tíos)




81 / 92

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:entidadesatributosrelaciones

Materia

Curso

Localización

Cursoprogramado

Cursoprogramado

público

Cursoprogramado

interno

cubre

RELACIÓNENTIDAD

ENTIDADASOCIATIVA

SUPERTIPO

SUBTIPO

código

aula

ATRIBUTO




82 / 92


Entidadrepresentació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 sustantivosDebe ser posible reconocer ocurrencias individuales de la

entidadCada entidad debe tener atributosLa entidad es de interés al sistema y al negocio

CURSO

AVIÓN

EMPLEADO

LIBRO




83 / 92


Atributosdefinen propiedades de una entidad

se usan paranombrar una ocurrencia de la entidaddescribir la entidadhacer referencias a ocurrencia en otra tabla

uno o varios atributos se definen como identificador (“clave”para encontrar una instancia de la entidad)

COCHE

matrícula

modelo

fabricante

color

carrocería

ID propietario




84 / 92


Relacioneslas entidades se relacionan unas con otras:

una persona posee un cocheun curso se imparte en un aulaun 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 cursoel curso puede ser impartido por un profesor

PROFESOR CURSOpuede impartir

Ana Introd. JavaManuel AccessJosé Cobol

PROFESOR CURSOpuede impartir

Ana Introd. JavaManuel AccessJosé Cobol

Puedeimpartir CURSOPROFESOR




85 / 92


Puedeimpartir

CURSO

PROFESOR

Haasistido

reservaESTUDIANTE

CLIENTE

CURSOPÚBLICO

PLANIFICADO

Puedeimpartir CURSOPROFESOR

pilota VUELOPILOTO

AVIÓN

asignado

ejemplos de relaciones entre entidades




86 / 92


Entidad y tablasuna entidad encapsula sólo datos

no hay referencia a operaciones sobre los datos

se puede representar como una tablaencabezamientos tabla: atributos del objetocuerpo tabla: ocurrencias de la entidad

PVSAzulSedánRE766MeganeRenault

JRIGrisCoupeFO677FocusFord

EBMAzulSportBM567525BMW

RSPRojoSedánAB123XsaraCitroen

ID Propietario

ColorTipo carrocería

Matricula

ModeloFabricante

COCHE

Matrícula

modelo

fabricante

color

carrocería

ID propietario

atributos identificativos

identificador

atributos descriptivos

atributo de referencia

PROPIETARIO

ID propietario

item

enlaza una entidad a otra, en este casoCoche a Propietario




87 / 92


Cardinalidadcantidad 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:1:1 (1 marido ---> 1 esposa)1:N (1 madre --> N hijos)M:N (1 tío --> N sobrinos, 1 sobrino --> N tíos)

posee COCHEPROPIETARIO

1:n 1:1

FABRICANTEconstruye 1:n

1:1




88 / 92


Entidades asociativas

- Entidad asociativa: entidad Y relación:

- tiene atributos (en su papel de entidad)- asocia ocurrencias de otras entidades (en su papel de relación)- como entidad puede tomar parte en otras relaciones

Entidades asociativas

- Entidad asociativa: entidad Y relación:

- tiene atributos (en su papel de entidad)- asocia ocurrencias de otras entidades (en su papel de relación)- como entidad puede tomar parte en otras relaciones

CURSO

CURSOPROGRAMADO

LOCALIZACIÓN

PROFESOR imparte

Fechacomienzo

Subtipo

- Grupo de items de entidades que:- tienen atributos específicosno relevantes para todos los

items de la entidad- pueden participar en relaciones no permitidas para todos los

items de la entidad- Puede haber cualquier número de subtipos- La entidad clasificada se denomina supertipo- Un item del subtipo es el mismo item del supertipo.

Subtipo

- Grupo de items de entidades que:- tienen atributos específicosno relevantes para todos los

items de la entidad- pueden participar en relaciones no permitidas para todos los

items de la entidad- Puede haber cualquier número de subtipos- La entidad clasificada se denomina supertipo- Un item del subtipo es el mismo item del supertipo.

Vehículo

Vehículoserviciopúblico

Vehículoprivado

SUBTIPOS

SUPERTIPO

Todos los vehículostienen atributos como“velocidad máxima” o“potencia”

Sólo los vehículos públicos tienen atributos como “número máximo de pasajeros”




89 / 92

administración del análisis: documentación

documentos de análisis de requerimientos (RAD)en él se documentan los resultados de la actividad de obtención de requerimientos y la actividad de análisis

describe totalmente el sistema desde el punto de vista de los requerimientos funcionales y no funcionales

usuarios del RAD:clienteusuariosadministradores del proyectoanalistas del sistemadiseñadores del sistema

debe escribirse cuando el modelo de casos de uso sea estable, es decir, cuando casi no haya modificaciones de requerimientos

se actualiza durante el proceso de desarrollo cuando se descubren problemas de especificaciones o cuando cambia el alcance del sistema




90 / 92

administración del análisis: responsabilidades

involucración de muchos participantesproblemas de integración y comunicación en el proyecto

solución: asignación de papeles y responsabilidades bien definidos

tipos de papeles:generación de información

usuario: experto en el dominio, genera información sobre el sistema, tareas,...analista: experto en el dominio de desarrollo, modela y genera información sobre el futuro sistema

integracióncliente: integra la información del dominio de aplicación, resolviendo inconsistencias en las expectativas de los usuariosarquitecto: unifica los modelos de casos de uso y objetos desde un punto de vista del sistema, proporcionando una filosofía del sistema e identificando omisiones en los requerimientos. Si hay distintos analistas pueden tener diferentes estilos y diferentes vistas departes del sistema de las que no son responsables.editor de documentos: responsable del formato general del documento y su índicegerente de configuración: mantiene el historial de revisiones del documento, así como la información de rastreabilidad que relaciona el RAD con otros documentos (por ejemplo, del diseño)

revisiónrevisor: valida el RAD para que sea correcto, completo, consistente, realista, verificable y rastreable. Son mejores revisores los individuos que no han estado involucrados en el desarrollo




91 / 92

administración del análisis: comunicación

factores que influyen en la comunicacióndiferentes conocimientos de los participantes

diferentes expectativas de los participantes

equipos de nueva formación

sistema en evolución (cambio de significado de términos)

enfoques que mejoran esos factoresdefinición clara de responsabilidades

definición de objetivos claros y criterios de éxito

tormentas de ideas




92 / 92

bibliografía

Larman, C., UML y patrones, cap. 10, 11, 12, 13, 26 y 27

Jacobson, I., Booch, G. y Rumbaugh, J., El Proceso Unificado de Desarrollo”, cap. 8

Stevens, P., Utilización de UML en ingeniería del software con objetos y componentes, cap. 5, 6, 9, 10, 11 y 12

Bruegge, B., Dutoit, A.H., Ingeniería del Software Orientado a Objetos, cap. 5

ingeniería del software de gestión. tema 3

Technology