Ingeniería del Software de Gestión. Tema 3

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

introducción al análisis tema 3 – análisis de sistemas ingeniería de requisitos los casos de uso son una buena herramienta para capturar requisitos, pero siempre quedan aspectos sin resolver o que son de especial complejidad y hay que estudiar posteriormente: deben mantenerse lo más independientes posibles unos de otros, obviando detalles relativos a interacciones, concurrencia, recursos compartidos,... ejemplo: Ingresar Dinero y Retirar Dinero son dos casos de uso que acceden a la misma cuenta y por tanto están relacionados deben escribirse utilizando el lenguaje del cliente: al usarse lenguaje natural se pierde poder expresivo y en la captura de requisitos pueden quedar sin describir adecuadamente detalles que requieren notaciones más formales escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 92

introducción al análisis tema 3 – análisis de sistemas análisis objetivo: conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y ayude a estructurar todo el sistema, incluyendo su Ingeniería de arquitectura requerimientos diversos enfoques Modelo de casos estructurado de uso prototipado :Modelo orientado a objetos Análisis se analizan los requisitos descritos durante la ingeniería de requisitos: Modelo de análisis analizándolos con mayor profundidad: se :Modelo puede razonar más sobre los aspectos internos del sistema, resolviendo cuestiones sobre interacciones de casos de uso, recursos Diseño compartidos,... utilizando el lenguaje de los desarrolladores, lo que permite indicar detalles no Modelo de especificados antes (refinar los requisitos) diseño :Modelo se pueden estructurar los requisitos para facilitar su comprensión, preparación, modificación y mantenimiento escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 3 / 92

introducción al análisis tema 3 – análisis de sistemas Comparación del modelo de casos de uso con el modelo de análisis Modelo de casos de uso Modelo de análisis Descrito con el lenguaje del cliente Descrito con el lenguaje del desarrollador Vista externa del sistema Vista interna del sistema Estructurado por los casos de uso Estructurado por clases y paquetes Utilizado fundamentalmente como contrato entre Utilizado fundamentalmente por los el cliente y los desarrolladores sobre qué debería desarrolladores para comprender cómo debería y qué no debería hacer el sistema darse forma al sistema, es decir, cómo debería ser diseñado e implementado Puede contener redundancias, inconsistencias,... No debe contener redundancias, entre los requisitos inconsistencias,... entre los requisitos Captura la funcionalidad del sistema, incluida la Esboza cómo llevar a cabo la funcionalidad dentro funcionalidad significativa para la arquitectura del sistema, incluida la funcionalidad significativa para la arquitectura; sirve como una primera aproximación al diseño Define casos de uso que se analizarán con más Define realizaciones de casos de uso y cada una profundidad en el modelo de análisis de ellas representa el análisis de un caso de uso del modelo de casos de uso escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 4 / 92

introducción al análisis tema 3 – análisis de sistemas requerimientos cambiantes habitual en grandes sistemas razones muchos usuarios (contradicciones, conflictos de intereses,...) los que pagan el sistema y los usuarios no suelen ser la misma persona, por lo que pueden tener requerimientos en conflicto el entorno de negocios y técnico cambia: nuevo hardware, nuevos sistemas, cambios en las prioridades del negocio, cambios legislativos,... administración de requerimientos proceso de comprender y controlar los cambios en los requerimientos del sistema requerimientos duraderos: aquellos relativamente estables, derivados de la actividad principal de la organización, y relacionados directamente con el dominio del sistema. Por ejemplo, en un hospital siempre habrá requerimientos referidos a pacientes, doctores, enfermeros, medicinas,... requerimientos volátiles: cambian probablemente durante el desarrollo del sistema o después de que se haya puesto en explotación. Por ejemplo, cambios en las normativas de salud. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 5 / 92

introducción al análisis tema 3 – análisis de sistemas planificación de la administración de requerimientos identificación de requerimientos proceso de administración del cambio análisis del problema y especificación del cambio análisis del cambio y evaluación económica implementación del cambio políticas de rastreo: definen la relación entre requerimientos y la de éstos y el diseño del sistema información de rastreo de la fuente: identificación de quién propone el cambio y la razón información de rastreo de los requerimientos: vincula los requerimientos dependientes en el RAD. Es necesario para comprobar cómo se ven afectados otros requerimientos por el cambio propuesto y la magnitud de este impacto. información de rastreo del diseño: vincula los requerimientos a los componentes de diseño (clases, métodos, módulos,...) en que serán implementados. Necesario para evaluar cómo se ve afectado el diseño y la implementación por el cambio propuesto. ayuda de herramientas CASE escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 6 / 92

el análisis en el proceso unificado tema 3 – análisis de sistemas actividades del análisis en el proceso unificado crear el Modelo de Dominio refinar el Modelo de Casos de Uso refinar la Especificación Complementaria refinar el Glosario se llevan a cabo a lo largo de varias iteraciones en la fase de elaboración escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 7 / 92

modelo del dominio tema 3 – análisis de sistemas artefacto de UML: modelo del dominio (o modelo conceptual) muestra clases conceptuales significativas en un dominio del problema, es decir, en el mundo real no muestra componentes software, clases software u objetos software con responsabilidades es el artefacto más importante en un análisis orientado a objetos (AOO) UML utiliza diagramas de clases para representar el modelo del dominio, que muestran: objetos del dominio o clases conceptuales asociaciones entre las clases conceptuales atributos de las clases conceptuales principal tarea del AOO: identificar diferentes conceptos en el dominio del problema y documentar el resultado en un modelo del dominio ejemplo: en el dominio de ventas pueden identificarse clases conceptuales como Tienda, Registro o Venta. el modelo del dominio se construye incrementalmente a lo largo de varias iteraciones en la fase de elaboración escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 8 / 92

modelo del dominio tema 3 – análisis de sistemas Modelo del dominio: ejemplo de un Diagrama de Clases concepto u Registra-venta-de LineaDeVenta Artículo objeto del cantidad dominio 0..1 1 * 1..n asociación Contenida-en Almacenado-en 1 Tienda 1 atributos dirección Venta tienda fecha hora 1 1 1 Capturada-en Alberga 1 Pagada-mediante 1.. * Registro 1 Pago cantidad escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 9 / 92

modelo del dominio tema 3 – análisis de sistemas pasos en la realización de un modelo del dominio 1. 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 atributos excluir las características irrelevantes no añadir cosas que no se encuentran en el dominio del problema que se está estudiando escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 10 / 92

modelo del dominio tema 3 – análisis de sistemas Los modelos del dominio no son modelos de Los modelos del dominio no son modelos de componentes software. componentes software. Elementos que no son adecuados en un modelo del Elementos que no son adecuados en un modelo del dominio: Venta dominio: • Artefactos software: ventanas, bases de datos,... fecha • Artefactos software: ventanas, bases de datos,... • Responsabilidades o métodos • Responsabilidades o métodos hora imprimir() BaseDeDatosVentas Son artefactos software o clases s oftware, por lo que no forman parte del m odelo del do m ini o Componente Acti veX escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 11 / 92

modelo del dominio tema 3 – análisis de sistemas clases conceptuales informalmente: una clase conceptual es una idea, cosa u objeto formalmente puede considerarse en términos de: símbolo: palabras o imágenes que representan una clase conceptual definición de la clase extensión: conjunto de ejemplos a los que se aplica la clase símbolo del concepto Venta fecha hora venta-3 venta-1 venta-4 definición del concepto venta-2 Una venta representa el hechoventa representa el Una de una transición de compra.una transición hecho de Sucede un día ycompra. Sucede un de a una hora. día y a una hora. extensión del concepto escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 12 / 92

