TECNOLGICO DE ESTUDIOS SUPERIORES DE CHALCO

INGENIERA INFORMTICA

INVESTIGACION PARA EVALUACION DE LA

UNIDAD 4
MATERIA: ANALISIS Y MODELADO DE SISTEMAS DE
INFORMACION
DOCENTE: LUIS GERARDO ALFARO MELENDEZ
ALUMNO: DOLORES VIRIDIANA PADILLA LOPEZ

CHALCO, ESTADO DE MXICO, A 07 DE ENERO DEL 2016.

INDICE

INTRUDUCCIN .............................................................................................................................. 3
4.1 MODELOS DE CASO DE USO ............................................................................................... 4
4.1.1 ACTORES, CASOS DE USO, REQUERIMIENTOS FUNCIONALES Y NO
FUNCIONALES. ........................................................................................................................... 5
4.1.2 PROTOTIPOS PARA CASO DE USO ............................................................................ 6
4.1.3 DOCUMENTACION ........................................................................................................... 7
4.2 MODELO DE INTERFACES .................................................................................................. 12
4.3 MODELO DEL DOMINIO DEL PROBLEMA ....................................................................... 14
4.3.1 IDENTIFICACION DE CLASES .................................................................................... 15
4.3.2 IDENTIFICACION DE ASOCIACIONES....................................................................... 16
4.3.3 IDENTIFICACION DE ATRIBUTOS .............................................................................. 17
4.3.4 DICCIONARIO DE CLASES ........................................................................................... 18
4.3.5 IDENTIFICACION DE MODULOS ................................................................................. 19
CONCLUSIN ................................................................................................................................ 20
REFERENCIAS .............................................................................................................................. 21
APENDICES .................................................................................................................................... 22

INTRUDUCCIN
Algunas de las debilidades de muchos mtodos estn contextualizadas en
etapas tempranas del desarrollo de software. Uno de los problemas derivado de
estas debilidades metodolgicas tiene que ver con la dificultad de determinar si el
modelo conceptual del sistema de software representa fiel y completamente los
requisitos de los usuarios.
Casi siempre estos requisitos son expresados de forma escasamente estructurada
sin establecer ninguna correspondencia entre stos y los elementos del modelo
conceptual. Ms an, generalmente estos mtodos carecen de directrices
adecuadas para el desarrollo de modelos conceptuales derivados de las
especificaciones y posteriormente de cdigo que sea funcionalmente equivalente a
dichos modelos conceptuales.
Como un esfuerzo para la superacin de estas limitaciones, en este trabajo se
presenta un enfoque sistemtico de Ingeniera de Requisitos que define un
proceso que posibilita la descomposicin sistemtica y repetitiva de los requisitos
de software hasta obtener una detallada especificacin que constituir el modelo
conceptual del sistema deseado. Este enfoque pretende mejorar la calidad del
proceso de produccin de software:

Proporcionando predecibilidad mediante la construccin de un modelo

conceptual como una precisa, estructurada y bien definida representacin
de los requisitos de los usuarios.

Aumentando la productividad al establecer vnculos precisos entre el

modelo conceptual y los requisitos de los usuarios. Esto facilitar la
incorporacin en el modelo conceptual de cambios en los requisitos. En
consecuencia, tales modificaciones quedarn reflejadas tambin en el
sistema de software desarrollado.

4.1 MODELOS DE CASO DE USO

El modelo de casos de uso describe la funcionalidad propuesta del nuevo
sistema. Un Caso de Uso representa una unidad discreta de interaccin entre un
usuario (humano o mquina) y el sistema. Un Caso de Uso es una unidad de
trabajo significativo; por ejemplo crear una solicitud y modificar una solicitud son
todos Casos de Uso.
Cada Caso de Uso tiene una descripcin que especifica la funcionalidad que se
incorporar al sistema propuesto. Un Caso de Uso puede 'incluir' la funcionalidad
de otro Caso de Uso o puede 'extender' otro Caso de Uso con su propio
comportamiento.
Los casos de uso tpicamente se relacionan con 'actores'. Un actor es un humano
o una mquina que interacta con el sistema para realizar un trabajo significativo.

