Carrera: Ingeniería en sistemas computacionales.

Materia: Fundamentos de ingeniería de software.

Profesora: Ing. María Nancy García Castro.

Tema:
Trabajo de investigación sobre la unidad Unidad IV
Modelo de Análisis :
4.1.Clases. 4.2. Objetos. 4.3. Modelo de requisitos. 4.4. Modelo de casos de uso. 4.5.
Modelo de dominio. (50%).

Equipo numero 6

Integrantes del equipo: Rodríguez Chávez Jonathan Dylan,

NºControl: 21321180.

Horario: 2:00 a 3:00pm.

Aula: 705.

Fecha de entrega: Martes/12/Diciembre/2023

(ciclo escolar agosto – diciembre 2023)

Contenido
INTRODUCCION..............................................................................3
MODELO DE ANÁLISIS..................................................................5
4.1.Clases.........................................................................................12
4.2. Objetos......................................................................................16
4.3. Modelo de requisitos...............................................................19
4.4. Modelo de casos de uso...........................................................21
4.5. Modelo de dominio..................................................................25
CONCLUSION...............................................................................28
 INTRODUCCION
En el vasto campo de la ingeniería de software, el Modelo de Análisis
desempeña un papel fundamental en el desarrollo de sistemas y aplicaciones
robustas y eficientes. Este modelo proporciona una representación estructurada
y detallada de los componentes esenciales de un sistema, centrándose en
aspectos clave como las clases, los objetos, los requisitos, los casos de uso y el
dominio.

Dentro del Modelo de Análisis, las clases juegan un papel fundamental al

identificar y definir las entidades principales que componen el sistema. Estas
clases representan conceptos o abstracciones del dominio del problema y
encapsulan tanto los datos como los comportamientos asociados a ellos. Al
establecer las relaciones entre las diferentes clases, se logra una comprensión
clara de cómo interactúan y se comunican entre sí.

A su vez, los objetos son instancias concretas de las clases mencionadas

anteriormente. Cada objeto posee un estado interno definido por sus atributos y
puede realizar acciones específicas mediante sus métodos. Estos objetos
interactúan entre sí a través de mensajes, lo que permite una comunicación
fluida y una colaboración efectiva en el sistema.

El Modelo de Requisitos se enfoca en identificar y documentar las necesidades y

metas del sistema desde la perspectiva de los usuarios y las partes interesadas.
Aquí se definen los requisitos funcionales y no funcionales, estableciendo los
objetivos que el sistema debe cumplir, las restricciones que deben respetarse y
los escenarios de uso que deben considerarse. Este modelo proporciona una base
sólida para el diseño y la implementación del sistema, asegurando que las
necesidades de los usuarios se aborden de manera efectiva.

Además, el Modelo de Casos de Uso es una técnica ampliamente utilizada para

capturar y describir las interacciones entre los actores (usuarios y sistemas
externos) y el sistema en cuestión. Los casos de uso representan las diferentes
funcionalidades que el sistema debe proporcionar y describen los pasos y las
acciones necesarias para lograr resultados específicos. Este modelo facilita la
comprensión de cómo los usuarios interactúan con el sistema y cómo este
responde a sus solicitudes.

Por último, el Modelo de Dominio se enfoca en comprender y representar el

contexto y el conocimiento específico del dominio en el que se encuentra el
sistema. Esto implica identificar y definir los conceptos clave, las reglas y las
relaciones que existen dentro del dominio. Al desarrollar un modelo de dominio
claro y completo, se logra una comprensión profunda de las entidades y los
procesos involucrados, lo que facilita la toma de decisiones en el diseño y la
implementación del sistema.

El Modelo de Análisis en ingeniería de software proporciona una estructura y

una representación detallada de las clases, los objetos, los requisitos, los casos
de uso y el dominio de un sistema. Sirve como base para el diseño y la
implementación exitosa de sistemas y aplicaciones, permitiendo una
comprensión clara de las interacciones y los comportamientos necesarios para
lograr los objetivos establecidos. Al emplear este modelo, los ingenieros de
software pueden desarrollar soluciones efectivas y eficientes que satisfagan las
necesidades de los usuarios y las partes interesadas.
 MODELO DE ANÁLISIS.
