Вы находитесь на странице: 1из 28
TECNOLÓGICO DE ESTUDIOS SUPERIORES DE CHALCO INGENIERÍA INFORMÁTICA INVESTIGACION PARA EVALUACION DE LA UNIDAD 4 MATERIA:
TECNOLÓGICO DE ESTUDIOS SUPERIORES DE CHALCO INGENIERÍA INFORMÁTICA INVESTIGACION PARA EVALUACION DE LA UNIDAD 4 MATERIA:

TECNOLÓGICO DE ESTUDIOS SUPERIORES DE CHALCO

INGENIERÍA INFORMÁTICA

TECNOLÓGICO DE ESTUDIOS SUPERIORES DE CHALCO INGENIERÍA INFORMÁTICA INVESTIGACION PARA EVALUACION DE LA UNIDAD 4 MATERIA:

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 MÉXICO, A 07 DE ENERO DEL 2016.

1
1
INDICE INTRUDUCCIÓN 3 4.1 MODELOS DE CASO DE USO 4 4.1.1 ACTORES, CASOS DE USO, REQUERIMIENTOS

INDICE

INDICE INTRUDUCCIÓN 3 4.1 MODELOS DE CASO DE USO 4 4.1.1 ACTORES, CASOS DE USO, REQUERIMIENTOS

INTRUDUCCIÓN

3

  • 4.1 MODELOS DE CASO DE USO

4

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

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

16

  • 4.3.3 IDENTIFICACION DE ATRIBUTOS

17

  • 4.3.4 DICCIONARIO DE CLASES ...........................................................................................

18

  • 4.3.5 IDENTIFICACION DE MODULOS .................................................................................

19

CONCLUSIÓN

20

REFERENCIAS

21

APENDICES ....................................................................................................................................

22

2
2
INTRUDUCCIÓN Algunas de las debilidades de muchos métodos están contextualizadas en etapas tempranas del desarrollo de

INTRUDUCCIÓN

INTRUDUCCIÓN Algunas de las debilidades de muchos métodos están contextualizadas en etapas tempranas del desarrollo de

Algunas de las debilidades de muchos métodos están contextualizadas en etapas tempranas del desarrollo de software. Uno de los problemas derivado de estas debilidades metodológicas 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. Más aún, generalmente estos métodos carecen de directrices adecuadas para el desarrollo de modelos conceptuales derivados de las especificaciones y posteriormente de código que sea funcionalmente equivalente a dichos modelos conceptuales.

Como un esfuerzo para la superación de estas limitaciones, en este trabajo se presenta un enfoque sistemático de Ingeniería de Requisitos que define un proceso que posibilita la descomposición sistemática y repetitiva de los requisitos de software hasta obtener una detallada especificación que constituirá el modelo conceptual del sistema deseado. Este enfoque pretende mejorar la calidad del proceso de producción de software:

Proporcionando predecibilidad mediante la construcción de un modelo conceptual como una precisa, estructurada y bien definida representación de los requisitos de los usuarios.

Aumentando la productividad al establecer vínculos precisos entre el modelo conceptual y los requisitos de los usuarios. Esto facilitará la incorporación en el modelo conceptual de cambios en los requisitos. En consecuencia, tales modificaciones quedarán reflejadas también en el sistema de software desarrollado.

3
3
4.1 MODELOS DE CASO DE USO El modelo de casos de uso describe la funcionalidad propuesta
4.1 MODELOS DE CASO DE USO El modelo de casos de uso describe la funcionalidad propuesta

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 interacción entre un usuario (humano o máquina) 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 descripción 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 típicamente se relacionan con 'actores'. Un actor es un humano o una máquina que interactúa con el sistema para realizar un trabajo significativo.

4.1 MODELOS DE CASO DE USO El modelo de casos de uso describe la funcionalidad propuesta
4
4
4.1.1 ACTORES, CASOS DE USO, REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES.  Actores Los actores representan un
4.1.1 ACTORES, CASOS DE USO, REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES.  Actores Los actores representan un

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 interactúa con el sistema. No tiene por qué ser un ser humano, puede ser otro sistema informático o unidades organizativas o empresas.

