introducciones del tema complementadas por los alumnos del I.E.S.T.P "24 DE JULIO" - ZARUMILLA. ESPERO LES SIRVA DE GRAN AYUDA PARA AMPLIAR SUS CONOCIMIENTOS E INVESTIGACIONES REFERENTE A SUS ESTUDIOS.

2. 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.

4.  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.

5.  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.
• CLASES
ES
 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.

6. ATRIBUTOS
 Mostrar sólo tipos primitivos relativamente
 “simples” como atributos.
 Las conexiones a otros conceptos se
 representarán como asociaciones, no como
 atributos.

7. 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.

8. 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.

9.  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.

11.  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.

12.  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.

13.  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.

14.  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>>.

15.  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>>.

16.  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á.

17.  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.

18.  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.

19. 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: