Upload
enrique-barreiro
View
1.869
Download
0
Embed Size (px)
DESCRIPTION
Transparencias del Tema 3 (Análisis de Sistemas) de la asignatura Ingeniería del Software de Gestión de la Escuela Superior de Ingeniería Informática.
Citation preview
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
3 / 92
introducción al análisis
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
4 / 92
introducción al análisis
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
5 / 92
introducción al análisis
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.
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
6 / 92
introducción al análisis
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
15 / 92
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
16 / 92
modelo del dominio: identificación de clases
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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.
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
Estación OficialCampo
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.
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
Estación OficialCampo
conocimientodel dominio
conocimientodel dominio
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.
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
Estación OficialCampo
modelo del dominio: identificación de clases
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
18 / 92
modelo del dominio: identificación de clases
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
19 / 92
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
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.
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
20 / 92
modelo del dominio: identificación de clases
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
21 / 92
modelo del dominio: identificación de clases
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
22 / 92
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 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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
Identificar clases conceptuales candidatas
Representar las clases en un modelo del dominio
Añadir las asociac iones necesarias
Añadir los atributos necesarios
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)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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.
Identificar clases conceptuales candidatas
Representar las clases en un modelo del dominio
Añadir las asociac iones necesarias
Añadir los atributos necesarios
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
26 / 92
modelo del dominio: asociaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
27 / 92
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
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
28 / 92
modelo del dominio: asociaciones
PÓLIZASPÓLIZAS
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
29 / 92
modelo del dominio: asociaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
30 / 92
modelo del dominio: asociaciones
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
**
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
31 / 92
modelo del dominio: asociaciones
pueden existir dos o más asociaciones entre dos clases conceptuales
Vuelo Aeropuerto
1n
1n
Vuela-a
1n
Vuela-desde 1n
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
32 / 92
modelo del dominio: asociaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
33 / 92
modelo del dominio: asociaciones
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.
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
34 / 92
modelo del dominio: asociaciones
asociaciones reflexivas
Persona
2*
Crea+padre
+hijo
2*
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
35 / 92
modelo del dominio: asociaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
36 / 92
modelo del dominio: asociaciones
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*
*
*
*
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
37 / 92
modelo del dominio: asociaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
38 / 92
modelo del dominio: asociaciones
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
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
39 / 92
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
Venta
fechahora
1
1
Pago
cantidad : Dinero
PagoEnEfectivo PagoACredito PagoConCheque
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
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
40 / 92
modelo del dominio: asociaciones
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
41 / 92
modelo del dominio: asociaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
42 / 92
modelo del dominio: asociaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
modelo del dominio: asociaciones
Sistema PDV: Clases de Pago
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
44 / 92
modelo del dominio: asociaciones
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
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
45 / 92
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.
la clase abstracta se representa en cursiva
Pagocantidad : Dinero
PagoEnEfectivo PagoACredito PagoConCheque
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
46 / 92
modelo del dominio: asociaciones
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
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
47 / 92
modelo del dominio: asociaciones
Empresa Persona
**
Empleo
salario
**
Emplea
Una persona podría tener empleos en varias empresas
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
Identificar clases conceptuales candidatas
Representar las clases en un modelo del dominio
Añadir las asociac iones necesarias
Añadir los atributos necesarios
Venta
fechahoraInicio : Hora
atributos
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
49 / 92
modelo del dominio: atributos
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
50 / 92
modelo del dominio: atributos
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
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
51 / 92
modelo del dominio: atributos
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
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
54 / 92
modelo del dominio: utilización de paquetes
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).
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
55 / 92
modelo del dominio: utilización de paquetes
Productos
Productos
Dominio
Pagos
Transacciones de Autorización
Básico
Ventas
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
56 / 92
modelo del dominio: utilización de paquetes
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,...
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
58 / 92
modelo de casos de uso: contratos de las operaciones
: 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.
fuente: C. Larman, UML y patrones, Prentice Hall, 2002
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
59 / 92
modelo de casos de uso: contratos de las operaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
60 / 92
modelo de casos de uso: contratos de las operaciones
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
61 / 92
modelo de casos de uso: contratos de las operaciones
-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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
62 / 92
modelo de casos de uso: contratos de las operaciones
-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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
64 / 92
modelado de comportamiento no trivial
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()
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
65 / 92
modelado de comportamiento no trivial
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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.
ColaboradoresResponsabilidades
Copia
CopiaMantener los datos sobre un libro.
Saber si hay copias disponibles para tomar prestadas.
ColaboradoresResponsabilidades
Libro
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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.
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
71 / 92
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 salidasFlujos y procesos no etiquetadosAlmacenamientos sólo de lectura o escrituraUtilización de herramientas CASE
No mostrar flujo o información de control
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
72 / 92
diagramas de flujo de datos (DFD)
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
73 / 92
diagramas de flujo de datos (DFD)
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
74 / 92
diagramas de flujo de datos (DFD)
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
Confirmación_Pedido
Dirección_Factura
Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:
Sample Yourdon process modelc:\ecwin\samples\yddfd\dfd0.dfdProcess OrdersFeb-18-1993Wayne McDonaldDec-12-1993EasyCASE
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
75 / 92
diagramas de flujo de datos (DFD)
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
Confirmación_Pedido
Forma_Pago_Cliente
Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:
Sample Yourdon process modelc:\ecwin\samples\yddfd\dfd1.dfdTake OrderFeb-23-1993Wayne McDonaldDec-12-1993EasyCASE
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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””
diagramas de flujo de datos (DFD)
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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 |’ | - | |
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
78 / 92
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.
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
79 / 92
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:
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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)
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
82 / 92
diagrama entidad-relación
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
83 / 92
diagrama entidad-relación
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
84 / 92
diagrama entidad-relación
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
85 / 92
diagrama entidad-relación
Puedeimpartir
CURSO
PROFESOR
Haasistido
reservaESTUDIANTE
CLIENTE
CURSOPÚBLICO
PLANIFICADO
Puedeimpartir CURSOPROFESOR
pilota VUELOPILOTO
AVIÓN
asignado
ejemplos de relaciones entre entidades
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
86 / 92
diagrama entidad-relación
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
87 / 92
diagrama entidad-relación
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
88 / 92
diagrama entidad-relación
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”
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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
escuela superior de ingeniería informáticaingeniería del software de gestión
© enrique barreiro alonsouniversidade de vigo - departamento de informática
tema 3 – análisis de sistemas
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