Siempre hay que intentar independizar los actores de la forma en que se interactúa con el sistema. Por ejemplo un teclado no es un actor en la mayor parte de los casos, sólo un medio para introducir información 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 descripción textual.

  • Asociaciones

Hay una asociación entre un actor y un caso de uso si el actor interactúa con el sistema para llevar a cabo el caso de uso.

5
5
4.1.2 PROTOTIPOS PARA CASO DE USO a) Prototipo Parchado: Es un sistema que tiene todas las
4.1.2 PROTOTIPOS PARA CASO DE USO a) Prototipo Parchado: Es un sistema que tiene todas las

4.1.2 PROTOTIPOS PARA CASO DE USO

  • a) Prototipo Parchado:

Es un sistema que tiene todas las características propuestas pero es realmente un modelo básico que eventualmente será mejorado. Este tipo de prototipo trabaja pero no es eficiente ni elegante.

  • b) Prototipo no Operacional:

La segunda concepción de un prototipo es la de un modelo o escala no funcional para objeto de probar determinados aspectos del diseño. Este puede ser hecha cuando la codificación 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 elaboración de prototipos de la entrada y salida solamente.

  • c) Prototipo Primero de una Serie:

Una tercera concepción de la elaboración de prototipos involucrados la creación de un primer modelo o escala completa de un sistema, llamado también piloto. Este tipo de prototipo es útil cuando se tiene planeadas muchas instalaciones del mismo sistema. El modelo funcional o escala completa permite la interacción realista con el nuevo sistema, pero minimiza el costo de superar cualquier problema que presente.

  • d) Prototipo de Características Seleccionadas:

Un prototipo de características seleccionada permite que el sistema sea puesto en su lugar mientras otras características pueden ser añadidas en fecha posterior. Se refiere a la construcción de un modelo operacional que incluye algunas, pero no todas, de las características que tendrá el sistema final.

6
6
4.1.3 DOCUMENTACION 1. Resumen En este trabajo se ofrecen un ejemplo de la técnica de los

4.1.3 DOCUMENTACION

  • 1. Resumen

4.1.3 DOCUMENTACION 1. Resumen En este trabajo se ofrecen un ejemplo de la técnica de los

En este trabajo se ofrecen un ejemplo de la técnica de los casos de uso,

aplicándolo al caso de la gestión de un pequeño vídeoclub. En la introducción inicial se explica brevemente en que consiste esta técnica y sus características más importantes. A continuación se han desarrollado los diferentes casos de uso del ejemplo junto a las plantillas para su especificación. Dado que se trata de un ejemplo ficticio se han simplificado las plantillas eliminando los campos relativos a versión, autores, fuentes, importancia, urgencia y estado de desarrollo. El ejemplo no es una especificación de requisitos completa, se incluye sólo a modo de ejemplo.

  • 2. Introducción

Los casos de uso son una técnica para la especificación de requisitos funcionales propuesta inicialmente en [Jac93] y que actualmente forma parte de la propuesta

de UML [Boo99].

Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más 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 interactúan con el sistema cuyos requisitos se están describiendo.

Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los requisitos funcionales, ya que facilitan la e licitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. Además, pueden servir de base a las pruebas del sistema y a la documentación para los usuarios.

Los

casos

de

uso

tienen

una

representación

gráfica en los denominados

diagramas de casos de uso [Boo99]. En estos diagramas, los actores se representan en forma de pequeños monigotes y los casos de uso se representan por elipses contenidas dentro de un rectángulo que representa al sistema. La

7
7
participación de los actores en los casos de uso se indica por una flecha entre el
participación de los actores en los casos de uso se indica por una flecha entre el

participación 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 dirección en la que fluye la información.

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 explotación. Serán especificados mediante una plantilla para objetivos.

OBJ01

Gestionar las cintas y películas

Descripción

El sistema deberá gestionar las cintas y películas disponibles en el vídeo club: adquisiciones, retiradas, disponibilidad, etc.

Estabilidad

Alta

Comentarios

Ninguno

 

OBJ02

Gestionar los socios

Descripción

El sistema deberá gestionar las socios del vídeoclub: altas, bajas, modificaciones de datos, sanciones, personas autorizadas, cuentas, etc.

Estabilidad

Alta

Comentarios

Ninguno

 

OBJ03

Gestionar los alquileres

Descripción

El sistema deberá gestionar los alquileres de cintas: entregas, devoluciones, devoluciones tardías, reclamaciones, disponibilidad, etc.

Estabilidad

Alta

Comentarios

Ninguno

8
8
4. Requisitos de almacenamiento de información Esta sección contiene la lista de requisitos de almacenamiento de
4. Requisitos de almacenamiento de información Esta sección contiene la lista de requisitos de almacenamiento de

4. Requisitos de almacenamiento de información

Esta sección contiene la lista de requisitos de almacenamiento de información que

se han identificado, utilizando para especificarlos la plantilla para requisitos de almacenamiento de información. Especificaremos toda la información que debemos almacenar en nuestro sistema.

RI01

Información sobre películas

Objetivos

OBJ01 Gestionar las películas y cintas

asociados

Requisitos

RF04 Alta de película

asociados

RF05 Alta de cinta de vídeo

RF08 Baja de cinta de vídeo

RF10 Consulta de película

RF13 Consulta de películas alquiladas un día determinado

Descripción

El sistema deberá almacenar la información correspondiente

a las películas del vídeoclub. En concreto:

Datos específicos

Título de la película

Cintas de la película alquiladas en cada momento

 

Cintas de la película disponibles para ser alquiladas en cada

momento Tipo de la película: infantil, acción, ciencia-ficción o adultos

Duración de la película, en horas y minutos

Actores principales de la película

Director de la película

Productora de la película

Año de producción de la película

Intervalo temporal

pasado y presente

Estabilidad

 

Alta

Comentarios

 

Ninguno

 

RI02

Información sobre socios

Objetivos

OBJ02 Gestionar los socios

asociados

 

Requisitos

RF01 Alta de socio

asociados

RF02 Baja de socio

RF03 Modificación de datos de un socio

9
9
    RF – 11 Consulta de un socio RF – 12 Consulta de
    RF – 11 Consulta de un socio RF – 12 Consulta de
 

RF11 Consulta de un socio

RF12 Consulta de socios con pagos pendientes

RF12 Consulta de los socios más rentables

RF15 Identificación de socio

Descripción

El sistema deberá almacenar la información correspondiente a los socios del vídeoclub. En concreto:

Datos específicos

Número de socio, que deberá ser único para cada socio

Número del documento nacional de identidad

 

Nombre y apellidos

Fecha de nacimiento

Sexo

Fecha de alta como socio

Dirección

Teléfonos

Películas alquiladas en un momento dado

Intervalo temporal

sólo presente

Estabilidad

Alta

Comentarios

Ninguno

 

RI03

Información sobre cuentas de socios

Objetivos

OBJ02 Gestionar los socios

asociados

Requisitos

RF01 Alta de socio

asociados

RF02 Baja de socio

RF05 Alquiler de cinta de vídeo

RF08 Devolución de cintas de vídeo

RF09 Ingreso a cuenta

RF11 Consulta de un socio

Descripción

RF12 Consulta de socios con pagos pendientes El sistema deberá almacenar la información correspondiente a las cuentas de los socios del vídeoclub. En concreto:

Datos específicos

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 también la película alquilada y la fecha del alquiler

10
10
Intervalo temporal sólo presente Estabilidad Alta Comentarios Un socio puede hacer ingresos a cuenta, por ejemplo
Intervalo temporal sólo presente Estabilidad Alta Comentarios Un socio puede hacer ingresos a cuenta, por ejemplo

Intervalo temporal

sólo presente

Estabilidad

Alta

Comentarios

Un socio puede hacer ingresos a cuenta, por ejemplo para enviar a sus hijos por películas sin que éstos tengan que llevar dinero

5. Requisitos funcionales

5.1 Diagramas de casos de uso

En esta sección hemos incluido los diagramas de casos de uso de nuestro sistema, desarrollados con la herramienta Rational Rose 98.

Diagrama de subsistemas.

Intervalo temporal sólo presente Estabilidad Alta Comentarios Un socio puede hacer ingresos a cuenta, por ejemplo
11
11
El modelo de
El modelo
de
El modelo de 4.2 MODELO DE INTERFACES interfaces describe la presentación entre los actores y el