El modelo de análisis describe la estructura del sistema o aplicación que está
modelando. Consta de diagramas de clase y de diagramas de secuencia que
describe la implementación lógica de los requisitos funcionales identificados en
el modelo de caso de uso.
El modelo de análisis identifica las clases principales del sistema y contiene un
conjunto de realizaciones de casos de uso que describen cómo se construirá el
sistema. Los diagramas de clase describen la estructura estática del sistema
utilizando estereotipos para modelar los componentes funcionales del sistema.
Los diagramas de secuencia realizan los casos de uso describiendo el flujo de
eventos en los casos de uso cuando se ejecutan. Estas realizaciones de casos de
uso modelan la forma en que los componentes del sistema interactúan dentro del
contexto de un caso de uso específico.
Puede pensar en el modelo de análisis como la fundación del modelo de diseño
ya que describe la estructura lógica del sistema pero no su implementación.

Análisis de requisitos
El análisis de requisitos le proporciona al diseñador de software una
representación de datos, función y comportamiento que puede trasladar a
diseños arquitectónicos de interfaz. Este, junto al modelo de análisis, ofrece al
desarrollador y al cliente los medios para evaluar la calidad una vez construido
el software.

Objetivos generales del modelo de análisis

El modelo de análisis debe cumplir tres objetivos primarios:
1. Describir los que requiere el cliente
2. Establecer una base para la creación de un diseño de software
3. Definir un conjunto de requisitos que pueda validarse una vez construido
el software.
ELEMENTOS DEL MODELO DE ANÁLISIS

El
modelo de análisis se complementa de cuatro elementos fundamentales. Estos
elementos sirven para clasificar principalmente los diferentes diagramas y otros
derivados conocidos en plataformas como sistemas de información e ingeniería
de software entre otros. Además estos con clasificados en elementos de
escenario, elementos de flujo, elementos de clases y elementos de
comportamiento.

MODELOS BASADOS EN ESCENARIOS

Este modelo en simples palabras sirve para una interacción más amena entre el
sistema y el usuario, por lo tanto el modelo de análisis con UML comienza con
la creación de escenarios en la forma de “los casos de uso, diagrama de
actividad y diagrama de carril”.
 Caso de uso: Describe un escenario de un caso específico en un lenguaje
directo desde el punto de vista de un actor definido.

 Diagrama de actividad: es un modelo muy parecido al caso de uso pero

mucho mejor complementado y proporciona una representación del flujo
de interacción dentro de un escenario específico.

 Diagrama de carril:
Consiste en tomar el diagrama actividad y situarlo en filas o en carriles.
En este modelo los actores son fundamentales ya que en el diagrama de
carril se especifica claramente, con un carril, la responsabilidad a cada
actor.
 MODELOS ORIENTADOS AL FLUJO

Tiene una visión del sistema del tipo entrada-proceso-salida. Los objetos de
datos fluyen hacia el interior del software, se transforman mediante elementos
de procesamiento y los objetos de datos resultantes fluyen al exterior del
software.

Diagrama de flujo de datos

Propiedades del DFD

1. El nivel 0 del diagrama del flujo debe representar al software.
2. La entrada y la salida primaria se deben establecer con cuidado.
3. La refinación debe comenzar por el aislamiento de procesos, objetos
de datos y almacenamiento de datos candidatos a ser representados en
el siguiente nivel.
4. Toda las flechas y burbujas se deben rotular con el nombre.
5. Se debe tener la continuidad de flujo al cambiar el nivel.
6. La refinación de burbujas debe hacerse una por una.

Este diagrama es orientado al

tiempo y rendimiento . Cada
elemento o evento de control
se puede implementar con
valores V o F, 1 ó 0 o
tambien otros similares.
MODELOS BASADOS EN CLASES

Una clase orientada a objetos encapsula atributos de los datos pero también
incorpora las operaciones que manipulan los datos implicados por dichos
atributos. Las clases se manifiestan en la siguiente forma: entidades externas,
sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y
estructuras.

Modelo CRC (clase-responsabilidad-colaborador)

El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un

medio simple para identificar y organizar las clases relevantes para los requisitos
del sistema o producto. Un modelo CRC es una colección de tarjetas índices
estándar que representan clases. El objeto es desarrollar una representación
organizada de las clases.
Clases: tienen diferentes categorías:
 Clases de entidad: llamadas clases de modelo o negocios, se extraen de