4.1.1 ACTORES, CASOS DE USO, REQUERIMIENTOS

FUNCIONALES Y NO FUNCIONALES.
Actores
Los actores representan un tipo de usuario del sistema. Se entiendo como usuario
cualquier cosa externa que interacta con el sistema. No tiene por qu ser un ser
humano, puede ser otro sistema informtico o unidades organizativas o empresas.
Siempre hay que intentar independizar los actores de la forma en que se
interacta con el sistema. Por ejemplo un teclado no es un actor en la mayor parte
de los casos, slo un medio para introducir informacin al sistema. Suele ser til
mantener una lista de los usuarios reales para cada actor.
Un actor en un diagrama de casos de uso representa un rol que alguien puede
estar jugando, no un individuo particular por lo tanto puede haber personas
particulares que puedan estar usando el sistema de formas diferentes en
diferentes ocasiones: socio de biblioteca y bibliotecario.

Caso de uso
Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se est
desarrollando. Se representan mediante un vulo. Cada caso de uso debe
detallarse, habitualmente mediante una descripcin textual.

Asociaciones
Hay una asociacin entre un actor y un caso de uso si el actor interacta con el
sistema para llevar a cabo el caso de uso.

4.1.2 PROTOTIPOS PARA CASO DE USO

a)

Prototipo Parchado:

Es un sistema que tiene todas las caractersticas propuestas pero es realmente un

modelo bsico que eventualmente ser mejorado. Este tipo de prototipo trabaja
pero no es eficiente ni elegante.

b)

Prototipo no Operacional:

La segunda concepcin de un prototipo es la de un modelo o escala no funcional

para objeto de probar determinados aspectos del diseo. Este puede ser hecha
cuando la codificacin requerida por las aplicaciones es muy amplia para hacer el
prototipo y, sin embargo se puede obtener una idea til del sistema por medio de
la elaboracin de prototipos de la entrada y salida solamente.

c)

Prototipo Primero de una Serie:

Una tercera concepcin de la elaboracin de prototipos involucrados la creacin

de un primer modelo o escala completa de un sistema, llamado tambin piloto.
Este tipo de prototipo es til cuando se tiene planeadas muchas instalaciones del
mismo sistema. El modelo funcional o escala completa permite la interaccin
realista con el nuevo sistema, pero minimiza el costo de superar cualquier
problema que presente.

d)

Prototipo de Caractersticas Seleccionadas:

Un prototipo de caractersticas seleccionada permite que el sistema sea puesto en

su lugar mientras otras caractersticas pueden ser aadidas en fecha posterior. Se
refiere a la construccin de un modelo operacional que incluye algunas, pero no
todas, de las caractersticas que tendr el sistema final.

4.1.3 DOCUMENTACION
1. Resumen
En este trabajo se ofrecen un ejemplo de la tcnica de los casos de uso,
aplicndolo al caso de la gestin de un pequeo vdeoclub.
En la introduccin inicial se explica brevemente en que consiste esta tcnica y sus
caractersticas ms importantes. A continuacin se han desarrollado los diferentes
casos de uso del ejemplo junto a las plantillas para su especificacin. Dado que
se trata de un ejemplo ficticio se han simplificado las plantillas eliminando los
campos relativos a versin, autores, fuentes, importancia, urgencia y estado de
desarrollo.
El ejemplo no es una especificacin de requisitos completa, se incluye slo a
modo de ejemplo.