4.2 MODELO DE INTERFACES

interfaces describe la presentación entre los actores y el

sistema. Se especifica en detalle cómo se verán las interfaces de usuario y

ejecutar cada uno de los casos de uso.

Está basado a través de un plan:

Complejidad del desarrollo de interfaces de usuario

Diseño basado como solución

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 través de la interfaz de usuario. Puede modelarse empleando un diagrama de clases o cualquier otro similar. Los elementos que típicamente aparecen en el modelo de dominio son clases o entidades con sus atributos y relaciones.

El modelo de usuarios:

Especifica una descomposición jerárquica de usuarios en estereotipos que comparten un rol común. Los elementos que suelen aparecen en este modelo son usuarios, grupos, sus características y relaciones.

El modelo de tareas:

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

12
12
acciones, precondiciones y postcondiciones. Suele expresarse en una notación denominada ConcurTaskTrees (CTT). 13
acciones, precondiciones y postcondiciones. Suele expresarse en una notación denominada ConcurTaskTrees (CTT). 13

acciones, precondiciones y postcondiciones. Suele expresarse en una notación denominada ConcurTaskTrees (CTT).

13
13
4.3 MODELO DEL DOMINIO DEL PROBLEMA Un modelo del dominio se utiliza con frecuencia como fuente
4.3 MODELO DEL DOMINIO DEL PROBLEMA Un modelo del dominio se utiliza con frecuencia como fuente

4.3 MODELO DEL DOMINIO DEL PROBLEMA

Un modelo del dominio se utiliza con frecuencia como fuente de inspiración para el diseño de los objetos software, y será una entrada necesaria para varios de los siguientes artefactos que se verán en este curso. El modelo del dominio muestra (a los modeladores) clases conceptuales significativas en un dominio de] problema; es el artefacto más importante que se crea durante el análisis orientado a objetos. Este documento presenta técnicas introductorias para la creación de modelos del dominio. Un modelo del dominio es una representación de las clases conceptuales del mundo real, no de componentes software. No se trata de un conjunto de diagramas que describen clases software, u objetos software con responsabilidades.

La etapa orientada a objetos esencial del análisis o investigación es la descomposición de un dominio de interés en clases conceptuales individuales u objetos -las cosas de las que, somos conscientes-. Un modelo del dominio es una representación visual de las clases conceptuales u objetos del mundo real en un dominio de interés. También se les denomina modelos conceptuales (término utilizado en la primera edición del libro de Larman), modelo de objetos del dominio y modelos de objetos de análisis.

Utilizando la notación UML, un modelo del dominio se representa con un conjunto de diagramas de clases en los que no se define ninguna operación. Pueden mostrar:

Objetos del dominio o clases conceptuales.

Asociaciones entre las clases conceptuales.

Atributos de las clases conceptuales.

14
14
4.3.1 IDENTIFICACION DE CLASES Nuestro objetivo es crear un modelo del dominio de clases conceptuales interesantes
4.3.1 IDENTIFICACION DE CLASES Nuestro objetivo es crear un modelo del dominio de clases conceptuales interesantes

4.3.1 IDENTIFICACION DE CLASES

Nuestro objetivo es crear un modelo del dominio de clases conceptuales interesantes significativas del dominio de interés (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 elaboración. En cada una, el modelo de dominio se limita a los escenarios anteriores y actuales en estudio, en lugar de un modelo de "gran explosión", que en las primeras etapas intenta capturar todas las posibles clases conceptuales y las relaciones.

A continuación se presentan dos técnicas para la identificación de las clases conceptuales:

  • 1. Utilización de una lista de categorías de clases conceptuales.

  • 2. Identificación de frases nominales.

Otra técnica para el modelado del dominio (que no se verá aquí) es el uso de patrones de análisis, que son modelos de dominios parciales existentes creados por expertos, utilizando libros publicados sobre el tema.

15
15
4.3.2 IDENTIFICACION DE ASOCIACIONES Una asociación es una relación entre conceptos que indica una conexión con
4.3.2 IDENTIFICACION DE ASOCIACIONES Una asociación es una relación entre conceptos que indica una conexión con

4.3.2 IDENTIFICACION DE ASOCIACIONES

Una asociación es una relación entre conceptos que indica una conexión

con

sentido

y

que

es

de

interés 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

relación

necesita

 

mantenerse por un cierto período de tiempo (asociaciones “necesita-

 

conocer”). Asociaciones derivadas de la Lista de Asociaciones.

 

Asociaciones simples y complejas

Las asociaciones son uno de los tipos de actividades más versátiles de Clic. En una asociación siempre intervienen dos conjuntos de información denominados A y B, entre los elementos de los cuales se definen unas determinadas relaciones. La única excepción a esta regla es la modalidad Pantalla de información, que no es exactamente una asociación a pesar de estar incluida en este grupo.

El contenido de las ventanas A y B puede ser un gráfico 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 identificación 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 ratón. 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 identificación) o decidir qué tipo de mensaje se tiene que mostrar (en las de exploración).