manera directa del enunciado del problema.
 Clases de frontera: se utilizan para crear la interfaz que el usuario ve y
con la cual interactúa cuando se utiliza el software.
 Clases de controlador: manejan una “unidad de trabajo” desde el inicio
hasta el final.
 Responsabilidad: son los atributos y las operaciones relevantes para la
clase.
 Colaboradores: son aquellas clases que se requieren para que una clase
reciba la información necesaria para completar una responsabilidad.
 Agregación: son las subclases que forman parte de una clase, se conectan
a través de una relación de tipo » es parte de».

MODELOS DE COMPORTAMIENTO

El modelo de comportamiento indica la forma en que el software responderá a

los eventos o estímulos externos.

Diagrama de estado: representa el comportamiento de las clases cuando el

sistema
Diagrama de Secuencia: representa el comportamiento al describir la forma en
que las clases se mueven de estado a estado.
4.1.Clases.
Diagrama de clases: En ingeniería de software, un diagrama de
clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de
estructura estática que describe la estructura de un sistema mostrando las clases
del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los
objetos.
Miembros
UML proporciona mecanismos para representar los miembros de la clase, como
atributos y métodos, así como información adicional sobre ellos.
Visibilidad
Para especificar la visibilidad de un miembro de la clase (es decir, cualquier
atributo o método), se coloca uno de los siguientes signos delante de ese
miembro:
Un ejemplo de las clases con su respectivo modelo UML.
 Ejemplo de diagrama de clases de una Universidad.

Ámbitos
UML especifica dos tipos de ámbitos para los
miembros: instancias y clasificadores y estos últimos se representan
con nombres subrayados.
· Los miembros clasificadores se denotan comúnmente como “estáticos”
en muchos lenguajes de programación. Su ámbito es la propia clase.
· Los valores de los atributos son los mismos en todas las instancias
· La invocación de métodos no afecta al estado de las instancias
· Los miembros instancias tienen como ámbito una instancia específica.
· Los valores de los atributos pueden variar entre instancias
· La invocación de métodos puede afectar al estado de las instancias(es
decir, cambiar el valor de sus atributos)
Para indicar que un miembro posee un ámbito de clasificador, hay que subrayar
su nombre. De lo contrario, se asume por defecto que tendrá ámbito de
instancia.
Relaciones
Una relación es un término general que abarca los tipos específicos de
conexiones lógicas que se pueden encontrar en los diagramas de clases y
objetos. UML presenta las siguientes relaciones:

Relaciones a nivel de instancia

Enlace
Un enlace es la relación más básica entre objetos.

Asociación

Ejemplo de diagrama de clases con una asociación de dos clases (en

inglés)

Una asociación representa a una familia de enlaces. Una asociación binaria

(entre dos clases) normalmente se representa con una línea continua. Una misma
asociación puede relacionar cualquier número de clases. Una asociación que
relacione tres clases se llama asociación ternaria.
A una asociación se le puede asignar un nombre, y en sus extremos se puede
hacer indicaciones, como el rol que desempeña la asociación, los nombres de las
clases relacionadas, su multiplicidad, su visibilidad, y otras propiedades.
Hay cuatro tipos diferentes de asociación: bidireccional, unidireccional,
agregación (en la que se incluye la composición) y reflexiva. Las asociaciones
unidireccional y bidireccional son las más comunes.
Por ejemplo, una clase vuelo se asocia con una clase avión de forma
bidireccional. La asociación representa la relación estática que comparten los
objetos de ambas clases.

Agregación

Ejemplo de diagrama de clases con una agregación entre dos clases (en
inglés)
La agregación es una variante de la relación de asociación “tiene un”: la
agregación es más específica que la asociación. Se trata de una asociación que
representa una relación de tipo parte-todo o parte-de.
Como se puede ver en la imagen del ejemplo (en inglés), un Profesor 'tiene una'
clase a la que enseña.
Al ser un tipo de asociación, una agregación puede tener un nombre y las
mismas indicaciones en los extremos de la línea. Sin embargo, una agregación
no puede incluir más de dos clases; debe ser una asociación binaria.
Una agregación se puede dar cuando una clase es una colección o un contenedor
de otras clases, pero a su vez, el tiempo de vida de las clases contenidas no
tienen una dependencia fuerte del tiempo de vida de la clase contenedora
(del todo). Es decir, el contenido de la clase contenedora no se destruye
automáticamente cuando desaparece dicha clase.

