DIAGRAMA DE DOMINIO

El modelo del dominio del problema define un modelo de clases común para todos los involucrados en el modelo de requisitos, analistas al igual que clientes.

clases consiste de los objetos del dominio del problema, o sea objetos que tienen una correspondencia directa en el área de la aplicación. Como los usuarios y clientes deberían reconocer todos los conceptos, se puede desarrollar una terminología común al razonar sobre los casos de uso, y por lo tanto disminuyendo la probabilidad de malos entendimientos entre el analista y el usuario. Al discutirlo, se evolucionará el modelo del dominio del problema.

•Una técnica utilizada cuando se trabaja con tal modelo es darle al cliente un papel y un lápiz y pedirle que dibuje su visión del sistema.

DIAGRAMA DE DOMINIO

Modelo de Dominio

Sintaxis del Modelo de Dominio Luego de que la lista de conceptos está completo debería hacerse un

modelo de dominio. Considere que los items simples deberían ser atributos de los objetos. El modelo de dominio es un modelo estático. El flujo del tiempo, con secuencias de eventos o flujo de información no son mostrados en el modelo de dominio. Evite mostrar relaciones procedimentales. Este modelo no incluye software. Los objetos en el modelo de dominio son candidatos para objetos de programación.

Descripción del modelo del dominio. Un modelo del domino captura los tipos más importantes de objetos en el

contexto del sistema. Los objetos del dominio representan las "cosas" que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los objetos del dominio o clases pueden obtenerse de una especificación de requisitos o mediante la entrevista con los expertos del dominio. [17]

El objetivo del modelado del dominio es comprender y describir las clases más importantes dentro del contexto del sistema.

Para una mayor comprensión del contexto en que se desarrolla el sistema se definen los principales conceptos relacionados con el entorno del problema.

CUANDO HACER MODELO DE DOMINIO O CONCEPTUAL

Sino se logra lo planteado en el modelo del negocio entonces identifico conceptos, se le da definiciones a estos conceptos y se trata de unir o relacionar en otro modelo distinto que es el de dominio. Este modelo permitirá mostrar de manera visual los principales conceptos que se manejan, ayudando a los usuarios, desarrolladores e interesados; a utilizar un vocabulario común para poder entender el contexto en que se desarrolla el sistema. Además contribuirá a identificar personas, eventos, transacciones y objetos involucrados en el sistema.

• CLASESES

Se obtienen de la base de del conocimiento de unos pocos expertos del dominio o posiblemente del conocimiento de asociado con sistemas similares al que estamos desarrollando.

Las clases tienen atributos pero normalmente ninguna o muy pocas operaciones. Puede hacer la traza de las clases hasta la experiencia de los expertos del

dominio. No hay forma evidente de hacer la traza entre el modelo de dominio y los casos de usos del sistema.

ATRIBUTOS

Mostrar sólo tipos primitivos relativamente

“simples” como atributos. Las conexiones a otros conceptos se representarán como asociaciones, no

como atributos.

VENTAJAS

Describe y limita el alcance del dominio del problema.

El modelo de dominio puede ser usado efectivamente para verificar y validar la comprensión del dominio del problema entre las diversas partes interesadas.

Define un vocabulario y es útil como herramienta de comunicación.

Puede añadir precisión y enfoque para la discusión entre el equipo de negocios, así como entre los equipos técnicos y de negocios.

Definición de las clases del modelo de dominio

EXPORTADOR: Usuario que posee privilegios para exportar un curso. Administrador: Usuario que posee privilegios para exportar un curso y configurar el bloque C2E-Book Moodle: Sistema de Gestión de Aprendizaje, donde el Exportador puede acceder al bloque C2E-Book para exportar cursos a formato de libro electrónico interactivo.

CURSO: Conjunto de contenidos referentes a una materia.

BLOQUE C2E-BOOK: Herramienta que permitirá exportar un curso de la plataforma de teleformación Moodle a formato de libro electrónico interactivo.

PAQUETE EPUB: Conjunto de ficheros (empaquetados) que componen el formato de libro electrónico interactivo EPUB.

ACTIVIDADES: Constituye la parte activa y colaborativa de un curso donde el estudiante tiene que hacer algo más que leer un texto. Debates y discusiones, resolución de problemas propuestos, redacción de trabajos, talleres, cuestionarios en línea, entre otros.

RECURSOS: Representa los contenidos y materiales del curso. Son todo tipo de textos, libros, apuntes, presentaciones de diapositivas, enlaces a páginas web externas entre otros, pensados para que los estudiantes los lean y estudien sobre ellos.

Clase de objeto • Agrupa un conjunto de objetos por tener: – las mismas propiedades – un mismo comportamiento – la misma relación con otros objetos – una misma semántica • Abstracción: – Ocultación de los detalles/características menos importantes para poder observar aspectos comunes • Los objetos de una clase tienen las mismas propiedades y los mismos patrones de comportamiento

Definición de los objetos y los conceptos principales En el modelo de dominio se definen las siguientes clases principales: Profesor,

Estudiante, Asignatura, Software Educativo. Profesor: Usuario interesado en obtener del sistema el desempeño del

estudiante en el SE. Estudiante: Es el usuario que utiliza el SE y se registra su comportamiento en el

sistema para ser analizado por el profesor. Asignatura: Materia que imparte un profesor a un grupo de estudiantes. Software Educativo: Herramienta que utiliza el profesor como complemento

educativo de la asignatura.

CASOS

DE USO

CASOS DE US0

Escriben en forma de acciones y reacciones el comportamiento del sistema, estudiado desde el punto de vista del usuario.

Definen los límites del sistema y sus relaciones con el entorno.

