Fundamentos de Ingenieria de Software

[Escriba aqu]
GLOBALTEC
Fundamentos de Ingeniera del Software
Integrantes del Equipo:

Cinthia Guadalupe Ramrez Montes
Lezly Susette Reyes Norman
Franklin Iztcoatl Monreal Cristerna
Bernardo Dvila Jimnez
Alfredo Pablo Hernndez
GlobalTec
Documento Final
Tabla de contenido
ndice de Figuras ............................................................................................................................ 6
Parte Terica y Parte de Actividades .................................................................................... 8
1.1 Conceptos Bsicos ........................................................................................................... 8
1.2 El Papel Evolutivo del Software ..................................................................................... 11
1.3 Etapas del Desarrollo del Software ............................................................................... 12
1.4 Definicin e Historia de las Herramientas Case ........................................................ 13
1.5 Clasificacin de las Herramientas CASE .................................................................... 16
Unidad 2: Ingeniera de requisitos........................................................................................... 19
Parte Terica .............................................................................................................................. 19
2.1 Tareas de la Ingeniera de Requisitos .......................................................................... 19
2.2 Tcnicas de la Ingeniera de Requisitos ...................................................................... 21
2.3 Modelado de Requisitos ................................................................................................. 26
2.4 Herramientas CASE para la Ingeniera de Requisitos ............................................... 28
Parte de Actividades ................................................................................................................ 31
Actividad 3: Documentar en un caso de desarrollo las distintas tareas de la ingeniera
de requerimientos. .................................................................................................................. 31
Actividad 5: Tcnicas de la Ingeniera de Requisitos ....................................................... 34
Actividad 6: Investigar sobre las aplicaciones del modelado y sus especificaciones. 39
Actividad 7: Aplicar al menos una herramienta CASE para la identificacin de
requerimientos. ....................................................................................................................... 41
Unidad 3: Modelo de anlisis .................................................................................................... 42
Parte Terica .............................................................................................................................. 42
3.1 Arquitectura de Clases .................................................................................................... 42
3.2 Clases con estereotipos.................................................................................................. 46
3.3 Clases ................................................................................................................................ 49
3.4 Diagramas de Secuencias.............................................................................................. 52
3.5 Diccionario de Clases Segn Mdulos ......................................................................... 55
3.6 Herramientas CASE para el Anlisis ............................................................................ 62
Actividad 1: Investigar los diferentes modelos orientados a objetos como base para la
identificacin de clases. ......................................................................................................... 65
Actividad 2: Desarrollar casos de uso y modelos CRC .................................................... 67
Ingeniera en Sistemas Computacionales
Pgina 3 de 154
GlobalTec
Documento Final
Actividad 3: Aplicar el modelo objeto-relacin comportamiento que indique como .... 69

Actividad 4: Aplicar al menos una Herramienta CASE para el anlisis ........................ 70
Unidad 4: Modelo de diseo ...................................................................................................... 71
Parte Terica .............................................................................................................................. 71
4.1 Estrategias de Diseo ..................................................................................................... 71
4.2 Diseo de Objetos ........................................................................................................... 73
4.3 Diseo de Sistema........................................................................................................... 75
4.4 Revisin del Diseo ......................................................................................................... 78
4.5 Diagramas de Secuencias del Diseo.......................................................................... 81
4.6 Herramientas CASE para el Diseo ............................................................................. 85
Actividad 1: Refinamiento a Clases ..................................................................................... 88
Actividad 2: Refinamiento a Subsistemas .......................................................................... 90
Actividad 3: Refinamiento a Diagrama de Colaboracin .................................................. 91
Actividad 4: Refinamiento Diagrama de componentes..................................................... 93
Actividad 5: Refinamiento de Diagrama de Actividades................................................... 94
Actividad 6: Refinamiento de Diagramas de Secuencias ................................................ 95
Actividad 7: Tabla comparativa mostrando las inconsistencias detectadas ............... 101
Actividad 8: Reporte de la estructura del sistema despus de haber realizado el
modelo de diseo en el caso de estudio........................................................................... 104
Actividad 9: Aplicar al menos una herramienta CASE para el diseo ......................... 105
Unidad 5: Modelo de implementacin .................................................................................. 106
Parte Terica ............................................................................................................................ 106
5.1 Diagramas de Componentes ....................................................................................... 106
5.2 Diagrama de despliegue ............................................................................................... 109
5.3 Modelos de pruebas ...................................................................................................... 112
Parte de Actividades .............................................................................................................. 115
Actividad 1: Aplicacin de Herramienta CASE Para Generar Cdigo ......................... 115
Actividad 2: Tcnicas de Prueba........................................................................................ 119
Actividad 3: Mtodos de implementacin de las empresas de desarrollo de software
................................................................................................................................................. 126
Referencias .................................................................................................................................. 129
Pgina 4 de 154
GlobalTec
Documento Final
Unidad 1 ..................................................................................................................................... 129

Unidad 2 ..................................................................................................................................... 130
Unidad 3 ..................................................................................................................................... 130
Unidad 4 ..................................................................................................................................... 131
Unidad 5 ..................................................................................................................................... 131
Anexos .......................................................................................................................................... 133
Anexo 1: Calendario ITZ (Pgina 1) ...................................................................................... 133
Anexo 1: Calendario ITZ (Pgina 2) ...................................................................................... 134
Anexo 2: Calendario SEP........................................................................................................ 135
Anexo 3: Manual del estudiante (Pgina 1) ......................................................................... 136
Anexo 4: O ISIC -2010-224 Fundamentos de Ingeniera de Software (Pgina 1) ......... 140
Anexo 5: Oficio de asignacin de proyecto .......................................................................... 149
Anexo 6: Hoja de proyecto (especificaciones del cliente, pgina 1) ................................ 150
Anexo 6: Hoja de proyecto (especificaciones del cliente, pgina 2) ................................ 151
Anexo 7: Examen escrito Unidad 1 Realizado por: Franklin Monreal Cristerna (pgina 1)
..................................................................................................................................................... 152
Anexo 7: Examen escrito Unidad 1 Realizado por: Franklin Monreal Cristerna (pgina 2)
..................................................................................................................................................... 153
Anexo 8: Programa de Actividades Realizadas durante el curso, organizadas a travs del
programa X-Mind .......................................................................................................................... 154
Pgina 5 de 154
GlobalTec
Documento Final
ndice de Figuras
Figura 2.- Linea del tiempo ........................................................................................................... 11
Figura 3.- Clasificacin basada en su integracin..................................................................... 18
Figura 4.- Especificacin ............................................................................................................... 33
Figura 5.- Casos de uso administrador ....................................................................................... 37
Figura 6.- Casos de uso Secretario ............................................................................................. 38
Figura 7.- Herramienta Case ........................................................................................................ 41
Figura 8: Configuracin segn modelo MVC ............................................................................. 42
Figura 9.- Diagrama de 3 dimensiones correspondiente a la arquitectura de clases.......... 43
Figura 10.- Descomposicin de la capa lgica de las aplicaciones ....................................... 44
Figura 11.- Estereotipo .................................................................................................................. 46
Figura 12.- Estereotipos correspondientes a las dimensiones de la arquitectura................ 46
Figura 13.- Los atributos esenciales y los sub tipos de una clase de anlisis. .................... 49
Figura 14.- Ejemplo de una clase de anlisis ............................................................................ 50
Figura 15.- La interfaz IU: La solicitud de pago se se usa para cubrir la interaccin entre el
actor Comprador y el caso de uso Pagar Factura..................................................................... 50
Figura 16.- La clase de Entidad Factura y su relacin con la interfaz de pago IU: Solicitud
de pago ............................................................................................................................................ 51
Figura 17.- La clase de Control, su relacin con los procesos empleados en diferentes
entidades ......................................................................................................................................... 51
Figura 18.- Tipo de mensajes ....................................................................................................... 52
Figura 19.- Muestra al conjunto bsico de smbolos del diagrama de secuencias, con los
smbolos en funcionamiento conjunto. ........................................................................................ 53
Figura 20.- Ejemplificacin de un diagrama de secuencias de instancia .............................. 53
Figura 21.- Ejemplificacin de un diagrama de secuencias genrico .................................... 54
Figura 22.- Mdulos principales ................................................................................................... 55
Figura 23.- Mdulos componentes de Registro ......................................................................... 56
Figura 24.- Mdulos componentes de Servicios ....................................................................... 57
Figura 25.- Mdulos componentes de Consultas ...................................................................... 59
Figura 26.- Ejemplificacin del uso de herramientas CASE para la elaboracin de casos
de uso ............................................................................................................................................... 63
Figura 27.- Ejemplificacin del uso de herramientas CASE para la elaboracin de
diagramas de secuencia ............................................................................................................... 63
Figura 28.- Ejemplificacin del uso de herramientas CASE para la elaboracin de
diagramas de implementacin...................................................................................................... 64
Figura 29.- Idea sistema UANL........................................................................................................... 66
Figura 30.- Casos de uso Administrador .................................................................................... 67
Figura 31.- Casos de uso Secretario ........................................................................................... 68
Figura 32.- Herramienta CASE .................................................................................................... 70
Figura 33.- Herramienta CASE .................................................................................................... 70
Figura 34.- Pirmide del diseo orientado a objetos ................................................................ 75
Figura 35.- Actividades del diseo orientado a objetos ............................................................ 76
Figura 36.- Ejemplificacin casos de uso ................................................................................... 81
37.- Representacin de un Objeto en un Diagrama de Secuencias. ..................................... 82
Pgina 6 de 154
GlobalTec
Documento Final
Figura 38.- Tipos de mensaje ....................................................................................................... 83

Figura 39.- Muestra al conjunto bsico de smbolos del diagrama de secuencias, con los
smbolos en funcionamiento conjunto ......................................................................................... 83
Figura 40.- Diagrama de secuencias .......................................................................................... 84
Figura 41.- Diagrama de secuencias genrico .......................................................................... 84
Figura 42.- Ejemplificacin casos de uso ................................................................................... 86
Figura 43.- Ejemplificacin diagramas de secuencia ............................................................... 86
Figura 44.- Ejemplificacin de diagrama de implementacin .................................................. 87
Figura 45.- Refinamiento a clases ............................................................................................... 88
Figura 46.- Refinamiento a clases ............................................................................................... 89
Figura 47.- Diagrama de Colaboracin ....................................................................................... 91
Figura 48.- Diagrama de Colaboracin ....................................................................................... 91
Figura 49.- Diagrama Refinado .................................................................................................... 92
Figura 50.- Diagrama de componentes ...................................................................................... 93
Figura 51.- Refinamiento de Diagrama Actividades.................................................................. 94
Figura 52.- Diagrama Secuencias Alumno ................................................................................. 96
Figura 53.- Diagrama Secuencias Equipo .................................................................................. 97
Figura 54.- Diagrama Secuencias Becas ................................................................................... 98
Figura 55.- Diagrama de secunacias pago ................................................................................ 99
Figura 56.- Diagrama Secuencias Usuarios ............................................................................ 100
Figura 57.- Herramienta CASE .................................................................................................. 105
Figura 58.- Diagrama de componentes .................................................................................... 106
Figura 59.- Representado Componentes ................................................................................. 107
Figura 60.- Componentes Requeridos ...................................................................................... 107
Figura 61.- Componente con puertos........................................................................................ 108
Figura 62.-Nodo ............................................................................................................................ 109
Figura 63.- Instancia de Nodo .................................................................................................... 109
Figura 64.- Estereotipo nodo ...................................................................................................... 109
Figura 65.- Artefacto..................................................................................................................... 110
Figura 66.- Modelo conexin ...................................................................................................... 110
Figura 67.- Modelo Incrustado.................................................................................................... 111
Figura 72.- Proceso de prueba................................................................................................... 120
Figura 73.- Proceso de prueba................................................................................................... 121
Figura 74.- Proceso de Prueba .................................................................................................. 121
Figura 75.- Proceso de Prueba .................................................................................................. 122
Figura 76.- Prueba de bluces ..................................................................................................... 123
Figura 77.- Evidencia ................................................................................................................... 127
Figura 78.- Evidencia ................................................................................................................... 127
Figura 79.- Modelo de prototipos ............................................................................................... 128
Pgina 7 de 154
GlobalTec
Documento Final
Unidad 1: Fundamentos de ingeniera de software.

Parte Terica y Parte de Actividades
1.1 Conceptos Bsicos
Glosario
Software.- Programas de computadoras y documentacin asociada, pueden ser
diseados por una sola persona, o por un grupo. Adems pueden ser genricos o
hechos a la medida para el cliente.
Los componentes lgicos incluyen, entre muchos otros, las aplicaciones
informticas; tales como el procesador de texto, que permite al usuario realizar
todas las tareas concernientes a la edicin de textos; el software de sistema, tal
como el sistema operativo, que, bsicamente, permite al resto de los programas
funcionar adecuadamente, facilitando tambin la interaccin entre los
componentes fsicos y el resto de las aplicaciones, y proporcionando
una interfaz con el usuario.
Equipamiento lgico o soporte lgico de un sistema informtico: Comprende
el conjunto de los componentes lgicos necesarios que hacen posible la
realizacin de tareas especficas, en contraposicin a los componentes fsicos,
que son llamados hardware.
Ingeniera.- Disciplina que utiliza todo tipo de recursos, sea humano, de
conocimiento, fsico, natural, financiero y de informacin, para crear y dirigir con
ciencia y arte, sistemas fsicos y sociales sustentables que proveen de bienes y
servicios, mediante el conocimiento y el perfeccionamiento de los atributos y
relaciones de dichos recursos, apoyada en las matemticas, ciencias naturales y
ciencias sociales con el fin de elevar la calidad de vida de la humanidad.
Ingeniera de Software.- Disciplina de la ingeniera que est conectada en todos
los aspectos al desarrollo de software. Los ingenieros de software deben adoptar
un enfoque sistemtico y organizado en su trabajo junto con el uso de
herramientas y tcnicas adecuadas dependiendo del problema a resolver, las
limitaciones de desarrollo y los recursos disponibles.
Informtica.- Tiene que ver con la teora y los fundamentos de la computacin.
Ingeniera en sistemas.- Enfoque interdisciplinario que permite estudiar y
comprender la realidad, con el propsito de implementar u optimizar
sistemas complejos. Los ingenieros de sistemas estn implicados en el sistema de
especificacin, diseo arquitectnico, la integracin y despliegue de los sistemas.
Proceso de creacin de software.- Un conjunto de actividades cuyo objetivo es
el desarrollo o evolucin de software, las partes principales son:
Especificacin.-Lo que el sistema debe hacer, su desarrollo y limitaciones.
Pgina 8 de 154
GlobalTec
Documento Final
Desarrollo.- Produccin del sistema de software.

Validacin.- Comprobar que el software es lo que el cliente quiere.
Evolucin.- Cambiar el software en respuesta a los cambios y demandas.
CASE.- Los sistemas de software que estn destinados a proporcionar soporte
automatizado para las actividades del proceso de software.
Sistema.- Una coleccin til de componentes interrelacionados para trabajar
juntos hacia un objetivo comn. Un sistema puede incluir software, mecnica,
hardware elctricos y electrnicos y estar en funcionamiento por la gente. Los
componentes del sistema son dependientes de los otros componentes del
sistema.
Modelado de arquitectura de sistema.- Un modelo arquitectnico presenta una
visin abstracta de los subsistemas que componen al sistema principal. Puede
incluir los principales flujos de informacin entre los subsistemas; generalmente se
presenta como un diagrama de bloques y este puede identificar los diferentes tipos
de relaciones funcionales y componentes en el modelo.
Programacin.- Es el proceso de disear, codificar, depurar y mantener el cdigo
fuente de programas computacionales. El cdigo fuente es escrito en un lenguaje
de programacin. El propsito de la programacin es crear programas que
exhiban un comportamiento deseado. Tambin se define como el proceso de
escribir cdigo que requiere frecuentemente de conocimientos en varias reas
distintas, adems del dominio del lenguaje a utilizar, algoritmos especializados y
lgica formal.
Depuracin.- Purificacin o correccin del cdigo en un sistema.
Validacin de software.- Verificacin y validacin que tiene por objeto mostrar
que un sistema se ajusta a su especificacin y cumple con los requisitos del
cliente del sistema.
Base de datos.- Coleccin de datos interrelacionados.
Dominio.- Es una red de identificacin asociada a un grupo de dispositivos o
equipos conectados a la red Internet.
Lenguaje de programacin.- Es un idioma artificial diseado para
expresar procesos que pueden ser llevados a cabo por mquinas como las
computadoras. Pueden usarse para crear programas que controlen el
comportamiento fsico y lgico de una mquina, para expresar algoritmos con
precisin, o como modo de comunicacin humana.
Interfaz.- Es la conexin entre dos ordenadores o mquinas de cualquier tipo
dando una comunicacin entre distintos niveles.
Pgina 9 de 154
GlobalTec
Documento Final
Documento.- Testimonio material de un hecho o acto realizado en el ejercicio de

sus funciones por instituciones o personas fsicas, jurdicas, pblicas o privadas,
registrado en una unidad de informacin en cualquier tipo de soporte en lengua
natural o convencional.
Mtodo.- Literalmente camino o va para llegar ms lejos tambin se le define
mtodo al modo ordenado y sistemtico de proceder para llegar a un resultado o
fin determinado. Las investigaciones cientficas se rigen por el llamado mtodo
griego, basado en la observacin y la experimentacin, la recopilacin de datos y
la comprobacin de las hiptesis de partida.
Mtodo VORD. Descubrir los puntos de vista que reciben servicios del sistema e identificar
los servicios prestados a cada punto de vista
Estructuracin de puntos de vista
Grupo de relacin de puntos de vista en una jerarqua. Los servicios
comunes son proporcionados a mayores niveles en la jerarqua
Mirador de documentacin
Perfeccionar la descripcin de los puntos de vista y prestaciones
determinadas
Punto de vista del sistema de asignacin
Transformar el anlisis a un diseo orientado a objetos
Escenario.- Los escenarios son descripciones de cmo un sistema es utilizado en
la prctica. Son tiles para obtencin de requisitos, comnmente se puede
identificar ms fcilmente que estos son la declaracin abstracta de lo que se
requiere en un sistema.
Los escenarios son particularmente tiles para aadir detalles a una descripcin
esquemtica de requisitos.
Excepciones.- Es la indicacin de alguna falla en el sistema.
Matriz.- Es un arreglo bidimensional de nmeros
Modelado del sistema.- Es una abstraccin del sistema que se est estudiando
en lugar de una representacin alternativa de ese sistema.
Mtodos estructurados.- Es una tcnica para escribir programas. Para ello se
utilizan nicamente tres estructuras: secuencia, seleccin e iteracin.
Dato.- Representacin simblica de una entidad.
Taxonoma.- Sistema de clasificacin
Pgina 10 de 154
GlobalTec
Documento Final
1.2 El Papel Evolutivo del Software

Lnea del Tiempo
Figura 1.- Linea del tiempo
Pgina 11 de 154
GlobalTec
Documento Final
1.3 Etapas del Desarrollo del Software

Cuadro Comparativo
Tabla 1. Tareas aplicadas en el desarrollo del software
Pgina 12 de 154
GlobalTec
Documento Final
1.4 Definicin e Historia de las Herramientas Case

Definicin
Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de
Software Asistida
por
Computadora)
son
diversas
aplicaciones
informticas destinadas a aumentar la productividad en el desarrollo de software
reduciendo el costo de las mismas en trminos de tiempo y de dinero.
Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de
desarrollo del software en tareas como el proceso de realizar un diseo del
proyecto, clculo de costos, implementacin de parte del cdigo automticamente
con el diseo dado, compilacin automtica, documentacin o deteccin de
errores entre otras, analiza la relacin existente entre los requisitos de un
problema y las necesidades que stos generaban, el lenguaje en cuestin se
denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a
buscar las necesidades de los diseadores PSA (Problem Statement Analyzer).
Tambin se puede definir una herramienta CASE como:
Conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo
de vida del desarrollo de sistemas de informacin, completamente o en alguna de
sus fases.
La sigla genrica para una serie de programas y una filosofa de desarrollo
de software que ayuda a automatizar el ciclo de vida de desarrollo de los
sistemas
La tecnologa CASE supone la automatizacin del desarrollo del software,
contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas
de informacin y se plantean los siguientes objetivos:
Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser

realizadas con una herramienta se consigue agilizar el trabajo.
Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones.
Simplificar el mantenimiento de los programas.
Mejorar y estandarizar la documentacin.
Aumentar la portabilidad de las aplicaciones.
Facilitar la reutilizacin de componentes de software.
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la
utilizacin de grficos.
Automatizar:
El desarrollo del software
La documentacin
La generacin del cdigo
El chequeo de errores
La gestin del proyecto
Pgina 13 de 154
GlobalTec
Documento Final
Permitir:
La reutilizacin del software
La portabilidad del software
La estandarizacin de la documentacin
Historia de las herramientas CASE:
Las Herramientas CASE tienen su inicio con el simple procesador de palabras que
fue usado para crear y manipular documentacin.
En la dcada de los 70s: El proyecto ISDOS desarroll un lenguaje llamado
"Problem Statement Language" (PSL) para la descripcin de los problemas de
usuarios y las necesidades de solucin de un sistema de informacin en un
diccionario
computarizado.
Problem Statement Analyzer (PSA) era
un producto asociado que analizaba la relacin de problemas y necesidades.
Los setentas vieron la introduccin de tcnicas grficas y diagramas de flujo de
estructuras de datos. Sobre este punto, el diseo y especificaciones en forma
pictrica han sido extremadamente complejos y consuman mucho tiempo para
realizar cambios.
La introduccin de las herramientas CASE para ayudar en este proceso ha
permitido que los diagramas puedan ser fcilmente creados y modificados,
mejorando la calidad de los diseos de software. Los diccionarios de datos, un
documento muy usado que mantiene los detalles de cada tipo de dato y los
procesos dentro de un sistema, son el resultado directo de la llegada del diseo de
flujo de datos y anlisis estructural, hecho posible a travs de las mejoras en las
Herramientas CASE.
Pronto se remplazaron los paquetes grficos por paquetes especializados que
habilitan la edicin, actualizacin e impresin en mltiples versiones de diseo.
Eventualmente, las herramientas grficas integradas con diccionarios de base de
datos para producir poderosos diseos y desarrollar herramientas, podran
sostener ciclos completos de diseo de documentos.
Como un paso final, la verificacin de errores y generadores de casos de pruebas
fueron incluidos para validar el diseo del software. Todos estos procesos pueden
haberse integrado en una simple herramienta CASE que soporta todo el ciclo de
desarrollo.
A inicios de los 80s: Empez a manejarse ms la ayuda en la documentacin por
medio de la computadora, se desarroll ms la diagramacin asistida por
computadora, el anlisis y el diseo.
A mediados de los 80s: Surgi el diseo automtico de anlisis y pruebas.
Mediante repositorios automticos de informacin de sistemas.
Pgina 14 de 154
GlobalTec
Documento Final
La primera herramienta comercial se remonta a 1982, aunque algunos

especialistas indican que algunos ejemplos de herramientas para diagramacin ya
existan en las herramientas CASE.
La primera herramienta CASE como hoy la conocemos fue "Excelerator" en 1984,
la cual era para PC. Actualmente la oferta de herramientas CASE es muy amplia y
tenemos por ejemplo el EASYCASE o WINPROJECT.
No fue sino hasta 1985 en que las herramientas CASE se volvieron realmente
importantes en el proceso de desarrollo de software. Los proveedores prometieron
a la Industria que muchas actividades seran beneficiadas por la ayuda de las
herramientas CASE.
Estos beneficios consistan, por ejemplo, en el aumento en la productividad. El
objetivo en 1985 para muchos vendedores era producir software ms
rpidamente.
Al final de los 80s: Surgi la generacin automtica de cdigo desde
especificaciones de diseo
A inicios de los 90s: Las herramientas CASE alcanzaron su techo a principios de
los aos 90. En la poca en la que IBM haba conseguido una alianza con la
empresa de software AD/Cycle para trabajar con sus mainframes, estos dos
gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida
del software. Pero poco a poco los mainframes han ido siendo menos utilizados y
actualmente el mercado de las Big CASE ha muerto completamente abriendo el
mercado de diversas herramientas ms especficas para cada fase del ciclo de
vida del software.
Las herramientas del CASE seran una familia de mtodos favorablemente
estructurados para planeamiento, anlisis y diseo. Esto llevara a la generacin
automtica de cdigo para desarrollo de software va una especificacin
formalmente diseada. Esto traera como beneficio:
Una mejora en la calidad, fiabilidad, utilidad y rendimiento.

El entorno de produccin de documentacin para software mejora la
comunicacin, mantenimiento y actualizacin.
Hace el trabajo de diseo de software ms fcil y agradable.
La promesa futura podra remplazar realmente a los ingenieros de software
especializados.
Reduccin del costo de produccin de software.
Pgina 15 de 154
GlobalTec
Documento Final
1.5 Clasificacin de las Herramientas CASE

No existe una nica clasificacin de herramientas CASE y en ocasiones, es difcil
incluirlas en una clase determinada. Podran clasificarse atendiendo a:
Las plataformas que soportan.

Las fases del ciclo de vida del desarrollo de sistemas que cubren.
La arquitectura de las aplicaciones que producen.
Su funcionalidad
1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado):

abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son
llamadas tambin CASE Workbench.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o frontend, orientadas a la automatizacin y soporte de las actividades
desarrolladas durante las primeras fases del desarrollo: anlisis y diseo.
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o backend, dirigidas a las ltimas fases del desarrollo: construccin e
implantacin.
4. Juegos de herramientas o Tools-Case, son el tipo ms simple de
herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro
de este grupo se encontraran las herramientas de reingeniera, orientadas
a la fase de mantenimiento.
Pgina 16 de 154
GlobalTec
Documento Final
Clasificacin basada en su funcionalidad

Tipo de Herramienta
Planificacin
Edicin de los Editores
Gestin de Cambio
Gestin de Configuracin
Prototipos
Mtodo de Herramientas de apoyo
Procesamiento del Lenguaje
Programa de anlisis
Pruebas
Depuracin
Documentacin
Reingeniera
Ejemplos
Herramientas PERT, Herramientas de Estimacin,
Hojas de Calculo
Herramientas de texto, editores de diagramas,
procesadores de palabras
Herramientas de requisitos de trazabilidad, cambio
de sistemas control
Sistema de gestin de versiones, sistemas de
herramientas de construccin
Verificador de lenguajes de alto nivel, generador de
interfaces de usuarios
Editores de diseo, diccionarios de datos,
generadores de cdigo
Compiladores, Interpretes
Generadores de referencia cruzada, analizadores
de esttica, analizadores dinmicos
Generadores de datos de pruebas ,Comparadores
de archivos
Sistemas de depuracin interactiva,
Diseo de pginas, programas editores de
imgenes
Referencias cruzadas de sistemas, programa para
la restructuracin de sistemas
Tabla 2. Calificacin basada en su funcionalidad
Pgina 17 de 154
GlobalTec
Documento Final
Clasificacin basada en el ciclo de vida del desarrollo de sistemas que cubren

Tipo de Herramienta de:
Especificacin
Diseo
Reingeniera
Prueba
Depuracin
Anlisis de Programa
Procesamiento de lenguaje
Herramientas de apoyo
Prototipos
Gestin de Configuracin
Gestin de Cambio
Documentacin
Edicin
Planificacin
Implementacin Verificacin
y Validacin
Tabla 3. Calificacin basada en el ciclo de vida del desarrollo de sistemas que cubren
Clasificacin basada en su integracin
Figura 2.- Clasificacin basada en su integracin
Pgina 18 de 154
GlobalTec
Documento Final
Unidad 2: Ingeniera de requisitos

Parte Terica
2.1 Tareas de la Ingeniera de Requisitos
A travs de los aos se ha podido constatar que los requerimientos o requisitos
son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan
el punto de partida para actividades como la planeacin, bsicamente en lo que se
refiere a las estimaciones de tiempos y costos, as como la definicin de recursos
necesarios y la elaboracin de cronogramas que ser uno de los principales
mecanismos de control con los que se contar durante la etapa de desarrollo.
La Ingeniera de Requerimientos (IR) cumple un papel primordial en el proceso de
produccin de software, ya que se enfoca un rea fundamental: la definicin de lo
que se desea producir. Su principal tarea consiste en la generacin de
especificaciones correctas que describan con claridad, sin ambigedades, en
forma consistente y compacta, las necesidades de los usuarios o clientes; de esta
manera, se pretende minimizar los problemas relacionados por la mala gestin de
los requerimientos en el desarrollo de sistemas.
Actividades de la ingeniera de requerimientos
Se dice que dentro de la IR existen cuatro actividades bsicas que se tienen que
llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la
importancia que tiene para el desarrollo de un proyecto de software realizar una
especificacin y administracin adecuada de los requerimientos de los clientes o
usuarios. Las cuatro actividades son:
Extraccin
Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre
comnmente dado a las actividades involucradas en el descubrimiento de los
requerimientos del sistema. Aqu, los analistas de requerimientos deben trabajar
junto al cliente para descubrir el problema que el sistema debe resolver, los
diferentes servicios que el sistema debe prestar, las restricciones que se pueden
presentar, etc. Es importante, que la extraccin sea efectiva, ya que la
aceptacin del sistema depender de cuan bien ste satisfaga las necesidades del
cliente.
Anlisis
Sobre la base de la extraccin realizada previamente, comienza esta fase en la
cual se enfoca en descubrir problemas con los requerimientos del sistema
identificados hasta el momento. Usualmente se hace un anlisis luego de haber
producido un bosquejo inicial del documento de requerimientos; en esta etapa se
leen los requerimientos, se conceptan, se investigan, se intercambian ideas con
Pgina 19 de 154
GlobalTec
Documento Final
el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones,

y luego se van fijando reuniones con el cliente para discutir los requerimientos.
Especificacin
En esta fase se documentan los requerimientos acordados con el cliente, en un
nivel apropiado de detalle. En la prctica, esta etapa se va realizando
conjuntamente con el anlisis, se puede decir que la especificacin es el "pasar en
limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de
documentacin, como la notacin UML (Lenguaje de Modelado Unificado), que es
un estndar para el modelado orientado a objetos, por lo que los casos de uso y la
obtencin de requerimientos basada en casos de uso se utiliza cada vez ms para
la obtencin de requerimientos.
Validacin
La validacin es la etapa final de la IR. Su objetivo es, ratificar los requerimientos,
es decir, verificar todos los requerimientos que aparecen en el documento
especificado para asegurarse que representan una descripcin, por lo menos,
aceptable del sistema que se debe implementar. Esto implica verificar que los
requerimientos sean consistentes y que estn completos.
Se puede apreciar que el proceso de ingeniera de requerimientos es un conjunto
estructurado de actividades, mediante las cuales se obtiene, se valida y se logra
dar un mantenimiento adecuado al documento de especificacin de
requerimientos, que es el documento final, de carcter formal, que se obtiene de
este proceso. Es necesario recalcar que no existe un proceso nico que sea vlido
de aplicar en todas las organizaciones. Cada organizacin debe desarrollar su
propio proceso de acuerdo al tipo de producto que se est desarrollando, a la
cultura organizacional, y al nivel de experiencia y habilidad de las personas
involucradas en la ingeniera de requerimientos. Hay muchas maneras de
organizar el proceso de ingeniera de requerimientos y en otras ocasiones se tiene
la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva ms
objetiva que las personas involucradas en el proceso.
Pgina 20 de 154
GlobalTec
Documento Final
2.2 Tcnicas de la Ingeniera de Requisitos

La ingeniera de requisitos puede ser un proceso largo y arduo para el que se
requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y
las relaciones entre la gente, as que es importante identificar a todos los actores
involucrados, considerar sus necesidades y asegurar que entienden las
implicaciones de los nuevos sistemas. Los analistas pueden emplear varias
tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido
tcnicas tales como las entrevistas, o talleres con grupos para crear listas de
requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso.
Cuando sea necesario, el analista emplear una combinacin de estos mtodos
para establecer los requisitos exactos de las personas implicadas, para producir
un sistema que resuelva las necesidades del negocio.
Entrevistas
Las entrevistas y cuestionarios son un mtodo comn y se emplean para reunir
informacin proveniente de personas o de grupos. Durante la entrevista, el
analista conversa con el encuestado; el cuestionario consiste en una serie de
preguntas relacionadas con varios aspectos de un sistema.
Por lo comn, los encuestados son usuarios de los sistemas existentes o usuarios
en potencia del sistema propuesto. En algunos casos, son gerentes o empleados
que proporcionan datos para el sistema propuesto o que sern afectados por l, e
incluso aquellas personas que harn un uso ms frecuente del nuevo sistema.
Las preguntas que deben realizarse en esta tcnica, deben ser preguntas de alto
nivel y abstractas que pueden realizarse al inicio del proyecto para obtener
informacin sobre aspectos globales del problema del usuario y soluciones
potenciales.
Las preguntas pueden ser enfocadas especficamente a un elemento del sistema
como por ejemplo:
Hacia el usuario
Quin es el cliente?
Quin es el usuario?
Son sus necesidades diferentes?
Cules son sus habilidades, capacidades, ambiente?
Pgina 21 de 154
GlobalTec
Documento Final
Hacia el proceso
Cul es la razn por la que se quiere resolver este problema?
Cul es el valor de una solucin exitosa?
Cmo usted resuelve el problema actualmente?
Qu retrasos ocurren o pueden ocurrir?
Hacia el producto
Qu problemas podra causar este producto en el negocio?
En qu ambiente se usar el producto?
Cules son sus expectativas para los conceptos fcil de usar, confiable,
rendimiento?
Qu obstculos afectan la eficiencia del sistema?
Lluvia de Ideas
Este mtodo comenz en el mbito de las empresas, aplicndose a temas tan
variados como la productividad, la necesidad de encontrar nuevas ideas y
soluciones para los productos del mercado, encontrar nuevos mtodos que
desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se
extendi a otros mbitos, incluyendo el mundo de desarrollo de sistemas;
bsicamente se busca que los involucrados en un proyecto desarrollen su
creatividad, promoviendo la introduccin de los principios creativos.
Principios de la lluvia de ideas
Aplazar el juicio y no realizar crticas, hasta que no agoten las ideas, ya que
actuara como un inhibidor. Se ha de crear una atmsfera de trabajo en la
que nadie se sienta amenazado.
Cuantas ms ideas se sugieren, mejores resultados se conseguirn: "la
cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo
de produccin de ideas, ser ms fcil que encontremos las soluciones y
tendremos ms variedad sobre la que elegir.
La produccin de ideas en grupos puede ser ms efectiva que la individual.
Tampoco debemos olvidar que durante las sesiones, las ideas de una
persona, sern asociadas de manera distinta por cada miembro, y har que
aparezcan otras por contacto.
Pgina 22 de 154
GlobalTec
Documento Final
El equipo en una lluvia de ideas debe estar formado por:

El Director: es la figura principal y el encargado de dirigir la sesin.
El secretario: registra por escrito las ideas segn van surgiendo.
Los participantes: pueden ser habituales o invitados; cualquier involucrado en
el proyecto entra en esta categora.
Fases de aplicacin de la lluvia de ideas:
Descubrir hechos: Se determina el problema, delimitndolo, precisndolo y
clarificndolo.
Producir ideas: Se busca producir una gran cantidad de ideas, aplicando los
principios de la lluvia de ideas.
Descubrir soluciones: Se elabora una lista definitiva de ideas, para
seleccionar las ms interesantes.
Prototipos
Los prototipos permiten al desarrollador crear un modelo del software que debe
ser construido. Es una pequea muestra, de funcionalidad limitada, de cmo sera
el producto final una vez terminado. El prototipo es evaluado por el cliente y el
usuario y utilizado para refinar los requerimientos del software a ser desarrollado.
Un proceso de iteracin tiene lugar a medida que el prototipo es "puesto a punto"
para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una
mejor comprensin del problema por parte del desarrollador. Adems ayudan a
conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al
producto terminado.
Existen principalmente dos tipos de prototipos:
Prototipo rpido (Fast prototype): El prototipo rpido es un mecanismo para lograr
la validacin pre-compromiso. Se utiliza para validar requerimientos en una etapa
previa al diseo especfico. En este sentido, el prototipo puede ser visto como una
aceptacin tcita de que los requerimientos no son totalmente conocidos o
entendidos antes del diseo y la implementacin. El prototipo rpido puede ser
usado como un medio para explorar nuevos requerimientos y as ayudar a
"controlar" su constante evolucin.
Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un
producto puede ser visto como una serie incremental de detallados prototipos
acumulativos. El punto de vista evolutivo del ciclo de vida del software considera a
la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras
subsecuentes resultan en nuevas entregas de prototipos ms maduros. Este
Pgina 23 de 154
GlobalTec
Documento Final
proceso contina hasta que se haya desarrollado el producto final. La adopcin de

esta ptica elimina la distincin arbitraria entre desarrollo y mantenimiento,
resultando en un importante cambio de mentalidad que afecta las estrategias para
la estimacin de costos, enfoques de desarrollo y adquisicin de productos.
Proceso de Anlisis Jerrquico (AHP)
Esta tcnica tiene por objetivo resolver problemas cuantitativos, para facilitar el
pensamiento analtico y las mtricas. Consiste en una serie de pasos a saber:
Encontrar los requerimientos que van a ser priorizados.

Combinar los requerimientos en las filas y columnas de la matriz n x n de
AHP.
Hacer algunas comparaciones de los requerimientos en la matriz
Sumar las columnas
Normalizar la suma de las filas
Calcular los promedios
Estos pasos pueden aplicarse fcilmente a una cantidad pequea de