16
16
4.3.3 IDENTIFICACION DE ATRIBUTOS Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las
4.3.3 IDENTIFICACION DE ATRIBUTOS Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las

4.3.3 IDENTIFICACION DE ATRIBUTOS

Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de información de los casos de uso que se estén desarrollando en ese momento.

Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos deberían ser modelados como conceptos y ser relacionados mediante asociaciones.

Incluso cuando un valor es de un tipo simple es más conveniente representarlo como concepto en las siguientes ocasiones:

· Se compone de distintas secciones. Por ejemplo: un número de teléfono, el nombre de una persona, etc.

· Tiene operaciones asociadas, tales como validación. 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 Análisis y del Diseño se va refinando según se le añaden conceptos que se habían pasado por alto.

17
17
4.3.4 DICCIONARIO DE CLASES Un diccionario de clases es un catálogo, un depósito, de los elementos
4.3.4 DICCIONARIO DE CLASES Un diccionario de clases es un catálogo, un depósito, de los elementos

4.3.4 DICCIONARIO DE CLASES

Un diccionario de clases es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. 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 más 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 análisis de flujo de datos y auxilia a los analistas que participan en la determinación 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 común para todos los elementos del sistema.

  • 3. Para documentar las características del sistema.

  • 4. Para facilitar el análisis

de

los

detalles con

la finalidad

de

evaluar las

características y determinar dónde efectuar cambios en el sistema.

  • 5. Localizar errores y omisiones en el sistema.

Manejo de detalles

Los sistemas grandes tienen enormes volúmenes de datos que fluyen por ellos en forma de documentos, reportes e incluso pláticas. De manera similar, se llevan a cabo muchas actividades que utilizan los datos existentes o que generan nuevos detalles. Recuérdese, como se mencionó en la historia al inicio de este capítulo, que Lodos los sistemas experimentan cambios continuos y manejar de manera completa todos los detalles es un desafió.

18
18
4.3.5 IDENTIFICACION DE MODULOS El módulo de identificación es el responsable del reconocimiento de individuos, por
4.3.5 IDENTIFICACION DE MODULOS El módulo de identificación es el responsable del reconocimiento de individuos, por

4.3.5 IDENTIFICACION DE MODULOS

El módulo de identificación es el responsable del reconocimiento de individuos, por ejemplo en una aplicación de control de acceso. El proceso de identificación comienza cuando el lector biométrico captura la característica del individuo a ser identificado y la convierte a formato digital, para que a continuación el extractor de características produzca una representación compacta con el mismo formato del patrón. La representación resultante se denomina query y es enviada al comparador de características que confronta a éste con uno o varios patrones para establecer la identidad.

El conjunto de procesos realizados por el módulo de inscripción recibe el nombre de fase de inscripción, mientras que los procesos realizados por el módulo de identificación reciben la denominación de fase operacional.

19
19
CONCLUSIÓN La Interfaz de Usuario, es un conjunto de elementos <a href=hardware y software de una computadora que presentan información al usuario y le permiten interactuar con la información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software. Si está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, 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 válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario. El modelo del dominio del problema, puede hacerse bastante complejo en el caso de un sistema de gran tamaño, para lo cual es necesario separar las clases en modules. De tal manera, el modelo completo se dividiría en una colección de módulos, donde cada modulo es una agrupación lógica de clases y sus asociaciones correspondientes. La razón de separar en dos módulos, 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 módulos afianzan esta correspondencia. Sin embargo, esto no tiene por qué ser realmente así, pudiendo existir un solo modulo para un sistema con múltiples actores secundarios, o incluso varios módulos por cada actor secundario. 20 " id="pdf-obj-19-2" src="pdf-obj-19-2.jpg">

