ilovepdf_merged.pdf

TEMA 1. INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE El software... - Es tangible - Se desarrolla, no se fabrica - No se estropea (se puede quedar obsoleto) Tipos de software Evolución del coste del software Hardware...

TEMA 1. INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE El software... - Es tangible - Se desarrolla, no se fabrica - No se estropea (se puede quedar obsoleto) Tipos de software Evolución del coste del software Hardware Software - Válvulas de vacío - Interfaces gráficas de usuario - Transistores - Internet - Circuitos integrados - La nube - Microprocesador → ordenador personal Evolución del Hardware / Software 1ª Generación (1945-56) 1ª Generación (1945-56) - Electrónica con tubos vacío - Lenguaje máquina (ensamblador) - ENIAC-1946, primer ordenador. IBM 701, - Trabajo secuencial: perforación, ejecución, primer ordenador comercializado impresión - 10K instrucciones por segundo 2ª Generación (1957-63) 2ª Generación (1957-63) - Electrónica con transistores, memoria con - Lenguajes alto nivel: COBOL, FORTRAN, núcleos de ferrita ALGOL - Procesamiento por lotes, máquinas dedicadas a E/S 3ª Generación (1964-71) 3ª Generación (1964-71) - Electrónica con circuitos integrados, - Utilización de SSOO memoria en chips - 5M instrucciones por segundo 4ª Generación (1972-81) 4ª Generación (1972-81) - Microprocesadores y chips de memoria - Lenguaje C / Unix. Programas de amplio - Mayor capacidad de integración (VLSI) uso - 200M instrucciones por segundo 5ª Generación (1982-89) 5ª Generación (1982-89) - Microprocesadores en paralelo. Redes de - Internet. Lenguajes simbólicos. Programas computadores más complejos - Componentes ópticos (CD/DVD) - 1G instrucción por segundo 6ª Generación (1990-Actualidad) 6ª Generación (1990-Actualidad) - Arquitecturas paralelas y distribuidas - Programación funcional - Procesadores especializados - Desarrollo de la inteligencia artificial Chaos Reports Intentan identificar los principales problemas del desarrollo software. Realizado por la consultora Standish Group. Clasifica miles de proyectos reales como: - Éxito: finalizado dentro del plazo y presupuesto y cumpliendo todos los requisitos. - Con problemas: finalizado pero fuera de plazo, fuera de presupuesto y sin cumplir todos los requisitos. - Fracaso: cancelado durante el desarrollo ¿Qué es una Ingeniería? Actividades propias de los Ingenieros: - Conciben, proyectan, construyen y gestionan la explotación eficiente de: obras públicas, máquinas, sistemas de control, redes de comunicaciones, centrales energéticas, sistemas de regadíos… Y el software. Científicos: Realizan actividad sistemática para adquirir nuevos conocimientos. Pilares de una Ingeniería - Vocabulario: conjunto de términos que se usan en un campo concreto (interfaz, clase, objeto, variable, interface, requisito…). - Tecnología: instrumentos, procedimientos o recursos usados en un campo (Java, Python, JS, HTML, Oracle, TCP/IP…). - Herramientas: conjunto de instrumentos para desempeñar un trabajo concreto (Eclipse, Aptana, VSCode, SQLDeveloper…). - Buenas prácticas: conjunto de acciones que dan buenos resultados en un campo (PMBOK, ITIL, CMMI…). - Metodologías: conjunto de procedimientos bien definidos para obtener buenos resultados (SCRUM, RUP, XP, AUP…). Orígenes de la Ingeniería del software El término software apareció por primera vez en la Software Engineering Conference (SEC) de la OTAN en Garmisch, Alemania (1968). Esta conferencia decidió tomar un enfoque ingenieril como solución a lo que se denominó la crisis del software. El término se atribuye a Fritz Bauer. Se definió el concepto de ciclo de vida del software y se identificaron los principales problemas asociados al software: sobrecostes, retrasos, baja calidad, mantenimiento difícil, etc. Definiciones de Ingeniería del Software - (a) la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software. (b) el estudio de los enfoques como los descritos en (a). - La aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios. Definición de Proyecto Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. Hay distintos tipos de proyectos: productivo, público, social, de vida y científico. Etapas de un proyecto (PDCA): Ciclo de Deming 1. Plan: organizar y planificar los pasos a seguir en el proyecto. 2. Do: llevar a cabo parte del plan. 3. Check: analizar los resultados. 4. Act: hacer los cambios necesarios para resolver los fallos. Roles en un proyecto software Productos de la ingeniería del software Durante un proyecto deben entregarse productos al cliente denominados “entregables”. - Entregables previos al comienzo: 1. Petición de propuestas. 2. Pliego de Prescripciones. 3. Oferta. 4. Contrato. - Entregables habituales: 1. Plan de proyecto. 2. Informes de seguimiento. 3. Especificaciones de requisitos. 4. Documento de diseño. 5. Plan de pruebas. 6. Código fuente. 7. Software ejecutable. 8. Manuales de usuario. Normas y estándares del ciclo de vida del software - ISO/IEC/IEEE 12027:2017: Es un estándar que trata sobre los procesos del ciclo de vida del software, sin fomentar ningún modelo concreto de ciclo de vida. Tampoco indica cómo realizar ninguna de las actividades indicadas en la normativa. Distingue dos tipos de procesos: específicos del software y del contexto del sistema. - CMMI-DEV (2010): Se trata de un modelo para la mejora y evaluación de procesos de desarrollo, mantenimiento y operación de sistemas software. Mide la madurez de los procesos de negocio. Al solicitar la certificación CMMI se obtiene un nivel acorde al cumplimiento de la normativa por parte de la entidad solicitante. Mantenimiento del software - Es necesario para mejorar, adaptar o corregir el software. - El coste de mantenimiento es el más alto de todo el ciclo de vida. - Tipos de mantenimiento: Evolutivo (60%), Adaptativo (18%), Correctivo (17%), Perfectivo (5%). Gestión de incidencias - Restaurar cuanto antes la operativa normal del servicio minimizando el impacto negativo en las operaciones de negocio. - Detección, registro, categorización, priorización, diagnóstico, escalado, resolución y cierre. Calidad del software Los gastos en análisis de calidad se compensan con el ahorro en solución de errores. Calidad de un proyecto: - Cumplir los requisitos. - Cumplir los estándares de desarrollo necesarios. - Tener las características implícitas que se esperan de todo software profesional. Equipo de SQA (Software Quality Assurance): - Establecer el plan de SQA del proyecto. - Participar en la creación del plan del proyecto. - Documentar e informar de los aspectos a mejorar que se detecten en las revisiones técnicas formales (RTF). Gestión de la configuración Se encarga de identificar, controlar e informar de los cambios producidos en los productos. Actividades: - Determinar los productos bajo control de configuración. - Control de cambios y versiones. - Auditoría de la configuración. - Generación de informes del estado de la configuración. Línea base (baseline): - Versión cerrada de algún elemento de configuración a partir de la cual es necesario aplicar la política de control de cambios antes de modificarlo. CMS/CMDB: - Configuration Management System / Configuration Management Database. - Infraestructura de la organización de TI, típicamente compuesta por varias bases de datos que almacenan información acerca de los elementos software bajo control de versiones. TEMA 2. EL CICLO DE VIDA DEL SOFTWARE ¿Qué es un ciclo de vida? Se trata de un marco de referencia que describe los procesos, actividades y tareas que se deberían realizar durante un proyecto de software. Ciclo de vida clásico (en cascada) - Cada fase comienza cuando termina la anterior. - Asume que se conocen todos los requisitos. - Se tarda mucho en disponer del software. - Es mejor que no seguir ningún ciclo de vida. - Es el más fácil de planificar, es el ciclo ideal. - Cada fase finaliza con entregables: 1. Análisis. 2. Diseño. 3. Implementación. 4. Pruebas. 5. Mantenimiento Inconvenientes: - El software no se desarrolla realmente de forma lineal. - Es un modelo demasiado rígido. - Es difícil conocer todos los requisitos desde el principio. - Modelo lento y monolítico. - No se dispone del software hasta finalizar todas las etapas. Ciclos evolutivos: Está basado en actualizaciones mediante ciclos de requisitos-desarrollo-evaluación. El resultado de la evaluación permite evolucionar hacia la siguiente versión. Ciclo incremental: Consiste en repetir varios ciclos de vida en cascada tras los cuales se entrega una versión parcial del software. Está orientado a desarrollos de gran tamaño. Ciclo iterativo: Al igual que el ciclo evolutivo, repite varios ciclos de vida en cascada, entregando, en este caso, una versión completa del software que mejora en cada iteración. Se suele aplicar a desarrollos en los que los requisitos no están claros. Los usuarios deben evaluar el producto en cada iteración y proponer mejoras. Ciclos de vida basados en prototipos - Uso no exclusivo del ciclo de vida iterativo. - Se emplean prototipos de interfaz de usuario, que pueden reutilizarse (ejecutables) o desecharse (papel). - Hay que evaluar si el esfuerzo de crear un prototipo merece la pena. - Es fundamental tener usuarios a los que mostrar el prototipo. - Enfoques: - Desechable: el prototipo no se reutiliza. - Evolutivo: el prototipo se convierte poco a poco en el sistema final. - Mixto: desechable para requisitos conocidos y evolutivo para requisitos poco conocidos. - Prototipos funcionales: se utilizan para evaluar diferentes algoritmos antes de tomar decisiones de diseño (sin interacción con el usuario). Inconvenientes: - Se suele refinar el prototipo en lugar de desecharlo y empezar de 0. - El cliente puede conformarse con el prototipo y finalizar el proyecto. - El prototipo provoca la relajación de los desarrolladores. - No disminuye el tiempo entre la definición de los requisitos y la entrega del producto. - Al usuario le desagrada que se deseche código. Ciclos de vida con métodos ágiles Son ciclos de vida evolutivos con iteraciones de corta duración que favorecen la comunicación con clientes y usuarios. En cada iteración se incorporan nuevos requisitos. Desarrollo ágil frente al tradicional. Iterativo e incremental a la vez: El manifiesto ágil de 2001… - Individuos e interacciones > procesos y herramientas - Software que funcione > documentación detallada - Colaboración con el cliente > negociación de contratos - Respuesta al cambio > seguimiento de un plan Los métodos ágiles no implican la mala práctica de escribir código sin planificación alguna. Técnicas de apoyo: - Refactoring: mejoras sobre el código fuente sin cambiar la funcionalidad. - Pruebas automáticas: pruebas programadas en lugar de realizadas a mano. - Integración continua: automatización de la compilación y ejecución de pruebas automáticas. Desarrollo ágil vs Desarrollo tradicional: Metodología Scrum Es el tipo de metodología ágil utilizada actualmente. Características: - Iteraciones de 30 días (sprints). - Código que puede ser entregable. - No se admiten cambios en los requisitos ni de miembros durante sprint. Agile meetings: Reuniones cortas y frecuentes en las que se expone qué se ha hecho, qué problemas han surgido y qué se va a hacer hasta la próxima reunión. Backlog: Se trata de una lista priorizada de tareas, tanto a nivel de producto como de iteración. Ciclo de vida del Proceso Unificado Proceso iterativo e incremental propuesto por los creadores de UML. Fases: 1. Inicio. 2. Elaboración. 3. Construcción. 4. Transición. 5. Producción. 6. Retirada. En cada fase se produce una o más iteraciones y se obtiene una versión evaluable del software. Ciclo de vida en Métrica 3 Es la metodología oficial de las Administraciones Públicas de España. Permite aplicar diferentes ciclos de vida. Procesos básicos: - Plan de Sistemas de Información (PSI). - Desarrollo de Sistemas de Información: - Estudio de Viabilidad del Sistema (EVS). - Análisis del Sistema de Información (ASI). - Diseño del Sistema de Información (DSI). - Construcción del Sistema de Información (CSI). - Implantación y Aceptación del Sistema (IAS). - Mantenimiento de Sistemas de Información (MSI) Procesos de apoyo: - Gestión de proyectos. - Seguridad. - Gestión de la Configuración. - Aseguramiento de la Calidad. Pruebas en el ciclo de vida Modelo en V: Asocia un tipo de prueba al producto de cada fase. - Pruebas unitarias → Implementación de componentes - Pruebas de Integración → Diseño de la arquitectura - Pruebas de sistema → Requisitos de software - Pruebas de aceptación → Requisitos de cliente Ingeniería inversa A veces es necesario mantener sistemas heredados (legacy systems) de los que no se dispone documentación. La ingeniería inversa consiste en estudiar dichos sistemas para crear la documentación, normalmente analizando el código para obtener el diseño. Reingeniería Utiliza la información obtenida por la ingeniería inversa para aplicar cualquier tipo de mantenimiento sobre el código. El mayor esfuerzo de ingeniería inversa y reingeniería de la historia de la Ingeniería del Software fue el efecto 2000. TEMA 3. INTRODUCCIÓN A LOS SISTEMAS DE INFORMACIÓN ¿Qué es un sistema de información? Un sistema diseñado para recoger, almacenar, procesar y distribuir información sobre el estado de su entorno y soportar las operaciones, la gestión y la toma de decisiones de la organización de la que forma parte y a la que da servicio. Un sistema interactúa con un entorno, del que toma sus entradas y hacia el que genera sus salidas. - Las entradas pueden ser datos, energía o materia. - Las salidas pueden ser información, energía o materia. - Los objetivos de un sistema determinan cómo se obtienen las salidas. - Casi todos los sistemas son realimentados, de forma que tienen en cuenta su propio efecto sobre el entorno y actúan en consecuencia Datos: Hechos o cifras que de manera aislada no son relevantes (necesitan ser procesados). Información: Conjunto de datos procesados dotados de significado y propósito. Conocimiento: Mezcla de experiencias, valores, información de contexto y juicio basado en la experiencia que permite evaluar e incorporar nuevas experiencias e información. Se origina y aplica en la mente humana. Nivel de gestión de una organización La eficiencia en una compañía depende de los niveles de gestión y planificación de su sistema logístico y de funcionamiento interno, al ayudar a la toma de decisiones. Estrategia: - Gestiona la organización como un todo. - Objetivos a largo plazo de la organización. - Decidida por la dirección. Táctica: - Gestiona un departamento/unidad. - Objetivos a medio-corto plazo de la unidad. - Responsabilidad de la unidad organizativa. Operativa: - Llevan a cabo planes de acción con metas inmediatas. - Resultados específicos. - Reparto previo de tareas. ¿Qué es un sistema informático ? Están compuestos por hardware, software, personal y los procesos de operación y mantenimiento. S. Informático vs. S. Información - Un sistema de información suele incluir un sistema informático entre sus componentes. - Un sistema informático no tiene porqué ser parte de un sistema de información. Ej: una consola es un sistema informático no incluido en un sistema de información. Ejemplo: Biblioteca - S. Información: bibliotecario, fichas de libros, procedimiento de préstamo… - S. Informático: ordenador, aplicación y personas que la usan… Sistemas de información Funciones: Se pueden ejecutar bajo demanda o de forma autónoma. - Memoria: mantiene una representación interna del estado del entorno del sistema. - Informativa: proporciona información sobre el estado del entorno del sistema. - Activa: realiza acciones que modifican el estado del entorno del sistema. Componentes: - Personas. - Software. - Hardware. - Recursos online. - Datos. Clasificación: Existen diferentes criterios, aunque el más habitual es en función del servicio que ofrecen. - Apoyo a la operación: TPS (Transaction Processing System). - Apoyo a la gestión: MIS (Management Information System) / DSS (Decision Support Systems). Transaction Processing System (TPS): Las transacciones son interacciones entre dos o más partes en las que se intercambia información. El objetivo de un TPS es obtener y procesar datos sobre las transacciones que se realizan diariamente en su organización. - Las transacciones suelen tener procedimientos rutinarios fáciles de informatizar. - Los TPS suelen recoger datos para otros sistemas de información. - Un fallo en un TPS puede tener graves consecuencias. Características ACID: Son aquellas con las que cuenta un buen TPS. - Atomicity: las operaciones o son completadas o descartadas por completo. - Consistency: las operaciones no pueden violar la integridad de los datos. - Isolation: cada operación debe ser independiente y ser llevada a cabo sin que afecte al resultado de otra transacción. - Durability: el resultado de una operación debe quedar registrado. Ejemplos: Cajeros automáticos, pedidos de clientes, tramitación de expedientes… Management Information System (MIS) Proporcionan la información necesaria para las operaciones y la administración táctica de la empresa. - Transforman los datos e información en otras formar más fáciles de manejar. - Generan informes periódicos a partir de la información proporcionada por los TPS. Ejemplos: Control de inventarios, elaboración de presupuestos, reubicación de personal… Decision Support Systems (DSS) Usan información de los TPS, MIS y fuentes externas (competencia, mercados, clientes…). - Proporcionan informes, análisis y simulaciones para resolver problemas imprevistos. - Para no cargar los TPS, se utiliza un sistema de Data Warehouse o Big Data. Sistemas integrales de gestión (soluciones integrales llave en mano) Enterprise Resource Planning (ERP): Son sistemas que integran todo lo necesario para el funcionamiento de los procesos de negocio de la empresa: compras, ventas, inventario, nóminas, fabricación, contabilidad… Customer Relationship Management (CRM): - Modelo de gestión de la empresa enfocado principalmente a los clientes. - Generan incentivos para satisfacer a los clientes, ofreciendo soluciones que se ajusten a sus expectativas. - Marketing, atención al cliente, facturación... Supplier Chain Management (SCM): - Sistemas que gestionan transporte, rutas, gestión de lotes… - Busca mejorar y automatizar el suministro, reduciendo las existencias y plazos de entrega. - Permite rastrear el paso de las “piezas” por la cadena de suministro. TEMA 4. REQUISITOS PARA SISTEMAS DE INFORMACIÓN ¿Qué es un requisito? Es una condición o característica que el sistema debe cumplir. Dominio del problema: - Crear un glosario de términos que aprender. - Obtener requisitos de los usuarios. Tipos de requisitos: - Generales (objetivo). - Detallados: - Funcionales: servicios deseados por el usuario. - No funcionales: relacionados con la calidad. Historias de usuario Es la forma de obtener los requisitos en metodologías ágiles. Son las propuestas de los usuarios que ayudan a la especificación de los requisitos. Se escriben con el vocabulario del usuario. Formato (Mike Cohn): - Como: tipo de usuario (opcional). - Quiero: servicio deseado. - Para: razón (opcional). Ejemplos: Requisitos generales (objetivos) Describen los objetivos finales del sistema de información. En muchos casos, el nivel de detalle de las historias de usuario es insuficiente para implementar una solución. Historias épicas: Son aquellas que recogen objetivos generales (muchas veces solo un nombre). Pueden servir para clasificar de forma jerarquizada el resto de historias que las detallan. Requisitos funcionales Definen los servicios que los usuarios desean que el sistema les ofrezca. Ejemplos: Requisitos de información Describen qué información se debe almacenar sobre un concepto relevante, junto con los datos específicos del concepto son importantes para los usuarios. Ejemplo: Reglas de negocio Definen reglas o políticas que son importantes para los usuarios y deben ser respetadas. Suelen ser requisitos relativamente inestables. Ejemplo: La sanción por devolución tardía o el número máximo de préstamos simultáneos en una biblioteca podría cambiar en el futuro por cambios en la política de la biblioteca. Requisitos no funcionales Describen aspectos relacionados con la calidad que son importantes para los usuarios: usabilidad, rendimiento, disponibilidad, fiabilidad, seguridad, compatibilidad, etc. Ejemplos: ISO 9126: Se trata de un estándar que divide los requisitos no funcionales en los siguientes grupos: - Funcionalidad. - Portabilidad. - Mantenibilidad. - Eficiencia. - Usabilidad. - Fiabilidad. Pruebas de aceptación Describen cómo verificar el cumplimiento de los requisitos y añaden detalle a las historias de usuario, sin complicar su descripción. - Cada prueba se asocia a uno o más requisitos. - Lo ideal es que puedan programarse para que se ejecuten automáticamente. Ejemplo: TEMA 6. INTRODUCCIÓN AL MODELO CONCEPTUAL El modelado conceptual es una técnica de análisis de requisitos y de diseño de bases de datos. - Como técnica de análisis de requisitos… Ayuda a identificar problemas en los requisitos antes de comenzar el desarrollo, evitando gastos innecesarios. - Como técnica de diseño de bases de datos… Permite representar de forma abstracta los conceptos y hechos relevantes del dominio del problema y transformarlos posteriormente en un esquema de una base de datos concreta. - Independientemente del ciclo de vida, se utiliza durante el análisis. Dominio del problema: En el ámbito de los sistemas de información, es el conjunto de conceptos que es necesario conocer para entender el negocio del cliente y sus necesidades y así proponer una solución adecuada. Trazabilidad hacia los requisitos: Todo elemento de un modelo conceptual debe estar trazado hacia los requisitos que lo justifican, habitualmente requisitos de información y reglas de negocio. Estándar para modelado conceptual: - UML (Unified Modeling Language) - Gestionado por la OMG (Object Management Group). - Ampliamente utilizado en la industria del software. - Múltiples herramientas disponibles. - Se utilizan principalmente: Diagramas de clases y Diagramas de objetos Diagrama de clases: Clase entidad Representan conceptos sobre los que el sistema debe almacenar información. Se nombran con sustantivos en singular. Atributo de una clase entidad: Son propiedades asociadas a cada entidad. Ejemplos: - Entidad alumno. Atributos: nombre, fechaNacimiento… - Entidad asignatura. Atributos: código, nombre… - Entidad matrícula. Atributos: número, fecha, tieneBeca… Notación UML Se divide en dos zonas diferenciadas. - Zona de nombre (obligatoria). - Zona de atributos (opcional). - No se suele especificar el tipo de los atributos. - Mediante [0..1] indicamos que el atributo es opcional, es decir, que cuando no se conozca su valor se representará mediante un valor nulo. Asociación Las asociaciones representan relaciones entre entidades. - Se nombran con un verbo en tercera persona del singular. - Su etiqueta debe formar una frase con sentido al leerla junto a los nombres de las entidades. - Para aclarar el sentido de la asociación se puede situar una flecha sobre la etiqueta. Rol de un extremo de una asociación - Papel que juega cada una de las clases que participan en una asociación. - Solo es necesario indicarlo en asociaciones de una clase consigo misma o cuando existe más de una asociación entre dos clases. Multiplicidad Dado un objeto de una clase, indica el mínimo y máximo número de objetos de la otra clase con los que puede estar asociado. Ej.: Un vuelo puede tener un único origen y un único destino, mientras que un aeropuerto puede tener cualquier número de salidas o llegada. Valores habituales de multiplicidades - 0..1 : opcional (uno o ninguno). - 0..* ó * : opcional múltiple (cualquier cantidad). - 1..* : obligatoria múltiple (al menos uno). - 1..1 ó 1 : obligatoria (estrictamente uno). Importante: No tiene sentido poner cardinalidad en el triángulo blanco (herencia) ni en el rombo (composición). Notación para asociaciones en UML Generalización/especialización A veces, algunos de los conceptos del dominio del problema presentan entre ellos relaciones del tipo es-un, por ejemplo: Estos conceptos suelen tener propiedades comunes, que al modelarlos conceptualmente aparecen como atributos o asociaciones comunes. La clase más general (la superclase), contiene todas las propiedades (atributos y asociaciones) comunes, que son heredados por las clases más específicas (las subclases). - Todas las instancias de las subclases se consideran también instancias de la superclase. - La generalización es una relación transitiva y antisimétrica. Notación para la generalización en UML Clasificación completa/incompleta: - {completa}: las instancias de la superclase deben ser instancias de al menos una subclase, la superclase es abstracta. - {incompleta}: puede haber instancias de la superclase que no lo sean de ninguna subclase. Clasificación disjunta/solapada: - {disjunta}: las instancias de la superclase pueden ser instancias de una sola subclase. - {solapada}: las instancias de la superclase pueden ser instancias de una o más subclases. - {completa, disjunta}: implica una partición del conjunto de instancias de la superclase. Composición Asociación especial que representa el concepto de ser-parte-de o de estar-compuesto-por: - Una parte sólo puede pertenecer a un todo. - Una parte no puede existir sin pertenecer a un todo. - La eliminación del todo implica la eliminación de todas sus partes. - Es una relación transitiva y antisimétrica. - Puede ser recursiva Notación para la composición en UML Agregación Es similar a la composición, pero más débil: - Una parte puede pertenecer a uno, varios o ningún todo. - Una parte sí puede existir sin pertenecer a un todo. - La eliminación del todo no implica la eliminación de todas sus partes. - Sigue siendo transitiva, antisimétrica y recursiva. Notación para la agregación en UML Notación para clases asociación en UML A veces es necesario añadir cierta información a las asociaciones, convirtiéndolas en clases. También es posible modelarlas como una clase componente (la clase asociación puede modelarse como componente de cualquiera de las clases que participan en la asociación, pero sólo de una, ya que una parte sólo puede pertenecer a un todo) de las clases participantes. Ambos modelos son equivalentes. Notación para restricciones Permiten añadir información al modelo que no puede expresarse de otra forma. Se representan mediante notas. El texto debe ir entre llaves, indicando tanto el nombre de la restricción como su descripción. Opcionalmente, se pueden enlazar a las entidades afectadas. Notación para tipos enumerados Definen un tipo que puede ser usado en los atributos de las clases entidades. Se utiliza el estereotipo «Enumerado» o «Enum». Los atributos son los posibles valores. Diagramas de objetos: Objetos y enlaces - Objetos: Cada ocurrencia o instancia de una clase. - Enlaces: Cada ocurrencia o instancia de una asociación. Notación para objetos y enlaces en UML Notación para clases asociación en UML Ejemplo: las horas que trabaja un empleado en un proyecto no son una propiedad ni del empleado ni del proyecto, sino de la asociación entre ambos. Creación de modelos conceptuales Pasos recomendados: 1. Analizar la información sobre el dominio del problema (glosario) y los requisitos. 2. Identificar posibles entidades y atributos. 3. Identificar posibles asociaciones. 4. Construir incrementalmente el modelo conceptual e identificar las multiplicidades de las asociaciones. 5. Identificar clasificaciones entre entidades con propiedades (atributos y/o asociaciones) comunes. 6. Identificar composiciones entre entidades. 7. Añadir las restricciones que no puedan expresarse gráficamente. 8. Validar con posibles escenarios mediante diagramas de objetos. 9. Registrar todos aquellos problemas semánticos que deban ser aclarados con clientes y usuarios