En UML, se representa gráficamente con un rombo hueco junto a la clase

contenedora con una línea que lo conecta a la clase contenida. Todo este
conjunto es, semánticamente, un objeto extendido que es tratado como una única
unidad en muchas operaciones, aunque físicamente está hecho de varios objetos
más pequeños..
Diagramas
· El diagrama de clases puede tener como ejemplo: una clase que sería un
objeto o persona misma en la cual se especifica cada acción y especificación.
· Propiedades de objetos que tienen propiedades y/u operaciones que
contienen un contexto y un dominio, los primeros dos ejemplos son clases de
datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el
sistema se pueden unir los datos con las operaciones.
· El diagrama de clases incluye mucha más información como la relación
entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de
operaciones/propiedades que son implementadas para una interfaz gráfica.
· Presenta las clases del sistema con sus relaciones estructurales y de
herencia.

· El diagrama de clases es la base para elaborar una arquitectura MVC o

MVP.

4.2. Objetos.
¿Qué es un diagrama de objetos en UML?
Un diagrama de objetos UML representa una instancia específica de un
diagrama de clases en un determinado momento en el tiempo. Cuando se lo
representa gráficamente, verás muchas similitudes con el diagrama de clases.
Usamos el mismo ejemplo de clase de coche de la página de diagramas de clases
para ilustrar los diagramas de objetos. Nuestra biblioteca de figuras UML puede
ayudarte a diseñar cualquier diagrama de objetos personalizado por medio de
nuestra herramienta UML en línea.

Ejemplo de diagrama de
objetos
Ejemplo de diagrama de clases

Un diagrama de objetos se enfoca en los atributos de un conjunto de objetos y

cómo esos objetos se relacionan entre sí. Por ejemplo, en el siguiente diagrama
de objetos, las tres cuentas bancarias están ligadas al banco mismo. Los títulos
de clase muestran el tipo de cuentas (ahorros, corriente y tarjeta de crédito) que
un cliente dado podría tener con este banco en particular. Los atributos de
clase son diferentes para cada tipo de cuenta. Esto se ilustra por el hecho de que
el objeto de tarjeta de crédito tiene un límite de crédito, mientras que las cuentas
de ahorros y corriente tienen tasas de interés.
El diagrama de objetos no está limitado a casos de uso bancario. Puedes crear un
diagrama de objetos para árboles genealógicos, departamentos corporativos, es
decir, cualquier sistema con partes interrelacionadas.

Aplicaciones de los diagramas de objetos

Hay muchos casos en los que a un desarrollador le resultarían útiles los
diagramas de objetos. Dichos casos incluyen:
o Revisión de una iteración específica de un sistema general.
o Obtención de una vista de nivel alto del sistema que desarrollarás.
o Prueba de un diagrama de clases que creaste para la estructura
general del sistema, por medio de diagramas de objetos para casos
de uso específicos.

Elementos de los diagramas de objetos

Los diagramas de objetos son sencillos de crear: se componen de objetos,
representados por rectángulos, conectados mediante líneas. Estos son los
elementos principales de un diagrama de objetos:
 Objetos - son instancias de una clase. Si un coche es una clase, un Altima
2007 de Nissan es un objeto de una clase. Los objetos en la clase "Padres"
son tus padres específicos, por ejemplo, Elaine y Gary.
 Títulos de clases - los atributos específicos de la clase. En el diagrama de
objetos de árbol genealógico, se trata del nombre, género y edad de los
integrantes de la familia. Se pueden enumerar como elementos en el
objeto o incluso en las propiedades del propio objeto (p. ej., color).
  Atributos de clases - un rectángulo con dos pestañas que indica un
elemento de software.
 Enlaces - se trata de las líneas que conectan un objeto con otro. El
diagrama de objetos corporativo siguiente muestra cómo los
departamentos están conectados en un estilo de organigrama tradicional.

Otros ejemplos de diagramas de objetos UML