2. Introduccin
Los casos de uso son una tcnica para la especificacin de requisitos funcionales
propuesta inicialmente en [Jac93] y que actualmente forma parte de la propuesta
de UML [Boo99].
Un caso de uso es la descripcin de una secuencia de interacciones entre el
sistema y uno o ms actores en la que se considera al sistema como una caja
negra y en la que los actores obtienen resultados observables.
Los actores son personas u otros sistemas que interactan con el sistema cuyos
requisitos se estn describiendo.
Los casos de uso presentan ciertas ventajas sobre la descripcin meramente
textual de los requisitos funcionales, ya que facilitan la e licitacin de requisitos y
son fcilmente comprensibles por los clientes y usuarios. Adems, pueden servir
de base a las pruebas del sistema y a la documentacin para los usuarios.
Los casos de uso tienen una representacin grfica en los denominados
diagramas de casos de uso [Boo99]. En estos diagramas, los actores se
representan en forma de pequeos monigotes y los casos de uso se representan
por elipses contenidas dentro de un rectngulo que representa al sistema. La

participacin de los actores en los casos de uso se indica por una flecha entre el
actor y el caso de uso que apunta en la direccin en la que fluye la informacin.
3. Objetivos del sistema
En este apartado vamos a definir una lista con los diferentes objetivos que se
esperan alcanzar cuando el sistema software a desarrollar est en explotacin.
Sern especificados mediante una plantilla para objetivos.
OBJ01

Gestionar las cintas y pelculas

Descripcin

El sistema deber gestionar las cintas y pelculas disponibles en el

vdeo club: adquisiciones, retiradas, disponibilidad, etc.

Estabilidad

Alta

Comentarios

Ninguno

OBJ02

Gestionar los socios

Descripcin

El sistema deber gestionar las socios del vdeoclub: altas, bajas,

modificaciones de datos, sanciones, personas autorizadas, cuentas,
etc.

Estabilidad

Alta

Comentarios

Ninguno

OBJ03

Gestionar los alquileres

Descripcin

El sistema deber gestionar los alquileres de cintas: entregas,

devoluciones, devoluciones tardas, reclamaciones, disponibilidad,
etc.

Estabilidad

Alta

Comentarios

Ninguno

4. Requisitos de almacenamiento de informacin

Esta seccin contiene la lista de requisitos de almacenamiento de informacin que
se han identificado, utilizando para especificarlos la plantilla para requisitos de
almacenamiento de informacin. Especificaremos toda la informacin que
debemos almacenar en nuestro sistema.
RI01

Informacin sobre pelculas

Objetivos
asociados
Requisitos
asociados

OBJ01 Gestionar las pelculas y cintas

Descripcin

RF04 Alta de pelcula

RF05 Alta de cinta de vdeo
RF08 Baja de cinta de vdeo
RF10 Consulta de pelcula
RF13 Consulta de pelculas alquiladas un da determinado
El sistema deber almacenar la informacin correspondiente
a las pelculas del vdeoclub. En concreto:

Intervalo temporal

Ttulo de la pelcula
Cintas de la pelcula alquiladas en cada momento
Cintas de la pelcula disponibles para ser alquiladas en cada
momento
Tipo de la pelcula: infantil, accin, ciencia-ficcin o adultos
Duracin de la pelcula, en horas y minutos
Actores principales de la pelcula
Director de la pelcula
Productora de la pelcula
Ao de produccin de la pelcula
pasado y presente

Estabilidad

Alta

Comentarios

Ninguno

RI02

Informacin sobre socios

Objetivos
asociados

OBJ02 Gestionar los socios

Requisitos
asociados

RF01 Alta de socio

RF02 Baja de socio
RF03 Modificacin de datos de un socio

Datos especficos

Descripcin

RF11 Consulta de un socio

RF12 Consulta de socios con pagos pendientes
RF12 Consulta de los socios ms rentables
RF15 Identificacin de socio
El sistema deber almacenar la informacin correspondiente a
los socios del vdeoclub. En concreto:

Intervalo temporal

Nmero de socio, que deber ser nico para cada socio

Nmero del documento nacional de identidad
Nombre y apellidos
Fecha de nacimiento
Sexo
Fecha de alta como socio
Direccin
Telfonos
Pelculas alquiladas en un momento dado
slo presente

Estabilidad

Alta

Comentarios

Ninguno

RI03

Informacin sobre cuentas de socios

Objetivos
asociados
Requisitos
asociados