CONCLUSIÓN

CONCLUSIÓN La Interfaz de Usuario, es un conjunto de elementos <a href=hardware y software de una computadora que presentan información al usuario y le permiten interactuar con la información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software. Si está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, 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 válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario. El modelo del dominio del problema, puede hacerse bastante complejo en el caso de un sistema de gran tamaño, para lo cual es necesario separar las clases en modules. De tal manera, el modelo completo se dividiría en una colección de módulos, donde cada modulo es una agrupación lógica de clases y sus asociaciones correspondientes. La razón de separar en dos módulos, 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 módulos afianzan esta correspondencia. Sin embargo, esto no tiene por qué ser realmente así, pudiendo existir un solo modulo para un sistema con múltiples actores secundarios, o incluso varios módulos por cada actor secundario. 20 " id="pdf-obj-19-6" src="pdf-obj-19-6.jpg">

La Interfaz de Usuario, es un conjunto de elementos hardware y software de una computadora que presentan información al usuario y le permiten interactuar con la información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software.

Si está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, 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 válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario.

El modelo del dominio del problema, puede hacerse bastante complejo en el caso de un sistema de gran tamaño, para lo cual es necesario separar las clases en modules. De tal manera, el modelo completo se dividiría en una colección de módulos, donde cada modulo es una agrupación lógica de clases y sus asociaciones correspondientes.

La razón de separar en dos módulos, 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 módulos afianzan esta correspondencia. Sin embargo, esto no tiene por qué ser realmente así, pudiendo existir un solo modulo para un sistema con múltiples actores secundarios, o incluso varios módulos por cada actor secundario.

20
20
REFERENCIAS  Capuz Rizo Salvador, Gómez Eliseo, Ingeniería, Organización y Gestión de Proyectos, Perproval, Primera Edición,

REFERENCIAS

REFERENCIAS  Capuz Rizo Salvador, Gómez Eliseo, Ingeniería, Organización y Gestión de Proyectos, Perproval, Primera Edición,
  • Capuz Rizo Salvador, Gómez Eliseo, Ingeniería, Organización y Gestión de Proyectos, Perproval, Primera Edición, Valencia. P.P 243.

  • José salvador Sánchez Garreta, Ingeniería de Proyectos Informáticos (Modelos de Interfaz de Usuarios), Universat Jaume, Castellano de Palma, 2003, Primera Edición. 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
21
APENDICES Describe la funcionalidad propuesta del nuevo sistema Cada uso tiene una descripción que especifica la

APENDICES