Explicitan los requisitos funcionales del sistema relativos a uno de los objetivos del usuario. Éstos se denominan también, de manera más precisa, casos de uso con objetivo usuario.

Por ejemplo, en un sistema que gestione las mercancías de una tienda, la compra de un producto constituye un caso de uso.

Actor Un usuario externo al sistema puede desempeñar diferentes funciones en

relación con el sistema. Una pareja (usuario, función) constituye un actor específico designado en UML únicamente por el nombre de la función.

Se diferencian dos categorías de actores: Los actores primarios son los que inician el caso de uso. Los actores secundarios son los que participan en el caso de uso.

Escenario Un escenario es una instancia de un caso de uso en la cual se fijan todas

las condiciones relativas a los diferentes eventos. A un caso de uso determinado corresponden varios escenarios. Ejemplos de diferentes escenarios para el caso de uso “Llevarse libro” de

una biblioteca serían: Escenario 1: Pedro se lleva el ejemplar “Los pilares de la tierra”. Escenario 2: María intenta llevarse el ejemplar “Drácula” pero no puede ya

que ha superado el límite de 3 préstamos simultáneos.

RELACIÓN DE COMUNICACIÓN La relación que vincula a un actor con un caso de uso se denomina

relación de comunicación. Esta relación da soporte a diferentes modelos de comunicación, por ejemplo:

Los servicios que el sistema debe suministrar a cada uno de los actores del caso de uso.

Las informaciones del sistema que un actor puede introducir, consultar o modificar.

Los cambios que intervienen en el entorno, de los cuales un actor informa al sistema.

Los cambios que intervienen dentro del sistema, de los cuales el sistema informa a un actor.

Diagrama de casos de uso El diagrama de casos de uso muestra los casos de uso representados en

forma de elipses y a los actores en forma de personajes. También indica las relaciones de comunicación que los vincula.

El sistema que responde al caso de uso puede representarse mediante un rectángulo en cuyo interior aparece el caso.

Relaciones entre los casos de uso: relación de inclusión La relación de inclusión sirve para enriquecer un caso de uso con otro. El caso de uso

incluido existe únicamente con ese propósito, ya que no responde a un objetivo de un actor primario. Estos casos de uso son subfunciones.

La inclusión sirve para compartir una funcionalidad común entre varios casos de uso. También puede emplearse para estructurar un caso de uso describiendo sus subfunciones.

En el diagrama de casos de uso estas relaciones se representan mediante una flecha discontinua acompañada del estereotipo <<include>>.

RELACIONES ENTRE LOS CASOS DE USO: RELACIÓN DE EXTENSIÓN

Al igual que la relación de inclusión, la relación de extensión enriquece un caso de uso mediante un caso de uso subfunción. El enriquecimiento es análogo al de la relación de inclusión, no obstante, es opcional.

Como ocurre con la inclusión, la extensión sirve para estructurar un caso de uso o para compartir un caso de uso de subfunción.

En el diagrama de casos de uso, esta relación se representa mediante una flecha discontinua acompañada del estereotipo <<extend>>.

ESPECIALIZACIÓN Y GENERALIZACIÓN DE LOS CASOS DE USO

Como vimos en el diagrama de clases, también es posible especializar un caso de uso en otro. Obtenemos así un subcaso de uso.

Al igual que ocurría con las clases, el subcaso hereda el comportamiento y las relaciones de comunicación, inclusión y extensión del supercaso de uso.

Muchas veces el supercaso de uso es abstracto, es decir, corresponde a un comportamiento parcial completado en el subcaso de uso.

En el diagrama de casos de uso la relación de especialización se representa mediante una flecha de especialización idéntica a la que une las subclases con las superclases. El nombre de los casos de uso abstractos se escribe en cursiva, o se acompaña del estereotipo <<abstract>>.

Los subcasos de uso tienen el mismo nivel que sus supercasos. Si el supercaso es una subfunción, el subcaso también lo será.

Representación textual de los casos de uso

La representación textual de los casos de uso no se especifica en UML, no obstante se utiliza habitualmente. Es una especificación en la que se usa el lenguaje natural del autor. Hay dos tipos de especificaciones: la de alto nivel y la expandida.

Representación de alto nivel

Se trata de realizar una descripción breve de las acciones del caso de uso. Esta representación tiene las siguientes partes:

Caso de uso: nombre del caso de uso. Actores: lista de actores, iniciador. Propósito: objetivo del caso de uso. Resumen: Descripción breve de las actividades que se deben llevar a cabo. Tipo: 1 – Primario, secundario, opcional 2 – Real o esencial.

Los tipos de caso de uso son los siguientes:

Primario: estos casos de uso representan los procesos comunes más importantes. Secundario: representan procesos menores o raros. Opcionales: representan procesos que pueden no abordarse. Real: describe concretamente el proceso a partir de su diseño concreto actual,

sujeto a las tecnologías específicas de entrada, salida, etc. Esencial: son casos expandidos que se expresan en forma teórica y que contiene

poca tecnología y pocos detalles de implementación. Las decisiones de diseño se posponen y se abstraen de la realidad. Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción.

Representación expandida

Se trata de realizar una descripción detallada de las acciones y los requisitos. Añade a la especificación de alto nivel las siguientes partes:

Referencias cruzadas: requisitos a los que hace referencia. Curso típico de acontecimientos: descripción detallada de la interacción

(conversación) entre los actores y el sistema. Descripción de los acontecimientos paso a paso.

Cursos alternativos: describe excepciones al curso típico.

Representación expandida

Se trata de realizar una descripción detallada de las acciones y los requisitos. Añade a la especificación de alto nivel las siguientes partes:

Modelado de negocio

Ejemplo de un sistema de transporte