modelo del dominio tema 3 – análisis de sistemas identificación de clases conceptuales para cada escenario se identifican las clases conceptuales relacionadas con él Identificar clases mejor especificar en exceso un modelo c oncept uales candidat as del dominio con muchas clases conceptuales “de grano fino” que especificar por defecto Representar las clases en estrategias complementarias para un modelo del dominio identificar clases conceptuales utilización de una lista de categorías de clases conceptuales identificación de frases nominales Añadir las asociac iones necesarias Añadir los atributos necesarios escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 13 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas identificación de clases conceptuales mediante una lista de categorías se utiliza una lista de categorías habituales que normalmente merece la pena tener en cuenta Categoría de clase conceptual Ejemplos objetos tangibles o físicos Registro Avión especificaciones, diseños o descripciones EspecificacionDelProducto de las cosas DescripcionDelVuelo lugares Tienda transacciones Venta, Pago Reserva líneas de la transacción LineaDeVenta roles de la gente Cajero Piloto contenedores de otras cosas Tienda, Almacén Avión cosas en un contenedor Artículo Pasajero otros sistemas informáticos o SistemaAutorizaciónPagoCrédito electromecánicos externos al sistema ControlDeTraficoAereo ... ... escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 14 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas 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ática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 15 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas Escenario principal de éxito (o flujo básico) de Procesar Venta. 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 comprar 1. El Cliente llega al terminal PDV con mercancías y/o servicios que comprar 2. El Cajero inicia una nueva venta 2. El Cajero inicia una nueva venta 3. El Cajero introduce el identificador del artículo 3. El Cajero introduce el identificador del artículo 4. El Sistema registra la línea de venta y presenta la descripción del artículo, 4. El Sistema registra la línea de venta y presenta la descripción del artículo, precio y suma parcial. El precio se calcula a partir de un conjunto de reglas precio y suma parcial. El precio se calcula a partir de un conjunto de reglas de precios. de precios. El Cajero repite los pasos 3-4 hasta que se indique El Cajero repite los pasos 3-4 hasta que se indique 5. El Sistema muestra el total con los impuestos calculados 5. El Sistema muestra el total con los impuestos calculados 6. El Cajero le dice al Cliente el total, y solicita el pago 6. El Cajero le dice al Cliente el total, y solicita el pago 7. El Cliente paga y el Sistema gestiona el pago 7. El Cliente paga y el Sistema gestiona el pago 8. El Sistema registra la venta completa y envía la información de la venta y el 8. 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 pago al sistema de Contabilidad externo (para la contabilidad y las comisiones) y al sistema de Inventario (para actualizar el inventario). comisiones) y al sistema de Inventario (para actualizar el inventario). 9. El sistema presenta el recibo 9. El sistema presenta el recibo 10. El Cliente se va con el recibo y las mercancías 10. El Cliente se va con el recibo y las mercancías Extensiones (o flujos alternativos) Extensiones (o flujos alternativos) ... ... 7a. Pago en efectivo: 7a. Pago en efectivo: 1. El Cajero introduce la cantidad de dinero entregada en efectivo. 1. El Cajero introduce la cantidad de dinero entregada en efectivo. 2. El sistema muestra la cantidad de dinero aa devolver y abre el cajón de 2. El sistema muestra la cantidad de dinero devolver y abre el cajón de caja. caja. 3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente 3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente 4. El Sistema registra el pago en efectivo 4. El Sistema registra el pago en efectivo escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 16 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas no se menciona de forma explícita, pero en la no se menciona de forma explícita, pero en la descripción se habla de “información enviada conocimiento descripción se habla de “información enviada conocimiento por el OficialCampo”. del dominio por el OficialCampo”. informar del dominio Al hablar con el cliente se descubre que a esta Al hablar con el cliente se descubre que a esta emergencia información se la conoce como informe de información se la conoce como informe de emergencia, por lo que se le da ese nombre a la emergencia, por lo que se le da ese nombre a la clase correspondiente clase correspondiente Ubicación Descripción del caso de uso Ubicación Descripción deldel caso de usouso Descripción Ubicación caso de Estación 1. El OficialCampo activa la función Informar Ubicación OficialCampo DescripciónOficialCampo activa la función Informar Emergencia en su PDA. uso El del caso de 1. Emergencia en su PDA. 1. El OficialCampo activa la función Informar 2. El sistema COMUNICA responde presentando un formulario alCOMUNICA responde presentando un su PDA. la función Informar 1. El OficialCampo activa 2. El sistema OficialCampo. El formulario incluye Emergencia en Estación un menú de al OficialCampo. El formulario incluye formulario tipos de emergencia (incendio, accidente, de tipos de emergencia para introducir en su PDA. Emergencia un menú disturbios,...) y campos (incendio, OficialCampo accidente, disturbios,...)del incidente, petición de y campos para introducir la ubicación, descripción El sistema COMUNICA responde presentando la 2. ubicación, descripción del incidente, petición de recursos,... 2. unEl sistema COMUNICA responde presentando formulario al OficialCampo. El formulario recursos,... un formulario al OficialCampo. El formulario 3. El OficialCampo cubre el formulario, y puede El OficialCampo cubre el formulario, a la menú de tipos de emergencia incluye un InformeDeEmergencia 3. también describir respuestas posibles y puede Controlador también describir respuestas posibles a la (incendio, un menú de tipos de emergencia incluye accidente, disturbios,...) y campos situación de emergencia y solicitar recursos específicos. Una vez que hasolicitar recursos situación de emergencia y llenado el formulario, elespecíficos. Una vez que ha(incendio, accidente, disturbios,...) y campos OficialCampo lo envía oprimiendo elel formulario, ubicación, descripción del para introducir la llenado botón “Enviar Informe” ylo envíaincidente,notifica al la ubicación, descripción del el OficialCampo en ese momento seel botón oprimiendo le para introducir “Enviar Informe” y en ese momento se le petición de recursos,... notifica al Controlador incidente, petición de recursos,... Controlador 4. Al Controlador se le notifica un nuevo informe de Estación incidente mediante le notifica un nuevo informe de cubre el formulario, y puede Al 3. Controlador se un cuadro OficialCampo El de diálogo 4. Controlador desplegable. El Controlador revisa diálogo incidente mediante un cuadro de la información 3. El OficialCampo cubre el formulario, y puede también describir respuestas posibles a la recibida y crea El Controlador revisa la información desplegable. un Incidente en la base de datos llamando alcrea un Incidente también datos situaciónde describir respuestas posibles a la en la base de emergencia y solicitar recursos recibida y caso de uso AbrirIncidente. Toda la información contenidauso específicos.de emergencia y llenado el llamando al caso de en el formulario delToda la AbrirIncidente. información se incluye automáticamente en Una vez que ha solicitar recursos situación OficialCampocontenida en el formulario del el OficialCampo Incidente OficialCampo se incluye automáticamente en el Una vez que ha llenado el específicos. formulario, el OficialCampo lo envía oprimiendo Incidente. El Controlador selecciona una respuesta Incidente. El Controlador selecciona una respuesta asignando recursos al incidente (con el caso de uso AsignarRecursos) yincidente (con el“Enviar OficialCampo lo envía oprimiendo el formulario, al Informe” y en ese momento se botón caso el asignando recursos al da un acuse de recibode uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando botónal Controlador informe de emergencia le el notifica “Enviar Informe” y en ese momento se un mensaje breve al OficialCampo. enviando un mensaje le notifica al Controlador breve al OficialCampo. Estación 5. El OficialCampo recibe el acuse de recibo y la respuesta seleccionada. el acuse de recibo y la se le notifica un nuevo informe El 4. OficialCampo recibe Al Controlador 5. OficialCampo respuesta seleccionada. 4. deAl Controlador se le notifica un de diálogo incidente mediante un cuadro nuevo informe Estación desplegable. Elmediante un cuadro la diálogo de incidente Controlador revisa de Controlador desplegable. El Controlador revisa la información recibida y crea un Incidente en la base de datos recibida y al caso de uso información llamando crea un Incidente en la descripción de los objetos y clases AbrirIncidente. Toda la informaciónde uso base de datos llamando al caso contenida enAbrirIncidente. Toda la informaciónincluye el formulario del OficialCampo se contenida automáticamente en el Incidente. El se incluye en el formulario del OficialCampo Controlador selecciona una respuesta Incidente. El Controlador automáticamente en el asignando recursos al inicialmente, breve incidente (conunacaso de uso AsignarRecursos) al selecciona el respuesta asignando recursos y da un acuse deel caso al informe de incidente (con recibo de uso AsignarRecursos) y da un acuse de recibo al informe de emergencia enviando un mensaje breve al documentación de atributos y OficialCampo. enviando un mensaje breve al emergencia OficialCampo. responsabilidades únicamente si son Estación 5. El OficialCampo recibe el acuse de recibo y la OficialCampo 5. respuesta seleccionada. el acuse de recibo y la El OficialCampo recibe obvios respuesta seleccionada. una vez que el modelo es estable, la descripción de cada clase será tan detallada como sea posible entrevistas con cliente y usuarios escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 17 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas lista de clases conceptuales candidatas del dominio generada a partir de lista de categorías análisis de lenguaje natural (frases nominales) restringida a los requisitos que se están estudiando actualmente ejemplo: lista de clases candidatas del caso de uso Procesar Venta. Registro EspecificaciónDelProducto Artículo LíneadeVenta Tienda Cajero Venta Cliente Pago Encargado CatálogoDeProductos ... 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? escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 18 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas error habitual al identificar clases candidatas: considerar como un atributo algo que debería ser un concepto en caso de duda, debe considerarse un concepto separado, puesto que los atributos no deben ser muy habituales en un modelo del dominio NO SI Tienda Venta Venta dirección tienda teléfono En el mundo real, una tienda o un aeropuerto no real, una tienda o un En el mundo se consideran un número o un no se consideran un aeropuerto texto. Estos términos sugieren una entidadEstos términos número o un texto. legal, una organización, yentidad legal, una sugieren una algo que ocupa organización, y algo que ocupa espacio. Por tanto, deben ser un espacio. Por tanto, deben ser un concepto. concepto. Aeropuerto Vuelo Vuelo nombre destino escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 19 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas Si se consumen todos los ObjetoOrdenador,todos los Si se consumen desaparecerá del ObjetoOrdenador : Artículo sistema también su desaparecerá del ObjetoOrdenador, precio, porque Artículo artículoID se encontraba como atributo porque sistema también su precio, en las ObjetoOrdenador : instancias que se eliminaron en las se encontraba como atributo numeroSerie Artículo instancias que se eliminaron cuando se vendieron. descripción ObjetoOrdenador : cuando se vendieron. precio Artículo clases conceptuales de especificación o descripción se utilizan para especificar o describir otras clases una clase EspecificaciónDelArtículo no representa un Artículo, sino una descripción de la información sobre los artículos: aunque se vendan todos los elementos inventariados, eliminándose las correspondientes instancias software de Artículo, permanecerá la EspecificaciónDelArtículo habituales en entornos de gestión (sistemas de compras, ventas, inventarios,...) y fabricación (descripciones de los productos fabricados) se usan cuando: se necesita la descripción de un artículo o servicio independientemente de la existencia actual de algún item de esos artículos o servicios la eliminación de instancias de las cosas que describen provocan pérdida de información que necesitaría mantenerse reduce información redundante o duplicada escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 20 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas NO SI Artículo EspecificaciónDelProducto artículoID desc ribe Artículo numeroSerie descripción precio numeroSerie descripción 1 n artículoID precio Vuelo Vuelo descrit o por DescripcionVuelo fecha fecha numero numero hora 1 n hora n n describe vuelos a vuela a 1 1 Aeropuerto Aeropuerto nombre nombre escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 21 / 92

modelo del dominio: identificación de clases tema 3 – análisis de sistemas reducción del salto en la representación (salto Modelo del Dominio semántico): Vista del personal involucrado de los conceptos más relevantes del dominio una de las grandes ventajas Visualiza los modelos del mundo real. de la tecnología de objetos Venta Pagada-median te Pago reducción de la diferencia fecha cantidad entre el modo en el que el hora 1 1 personal involucrado concibe el dominio y su representación en el software inspira objetos y nombres en el ejemplo: modelo de diseño un pago en el Modelo del Dominio es una clase conceptual (un concepto) Venta un pago en el Modelo de Pago pagada mediant e fecha : Date Diseño es una clase software cantidad : Dinero hora : Tiempo no son lo mismo, pero el 1 1 getDevolucion() : Dinero primero “inspiró” el nombre getTotal() : Dinero y definición del segundo Modelo del Diseño El desarrollador orientado a objetos se ha inspirado en el dominio del mundo real al crear las clases software. Visualiza los componentes software escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 22 / 92

modelo del dominio: representar las clases tema 3 – análisis de sistemas representar las clases en un modelo del dominio se utiliza la notación de clase de UML Identificar clases c oncept uales candidat as nombre clase Representar las clases en un modelo del dominio Persona lista de atributos nombre : Nombre idEmpleado : Integer Añadir las as ociac iones necesarias cargo : String obtenerFoto() obtenerInformaciónDeContacto() Añadir los atributos obtenerRegistrosPersonales() necesarios lista de operaciones (no se suelen reflejar en el modelo del dominio) escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 23 / 92

modelo del dominio: representar las clases tema 3 – análisis de sistemas Representación de las clases conceptuales del Sistema PDV Registro Artículo Tienda Venta LineaDeVenta Cajero Cliente Encargado CatalogoDe Especificacion Pago Productos DelProducto escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 24 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas asociación según UML, una asociación es “la relación semántica entre dos o más clasificadores que implica conexiones entre sus instancias” se registran las asociaciones: de las que es necesario conservar el conocimiento de la relación durante algún tiempo (por ejemplo, la relación entre LíneaPedido y Pedido) Identificar clases derivadas de la Lista de Asociaciones Comunes c oncept uales candidat as importante: registrar únicamente asociaciones útiles para mantener el diagrama legible es más importante dedicar tiempo a localizar las clases Representar las clases en conceptuales que a identificar las asociaciones un modelo del dominio Flecha de dirección de lectura. Normalmente nombre de la se excluye. asociación Añadir las as ociac iones necesarias Añadir los atributos Venta necesarios Pagada-median te Pago fecha cantidad hora 1 1 multipli cidad escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 25 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas lista de asociaciones comunes relación de categorías habituales que, normalmente, merece la pena tener en cuenta Categoría Ejemplos Categoría Ejemplos A es una parte física de Caja-Registro A es miembro de B Cajero-Tienda Ala-Avión B Piloto-CompañíaAerea A es una parte lógica de LineaDeVenta-Venta A utiliza o gestiona B Cajero-Registro EtapaVuelo-RutaVuelo Piloto-Avión B A se comunica con B Cliente-Cajero A está contenido Registro-Tienda, Artículo- AgenteReservas-Pasajero Estantería físicamente en B Pasajero-Avión A está relacionado con Cliente-Pago Pasajero-Billete una transacción B A está contenido DescripciónArtículo- Catálogo lógicamente en B A es una transacción Pago-Venta Vuelo-PlanificaciónVuelo Reserva-Cancelación relacionada con otra A se conoce/registra/ Venta-Registro transacción B Reserva-ListaPasajeros recoge/informa/captura en B A está al lado de B LíneaDeVenta- LíneaDeVenta A es una descripción de DescripciónDelArtículo- Ciudad-Ciudad Artículo B A es propiedad de B Registro-Tienda DescripciónDelVuelo-Vuelo Avión-CompañíaAerea A es una línea de una LíneaDeVenta-Venta A es un evento Venta-Cliente, Venta- TrabajoMantenimiento- transacción o importe Tienda RegistroDeMantenimiento relacionado con B de B Salida-Vuelo A es una subunidad Departamento-Tienda relaciones cuya inclusión relaciones cuya inclusión Mantenimiento- en el Modelo de Dominio organizativa de B en el Modelo de Dominio CompañíaAerea es especialmente útil es especialmente útil escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 26 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas Tienda nombre de las asociaciones 1 formato: NombreTipo – FraseVerbal – Alberga NombreTipo donde la frase verbal crea una secuencia legible y con 1..* significado en el contexto Captura Pagada-mediante del modelo Venta Pago Registro normalmente la dirección 1 1 1 1 por defecto para la lectura de los nombres de asociaciones es de Compañía izquierda a derecha o Aerea arriba abajo 1 Emplea 1..n Asignado-a Asignado-a Persona Vuelo Avión 1 n n 1 n 1 fuente: C. Larman, UML y patrones, Prentice Hall, 2002 Supervisa escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 27 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas PÓLIZAS PÓLIZAS escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 28 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas multiplicidad indica cuántas instancias de una clase A pueden asociarse con una instancia de una clase B en un momento concreto NO a lo largo de un periodo de tiempo indica una restricción de diseño que será (o podrá ser) reflejada en el software * Clase cero o más; muchos 1..* Clase uno o más 1..40 Clase de uno a 40 5 Clase exactamente 5 3,5,8 Clase exactamente 3, 5 u 8 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 29 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas multiplicidad puede existir cualquier tipo de multiplicidad, pero en la práctica la mayoría de las asociaciones pertenecen a uno de los siguientes tipos asociación de uno a uno: tiene una multiplicidad de 1 a cada extremo. Significa que existe solamente un vínculo entre OficialPolicía NúmeroIdentificación instancias de cada clase. Por ejemplo, 1 1 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 Asegurado Automó vil 1 1..* multiplicidad de 1 en un extremo y 0..n en el otro (a veces representado con un asterisco) +propietario +propiedad asociación de muchos a muchos: tiene una multiplicidad de 0..n o 1..n en ambos extremos. Indica que pueden existir una escribe Autor Libro cantidad arbitraria de vínculos entre instancias de las dos clases. Es el tipo más complejo de * * asociación. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 30 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas pueden existir dos o más asociaciones entre dos clases conceptuales Vuela-a n 1 Vuelo Aeropuerto n Vuela-desde 1 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 31 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas Categoría Ejemplos A es una parte física de B Registro-Caja A es una parte lógica de B LineaDeVenta-Venta A está contenido físicamente en B Registro-Tienda, Artículo-Tienda A está contenido lógicamente en B EspecificacionDelProducto-CatalogoDeProductos CatalogoDeProductos-Tienda A es una descripción de B EspecificacionDelProducto-Articulo A es una línea de una transacción o informe de B LíneaDeVenta-Venta A se conoce/registra/recoge/informa/captura en B (completa) Venta-Tienda (actual) Venta-Registro A es miembro de B Cajero-Tienda A es una subunidad organizativa de B No aplicable A utiliza o gestiona B Cajero-Registro Encargado-Registro Encargado-Cajero, aunque probablemente no es aplicable A se comunica con B Cliente-Cajero A está relacionado con una transacción B Cliente-Pago Cajero-Pago A es una transacción relacionada con otra Pago-Venta transacción B A está al lado de B LineaDeVenta-LineaDeVenta A es propiedad de B o informe de B Registro-Tienda escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 32 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas navegabilidad indica que es posible enviar mensajes en la dirección de la flecha en uno de los dos extremos de asociación no hay que especificarla hasta que el diagrama de clases sea estable está cursando Estudi ante Asignatura En este caso, la clase Asignatura conoce a la clase Estudiante, pero no al revés. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 33 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas asociaciones reflexivas +hijo Persona * 2 +padre Crea escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 34 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas agregación es un tipo de asociación que se utiliza para modelar las relaciones todo-parte entre las cosas. El todo se denomina compuesto normalmente se identifica en el Modelo de Diseño, pero puede ser útil o necesario identificar algunas relaciones de agregación en el Modelo del Dominio. representación en UML: un rombo hueco o relleno en el extremo del compuesto de una asociación todo-parte el nombre de la asociación se suele excluir porque se piensa normalmente como Tiene-parte 1 4 Coche Rueda 11 0..1 Radio 1 Motor escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 35 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas agregación de composición Coche la parte es un miembro de un único objeto compuesto y existe una dependencia de existencia y 1 disposición de la parte sobre el compuesto la multiplicidad en la parte del compuesto sólo puede ser 1 1 ejemplo: en una relación Coche – Motor, el motor tiene sentido como tal (existe) únicamente si está Motor asociado a un coche representación en UML: un rombo relleno agregación compartida DiagramaUML la multiplicidad en el extremo del compuesto puede ser más de uno: la parte puede estar simultáneamente en muchas instancias del * compuesto se utiliza para conceptos abstractos, no físicos representación en UML: un rombo hueco * ElementoUML escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 36 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas identificación de la agregación si hay duda, se descarta se debe mostrar una agregación: cuando el tiempo de vida de la parte está ligado al tiempo de vida del compuesto (existe una dependencia de creación – eliminación de la parte en el todo). cuando existe un ensamblaje obvio todo-parte físico o lógico cuando alguna propiedad del compuesto se propaga a las partes, como la ubicación cuando las operaciones que se aplican sobre el compuesto se propagan a las partes, como la destrucción, movimiento o grabación Venta LineaDeVenta 1 1..n CatalogoDeProductos EspecificacionDelProducto 1..n 1 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 37 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas generalización actividad de identificar elementos comunes entre los conceptos y definir las relaciones de superclase (concepto general) y PAGO subclase (concepto especializado). Así, los conceptos se representan en jerarquías de clases. Pago con cheque Pago en efectivo superclase conceptual: su definición es más general y abarca más que la definición de una subclase Pago a crédito 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 Un Pago representa la Un Pago representa la transacción de transferir Pago transacción de transferir dinero para una compra cantidad : Dinero dinero para una compra de una parte a otra. de una parte a otra. PagoACredito es una transferencia dees una PagoACredito dinero por medio de una dinero transferencia de por medio de una institución de crédito que autoriza la operación. que institución de crédito PagoACredito PagoEnEfectivo PagoConCheque autoriza la operación. Por tanto, Pago es una Por tanto, Pago es una definición más amplia y general quemás amplia y definición la de PagoACredito. de general que la fuente: C. Larman, UML y patrones, Prentice Hall, 2002 PagoACredito. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 38 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas 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 El diagrama indica que fecha El diagrama indica que todos los Pagos tienen hora todos los Pagos tienen una cantidad y que se asocian con una que se una cantidad y Venta asocian con una Venta 1 Pagada-mediante 1 Pago cantidad : Dinero PagoACredito PagoEnEfectivo PagoConCheque fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 39 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 40 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas cuando dividir una clase conceptual en subclases cuando la subclase tiene atributos adicionales de interés cuando la subclase tiene asociaciones adicionales de interés cuando el concepto de la subclase funciona, se maneja, reacciona o se manipula de manera diferente a la superclase o a otras subclases, de alguna manera que es interesante. cuando el concepto de la subclase representa una cosa animada (animal, maquinaria,...) que se comporta de manera diferente a la superclase o a otras subclases, de alguna manera que resulta interesante poner de manifiesto en el modelo del dominio. Motivación de la subclase conceptual Ejemplos La subclase tiene atributos adicionales de interés Pagos: no aplicable Biblioteca: Libro, subclase de RecursoPrestable, tiene un atributo ISBN La subclase tiene asociaciones adicionales de Pagos: PagoACredito, subclase de Pago, asociada con interés una TarjetaDeCredito Biblioteca: Vídeo, subclase de RecursoPrestable, asociada con un Encargado El concepto de la subclase funciona, se maneja, Pagos: PagoACredito, subclase de Pago, se gestiona de reacciona o se manipula de manera diferente a la manera diferente a otros tipos de pagos en el modo de superclase o a otras subclases, de alguna manera autorizarlo que es interesante Biblioteca: Software, subclase de RecursoPrestable, requiere un depósito antes de que pueda prestase El concepto de la subclase representa una cosa Pagos: no aplicable animada (personal, maquinaria, animal...) que se Biblioteca: no aplicable comporta de manera diferente a la superclase o a Investigación de Mercado: Hombre, subclase de otras subclases, de alguna manera que resulta Persona, se comporta de manera diferente a la Mujer interesante poner de manifiesto en el modelo del con respecto a los hábitos de compras dominio escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 41 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas cuando definir una superclase conceptual cuando las subclases potenciales representan variaciones de un concepto similar cuando las subclases se ajustarán a las reglas del 100% y la regla Es-Un-Tipo-De cuando todas las subclases tienen un mismo atributo que se puede expresar en la superclase cuando todas las subclases tienen la misma asociación que se puede unir y relacionar con la superclase jerarquías de clases y herencia en el software la herencia es un mecanismo software para hacer que las características de la superclase se apliquen a las subclases es un concepto que no se utiliza en el Modelo del Dominio, pero sí cuando se pasa al Modelo de Diseño y Modelo de Implementación las jerarquías de clases conceptuales del Modelo del Dominio pueden reflejarse o no en el Modelo de Diseño, dependiendo de las características del lenguaje y otras cuestiones escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 42 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas Sistema PDV: Clases de Pago superclase justificada por atributos comunes y asociaciones Venta 1 fecha Pagada-mediante Pago 1 hora cantidad : Dinero cada subclase de PagoEnEfectivo PagoACredito PagoConCheque Pago se maneja de manera diferente 1 1 Identifica-crédito-con Pagado-con 1 n TarjetaDeCredito Cheque asociaciones adicionales fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 43 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas Sistema PDV: Clases de ServicioAutorización Tienda Superclase justificada Autoriza-pagos-de por atributos comunes n ServicioAutorizac ión y asociaciones 1 ServicioAutorización ServicioAutorización Cheques Crédito n n Aut oriza Autoriza 1 1 PagoACrédito PagoConCheque Asociaciones adicionales fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 44 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas 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 Pago cantidad : Dinero PagoEnEfectivo PagoACredito PagoConCheque escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 45 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas clases asociación en un modelo del dominio, si una clase C puede tener simultáneamente muchos valores para el mismo tipo de atributo A, no se colocará este atributo en C, sino en otra clase asociada con C. ejemplo: una Persona puede tener muchos números de teléfono. Se colocará el número de teléfono en otra clase, como NúmeroTeléfono o InformaciónDeContacto, y se asocian muchas de estas clases a Persona. guía hay un atributo relacionado con una asociación el tiempo de vida de las instancias de la clase asociación depende de la asociación existe una asociación muchos- a-muchos entre dos conceptos, e información asociada con la propia asociación fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 46 / 92

modelo del dominio: asociaciones tema 3 – análisis de sistemas Emplea Empresa Persona * * Una persona podría Empleo tener empleos en varias empresas salario escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 47 / 92

modelo del dominio: atributos tema 3 – análisis de sistemas atributo es un valor de datos lógico de un objeto se incluyen aquellos atributos para los que los requisitos indican la necesidad de registrar su Identificar clases c oncept uales candidat as información ejemplo: un recibo recoge la información de una venta, incluyendo fecha y hora. La dirección Representar las clases en quiere conocer fecha y hora de las ventas. Por un modelo del dominio tanto, la clase Venta necesita los atributos fecha y hora notación UML: se muestran en el segundo Añadir las as ociac iones necesarias compartimento del rectángulo de la clase. Los tipos se muestran opcionalmente Añadir los atributos necesarios Venta atributos fecha horaIni cio : Hora escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 48 / 92

modelo del dominio: atributos tema 3 – análisis de sistemas tipos de atributos en el modelo de dominio deben usarse preferiblemente atributos simples: no deben ser conceptos de dominio complejos (Venta, Aeropuerto, ...) tipos de datos: principalmente booleano, fecha, número, string y hora otros: Dirección, Color, Teléfono, NIF, Código Postal,... importante: relacionar las clases conceptuales con una asociación, no con un atributo. En caso de duda, se debe optar por usar una clase conceptual antes que un atributo. durante el diseño y la implementación podrán aparecer nuevos atributos que referencian a otros objetos software complejos, pero que no tienen sentido en el Modelo de Dominio destino es un concepto Vuelo complejo es un concepto destino complejo destino Peor Vuela-a Vuelo Aeropuerto Mejor escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 49 / 92

modelo del dominio: atributos tema 3 – análisis de sistemas tipos de datos como clases un atributo que puede considerarse como un tipo de dato primitivo puede representarse como una clase si: está compuesto de secciones separadas (número de teléfono, nombre de persona,...) hay operaciones asociadas con él, como algoritmos de validación (NIF, número de la Seguridad Social,...) tiene otros atributos (el precio de una oferta puede tener una fecha de comienzo y otra de fin) es una cantidad con una unidad de medida (la cantidad de un pago tiene una unidad monetaria) es una abstracción de uno o más tipos con estas cualidades (un identificador de artículo en el dominio de ventas es una generalización de tipos como el Código de Producto Universal –UPC- o el Número de Artículo Europeo – EAN -) ejemplo: en el sistema de Punto de Venta las clases ArticuloID, Direccion y Cantidad son tipos de datos pero se pueden considerar como clases independiente debido a sus características representación: como clase independiente o en el compartimento de atributos de la clase, dependiendo de la utilización del modelo del dominio y la importancia de los conceptos en el dominio Especificación Tienda Dirección ArticuloID Correcto DelProducto 1 1 1 1 Tienda EspecificaciónDelProducto Correcto dirección : Dirección id : ArticuloID fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 50 / 92

modelo del dominio: atributos tema 3 – análisis de sistemas cantidades y unidades de los atributos la mayoría de las cantidades numéricas llevan unidades asociadas no deben representarse únicamente como números ejemplos: precio, velocidad, peso ... solución: representar la cantidad como una clase conceptual aparte con una unidad asociada no es útil no es útil Pago Incorrecto cantidad : Número Tiene-importe Est á-en Cantidad Unidad Pago Correcto cantidad : Número nombreMoneda n 1 n 1 variación: Dinero es una las cantidades son especialización de es una variación: Dinero Pago valores de datosson las cantidades simples, Pago especialización de es Cantidad cuya unidad cantidad : Dinero valores de datos simples, por lo que es adecuado Cantidad cuya unidad es cantidad : Cantidad una moneda representarlas adecuado por lo que es en la una moneda representarlas en la sección de atributos sección de atributos fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 51 / 92

modelo del dominio tema 3 – análisis de sistemas Registra-venta-de Descrita-por 1 n Especificacion 0..1 CatalogoDe DelProducto LineaDeVenta Contiene Product os descripción cantidad 1 1..n precio articuloID 1 1.. n Utilizado-por n Contenida-en Tienda Abastece Articulo direc ción Registra-completas nombre 1..n 1 n 1 1 1 Venta Alberga n 1..n fecha Iniciado-por hora Registro 1 1 Encargado 1 Capturada-en 1 1 1 1 Pagada-mediante Iniciada-por Registra-ventas-en 1 1 1 Pago Cliente cantidad Cajero fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 52 / 92

modelo del dominio: utilización de paquetes tema 3 – análisis de sistemas los modelos de dominio se pueden dividir en paquetes cuando han crecido demasiado los paquetes incluyen conceptos fuertemente relacionados mejora la comprensión permite realizar tareas de análisis en paralelo, de tal forma que diferentes equipos o personas analizan diferentes subdominios notación de paquetes en UML paquete: se representa por una carpeta pueden mostrarse dentro de un paquete otros paquetes subordinados un elemento pertenece al paquete donde está definido, pero puede ser referenciado en otros paquetes, utilizando el formato NombrePaquete::NombreElemento escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 53 / 92

modelo del dominio: utilización de paquetes tema 3 – análisis de sistemas Relación de dependencia: indica que de dependencia: Relación los elementos del paquete los elementos indica que dependiente del paquete dependiente Dominio (Ventas) conocen o están acoplados conocen o están (Ventas) de algún modo con los elementos delmodo acoplados de algún paquete elementos del con los destino paquete destino (Elementos Básicos). Elementos Básicos (Elementos Básicos). Ventas Una clase referenciada en un clase referenciada Una paquete en un paquete Ventas Elementos Básicos tiene Tienda Registro 1..* 1 fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 54 / 92

modelo del dominio: utilización de paquetes tema 3 – análisis de sistemas Dominio Productos Básico Pagos Ventas Transacciones de Autorización Productos fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 55 / 92

modelo del dominio: utilización de paquetes tema 3 – análisis de sistemas cómo dividir el Modelo del Dominio se deben poner juntos en paquetes los elementos que: se encuentran en el mismo área de interés (están estrechamente relacionados por conceptos u objetivos) están juntos en una jerarquía de clases participan en los mismos casos de uso están fuertemente asociados consejo utilizar un paquete Dominio que será el raíz de todos los elementos relacionados con el modelo del dominio utilizar un paquete Elementos Básicos, o Conceptos Comunes, para englobar todos los elementos compartidos, comunes a otros elementos, básicos,... escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 56 / 92

modelo de casos de uso: contratos de las operaciones tema 3 – análisis de sistemas 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ática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 57 / 92

modelo de casos de uso: contratos de las operaciones tema 3 – análisis de sistemas : Sistema : Cajero crearNuevaVenta() introducirArticulo(artID, cantidad) descripción, total *[más artículos] Estos eventos de entrada del sistema invocaneventos de entrada del sistema Estos operaciones del sistema. invocan operaciones del sistema. El evento del sistema crearNuevaVenta finalizarVenta() invoca una del sistema crearNuevaVenta El evento operación del sistema denominada operación del sistema invoca una crearNuevaVenta y así denominada crearNuevaVenta y así total con impuestos sucesivamente. sucesivamente. Es similar a cuando en la programación realizarPago(cantidad) orientada a a cuando en la programación Es similar objetos un mensaje xyz invoca el método xyz. mensaje xyz orientada a objetos un invoca el método xyz. cambio devuelto, recibo fuente: C. Larman, UML y patrones, Prentice Hall, 2002 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 58 / 92

modelo de casos de uso: contratos de las operaciones tema 3 – análisis de sistemas secciones del contrato Operación Nombre de la operación y parámetros Referencias cruzadas (opcional) Casos de uso en los que pueden tener lugar esta operación Precondiciones 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 el lector Postcondiciones 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. escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 59 / 92

modelo de casos de uso: contratos de las operaciones tema 3 – análisis de sistemas escritura de contratos sólo deben hacerse en algunas operaciones: son útiles cuando los detalles y complejidad de los cambios de estado requeridos son difíciles de capturar en los casos de uso (pueden dar lugar a un caso de uso excesivamente detallado) guía para hacer contratos 1. identificar las operaciones del sistema a partir de los DSS 2. construir un contrato para las operaciones 3. para describir las postcondiciones utilizar las siguientes categorías creación y eliminación de instancias modificación de atributos formación y rotura de asociaciones escribir en pasado: se creó una LineaDeVenta IMPORTANTE: reflejar el establecimiento de relaciones entre objetos: La LineaDeVenta se asoció con la Venta escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 60 / 92

modelo de casos de uso: contratos de las operaciones tema 3 – análisis de sistemas Operación introducirArtículo(articuloID:ArticuloID, cantidad:integer) Referencias cruzadas Caso de uso: Procesar Venta Precondiciones Hay una venta en curso Postcondiciones -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) escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 61 / 92