OBJ02 Gestionar los socios

Datos especficos

Descripcin

Datos especficos

RF01 Alta de socio

RF02 Baja de socio
RF05 Alquiler de cinta de vdeo
RF08 Devolucin de cintas de vdeo
RF09 Ingreso a cuenta
RF11 Consulta de un socio
RF12 Consulta de socios con pagos pendientes
El sistema deber almacenar la informacin correspondiente a
las cuentas de los socios del vdeoclub. En concreto:

Saldo de la cuenta en cada momento

Ingresos realizados en la cuenta, indicando fecha y cantidad
Cargos realizados en la cuenta, indicando fecha, motivo y
cantidad
Pagos pendientes, indicando motivo que podr ser alquiler
no pagado o multa; en el caso de alquiler no pagado se
debe indicar tambin la pelcula alquilada y la fecha del
alquiler

10

Intervalo temporal

slo presente

Estabilidad

Alta

Comentarios

Un socio puede hacer ingresos a cuenta, por ejemplo para

enviar a sus hijos por pelculas sin que stos tengan que llevar
dinero

5. Requisitos funcionales
5.1 Diagramas de casos de uso
En esta seccin hemos incluido los diagramas de casos de uso de nuestro
sistema, desarrollados con la herramienta Rational Rose 98.
Diagrama de subsistemas.

11

4.2 MODELO DE INTERFACES

El modelo de interfaces describe la presentacin entre los actores y el
sistema. Se especifica en detalle cmo se vern las interfaces de usuario y
ejecutar cada uno de los casos de uso.
Est basado a travs de un plan:

Complejidad del desarrollo de interfaces de usuario

Diseo basado como solucin

Ejemplo practico

Conclusiones

Algunos Modelos:
Tradicionalmente no ha existido un consenso sobre el conjunto de modelos a
emplear, pero de forma recurrente aparecen los siguientes modelos en la
literatura:

El modelo de dominio:

Define los objetos accesibles a los usuarios a travs de la interfaz de usuario.

Puede modelarse empleando un diagrama de clases o cualquier otro similar. Los
elementos que tpicamente aparecen en el modelo de dominio son clases o
entidades con sus atributos y relaciones.

El modelo de usuarios:

Especifica una descomposicin jerrquica de usuarios en estereotipos que

comparten un rol comn. Los elementos que suelen aparecen en este modelo son
usuarios, grupos, sus caractersticas y relaciones.

El modelo de tareas:

Describe el conjunto de tareas que los usuarios pueden realizar. Este modelo
suele tener una estructura jerrquica y normalmente se compone de objetivos,

12

acciones, precondiciones y postcondiciones. Suele expresarse en una notacin

denominada ConcurTaskTrees (CTT).

13

4.3 MODELO DEL DOMINIO DEL PROBLEMA

Un modelo del dominio se utiliza con frecuencia como fuente de inspiracin
para el diseo de los objetos software, y ser una entrada necesaria para varios
de los siguientes artefactos que se vern en este curso. El modelo del dominio
muestra (a los modeladores) clases conceptuales significativas en un dominio de]
problema; es el artefacto ms importante que se crea durante el anlisis orientado
a objetos. Este documento presenta tcnicas introductorias para la creacin de
modelos del dominio.
Un modelo del dominio es una representacin de las clases conceptuales del
mundo real, no de componentes software. No se trata de un conjunto de
diagramas

que

describen

clases

software,

objetos

software

con

responsabilidades.
La etapa orientada a objetos esencial del anlisis o investigacin es la
descomposicin de un dominio de inters en clases conceptuales individuales u
objetos -las cosas de las que, somos conscientes-. Un modelo del dominio es una
representacin visual de las clases conceptuales u objetos del mundo real en un
dominio de inters. Tambin se les denomina modelos conceptuales (trmino
utilizado en la primera edicin del libro de Larman), modelo de objetos del dominio
y modelos de objetos de anlisis.
Utilizando la notacin UML, un modelo del dominio se representa con un conjunto
de diagramas de clases en los que no se define ninguna operacin. Pueden
mostrar:

Objetos del dominio o clases conceptuales.

Asociaciones entre las clases conceptuales.

Atributos de las clases conceptuales.

14

4.3.1 IDENTIFICACION DE CLASES

Nuestro objetivo es crear un modelo del dominio de clases conceptuales
interesantes significativas del dominio de inters (ventas). En este caso, eso
significa conceptos relacionados con el caso de uso Procesar Venta.
En el desarrollo iterativo, uno incrementalmente construye un modelo del dominio
lo largo de varias iteraciones en la fase de elaboracin. En cada una, el modelo de
dominio se limita a los escenarios anteriores y actuales en estudio, en lugar de un
modelo de "gran explosin", que en las primeras etapas intenta capturar todas las
posibles clases conceptuales y las relaciones.
A continuacin se presentan dos tcnicas para la identificacin de las clases
conceptuales:
1. Utilizacin de una lista de categoras de clases conceptuales.
2. Identificacin de frases nominales.
Otra tcnica para el modelado del dominio (que no se ver aqu) es el uso de
patrones de anlisis, que son modelos de dominios parciales existentes creados
por expertos, utilizando libros publicados sobre el tema.

15

4.3.2 IDENTIFICACION DE ASOCIACIONES

Una asociacin es una relacin entre conceptos que indica una conexin
con sentido y que es de inters en el conjunto de casos de uso que se est
tratando.
Se incluyen en el modelo las asociaciones siguientes:

Asociaciones para las que el conocimiento de la relacin necesita

mantenerse por un cierto perodo de tiempo (asociaciones necesitaconocer).

Asociaciones derivadas de la Lista de Asociaciones.

Asociaciones simples y complejas

Las asociaciones son uno de los tipos de actividades ms verstiles de Clic. En
una

asociacin

siempre

intervienen

dos

conjuntos

de

informacin

denominados A y B, entre los elementos de los cuales se definen unas

determinadas relaciones. La nica excepcin a esta regla es la modalidad Pantalla
de informacin, que no es exactamente una asociacin a pesar de estar incluida
en este grupo.
El contenido de las ventanas A y B puede ser un grfico o un archivo de texto y,
como en todas las actividades Clic, los archivos de texto se pueden utilizar para
realizar referencias a elementos multimedia escribiendo su nombre entre claves.
En las asociaciones de respuesta escrita el contenido de B debe ser siempre un
texto, y en las de la modalidad identificacin siempre es el conjunto formato por las
expresiones S y No.
En las modalidades normal y compleja siempre se muestra el contenido completo
de ambas ventanas, que el usuario debe relacionar con clics del ratn. En las
otras modalidades el contenido de la ventana B no se llega a mostrar nunca al
usuario, pero el programa lo utiliza para validar las respuestas (en respuesta
escrita e identificacin) o decidir qu tipo de mensaje se tiene que mostrar (en las
de exploracin).

16

4.3.3 IDENTIFICACION DE ATRIBUTOS

Es necesario incorporar al Modelo Conceptual los atributos necesarios para
satisfacer las necesidades de informacin de los casos de uso que se estn
desarrollando en ese momento.
Los atributos deben tomar valor en tipos simples (nmero, texto, etc.), pues los
tipos complejos deberan ser modelados como conceptos y ser relacionados
mediante asociaciones.
Incluso cuando un valor es de un tipo simple es ms conveniente representarlo
como concepto en las siguientes ocasiones:
Se compone de distintas secciones. Por ejemplo: un nmero de telfono, el
nombre de una persona, etc.
Tiene operaciones asociadas, tales como validacin. Ejemplo: NIF.
Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin.
Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesetas
o en euros.
Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no
es un modelo definitivo, pues a lo largo del Anlisis y del Diseo se va refinando
segn se le aaden conceptos que se haban pasado por alto.

17

4.3.4 DICCIONARIO DE CLASES