Las especificaciones UML realmente no cambian cuando describimos un
diagrama de objetos en diferentes lenguajes de programación. La idea de
UML es que podamos planificar software independientemente de las
plataformas específicas. A continuación se encuentran los tipos de
diagramas de objetos más comúnmente buscados en diferentes lenguajes
de programación.
Diagrama de objetos en Objective C
Objective C se ha vuelto muy popular desde el lanzamiento de "Objective
C 2.0" de Apple, y ahora es el lenguaje de programación preferido para
las aplicaciones de la tienda virtual de Apple. Alguien que busque un
diagrama de objetos en Objective C probablemente esté intentando
mostrar instancias de una aplicación de iPhone.
Diagrama de objetos en Java
Este término requiere un poco de desambiguación. Hay diagramas de
objetos que se pueden usar en UML para describir instancias que se
pueden programar en Java en última instancia. También existen
diagramas que describen objetos Java que no tienen nada que ver con
UML. Ya sea que busques los primeros o los últimos, Lucidchart puede
ayudar a trazar la estructura que necesitas crear.
4.3. Modelo de requisitos.

Definición: Requisito

Una condición o necesidad de un usuario para resolver un problema o

alcanzar un objetivo.

Una condición o capacidad que debe estar presente en un sistema o

componentes de sistema para satisfacer un contrato, estándar, especificación u
otro documento formal.

Ingeniería de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente o
usuario para un sistema es llamado ingeniería de requerimientos. La meta de la
ingeniería de requerimientos (IR) es entregar una especificación de requisitos de
software correcta y completa.

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de

requisitos o Ingeniería de requerimientos comprende todas las tareas
relacionadas con la determinación de las necesidades o de las condiciones a
satisfacer para un software nuevo o modificado, tomando en cuenta los diversos
requisitos de los inversores, que pueden entrar en conflicto entre ellos.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un

estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los
buenos requisitos deben ser medibles, comprobables, sin ambigüedades o
contradicciones, etc.

La parte más difícil de construir un sistema es precisamente saber qué construir.

Ninguna otra parte del trabajo conceptual es tan difícil como establecer los
requisitos técnicos detallados, incluyendo todas las interfaces con gente,
máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema
si es hecha mal. Ninguna es tan difícil de corregir más adelante. Entonces, la
tarea más importante que el ingeniero de software hace para el cliente es la
extracción iterativa y el refinamiento de los requerimientos del producto.
Tipos de Requerimientos

Los requerimientos de software pueden dividirse en 2 categorías:

requerimientos funcionales y requerimientos no funcionales.

Requerimientos funcionales. Son los que definen las funciones que el sistema
será capaz de realizar, describen las transformaciones que el sistema realiza
sobre las entradas para producir salidas.

Requerimientos no funcionales. Requerimientos no funcionales tienen que ver

con características que de una u otra forma puedan limitar el sistema, como por
ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad,
portabilidad, estándares, etc.

Características de un Requerimiento

Es importante no perder de vista que un requerimiento debe ser:

Especificado por escrito: Como todo contrato o acuerdo entre dos partes.

Posible de probar o verificar. Si un requerimiento no se puede comprobar,

entonces ¿cómo se sabe si se cumplió con él o no?

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su

redacción debe ser simple y clara para aquellos que vayan a consultarlo en un
futuro.

Completo: Un requerimiento está completo si no necesita ampliar detalles en su

redacción, es decir, si se proporciona la información suficiente para su
comprensión.

Consistente: Un requerimiento es consistente si no es contradictorio con otro

requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola

interpretación. El lenguaje usado en su definición, no debe causar confusiones al
lector.
4.4. Modelo de casos de uso.
Un caso de uso es una descripción de los pasos o las actividades que deberán
realizarse para llevar a cabo algún proceso. Los personajes o entidades que
participarán en un caso de uso se denominan actores. En el contexto
de ingeniería del software, un caso de uso es una secuencia de interacciones que
se desarrollarán entre un sistema y sus actores en respuesta a un evento que
inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso
sirven para especificar la comunicación y el comportamiento de un sistema
mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual,
un diagrama que muestra la relación entre los actores y los casos de uso en un
sistema. Una relación es una conexión entre los elementos del modelo, por
ejemplo la especialización y la generalización son relaciones. Los diagramas de
casos de uso se utilizan para ilustrar los requisitos del sistema al mostrar cómo
reacciona a eventos que se producen en su ámbito o en él mismo.
Su uso es común para la captura de requisitos funcionales, especialmente con el
paradigma de la programación orientada a objetos, donde se originaron, si bien
puede utilizarse con resultados igualmente satisfactorios con otros paradigmas
de programación.