requerimientos, sin embargo, para un volumen grande, esta tcnica no es la ms
adecuada.
Casos de uso
Un caso de uso es una tcnica para documentar posibles requisitos, graficando la
relacin del sistema con los usuarios u otros sistemas. Es una forma de expresar
cmo alguien o algo externo a un sistema lo usa. Cuando decimos "alguien o algo"
hacemos referencia a que los sistemas son usados no slo por personas, sino
tambin por otros sistemas de hardware y software. Dado que el propio sistema
aparece como una caja negra, y slo se representa su interaccin con entidades
externas, permite omitir dichos aspectos y determinar los que realmente
corresponden a las entidades externas. El objetivo de esta prctica es mejorar la
comunicacin entre los usuarios y los desarrolladores, mediante la prueba
temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir
los costes finales. Los casos de uso tienen las siguientes caractersticas:
Estn expresados desde el punto de vista del actor.
Se documentan con texto informal.
Describen tanto lo que hace el actor como lo que hace el sistema cuando
interacta con l, aunque el nfasis est puesto en la interaccin.
Son iniciados por un nico actor.
Estn acotados al uso de una determinada funcionalidad del sistema, claramente
diferenciada.
Pgina 24 de 154
GlobalTec
Documento Final
Esta tcnica se enfrenta a los siguientes peligros potenciales:

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda
mucho trabajo por hacer para completar el diseo final.
Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder
el tiempo al comenzar otra vez.
Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz
de usuario. Sin embargo, no proporcionan explcitamente cules son los
requisitos.
Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo
de la interfaz de usuario y demasiado poco en producir un sistema que sirva el
proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con
funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el
software final tenga diseo grfico, se realizan en una variedad de documentos de
diseo grficos y a menudo elimina todo el color del diseo del software (es decir
utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la
apariencia final de la aplicacin.
Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las
personas implicadas individuales y que a menudo no se descubren en las
entrevistas o quedan incompletamente definidas durante la misma. Estas
implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado,
talleres facilitados por un analista del negocio, en donde las personas implicadas
participan en discusiones para descubrir requisitos, analizan sus detalles y las
implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a
la documentacin de la discusin, liberando al analista del negocio para centrarse
en el proceso de la definicin de los requisitos y para dirigir la discusin.
Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los
requisitos. En sistemas muy complejos stos pueden tener centenares de pginas.
Objetivos medibles
Los requisitos formulados por los usuarios se toman como objetivos generales, a
largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de
vista del sistema hasta determinar los objetivos crticos del funcionamiento interno
que luego darn forma a los comportamientos apreciables por el usuario. Luego,
se establecen formas de medir el progreso en la construccin, para evaluar en
cualquier momento qu tan avanzado se encuentra el proyecto.
Pgina 25 de 154
GlobalTec
Documento Final
2.3 Modelado de Requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la
funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo
puede funcionar como un contrato entre el desarrollador y el cliente o usuario del
sistema, y por lo tanto proyecta lo que el cliente desea segn la percepcin del
desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este
modelo.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base
para la formacin de todos los dems modelos en el desarrollo de software. En
general, cualquier cambio en la funcionalidad del sistema es ms fcil de hacer, y
con menores consecuencias, a este nivel que posteriormente. El modelo de
requisitos que desarrollaremos se basa en la metodologa Objectory (Jacobson et
al. 1992), basada principalmente en el modelo de casos de uso. Actualmente esta
metodologa es parte del Proceso Unificado de Rational (RUP).
Requisitos: El modelo de casos de uso sirve para expresar el modelo de
requisitos, el cual se desarrolla en cooperacin con otros modelos como se ver
ms adelante.
Anlisis: La funcionalidad especificada por el modelo de casos de uso se
estructura en el modelo de anlisis, que es estable con respecto a cambios,
siendo un modelo lgico independiente del ambiente de implementacin.
Diseo: La funcionalidad de los casos de uso ya estructurada por el anlisis es
realizada por el modelo de diseo, adaptndose al ambiente de implementacin
real y refinndose an ms.
Implementacin: Los casos de uso son implementados mediante el cdigo fuente
en el modelo de implementacin.
Pruebas: Los casos de uso son probados a travs de las pruebas de
componentes y pruebas de integracin.
Documentacin: El modelo de casos de uso debe ser documentado a lo largo de
las diversas actividades, dando lugar a distintos documentos como los manuales
de usuario, manuales de administracin, etc.
El propsito del modelo de requisitos es comprender completamente el problema y
sus implicaciones. Todos los modelos no solamente se verifican contra el modelo
de requisitos, sino que tambin se desarrollan directamente de l. El modelo de
requisitos sirve tambin como base para el desarrollo de las instrucciones
operacionales y los manuales ya que todo lo que el sistema deba hacer se
Pgina 26 de 154
GlobalTec
Documento Final
describe aqu desde la perspectiva del usuario. El modelo de requisitos no es un

proceso mecnico, el analista debe interactuar constantemente con el cliente para
completar la informacin faltante, y as clarificar ambigedades e inconsistencias.
El analista debe separar entre los requisitos verdaderos y las decisiones
relacionadas con el diseo e implementacin. Se debe indicar cuales aspectos son
obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la
implementacin. Durante el diseo se debe extender el modelo de requisitos con
especificaciones de rendimiento y protocolos de interaccin con sistemas
externos, al igual que provisiones sobre modularidad y futuras extensiones. En
ciertas ocasiones ya se puede incluir aspectos de diseo, como el uso de
lenguajes de programacin particulares.
En la metodologa de Objectory, el modelo de requisitos consiste de tres modelos
principales, visualmente representado por un diagrama de tres dimensiones.
El modelo de comportamiento, basado directamente en el modelo de casos de
uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del
usuario. Este modelo utiliza dos conceptos claves: actores para representar los
distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso
para representar qu pueden hacer los actores con respecto al sistema
El modelo de presentacin o modelo de interfaces o borde especifica cmo
interacta el sistema con actores externos al ejecutar los casos de uso, en
particular, en los sistemas de informacin ricos en interaccin con el usuario,
especifica cmo se vern visualmente las interfaces grficas y que funcionalidad
ofrecer cada una de ellas.
El modelo de informacin o modelo del dominio del problema especifica los
aspectos estructurales del sistema.
Este modelo conceptualiza el sistema segn los objetos que representan las
entidades bsicas de la aplicacin. Aunque en muchas metodologas se permite
especificar la funcionalidad completa del sistema utilizando el modelo del dominio
del problema, incluyendo operaciones formales sobre los objetos correspondientes
a un modelo de requisitos expresado sin casos de uso, el modelo del dominio del
problema ser de mucha ms ayuda como apoyo al modelo de casos de uso y no
como una entidad totalmente independiente.
Es importante resaltar que esta separacin en tres ejes de modelado
independientes es la base para una mayor estabilidad en el desarrollo del sistema,
permitiendo minimizar los efectos de cada uno sobre los otros dos.
Pgina 27 de 154
GlobalTec
Documento Final
2.4 Herramientas CASE para la Ingeniera de Requisitos

De acuerdo con Kendall y Kendall la Ingeniera de Sistemas asistida por
computadora es la aplicacin de tecnologa informtica a las actividades, las
tcnicas y las metodologas propias de desarrollo, su objetivo es acelerar el
proceso para el que han sido diseadas, en el caso de CASE para automatizar o
apoyar una o ms fases del ciclo de vida del desarrollo de sistemas.
Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de
vida de las aplicaciones de bases de datos, tambin se puede escoger una
herramienta CASE que permita llevar a cabo el resto de tareas del modo ms
eficiente y efectivo posible. Una herramienta CASE suele incluir:
Herramientas de diseo para dar apoyo al anlisis de datos.

Herramientas que permitan desarrollar el modelo de datos corporativo, as
como los esquemas conceptual y lgico.
Herramientas para desarrollar los prototipos de las aplicaciones.
Con el nimo de facilitar las tareas del desarrollo de software, surgen herramientas
informticas que agilizan la labor en la IR. Dichas herramientas son denominadas
CASE (Ingeniera de software asistida por computador), y sirven de apoyo para los
desarrolladores, desde el principio hasta el final del proceso.
Para el caso particular de esta investigacin, son de especial inters aquellos
instrumentos que se encargan de actividades como: extraer, analizar, documentar,
revisar, negociar y validar los requisitos del sistema objeto de estudio.
Herramientas CASE, hacia una Ingeniera de Requisitos computarizada
A medida que pasa el tiempo se logra entender que el empleo del software es una
buena opcin para agilizar y sistematizar las tareas en el desarrollo de procesos.
El desarrollo de software no es la excepcin; en este caso dichas herramientas se
han denominado CASE (Ingeniera De Software Asistida Por Computador). Estas
incluyen un conjunto de programas que facilitan la optimizacin de un producto
ofreciendo apoyo permanente a los analistas, ingenieros de software y
desarrolladores. CASE es la aplicacin de mtodos y tcnicas que dan utilidades a
los programas, por medio de otros, procedimientos y su respectiva
documentacin. En esta investigacin se hace referencia a las herramientas que
ayudan a la gestin de requisitos; es decir al proceso de identificacin, asignacin
y seguimiento de los mismos, incluyendo interfaz, verificacin, modificacin y
control de cada requisito, durante el ciclo de vida del proyecto. Los cambios y
actualizaciones de requisitos deben ser gestionados para asegurar que se
mantenga la calidad del producto.
Pgina 28 de 154
GlobalTec
Documento Final
Hasta hace poco tiempo las herramientas para la gestin de requisitos de software
se limitaban a editores de texto, los cuales hacan de esta tarea una labor tediosa
y confusa. Actualmente, se cuenta con mltiples opciones, como las que se
mencionan a continuacin:
IRQA 43
Herramienta CASE de Ingeniera de Requisitos, diseada para soportar las
actividades realizadas en el proceso de especificacin de sistemas. sta facilita y
formaliza la comunicacin entre el cliente, el proveedor y los distintos miembros
del equipo de desarrollo. Facilita la captura, organizacin y anlisis de las
condiciones, as como la especificacin de la solucin mediante el apoyo
metodolgico adaptable a cada cliente.
RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos
funcionales del sistema; bsicamente, mediante tres tcnicas complementarias
entre s: la definicin de la Misin del Sistema, la construccin del rbol de
Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Adems,
se introduce un Proceso de Anlisis que permite traducir el Modelo de Requisitos
en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y propiciando
una representacin de la informacin en el segundo prototipo.
CONTROLA
Herramienta de apoyo al proceso de ingeniera de software en pequeas
empresas. Se cre gracias a la expansin que tuvo el mercado y a la generacin
de grandes y pequeas empresas, las cuales requieren un instrumento para el
desarrollo de sus proyectos.
Ofrece recursos importantes tales como: Administracin de requisitos,
administracin de casos de uso, administracin de casos de prueba y error,
planeamiento de liberaciones, administracin de implementaciones, control de
dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de
los requisitos.
OSRMT (Open Source Requirements Management Tool)
Herramienta libre para la gestin de requisitos, cuyas principales caractersticas
son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versin 1.3
trae un mdulo para manejar la trazabilidad y lo introduce para el control de
cambios; as mismo, genera la documentacin de los requisitos tratados.
JEREMIA5
Se trata exclusivamente de una aplicacin cliente exclusivamente, lo cual no
permite la posibilidad de trabajar en equipo. sta, ayuda durante el desarrollo del
Pgina 29 de 154
GlobalTec
Documento Final
sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo

del ciclo de vida. Con JEREMIA es posible captar las necesidades, analizarlas y
clasificarlas. Implementa un mdulo orientado a la generacin de la
documentacin posible de exportar en formato DocBook XML, la cual junto con los
requisitos, se almacena en una base de datos en MySQL.
RAMBUTAN6
Esta herramienta est basada en XML, realmente consta de un conjunto de
aplicaciones para el usuario final, ayudando a los analistas de sistemas en la
recopilacin y categorizacin de hechos en un documento de especificacin de
requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza
para recopilar los hechos en el lugar donde est ubicado el cliente mientras que la
aplicacin de escritorio recibe la informacin, edita y perfecciona. Ambas
aplicaciones permiten al usuario introducir, modificar y visualizar los datos que
componen un documento de especificacin de requisitos.
Comparada con otras herramientas de gestin de requisitos, Rambutan ofrece las
siguientes ventajas competitivas: Aplicacin cliente para palm (PDAclass),
portabilidad entre plataformas, es independiente de cualquier metodologa de
especificacin de requisitos, y permite distribucin libre. Existen otras
herramientas en estudios para la gestin de requisitos. A continuacin se
mencionan, algunas de las incluidas en el estudio comparativo presentado por El
Consejo Internacional sobre la Ingeniera de Sistemas (INCOSE)7:
CaliberRM, REM, SMART TRACE, SoftREQ, Analyst Real Team System (ARTS),
CARE 3.2, CORE 5.1, Cradle 5.2, Envision VIP, Gatherspace, IBM Rational
RequisitePro, KollabNet Editor 2005, PACE, RaQuest 3.0, RMTrak, RTM, SLATE
REquire 6.5, SoftREQ, UGS Teamcenter 2005, truereq product desktop, XTie-RT,
Specification Analysis Tool (SAT), ECM, Banyan2.2, Contour, Projectricity 3.5,
FeaturePlan 2.6, analyst pro, ChangeWare 2.0, aligned elements, Dassault
Systemes CSE 4.0, Polarion ALM for Subversion 3.0, Telelogic DOORS, Accept
360.
Pgina 30 de 154
GlobalTec
Documento Final
Parte de Actividades
Actividad 3: Documentar en un caso de desarrollo las distintas tareas de la
ingeniera de requerimientos.
Sistema para la Academia Oficial de Tigres de la UANL
Boleta de Pagos
Extraccin
Primero que nada contactar al cliente para hablar sobre lo que quiere y espera del
sistema. El proyecto consiste en elaborar una base de datos mediante la cual se
pueda llevar el control de los alumnos que ingresa al club deportivo, este sistema
debe contar con:
Nombre del alumno (nombre completo del aspirante)

Edad (aos cumplidos a la fecha, sujeto a actualizaciones continuas)
Fecha de nacimiento (fecha con formato da/mes/ao)
Beca (tipo de la beca y monto asignado)
Descuentos (solo si se cuenta con un hermano que este registrado ya en el
equipo o se suscriban al mismo tiempo ambos)
Los puntos anteriormente mencionados son aquellos con los que el cliente espera
cuente su sistema pero debemos tomar en cuenta tambin los siguientes puntos
importantes:
En cuento a pagos:
Las colegiaturas sern pagadas en las fechas estipuladas.

A partir del 5to da hbil el pago se considerara tardo y se generara un 6%
de recargos mensuales.
Si se tiene beca se podr conservar solo si sus pagos son estrictamente
puntuales.
El pago de la inscripcin es anual.
Se podr suspender a aquel alumno que retrase sus pagos.
No participaran alumnos en torneos con adeudos al torneo anual de
Academias.
Pgina 31 de 154
GlobalTec
Documento Final
Otros requisitos obligatorios:
La credencial es obligatoria con vigencia al ciclo anual.

Adquirir y usar uniforme de forma obligatoria y reponerlo en casi de estar en
mal estado.
Se requieren como mnimo 12 alumnos para abrir un grupo.
Antes de abandonar la academia se debe dar un aviso con 15 das de
anticipacin y una carta que explique el motivo.
Anlisis
De acuerdo a la informacin extrada del cliente se puede optar por crear un
generador de claves para cada alumno inscrito o bien hacer uso de su CURP para
evitar as el duplicado de datos, otra observacin es agregar el nombre y horario
del equipo asignado as como el entrenador a cargo para llevar un seguimiento
ms especfico del alumno, pueden existir confusiones u olvidos en cuanto a las
fechas de pago as que se puede crear un calendario en el cual los alumnos
puedan darle seguimiento diario a sus fechas de beca, sus montos a pagar y el
descuento hecho de acuerdo a su beca todo esto por va internet y en un link
asignado en la pgina oficial al cual podrn ingresar con un nombre y contrasea
de usuario. Se puede asignar tambin un apartado en donde el entrenador escriba
semanalmente una evaluacin del alumno el cual contenga (comportamiento,
cumplimiento con horas de llegada y asistencias, porte de uniforme, uso de
credencial, desempeo en el entrenamiento, calificacin asignada semanal).
Clave del alumno

Calendario de pagos
Reporte de entrenador
Pgina 32 de 154
GlobalTec
Documento Final
Especificacin
Figura 3.- Especificacin

Validacin
Verificando los datos que anteriormente se revisaron se hace un ltimo anlisis en
el cual se rectifica los datos deseados:
Informacin completa del alumno (clave, nombre, edad, fecha de

nacimiento), es la informacin bsica y necesaria de cada alumno.
Pagos (beca, calendario, monto a pagar y descuentos adems de sus extra
contenidos como tipo y monto de la beca y las fechas de pago de beca y
pago anual de la colegiatura del equipo), aqu todos los pagos y fechas que
se le harn y har el alumno segn le corresponda.
Informacin completa sobre el equipo al que pertenece (nmero mnimo de
alumnos validados con un mnimo de 12, el nombre y el entrenador a
cargo), es la informacin bsica del equipo al que pertenece el alumno.
Historial de alumno (comportamiento, puntualidad, calificacin y
cumplimiento en cuanto al uso de credencial y porte de uniforme), es una
pequea evaluacin del alumno por parte del entrenador para evitar
sanciones y poder tener un pequeo historial de su instancia en el equipo.
Pgina 33 de 154
GlobalTec
Documento Final
Actividad 5: Tcnicas de la Ingeniera de Requisitos

Entrevistas y Cuestionarios
1. A qu tipo de tipo de pblico est dirigida la empresa (Gnero, Edad)?
2. Quines son los usuarios principales o ms significativos del sistema?
3. Cules son las necesidades principales que requiere el sistema?
4. Cules son sus habilidades, capacidades, y/o cualidades del personal?
5. Cul es la razn por la que se quiere resolver u optimizar este problema?
6. Qu valor para la empresa o de qu manera afectara el resultado del
sistema a la empresa?
7. De qu manera se est resolviendo el problema actualmente?
8. Qu retrasos o problemas ocurren actualmente?
9. Cules son sus expectativas para los conceptos fcil uso, confiabilidad,
rendimiento?
10. Qu obstculos afectan la eficiencia del sistema?
11. Se considera importante el control de toda la empresa o de algn sector
en particular?
12. Influye de alguna manera la elaboracin de actividades en tiempo y forma
dentro de la empresa?
Pgina 34 de 154
GlobalTec
Documento Final
Lluvia de ideas
Director: Franklin Monreal Cristerna

Secretario: Alfredo Pablo Hernndez
Auditores: Bernardo Dvila
Cinthia Ramrez
Lezly Norman
Problema
El proyecto consiste en elaborar una base de datos mediante la cual se pueda
llevar el control de los alumnos que ingresa al club deportivo, este sistema debe
contar con:

Ideas Planteadas:
Crear una base de datos de bien elaborada y con un manejo simple

mediante una interfaz grafica
Dividir los alumnos del sistema en categoras
Crear una base de datos alterna para el manejo de datos secundarios en el
sistema
Tener un control sobre fechas y pagos
Uso de identificaciones o ID para cada integrante del sistema en general
Hacer el uso de un generador de claves para la identificacin de los
integrantes del sistema
Hacer uso de la CURP como clave de identificacin secundaria para el
sistema
Tener un control sobre docentes o instructores, asi como cada una de las
actividades que este realizar
Tener un calendario para el sistema en general
Hacer uso de internet para el control de fechas de los alumnos
Tener un usuario y contrasea alterno a su ID para la consulta de fechas
dentro del sistema
Pgina 35 de 154
GlobalTec
Documento Final
Tener un registro de actividades sobre evaluaciones, asistencias,

desempeo, etc.
Hacer uso del control de asistencia para mayor control sobre los alumnos
Tener una bitcora o historial de cada alumno
Algunas ideas preliminares
Tener un control sobre fechas y pagos

Hacer el uso de un generador de claves para la identificacin de los
integrantes del sistema
Hacer uso de la CURP como clave de identificacin secundaria o primaria
para el sistema
Tener un control sobre docentes o instructores, as como cada una de las
actividades que este realizar
Tener un calendario para el sistema en general
Tener un registro de actividades sobre evaluaciones, asistencias,
desempeo, etc.
Tener una bitcora o historial de cada alumno
Pgina 36 de 154
GlobalTec
Documento Final
Casos de Uso
Sistema para la academia oficial de Tigres UANL boleta de pago
uc Casos de Uso Admnistrador
Actualizar
Fechas
Modificar
Fechas
Consultar
Descuentos
Agregar Becas
Consultar
Becas
Modificar
Descuentos
Agregar
Expediente
Borrar Alumno
Modificar
Alumno
Modificar
Expediente
Agregar
alumno
Borrar
Expediente
Agregar
Descuentos
Consultar
Alumno
Consultar
Expediente
Borrar Becas
Modificar
Becas
Borrar
Descuentos
Administrador
Modificar
usuarios
Modificar
Equipo
Agregar
usuarios
Agregar Equipo
Agregar
Fechas
Borrar
usuarios
Consultar
Equipo
Consultar
Usuarios
Consultar
Pagos
Borrar Equipo
Modificar
Pagos
Consultar
Fechas
Borrar Pagos
Agregar Pagos
Figura 4.- Casos de uso administrador
Pgina 37 de 154
GlobalTec
Documento Final
uc Casos de uso Secretario
Modificar
Alumno
Consultar
Alumno
Agregar
alumno
Consultar
Expediente
Modificar
Expediente
Consultar
Equipo
Modificar
Equipo
Consultar
Descuentos
Secretario
Consultar
Pagos
Modificar
Pagos
Agregar Becas
Consultar
Becas
Consultar
Fechas
Agregar Pagos
Figura 5.- Casos de uso Secretario
Pgina 38 de 154
GlobalTec
Documento Final
Actividad 6: Investigar sobre las aplicaciones del modelado y sus

especificaciones.
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la
funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo
puede funcionar como un contrato entre el desarrollador y el cliente o usuario del
sistema, y por lo tanto proyecta lo que el cliente desea segn la percepcin del
desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este
modelo.
Requisitos:

Descuentos (solo si se cuenta con un hermano que este registrado ya en el
equipo o se suscriban al mismo tiempo ambos)
Las colegiaturas sern pagadas en las fechas estipuladas.
A partir del 5to da hbil el pago se considerara tardo y se generara un 6%
de recargos mensuales.
Si se tiene beca se podr conservar solo si sus pagos son estrictamente
puntuales.
El pago de la inscripcin es anual.
Se podr suspender a aquel alumno que retrase sus pagos.
No participaran alumnos en torneos con adeudos al torneo anual de
Academias.
La credencial es obligatoria con vigencia al ciclo anual.
Adquirir y usar uniforme de forma obligatoria y reponerlo en casi de estar en
mal estado.
Se requieren como mnimo 12 alumnos para abrir un grupo.
Antes de abandonar la academia se debe dar un aviso con 15 das de
anticipacin y una carta que explique el motivo.
Pgina 39 de 154
GlobalTec
Documento Final
Anlisis:
Una de las ideas que como equipo pudimos concluir y se tom la decisin que con
la informacin que se obtendr por medio del cliente pensamos nosotros que es
mejor realizar un cdigo que nos genere de claves nicas para cada alumno para
tratar de evitar conflictos con la repeticin de datos dentro de la base de datos que
vamos a necesitar.
Nmero nico para cada alumno (clave)
Diseo:
En cuanto al diseo trataremos de hacerlo de una manera prctica, tanto para
facilitar el trabajo para el administrador de la base de datos, porque incluso
pensamos que pudiera ser un conflicto y a la larga pudiera traernos problemas a
nosotros mismos, por lo tanto pensamos que lo ms grafico que se pueda con
pocas ventanas en el sistema para que se pueda mover de una manera bastante
sencilla.
Implementacin: Los casos de uso son implementados mediante el cdigo fuente
en el modelo de implementacin. Esta parte de la actividad no fue realizada, ya
que por el cambio que realizamos en cuestin del sistema, sera un poco tedioso
para nosotros tener que hacer los 2 sistemas.
Pruebas: Los casos de uso son probados a travs de las pruebas de
componentes y pruebas de integracin. Esta parte de la actividad no fue realizada,
ya que por el cambio que realizamos en cuestin del sistema, sera un poco
tedioso para nosotros tener que hacer los 2 sistemas.
Documentacin: El modelo de casos de uso debe ser documentado a lo largo de
las diversas actividades, dando lugar a distintos documentos como los manuales
de usuario, manuales de administracin, etc. Esta parte de la actividad no fue
realizada, ya que por el cambio que realizamos en cuestin del sistema, sera un
poco tedioso para nosotros tener que hacer los 2 sistemas.
Pgina 40 de 154
GlobalTec
Documento Final
Actividad 7: Aplicar al menos una herramienta CASE para la identificacin de

requerimientos.
La herramienta CASE que utilizamos para la identificar los requerimientos fue
Analyst Real Team System (ARTS), en la cual se puede observar que para cada
requerimiento le asigna un id, una prioridad y un status. Como se muestra en la
siguiente Figura (Figura 6).
NOTA: Esta herramienta cuenta con 30 das de prueba libres. Es un software de
venta por lo que no podemos hacer uso de todas sus herramientas.
Figura 6.- Herramienta Case
Pgina 41 de 154
GlobalTec
Documento Final
Unidad 3: Modelo de anlisis

Parte Terica
3.1 Arquitectura de Clases
El modelo de anlisis tiene como objetivo generar una arquitectura de objetos que
sirva como base para el diseo posterior del sistema. Dependiendo del tipo de
aplicacin existen diversas arquitecturas que se pueden utilizar, siendo de inters
aquellas arquitecturas especialmente diseadas para el manejo de los sistemas de
informacin. stas se distinguen segn la organizacin de la funcionalidad que
ofrecen los objetos dentro de ellas o la dimensin de los objetos. Esta dimensin
corresponde a los diferentes tipos de funcionalidad que manejan los objetos dentro
la arquitectura. Por ejemplo, en el caso de funcionalidad para el manejo de bordes
y base de datos, si existen tipos distintos de objetos para el manejo de cada una
de estas por separado, entonces se considera que la arquitectura es de dos
dimensiones. Por el contrario, si todos los objetos manejan de manera indistinta
los dos tipos de funcionalidades, entonces se considera que la arquitectura es de
una sola dimensin.
Uno de las tipos de arquitecturas ms importantes es la arquitectura MVC-Modelo,
Vista, Control (Model, View, Control). Esta arquitectura se basa en tres
dimensiones principales: Modelo (informacin), Vista (presentacin) y Control
(comportamiento).
Figura 7: Configuracin segn modelo

MVC
Aunque existe cierta dependencia entre estas tres dimensiones se considera que
la manera de presentar la informacin es independiente de la propia informacin y
de cmo esta se controla. Sin embargo, cada una de ellas probablemente
experimente cambios a lo largo de la vida del sistema, donde el control es el ms
propenso a ser modificado, seguido de la vista y finalmente el modelo.
Para capturar estos tres aspectos de la funcionalidad es importante notar la
correspondencia con las tres dimensiones utilizadas durante el modelo de
requisitos. La razn de ser de las tres dimensiones del modelo de requisitos
Pgina 42 de 154
GlobalTec
Documento Final
realmente se deriva para lograr una rastreabilidad con la arquitectura que se

desarrollar en el modelo de anlisis.
Figura 8.- Diagrama de 3 dimensiones

correspondiente a la arquitectura de clases
El estereotipo entidad (entity en ingls) para objetos que guarden informacin

sobre el estado interno del sistema, a corto y largo plazo, correspondiente
al dominio del problema. Todo comportamiento naturalmente acoplado con esta
informacin tambin se incluye en los objeto entidad
El estereotipo interface o borde (boundary en ingls) para objetos
que implementen la presentacin o vista correspondiente a las bordes del sistema
hacia el mundo externo, para todo tipo de actores, no slo usuarios humanos.
El estereotipo control (control en ingls) para objetos que implementen el
comportamiento o control especificando cuando y como el sistema cambia de
estado, correspondiente a los casos de uso. Los objetos control modelan
funcionalidad que no se liga naturalmente con ningn otro tipo de objeto, como el
comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer
alguna computacin y luego devolver el resultado a un objeto borde.
Pgina 43 de 154
GlobalTec
Documento Final
Arquitectura multicapas orientadas a objetos

Una arquitectura multicapas que se adece a los sistemas de informacin
orientados a objetos incluye la divisin de las responsabilidades que encontramos
en la arquitectura clsica de tres capas. Las responsabilidades se asignan a los
objetos de software.
Descomposicin de la capa de la lgica de las aplicaciones

En un diseo orientado a objetos, la capa de la lgica de aplicaciones se divide en
otras menos densas. La capa de la lgica de aplicaciones est constituida por las
siguientes capas:
Objetos del dominio: Clases que representan los conceptos del dominio; por
ejemplo, una venta.
Servicios: Los objetos servicio de las funciones como la interaccin de bases de
datos, los reportes, las comunicaciones y la seguridad.
Figura 9.- Descomposicin de la capa lgica de las aplicaciones
Una arquitectura lgica de tres capas puede desplegarse o implementarse

fsicamente en varias configuraciones, entre las cuales se encuentran:
Capas de la lgica de presentacin y de aplicaciones en la computadora del
cliente, en su almacenamiento o en su servidor.
Pgina 44 de 154
GlobalTec
Documento Final
La presentacin en la computadora del cliente, la lgica de aplicaciones en un

servidor de la aplicacin y el almacenamiento en un servidor de datos
independiente.
Entre los motivos por los cuales se recurre a la arquitectura multicapas se cuentan
los siguientes:
Aislamiento de la lgica de aplicaciones en componentes independientes

susceptibles de reutilizarse despus en otros sistemas.
Distribucin de las capas en varios nodos fsicos de cmputo y en varios
procesos. Esto puede mejorar el desempeo, la coordinacin y el compartir
la informacin en un sistema de cliente-servidor
Asignacin de los diseadores para que construyan determinadas capas;
por ejemplo, un equipo que trabaje exclusivamente en la capa de
presentacin. Y as se brinda soporte a los conocimientos especializados en
las habilidades de desarrollo y tambin a la capacidad de realizar las
actividades simultaneas en equipo.
Pgina 45 de 154
GlobalTec
Documento Final
3.2 Clases con estereotipos

La idea de los estereotipos fue acuada por Rebeca Wirfs-Brock, y el concepto ha
sido adaptado por los mismsimos inventores del UML.
La idea original se refera a una clasificacin de alto nivel de un objeto que diera
alguna indignacin del tipo de objeto que era.
Ejemplo: la diferencia entre un controlador y un coordinador.
En un diseo orientado a objetos parece ser que una clase hace todo el trabajo,
ms que otras clases no hacen nada ms que encapsular datos, esta clase de
diseo es muy pobre, ya que el controlador es muy complejo y difcil de manejar.
Para mejorar la situacin, se traslada el comportamiento del controlador a los
objetos de datos relativamente tontos, de modo de volverlos un poco ms
inteligentes y adquieren responsabilidades de ms alto nivel as el controlador se
convierte en un coordinador, el coordinador es el encargado de disparar tareas en
una secuencia particular, pero otros objetos son los que saben cmo
desempearlas.
El tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura
se le conoce como su estereotipo. Para los sistemas de informacin la arquitectura
del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos
de objetos:
Figura 10.- Estereotipo
Figura 11.- Estereotipos correspondientes a las dimensiones de la

arquitectura
ENTIDAD:
Las operaciones asignadas a los objetos entidad pueden ser ms o menos
complejas. En el caso menos complejo un objeto entidad consta slo de
operaciones de acceso a los valores de los atributos. En el caso ms complejo un
objeto entidad puede tener flujos de eventos ms all de simples accesos a los
valores de los atributos. Sea cual sea la complejidad de estas operaciones, el
Pgina 46 de 154
GlobalTec
Documento Final
objetivo es que stas slo dependan y afecten informacin local. La siguiente es

una lista de las operaciones tpicas que deben ser ofrecidas por un objeto entidad:
Guardar y traer informacin

Comportamiento que debe modificarse si el objeto entidad cambia
Crear y remover el objeto entidad
CONTROL
Los objetos de control tpicamente actan como pegamento entre los otros tipos
de objetos y por lo tanto proveen la comunicacin entre los dems tipos
de objetos. Son tpicamente los ms efmeros de todos los tipos de objetos,
dependiendo de la existencia del propio caso de uso.
La meta debe ser ligar solo un actor con cada objeto control ya que los cambios en
los sistemas a menudo son originados por los actores y de tal manera se logra
modularizar los posibles cambios. La estrategia de asignacin de control se debe
decidir segn cada aplicacin. En la mayora de los casos, sin embargo, se
promueve la separacin del control de un caso de uso en un objeto control
que delega funcionalidad de manejo ms local a los otros dos tipos de objetos.
Clases segn estereotipos:
Estereotipo Entidad:
Para los objetos que guardan informacin sobre el estado interno del
sistema; estos objetos corresponden al dominio del problema. Ejemplo: un
registro de usuario con sus datos.
Identificacin:
Se identifican principalmente a partir del dominio del problema del

modelo de requisitos.
Corresponden a objetos que sirven para modelar la informacin que el
sistema debe manejar a corto o largo plazo.
Los casos de uso sirven como base para determinar los objetos
entidad que son necesarios para la aplicacin.
Cmo saber si cierta informacin se debe modelar como una entidad o
como un atributo
Estereotipo Borde:
Para objetos que implementan las interfaces del sistema con el mundo
externo; corresponde a todos los actores incluyendo los no humanos.
Ejemplo: un objeto que se comunica con una BD externa al sistema. Tambin
una interfaz de usuario.
Pgina 47 de 154
GlobalTec
Documento Final
Identificacin de los objetos borde:
Con base en los actores

Con base en las descripciones de las interfaces del sistema (modelo de
requisitos)
Con base en las descripciones de los casos de uso.
Una interfaz por cada actor y la pantalla del prototipo que se coloc en el
caso de uso
Estereotipo Control:
Para objetos que implementan la lgica de los casos de uso. Ejemplo: validar
un usuario existente o insertar uno nuevo.
Identificacin:
Se identifican principalmente a partir de los casos de uso.

En la mayora de los sistemas es suficiente con definir un solo objeto
control para cada caso de uso.
El comportamiento que no se asign a los objetos borde y a los objetos
entidad se asigna a los objetos control.
Principios para la asignacin de objetos a cada caso de uso

Las funcionalidades del caso de uso que dependen directamente de la interaccin
del sistema con el mundo externo, se asignan a los objetos borde.
Las funcionalidades relacionadas con almacenamiento y manejo de informacin
del dominio se asignan a los objetos entidad.
Las funcionalidades que afectan mltiples objetos a la vez o que no se relacionan
naturalmente con ningn objeto borde o entidad, se asigna a los objetos control.
Pgina 48 de 154
GlobalTec
Documento Final
3.3 Clases
Representa una abstraccin de uno o varios objetos y subsistemas del diseo del
sistema que posee las siguientes caractersticas:
Una clase de anlisis se centra en el tratamiento de los requisitos funcionales.
Esto hace que una clase de anlisis sea ms evidente en el contexto del domino
del problema. Una clase de anlisis raramente define u ofrece una interfaz en
trminos de operaciones. Su comportamiento se define mediante
responsabilidades
Una clase de anlisis define atributos que son conceptuales y reconocibles en el
dominio del problema. As mismo participa en relaciones.
La clase de anlisis encaja en uno de tres estereotipos bsicos.
De interfaz
De control
De entidad
Figura 12.- Los atributos esenciales y los sub tipos de

una clase de anlisis.
Pgina 49 de 154
GlobalTec
Documento Final
Estos tres estereotipos estn estandarizados en UML y ayudan a los

desarrolladores a distinguir el mbito de las diferentes clases.
Figura 13.- Ejemplo de una clase de anlisis

Clase de Interfaz:
Se utiliza para modificar la interaccin entre el sistema y sus actores lo que implica
recibir y representar informaciones y peticiones de los usuarios y sistemas
externos.
Representa la abstraccin de ventanas formularios, paneles, interfaz de
comunicacin, interfaz de impresin, censores, terminales, APIS.
Figura 14.- La interfaz IU: La solicitud de pago se se

usa para cubrir la interaccin entre el actor
Comprador y el caso de uso Pagar Factura
Pgina 50 de 154
GlobalTec
Documento Final
Clase de Entidad:
Se usa para modelar informacin que posee una vida larga y que es a menudo
persistente. Modela la informacin y comportamiento asociado de algn fenmeno
o concepto (persona, objeto del mundo real o suceso). Se derivan de una clase de
entidad del negocio o del dominio.
Figura 15.- La clase de Entidad Factura y su

relacin con la interfaz de pago IU: Solicitud
de pago
Clase Control:
Representa coordinacin secuencial, transacciones y control de otros objetos. Se
usa para encapsular el control de un caso de uso en concreto. Tambin se usa
para representar derivaciones y clculos complejos.
Figura 16.- La clase de Control, su relacin con los procesos empleados en

diferentes entidades
Pgina 51 de 154
GlobalTec
Documento Final
3.4 Diagramas de Secuencias

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin
entre objetos en un sistema segn UML, muestra la forma en que los objetos se
comunican entre s. Este diagrama consta de objetos que representan del modo
usual: Rectngulos con nombre, mensajes representados por lneas continuas
con una punta de flecha y el tiempo representado como una progresin vertical.
Elementos principales en el diagrama de secuencias:
Objeto
Los objetos se colocan cerca de la parte superior de diagrama de izquierda a
derecha y se acomodan de manera que simplifiquen al diagrama. La extensin
que est debajo (en forma descendente) de cada objeto ser una lnea discontinua
conocida como la lnea de vida de un objeto. Junto con la lnea de vida de un
objeto se encuentra un pequeo rectngulo conocido como activacin, el cual
representa la ejecucin de una operacin que realiza el objeto. La longitud del
rectngulo se interpreta como la duracin de la activacin.
Mensaje
Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto ala
de otro, Un objeto puede enviarse en un mensaje a s mismo, es decir, desde su
lnea de vida hacia su propia lnea de vida.
Tipos de mensajes
Simple: Es la transferencia del control de un objeto a otro.
Sincrnico: Este tipo de mensajes sucede cuando un objeto enva un mensaje y
este se queda en espera de la respuesta a tal mensaje antes de continuar su
trabajo.
Asincrnico: Esto sucede si un objeto si un objeto enva un mensaje y no espera
respuesta alguna para continuar su trabajo.
Figura 17.- Tipo de mensajes
Pgina 52 de 154
GlobalTec
Documento Final
Tiempo
El diagrama representa tiempo en direccin vertical. El tiempo se inicia en la parte
superior y avanza hacia la parte inferior. Un mensaje que est ms cerca de la
parte superior ocurrir antes que uno que est cerca de la parte inferior.
Con ello el diagrama de secuencias tiene dos dimensiones. La dimensin
horizontal es la disposicin de los objetos, y la dimensin vertical muestra el paso
del tiempo
Figura 18.- Muestra al conjunto bsico de smbolos del diagrama de

secuencias, con los smbolos en funcionamiento conjunto.
Tipos de diagramas de secuencia (Instancia y Genricos):

Diagramas de secuencia de instancia
Este tipo de diagrama de secuencias solo se centra en un escenario por lo que
describe un escenario especifico (un escenario es una instancia de la ejecucin de
un caso de uso).
Figura 19.- Ejemplificacin de un diagrama de secuencias de instancia
Pgina 53 de 154
GlobalTec
Documento Final
Diagrama de secuencias genrico

Este tipo de diagramas de secuencia existe cuando se toman en cuenta todos los
escenarios de un caso de uso al momento de crear el diagrama de secuencias, es
decir, describe la interaccin para un caso de uso en general, mediante el uso de
ramificaciones (branches), condiciones y bucles.
Se puede generar un diagrama de secuencias genrico a partir del diagrama de
secuencias de instancia mediante el uso de condiciones.
Figura 20.- Ejemplificacin de un diagrama de secuencias genrico
Pgina 54 de 154
GlobalTec
Documento Final
3.5 Diccionario de Clases Segn Mdulos

Como ltima etapa del modelo de anlisis, se actualiza el diccionario de
datos originalmente descrito para el dominio del problema para incluir todas
las clases identificadas durante el modelo de anlisis. Aunque no es obligatorio,
esto nos ayuda a aprovechar para separar estas clases en diferentes mdulos
para lograr una mejor organizacin y correspondencia entre clases y casos de
uso. Aquellas clases que participan en varios casos de uso se pueden asignar a
mdulos adicionales. Comenzamos con cuatro mdulos o paquetes principales:
Interface Usuario, Principal, Registro y Servicios, como se muestra en la siguiente
figura:
Figura 21.- Mdulos principales

Interface de Usuario
El mdulo Interface de Usuario est compuesto por una sola clase: Interface de
Usuario
Clase Borde. Toda la interaccin con el usuario se hace por medio de la borde
de usuario.
Principal
El mdulo principal est compuesto por dos clases:
Pantalla Principal
- Clase Borde. Pantalla principal.
Manejador Principal
- Clase Control. El manejador principal es el encargado de desplegar la pantalla
principal de interaccin con el usuario, y luego delegar las diferentes funciones a
los manejadores especializados apropiados.
Pgina 55 de 154
GlobalTec
Documento Final
Registro
El mdulo registro se divide en los siguientes mdulos: Registro Principal, Usuario
y Tarjeta. Como se muestra en la siguiente figura:
Figura 22.- Mdulos componentes de Registro
Registro Principal
El mdulo Registro Principal est compuesto por una sola clase:
Interface Base Datos Registro
- Clase Borde. La informacin de cada usuario se almacena en la base de datos
de registro la cual se accesa mediante la borde de la base de datos de registro.
Esto permite validar a los distintos usuarios adems de guardar informacin sobre
la tarjeta de crdito para pagos en lnea.
Usuario
El mdulo Usuario est compuesto por las clases:
Pantalla Crear Reg. Usuario
- Clase Borde. Pantalla de solicitud de registro de usuario.
Pantalla Obtener Reg. Usuario
- Clase Borde. Pantalla de devolucin con informacin de registro de usuario.
Registro Usuario
- Clase Entidad. Para poder utilizar el sistema de reservaciones, el usuario debe
estar registrado con el sistema. El registro contiene informacin acerca del usuario
que incluye nombre, direccin, colonia, ciudad, pas, cdigo postal, telfono de
casa, telfono de oficina, fax, email, login y password.
Pgina 56 de 154
GlobalTec
Documento Final
Manejador Registro Usuario

- Clase Control. El manejador de registro de usuario se encarga de todo lo
relacionado con registro del usuario para poder utilizar el sistema.
Tarjeta
El mdulo Tarjeta est compuesto por las clases:
Pantalla Crear Reg. Tarjeta
- Clase Borde. Pantalla de solicitud de registro de tarjeta
Pantalla Obtener Reg. Tarjeta
- Clase Borde. Pantalla de devolucin con informacin de registro de tarjeta.
Registro Tarjeta
- Clase Entidad. Para poder hacer un pago con una tarjeta de crdito, se debe
tener un registro de tarjeta. El registro contiene informacin acerca de la tarjeta
incluyendo nombre, nmero, expedidor y vencimiento. La tarjeta est ligada a un
registro de usuario.
Manejador Registro Tarjeta
- Clase Control. El manejador de registro de tarjeta se encarga de todo lo
relacionado con registro de la tarjeta del usuario para poder pagar las
reservaciones.
Servicios
El mdulo Servicio se divide en los siguientes mdulos: Servicio Principal,
Dominio, Consultas, Reservas, y Pagos, como se muestra en la siguiente figura:
Figura 23.- Mdulos componentes de Servicios
Pgina 57 de 154
GlobalTec
Documento Final
Servicio Principal
El mdulo Servicio Principal est compuesto por las clases:
Interface Base Datos Reserva
- Clase Borde. La informacin del sistema de reservaciones de vuelo se almacena
en la base de datos de reservas la cual se accesa mediante la borde de la base de
datos de reservas. Esto permite generar consultas, reservas y pago de reservas
de manera dinmica.
Pantalla Servicio
- Clase Borde. Pantalla de servicios.
Manejador Servicio
- Clase Control. El manejador de servicios se encarga de enviar las peticiones
particulares de servicios a los manejadores especializados para consulta, reserva
y compra.
Dominio
El mdulo Dominio est compuesto por las clases:
Vuelo
- Clase Entidad. Se denomina por medio de un nmero. El vuelo tiene como origen
un aeropuerto en una ciudad y tiene como destino un aeropuerto de otra ciudad.
Un vuelo puede tener mltiples escalas y mltiples vuelos se relacionan por medio
de conexiones. El vuelo pertenece a una aerolnea y puede operar varios das a la
semana teniendo un horario de salida y otro de llegada.
Reservacin
- Clase Entidad. Para poder tomar un vuelo es necesario contar con una
reservacin previa, la cual debe pagarse antes de una fecha lmite, que puede ser
el propio da del vuelo. Una reservacin puede hacerse para mltiples vuelos y
mltiples pasajeros. La reservacin cuenta con una clave identificando un rcord
de reservacin particular.
Horario
- Clase Entidad. El horario de un vuelo se determina por su hora de salida y hora
de llegada durante los das que opera.
Aerolnea
- Clase Entidad. La aerolnea provee servicio de mltiples vuelos entre diferentes
ciudades bajo diferentes horarios. La aerolnea se identifica por un nombre.
Pgina 58 de 154
GlobalTec
Documento Final
Aeropuerto
- Clase Entidad. El aeropuerto sirve como origen, destino y escalas de un vuelo. El
aeropuerto se encuentra en una ciudad de un pas determinado.
Tarifa - Clase Entidad. Los diferentes vuelos tienen mltiples tarifas para compra
de boleto, variando segn la clase de boleto, si son de ida o de ida y vuelta, y
dependiendo de las diversas restricciones y ofertas existentes.
Asiento
- Clase Entidad. Una reservacin de vuelo puede incluir la asignacin de asiento,
especificada mediante una fila y un nmero. El nmero de asientos disponibles en
un vuelo particular dependen del tipo de avin que opere ese da.
Pasajero
- Clase Entidad. Para poder hacer una reservacin se requiere dar el nombre del
pasajero. Varios pasajeros pueden aparecer bajo una sola reservacin.
Avin
- Clase Entidad. Un vuelo en una fecha determinada se hace en un tipo de avin
particular. El tipo de avin define la cantidad mxima de pasajeros que pueden
viajar en ese vuelo para esa fecha.
Viajero Frecuente
- Clase Entidad. El pasajero tiene la opcin de acumular millas para un vuelo
particular si cuenta con una tarjeta de viajero frecuente para la aerolnea
correspondiente.
Consultas
El mdulo Consultas se divide en los siguientes mdulos: Consultas Principal,
Horarios, Tarifas Y Estado, como se muestra en la siguiente figura:
Figura 24.- Mdulos componentes de Consultas
Pgina 59 de 154
GlobalTec
Documento Final
Consultas Principal
El mdulo Consultas Principal est compuesto por las clases:
Pantalla Consultas
- Clase Borde. Pantalla de presentacin de consultas.
Manejador Consultas
- Clase Control. El manejador de consulta se encarga de enviar las peticiones de
consulta particular a los manejadores de consulta especializados.
Horarios
El mdulo Horarios est compuesto por las clases:
Pantalla Consulta Horarios
- Clase Borde. Pantalla de presentacin de consulta de horarios.
Pantalla Resultado Horarios
- Clase Borde. Pantalla de devolucin de consulta de horarios.
Manejador Consulta Horarios
- Clase Control. El manejador de consulta de horarios se encarga de controlarlas
peticiones de consulta de horarios.
Tarifas
El mdulo Tarifas est compuesto por las clases:
Pantalla Consulta Tarifas
- Clase Borde. Pantalla de presentacin de consulta de tarifas.
Pantalla Resultado Tarifas
- Clase Borde. Pantalla de devolucin de consulta de tarifas.
Manejador Consulta Tarifas
- Clase Control. El manejador de consulta de tarifas se encarga de controlar las
peticiones de consulta de tarifas.
Pgina 60 de 154
GlobalTec
Documento Final
Estado
El mdulo Estado est compuesto por las clases:
Pantalla Consulta Estado
- Clase Borde. Pantalla de presentacin de consulta de estado.
Pantalla Resultado Estado
- Clase Borde. Pantalla de devolucin de consulta de estado
Manejador Consulta Estado
- Clase Control. El manejador de consulta de estado se encarga de controlar las
peticiones de consulta de estado.
Reservas
El mdulo Reservas est compuesto por las clases:
Pantalla Clave Reservas
- Clase Borde. Pantalla de solicitud de clave de reservas.
Pantalla Crear Reserva Vuelos
- Clase Borde. Pantalla de solicitud de reservas.
Pantalla Record Reserva Vuelos
- Clase Borde. Pantalla de devolucin de reservas
Manejador Reservas
- Clase Control. El manejador de reserva se encarga de enviar las solicitudes de
reserva a la base de datos del sistema de reservaciones.
Pantalla Pagar Reg. Tarjeta
- Clase Borde. Pantalla de solicitud de pago de reservas.
Pantalla Rembolsar Reg. Tarjeta
- Clase Borde. Pantalla de solicitud de rembolso de pago.
Manejador Pagos
- Clase Control. El manejador de compra se encarga de enviar las solicitudes de
compra de boleto a la base de datos del sistema de reservaciones.
Pgina 61 de 154
GlobalTec
Documento Final
3.6 Herramientas CASE para el Anlisis

Herramientas de Anlisis y Diseo: permiten al desarrollador crear un modelo del
sistema que se va a construir y tambin la evaluacin de la validez y consistencia
de este modelo. Proporcionan un grado de confianza en la representacin del
anlisis y ayudan a eliminar errores con anticipacin. Entre ellas podemos
encontrar:
Herramientas de anlisis y diseo (Modelado).

Herramientas de creacin de prototipos y de simulacin.
Herramientas para el diseo y desarrollo de interfaces.
Dichas herramientas tiene soporte para diagramas UML 2
Diagramas Estructurales:
Clase
Objeto
Compuesto
Paquete
Componente
Despliegue
Diagramas de Comportamiento:
Casos de Uso
Comunicacin
Secuencia
Descripcin de la Interaccin
Actividad
Estado
Tiempo
Pgina 62 de 154
GlobalTec
Documento Final
Modelo de Casos de Uso
Figura 25.- Ejemplificacin del uso de herramientas CASE para la

elaboracin de casos de uso
Diagramas de Secuencia

elaboracin de diagramas de secuencia
Pgina 63 de 154
GlobalTec
Documento Final
Diagrama de Implementacin

elaboracin de diagramas de implementacin
ALGUNOS EJEMPLOS DE HERRAMIENTAS CASE:

System Architect, herramientas CASE para Anlisis y Diseo, incluye tcnicas
estructuradas y orientadas a objetos.
Win A&D, herramientas CASE para Anlisis y Diseo, incluye tcnicas
CRADLE, conjunto de herramientas CASE integradas que dan soporte a la
Planificacin estratgica, Anlisis y Diseo.
PowerDesigner 7.0: herramienta CASE de Anlisis y Diseo incluye capacidades
de generacin relacional y con orientacin a objetos.
Pgina 64 de 154
GlobalTec
Documento Final
Actividad 1: Investigar los diferentes modelos orientados a objetos como
base para la identificacin de clases.
Uso del modelo arquitectnico MVC
Tipos de modelos o arquitecturas de anlisis
Arquitecturas Hibridas (Servicios-Capas-Plataformas)

Modelo-Vista-Controlados MVC
Arquitectura Orientada a Servicios
Arquitectura Flujo de Datos- filtros (Filtres) y Tuberas (Pipes)
Arquitectura por capas
Arquitectura Fsica Centrada en los Datos
Cliente-Servidor
MVC, son las siglas de modelo-vista-controlador, que es uno de los tantos

patrones de arquitectura de software. Se presenta el modelo en un formato
adecuado para interactuar, usualmente un elemento de interfaz de usuario.
Ventajas del modelo de uso MVC:
Este responde a eventos, usualmente acciones del usuario e invoca

cambios en el modelo y probablemente la vista.
El objetivo primordial del MVC es la reutilizacin del cdigo ya
implementado.
Es el ms utilizado con mayor frecuencia en las aplicaciones Web, donde la
Vista es la pgina HTML, y el controlador es el cdigo que rene la data
dinmica y genera el contenido de la pgina.
Se presenta la misma informacin de distintas formas.
Las vistas y comportamientos de una aplicacin deben reflejar las
manipulaciones de los datos de forma inmediata.
Debera ser fcil cambiar la interfaz de usuario (incluso en tiempo de
ejecucin).
Permitir diferentes estndares de interfaz de usuario o portarla a otros
entornos no debera afectar el cdigo aplicacin.
Definen su propio flujo de control y manejan los eventos internamente.
MODELO MVC
Pgina 65 de 154
GlobalTec
Documento Final
El funcionamiento bsico del patrn MVC, puede resumirse en:

1. El usuario realiza una peticin
2. El controlador captura el evento (puede hacerlo mediante un manejador de
eventos handler , por ejemplo)
3. Hace la llamada al modelo/modelos correspondientes (por ejemplo,
mediante una llamada de retorno callback -) efectuando las
modificaciones pertinentes sobre el modelo
4. El modelo ser el encargado de interactuar con la base de datos, ya sea en
forma directa, con una capa de abstraccin para ello, un Web Service, etc.
Y retornar esta informacin al controlador
5. El controlador recibe la informacin y la enva a la vista
6. La vista, procesa esta informacin pudiendo hacerlo desde el enfoque que
veremos en este libro, creando una capa de abstraccin para la lgica
(quien se encargar de procesar los datos) y otra para el diseo de la
interfaz grfica o GUI. La lgica de la vista, una vez procesados los datos,
los acomodar en base al diseo de la GUI - layout y los entregar al
usuario de forma humanamente legible.
Figura 28.- Idea sistema UANL
Pgina 66 de 154
GlobalTec
Documento Final
Actividad 2: Desarrollar casos de uso y modelos CRC

Que permitan tener una comprensin de la
Manera en que el sistema se utilizar.
Figura 29.- Casos de uso Administrador
Pgina 67 de 154
GlobalTec
Documento Final
Figura 30.- Casos de uso Secretario

Usuario: Administrador
Responsabilidades
Colaboradores
Tipo de usuario: Administrador
Fechas
Datos: El encargado o directivo de la Partidos
empresa
Equipos
Expedientes
Responsabilidades:
Alumnos
Pagos
Crear
Usuarios
Eliminar
Becas
Actualizar
Descuentos
Consultar
Tabla 4. Administrador
Usuario: Secretario
Responsabilidades
Colaboradores
Tipo de usuario: Administrativo
Fechas
Datos: Empleado Administrativo
Equipos
Expedientes
Responsabilidades:
Alumnos
Pagos
Usuarios
Consultar
Becas
Modificar
Tabla 5. Secretario
Pgina 68 de 154
GlobalTec
Documento Final
Actividad 3: Aplicar el modelo objeto-relacin comportamiento que indique

como
Responder el sistema OO a eventos.
Modelo objeto-relacin-comportamiento
Administrador-Alumnos-Da de alta, consulta, modifica y borra
Administrador-Expediente-Da de alta, consulta, modifica y borra
Administrador-Equipo- Da de alta, consulta, modifica y borra
Administrador-Descuentos- Da de alta, consulta, modifica y borra
Administrador-Pagos- Da de alta, consulta, modifica y borra
Administrador-Usuarios- Da de alta, consulta, modifica y borra
Administrador-Fechas- Da de alta, consulta, modifica y borra
Administrador-Becas- Da de alta, consulta, modifica y borra
Secretario-Alumno-Consultar, modificar y agregar
Secretario-Expediente- Consultar, modificar y agregar
Secretario-Equipo- Consultar, modificar y agregar
Secretario-Descuentos- Consultar
Secretario-Pagos-Consultar, agregar y modificar
Secretario-Usuarios-Consultar
Secretario-Fechas- Consultar
Secretario-Becas-Consultar y agregar
Secretario-Fechas-consultar
Pgina 69 de 154
GlobalTec
Documento Final
Actividad 4: Aplicar al menos una Herramienta CASE para el anlisis
Figura 31.- Herramienta CASE
Pgina 70 de 154
GlobalTec
Documento Final
Unidad 4: Modelo de diseo

Parte Terica
4.1 Estrategias de Diseo
El diseo de software es un proceso de definicin de la arquitectura,
componentes, interfaces y otras caractersticas de un sistema o componente y la
planificacin de una solucin de software. Despus de que el propsito y las
especificaciones de software estn determinados, los desarrolladores de software
disean o utilizan los diseadores para desarrollar un plan para una solucin. Un
diseo de software puede ser independiente de la plataforma o especfico de
plataforma, en funcin de la disponibilidad de la tecnologa llamada por el diseo.
Las estrategias generales de diseo de software ms conocidas son:
Divide y vencers
Implica resolver un problema difcil, dividindolo en partes ms simples tantas
veces como sea necesario, hasta que la resolucin de las partes se torna
obvia. La solucin del problema principal se construye con las soluciones
encontradas.
Refinamiento en pasos sucesivos

Se desarrolla una jerarqua descomponiendo una funcin de forma sucesiva
hasta que se llega a las sentencias del lenguaje de programacin.
Comenzamos con una declaracin de la funcin (o una descripcin de la
informacin) definida a un nivel superior de abstraccin. Es decir, la
declaracin describe la funcin o la informacin conceptualmente, pero no
proporciona informacin sobre el funcionamiento interno de la funcin o sobre
la estructura interna de la informacin, sino que se va a realizando
sucesivamente, dando cada vez ms detalles.
Top-down vs. bottom-up

Se formula un resumen del sistema, sin especificar detalles. Cada parte del
sistema se refina diseando con mayor detalle. Cada parte nueva es entonces
redefinida, cada vez con mayor detalle, hasta que la especificacin completa
es lo suficientemente detallada para validar el modelo. El modelo "Top-Down"
se disea con frecuencia con la ayuda de "cajas negras" que hacen ms fcil
cumplir requerimientos aunque estas cajas negras no expliquen en detalle los
componentes individuales. En contraste, en el diseo Bottom-up las partes
individuales se disean con detalle y luego se enlazan para formar
componentes ms grandes, que a su vez se enlazan hasta que se forma el
sistema completo. Las estrategias basadas en el flujo de informacin "bottomup" se hacen potencialmente necesarias y suficientes porque se basan en el
Pgina 71 de 154
GlobalTec
Documento Final
conocimiento de todas las variables que pueden afectar los elementos del
sistema.
(Se denomina caja negra a aquel elemento que es estudiado desde el punto
de vista de las entradas que recibe y las salidas o respuestas que produce, sin
tener en cuenta su funcionamiento interno.)
Abstraccin de datos y ocultamiento de informacin
La abstraccin de datos es un conjunto de datos que describen un objeto,
como puede ser el DNI de una persona, que est compuesta por conjunto de
partes de informacin, pero que nos podemos referir a todos los datos
mencionando el nombre de la abstraccin de datos.
El principio de ocultamiento de la informacin sugiere que los mdulos deben
especificarse de forma que la informacin (procedimientos y datos) contenida
dentro de un mdulo sea inaccesible a otros mdulos que no necesiten tal
informacin. Por tanto se trata de definir una serie de mdulos independientes
que se comuniquen slo a travs de la informacin necesaria para realizar la
funcin de software. El uso de ocultamiento de informacin en el diseo
facilitar las modificaciones, prueba y mantenimiento del software, ya que
como la mayora de los datos y de los procedimientos estn ocultos a otras
partes del software, ser menos probable que los errores que se introduzcan
durante la modificacin se propaguen a otros mdulos del software.
Uso de heursticas
La resolucin de problemas es especficamente distinta del aprendizaje de
hechos, la creacin de estructuras conceptuales y la adquisicin de destrezas,
algoritmos y valores. Sin embargo es una importante tcnica metodolgica
para la formacin de conceptos y para establecer relaciones entre ellos. Son
reglas muy generales que permiten transformar el problema en una situacin
ms sencilla, nos ayudan a comprender el problema y favorecer el xito en
encontrar la solucin.
Uso de patrones
Contribuyen a reutilizar diseo grfico, identificando aspectos claves de la
estructura de un diseo que puede ser aplicado en una gran cantidad de
situaciones. La importancia de la reutilizacin del diseo no es despreciable,
ya que sta nos provee de numerosas ventajas: reduce los esfuerzos de
desarrollo y mantenimiento, mejora la seguridad informtica, eficiencia y
consistencia de nuestros diseos, y nos proporciona un considerable ahorro
en la inversin. Mejoran (aumentan, elevan) la flexibilidad, modularidad y
extensibilidad, factores internos e ntimamente relacionados con la calidad
percibida por el usuario.
Pgina 72 de 154
GlobalTec
Documento Final
Aproximacin iterativa e incremental

En la aproximacin iterativa los requerimientos y soluciones evolucionan
mediante la colaboracin de grupos auto organizado y multidisciplinario. La
iteracin debe durar de una a cuatro semanas. Cada iteracin del ciclo de vida
incluye: planificacin, anlisis de requerimientos, diseo, codificacin, revisin
y documentacin. Al final de cada iteracin el equipo vuelve a evaluar las
prioridades del proyecto. En cuanto a la aproximacin incremental se
comienza el desarrollo del sistema para satisfacer un subconjunto de
requisitos especificados. Las ltimas versiones prevn los requisitos que
faltan. De esta forma se logra una rpida disponibilidad del sistema, que
aunque incompleto, es utilizable y satisface algunas de las necesidades
bsicas de informacin. Cada versin parte de una previa sin cambios pero
con nuevas funciones.
4.2 Diseo de Objetos
Este mtodo fue definido por G. Booch a principios de los aos 80 y ha conocido
varias versiones sucesivas. Desde el punto de vista de las aplicaciones
industriales, es probablemente uno de los mtodos precursores de la
aproximacin orientada a objetos. Fue definido para el Departamento de Defensa
estadounidense (DOD) para racionalizar el desarrollo de las aplicaciones en ADA.
Posteriormente ha sido ampliado para el lenguaje C++. Por lo tanto, se trata de un
mtodo de desarrollo (especificacin tcnica e implementacin) y no de diseo
(anlisis de las necesidades y especificacin formal). Con posterioridad ha
inspirado numerosos mtodos, algunos de los cuales son extensiones directas,
como HOOD.
La idea principal de OOD es sugerir a los programadores la utilizacin de los
paquetes de ADA, no para poner en ellos cualquier procedimiento o definicin de
tipo, sino para implementar clases en el sentido de la aproximacin orientada a
objetos. De este modo, cualquier objeto del sistema se representa como un
paquete. Lo esencial del mtodo est dedicado a la elaboracin del modelo
esttico (describir los objetos del sistema); el modelo dinmico (cambios de estado
de los objetos frente a ciertos eventos) solamente se aborda muy parcialmente y el
modelo funcional (describe los procesos de transformacin de los usuarios) no se
tiene en cuenta. OOD recomienda sin embargo el anlisis de las funciones segn
el mtodo SADT.
Pgina 73 de 154
GlobalTec
Documento Final
Los Modelos del Mtodo.

OOD se centra en la definicin del modelo esttico, y completa esta definicin con
algunos diagramas de estados para representar el aspecto dinmico.
En el mbito lgico se proponen dos tipos de diagramas: los diagramas de clases
y los diagramas de objetos (o de instancias). Los principales conceptos siguientes
constituyen los elementos de estos diagramas:
Objeto: Adems de su definicin por sus atributos, sus operaciones y su
identificador, un objeto posee adems un estado o un conjunto de estados que
controlan su evolucin en el tiempo.
Asociaciones: Adems de las asociaciones de herencia, de instanciacin y de
meta clases, el modelo esttico comporta una relacin que expresa un mensaje
enviado por un objeto a otro. Esta relacin se denomina relacin de utilizacin (un
objeto utiliza los servicios de otro objeto).
Objeto cliente: Es un objeto que utiliza los recursos de otro objeto.
Protocolo de un objeto: Es la lista de operaciones que un objeto puede efectuar
sobre los dems objetos (conjunto de relaciones de utilizacin partiendo de dicho
objeto).
Comportamiento de un objeto: Es el protocolo del objeto ms la lista de
operaciones que los dems objetos pueden efectuar sobre l (lista de los servicios
que solicita ms los que ofrece).
Funcin de un objeto: Un objeto puede ser cliente o actor (o activo) cuando
opera sobre otros objetos (les solicita servicios). Puede ser servidor(o pasivo)
cuando es utilizado por los dems (les ofrece servicios). Puede ser agente cuando
es a la vez cliente y servidor.
Concurrencia entre objetos: Un objeto puede tener un comportamiento
secuencial (se dice que es un objeto secuencial) o concurrente (objeto
concurrente). Un objeto secuencial realiza una solicitud de servicio a otro objeto y
espera el resultado. Un objeto concurrente realiza una solicitud de servicio y sigue
con su trabajo hasta la llegada del resultado, que tendr en cuenta seguidamente.
Un objeto secuencial solamente efecta un servicio a la vez. Un objeto
concurrente puede rendir varios servicios simultneamente.
Objeto persistente: OOD menciona la persistencia de los objetos sin enunciar la
naturaleza del sistema que gestionar dicha persistencia. En realidad, como el
mtodo viene muy marcado por el lenguaje ADA, que no gestiona la persistencia,
esta ltima no se toma en cuenta realmente en el mbito lgico o fsico.
Pgina 74 de 154
GlobalTec
Documento Final
4.3 Diseo de Sistema

Para los sistemas orientados a objetos, podemos definir una pirmide diseo, pero
las capas son un poco diferentes. Haciendo referencia a la Figura 33, las cuatro
capas de la OO diseo de la pirmide son:
La capa subsistema contiene una representacin de cada uno de los

subsistemas que permiten al software para conseguir sus requerimientos
definidos en el cliente y a implementar la infraestructura tcnica que soporta
los requerimientos del cliente.
La clase y la capa de objeto contienen las jerarquas de clases que
permiten al sistema que se cre mediante generalizaciones y cada vez ms
orientada especializaciones. Esta capa tambin contiene representaciones
de cada objeto.
La capa de mensaje contiene los detalles de diseo que permiten a cada
objeto para comunicarse con sus colaboradores. Esta capa establece el
externo e interfaces internas para el sistema.
La capa responsabilidades contiene la estructura de datos y algoritmos
diseo para todos los atributos y operaciones para cada objeto.
Figura 33.- Pirmide del diseo orientado a objetos

La pirmide de diseo se centra exclusivamente en el diseo de un producto o
sistema.
Cabe sealar, sin embargo, que otra "capa" de diseo existe, y esta capa forma la
base sobre la que descansa la pirmide. La capa de base se centra en el diseo
de objetos de dominio (llamados patrones de diseo ms adelante en este
captulo). Objetos de dominio desempean un papel clave en la construccin de la
infraestructura para el sistema orientado a objetos mediante el apoyo a actividades
de interfaz humano/ordenador, gestin de tareas y gestin de datos. Los objetos
Pgina 75 de 154
GlobalTec
Documento Final
de dominio tambin se pueden utilizar para profundizar en el diseo de la propia

aplicacin.
El diseo del sistema se obtiene teniendo en cuenta las necesidades generales de
los clientes (representados con casos de uso) y los eventos y estados que son
externamente observables (el modelo objeto-comportamiento). Clase y diseo de
objetos se asigna a partir de la descripcin de los atributos, operaciones y
colaboraciones contenidas en el modelo CRC. El mensaje de diseo es impulsado
por el modelo objeto-relacin, y el diseo de las responsabilidades est derivado
de los atributos, operaciones y colaboraciones descritas en el modelo de CRC.
Fichman y Kemerer [FIC92] sugieren diez componentes de modelado de diseo
que se pueden utilizar para comparar diversos mtodos de diseo convencionales
y orientados a objetos:
1. Representacin de la jerarqua de mdulos.
2. Especificacin de las definiciones de datos.
3. Especificacin de la lgica procesal.
4. Indicacin de secuencias de procesamiento de extremo a extremo.
5. Representacin de estados y transiciones de objetos.
6. Definicin de las clases y las jerarquas.
7. La asignacin de las operaciones a las clases.
8. Definicin detallada de las operaciones.
9. Especificacin de conexiones de mensajes.
10. Identificacin de los servicios exclusivos.
Figura 34.- Actividades del diseo orientado a objetos
Pgina 76 de 154
GlobalTec
Documento Final
Dividir requerimos: Analice los requerimientos y organcelos en grupos afines.

Normal existen varias opciones posibles de divisin, y pueden sugerir varias
alternativas en esta de procesos.
Identificar subsistemas: Debe identificar los diferentes subsistemas que pueden,
individual o colectivamente, cumplir los requerimientos. Los grupos de
requerimiento estn normalmente relacionados con los subsistemas, de tal forma
que esta actividad y la divisin de requerimientos se pueden fusionar. Sin
embargo, la identificacin de subsistemas se puede ver influenciada por otros
factores organizacionales y del entorno.
Asignar requerimientos a los subsistemas: Asigne los requerimientos a los
subsistemas. En principio, esto ser sencillo si la divisin de requerimientos se
utiliza para la identificacin de subsistemas. En la prctica, no existe igualdad
entre las divisiones de requerimientos y la identificacin de subsistemas. Las
limitaciones de los subsistemas comerciales pueden significar que tenga que
cambiar los requerimientos para acomodarlos a estas restricciones.
Especificar la funcionalidad de los subsistemas: Debe enumerar las funciones
especficas asignadas a cada subsistema. Esto puede verse como parte de la fase
de diseo del sistema o, si el subsistema es un sistema de software, como parte
de la actividad de especificacin de requerimientos para ese sistema. Tambin
debe especificar las relaciones entre los subsistemas en esta etapa.
Definir las interfaces del subsistema: Defina las interfaces necesarias y
requeridas por cada subsistema. Una vez que estas interfaces se han acordado,
es posible desarrollar estos subsistemas en paralelo.
Pgina 77 de 154
GlobalTec
Documento Final
4.4 Revisin del Diseo

El Diseo del Software es un proceso y un modelado a la vez. El proceso de
Diseo es un conjunto de pasos repetitivos que permiten al diseador describir
todos los aspectos del Sistema a construir. A lo largo del diseo se evala la
calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el modelo
de anlisis y debe acumular todos los requisitos implcitos que desea el cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y los
que prueban y mantienen el Software.
El Diseo debe proporcionar una completa idea de lo que es el Software,
enfocando los dominios de datos, funcional y comportamiento desde el punto de
vista de la Implementacin.
Para evaluar la calidad de una presentacin del diseo, se deben establecer
criterios tcnicos para un buen diseo como son:
Un diseo debe presentar una organizacin jerrquica que haga un uso

inteligente del control entre los componentes del software.
El diseo debe ser modular, es decir, se debe hacer una particin lgica del
Software en elementos que realicen funciones y sub funciones especficas.
Un diseo debe contener abstracciones de datos y procedimientos.
Debe producir mdulos que presenten caractersticas de funcionamiento
independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones
entre los mdulos y el entorno exterior.
Debe producir un diseo usando un mtodo que pudiera repetirse segn la
informacin obtenida durante el anlisis de requisitos de Software.
Una revisin es un proceso o reunin durante la cual un producto de trabajo, un

conjunto de productos de trabajo o la evidencia de la ejecucin de un proceso se
presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras
partes interesadas para su comentario o aprobacin.
Las revisiones al diseo de los productos de software se realizan por demanda
con el objetivo de detectar e identificar no conformidades en el diseo antes de
pasar a la codificacin, as como tambin identificar aspectos de mejoramiento.
Entre otros, en esta actividad se verifica la arquitectura y utilizacin de patrones en
el diseo.
Cuando el diseo se completa se mantienen reuniones con los clientes para
revisarlos antes de avanzar al desarrollo, el proceso de revisin se realiza en tres
etapas en correspondencia con los pasos del proceso del diseo:
Pgina 78 de 154
GlobalTec
Documento Final
1. Revisin del diseo preliminar

Los clientes y usuarios se renen para validar el diseo conceptual.
Se asegura que todos los aspectos relativos a los requerimientos han sido
apropiadamente completados en el diseo
Se invita a participar a ciertas personas claves:
Cliente(s): ayudan a definir los requerimientos del sistema.

Analista(s): quien colabora para definir los requerimientos del sistema.
Usuario(s): potenciales del sistema
Diseador(es): del sistema
Un moderador, un secretario y otros desarrolladores.
Se recomienda que el nmero de integrantes sea pequeo de modo que faciliten

las discusiones.
Durante la revisin se presenta a la audiencia el diseo conceptual. Al hacerlo, se
demuestra que el sistema tiene estructura requerida, las funciones y las
caractersticas especificadas por los documentos del anlisis.
Todos los participantes, en conjunto, verifican que el diseo propuesto incluya el
hardware necesario, interfaces con otros sistemas entradas y salidas.
Los clientes prueban los dilogos y mens, los formatos de los informes y el
tratamiento e defectos propuestos.
2. Revisin crtica del diseo.
Realiza una revisin crtica del diseo, donde se presenta una vista general del
diseo tcnico.
Integrantes:
Analistas
Diseadores del sistema
Moderador
Diseadores del programa para el proyecto
Probador del sistema
Analista que escribir la documentacin del sistema y otros desarrolladores.

Este grupo es ms tcnico que el anterior, ya que la revisin trata de aspectos
tcnicos.
El moderador conduce la reunin para que se traten dos puntos: si el diseo
implementa todos los requerimientos y si es un diseo de calidad.
Pgina 79 de 154
GlobalTec
Documento Final
Usando diagramas, o datos ambas cosas se explican las estrategias de diseo

alternativa y como y porque se han tomado las principales decisiones de diseo.
Si se identifican problemas mayores el diseo se rehace.
3. Revisin del diseo de programas.
Cuando el diseo tcnico resulta satisfactorio, los diseadores de programas
estarn en posicin de interpretarlo como el conjunto de descripciones de diseo
para los componentes reales, que deben ser codificados y probados.
Despus de completar los diseos de programas, pero antes de comenzar la
decodificacin, se presentan sus planes.
Integrantes:
Analistas
Diseadores del sistema
Diseadores del programa
Moderador, secretario y probador del sistema.
Este proceso se centra en la deteccin de defectos ms que en su correccin.

Adems, se est evaluando el diseo no a los diseadores.
El proceso beneficia a todos al encontrar defectos y problemas cuando an son
fciles y poco costosos de corregir.
Pgina 80 de 154
GlobalTec
Documento Final
4.5 Diagramas de Secuencias del Diseo

Diagramas de secuencia
Los diagramas de secuencia se usan para mostrar la interaccin entre los
usuarios, las pantallas y las instancias de los objetos en el sistema. Proveen un
mapa secuencial del paso de los mensajes entre los objetos a lo largo del tiempo.
Frecuentemente, estos diagramas se ubican bajo los casos de uso o los
componentes en el modelo para ilustrar un escenario, cmo interacta un usuario
con el sistema y qu sucede internamente para que el trabajo se lleve a cabo.
Muchas veces, los objetos se representan utilizando conos especialmente
estereotipados.
Figura 35.- Ejemplificacin casos de uso

Como se muestra en el ejemplo anterior. El objeto etiquetado "Pantalla De
Ingreso" (Login Screen) se muestra empleando el cono de interfaz. El objeto
etiquetado "Administrador De Seguridad" (SecurityManager) se muestra usando el
cono controlador. El objeto etiquetado "Usuarios" (Users) se muestra usando el
cono entidad.
La idea primordial es que las interacciones entre los objetos se realiza en una
secuencia establecida y que la secuencia se toma su tiempo en ir del principio al
fin. Al momento de crear un sistema tendr que especificar la secuencia, y para
ello, utilizara al diagrama correspondiente.
Pgina 81 de 154
GlobalTec
Documento Final
Un diagrama de secuencias consta de objetos que se representan del modo usual:

rectngulos con nombre (subrayado), mensajes representados por lneas
continuas con una punta de flecha y el tiempo representado como una progresin
vertical
Objetos
Se colocan cerda de la parte superior del diagrama de izquierda a derecha y se
acomodan de manera que simplifiquen al diagrama. La extensin que est debajo
(y en forma descendente) de cada objeto ser una lnea discontinua conocida
como la lnea de vida de un objeto. Junto con esta se encuentra un pequeo
rectngulo conocido como activacin, el cual representa la ejecucin de una
operacin que realiza el objeto. La longitud del rectngulo se interpreta como la
duracin de la activacin.
Figura 36.- Representacin de un Objeto en un Diagrama de Secuencias.

Mensaje
Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto a la
de otro. Un objeto puede enviarse un mensaje a si mismo (Es decir, desde su lnea
de vida hacia su propia lnea de vida).
Tipos de mensajes
Simple: Es la transferencia del control de un objeto a otro.

Sincrnico: Este tipo de mensajes sucede cuando un objeto enva un
mensaje y este se queda en espera de la respuesta a tal mensaje antes de
continuar su trabajo.
Asincrnico: Esto sucede si un objeto si un objeto enva un mensaje y no
espera respuesta alguna para continuar su trabajo.
Pgina 82 de 154
GlobalTec
Documento Final
Figura 37.- Tipos de mensaje

Tiempo
El diagrama representa tiempo en direccin vertical. El tiempo se inicia en la parte
superior y avanza hacia la parte inferior. Un mensaje que est ms cerca de la
parte superior ocurrir antes que uno que est cerca de la parte inferior.
Con ello el diagrama de secuencias tiene dos dimensiones. La dimensin
horizontal es la disposicin de los objetos, y la dimensin vertical muestra el paso
del tiempo
Figura 38.- Muestra al conjunto bsico de smbolos del diagrama de

secuencias, con los smbolos en funcionamiento conjunto
Tipos de diagramas de secuencia (Instancia y Genricos):
Diagramas de secuencia de instancia
Este tipo de diagrama de secuencias solo se centra en un escenario por lo que
describe un escenario especifico (un escenario es una instancia de la ejecucin de
un caso de uso).
Pgina 83 de 154
GlobalTec
Documento Final
Figura 39.- Diagrama de secuencias

Diagrama de secuencias genrico
Este tipo de diagramas de secuencia existe cuando se toman en cuenta todos los
escenarios de un caso de uso al momento de crear el diagrama de secuencias, es
decir, describe la interaccin para un caso de uso en general, mediante el uso de
ramificaciones (branches), condiciones y bucles.
Se puede generar un diagrama de secuencias genrico a partir del diagrama de
secuencias de instancia mediante el uso de condiciones.
Figura 40.- Diagrama de secuencias genrico
Pgina 84 de 154
GlobalTec
Documento Final
4.6 Herramientas CASE para el Diseo

Herramientas de Anlisis y Diseo: Permiten al desarrollador crear un modelo del
sistema que se va a construir y tambin la evaluacin de la validez y consistencia
de este modelo. Proporcionan un grado de confianza en la representacin del
anlisis y ayudan a eliminar errores con anticipacin. Entre ellas podemos
encontrar:
Herramientas de anlisis y diseo (Modelado).

Herramientas de creacin de prototipos y de simulacin.
Herramientas para el diseo y desarrollo de interfaces.
Dichas herramientas tiene soporte para diagramas UML 2

Diagramas Estructurales:
Clase
Objeto
Compuesto
Paquete
Componente
Despliegue
Diagramas de Comportamiento:
Casos de Uso
Comunicacin
Secuencia
Descripcin de la Interaccin
Actividad
Estado
Tiempo
Pgina 85 de 154
GlobalTec
Documento Final
Modelo de Casos de Uso
Figura 41.- Ejemplificacin casos de uso

Diagramas de Secuencia
Figura 42.- Ejemplificacin diagramas de secuencia
Pgina 86 de 154
GlobalTec
Documento Final
Diagrama de Implementacin
Figura 43.- Ejemplificacin de diagrama de implementacin
ALGUNOS EJEMPLOS DE HERRAMIENTAS CASE:

System Architect, herramientas CASE para Anlisis y Diseo, incluye tcnicas
Win A&D, herramientas CASE para Anlisis y Diseo, incluye tcnicas
CRADLE, conjunto de herramientas CASE integradas que dan soporte a la
Planificacin estratgica, Anlisis y Diseo.
PowerDesigner 7.0: herramienta CASE de Anlisis y Diseo incluye capacidades
de generacin relacional y con orientacin a objetos.
Pgina 87 de 154
GlobalTec
Documento Final
Actividad 1: Refinamiento a Clases
En esta actividad se realiz el refinamiento de las Clases del Sistema es decir se
verifico los atributos que estn deberan contener mediante un anlisis de los
requerimientos y el funcionamiento del sistema se modificaron algunos aspectos
de importancia que se pudieron haber omitido. Esto con el fin de corregir los
menores errores posibles en la etapa de diseo, para que la etapa de
implementacin se lleve a cabo con el menor nmero de inconvenientes.
class Clases
class Clases
Equipo
Alumno
-
Id_Alumno: int
Num_Equipo: int
Nombre: String
Apellido Materno: String
Apellido Paterno: String
Edad: int
Fecha Nacimiento: Date
Direccion: String
Telefono: String
Nombre Tutor: String
Estado: String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Alumno () : void
Alumno(int, int, String, String, String, int, Date, String, String, String) : void
Get_Id_Alumno() : int
Set_Id_Alumno(int) : void
Get_Nombre_Completo() : String
Get_Num_Equipo() : int
Set_Num_Equipo(int) : void
Get_Nombre() : String
Set_Nombre(String) : void
Get_Apell_Pa() : String
Set_Apell_Pa(String) : void
Get_Apell_Ma() : String
Set_Apell_Ma(String) : void
Get_Edad() : int
Set_Edad(int) : void
Get_Fecha_Nac_Date() : Date
Get_Fecha_Nac() : String
Set_Fecha_Nac(Date) : void
Get_Direccion() : String
Set_Direccion(String) : void
Get_Telefono() : String
Set_Telefono(String) : void
Get_Nombre_Tutor() : String
Set_Nombre_Tutor(String) : void
Get_Estado() : String
Set_Estado(String) : void
Num_Equipo: int
Nombre_Equipo: String
Nombre_Entrenador: String
Categoria: int
Numero_Alumnos: int
+
+
+
+
+
+
+
+
+
+
+
+
Equipo() : void
Equipo(int, String, String, String, int) : void
Get_Num_Equipo() : int
Set_Num_Equipo(int) : void
Get_Nombre_Equipo() : String
Set_Nombre_Equipo(int) : void
Get_Nombre_Entrenador() : String
Set_Nombre_Entrenador(String) : void
Get_Categoria() : int
Set_Categoria(int) : void
Get_Numero_Alumnos() : int
Set_Numero_Alumnos(int) : void
Figura 44.- Refinamiento a clases
Pgina 88 de 154
GlobalTec
Documento Final
El Diagrama de Clases muestra los atributos o propiedades que contendr cada

clase as como como sus modificadores de acceso y los diferentes mtodos que
sern necesarios para acceder a dichos atributos. Sin olvidarnos de las
operaciones que cada clase podr realizar con los diferentes datos que estas
contenga a la hora de crear un objeto.
class Clases
class Clases
Pago
Usuarios
-
Id_Usuario: int
Usuario: String
Nombre Completo: String
Tipo: String
+
+
+
+
+
+
+
+
+
+
Usuario() : void
Usuario(int, String, String, String) : void
Get_Id_Usuario() : int
Set_Id_Usuario(int) : void
Get_Nombre_Completo() : String
Set_Nombre_Completo(String) : void
Get_Usuario() : String
Set_Usuario(String) : void
Get_Tipo() : String
Set_Tipo(String) : void
class Clases
Beca
-
Id_Beca: int
Id_Alumno: int
Tipo_Beca: String
Monto_Beca: double
Fecha_Deposito: Date
+
+
+
+
+
+
+
+
+
+
+
+
+
Beca() : void
Get_Id_Beca() : int
Set_Id_Beca(int) : void
Get_Tipo_Beca() : String
Set_Tipo_Beca(String) : void
Get_Monto() : Double
Set_Monto(Double) : void
Get_Fecha_Deposito_Date() : Date
Get_Fecha_Deposito() : String
Set_Fecha_Deposito(Date) : void
Beca(int, int, String, double, Date) : void
Id_Pago: int
Id_Alumno: int
Concepto: String
Fecha limite de Pago: Date
Importe: double
Descuentos: double
Fecha de Pago: Date
Recargos: double
Estado (Status): String
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Pago() : void
Pago(int, int, String, Date, double, double, Date, double, String) : void
Get_Id_Pago() : int
Set_Id_Pago(int) : void
Get_Concepto() : String
Set_Concepto(String) : void
Get_Fecha_Li_Pago() : String
Get_Fecha_Li_Pa_Date() : Date
Set_Fecha_Li_Pa(Date) : void
Get_Importe() : Double
Set_Importe(Double) : void
Get_Descuentos() : Double
Set_Descuentos(Double) : void
Get_Fecha_Pago() : String
Get_Fecha_Pago_Date() : Date
Set_Fecha_Pago(Date) : void
Get_Recargos() : Double
Set_Recargos(Double) : void
Get_Estado() : String
Set_Estado(String) : void
Figura 45.- Refinamiento a clases
Pgina 89 de 154
GlobalTec
Documento Final
Actividad 2: Refinamiento a Subsistemas

En esta actividad se peda realizar el refinamiento de subsistema lo cual implicaba
subsistemas, al analizar los alcances del proyecto y con la orientacin del asesor
se obvio que al ser un sistema pequeo no cuenta con subsistemas por lo que
esta actividad no fue necesario realizar ya que no tena razn de hacerla.
Pgina 90 de 154
GlobalTec
Documento Final
Actividad 3: Refinamiento a Diagrama de Colaboracin

Un diagrama de colaboracin es esencialmente un diagrama que muestra
interacciones organizadas alrededor de los roles. A diferencia de los diagramas de
secuencia, los diagramas de colaboracin, tambin llamados diagramas de
comunicacin, muestran explcitamente las relaciones de los roles.
En el primer diagrama (Figura 46) se muestra como se tenan originalmente
organizadas las clases y los actores del sistema
Figura 46.- Diagrama de Colaboracin

Figura 47, se muestra el diagrama de colaboracin modificado, agregando un
actor ms (usuario), el cual es solo capaz de ver los archivos almacenados del
sistema, sin poder interactuar con otras clases y objetos.
Figura 47.- Diagrama de Colaboracin
Pgina 91 de 154
GlobalTec
Documento Final
Diagrama refinado:
SISTEMA UANL
Figura 48.- Diagrama Refinado

Administrador
Secretario
Agrega, modifica,
consulta, borra:
Alumnos
expedientes
pagos
descuentos
expedientes.
Consulta:
Becas
equipos
fechas
usuarios
equipos
becas
fechas
pagos
expedientes
usuarios
Agrega:
alumnos, pagos, becas.
Sistema UANL
Modifica:
expediente, alumnos, pagos
usuarios
Consulta:
alumnos, torneos
Pgina 92 de 154
GlobalTec
Documento Final
Actividad 4: Refinamiento Diagrama de componentes

En este diagrama se observa cmo van conectadas las interfaces y que contiene
cada una de estas, tanto botones, como las etiquetas y como se van conectado
cada una de ellas para realizar el sistema. Queda de una manera muy sencilla ya
que no contamos con un subsistema
El diagrama es el siguiente:
Figura 49.- Diagrama de componentes
Pgina 93 de 154
GlobalTec
Documento Final
Actividad 5: Refinamiento de Diagrama de Actividades

Los diagramas de actividades se pueden mostrar junto con los diagramas de
secuencias ya que se especifica las acciones y mtodos que se ejecutan ante
determinada intervencin e interaccin del usuario ante el sistema.
sd Agregar Alumno
sd Borrar Alumno
table
table
Alumnos
Alumnos
Usuario
Formulario
Usuario
(from Equipo)
Nuevo_Alumno_Click()
Formulario
(from Equipo)
Alumno()
Boton_Borrar_Alumno_Click()
Alumno
Alumno()
Alumno
Boton_Guardar_Click()
Buscar
Alumno(Id_Alumno)
Alta_Alumno()
Datos Guardados()
Objeto Alumno()
Boton Salir()
Borrar Alumno()
~Alumno()
Borrar
Alumno(Id_Alumno)
~Formulario()
Alumno Eliminado()
(from casos de uso)
(from casos de uso)
Figura 50.- Refinamiento de Diagrama Actividades
Pgina 94 de 154
GlobalTec
Documento Final
Actividad 6: Refinamiento de Diagramas de Secuencias

El refinamiento de estos diagramas nos permitir detallar de manera ms
especifica la interaccin de los usuarios con el sistema de manera secuencial, es
decir las acciones u operaciones que sern ejecutadas al recibir un mensaje del
usuario, de tal manera que se pueda identificar cuando alguna accin o mtodo es
ejecutado, que valores requiere, como interacta con otros mtodos o con el
sistema, que es lo que nos regresara, cuando finaliza y que acciones se
ejecutaran al terminar su el ciclo de vida de los objetos.
Pgina 95 de 154
GlobalTec
Documento Final
Diagramas de Alumno
sd Borrar Alumno
sd Agregar Alumno
table
table
Alumnos
Usuario
Alumnos
Usuario
Formulario
Formulario
(from Equipo)
Nuevo_Alumno_Click()
(from Equipo)
Alumno()
Boton_Borrar_Alumno_Click()
Alumno
Alumno()
Alumno
Buscar
Alumno(Id_Alumno)
Alta_Alumno()
Datos Guardados()
Objeto Alumno()
Boton Salir()
Borrar Alumno()
~Alumno()
Borrar
Alumno(Id_Alumno)
~Formulario()
Alumno Eliminado()
(from casos de uso)
(from casos de uso)
sd Modificar Alumno
sd Consultar Alumnos
table
table
Alumnos
Alumnos
Usuario
Formulario
Usuario
(from Equipo)
Modificar Alumno Click()
Formulario
(from Equipo)
Alumno()
Boton_Consultar_Click()
Alumno
Buscar Alumno(Id_Alumno)
Alumno()
Alumno
Buscar_Alumno(T
ipo_Consulta)
Alumno Encontrado()
Ingresar Nuevos Datos()
Datos del Alumno()
[a]:Datos del Alumno()
Datos del Alumno()
Actualizar Click()
Guardar Datos()
Boton_Salir_Click()
Datos Guardados()
Boton_Salir_Click()
~Alumno()
(from casos de uso)
(from casos de uso)
Figura 51.- Diagrama Secuencias Alumno
Pgina 96 de 154
GlobalTec
Documento Final
Diagramas de Equipo
sd Borrar Equipo
sd Agregar Equipo
table
table
Equipo
Equipo
Usuario
Usuario
Formulario
Formulario
Boton_Borrar_Equipo()
Boton_Nuevo_Equipo_Clicl()
Equipo()
Equipo()
Equipo
Equipo
Buscar Equipo()
Obj_Equipo()
Datos Equipo()
Boton_Guardar()
Obj Equipo()
Guardar Datos()
Borrar Equipo()
Borrar Equipo()
Datos Guardados()
Equipo Borrado()
Datos Guardados Correctamente()

Equipo Borrado()
Boton Salir Click()
Boton_Salir()
~Equipo()
~Equipo()
(from casos de uso)
(from casos de uso)
sd Modificar Equipo
sd Consultar Equipo
table
table
Equipo
Equipo
Usuario
Usuario
Formulario
Formulario
Boton_Modificar_Click()
Equipo()
Equipo
Equipo()
Buscar Equipo()
Equipo
Datos Equipo()
Buscar Equipo(Tipo Consulta)
Datos Equipo()
Datos Equipo()
Datos Equipo()
Nuevos Datos()
Datos Equipo()
Obj_Equipo()
Actualizar_Click()
Actualizar()
Boton Salir Click()

Actualizacion Correcta()
~Equipo()
Boton Salir()
~Equipo()
(from casos de uso)
(from casos de uso)
Figura 52.- Diagrama Secuencias Equipo

Diagramas de
Pgina 97 de 154
GlobalTec
Documento Final
Becas
sd Alta Becas
sd Consultar Becas
table
table
Becas
Usuario
Becas
Usuario
Formulario
Formulario
Nueva_Beca_Clcik()
Beca()
Beca()
Becas
Becas
Consultar Beca(Tipo de Consulta)
Boton_Guardar()
Datos de Beca()
Alta_Beca()
Datos Beca()
Datos_ Beca()
Datos Guardados()
Boton_Salir_Click()
Boton Salir()
~Beca()
(from casos de uso)
sd Modificar Becas
(from casos de uso)

table
Becas
Usuario
Formulario
sd Borrar Becas
table
Becas
Modificar_Beca_Click()
Usuario
Formulario
Beca()
Becas
Borrar_Beca_Click()
Buscar Beca()
Beca()
Becas
Beca Encontrada()
Buscar Beca()
Beca Encontrada()
Beca Encontrada()
Beca Encontrada()
Acrtualizar_Click()
Borrar Beca()
Guardar Datos()
Borrar Beca()
Datos Guardados()
Borrado()
Boton Salir()
Boton Salir()
~Beca()
~Beca()
(from casos de uso)

(from casos de uso)
Figura 53.- Diagrama Secuencias Becas

Pgina 98 de 154
GlobalTec
Documento Final
Diagramas de Pagos
sd Borrar Pago
sd Agregar Pago
table
table
Pagos
Pagos
Usuario
Usuario
Formulario
Formulario
Nuevo_Pago_Click()
Borar_Pago_Click()
Pago()
Pago()
Pago
Pago
Buscar Pago()
Alta_Pago()
Pago Encontrado()
Borrar Pago()
Datos Guardados()
Borrar Pago()
Boton_Salir()
~Pago()
Borrado()
Boton Salir()
~Pago()
(from casos de uso)
(from casos de uso)
sd Actualizar Pago
sd Consultar Pago
table
table
Pagos
Usuario
Pagos
Formulario
Usuario
Formulario
Modificar_Pago_Click()
Boton Consultar Click()

Pago()
Pago
Buscar Pago()
Pago
Consulta Pago(Tipo Consulta)
Pago Encontrado()
Datos Pago()
Datos Pago()
Datos Pago()
Actualizar_Click()
Guardar Datos()
Boton Salir()
Datos Actualizados()
~Pago()
Boton Salir()
~Pago()
(from casos de uso)
(from casos de uso)
Figura 54.- Diagrama de secunacias pago

Pgina 99 de 154
GlobalTec
Documento Final
Diagramas Usuarios
sd Borrar Usuario
sd Agregar Usuario
tabl e
table
Usuarios
Usuari os
Admni si trador
Formulario
Admnisitrador
Formulario
Boton_Borrar_Usuari o()
Nuevo_Usuario_Click()
Usuario()
Usuario
Usuario
Buscar Usuari o((User o Id))
Obj _Usuari o()
Alta_Usuario()
Borrar Usuari o()
Datos Guardados()
Borrar
usuari o(User o
Id_Usuari o)
Datos Guardados()
Usuari o El mi ni ado()
Boton Salir()
Usuari o El i mni ado()
~Usuario()
Sal i r()
~Usuari o()
sd Modificar Usuario
sd Consultar Usuarios
table
table
Usuarios
Admnisitrador
Usuarios
Formulario
Admnisitrador
Formulario
Modificar Usuario()
Boton Consultar Click()

Usuario
Buscar Usuario(User o Id)
Usuario()
Usuario
Buscar Usuario(User o Id)
Usuario Encontrado()
Datos Usuario()
Datos Usuario()
Actualizar Click()
Guardar Datos(Nuevos Datos y Privilegios)
Boton Salir()
Boton Salir Click()
~Usuario()
~Usuario()
Figura 55.- Diagrama Secuencias Usuarios

Pgina 100 de 154
GlobalTec
Documento Final
Actividad 7: Tabla comparativa mostrando las inconsistencias detectadas

Antes
Clave
Fecha de Nacimiento
Despus
Alumno
Id_Alumno
Fecha Nac
Num_Equipo
Nombre
Nombre
Apellido Paterno
Apellido Materno
Direccin
Telfono
Nombre Tutor
Estado
Edad
Edad
Justificacin
Se agreg este campo para
identificar de forma nica a cada
alumno
poder verificar la edad de los
alumnos y as ubicarlos en el
equipo correspondiente
poder identificar a que equipo
pertenece cada alumno
Se agreg este campo
indispensable para poder tener la
identidad el alumno
Se agreg este campo
identidad el alumno
Se agreg este campo
identidad el alumno
Se agreg este campo contar con
la ubicacin bsica del alumno
Se agreg este campo contar con
un numero de ubicacin del
alumno
Se agreg este campo ya que
muchos de los alumnos son
menores de edad y por tanto
necesitan de un tutor
obtener un poco de ms de
ubicacin del alumno
poder ubicar a los alumnos en los
equipos acorde a su edad
Equipo
Entrenador
Se quit el campo entrenador ya

que nos pareci innecesario en el
sistema
Pgina 101 de 154
GlobalTec
Documento Final
Num_Equipo
Numero de Integrante
Nombre del Equipo
Nombre del Equipo
Horario
Nombre_Entrenador
Categoria
Numero_Alumnos
Pago
Id_Pago
Fecha de pago
Recargos
Fecha lmite de pago
Concepto
Importe
Descuentos
Estatus
Beca
Se agreg este campo

indispensable para diferenciar los
equipos
Se quit el nmero de integrante
ya que podemos identificarlo con
el Id_Alumno
personalizar y ubicar cada equipo
Se agreg este campo para llevar
un control de las clases de los
equipos
poder identificar al responsable
de cada equipo (entrenador)
poder tener una identificacin
ms a fondo de los equipos por
categoras
un control del nmero de
alumnos en cada equipo

identificar el tipo de pago
el control de la fecha de pagos
identificar los recargos a pagar
verificar la fecha lmite de pago
identificar mejor el tipo de pago
verificar el importe de pago
poder hacer uso de nuestros
beneficios en descuentos
poder identificar el estatus de
cada pago
Se quit este campo ya que se
Pgina 102 de 154
GlobalTec
Documento Final
cre una nueva clase con este

Calendario
Se quit este campo ya que con

los nuevos agregados nos
pareci innecesario
No era una clase
Beca
Tipo_Beca
No era una clase
Monto_Beca
Id_Beca
Id_Alumno
Fecha_deposito

identificar las distintas becas
verificar las cantidades de dinero
que deben ser entregadas a los
alumnos
Se agreg este campo para una
mayor identificacin de la beca
Se agreg este campo en beca
para identificar a los becarios
un control de la fecha de deposito
Usuarios
No exista
Id_Usuario
No exista
Usuario
No exista
Nombre completo
No exista
Tipo

identificar al usuario
asignarle un sobrenombre al
usuario
obtener informacin ms
completa del usuario
identificar qu tipo de usuario es
Tabla 6. Tabla comparativa comprobando inconsistencia
Pgina 103 de 154
GlobalTec
Documento Final
Actividad 8: Reporte de la estructura del sistema despus de haber realizado

el modelo de diseo en el caso de estudio
El reporte de la estructura del sistema se muestra en el diagrama de componentes
as como en los diagramas de clases y de secuencias, que muestra como est
conformado el sistema, que acciones realiza y de qu manera.
Pgina 104 de 154
GlobalTec
Documento Final
Actividad 9: Aplicar al menos una herramienta CASE para el diseo

Durante esta actividad utilizamos la herramienta CASE que ya venamos utilizando
el Enterprise Architec la cual permite realizar diversos diagramas de diseo que
nos permitirn definir acciones y especificaciones de las tareas del sistema.
Utilizamos esta herramienta para realizar Casos de Usos, Diagramas de Clases,
Diagramas de Secuencias, Diagramas de Colaboracin y Diagramas de
Componentes.
Como evidencia de la aplicacin de la herramienta CASE se encuentran los

dems diagramas que realizamos se muestran en cada una de las actividades con
las imgenes de los diagramas correspondientes realizadas en esta herramienta
CASE.
Pgina 105 de 154
GlobalTec
Documento Final
Unidad 5: Modelo de implementacin

Parte Terica
5.1 Diagramas de Componentes
Los Diagramas de Componentes ilustran las piezas del software, controladores
embebidos, etc. que conformarn un sistema. Un diagrama de Componentes tiene
un nivel ms alto de abstraccin que un diagrama de clase usualmente un
componente se implementa por una o ms clases (u objetos) en tiempo de
ejecucin. Estos son bloques de construccin, como eventualmente un
componente puede comprender una gran porcin de un sistema (Figura 58).
Figura 57.- Diagrama de componentes

El diagrama de arriba muestra algunos componentes y sus relaciones internas.
Los conectores Ensamble vinculan las interfaces proporcionadas suministrada
por el Producto y el Cliente a las interfaces requeridas especificadas por orden.
Una relacin de dependencia traza los detalles de la cuenta asociada del cliente a
la interfaz requerida, pago, indicada por orden.
Los componentes son similares en prctica a los diagramas de paquete como los
lmites definidos y se usan para agrupar elementos en estructuras lgicas. La
Pgina 106 de 154
GlobalTec
Documento Final
diferencia entre Diagramas de Paquete y Diagramas de Componente es que los

diagramas de componente ofrecen un mecanismo de agrupamiento ms rico
semnticamente. Con los Diagramas de Componente todos los elementos del
modelo son privados mientras que los diagramas de Paquete solo muestran tems
pblicos.
Representando componentes: Componentes se representan como un

clasificador rectangular con la clave componente, opcionalmente el componente
se puede mostrar como un rectngulo con un icono de componente en la esquina
derecha arriba (Figura 59).
Figura 58.- Representado Componentes

Interfaces requeridas: El conector Ensamble une la interfaz requerida del
componente (Componente1) con la interfaz proporcionada de otro componente
(Component2); esto permite que un componente provea los servicios que otro
componente requiere. Las Interfaces son colecciones de uno o ms mtodos que
pueden o no contener atributos (Figura 60).
Figura 59.- Componentes Requeridos

Componentes con puertos: Usar puertos con Diagramas de Componentes
permite que se especifique un servicio o comportamiento a su entorno as como
tambin un servicio o comportamiento que un componente requiere. Los puertos
pueden especificar entradas, salidas as como tambin operar bidireccionalmente.
El siguiente diagrama detalla un componente con un puerto para servicios En
Lnea conjuntamente con dos interfaces proporcionadas Ordenar Entrada y
Seguimiento as como tambin una interfaz requerida Pago (Figura 61).
Pgina 107 de 154
GlobalTec
Documento Final
Figura 60.- Componente con puertos
Pgina 108 de 154
GlobalTec
Documento Final
5.2 Diagrama de despliegue

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecucin de un
sistema. Esto muestra la configuracin de los elementos de hardware (nodos) y
muestra cmo los elementos y artefactos del software se trazan en esos nodos.
Nodo: Un Nodo es un elemento de hardware o software. Esto se muestra con la
forma de una caja en tres dimensiones, como a continuacin (Figura 62).
Figura 61.-Nodo
Instancia de nodo: Una instancia de nodo se puede mostrar en un diagrama. Una
instancia se puede distinguir desde un nodo por el hecho de que su nombre esta
subrayado y tiene dos puntos antes del tipo de nodo base. Una instancia puede o
no tener un nombre antes de los dos puntos. El siguiente diagrama muestra una
instancia nombrada de una computadora (Figura 63).
Figura 62.- Instancia de Nodo

Estereotipo de nodo: Un nmero de estereotipos estndar se proveen para los
nodos, nombrados cdrom, cd-rom, computer, disk array, pc, pc
client, pc server, secure, server, storage, unix server, user pc.
Estos mostrarn un icono apropiado en la esquina derecha arriba del smbolo
nodo (Figura 64).
Figura 63.- Estereotipo nodo
Pgina 109 de 154
GlobalTec
Documento Final
Artefacto: Un artefacto es un producto del proceso de desarrollo de software, que

puede incluir los modelos del proceso (eje. modelos de Casos de Uso, modelos de
Diseo, etc.), archivos fuente, ejecutables, documentos de diseo, reportes de
prueba, prototipos, manuales de usuario y ms. Un artefacto se denota por un
rectngulo mostrando el nombre del artefacto, el estereotipo artifact y un icono
de documento, como a continuacin (Figura 65).
Figura 64.- Artefacto

Asociacin: En el contexto del diagrama de despliegue, una asociacin
representa una ruta de comunicacin entre los nodos. El siguiente diagrama
muestra un diagrama de despliegue para una red, mostrando los protocolos de red
como estereotipos y tambin mostrando multiplicidades en los extremos de la
asociacin (Figura 66).
Figura 65.- Modelo conexin
Pgina 110 de 154
GlobalTec
Documento Final
Nodo como contenedor: Un nodo puede contener otros elementos, como

componentes o artefactos. El siguiente diagrama muestra un diagrama de
despliegue para una parte del sistema embebido y muestra un artefacto ejecutable
como contenido por el nodo madre (motherboard) (Figura 67).
Figura 66.- Modelo Incrustado
Pgina 111 de 154
GlobalTec
Documento Final
5.3 Modelos de pruebas

Uno de los objetivos de la fase de pruebas del sistema es verificar que el
comportamiento externo del sistema software satisface los requisitos establecidos
por los clientes y futuros usuarios del mismo. A medida que aumenta la
complejidad de los sistemas software y aumenta la demanda de calidad, se hacen
necesarios procesos y mtodos que permitan obtener buenos conjuntos de
pruebas del sistema. Este trabajo describe los modelos necesarios para generar
de manera sistemtica un conjunto de pruebas que permitan verificar la
implementacin de los requisitos funcionales de un sistema software.
La fase de pruebas del sistema tiene como objetivo verificar el sistema software
para comprobar si este cumple sus requisitos. Dentro de esta fase pueden
desarrollarse varios tipos distintos de pruebas en funcin de los objetivos de las
mismas. Algunos tipos son pruebas funcionales, pruebas de usabilidad, pruebas
de rendimiento, pruebas de seguridad, etc. Este trabajo se centra en pruebas
funcionales de aplicaciones con interfaces grficas. Estas pruebas verifican que el
sistema software ofrece a los actores humanos la funcionalidad recogida en su
especificacin.
Una de las tcnicas ms empleadas para la especificacin funcional de sistemas
software son los casos de uso. Las principales ventajas de los casos de uso son
que ocultan los detalles internos del sistema, son rpidos de construir, fciles de
modificar y entender por los clientes y futuros usuarios del sistema y pueden
aplicarse a distintos tipos de sistemas. Actualmente, existe un amplio nmero de
propuestas que describen cmo generar pruebas del sistema a partir de los casos
de uso.
Los casos de uso contienen elementos variables cuyos valores o comportamiento
difiere de una ejecucin de un caso de uso a otra. Algunos ejemplos son la
informacin suministrada por un actor, una opcin seleccionada por un actor, o la
informacin mostrada por el sistema como resultado del caso de uso.
Los objetivos del modelo de datos de prueba son dos. En primer lugar, el modelo
de datos de prueba expresa todas las variables del caso de uso, su estructura si
son tipos complejos (como clientes o compras), las restricciones que puedan
existir entre ellos y las particiones de sus respectivos dominios. Esto se realiza
mediante un diagrama de clases segn la notacin propuesta en el Testing Profile
de UML. Dicho diagrama de clases puede extraerse automticamente. Las clases
se obtienen a partir de los requisitos funcionales y las distintas particiones se
obtienen a partir de las condiciones evaluadas en las alternativas del diagrama de
comportamiento. Este diagrama de clases puede refinarse posteriormente
aadiendo particiones adicionales si fuera necesario.
Pgina 112 de 154
GlobalTec
Documento Final
Qu tipo de pruebas se pueden hacer en ingeniera del software?

Una vez obtenido el cdigo ejecutable de un programa depurado lo mximo
posible, hay que comprobar, exhaustivamente, su funcionalidad. Para ello, se tiene
que ejecutar tantas veces como se considere necesario, proporcionndole, cada
vez, datos de entrada distintos, y comprobando si los datos de salida son siempre
los esperados.
El cdigo ejecutable de un programa es imposible que tenga errores de sintaxis,
ya que, estos habrn sido detectados por el compilador y corregidos por el
programador. Por tanto, las pruebas a realizar se deben centrar en la bsqueda de
errores de ejecucin o de lgica.
Para estar totalmente seguros del buen funcionamiento de un programa se
debera probar con todas las combinaciones posibles de entrada, cosa que suele
ser imposible, ya que, stas podran ser infinitas. As pues, las pruebas tienen que
ser muy bien elegidas, intentando abarcar el mayor nmero de casos, y poniendo
a prueba al programa en aspectos crticos.
En un programa tan simple como el de este ejemplo, las pruebas a realizar
pueden llevar poco tiempo. Sin embargo, cuando se desarrolla una aplicacin
grande, las pruebas pueden tardar semanas o incluso meses. Las pruebas no slo
se deben centrar en la comprobacin del tratamiento de los datos, sino tambin en
aspectos como: la adaptacin de la aplicacin al resto del sistema informtico o la
interaccin del software con otras aplicaciones ya existentes. Una aplicacin
informtica de tal envergadura puede estar formada por cientos o miles de
programas, y todos ellos deben ser probados individual y conjuntamente. Antes de
implantar un software de estas caractersticas, lo normal es hacer simulaciones
con datos reales para verificar su buen funcionamiento.
Para corregir los errores de ejecucin o de lgica encontrados en la fase de
pruebas, casi siempre, por no decir siempre, hay que modificar el algoritmo y, en
algunos casos, incluso hay que volver a analizar el problema, volviendo a pasar
por todas las fases de desarrollo; de lo cual se deduce que, cuanto mejor se haga
el anlisis y el diseo de una aplicacin, la probabilidad de encontrar errores en la
fase de pruebas ser menor.
Pgina 113 de 154
GlobalTec
Documento Final
Tipos de pruebas:
Pruebas estticas
Son el tipo de pruebas que se realizan sin ejecutar el cdigo de la aplicacin.
Pruebas dinmicas
Todas aquellas pruebas que para su ejecucin requieren la ejecucin de la
aplicacin.
Tipos de pruebas por su ejecucin
Pruebas automticas
Pruebas manuales
Niveles de pruebas
Pruebas unitarias
Pruebas de Integracin
Pruebas de sistema
Pruebas funcionales
Pruebas funcionales
Pruebas de humo
Pruebas de regresin
Pruebas de aceptacin
Alpha testing
Beta testing
Pruebas no funcionales
Pruebas no funcionales
Pruebas de seguridad
Pruebas de usabilidad
Pruebas de rendimiento
Pruebas de internacionalizacin y localizacin
Pruebas de escalabilidad
Pruebas de mantenibilidad
Pruebas de instabilidad
Pruebas de portabilidad
Pgina 114 de 154
GlobalTec
Documento Final
Actividad 1: Aplicacin de Herramienta CASE Para Generar Cdigo
En esta actividad utilizamos los diagramas de clases que realizamos en la
herramienta CASE Enterprise Architect para generar el cdigo fuente en el
lenguaje de programacin Java a partir de estos diagramas de clases, dicha
herramienta tambin tiene soporte para otro lenguajes de programacin.
Pgina 115 de 154
GlobalTec
Documento Final
Pgina 116 de 154
GlobalTec
Documento Final
Pgina 117 de 154
GlobalTec
Documento Final
Pgina 118 de 154
GlobalTec
Documento Final
Actividad 2: Tcnicas de Prueba

Una vez que el cdigo fuente ha sido generado, el software debe someterse a
prueba para descubrir errores (y corregir) el mayor nmero posible de antes de la
entrega a su cliente. Su objetivo es disear una serie de casos de prueba que
tienen una alta probabilidad de encontrar errores, pero cmo? Ah es donde las
tcnicas de pruebas de software entran en escena. Estas tcnicas proporcionan
orientacin sistemtica para el diseo de las pruebas de que hagan uso de la
lgica interna de los componentes de software el ejercicio de los dominios de
entrada y salida del programa para descubrir los errores en funcin del programa,
el comportamiento y el rendimiento.
Quin lo hace? Durante las etapas iniciales de la prueba, un ingeniero de
software realiza todas las pruebas. Sin embargo, como el proceso de prueba
progresa, los especialistas de prueba pueden participar.
Por qu es importante? Comentarios y otras actividades de SQA (Software
quality assurance) pueden y descubrir los errores, pero no son suficientes. Cada
vez que se ejecuta el programa, el cliente lo pone a prueba. Por lo tanto, usted
tiene que ejecutar el programa antes de que llegue al cliente con la intencin
especfica de encontrar y eliminar todos los errores. Con el fin de encontrar el
mayor nmero posible de errores, los ensayos se llevan a cabo de manera
sistemtica y los casos de prueba deben ser diseados usando tcnicas
disciplinadas.
En la etapa de prueba del software se crean una serie de casos de prueba que
intentan "destruir" el software desarrollado. La prueba requiere que se descarten
ideas preconcebidas sobre la "calidad o correccin" del software desarrollado.
La prueba es un proceso de ejecucin de un programa con la intencin de

descubrir un error
Un buen caso de prueba es aquel que tiene una alta probabilidad de
mostrar un error no descubierto hasta entonces
Una prueba tiene xito si descubre un error no detectado hasta entonces El
objetivo es disear casos de prueba que, sistemticamente, saquen a la luz
diferentes clases de errores, hacindolo con la menor cantidad de tiempo y
de esfuerzo.
La prueba no puede asegurar la ausencia de errores; slo puede demostrar que

existen defectos en el software.
Pgina 119 de 154
GlobalTec
Documento Final
Proceso de prueba
Figura 71.- Proceso de prueba

El proceso de prueba tiene dos entradas:
Configuracin del software: Incluye la especificacin de requisitos del

software, la especificacin del diseo y el cdigo fuente
Configuracin de prueba: Incluye un plan y un procedimiento de prueba
Si el funcionamiento del software parece ser correcto y los errores encontrados

son fciles de corregir, podemos concluir con que:
La calidad y la fiabilidad del software son aceptables, o que

Las pruebas son inadecuadas para descubrir errores serios
Diseo de casos de prueba

Se trata de disear pruebas que tengan la mayor probabilidad de encontrar el
mayor nmero de errores con la mnima cantidad de esfuerzo y de tiempo.
Cualquier producto de ingeniera se puede probar de dos formas:
Pruebas de caja negra: Realizar pruebas de forma que se compruebe que cada
funcin es operativa.
Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la
operacin interna se ajusta a las especificaciones, y que todos los componentes
internos se han probado de forma adecuada.
En la prueba de la caja negra, los casos de prueba pretenden demostrar que las
funciones del software son operativas, que la entrada se acepta de forma
adecuada y que se produce una salida correcta.
En la prueba de caja blanca se realiza un examen minucioso de los detalles
procedimentales, comprobando los caminos lgicos del programa, comprobando
los bucles y condiciones, y examinado el estado del programa en varios puntos.
Pgina 120 de 154
GlobalTec
Documento Final
Prueba de la caja blanca

La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usa
la estructura de control del diseo procedimental para derivar los casos de prueba.
Las pruebas de caja blanca intentan garantizar que:
Se ejecutan al menos una vez todos los caminos independientes de cada
mdulo
Se utilizan las decisiones en su parte verdadera y en su parte falsa
Se ejecuten todos los bucles en sus lmites
Se utilizan todas las estructuras de datos internas
Prueba del camino bsico
El mtodo del camino bsico (propuesto por McCabe) permite obtener una medida
de la complejidad de un diseo procedimental, y utilizar esta medida como gua
para la definicin de una serie de caminos bsicos de ejecucin, diseando casos
de prueba que garanticen que cada camino se ejecuta al menos una vez.
Notacin del grafo de flujo o grafo del programa
Representa el flujo de control lgico con la siguiente notacin:
Figura 72.- Proceso de prueba
Figura 73.- Proceso de Prueba
Pgina 121 de 154
GlobalTec
Documento Final
Figura 74.- Proceso de Prueba
Complejidad ciclomtica
Es una medida que proporciona una idea de la complejidad lgica de un
programa.
La complejidad ciclomtica coincide con el nmero de regiones del grafo de

flujo
La complejidad ciclomtica, V(G), de un grafo de flujo G, se define como:
V (G) = Aristas - Nodos + 2
La complejidad ciclomtica, V(G), de un grafo de flujo G, tambin se define
como V(G) = Nodos de predicado + 1
A partir del grafo de flujo de la ilustracin 4, la complejidad ciclomtica sera:
Como el grafo tiene cuatro regiones, V(G) = 4

Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 - 2 = 4
Como el grafo tiene 3 nodos predicado, V(G) = 3 + 1 = 4
A partir del valor de la complejidad ciclomtica obtenemos el nmero de caminos

independientes, que nos dan un valor lmite para el nmero de pruebas que
tenemos que disear.
En el ejemplo, el nmero de caminos independientes es 4, y los caminos
independientes son:
Pgina 122 de 154
GlobalTec
Documento Final
1-11
1-2-3-4-5-10-1-11
1-2-3-6-7-9-10-1-11
1-2-3-6-8-9-10-1-11
Pasos del diseo de pruebas mediante el camino bsico
Obtener el grafo de flujo, a partir del diseo o del cdigo del mdulo
Obtener la complejidad ciclomtica del grafo de flujo
Definir el conjunto bsico de caminos independientes
Determinar los casos de prueba que permitan la ejecucin de cada uno de
los caminos anteriores
Ejecutar cada caso de prueba y comprobar que los resultados son los
esperados
Prueba de bucles
Los bucles son la piedra angular de la inmensa mayora de los algoritmos
implementados en software, por lo que tenemos que prestarles una atencin
especial a la hora de realizar la prueba del software. La prueba de bucles es una
tcnica de prueba de caja blanca que se centra en la validez de las construcciones
de los bucles. Se pueden definir cuatro tipos de bucles diferentes:
Bucles simples
Bucles concatenados
Bucles anidados
Bucles no estructurados
Figura 75.- Prueba de bucles

Pgina 123 de 154
GlobalTec
Documento Final
Bucles simples
A los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de
pruebas siguientes:
Saltar el bucle
Pasar slo una vez por el bucle
Pasar dos veces por el bucle
Hacer m pasos del bucle con m < n
Hacer n-1, n y n+1 pasos por el bucle
Bucles anidados
Si extendisemos el conjunto de pruebas de los bucles simples a los bucles
anidados, el nmero de pruebas crecera geomtricamente, por lo que Beizer
sugiere el siguiente conjunto de pruebas para bucles anidados:
Comenzar con el bucle ms interno, estableciendo los dems bucles a los
valores mnimos
Llevar a cabo las pruebas de bucles simples para el bucle ms interno,
conservando los valores de iteracin de los bucles ms externos a los
valores mnimos
Progresar hacia fuera en el siguiente bucle ms externo, y manteniendo los
bucles ms externos a sus valores mnimos
Continuar hasta que se hayan probado todos los bucles
Bucles concatenados
Probar los bucles concatenados mediante las tcnicas de prueba para bucles
simples, considerndolos como bucles independientes.
Bucles no estructurados
Redisear estos bucles para que se ajusten a las construcciones de la
programacin estructurada.
PRUEBA DE LA CAJA NEGRA
Las pruebas de caja negra se llevan a cabo sobre la interfaz del software,
obviando el comportamiento interno y la estructura del programa. Los casos de
prueba de la caja negra pretenden demostrar que:
Las funciones del software son operativas
La entrada se acepta de forma correcta
Se produce una salida correcta
La integridad de la informacin externa se mantiene
Pgina 124 de 154
GlobalTec
Documento Final
A continuacin se derivan conjuntos de condiciones de entrada que utilicen todos

los requisitos funcionales de un programa. Las pruebas de caja negra pretenden
encontrar estos tipos de errores:
Funciones incorrectas o ausentes
Errores en la interfaz
Errores en estructuras de datos o en accesos a bases de datos externas
Errores de rendimiento
Errores de inicializacin y de terminacin
Los tipos de prueba de cana negra que vamos a estudiar son:
Prueba de particin equivalente
Prueba de particin equivalente

Este mtodo de prueba de caja negra divide el dominio de entrada de un
programa en clases de datos, a partir de las cuales deriva los casos de prueba.
Cada una de estas clases de equivalencia representa a un conjunto de estados
vlidos o invlidos para las condiciones de entrada.
Identificacin de las clases de equivalencia
Se identifican clases de equivalencia vlidas e invlidas con la siguiente tabla
Tabla 7.- Prueba de particin equivalente
Pgina 125 de 154
GlobalTec
Documento Final
Actividad 3: Mtodos de implementacin de las empresas de desarrollo de

software
El desarrollo de software es una actividad catica, frecuentemente caracterizada
por la frase "codifica y corrige". El software se escribe con un plan subyacente
mnimo, y el diseo del sistema se adoquina con muchas decisiones a corto plazo.
Esto realmente funciona muy bien si el sistema es pequeo, pero conforme el
sistema crece llega a ser cada vez ms difcil agregar nuevos aspectos al mismo.
Adems los bugs llegan a ser cada vez ms frecuentes y ms difciles de corregir.
La sea tpica de tal sistema es una larga fase de pruebas despus de que el
sistema ha sido "completado". Tal fase larga de pruebas hace estragos con los
planes de pruebas y depurado llegando a ser imposible de incluir en el programa
de trabajo.
Metodologas usadas por Ricardo Vzquez Garca desarrollador de software
en softLab
Nos dedicamos a la creacin de soluciones empresariales para la WEB. Usamos
la suite de Microsoft Visual Studio 2012 as como software de terceros que
usualmente compramos a Telerik para incrementar la calidad de los productos y
disminuir el tiempo de codificado.
Usamos C# para escribir el software por el poder y portabilidad que tiene en
comparacin a otros lenguajes de .Net.
En softLab usamos mucho lo que es la entrega de Prototipos, pues es ventajosa
en el sentido de que con cada cambio que se hace al software se le notifica al
cliente, y de esta manera podemos tener un control de calidad respecto a lo que el
cliente espera de la funcionalidad del mismo.
La desventaja de usar esto o al menos la que yo encuentro hasta el momento, es
que por la misma razn de estar entregando cada cambio al cliente, el tiempo de
entrega se extiende muchsimo, pues hay que estar ms pendientes a los cambios
grandes o pequeos que se hagan al Software.
Pgina 126 de 154
GlobalTec
Documento Final
Evidencias:
Figura 77.- Evidencia
Figura 76.- Evidencia
Pgina 127 de 154
GlobalTec
Documento Final
Modelo de Prototipos
Un cliente, a menudo, define un conjunto de objetivos generales para el software,
pero no identifica los requisitos detallados de entrada, proceso o salida. En otros
casos, el responsable del desarrollo del software puede no estar seguro de la
eficiencia de un algoritmo, de la calidad de adaptacin de un sistema operativo, o
de la forma en que debera tomarse la interaccin hombre-mquina. En estas y en
otras muchas situaciones, un paradigma de construccin de prototipos puede
ofrecer el mejor enfoque.
El paradigma de construccin de prototipos comienza con la recoleccin de
requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales
para el software, identifican los requisitos conocidos y las reas del esquema en
donde es obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo
rpido se centra en una representacin de esos aspectos del software que sern
visibles para el usuario/cliente. El diseo rpido lleva a la construccin de un
prototipo. El prototipo lo evala el cliente/usuario y se utiliza para refinar los
requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo se
pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo
tiempo que el desarrollador comprenda mejor lo que se necesita hacer.
Figura 78.- Modelo de prototipos
Pgina 128 de 154
GlobalTec
Documento Final
Referencias
Unidad 1
Libros
Ttulo: Conceptos Bsicos de la Ingeniera de software
Libro: Software Engineering
Edicin: 6th Edicin
Autor: Ian Sommerville
Ttulo: Clasificacin de Herramientas Case
Libro: Software Engineering
Edicin: 6th Edicin
Autor: Ian Sommerville
Ttulo: Evolucin del software
Libro: Ingeniera de Software un enfoque practico
Edicin: 5ta Edicin
Autor: Roger S. Pressman
Ttulo: Ingeniera del software un enfoque practico
Libro: Pressman Roger
Edicin: 5ta Edicin
Sitios Web
Herramientas CASE
[4]http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf
Clasificacin de las herramientas CASE
[1]http://www.monografias.com/trabajos14/herramicase/herramicase.shtml
Historia de las herramientas CASE
[2]http://eltamiz.com/elcedazo/2009/05/12/herramientas-case-hasta-en-la-sopa/
Clasificacin de las herramientas CASE
[3]http://www.uclm.es/ab/educacion/ensayos/pdf/revista10/10_17.pdf
Pgina 129 de 154
GlobalTec
Documento Final
Unidad 2
Sitios Web
Modelo de requisitos
[1]http://www.cannes.itam.mx/Alfredo/Espaniol/Publicaciones/MINT/Requisitos.pdf
Tcnicas para la obtencin de requisitos
[2]http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos#T.C3.A9cnicas_pri
ncipales
[3]http://www.monografias.com/trabajos6/resof/resof2.shtml#teec
Tareas de la ingeniera de requisitos
[4]http://redalyc.uaemex.mx/pdf/666/66661111.pdf
Herramientas CASE para la ingeniera de requisitos
[5]http://es.scribd.com/doc/19083744/INGENIERIA-DE-REQUERIMIENTOS
[6]http://www.revistasjdc.com/main/index.php/ccient/article/view/37/36
Libros
Ttulo: Ingeniera de Requerimientos
Autor: Diana Santofimio Ariza
Fecha: Agosto del 2009
Ttulo: Herramientas CASE para Ingeniera de Requisitos

Autor: Instituto de Investigaciones Cientficas
Fecha: 2008
Unidad 3
Libros
Ttulo: arquitectura de clases y clases
Libro: UML y Patrones (Craig Larman)
Autor: Weizenfeld
Ttulo: identificacin de clases segn su estereotipo
Captulo 7 del libro Ingeniera de software orientada a objetos con UML
Pgina 130 de 154
GlobalTec
Documento Final
Libro: UML gota a gota pg. 102

Sitios Web
Modelo de anlisis
[1]http://www.slideshare.net/juliopari/13-clase-flujo-de-analisis
Identificacin de clases segn estereotipos
[2]http://es.scribd.com/doc/52037161/4/Identificacion-de-Clases-segunEstereotipos
Unidad 4
Libros
Ttulo: Diseo de sistema
Libro: Software Engineering A P R A C T I T I O N E R S A P P R O A C H
Captulo 22
Sitios Web
Estrategias de diseo
[1]http://translate.google.com.mx/translate?hl=es&langpair=en%7Ces&u=http://nev
erletdown.net/2010/08/choosing-a-software-design-strategy/
Diseo de sistemas
[2]http://www.slideshare.net/SergioRios/unidad-21-diseo-de-sistemas Pg. 59
Unidad 5
Sitios Web
Diagrama de despliegue
[1]http://www.sparxsystems.com.ar/resources/tutorial/uml2_deploymentdiagram.ht
ml
Diagrama de componentes
[2]http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.ht
ml
Pgina 131 de 154
GlobalTec
Documento Final
Modelos de prueba
[3]http://ceur-ws.org/Vol-227/paper07.pdf
[4]http://farova2.blogspot.mx/2008/10/modelo-de-pruebas-de-software.html
Tipos de pruebas
[5]http://es.wikipedia.org/wiki/Pruebas_de_software
[6]http://www.carlospes.com/curso_de_ingenieria_del_software/05_01_pruebas.ph
p
Pgina 132 de 154
GlobalTec
Documento Final
Anexos
Anexo 1: Calendario ITZ (Pgina 1)
Pgina 133 de 154
GlobalTec
Documento Final
Anexo 1: Calendario ITZ (Pgina 2)
Pgina 134 de 154
GlobalTec
Documento Final
Anexo 2: Calendario SEP
Pgina 135 de 154
GlobalTec
Documento Final
Anexo 3: Manual del estudiante (Pgina 1)
Pgina 136 de 154
GlobalTec
Documento Final
Pgina 137 de 154
GlobalTec
Documento Final
Pgina 138 de 154
GlobalTec
Documento Final
Pgina 139 de 154
GlobalTec
Documento Final
Anexo 4: O ISIC -2010-224 Fundamentos de Ingeniera de Software (Pgina 1)
Pgina 140 de 154
GlobalTec
Documento Final
Pgina 141 de 154
GlobalTec
Documento Final
Pgina 142 de 154
GlobalTec
Documento Final
Pgina 143 de 154
GlobalTec
Documento Final
Pgina 144 de 154
GlobalTec
Documento Final
Pgina 145 de 154
GlobalTec
Documento Final
Pgina 146 de 154
GlobalTec
Documento Final
Pgina 147 de 154
GlobalTec
Documento Final
Pgina 148 de 154
GlobalTec
Documento Final
Anexo 5: Oficio de asignacin de proyecto
Pgina 149 de 154
GlobalTec
Documento Final
Anexo 6: Hoja de proyecto (especificaciones del cliente, pgina 1)
Pgina 150 de 154
GlobalTec
Documento Final
Anexo 6: Hoja de proyecto (especificaciones del cliente, pgina 2)
Pgina 151 de 154
GlobalTec
Documento Final
Anexo 7: Examen escrito Unidad 1 Realizado por: Franklin Monreal Cristerna

(pgina 1)
Pgina 152 de 154
GlobalTec
Documento Final
Anexo 7: Examen escrito Unidad 1 Realizado por: Franklin Monreal Cristerna

(pgina 2)
Pgina 153 de 154
GlobalTec
Documento Final
Anexo 8: Programa de Actividades Realizadas durante el curso, organizadas

a travs del programa X-Mind
Pgina 154 de 154
GlobalTec
Documento Final
Pgina 155 de 154

Fundamentos de Ingenieria de Software

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Fundamentos de Ingenieria de Software

Încărcat de

Drepturi de autor:

Formate disponibile

[Escriba aqu]

Integrantes del Equipo:

Actividad 3: Aplicar el modelo objeto-relacin comportamiento que indique como .... 69

Ingeniera en Sistemas Computacionales

Unidad 1 ..................................................................................................................................... 129

Ingeniera en Sistemas Computacionales

Ingeniera en Sistemas Computacionales

Figura 38.- Tipos de mensaje ....................................................................................................... 83

Ingeniera en Sistemas Computacionales

Unidad 1: Fundamentos de ingeniera de software.

Desarrollo.- Produccin del sistema de software.

Ingeniera en Sistemas Computacionales

Documento.- Testimonio material de un hecho o acto realizado en el ejercicio de

1.2 El Papel Evolutivo del Software

Figura 1.- Linea del tiempo

Ingeniera en Sistemas Computacionales

1.3 Etapas del Desarrollo del Software

Tabla 1. Tareas aplicadas en el desarrollo del software

Ingeniera en Sistemas Computacionales

1.4 Definicin e Historia de las Herramientas Case

Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser

Ingeniera en Sistemas Computacionales

Ingeniera en Sistemas Computacionales

La primera herramienta comercial se remonta a 1982, aunque algunos

Una mejora en la calidad, fiabilidad, utilidad y rendimiento.

Ingeniera en Sistemas Computacionales

1.5 Clasificacin de las Herramientas CASE

Las plataformas que soportan.

1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado):