Un diccionario de clases es un catlogo, un depsito, de los elementos en
un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de
los datos y la forma en que estn estructurados para satisfacer los requerimientos
de los usuarios y las necesidades de la organizacin. En un diccionario de datos
se encuentra la lista de todos los elementos que forman parte del flujo de datos en
todo el sistema. Los elementos ms importantes son flujos de datos, almacenes
de datos y procesos. El diccionario guarda los detalles y descripciones de todos
estos elementos.
El diccionario se desarrolla durante el anlisis de flujo de datos y auxilia a los
analistas que participan en la determinacin de los requerimientos de sistemas.
Importancia del diccionario
Los analistas utilizan los diccionarios de datos por cinco razones importantes:
1. Para manejar los detalles en sistemas grandes.
2. Para comunicar un significado comn para todos los elementos del sistema.
3. Para documentar las caractersticas del sistema.
4. Para facilitar el anlisis de los detalles con la finalidad de evaluar las
caractersticas y determinar dnde efectuar cambios en el sistema.
5. Localizar errores y omisiones en el sistema.
Manejo de detalles
Los sistemas grandes tienen enormes volmenes de datos que fluyen por ellos en
forma de documentos, reportes e incluso plticas. De manera similar, se llevan a
cabo muchas actividades que utilizan los datos existentes o que generan nuevos
detalles. Recurdese, como se mencion en la historia al inicio de este captulo,
que Lodos los sistemas experimentan cambios continuos y manejar de manera
completa todos los detalles es un desafi.

18

4.3.5 IDENTIFICACION DE MODULOS

El mdulo de identificacin es el responsable del reconocimiento de
individuos, por ejemplo en una aplicacin de control de acceso. El proceso de
identificacin comienza cuando el lector biomtrico captura la caracterstica del
individuo a ser identificado y la convierte a formato digital, para que a continuacin
el extractor de caractersticas produzca una representacin compacta con el
mismo formato del patrn. La representacin resultante se denomina query y es
enviada al comparador de caractersticas que confronta a ste con uno o varios
patrones para establecer la identidad.
El conjunto de procesos realizados por el mdulo de inscripcin recibe el nombre
de fase de inscripcin, mientras que los procesos realizados por el mdulo de
identificacin reciben la denominacin de fase operacional.

19

CONCLUSIN
La Interfaz de Usuario, es un conjunto de elementos hardware y software de
una computadora que presentan informacin al usuario y le permiten interactuar
con la informacin y con el computadora. Tambin se puede considerar parte de la
IU la documentacin (manuales, ayuda, referencia, tutoriales) que acompaa al
hardware y al software.
Si est bien diseada, el usuario encontrar la respuesta que espera a su accin.
Si no es as puede ser frustrante su operacin, ya que el usuario habitualmente
tiende a culparse a s mismo por no saber usar el objeto.
Los programas son usados por usuarios con distintos niveles de conocimientos,
desde principiantes hasta expertos. Es por ello que no existe una interfaz vlida
para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para
que elija el modo de interaccin que ms se adece a sus objetivos en cada
momento. La mayora de los programas y sistemas operativos ofrecen varias
formas de interaccin al usuario.
El modelo del dominio del problema, puede hacerse bastante complejo en el caso
de un sistema de gran tamao, para lo cual es necesario separar las clases en
modules. De tal manera, el modelo completo se dividira en una coleccin de
mdulos, donde cada modulo es una agrupacin lgica de clases y sus
asociaciones correspondientes.
La razn de separar en dos mdulos, va muy de la mano con la existencia de
estos dos actores secundarios, ya que al corresponder cada actor secundario a
una base de datos, los mdulos afianzan esta correspondencia. Sin embargo, esto
no tiene por qu ser realmente as, pudiendo existir un solo modulo para un
sistema con mltiples actores secundarios, o incluso varios mdulos por cada
actor secundario.

20