Definiciones básicas
Actores.
Se le llama actor a toda entidad externa al sistema que guarda una relación con
éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos
pero también incluye a todos los sistemas externos, además de entidades
abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones
de rol por lo que un mismo individuo puede corresponder a uno o más Actores.
Suele suceder sin embargo, que es el sistema quien va a tener interés en el
tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones
automáticas en determinados momentos; y siendo esto un requisito funcional
obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en
el modelo de caso de uso final.

Tipos de relaciones.
· Comunica (<<communicates>>): Relación (asociación) entre un actor y
un caso de uso que denota la participación del actor en dicho caso de uso.
· Usa (<<uses>>) (o <<include>> en la nueva versión de UML):
Relación de dependencia entre dos casos de uso que denota la inclusión del
comportamiento de un escenario en otro.
· Extiende (<<extends>>): Relación de dependencia entre dos casos de
uso que denota que un caso de uso es una especialización de otro. Por ejemplo,
podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que
permita escoger el tipo de azúcar (normal, dietético o moreno) y además la
cantidad en las unidades adecuadas (cucharadas o bolsas).
Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos
encontramos con un caso de uso similar a otro pero que hace algo más que éste
(variante). Por contra, utilizaremos una relación tipo <<uses>> cuando nos
encontramos con una parte de comportamiento similar en dos casos de uso y no
queremos repetir la descripción de dicho comportamiento común.
En una relación <<extends>>, un actor que lleve a cabo el caso de uso base
puede realizar o no sus extensiones. Mientras, en una relación <<include>> el
actor que realiza el caso de uso base también realiza el caso de uso incluido.
En general utilizaremos <<extends>> cuando se presenta una variación del
comportamiento normal, e <<include>> cuando se repite un comportamiento en
dos casos de uso y queremos evitar dicha repetición.
Por último en un diagrama de casos de uso, además de las relaciones entre casos
de uso y actor (asociaciones) y las dependencias entre casos de uso
(<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea
entre casos de uso o entre actores.
Llamamos modelo de casos de uso a la combinación de casos de uso y sus
correspondientes diagramas. Los modelos de casos de uso se suelen acompañar
por un glosario que describe la terminología utilizada. El glosario y el modelo
de casos de uso son importantes puntos de partida para el desarrollo de los
diagramas de clases.
Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a
diferentes realizaciones, es importante reflejar en cada representación el motivo
que nos ha llevado a descartarla, si es el caso.

Pasos para la Definición de un Caso de Uso:

1. ID
2. NOMBRE
3. REFERENCIAS CRUZADAS
4. CREADO POR
5. ULTIMA ACTUALIZACIÓN POR
6. FECHA DE CREACIÓN
7. FECHA DE ULTIMA ACTUALIZACIÓN
8. ACTORES
9. DESCRIPCIÓN
10.TRIGGER
11.PRE-CONDICIÓN
12.POST-CONDICIÓN
13.FLUJO NORMAL
14.FLUJOS ALTERNATIVOS
15.INCLUDES
16.FRECUENCIA DE USO
17.REGLAS DE NEGOCIO
18.REQUISITOS ESPECIALES
19.NOTAS Y ASUNTO

Normas de aplicación.
Los casos de uso evitan típicamente el lenguaje técnico, prefiriendo la lengua
del usuario final o del experto del campo del saber al que se va a aplicar. Los
casos del uso son a menudo elaborados en colaboración por los analistas de
requisitos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea.
Desde una perspectiva tradicional de la ingeniería de software, un caso de uso
describe una característica del sistema. Para la mayoría de proyectos de
software, esto significa que quizás a veces es necesario especificar decenas o
centenares de casos de uso para definir completamente el nuevo sistema. El
grado de la formalidad de un proyecto particular del software y de la etapa del
proyecto influenciará el nivel del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el
comportamiento del software o de los sistemas. Un caso de uso contiene una
descripción textual de todas las maneras que los actores previstos podrían
trabajar con el software o el sistema. Los casos de uso no describen ninguna
funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se
implementará. Simplemente muestran los pasos que el actor sigue para realizar
una operación.
Un caso de uso debe:
 Describir una tarea del negocio que sirva a una meta de negocio.
 Tener un nivel apropiado del detalle.
 Ser bastante sencillo como que un desarrollador lo elabore en un
único lanzamiento.
Situaciones que pueden darse:
 Un actor se comunica con un caso de uso (si se trata de un
actor primario la comunicación la iniciará el actor, en
cambio si es secundario, el sistema será el que inicie la
comunicación).
 Un caso de uso extiende otro caso de uso.
 Un caso de uso utiliza otro caso de uso.

Ventajas.
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la
intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requisito permite que el analista se centre en las
necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando
que la gente especializada en informática dirija la funcionalidad del nuevo
sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en
las tareas centrales del usuario describiendo por lo tanto los casos de uso que
mayor valor aportan al negocio. Esto facilita luego la priorización del requisito.
Aunque comúnmente se asocian a la fase de Test de una aplicación, esta idea es
errónea, y su uso se extiende mayormente a las primeras fases de un desarrollo.

Limitaciones.
Los casos de uso pueden ser útiles para establecer requisitos de comportamiento,
pero no establecen completamente los requisitos funcionales ni permiten
determinar los requisitos no funcionales. Los casos de uso deben
complementarse con información adicional como reglas de negocio, requisitos
no funcionales, diccionario de datos que complementen los requisitos del
sistema. Sin embargo la ingeniería del funcionamiento especifica que cada caso
crítico del uso debe tener un requisito no funcional centrado en el
funcionamiento asociado.
4.5. Modelo de dominio.

Un modelo de dominio en la resolución de problemas e ingeniería de software,

es un modelo conceptual de todos los temas relacionados con un problema
específico. En él se describen las distintas entidades, sus atributos, papeles y
relaciones, además de las restricciones que rigen el dominio del problema.

Descripción general
El modelo de dominio se crea con el fin de representar el vocabulario y los
conceptos clave del dominio del problema. El modelo de dominio también
identifica las relaciones entre todas las entidades comprendidas en el ámbito del
dominio del problema, y comúnmente identifica sus atributos. Un modelo de
dominio que encapsula los métodos dentro de las entidades se asocia más bien
con modelos orientados a objetos. El modelo de dominio proporciona una visión
estructural del dominio que puede ser complementado con otros puntos de vista
dinámicos, como el modelo de casos de uso.

Cuando se va a desarrollar un software es esencial estudiar y analizar el

problema que se desea resolver. Este problema puede estar enfocado por
ejemplo a la automatización de un proceso de negocio de alguna empresa. El
software a desarrollar seguramente permitirá registrar información que necesite
el proceso de negocio y generar resultados de valor para sus usuarios. También
deberá permitir validar o hacer cumplir muchas reglas de negocio. Por lo tanto,
los ingenieros de software necesitan usar algunas técnicas que les ayuden a
entender mejor la problemática que están analizando antes de iniciar con la
implementación del software.

Una de estas técnicas es elaborar modelos conceptuales que representan los

conceptos y sus relaciones que participan en el contexto de estudio o dominio de
problema. Los conceptos se entienden como las entidades de información que
representan objetos físicos o lógicos del dominio de problema. Para elaborar un
modelo conceptual se usa el diagrama de clases de UML en donde se deben
representar sólo el nombre de las clases y sus atributos junto con las relaciones
entre clases, pero no las operaciones de las clases. El RUP como metodología de
desarrollo de software recomienda el uso de esta técnica y lo define como el
Modelo de Dominio. Por lo tanto, un modelo de dominio es un diagrama de
clases UML que no representa un diseño de software si no un modelo
conceptual.

El modelo de dominio sirve para:

 Identificar y representar conceptos del dominio de problema.
 Establecer y entender las relaciones entre los conceptos.
 Identificar atributos de cada concepto.
 Representar entidades de negocio en el modelado de procesos.
 Apoyar en el análisis de los requisitos.
 Elaborar un diccionario de datos.
 Elaborar un glosario de términos.
 Evolucionar hacia un modelo de diseño y modelo de datos.

Para que el ingeniero de software pueda elaborar un modelo de dominio se

necesita de la colaboración de un experto del dominio. Este experto del dominio
deberá ser alguien que conoce muy bien la problemática que se está analizando
o el proceso de negocio que se desea automatizar. Gracias a la colaboración del
experto del dominio se podrá elaborar buenos modelos conceptuales y
evolucionar hacia un adecuado modelo de diseño que finalmente concluirá con
su implementación del software.

La elaboración del modelo de dominio puede iniciar desde la primera fase del
desarrollo del proyecto y ser refinado durante la fase siguiente. En RUP se
puede trabajar con este modelo en la fase de inicio y la fase de elaboración. En
sí, este modelo debe servir de inspiración para el modelo de diseño en las
primeras fases y no se necesita que se siga actualizando o refinando en todas las
fases. Cuando ya se tenga un modelo de diseño se debe dejar de lado el modelo
de dominio y seguir evolucionado el software sólo con el modelo de diseño.

Por último, se puede aplicar el enfoque Domain Driven Design (DDD) para el
desarrollo de software de dominios complejos y ya en la etapa de diseño e
implementación definir una Arquitectura de software basado en un patrón N-
Capas con orientación al Dominio o también llamado N-Capas DDD.
 Modelo de Dominio de en ejemplo de Farmacia.

CONCLUSION
El Modelo de Análisis en ingeniería de software, que abarca las clases, los
objetos, el modelo de requisitos, el modelo de casos de uso y el modelo de
dominio, desempeña un papel crucial en el desarrollo de sistemas y aplicaciones
de software efectivas y de calidad.
Las clases son entidades fundamentales en el Modelo de Análisis, ya que
representan abstracciones o conceptos del dominio del problema. Estas clases
encapsulan tanto los datos como los comportamientos relacionados,
proporcionando una estructura sólida para el sistema. Al definir las relaciones
entre las clases, se establece una comprensión clara de cómo interactúan y se
comunican entre sí.
Los objetos, por su parte, son instancias concretas de las clases. Cada objeto
tiene su propio estado interno y puede realizar acciones específicas mediante sus
métodos. La interacción entre objetos a través de mensajes facilita la
colaboración y la comunicación efectiva dentro del sistema.
El modelo de requisitos se centra en identificar y documentar las necesidades y
metas del sistema desde la perspectiva de los usuarios y las partes interesadas.
Al definir los requisitos funcionales y no funcionales, se establecen los objetivos
que el sistema debe cumplir y las restricciones que debe respetar. Esto
proporciona una base sólida para el diseño e implementación del sistema,
asegurando que las necesidades de los usuarios se satisfagan de manera efectiva.
El modelo de casos de uso es una técnica ampliamente utilizada para capturar y
describir las interacciones entre los actores y el sistema. Los casos de uso
representan las funcionalidades clave que el sistema debe proporcionar y
describen los pasos necesarios para lograr resultados específicos. Este modelo
facilita la comprensión de cómo lo 1s usuarios interactúan con el sistema y cómo
este responde a sus solicitudes.
Finalmente, el modelo de dominio se enfoca en comprender el contexto y
conocimiento específico del dominio en el que se encuentra el sistema. Esto
implica identificar y definir los conceptos clave, las reglas y las relaciones
dentro del dominio. Al desarrollar un modelo de dominio claro y completo, se
logra una comprensión profunda de las entidades y los procesos involucrados, lo
que facilita la toma de decisiones en el diseño y la implementación del sistema.
En conclusión, el Modelo de Análisis en ingeniería de software es esencial para
el desarrollo exitoso de sistemas y aplicaciones. Al utilizar este modelo, los
1
ingenieros de software pueden comprender y representar de manera efectiva las
clases, los objetos, los requisitos, los casos de uso y el dominio del sistema. Esto
proporciona una base sólida para el diseño, la implementación y el
mantenimiento de sistemas de software robustos y eficientes, que cumplen con
las necesidades y expectativas de los usuarios y las partes interesadas. Al
emplear el Modelo de Análisis, se promueve el desarrollo de soluciones de
software de calidad y exitosas en el mercado.