modelo de casos de uso: contratos de las operaciones tema 3 – análisis de sistemas Operación realizarPago(cantidad:Dinero) Referencias cruzadas Caso de Uso: Procesar Venta Precondiciones Hay una venta en curso Postcondiciones -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) escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 62 / 92

modelado de comportamiento no trivial tema 3 – análisis de sistemas diagramas de estado representan el comportamiento del sistema desde la perspectiva de un solo objeto, mostrando la dependencia entre el estado de un objeto y su reacción ante los mensajes u otros eventos permiten identificación de nuevos casos de uso construir una descripción formal del comportamiento del objeto sólo se construyen diagramas de estado de los objetos que tienen una vida extendida y un comportamiento no trivial pueden existir diagramas anidados de nivel más bajo que modelan las transiciones de estado de forma más detallada. En el ejemplo, podría haber un diagrama de nivel más bajo que modelara los cambios de estado de Incidente mientras está Activo Incidente númeroInforme : Integer tipoEmergencia : (incendio, tráfico, otro) ubicación : String descripción : String Activo Archivado cantRecursosAsignados : Integer fecha : Date cantRecursosAsignados == 0 cuando incidente.fecha > 1 año se envían todos los informes Inactivo Cerrado fuente: Ingeniería del Software Orientado a Objetos, B.Bruegge, A.H. Dutoit, p. 153 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 63 / 92