APENDICES Describe la funcionalidad propuesta del nuevo sistema Cada uso tiene una descripción que especifica la
Describe la funcionalidad propuesta del nuevo sistema Cada uso tiene una descripción que especifica la funcionalidad
Describe la
funcionalidad
propuesta del
nuevo sistema
Cada uso tiene
una descripción
que especifica la
funcionalidad
Representa la
4.1 MODELO
DE CASO DE
USO
Normalmente
se relacionan
interpretación
“Actores”.
de usuario
UNIDAD 4
MODELOS DE
REQUISITOS
ACTORES
Representa un
tipo de usuario
del sistema
Es un diagrama
de caso de usos
que representa el
Rol de alguien
CASO DE USO
4.1.1 ACTORES,
CASOS DE USO,
REQUERIMIENTOS
FUNCIONALES Y NO
FUNCIONALES
ASOCIASIONES
Este debe ser
detallado
mediante una
descripción textual
Hay una
asociación entre
un actor y un
caso de uso
22
22
Prototipo Parchado: Prototipo no Es un sistema que tiene todas las características propuestas Operacional: La segunda
Prototipo Parchado: Prototipo no Es un sistema que tiene todas las características propuestas Operacional: La segunda
Prototipo Parchado: Prototipo no Es un sistema que tiene todas las características propuestas Operacional: La segunda
Prototipo Parchado:
Prototipo no
Es un sistema que
tiene todas las
características
propuestas
Operacional:
La segunda
concepción de un
prototipo es la de un
modelo o escala no
4.1.2.
PROTOTIPOS
PARA CASOS
DE USO
Prototipo Primero de
una Serie:
Prototipo de
Características
Seleccionadas:
Una tercera concepción
de la elaboración de
prototipos
Un prototipo de
características seleccionada
permite que el sistema sea
puesto en su lugar
23
23
Resumen En este trabajo se ofrecen un ejemplo de la técnica de los casos de uso,
Resumen En este trabajo se ofrecen un ejemplo de la técnica de los casos de uso,
Resumen En este trabajo se ofrecen un ejemplo de la técnica de los casos de uso,
Resumen
En este trabajo se ofrecen
un ejemplo de la técnica
de los casos de uso,
aplicándolo al caso de la
gestión de un pequeño
vídeo–club.
Introducción
Los casos de uso son una
técnica para la
especificación de
requisitos funcionales
propuesta inicialmente en
[Jac93] y que actualmente
forma parte de la
4.1.3
DOCUMENTACION
Objetivos del
sistema
Serán especificados
Requisitos
mediante una
funcionales
plantilla para
objetivos.
los diagramas de
casos de uso de
nuestro sistema,
desarrollados con la
herramienta
24
24
Describe la presentación entre los actores y el sistema Está basado a través de un plan:
Describe la presentación entre los actores y el sistema Está basado a través de un plan:
Describe la presentación entre los actores y el sistema Está basado a través de un plan:
Describe la
presentación entre
los actores y el
sistema
Está
basado
a
través de un plan:
Complejidad del
4.2 MODELO DE
INTERFACES
desarrollo
de
interfaces de usuario
Diseño basado como
solución
Ejemplo practico
BASADO DE
Conclusiones
ALGUNOS
MODELOS
  • El modelo de dominio

  • El modelo de usuarios

  • El modelo de tareas

25
25
Se utiliza con frecuencia como fuente de inspiración para el diseño de los objetos software Es
Se utiliza con frecuencia como fuente de inspiración para el diseño de los objetos software Es
Se utiliza con frecuencia como fuente de inspiración para el diseño de los objetos software Es
Se utiliza con
frecuencia como
fuente de
inspiración para el
diseño de los
objetos software
Es una
representación de
las clases
conceptuales del
mundo real, no de
componentes
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

las clases

conceptuales.

26
26
Modelo del dominio de clases conceptuales interesantes significativas del dominio de interés 4.3.1 IDENTIFICACION DE CLASES
Modelo del dominio de clases conceptuales interesantes significativas del dominio de interés 4.3.1 IDENTIFICACION DE CLASES
Modelo del dominio de clases conceptuales interesantes significativas del dominio de interés 4.3.1 IDENTIFICACION DE CLASES
Modelo del dominio
de clases
conceptuales
interesantes
significativas del
dominio de interés
4.3.1
IDENTIFICACION
DE CLASES
A continuación se
presentan dos
técnicas para la
identificación de las
clases conceptuales:
1. Utilización de una lista de categorías
de clases conceptuales.
2.
Identificación
de
frases
nominales.
27
27
Es una relación entre conceptos que indica una conexión con sentido 4.3.2 IDENTIFICACION DE ASOCIACIONES Icluyen
Es una relación entre conceptos que indica una conexión con sentido 4.3.2 IDENTIFICACION DE ASOCIACIONES Icluyen
Es una relación
entre conceptos
que indica una
conexión con
sentido
4.3.2
IDENTIFICACION
DE
ASOCIACIONES
Icluyen en el
modelo las
asociaciones
siguientes:
Es una relación entre conceptos que indica una conexión con sentido 4.3.2 IDENTIFICACION DE ASOCIACIONES Icluyen
 Asociaciones para las que el conocimiento de la relación necesita mantenerse por un cierto período
Asociaciones para las que el conocimiento de la relación necesita
mantenerse por un cierto período de tiempo (asociaciones “necesita-
conocer”).
Asociaciones derivadas de la Lista de Asociaciones.
28
28