Ingeniera en Sistemas Computacionales

Clasificacin basada en su funcionalidad

Tabla 2. Calificacin basada en su funcionalidad

Ingeniera en Sistemas Computacionales

Clasificacin basada en el ciclo de vida del desarrollo de sistemas que cubren

Clasificacin basada en su integracin

Figura 2.- Clasificacin basada en su integracin

Ingeniera en Sistemas Computacionales

Unidad 2: Ingeniera de requisitos

Ingeniera en Sistemas Computacionales

el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones,

Ingeniera en Sistemas Computacionales

2.2 Tcnicas de la Ingeniera de Requisitos

Ingeniera en Sistemas Computacionales

Ingeniera en Sistemas Computacionales

El equipo en una lluvia de ideas debe estar formado por:

proceso contina hasta que se haya desarrollado el producto final. La adopcin de

Encontrar los requerimientos que van a ser priorizados.

Estos pasos pueden aplicarse fcilmente a una cantidad pequea de

Ingeniera en Sistemas Computacionales

Esta tcnica se enfrenta a los siguientes peligros potenciales:

2.3 Modelado de Requisitos

Ingeniera en Sistemas Computacionales

describe aqu desde la perspectiva del usuario. El modelo de requisitos no es un

Ingeniera en Sistemas Computacionales

2.4 Herramientas CASE para la Ingeniera de Requisitos

Herramientas de diseo para dar apoyo al anlisis de datos.

Ingeniera en Sistemas Computacionales

sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo

Ingeniera en Sistemas Computacionales

Nombre del alumno (nombre completo del aspirante)

Las colegiaturas sern pagadas en las fechas estipuladas.

Ingeniera en Sistemas Computacionales

Otros requisitos obligatorios:

La credencial es obligatoria con vigencia al ciclo anual.