modelado de comportamiento no trivial tema 3 – análisis de sistemas componentes del diagrama de estados estado: lo constituyen todos los datos que encapsula un objeto en un momento determinado, y se representa como una caja con esquinas redondeadas transición: mediante flechas se representa el cambio de un estado a otro evento: provocan las transiciones entre estados, y normalmente se trata de la recepción de un mensaje por parte del objeto. Se representa escribiendo el mensaje en la flecha de transición marca de creación: un punto negro indica el estado inicial del objeto marca de destrucción: un punto negro rodeado por un anillo significa que el objeto ha alcanzado el final de su vida y será destruido acción: representa un mensaje que envía el objeto como respuesta a uno recibido, es decir, una acción como respuesta a un evento t omarPrestado() en la estant ería en préstamo entry/ libro.prestado(self) entry/ libro.devuelto(self) devolver() escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 64 / 92

modelado de comportamiento no trivial tema 3 – análisis de sistemas Climatizador evento inicio final apagar demasiadoCaliente ( te m pDeseada ) inactivo demasiadoFrío( tempDeseada ) estado t empAlcanzada tempAlcanzada calentando demasiadoFrío( tempDeseada ) transición enfriando demasiadoCaliente( tempDeseada ) inicio encender( ) preparado en activo preparación escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 65 / 92

