lOMoARcPSD|9132568 Elaboración de los diagramas del Modelo de dominio del proyecto. GA2-220501093-AA2-EV01 lOMoARcPSD|9132568 Servicio Nacional de Aprendizaje SENA Tecnología en Análisis y Desarrollo de Software ADSO Nombre de la evidencia: GA2-220501093-AA2-EV01 Elaboración de los diagramas del modelo de dominio del proyecto. Presentado por : Juan David sierra laborde lOMoARcPSD|9132568 ÍNDICE Introducción...............................................................................................................................................3 Descripción de la actividad a realizar....................................................................................................4 Desarrollo de la actividad........................................................................................................................5 Diagrama de clases..................................................................................................................................5 Diagrama de paquetes.............................................................................................................................6 Página 2 de 9 lOMoARcPSD|9132568 Introducción En el presente documento vamos a realizar el diagrama de clases y diagrama de paquetes para el desarrollo del proyecto de la página web de la empresa Estufas Ecoeficientes METALCOF, para llevar a cabo la organización de las categorías que intervienen en el proyecto Página 3 de 9 lOMoARcPSD|9132568 DESCRIPCIÓN DE LA ACTIVIDAD A REALIZAR Evidencia GA2-220501093-AA2-EV01: elaboración de los diagramas del modelo de dominio del proyecto. Esta evidencia se centra en la elaboración del diagrama de clases del proyecto, identificando cómo las categorías que intervienen se relacionan, teniendo en cuenta su cardinalidad, dependencias y herencias, llevando esto a la organización de objetos por medio de segmentación de componentes en paquetes claramente identificables. Aspectos a tener en cuenta: Se deben seguir las características e instrucciones para la elaboración de un diagrama de dominio del proyecto. El modelo conceptual resultante debe guardar las proporciones necesarias, de modo que se vea ordenado y sea fácil su lectura. Para complementar el modelo del dominio, se puede representar por medio de otra vista que corresponde al diagrama de paquetes del proyecto. Tener en cuenta los requisitos del software. Identificar el tipo de diagrama apropiado para modelar el dominio. Diagramar con UML los artefactos del sistema, diagrama de clases y de paquetes. Manejar herramientas de software para apoyar la elaboración de los diagramas. Elaborar documento plantilla de casos de uso con base en estándares de documentación. Lineamientos para la entrega del producto: Producto para entregar: documento del dominio del proyecto. Formato: PDF Extensión: libre. Para hacer el envío de la evidencia, remítase al área de la actividad correspondiente y acceda al espacio: Elaboración de los diagramas del modelo de dominio del proyecto. GA2-220501093AA2-EV01. Criterios de Evaluación: Representa el negocio en términos de clases abstractas, generando un modelo de dominio consistente. Lista de chequeo: 1. 2. 3. 4. Identifica el tipo de diagrama apropiado para modelar el dominio. Diagrama con UML los artefactos del sistema diagrama de clases y de paquetes. Maneja herramientas de software para apoyar la elaboración de los diagramas. Elabora documento plantilla de casos de uso con base en estándares de documentación. 5. Sigue las instrucciones para la elaboración de un diagrama de dominio del proyecto y el modelo conceptual resultante se presenta ordenado y de fácil lectura. Página 4 de 9 lOMoARcPSD|9132568 DESARROLLO DE LA ACTIVIDAD Diagrama de clases En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones, y las relaciones entre los objetos. Página 5 de 9 Multiplicidad La multiplicidad de una asociación determina cuántos objetos de cada tipo intervienen en la relación: El número de instancias de una clase que se relacionan con UNA instancia de la otra clase. - Cada asociación tiene dos multiplicidades (una para cada extremo de la relación). - Para especificar la multiplicidad de una asociación hay que indicar la multiplicidad mínima y la multiplicidad máxima (mínima..máxima) Cada asociación tiene dos multiplicidades (una para cada extremo de la relación).Para especificar hay que indicar que la multiplicidad mínima y máxima (mínima...máxima). Cuando la multiplicidad mínima es 0, la relación es opcional Una multiplicidad mínima mayor igual que 1 establece una relación obligatoria. Página 6 de 9 Diagrama de dominio Los diagramas de dominio se utilizan para analizar orientado a objetos. Si bien los casos de uso son un elemento importante en el análisis de requisitos, no son orientados a objetos. Para orientarnos a objetos, necesitamos modelar entidades, cómo ? Necesitamos acompañar el caso de uso con un diagrama de dominio. Definir el nombre de cada entidad Las entidades se crean con un elemento de tipo clase. Añadir las asociaciones necesarias entre las entidades Es más importante encontrar las entidades que las asociaciones entre entidades. La mayoría del tiempo dedicado a la creación del diagrama de dominio debería emplearse en la identificación de las entidades, y no en las asociaciones. Una asociación es una relación entre entidades que indica alguna conexión significativa e interesante. En un diagrama de dominio con una determinada cantidad de entidades, puede ocurrir que haya muchas relaciones entre las diferentes entidades. No es conveniente dibujar todas las relaciones posibles, eso genera mucho “ruido” en la interpretación del dominio. Una buena práctica es repasar el proceso que se describe en el caso de uso y solo mostrar las relaciones que se necesitan en el proceso. Es importante, particularmente en esta etapa, tener en claro qué es una entidad, para evitar querer crear entidades a partir de tablas del modelo de datos. Recordemos que las entidades no son una representación del modelo de datos! Las asociaciones se representan con una línea entre entidades y con un nombre de asociación: A diferencia de los diagramas de diseño, en el análisis, las asociaciones entre entidades son bidireccionales, opcionalmente se puede utilizar una “flecha de dirección de lectura” que no tiene significado en términos del modelo, sólo es una ayuda para el lector del diagrama. Si la “flecha de dirección de lectura” no está presente, existe una convención de leer la asociación de izquierda a derecha o de arriba hacia abajo. Definir los atributos de las entidades Teniendo entonces ya las entidades con sus nombres, podremos incorporarle los atributos que contendrán. Al igual que con las relaciones, resulta útil identificar aquellos atributos necesarios para satisfacer los requisitos del escenario que se está analizando. Un atributo no debería ser un concepto complejo sino que deberían ser cosas simples o tipos de datos. Por ejemplo: fecha, hora, número, color, número, código, descripción, cantidad. Cuando algo está compuesto de más de un elemento, da la idea de estar frente a una entidad y no un atributo. Por ejemplo, la dirección puede resultar un concepto simple pero en realidad está formada por calle, altura, etc. Si una entidad puede tener muchos valores simultáneos para un mismo atributo, ese atributo debería ser otra entidad. Por ejemplo, una persona puede tener muchos números de teléfono, entonces número de teléfono es una entidad con una asociación de 1 a muchos con la persona. Una regla importante a tener en cuenta es relacionar las entidades con una asociación y no a través de un atributo. No existe un único diagrama de dominio correcto, todos serán una aproximación del dominio que estamos intentando entender. Un buen diagrama captura las abstracciones y da la información necesaria para entender el contexto Página 7 de 9 Entidades de especialización En algunas situaciones, nos ha resultado una práctica sumamente útil identificar una entidad que represente un concepto de modo general y luego identificar entidades de ese concepto de modo especializado. Veamos un ejemplo: Esta jerarquía se la conoce con el nombre de generalización-especialización, o simplemente jerarquía de clases en la cual, la superclase representa un concepto más general y la subclase conceptos más especializados. La subclase conceptual es un tipo de la superclase. Nos conviene identificar estas especializaciones cuando nos vamos a referir a ellas, entonces teniéndolas identificadas gráficamente ayuda a comprenderlas y reducir información repetida. La relación de generalización se representa con una línea que termina con un triángulo grande en el extremo que apunta a la entidad más general. Diagramas UML para entidades El diagrama de dominio no puede faltar al momento de modelar las entidades y se puede graficar mediante un diagrama de clases. La regla general puede ser hacer un diagrama de dominio para cada caso de uso. Si bien parecen situaciones donde un caso de uso no cuenta con demasiado manejo de entidades y se vale de otros casos de uso para describir una funcionalidad, entonces la tendencia es englobar en un único diagrama de dominio esa funcionalidad. Por ejemplo, la funcionalidad para especificar las condiciones comerciales de un cliente está escrita en más un caso de uso y entonces conviene hacer un único diagrama de dominio que muestre las entidades que hacen a las condiciones comerciales del cliente. La cantidad de entidades puede llegar a ser lo suficientemente amplia para que sea conveniente dividirlas en paquetes que incluyan conceptos fuertemente relacionados. Esto ayuda para mejorar la comprensión y para abordar el trabajo de análisis en paralelo, donde cada analista genera el diagrama de dominio que acompañara al caso de uso. Al empaquetar las entidades, el diagrama de dominio mostrará el intercambio que hay entre los diferentes paquetes. Veamos en el ejemplo como se visualiza la relación de la factura de venta con los planes: Como siempre, el objetivo de estos diagramas es servir como una herramienta para entender al sistema. Si el diagrama no resulta claro, no estaremos cumpliendo con uno de los motivos por el cual estamos modelando. Es una buena práctica discutir los diagramas entre analistas que estén haciendo la tarea y los mismos diseñadores que tomen estos diagramas como puerta de entrada. Página 8 de 9 lOMoARcPSD|9132568 Diagrama de paquetes Un diagrama de paquetes en el Lenguaje Unificado de Modelado representa las dependencias entre los paquetes que componen un modelo. Es decir, muestra cómo un sistema está dividido en agrupaciones lógicas y las dependencias entre esas agrupaciones. Página 9 de 9
