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
0