tarjetas CRC tema 3 – análisis de sistemas tarjetas CRC (Clase, Responsabilidades y Colaboraciones) SocioBiblioteca no forman parte de UML pero aportan Responsabilidades Colaboradores una gran utilidad Mantener los datos sobre las copias identificación de clases y asociaciones prestadas actualmente Copia identificación de navegabilidad de las Atender peticiones para tomar asociaciones prestados y devolver copias localización temprana de posibles problemas de cohesión y acoplamiento Copia una tarjeta CRC consta de Responsabilidades Colaboradores nombre de la clase Mantener los datos sobre una copia responsabilidades de la clase determinada de un libro. Libro describen a alto nivel el propósito de la Informar del correspondiente Libro existencia de la clase cuando es prestado y devuelto. normalmente una clase no debe tener más de tres o cuatro responsabilidades. Si tiene más, habría que plantearse describirla de forma más concisa o Libro dividirla la clase porque su cohesión es baja Responsabilidades Colaboradores colaboradores de la clase Mantener los datos sobre un libro. ayudan a ejecutar cada responsabilidad Copia Saber si hay copias disponibles para si hay demasiados es que existe un tomar prestadas. excesivo acoplamiento escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 66 / 92

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

ejercicio Diagrama de Clases tema 3 – análisis de sistemas 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ática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 68 / 92