REFERENCIAS
Capuz Rizo Salvador, Gmez Eliseo, Ingeniera, Organizacin y Gestin de
Proyectos, Perproval, Primera Edicin, Valencia. P.P 243.
Jos salvador Snchez Garreta, Ingeniera de Proyectos Informticos
(Modelos de Interfaz de Usuarios), Universat Jaume, Castellano de Palma,
2003, Primera Edicin. PP. 171.
El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson.
Addison Wesley Iberoamericana, 1999.
Object-Oriented Analysis and Design. G. Booch. Benjamin/Cummings,1994.

21

APENDICES
Describe la
funcionalidad
propuesta del
nuevo sistema

Representa la
interpretacin
de usuario

Cada uso tiene

una descripcin
que especifica la
funcionalidad

4.1 MODELO
DE CASO DE
USO

Normalmente
se relacionan
Actores.

UNIDAD 4
MODELOS DE
REQUISITOS

ACTORES

Es un diagrama
de caso de usos
que representa el
Rol de alguien

Representa un
tipo de usuario
del sistema

CASO DE USO
Este debe ser
detallado
mediante una
descripcin textual

4.1.1 ACTORES,
CASOS DE USO,
REQUERIMIENTOS
FUNCIONALES Y NO
FUNCIONALES

22

ASOCIASIONES
Hay una
asociacin entre
un actor y un
caso de uso

Prototipo Parchado:
Prototipo no
Operacional:

Es un sistema que
tiene todas las
caractersticas
propuestas

4.1.2.
PROTOTIPOS
PARA CASOS
DE USO

La segunda
concepcin de un
prototipo es la de un
modelo o escala no
funcional

Prototipo de
Caractersticas
Seleccionadas:

Prototipo Primero de
una Serie:
Una tercera concepcin
de la elaboracin de
prototipos

Un prototipo de
caractersticas seleccionada
permite que el sistema sea
puesto en su lugar

23

Resumen
En este trabajo se ofrecen
un ejemplo de la tcnica
de los casos de uso,
aplicndolo al caso de la
gestin de un pequeo
vdeoclub.

Introduccin
Los casos de uso son una
tcnica para la
especificacin de
requisitos funcionales
propuesta inicialmente en
[Jac93] y que actualmente
forma parte de la
propuesta de UML
[Boo99].

4.1.3
DOCUMENTACION

Objetivos del
sistema
Sern especificados
mediante una
plantilla para
objetivos.

Requisitos
funcionales
los diagramas de
casos de uso de
nuestro sistema,
desarrollados con la
herramienta

24

Describe la
presentacin entre
los actores y el
sistema

Est

basado

travs de un plan:

4.2 MODELO DE
INTERFACES

Complejidad

del

desarrollo

de

interfaces de usuario
Diseo basado como
solucin
Ejemplo practico
BASADO DE
ALGUNOS
MODELOS

Conclusiones

El modelo de dominio
El modelo de usuarios
El modelo de tareas

25

Es una
representacin de
las clases
conceptuales del
mundo real, no de
componentes
software.

Se utiliza con
frecuencia como
fuente de
inspiracin para el
diseo de los
objetos software

4.3 MODELO
DEL DOMINIO
DEL PROBLEMA

Un modelo del
dominio se
representa con un
conjunto de
diagramas de clases

Objetos del dominio o clases

conceptuales.

Asociaciones entre las clases

conceptuales.

Atributos

de

conceptuales.

26

las

clases

Modelo del dominio

de clases
conceptuales
interesantes
significativas del
dominio de inters
(ventas).

4.3.1
IDENTIFICACION
DE CLASES

A continuacin se
presentan dos
tcnicas para la
identificacin de las
clases conceptuales:

1. Utilizacin de una lista de categoras

2.

de clases conceptuales.

nominales.

27

Identificacin

de

frases

Es una relacin
entre conceptos
que indica una
conexin con
sentido

4.3.2
IDENTIFICACION
DE
ASOCIACIONES

Icluyen en el
modelo las
asociaciones
siguientes:

Asociaciones para las que el conocimiento de la relacin necesita

mantenerse por un cierto perodo de tiempo (asociaciones necesitaconocer).

Asociaciones derivadas de la Lista de Asociaciones.

28