análisis estructurado tema 3 – análisis de sistemas ANÁLISIS ESTRUCTURADO ANÁLISIS ESTRUCTURADO DISEÑO ESTRUCTURADO (De Marco, Gane y Sarson, Page-Jones, DISEÑO ESTRUCTURADO (De Marco, Gane y Sarson, Page-Jones, (Constantine, Yourdon,...) Ward y Mellor, Yourdon,...) (Constantine, Yourdon,...) Ward y Mellor, Yourdon,...) Mediados 70’s Finales 70’s Mediados 70’s Finales 70’s MODELADO DE DATOS MODELADO DE DATOS Es MODELADO FUNCIONAL pe es MODELADO FUNCIONAL ad cif ica tid en ci de ón ón de ci pr rip oc Diagrama sc es Diagrama De os Entidad- de Flujo de Relación Datos DICCIONARIO DE DATOS Diagrama de Transición de Estados Especificación de control MODELADO DE COMPORTAMIENTO MODELADO DE COMPORTAMIENTO escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 69 / 92

diagramas de flujo de datos (DFD) tema 3 – análisis de sistemas FLUJOS DE DATOS Representan datos en movimiento PROCESOS mediante flechas Convenciones: Muestran una parte del sistema que transforma • No hay datos distintos con el mismo nombre datos de entrada en datos de salida • Representan conocimiento • No hay nombres en la entrada y salida de Se describen con una sola frase sencilla: verbo- almacenamientos objeto • No representan flujos de control 1 2 datoA datoB ENTIDAD PROCESO 1 PROCESO 2 EXTERNA datoC Almacenamiento de datos ENTIDADES EXTERNAS Muestran origen y destino de los datos ALMACENAMIENTO DE DATOS Persona, organización o sistema que permanece fuera del contexto del sistema Representa un conjunto de datos en Proporcionan información sobre la conexión del reposo. sistema con el mundo exterior Representa archivos, bases de datos,... Debe tener entradas y salidas escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 70 / 92

diagramas de flujo de datos (DFD) tema 3 – análisis de sistemas Reglas generales de elaboración de los DFDs Escoger nombres con significado: saldo_cliente, Imprimir Nómina, ... Numerar los procesos Evitar DFDs excesivamente complejos Asegurar la consistencia de los DFDs: Procesos sin entradas o sin salidas Flujos y procesos no etiquetados Almacenamientos sólo de lectura o escritura Utilización de herramientas CASE No mostrar flujo o información de control escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 71 / 92

diagramas de flujo de datos (DFD) tema 3 – análisis de sistemas Los DFDs por niveles Subdivisión cuando el sistema es demasiado grande: cada proceso se despliega en otro DFD formado por distintos procesos. Diagrama de contexto: delimitación del dominio del sistema Nivel inferior: primitivas funcionales (procesos que no se despliegan en DFDs) Convenciones de los DFDs por niveles Equilibrado y descomposición paralela de datos y funciones Convenciones numéricas: Diagrama de contexto: el proceso se numera con un 0 Diagrama de nivel 0: los procesos se numeran 1, 2, 3, ... Otros diagramas: numeración de 1 en adelante precedido por el número del proceso padre (por ejemplo, el DFD 1 es el hijo del proceso 1 y sus procesos se numeran 1.1, 1.2, 1.3, ... Almacenamientos locales: un almacenamiento se muestra en un DFD en el primer nivel donde se usa como interface entre dos procesos Fuente y destino de los datos Límite aconsejado de la división: 7 procesos Primitivas funcionales escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 72 / 92

diagramas de flujo de datos (DFD) tema 3 – análisis de sistemas Pedido Cliente Pedido_Proveedor Pago_Cliente Devolución_Cliente CLIENTE PROVEEDOR Confirmación_Pedido Pago_Proveedor Envío_Cliente Producto_Stock 0 Sistema Devolución_Cliente de Factura_Cliente Pedidos de Factura_Proveedor Inventario Políticas_Ventas_ y_Cuotas Petición_Comprobación_Crédito Detalles_Crédito ENTIDAD Informe_Ventas DIRECCIÓN TARJETA CRÉDITO Project Name: Sample Yourdon process model Project Path: c:\\ecwin\\samples\\yddfd\\ Chart File: context.dfd Chart Name: Sales Order Processing Created On: Feb-16-1993 Created By: Wayne McDonald Modified On: Dec-12-1993 escuela superior de ingeniería informática © enrique barreiro alonso Modified By: EasyCASE universidade de vigo - departamento de informática ingeniería del software de gestión 73 / 92

diagramas de flujo de datos (DFD) tema 3 – análisis de sistemas Factura_Proveedor Confirmación_Pedido Producto_Stock Pago_Cliente Petición_Comprobación_Crédito Pedido Cliente 1 3 Pedido_Proveedor RECIBIR GESTIONAR Detalles_Crédito Stock PEDIDO STOCK Pago_Proveedor Cliente Dirección_Envío Clientes Producto_Devuelto Detalles_Pedido 2 Factura_Cliente ENVIAR PEDIDO Envío_Cliente Detalles_Pedido Productos Devueltos Número_Empleado Producto_Devuelto Dirección_Factura Cliente Representante Ventas 4 RECIBIR Reintegro_Cliente DEVOLUCIONES Nombre_Empleado_y_Supervisor 5 Project Name: Sample Yourdon process model GENERAR Project Path: c:\\ecwin\\samples\\yddfd\\ Políticas_Ventas_ Informe_Ventas INFORMES Chart File: dfd0.dfd y_Cuotas Devolución_Cliente VENTAS Chart Name: Process Orders Created On: Feb-18-1993 Created By: Wayne McDonald Modified On: Dec-12-1993 Modified By: EasyCASE escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 74 / 92

diagramas de flujo de datos (DFD) tema 3 – análisis de sistemas Detalles_Crédito Pago_Cliente 1.4 Petición_Comprobación_Crédito CONFIRMAR Cliente Clientes Forma_Pago_Cliente CRÉDITO 1.1 OBTENER Info_Cliente Info_Pedido INFORMACIÓN Crédito_OK CLIENTE Detalles Pedido Número_Empleado 1.5 Item_Línea_Pedido Confirmación_Pedido CONFIRMAR Número_Pedido PEDIDO Item_Línea_Pedido Representante Ventas Estado_Item_Pedido 1.3 Item_Línea_Pedido Project Name: Sample Yourdon process model COMPROBAR Project Path: c:\\ecwin\\samples\\yddfd\\ STOCK Chart File: dfd1.dfd 1.2 Chart Name: Take Order Items_Pedido_Cliente OBTENER Item_Línea_Pedido Created On: Feb-23-1993 ITEMS Created By: Wayne McDonald PEDIDO Modified On: Dec-12-1993 Modified By: EasyCASE Stock escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 75 / 92

diagramas de flujo de datos (DFD) tema 3 – análisis de sistemas Miniespecificación: PROCESO Producir instrucciones de asistencia Descripción precisa de lo que hace una primitiva funcional FLUJOS DE DATOS (INPUTS) Debe ser rigurosa y comprensible para el lector (analista, usuario y diseñador) FLUJOS DE DATOS (OUTPUTS) instrucciones de asistencia La definición del comportamiento real del sistema está en las miniespecs. Los DFDs representan la organización y el “mapa”. INPUTS DE DATOS ALMACENADOS Componentes de la miniespecificación: <Curso Público Programado>.fecha_comienzo <Localización>.direcciones El proceso: nombre del proceso correspondiente en el DFD <Localización>.id Inputs de flujos de datos <Curso>.nombre Outputs de flujo de datos <Estudiante>.nombre Inputs de datos almacenados: entidades, <Empresa>.dirección relaciones o atributos leídos por el proceso Outputs de datos almacenados: entidades, relaciones o atributos creados, borrados o OUTPUTS DE DATOS ALMACENADOS actualizados por el proceso <Reservas>.instrucciones asistencia enviadas Términos locales: especifican operaciones y comparaciones disponibles sólo en la miniespec Función: lógica usada por el proceso, y que se suele representar en lenguaje estructurado TÉRMINOS LOCALES TÉRMINOS LOCALES Reglas: <diferencia días> es <diferencia días> es Deben contener sólo los datos usados por el <Curso Público Programado>.fecha_comienzo – fecha_hoy <Curso Público Programado>.fecha_comienzo – fecha_hoy proceso que describen <Curso Público Inminente> es un <Curso Público Programado> <Curso Público Inminente> es un <Curso Público Programado> Deben utilizar o producir todos los flujos de datos con <diferencia días> entre 0 y 10 con <diferencia días> entre 0 y 10 indicados en el proceso Deben ser comprensibles para el usuario FUNCIÓN Deben ser completas y sin ambigüedades (es decir, FUNCIÓN dos personas diferentes que comprueben la Para cada <Curso Público Inminente> miniespec con los mismos datos deben obtener la Para cada <Curso Público Inminente> Para cada <Reserva> misma respuesta) Para cada <Reserva> Si Instrucciones Asistencia Enviadas = “No” entonces Si Instrucciones Asistencia Enviadas = “No” entonces Producir Instrucciones Asistencia Producir Instrucciones Asistencia Establecer Instrucciones Asistencia Enviadas a “Si”” Establecer Instrucciones Asistencia Enviadas a “Si”” escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 76 / 92

diccionario de datos tema 3 – análisis de sistemas Notación Notación Diccionario de datos: listado está compuesto de == está compuesto de organizado de todos los datos pertinentes al sistema, con y ++ y definiciones rigurosas y precisas que opcional (puede estar o no presente) ( () ) permiten al analista y al usuario opcional (puede estar o no presente) entender las entradas, salidas, iteración almacenamientos y cálculos n{ }m iteración n{ }m intermedios. comentario ** comentario ** Utilidad: identificador (campo clave) de un @ identificador (campo clave) de un @ Describe el significado de los flujos y almacenamiento almacenamiento almacenes de los DFDs separa opciones alternativas || separa opciones alternativas Describe la composición de datos compuestos (por ejemplo, datos de un cliente) que se pueden descomponer en datos más EJEMPLOS EJEMPLOS elementales (nombre, DNI, dirección,...), tanto de los que se nombre = título_cortesía + nombre + (segundo_nombre) + apellido nombre = título_cortesía + nombre + (segundo_nombre) + apellido mueven por el sistema como de los almacenados. título_cortesía = [Sr. | Srta. | Sra. | Dr. | Prof. título_cortesía = [Sr. | Srta. | Sra. | Dr. | Prof. Especifica los valores y unidades relevantes de datos elementales en nombre = {carácter legal} nombre = {carácter legal} los flujos de datos y almacenamientos. segundo nombre = {carácter legal} segundo nombre = {carácter legal} Describe los detalles de las relaciones entre almacenes que se reflejan en apellido == {carácter legal} apellido {carácter legal} un diagrama entidad-relación. carácter legal = [A-Z | a-z | 0-9 |’ | - | | carácter legal = [A-Z | a-z | 0-9 |’ | - | | escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 77 / 92

diccionario de datos tema 3 – análisis de sistemas FLUJO DE DATOS Instrucciones_Reserva SIGNIFICADO Las instrucciones notificadas por el cliente concernientes a la reserva de un curso. ESTRUCTURA múltiple FLUJOS DE Reserva_Provisional, Especificación de los flujos de DATOS Reserva_en_Firme, CONTENIDOS Cancelación_Estudiante datos en el Diccionario de Datos. Tipos de flujos de datos: FLUJO DE DATOS Reserva_Provisional Múltiple: el flujo está compuesto SIGNIFICADO Reserva no confirmada para una plaza en un curso. Las reservas de flujos que existen en provisionales se asumen como canceladas si no se recibe una Reserva_en_Firme del cliente en el momento de comenzar el curso diferentes momentos de tiempo. ESTRUCTURA grupo Se usan para simplificar COMPOSICIÓN Datos_Cliente diagramas de alto nivel. + Datos_Empresa_Cliente + (Tratamiento_Estudiante) Grupo: el flujo está compuesto + Nombre_Estudiante + Identificación_Curso de otros flujos que existen en el mismo momento de tiempo. Pueden contener otros flujos. FLUJO DE DATOS Nombre_Estudiante ESTRUCTURA elemento Elemento: el flujo es un dato ENTIDAD ESTUDIANTE único, simple. Estos flujos son COMPOSICIÓN {Carácter_Alfabético}30 bien un atributo de una entidad o un mensaje. FLUJO DE DATOS Petición_Sumario_Reserva Par de diálogo: el flujo tiene FLUJO DE DATOS Sumario_Reserva dos nombres: primero un SIGNIFICADO Diálogo relativo a la gestión sobre reservas ESTRUCTURA par de diálogo iniciador y segundo un flujo de respuesta. Ambos deben ser grupos o elementos con su propia FLUJO DE DATOS Petición_Sumario_Reserva especificación de flujo de datos. SIGNIFICADO Petición para conocer el número de estudiantes matriculados en los cursos en la fecha actual ESTRUCTURA grupo COMPOSICIÓN 1{Identificación_Curso} FLUJO DE DATOS Sumario_Reserva SIGNIFICADO Relación del número de matriculados en los cursos ESTRUCTURA grupo COMPOSICIÓN 1{Identificación_Curso + Reservas_Totales} + Fecha_Actual escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 78 / 92

diccionario de datos tema 3 – análisis de sistemas Especificación de entidades y relaciones del DER en el Diccionario de Datos Ejemplo ENTIDAD: Especificación de entidad. ENTIDAD CURSO A cada entidad le SIGNIFICADO Cada CURSO es un seminario estándar que puede ser programado para llevarse a cabo en determinadas fechas o bajo demanda de corresponde una clientes específicos especificación, que ATRIBUTOS Identificación_Curso contiene: Nombre_Curso Duración_Curso Significado Número_Máximo_Estudiantes IDENTIFICADORES Identificación_Curso Atributos Nombre_Curso Identificadores (atributos clave) Ejemplo RELACIÓN Especificación de RELACIÓN cubre relación. A cada relación ENTIDADES CURSO cubre MATERIA le corresponde una PARTICIPANTES especificación, que SIGNIFICADO Un CURSO cubre una determinada MATERIA si en su desarrollo se trata ésta con una cierta profundidad contiene: PARTICIPACIÓN CURSO: opcional Entidades MATERIA: opcional CARDINALIDAD CURSO 1:N participantes MATERIA 1:N Significado de la relación Tipo de participación de las entidades (obligatoria u opcional) Cardinalidad escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 79 / 92

modelado de datos tema 3 – análisis de sistemas Cuestiones relevantes del modelado Cuestiones relevantes del modelado de datos: de datos: Necesidad de organizar la información: Necesidad de organizar la información: - ¿Cuales son las entidades (objetos de - ¿Cuales son las entidades (objetos de - Ayuda a entender y nombrar la información datos) primarios que va a procesar el - Ayuda a entender y nombrar la información datos) primarios que va a procesar el - Evita la redundancia sistema? - Evita la redundancia sistema? - Asegura la corrección, validación y completitud - ¿Cual es la composición de cada - Asegura la corrección, validación y completitud - ¿Cual es la composición de cada - Su organización refleja la política del negocio entidad y qué atributos la describen? - Su organización refleja la política del negocio entidad y qué atributos la describen? - ¿Qué relaciones existen entre las - ¿Qué relaciones existen entre las entidades? - Profesor entidades? - Profesor - Estudiante - Estudiante - Curso programado - Curso programado ENTIDADES: conjunto de información ENTIDADES: conjunto de información compuesta (categorías o cosas que son compuesta (categorías o cosas que son descritas por la información) descritas por la información) - El profesor IMPARTE un curso - El profesor IMPARTE un curso programado RELACIONES: asociaciones entre las entidades programado COMPONENTES DE RELACIONES: asociaciones entre las entidades - El alumno SE MATRICULA de un COMPONENTES DE - El alumno SE MATRICULA de un LA INFORMACIÓN curso programado LA INFORMACIÓN curso programado ATRIBUTOS: definen las propiedades de una ATRIBUTOS: definen las propiedades de una entidad. Se pueden usar para: entidad. Se pueden usar para: - Nombrar - Nombrar - Número de estudiantes - Describir - Número de estudiantes - Describir - Fecha de comienzo - Referenciar - Fecha de comienzo - Referenciar - Dirección Cada ocurrencia de la entidad tiene un valor para - Dirección Cada ocurrencia de la entidad tiene un valor para cada atributo cada atributo Cardinalidad: cantidad de ocurrencias de una Cardinalidad: cantidad de ocurrencias de una entidad que se relacionan con las de otra entidad. entidad que se relacionan con las de otra entidad. Tipos: 1:1 (1 marido ---> 1 esposa) Tipos: 1:1 (1 marido ---> 1 esposa) 1:N (1 madre --> N hijos) 1:N (1 madre --> N hijos) M:N (1 tío --> N sobrinos, M:N (1 tío --> N sobrinos, 1 sobrino --> N tíos) escuela superior de ingeniería informáticasobrino --> N tíos) © enrique barreiro alonso 1 universidade de vigo - departamento de informática ingeniería del software de gestión 80 / 92

diagrama entidad-relación tema 3 – análisis de sistemas Diagrama Entidad-Relación (DER): Materia ENTIDAD Propuesto por Chen (1977) para el diseño de bases de RELACIÓN datos relacionales Muestra categorías ENTIDAD importantes de información ASOCIATIVA cubre Localización Muestra asociaciones relevantes entre categorías La política del negocio SUPERTIPO aula determina qué es o no es relevante independiente del Curso Curso procesamiento programado (transformación) de datos componentes: entidades ATRIBUTO código atributos relaciones SUBTIPO Curso Curso programado programado público interno escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 81 / 92

diagrama entidad-relación tema 3 – análisis de sistemas Entidad representación de cualquier composición de información compuesta que necesite el sistema composición de información: todo lo que tiene un número de propiedades o atributos diferentes: Pueden ser: CURSO cosas (informes, pantallas,...) entidades externas (productores o consumidores de información) sucesos (una alarma) unidades de una organización (departamento, empresa,...) AVIÓN ... Ejemplos: edad: valor sencillo (no es una entidad) EMPLEADO persona: incorpora edad, peso, altura,... (es una entidad) Algunas guías: LIBRO Las entidades deben nombrarse con sustantivos Debe ser posible reconocer ocurrencias individuales de la entidad Cada entidad debe tener atributos La entidad es de interés al sistema y al negocio escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 82 / 92

diagrama entidad-relación tema 3 – análisis de sistemas Atributos definen propiedades de una entidad se usan para nombrar una ocurrencia de la entidad describir la entidad hacer referencias a ocurrencia en otra tabla uno o varios atributos se definen como identificador (“clave” para encontrar una instancia de la entidad) color ID propietario matrícula COCHE modelo fabricante carrocería escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 83 / 92

diagrama entidad-relación tema 3 – análisis de sistemas Relaciones las entidades se relacionan unas con otras: una persona posee un coche un curso se imparte en un aula un cliente solicita un producto se definen por el contexto del problema analizado para que exista deben existir previamente las ocurrencias de las entidades Se nombran con frases verbales. Se pueden nombrar en los dos sentidos: el profesor puede impartir un curso el curso puede ser impartido por un profesor PROFESOR CURSO PROFESOR CURSO puede impartir Puede puede impartir PROFESOR CURSO Ana Introd. Java impartir Ana Introd. Java Manuel Access Manuel Access José Cobol José Cobol escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 84 / 92

diagrama entidad-relación tema 3 – análisis de sistemas ejemplos de relaciones entre entidades CLIENTE Puede PROFESOR CURSO impartir CURSO reserva ESTUDIANTE PÚBLICO PLANIFICADO PROFESOR Puede Ha pilota PILOTO VUELO impartir asistido CURSO asignado AVIÓN escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 85 / 92

diagrama entidad-relación tema 3 – análisis de sistemas Entidad y tablas una entidad encapsula sólo datos no hay referencia a operaciones sobre los datos se puede representar como una tabla encabezamientos tabla: atributos del objeto cuerpo tabla: ocurrencias de la entidad enlaza una entidad a otra, en este caso atributos PROPIETARIO Coche a Propietario identificativos atributos atributo descriptivos de referencia ID propietario identificador Fabricante Modelo Matricul Tipo Color ID a carrocería Propietario color ID propietario Citroen Xsara AB123 Sedán Rojo RSP BMW 525 BM567 Sport Azul EBM Matrícula Ford Focus FO677 Coupe Gris JRI COCHE Renault Megane RE766 Sedán Azul PVS modelo item fabricante carrocería escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 86 / 92

diagrama entidad-relación tema 3 – análisis de sistemas Cardinalidad cantidad de ocurrencias (items, instancias) de la entidad X que están relacionadas con la entidad Y define el número máximo de relaciones de entidades que pueden participar en una relación ejemplos: 1:1 (1 marido ---> 1 esposa) 1:N (1 madre --> N hijos) M:N (1 tío --> N sobrinos, 1 sobrino --> N tíos) 1:n 1:1 posee PROPIETARIO COCHE 1:1 1:n construye FABRICANTE escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 87 / 92

diagrama entidad-relación tema 3 – análisis de sistemas Entidades asociativas Entidades asociativas - Entidad asociativa: entidad Y relación: - Entidad asociativa: entidad Y relación: CURSO LOCALIZACIÓN - tiene atributos (en su papel de entidad) - tiene atributos (en su papel de entidad) - asocia ocurrencias de otras entidades (en su papel de relación) - asocia ocurrencias de otras entidades (en su papel de relación) - como entidad puede tomar parte en otras relaciones - como entidad puede tomar parte en otras relaciones CURSO PROFESOR imparte PROGRAMADO Fecha comienzo SUPERTIPO Todos los vehículos Subtipo Subtipo tienen atributos como “velocidad máxima” o - Grupo de items de entidades que: Vehículo - Grupo de items de entidades que: “potencia” - tienen atributos específicosno relevantes para todos los - tienen atributos específicosno relevantes para todos los items de la entidad items de la entidad - pueden participar en relaciones no permitidas para todos los - pueden participar en relaciones no permitidas para todos los items de la entidad items de la entidad - Puede haber cualquier número de subtipos - Puede haber cualquier número de subtipos - La entidad clasificada se denomina supertipo - La entidad clasificada se denomina supertipo - Un item del subtipo es el mismo item del supertipo. - Un item del subtipo es el mismo item del supertipo. Vehículo Vehículo servicio privado Sólo los vehículos público públicos tienen atributos como “número máximo de SUBTIPOS pasajeros” escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 88 / 92

administración del análisis: documentación tema 3 – análisis de sistemas 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: cliente usuarios administradores del proyecto analistas del sistema diseñ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ática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 89 / 92

administración del análisis: responsabilidades tema 3 – análisis de sistemas involucración de muchos participantes problemas 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ón cliente: integra la información del dominio de aplicación, resolviendo inconsistencias en las expectativas de los usuarios arquitecto: 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 de partes del sistema de las que no son responsables. editor de documentos: responsable del formato general del documento y su índice gerente 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ón revisor: 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ática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 90 / 92

administración del análisis: comunicación tema 3 – análisis de sistemas factores que influyen en la comunicación diferentes 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 factores definición clara de responsabilidades definición de objetivos claros y criterios de éxito tormentas de ideas escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 91 / 92

bibliografía tema 3 – análisis de sistemas 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 escuela superior de ingeniería informática © enrique barreiro alonso universidade de vigo - departamento de informática ingeniería del software de gestión 92 / 92

Ingeniería del Software de Gestión. Tema 3

0 comments

Notes on slide 1

1 Favorite