DIRECCIN GENERAL DE EDUCACIN SUPERIOR TECNOLOGICA

INSTITUTO TECNOLOGICO DE ACAPULCO

MATERIA:
FUNDAMENTOS DE INGENIERA DE SOFTWARE
UNIDADES 1-5 DE LA MATERIA DE FUNDAMENTOS DE
INGENIERA DE SOFTWARE

CARRERA:
INGENIERIA EN SISTEMAS COMPUTACIONALES

PERODO: AGOSTO-DICIEMBRE 2014

NDICE

UNIDAD 1. FUNDAMENTOS DE INGENIERA DE SOFTWARE

Introduccin. 5
1.1 Conceptos bsicos..... 6
1.2 Papel evolutivo del software........15
1.3 Etapas de desarrollo software...24
1.4 Clasificacin de la tecnologa en el desarrollo de software
(tecnologa estructurada y orientada a objetos)28
1.5 Definicin e historia de las herramientas CASE.33
1.6 Clasificacin de las herramientas CASE..35
Conclusin42
UNIDAD 2. INGENIERA DE REQUISITOS
Introduccin.43
2.1. Tareas de la Ingeniera de Requisitos...44
2.2. Tcnicas de la Ingeniera de Requisitos.48
2.3. Modelado de requisitos..52

2.4. Herramientas CASE para la Ingeniera de requisitos55

Conclusin.59
UNIDAD 3. MODELO DE ANLISIS
Introduccin61
3.1. Arquitectura de clases.62
3.2. Identificacin de clases segn Estereotipos...64
3.3. Clases.70
3.4. Diagramas de secuencias76
3.5. Diccionario de clases segn Mdulos79
3.6. Herramientas CASE para el anlisis..85
Conclusin..89
UNIDAD 4. MODELO DE DISEO
Introduccin..90
4.1. Estrategias de diseo..91
4.2. Diseo de objetos.97
4.3. Diseo de sistema..100

4.4. Revisin del diseo.104

4.5. Diagramas de secuencias del Diseo.......106
4.6. Herramientas CASE para el diseo.108
Conclusin111
UNIDAD 5. MODELO IMPLEMENTACIN
Introduccin..112

5.1. Diagrama de componentes.114

5.2. Diagrama de despliegue. 117
5.3. Modelos de pruebas.119
Conclusin.122

UNIDAD 1. FUNDAMENTOS DE INGENIERA DE

SOFTWARE
INTRODUCCIN

El trmino Ingeniera de Software surge a final de los aos 60 dentro de una

conferencia dedicada a la crisis del software.
La Ingeniera de Software se define cmo la disciplina tecnolgica relacionada
con la produccin sistemtica y el mantenimiento de productos de software que
son desarrollados y modificados en el tiempo previsto y dentro de los costos
estimados. El objetivo de la Ingeniera de Software es producir productos de
software.
En esta unidad se pretende dar una introduccin a la ingeniera de software,
comprendiendo sus conceptos bsicos, orgenes y evolucin de esta rama a lo
largo de los aos (O generaciones), tipos de tecnologas que comprende y
adems una breve descripcin de cada una de las etapas del desarrollo de
software. Tambin se introduce a las herramientas CASE, qu son y cul es su
origen.

1.1 CONCEPTOS BSICOS

Qu es el software?

El software de computadora es el producto que disean y construyen los

ingenieros del software. Esto abarca programas que se ejecutan dentro de una
computadora de cualquier tamao y arquitectura, documentos que comprenden
formularios virtuales e impresos y datos que combinan nmeros y texto y tambin
incluyen representaciones de informacin de audio, vdeo e imgenes.
Caractersticas del software.
El software es un elemento del sistema que es lgico, en lugar de fsico. Por tanto
el software tiene unas caractersticas considerablemente distintas a las del
hardware:
1. El software se desarrolla,
Aunque existen similitudes entre el desarrollo del software y la construccin del
hardware, ambas actividades son fundamentalmente diferentes. En ambas
actividades la buena calidad se adquiere mediante un buen diseo, pero la fase de
construccin del hardware puede introducir problemas de calidad que no existen
(o son fcilmente corregibles) en el software.
Ambas actividades dependen de las personas, pero la relacin entre las personas
dedicadas y el trabajo realizado es completamente diferente para el software.
Ambas actividades requieren la construccin de un producto pero los enfoques
son diferentes no se fabrica en un sentido clsico.
Los costes del software se encuentran en la ingeniera. Esto significa que los
proyectos de software no se pueden gestionar como si fueran proyectos de
fabricacin.
2. El software no se estropea.

La Figura 1.1 describe, para el hardware, la proporcin de fallos como una

funcin del tiempo. Esa relacin, denominada frecuentemente curva de baera,
indica que el hardware exhibe relativamente muchos fallos al principio de su vida
(estos fallos son atribuibles normalmente a defectos del diseo o de la
fabricacin); una vez corregidos los defectos, la tasa de fallos cae hasta un nivel
estacionario (bastante bajo, con un poco de optimismo) donde permanece durante
un cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, el hardware
empieza a desgastarse y la tasa de fallos se incrementa.
El software no es susceptible a los males del entorno que hacen que el hardware
se estropee. Por tanto, en teora, la curva de fallos para el software tendra la
forma que muestra la Figura 1.2. Los defectos no detectados harn que falle el
programa durante las primeras etapas de su vida. Sin embargo, una vez que se
corrigen (suponiendo que no se introducen nuevos errores) la curva se aplana,
como se muestra. La curva idealizada es una gran simplificacin de los modelos
reales de fallos del software. Sin embargo la implicacin es clara, el software no se
estropea. Pero se deteriora!

3. Aunque la industria tiende a ensamblar componentes, la mayora del

software se construye a medida.
Consideremos la forma en la que se disea y se construye el hardware de control
para un producto basado en computadora. El ingeniero de diseo construye un
sencillo esquema de la circuitera digital, hace algn anlisis fundamental para
asegurar que se consigue la funcin adecuada y va al armario donde se
encuentran los catlogos de componentes digitales.
Despus de seleccionar cada componente, puede solicitarse la compra.

A medida que la disciplina del software evoluciona, se crea un grupo de

componentes de diseo estndar. Tornillos estndar y circuitos integrados
preparados para la venta son solamente los dos mil componentes estndar que
utilizan ingenieros mecnicos y elctricos cuando disean nuevos sistemas. Los
componentes reutilizables se han creado para que el ingeniero pueda
concentrarse en elementos verdaderamente innovadores de un diseo, por
ejemplo, las partes del diseo que representan algo nuevo. En el mundo del
hardware, la reutilizacin de componentes es una parte natural del proceso de
ingeniera. En el mundo del software es algo que slo ha comenzado a lograrse en
una escala amplia. El componente de software debera disearse e implementarse
para que pueda volver a ser reutilizado en muchos programas diferentes. En los
aos 60, se construyeron bibliotecas de subrutinas cientficas reutilizables en una
amplia serie de aplicaciones cientficas y de ingeniera. Esas bibliotecas de
subrutinas reutilizaban de forma efectiva algoritmos bien definidos, pero tenan un
dominio de aplicacin limita do. Hoy en da, hemos extendido nuestra visin de
reutilizacin para abarcar no slo los algoritmos, sino tambin estructuras de
datos. Los componentes reutilizables modernos encapsulan tanto datos como
procesos que se aplican a los datos, permitiendo al ingeniero del software crear
nuevas aplicaciones a partir de las partes reutilizables. Por ejemplo, las interfaces
grficas de usuario de hoy en da se construyen frecuentemente a partir de
componentes reutilizables que permiten la creacin de ventanas grficas, de
mens desplegables y de una amplia variedad de mecanismos de interaccin.

Aplicaciones de software.

El software puede aplicarse en cualquier situacin en la que se haya definido

previamente un conjunto especfico de pasos procedimentales (es decir, un
algoritmo) (excepciones notables a esta regla son el software de los sistemas
expertos y de redes neuronales). El contenido y el determinismo de la
informacin son factores importantes a considerar para determinar la naturaleza
de una aplicacin de software. El contenido se refiere al significado y a la forma
de la informacin de entrada y salida. Por ejemplo, muchas aplicaciones
bancarias usan unos datos de entrada muy estructurados (una base de datos) y
producen informes con determinados formatos. El software que controla una
mquina automtica (por ejemplo: un control numrico) acepta elementos de datos
discretos con una estructura limitada y produce rdenes concretas para la
mquina en rpida sucesin.
El determinismo de la informacin se refiere a la predictibilidad del orden y del
tiempo de llegada de los datos. Un programa de anlisis de ingeniera acepta
datos que estn en un orden predefinido, ejecuta el algoritmo(s) de anlisis sin
interrupcin y produce los datos resultantes en un informe o formato grfico.

Se dice que tales aplicaciones son determinadas. Un sistema operativo

multiusuario, por otra parte, acepta entradas que tienen un contenido variado y
que se producen en instantes arbitrarios, ejecuta algoritmos que pueden ser
interrumpidos por condiciones externas y produce una salida que depende de una
funcin del entorno y del tiempo. Las aplicaciones con estas caractersticas se
dice que son indeterminadas.
Algunas veces es difcil establecer categoras genricas para las aplicaciones del
software que sean significativas. Conforme aumenta la complejidad del software,
es ms difcil establecer compartimentos ntidamente separados. Las siguientes
reas del software indican la amplitud de las aplicaciones potenciales:
Software de sistemas. El software de sistemas es un conjunto de programas
que han sido escritos para servir a otros programas. Algunos programas de
sistemas (por ejemplo: compiladores, editores y utilidades de gestin de
archivos) procesan estructuras de informacin complejas pero determinadas.
Otras aplicaciones de sistemas (por ejemplo: ciertos componentes del sistema
operativo,
utilidades
de
manejo
de
perifricos,
procesadores
de
telecomunicaciones) procesan datos en gran medida indeterminados. En cualquier
caso, el rea del software de sistemas se caracteriza por una fuerte interaccin
con el hardware de la computadora; una gran utilizacin por mltiples usuarios;
una operacin concurrente que requiere una planificacin, una comparticin de
recursos y una sofisticada gestin de procesos; unas estructuras de datos
complejas y mltiples interfaces externas.
Software de tiempo real. El software que coordina/analiza/controla sucesos del
mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos
del software de tiempo real se incluyen: un componente de adquisicin de datos
que recolecta y da formato a la informacin recibida del entorno externo, un
componente de anlisis que transforma la informacin segn lo requiera la
aplicacin, un componente de control/salida que responda al entorno externo, y
un componente de monitorizacin que coordina todos los dems componentes, de
forma que pueda mantenerse la repuesta en tiempo real (tpicamente en el rango
de un milisegundo a un segundo).
Software de gestin. El proceso de la informacin comercial constituye la mayor
de las reas de aplicacin del software. Los sistemas discretos (por ejemplo:
nminas, cuentas de haberes-dbitos, inventarios, etc.) han evolucionado hacia el
software de sistemas de informacin de gestin (SIG) que accede a una o ms
bases de datos que contienen informacin comercial. Las aplicaciones en esta
rea reestructuran los datos existentes para facilitar las operaciones comerciales
o gestionar la toma de decisiones. Adems de las tareas convencionales de
procesamientos de datos, las aplicaciones de software de gestin tambin realizan
clculo interactivo (por ejemplo: el procesamiento de transacciones en puntos de
ventas).

Software de ingeniera y cientfico. El software de ingeniera y cientfico est

caracterizado por los algoritmos de manejo de nmeros. Las aplicaciones van
desde la astronoma a la vulcanologa, desde el anlisis de la presin de los
automotores a la dinmica orbital de las lanzaderas espaciales y desde la
biologa molecular a la fabricacin automtica. Sin embargo, las nuevas
aplicaciones del rea de ingeniera/ciencia se han alejado de los algoritmos
convencionales numricos. El diseo asistido por computadora (del ingls CAD),
la simulacin de sistemas y otras aplicaciones interactivas, han comenzado a
coger caractersticas del software de tiempo real e incluso del software de
sistemas.
Software empotrado. Los productos inteligentes se han convertido en algo
comn en casi todos los mercados de consumo e industriales. El software
empotrado reside en memoria de slo lectura y se utiliza para controlar productos
y sistemas de los mercados industriales y de consumo. El software empotrado
puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las
teclas de un horno de microondas) o suministrar una funcin significativa y con
capacidad de control (por ejemplo: funciones digitales en un automvil, tales como
control de la gasolina, indicadores en el salpicadero, sistemas de frenado, etc.).
Software de computadoras personales.
El mercado del software de
computadoras personales ha germinado en las pasadas dos dcadas. El
procesamiento de textos, las hojas de clculo, los grficos por computadora,
multimedia, entretenimientos, gestin de bases de datos, aplicaciones financieras,
de negocios y personales y redes o acceso a bases de datos externas son
algunas de los cientos de aplicaciones.
Software basado en Web. Las pginas Web buscadas por un explorador son
software que incorpora instrucciones ejecutables (por ejemplo, CGI, HTML, Perl, o
Java), y datos (por ejemplo, hipertexto y una variedad de formatos de audio y
visuales). En esencia, la red viene a ser una gran computadora que proporciona
un recurso software casi ilimitado que puede ser accedido por cualquiera con un
modem.
Software de inteligencia artificial. El software de inteligencia artificial (IA) hace
uso de algoritmos no numricos para resolver problemas complejos para los que
no son adecuados el clculo o el anlisis directo. Los sistemas expertos,
tambin llamados sistemas basados en el conocimiento, reconocimiento de
patrones (imgenes y voz), redes neuronales artificiales, prueba de teoremas, y
los juegos son representativos de las aplicaciones de esta categora.

10

Crisis del software

La palabra crisis se define en el diccionario Webster como un punto decisivo en

el curso de algo, momento, etapa o evento decisivo o crucial. Sin embargo, en
trminos de calidad del software total y de velocidad con la cual son
desarrollados los productos y los sistemas basados en computadoras, no ha
habido ningn punto crucial, ningn momento decisivo, solamente un lento
cambio evolutivo, puntualizado por cambios tecnolgicos explosivos en las
disciplinas relacionadas con el software.
Cualquiera que busque la palabra crisis en el diccionario encontrar otra
definicin: el punto decisivo en el curso de una enfermedad, cuando se ve ms
claro si el paciente vivir o morir. Esta definicin puede darnos una pista sobre
la verdadera naturaleza de los problemas que han acosado el desarrollo del
software.
Lo que realmente tenemos es una afliccin crnica. La palabra afliccin se define
como algo que causa pena o desastre. Pero la clave de nuestro argumento es
la definicin del adjetivo crnica: muy duradero o que reaparece con frecuencia
continuando indefinidamente. Es bastante ms preciso describir los problemas
que hemos estado aguantando en el negocio del software como una afliccin
crnica, en vez de como una crisis.
Sin tener en cuenta como lo llamemos, el conjunto de problemas encontrados en
el desarrollo del software de computadoras no se limitan al software que no
funciona correctamente. Es ms, el mal abarca los problemas asociados a cmo
desarrollar software, cmo mantener el volumen cada vez mayor de software
existente y cmo poder esperar mantenemos al corriente de la demanda
creciente de software.
Vivimos con esta afliccin desde este da - de hecho, la industria prospera a pesar
de ello -. Y as, las cosas podrn ser mejores si podemos encontrar y aplicar
un remedio

Bibliografa 1:
Libro: Ingeniera del software. Un enfoque prctico
Autor: Roger S. Pressman.
Editorial: McGraw Hill
Captulo: 1.EL producto y el proceso
Pginas: 3-8

11

1.1 CONCEPTOS BSICOS

Definicin de software.
El software de computadora es el producto que disean y construyen los
ingenieros de software. Esto abarca programas que se ejecutan dentro de una
computadora de cualquier tamao y arquitectura, documentos que comprenden
formularios virtuales e impresos y datos que combinan nmeros y texto y tambin
incluyen representaciones de informacin de audio, video e imgenes.

Caractersticas del software.

Mantenimiento. El software debe escribirse de tal forma que pueda evolucionar
para satisfacer las necesidades cambiantes de los clientes. ste es un atributo
crtico porque el cambio del software es un requerimiento inevitable de un entorno
empresarial variable.
Confiabilidad y seguridad. La confiabilidad del software incluye un rango de
caractersticas que abarcan fiabilidad, seguridad y proteccin. El software
confiable no tiene que causar dao fsico ni econmico, en caso de falla del
sistema. Los usuarios malintencionados no deben tener posibilidad de acceder al
sistema o daarlo.
Eficiencia. El software no tiene que desperdiciar los recursos del sistema, como la
memoria y los ciclos del procesador. Por lo tanto, la eficiencia incluye capacidad
de respuesta, tiempo de procesamiento, utilizacin de memoria, etctera.
Aceptabilidad. El software debe ser aceptable al tipo de usuarios para quienes se
disea. Esto significa que necesita ser comprensible, utilizable y compatible con
otros sistemas que ellos usan.

12

Aplicaciones del software

Existen muchos diferentes tipos de aplicacin, incluidos los siguientes:

1. Aplicaciones independientes. Se trata de sistemas de aplicacin que corren
en una computadora local, como una PC, e incluyen toda la funcionalidad
necesaria y no requieren conectarse a una red. Ejemplos de tales aplicaciones son
las de oficina en una PC, programas CAD, software de manipulacin de
fotografas, etctera.
2.
Aplicaciones interactivas basadas en transaccin. Consisten en
aplicaciones que se ejecutan en una computadora remota y a las que los usuarios
acceden desde sus propias PC o terminales. Evidentemente, en ellas se incluyen
aplicaciones Web como las de comercio electrnico, donde es posible interactuar
con un sistema remoto para comprar bienes y servicios. Esta clase de aplicacin
tambin incluye sistemas empresariales, donde una organizacin brinda acceso a
sus sistemas a travs de un navegador Web o un programa de cliente de
propsito especfico y servicios basados en nube, como correo electrnico y
comparticin de fotografas. Las aplicaciones interactivas incorporan con
frecuencia un gran almacn de datos al que se accede y actualiza en cada
transaccin.
3. Sistemas de control embebido. Se trata de sistemas de control de software
que regulan y gestionan dispositivos de hardware. Numricamente, quizs existen
ms sistemas embebidos que cualquier otro tipo de sistema. Algunos ejemplos de
sistemas embebidos incluyen el software en un telfono mvil (celular), el software
que controla los frenos antibloqueo de un automvil y el software en un horno de
microondas para controlar el proceso de cocinado.
4. Sistemas de procesamiento en lotes. Son sistemas empresariales que
disean para procesar datos en grandes lotes (batch). Procesan gran cantidad
entradas individuales para crear salidas correspondientes. Los ejemplos
sistemas batch incluyen sistemas de facturacin peridica, como los sistemas
facturacin telefnica y los sistemas de pago de salario.

se
de
de
de

5. Sistemas de entretenimiento. Son sistemas para uso sobre todo personal,

que tienen la intencin de entretener al usuario. La mayora de estos sistemas son
juegos de uno u otro tipo. La calidad de interaccin ofrecida al usuario es la
caracterstica ms importante de los sistemas de entretenimiento.
6. Sistemas para modelado y simulacin. stos son sistemas que desarrollan
cientficos e ingenieros para modelar procesos o situaciones fsicas, que incluyen
muchos objetos separados interactuantes. Dichos sistemas a menudo son
computacionalmente intensivos y para su ejecucin requieren sistemas paralelos
de alto desempeo.

13

7. Sistemas de adquisicin de datos. Son sistemas que desde su entorno

recopilan datos usando un conjunto de sensores, y envan dichos datos para su
procesamiento a otros sistemas. El software tiene que interactuar con los sensores
y se instala regularmente en un ambiente hostil, como en el interior de un motor o
en una ubicacin remota.
8. Sistemas de sistemas. Son sistemas compuestos de un cierto nmero de
sistemas de software. Algunos de ellos son producto del software genrico, como
un programa de hoja de clculo. Otros sistemas en el ensamble pueden estar
especialmente escritos para ese entorno.

Crisis del software.

El concepto ingeniera del software se propuso originalmente en 1968, en una

conferencia realizada para discutir lo que entonces se llamaba la crisis del
software (Naur y Randell, 1969). Se volvi claro que los enfoques individuales al
desarrollo de programas no escalaban hacia los grandes y complejos sistemas de
software. stos no eran confiables, costaban ms de lo esperado y se distribuan
con demora.
A lo largo de las dcadas de 1970 y 1980 se desarroll una variedad de nuevas
tcnicas y mtodos de ingeniera de software, tales como la programacin
estructurada, el encubrimiento de informacin y el desarrollo orientado a objetos.
Se perfeccionaron herramientas y notaciones estndar y ahora se usan de manera
extensa.

Bibliografa 2:
Libro: Ingeniera del software.
Autor: Ian Sommerville.
Editorial: Pearson
Captulo: 1.Introduccin
Pginas: 5-8,10-11.

14

1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE

Hoy en da, el software tiene un papel dual. Es producto y canal de distribucin de

este. Como producto, ofrece la potencia de cmputo presentada como hardware
de una computadora o, de manera ms global por una red de computadoras
accesible mediante hardware local y de acceso fsico. Sin importar el lugar en que
resida el software, ya sea en un celular o dentro de una computadora central, ste
es un transformador de informacin; realiza la produccin, el manejo, la
adquisicin, la modificacin, el despliegue o la transmisin de la informacin que
puede ser tan simple como un solo bit o tan compleja como una presentacin
multimedia. En su papel de vehculo para la entrega de un producto, el software
acta como la base para el control de la computadora (Sistemas Operativos), la
comunicacin de informacin (redes), y la relacin y el control de otros programas
(utileras de software y ambientes).
El software entrega el producto ms importante de nuestro tiempo: informacin.
Transforma los datos personales (por ejemplo, las transacciones financieras de un
individuo) de forma que los datos sean ms tiles en un contexto local; maneja
informacin alrededor del mundo (Internet) y proporciona los medios para adquirir
informacin en todas sus formas.
El papel del software de computadora ha experimentado un cambio significativo en
un periodo un poco mayor a 50 aos. Las mejoras sustanciales en el desempeo
del hardware, los cambios profundos en las arquitecturas de cmputo, los
enormes incrementos en las capacidades de memoria y almacenamiento, y la
amplia variedad de opciones de salida y entrada han propiciado el surgimiento de
sistemas ms elaborados y complejos basados en computadoras.
En la actualidad una enorme industria del software se ha convertido en un factor
dominante en la economa del mundo industrializado. El programador solitario de
la era inicial ha sido sustituido por equipos de especialistas en software, en los que
cada uno se enfoca en una parte de la tecnologa requerida para desarrollar una
ampliacin compleja. Hasta ahora, las preguntas formuladas al programador
solitario son las mismas que se hacen cuando se construyen los sistemas basados
en computadoras modernas.

Primera era (1950 / 1965)

Se trabajaba con la idea de Codificar y Corregir.

No exista un planteamiento previo.
No exista documentacin de ningn tipo.
Existencia de pocos mtodos formales y pocos creyentes en ellos.
Desarrollado a base de prueba y error.

15

Segunda era (1965 1972)

Se busca simplificar cdigo.

Aparicin de Multiprogramacin y Sistemas Multiusuarios.
Sistemas de Tiempo Real apoyan la toma de decisiones. Aparicin de
Software como producto. (Casas de Software).
Se buscan procedimientos para el desarrollo del Software.

Tercera era (1972 1985)

Nuevo Concepto: Sistemas Distribuidos.

Complejidad en los Sistemas de Informacin.
Aparecen: Redes de rea local y global, y Comunicadores Digitales.
Uso de Microprocesadores.

Cuarta era (1985 - 1995)

Impacto Colectivo de Software.

Aparecen: Las Redes de Informacin, Tecnologas Orientadas a Objetos.
Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia
Artificial.
La informacin como valor preponderante dentro de las Organizaciones.

Quinta era (2000 hasta hoy en da)

Utiliza algunos requisitos de las eras anteriores solo que aumenta la

omnipresencia de la web, la reutilizacin de informacin y componentes de
software
Codificar: Transformar mediante las reglas de un cdigo la formulacin de
un mensaje.

Hardware: Componente fsico de la computadora. Por ejemplo: el monitor,

la impresora o el disco rgido. El hardware por s mismo no hace que una
mquina funcione.

Multiprogramacin: Se denomina multiprogramacin a la tcnica que

permite que dos o ms procesos ocupen la misma unidad de memoria
principal y que sean ejecutados al "mismo tiempo.

16

17

Bibliografa 1
Libro: Uml y patrones.
Autor: Craig Larman.
Editorial: Pearson
Captulo: 1
Pgina: 9

18

1.2.- EL PAPEL EVOLUTIVO DEL SOFTWARE.

El desarrollo del software no se detiene cuando un sistema se entrega, si no que
contina a lo largo de la vida de este. Despus de distribuir un sistema,
inevitablemente debe modificarse, con la finalidad de mantenerlo til. Tanto los
cambios empresariales como los de las expectativas del usuario generan nuevos
requerimientos para el software existente. Es posible que tengan que modificarse
partes del software para corregir errores encontrados durante su operacin, para
adaptarlo a los cambios en su plataforma de software y hardware, y mejorar su
rendimiento u otras caractersticas no funcionales.
La evolucin del software es importante porque las organizaciones invierten
grandes cantidades de dinero en l y en la actualidad son completamente
dependientes de dichos sistemas. Sus sistemas se consideran activos
empresariales crticos, por lo que tienen que invertir en el cambio del sistema para
mantener el valor de estos activos. En consecuencia, las compaas ms grandes
gastan ms en conservar en conservar los sistemas existentes que en el
desarrollo de sistemas nuevos. Con base en una encuesta industrial informal,
Erlikh (2000) sugiere que entre el 85 y 90% de los costos del software
organizacional son costos de evolucin; mientras que otros estudios sugieren que
estos conforman alrededor de dos tercios de los costos del software. Desde luego,
los costos del cambio del software representan una gran parte del presupuesto de
TI de todas las compaas.
La evolucin del software puede potenciarse al cambiar los requerimientos
empresariales, con reportes de defectos del software o por cambios a otros
sistemas en un entorno del sistema de software. Hopkins y Jenkins (2008)
acuaron el trmino desarrollo de software abandonado para describir
situaciones en que los software tienen que desarrollarse y gestionarse en un
ambiente donde dependen de muchos otros sistemas de software.
Por consiguiente, la evolucin de un sistema rara vez puede considerarse en
aislamiento. Los cambios al entorno conducen a cambios en el sistema que, a la
vez, pueden generar ms cambios en el entorno. Desde luego, el hecho de que
los sistemas tengan que evolucionar en un ambiente rico en sistemas con
frecuencia aumenta las dificultades y los costos de la evolucin. Adems de
comprender y analizar el impacto de un cambio propuesto por el sistema en s,
tambin es probable que se deba valorar como esto afectara a otros sistemas en
el entorno operacional.
Por lo general, los sistemas de software tiles tienen una vida muy larga. Por
ejemplo, los grandes sistemas militares o de infraestructura, como los de control
de trfico areo, llegan a durar 30 aos o ms; en tanto que los sistemas
empresariales con frecuencia superan los 10 aos. Puesto que el costo del
software es elevado, una compaa debe usar un sistema de software durante
muchos aos para recuperar su inversin. Evidentemente, los requerimientos de

19

los sistemas instalados cambian conforme lo hace el negocio y su entorno. Por

consiguiente, se crean a intervalos regulares nuevas versiones de los sistemas,
las cuales incorporan cambios y actualizaciones.
Por ende, la ingeniera de software se debe considerar como un proceso en
espiral, con requerimientos, diseo, implementacin y pruebas continuas, a lo
largo de la vida del sistema. Esto comienza por crear la versin 1 del sistema. Una
vez entregada, se proponen cambios y casi de inmediato comienza el desarrollo
de la versin 2. De hecho, la necesidad de evolucin puede volverse evidente
incluso antes de que el sistema se distribuya, de manera que las futuras versiones
del software estaran en desarrollo antes de que se libere la versin actual.
Este modelo de evolucin del software implica que una sola organizacin es
responsable tanto del desarrollo del software inicial como de la evolucin del
software. La mayora de los productos de software empacados se desarrollan
siguiendo este enfoque. Para el software personalizado, por lo general se utiliza
un enfoque diferente. Una compaa de software lo desarrolla para un cliente y
luego, el personal de desarrollo del propio cliente se hace cargo del sistema. Ellos
son los responsables de la evolucin del software. De forma alternativa, el cliente
del software puede otorgar por separado un contrato a una compaa diferente,
con la finalidad de que de soporte al sistema y continuar su evolucin.

En este caso, es probable que existan discontinuidades en el proceso espiral. Los

documentos de requerimientos y diseo quiz no se compartan entre una
compaa y otra. Estas podran fusionarse o reorganizarse y heredar el software
de otras compaas, para luego descubrir que este ltimo tiene que cambiarse.
Cuando la transicin del desarrollo a la evolucin no es uniforme, el proceso de
cambiar el software despus de la entrega se conoce como mantenimiento de
software.

20

Durante los primeros aos de la era de la computadora, el software se

contemplaba como un aadido. La programacin de computadoras era un "arte de
andar por casa" para el que existan pocos mtodos sistemticos. El desarrollo del
software se realizaba virtualmente sin ninguna planificacin, hasta que los planes
comenzaron a descalabrarse y los costes a correr. Los programadores trataban de
hacer las cosas bien, y con un esfuerzo heroico, a menudo salan con xito. El
software se diseaba a medida para cada aplicacin y tena una distribucin
relativamente pequea.
La mayora del software se desarrollaba y era utilizado por la misma persona u
organizacin. La misma persona lo escriba, lo ejecutaba y, si fallaba, lo depuraba.
Debido a este entorno personalizado del software, el diseo era un proceso
implcito, realizado en la mente de alguien y, la documentacin normalmente no
exista.
La segunda era en la evolucin de los sistemas de computadora se extienden
desde la mitad de la dcada de los sesenta hasta finales de los setenta. La
multiprogramacin y los sistemas multiusuario introdujeron nuevos conceptos de
interaccin hombre - mquina. Las tcnicas interactivas abrieron un nuevo mundo
de aplicaciones y nuevos niveles de sofisticacin del hardware y del software. Los
sistemas de tiempo real podan recoger, analizar y transformar datos de mltiples
fuentes, controlando as los procesos y produciendo salidas en milisegundos en
lugar de minutos. Los avances en los dispositivos de almacenamiento en lnea
condujeron a la primera generacin de sistemas de gestin de bases de datos.
La segunda era se caracteriz tambin por el establecimiento del software como
producto y la llegada de las "casas del software". Los patronos de la industria, del
gobierno y de la universidad se aprestaban a "desarrollar el mejor paquete de
software" y ganar as mucho dinero.
Conforme creca el nmero de sistemas informticos, comenzaron a extenderse
las bibliotecas de software de computadora. Las casas desarrollaban proyectos en
los que se producan programas de decenas de miles de sentencia fuente. Todos
esos programas, todas esas sentencias fuente tenan que ser corregidos cuando
se detectaban fallos, modificados cuando cambiaban los requisitos de los usuarios
o adaptados a nuevos dispositivos hardware que se hubieran adquirido. Estas
actividades se llamaron colectivamente mantenimiento del software.
La tercera era en la evolucin de los sistemas de computadora comenz a
mediados de los aos setenta y contino ms all de una dcada. El sistema
distribuido, mltiples computadoras, cada una ejecutando funciones concurrentes
y comunicndose con alguna otra, increment notablemente la complejidad de los
sistemas informticos. Las redes de rea local y de rea global, las
comunicaciones digitales de alto ancho de banda y la creciente demanda de
acceso "instantneo" a los datos, supusieron una fuerte presin sobre los
desarrolladores del software.

21

La conclusin de la tercera era se caracteriz por la llegada y amplio uso de los

microprocesadores. El microprocesador ha producido un extenso grupo de
productos inteligentes, desde automviles hasta hornos microondas, desde robots
industriales a equipos de diagnsticos de suero sanguneo.
La cuarta era de la evolucin de los sistemas informticos se aleja de
las computadoras individuales y de los programas de computadoras, dirigindose
al impacto colectivo de las computadoras y del software. Potentes maquinas
personales controladas por sistemas operativos sofisticados, en redes globales y
locales, acompaadas por aplicaciones de software avanzadas se han convertido
en la norma.
La industria del software ya es la cuna de la economa del mundo. Las tcnicas de
la cuarta generacin para el desarrollo del software estn cambiando en la forma
en que la comunidad del software construye programas informticos. Las
tecnologas orientadas a objetos estn desplazando rpidamente los enfoques de
desarrollo de software ms convencionales en muchas reas de aplicaciones.

Sin embargo, un conjunto de problemas relacionados con el software ha persistido

a travs de la evolucin de los sistemas basados en computadora, y estos
problemas continan aumentando.

Los avances del software continan dejando atrs nuestra habilidad de

construir software para alcanzar el potencial del hardware.
Nuestra habilidad de construir nuevos programas no pueden ir al mismo
ritmo de la demanda de nuevos programas, ni podemos construir
programas lo suficientemente rpido como para cumplir las necesidades del
mercado y de los negocios.

22

El uso extenso de computadoras ha hecho de la sociedad cada vez ms

dependiente de la operacin fiable del software. Cuando el software falla,
pueden ocurrir daos econmicos enormes y ocasionar sufrimiento
humano.
Luchamos por construir software informtico que tengan fiabilidad y alta
calidad.
Nuestra habilidad de soportar y mejorar los programas existentes se ve
amenazada por diseos pobres y recursos inadecuados.

En respuesta a estos problemas, las prcticas de la Ingeniera del Software se

estn adoptando en toda la industria.
Los procesos de evolucin del software varan dependiendo del tipo de software
que se mantiene, de los procesos de desarrollo usados en la organizacin y de las
habilidades de las personas que intervienen. En algunas organizaciones, la
evolucin es un proceso informal, donde las solicitudes de cambios provienen
sobre todo de conversaciones entre los usuarios del sistema y los desarrolladores.
En otras compaas, se trata de un proceso formalizado con documentacin
estructurada generada en cada etapa del proceso.
Las propuestas de cambio al sistema son el motor para la evolucin del sistema
en todas las organizaciones. Estos cambios provienen de requerimientos
existentes que no se hayan implementado en el sistema liberado, de peticiones de
nuevos requerimientos, de reportes de bugs de los participantes del sistema, y de
nuevas ideas para la mejora del software por parte del equipo del desarrollo del
sistema. Los procesos de identificacin de cambios y evolucin del sistema son
cclicos y continan a lo largo de la vida de un sistema

Bibliografa 2:
Libro: Ingeniera de Software.
Autor: Ian Sommerville.
Editorial: Pearson
Captulo: 9.Evolucin del software.
Pgina: 235.

23

1.3 ETAPAS DE DESARROLLO DE SOFTWARE

Cuando se trabaja en equipo para construir un producto o sistema es importante
seguir una serie de pasos predecibles: una especie de mapas de carretera que
ayude a crear un resultado de alta calidad y a tiempo.
El mapa de carretera que se debe seguir se llama proceso o desarrollo de
software. Los ingenieros de software y sus jefes adoptan el proceso a sus
necesidades y despus lo siguen. Adems, la gente que ha solicitado el software
tiene una funcin que desempear en el proceso de definirlo, construirlo y
probarlo. Esto es importante porque ofrece estabilidad, control y organizacin a
una actividad que puede volverse catica si no se control. Sin embargo, un
enfoque de ingeniera de software moderno debe ser gil. Debe requerir solo
aquellas actividades, controles y documentaciones apropiados para el equipo del
proyecto y el producto que ha de producirse.
En detalle, el proceso que se adopte depende del software que se est
construyendo. Un marco de trabajo establece la base para un proceso de software
completo al identificar un nmero pequeo de actividades del marco de trabajo
aplicables a todos los proyectos de software, sin importar su tamao o
complejidad.
Adems, el marco de trabajo del proceso abarca un conjunto de actividades
sombrillas aplicables a lo largo del proceso de software.
Marco de trabajo del proceso
Actividades sombrilla
Actividades del marco de trabajo #1
Accin de la ingeniera de software # 1.1

Conjunto de tareas

Tareas de trabajo
Productos de trabajo
Puntos de aseguramiento de la
calidad
Fundamentos del proyecto

.
.
.
Accin de la ingeniera de software # 1.k
Conjunto de tareas

Tareas de trabajo
Productos de trabajo
Puntos de aseguramiento de la
calidad
Fundamentos del proyecto

24

El siguiente marco de trabajo genrico del proceso se puede aplicar en la inmensa

mayora de los proyectos de software:
Comunicacin. Esta actividad del marco de trabajo implica una intensa
colaboracin y comunicacin con los clientes; adems, abarca la investigacin de
requisitos y otras actividades relacionadas.
Planeacin. Esta actividad establece un plan para el trabajo de la ingeniera del
software. Describe las tareas tcnicas que deben realizarse, los riesgos probables,
los recursos que sern requeridos, los productos del trabajo que han de producirse
y un programa de trabajo.
Modelado. Esta actividad abarca la creacin de modelos que permiten al
desarrollador y al cliente entender mejor los requisitos dl software y el diseo que
lograra satisfacerlos.
Construccin. Esta actividad combina la generacin del cdigo (ya sea manual o
automatizado) y la realizacin de pruebas necesarias para descubrir errores en el
cdigo.
Despliegue. El software (como una entidad completa o un incremento completado
de manera parcial) se entrega al cliente, quien evala el producto recibido y
proporciona informacin basada en su evaluacin.
Estas cinco actividades genricas del marco de trabajo son tiles durante el
desarrollo de programas pequeos, la creacin de grandes aplicaciones en la red,
y en la ingeniera de sistemas basados en computadoras grandes y complejas.
Los detalles del proceso de software sern muy diferentes en cada caso, pero las
actividades dentro del marco permanecern iguales.
El marco de trabajo descrito en la visin general de la ingeniera de software lo
completa una serie de actividades de sombrilla. Las actividades tpicas en esta
categora incluyen:
Seguimiento y control del proyecto de software: Permite que el equipo de
software evalu el progreso comparndolo con el plan de proyecto y as tomar las
acciones necesarias para mantener el programa.
Gestin de riesgo: Evala los riesgos que pudieran afectar los resultados del
proyecto o la calidad del producto.
Aseguramiento de la calidad del software: Define y conduce las actividades
requeridas para asegurar la calidad del software.
Revisiones tcnicas formales: Evala los productos del trabajo de la ingeniera
de software en un esfuerzo encaminado a descubrir y eliminar los errores antes de
que estos se propaguen hacia la siguiente accin.

25

Medicin: Define y recolecta mediciones del proceso, el proyecto y el producto

para ayudar al equipo a entregar el software que satisfaga las necesidades del
cliente; se puede usar en conjunto con todas las otras actividades del marco o
actividades de sombrilla.
Gestin de la configuracin del software: Maneja los efectos del cambio a
travs del proceso del software.
Gestin de la reutilizacin: Define los criterios para la reutilizacin de productos
(se incluyen componentes de software) y se establece mecanismos para la
creacin de componentes reutilizables.
Preparacin y produccin del producto de trabajo: Abarca las actividades
requeridas para crear productos del trabajo como modelos, documentos, registros,
formatos y listas.
Bibliografa 1:
Libro: Ingeniera del software. Un enfoque prctico
Autor: Roger S. Pressman
Capitulo: 2 El proceso una visin general 2.2 Marco de trabajo para el proceso
Pginas: 24-26
1.3 ETAPAS DE DESARROLLO DE SOFTWARE
Un proceso de software es un conjunto de actividades que conducen a la creacin
de un producto de software. Estas actividades pueden consistir en el desarrollo de
software desde cero en un lenguaje de programacin estndar como Java o C. Sin
embargo, cada vez ms, se desarrolla nuevo software ampliando y modificando
los sistemas existentes y configurando e integrando software comercial o
componentes de sistema.
Los procesos de software son complejos y, como todos los procesos intelectuales
y creativos, dependen de las personas que toman decisiones y juicios. Debido a la
necesidad de juzgar y crear, los intentos para automatizar estos procesos han
tenido un xito limitado.
Aunque existen muchos procesos diferentes de software, algunas actividades
fundamentales son comunes para todos ellos:

1. Especificacin del software. Se debe definir la funcionalidad del software

y las restricciones en su operacin.
2. Diseo e implementacin del software. Se debe producir software que
cumpla su especificacin.

26

3. Validacin del software. Se debe validar el software para asegurar que

hace lo que el cliente desea.
4. Evolucin del software. El software debe evolucionar para cubrir las
necesidades cambiantes del cliente.

Cada modelo de proceso representa un proceso desde una perspectiva particular,

y as proporciona solo informacin parcial sobre ese proceso.
Estos modelos generales no son descripciones definitivas de los procesos del
software. Ms bien, son abstracciones de los procesos que se pueden utilizar para
explicar diferentes enfoques para el desarrollo de software. Puede pensarse en
ellos como marcos de trabajo del proceso que pueden ser extendidos y adaptados
para crear procesos ms especficos de ingeniera de software.
1. Modelo en cascada. Considera las actividades fundamentales del proceso
de especificacin, validacin y evolucin, y los representa como pases
separadas del proceso, tales como la especificacin de requerimientos, el
diseo del software, la implementacin, las pruebas, etctera
Las principales etapas de
fundamentales del desarrollo:

este

modelo

se

trasforman

en

actividades

1. Anlisis y definicin de requerimientos. Los servicios, restricciones y

metas del sistema se definen a partir de las consultas con los usuarios.
Entonces, se definen en detalle y sirven como una especificacin del
sistema.
2. Diseo del sistema y del software. El proceso de diseo del sistema
divide los requerimientos en sistemas de hardware o software. Establece
una arquitectura completa del sistema. El diseo del software identifica y
describe las abstracciones fundamentales del sistema de software y sus
relaciones.
3. Implementacin y prueba de unidades. Durante esta etapa, el diseo del
software se lleva a cabo como un conjunto o unidades de programa. La
prueba de unidades implica verificar que cada una cumpla su
especificacin.
4. Integracin y prueba del sistema. Los programas o las unidades
individuales de programas se integran y prueban como un sistema completo
para asegurar que se cumplan los requerimientos del software. Despus de
las pruebas, el sistema de software se entrega al cliente.
5. Funcionamiento y mantenimiento. Por lo general, esta es la fase ms
larga del ciclo de vida. El sistema se instala y pone en funcionamiento
prctico. El mantenimiento implica corregir errores no descubiertos en las

27

etapas anteriores del ciclo de vida, mejorar la implementacin de las

unidades del sistema y resaltar los servicios del sistema una vez que se
descubren nuevos requerimientos.
Definicin de
requerimientos
Diseo del sistema y del
software

Implementacin y prueba
de unidades
Integracin y prueba del
sistema
Funcionamiento y
mantenimiento

Bibliografa 2:
Libro: Ingeniera del software.
Autor: Ian Sommerville.
Captulo: 4 Modelos del proceso.
Pginas: 60-62

1.4. CLASIFICACIN DE LA TECNOLOGA EN EL DESARROLLO DE

SOFTWARE (TECNOLOGA ESTRUCTURADA Y ORIENTADA A OBJETOS)
Programacin estructurada
En esta tecnologa tradicional, un programa o aplicacin consta de mltiples datos
y funciones globales.
Datos

Funciones

28

El trmino global describe el hecho que todos los datos o funciones son visibles
en todo el programa, y por lo tanto, pueden ser llamados desde cualquier
ubicacin en la aplicacin.
En forma de programacin estructurada tiene a sus orgenes en las primeras
computadoras modernas basadas en la arquitectura Von Newman, donde las
instrucciones de un programa se guardan en memoria, creado el concepto de
programa, los cuales eran almacenados en otras secciones de la memoria.
Este tipo de programacin tiene dos problemas principales:
a) Obliga a un programador a que organice su programa de acuerdo con la
arquitectura de la computadora, que piense como la maquina
b) Al estar separados por las funciones, los datos se vuelven totalmente
visibles para poder ser llamados
Programacin orientada a objetos
Esta programacin define una estructura de ms alto nivel llamado objeto, que
ofrece dos ventajas:
a) Permite al programador que organice su programa de acuerdo con
abstracciones de ms alto nivel. Los objetos son las unidades de
representacin de las aplicaciones.
b) La segunda es la que los datos globales desaparecen, siendo estos con los
funciones parte interna de los objetos. Por lo tanto, cualquier cambio en
alguna estructura de los datos solo debera afectar las funciones definidas
en ese mismo objeto y no de los dems.
Un programa orientado a objetos se define exclusivamente en trminos de objetos
y sus relaciones.

OBJETO

OBJETO

OBJETO

29

Los datos y funciones se guardan dentro de objetos. Los datos estn ubicados en
el centro del trabajo, lo cual hace que un cambio en su estructura, solo afecte las
funciones del mismo objeto pero no al resto de la aplicacin.

FUNCIONES
DATOS

La idea de esta tecnologa es que es posible estructurar el modelo de un sistema

de software en base o funciones que procesan informes que reciben de otras
funciones y dirigen la informacin procesando en otros mdulos funcionales
necesarios.
Bibliografa 1:
Libro: ingeniera de software: Orientado a objetos con UML Java e Internet.
Autor: Alfredo Weitzer.
Editorial: Thomson.
Capitulo: 2.
Pginas: 21-23.
1.4. CLASIFICACIN DE LA TECNOLOGA EN EL DESARROLLO DE
SOFTWARE (TECNOLOGA ESTRUCTURADA Y ORIENTADA A OBJETOS)
Tecnologas de desarrollo estructurado
Las tecnologas de desarrollo estructurado son las ms convencionales de las
empleadas hoy da. Han surgido de la evolucin de las ideas de programacin
estructurada (hace ms de veinticinco aos) hacia las fases iniciales del ciclo de
vida. En su formulacin actual, las notaciones empleadas en las primeras fases
del ciclo de vida (especificacin de requisitos de usuario y sistema) suelen estar
constituidas por lenguajes grficos que permiten: identificar el sistema y el
entorno; representar el flujo de informacin entre los elementos; y, describir los
datos y las actividades del sistema.
La idea base de esta tecnologa es que es posible estructurar el modelo de un
sistema de software en base a funciones que procesan informacin que reciben de
otras funciones (o del exterior) y dirigen la informacin procesada a otros mdulos
funcionales (o al exterior). El enfoque seguido, por tanto, es el de pensar en las

30

funciones del sistema necesarias (extradas de los requisitos del sistema) y

luego en los datos que requieren.
Para la fase de anlisis y especificacin de requisitos, las herramientas estn
asociadas a la construccin de modelos del sistema (modelos lgicos con
diagramas de estado asociados). Estas herramientas no son genricas sino que
soportan mtodos concretos. Suelen constar de:
A) Editores grfico-textuales de la notacin asociada a un mtodo (tanto para
describir las funciones como para describir el comportamiento mediante diagramas
de estado).
B) Comprobadores de consistencia en la informacin relativa a refinamientos del
modelo (nombres, tipos, uso, etc. de los elementos definidos en los diagramas).
C) Sistema de gestin de la informacin almacenada (en ocasiones basada
en bases de datos relacionales u orientados a objetos para gestionar el acceso a
la informacin).
D) Generadores de prototipos (normalmente de interfaz grfica) con objeto de
evaluar los modelos lgicos o de diseo.
En las fases de diseo del sistema se dispone del mismo tipo de herramientas
aunque en este caso se suele disponer tambin de: analizadores temporales y
estimadores de tiempos de ejecucin, generadores de cdigo (ms o menos
completos) o facilidades para la utilizacin de componentes genricos contenidos
en bibliotecas menos comunes pero cada vez ms conocidas son herramientas
como las de animacin grfica de modelos.
Estas herramientas aparecen como extensin de las que permiten editar y validar
modelos de especificacin y diseo estructurado de sistemas de software.
Finalmente, las herramientas que soportan la fase de implementacin son las ms
conocidas dado que han estado en su mayor parte presentes desde los comienzos
de la programacin: editores (conociendo la sintaxis del lenguaje en algunos
casos), compiladores e intrpretes, generadores/optimizadores de cdigo,
ejecutores de casos de prueba, depuradores simblicos, etc.

31

Tecnologas orientadas a objetos

Las tecnologas de desarrollo estructurado han demostrado sus limitaciones a la
hora de organizar y facilitar la evolucin de sistemas de software complejos. La
descomposicin en funciones hace difcil al diseador mantener la relacin con los
objetos del mundo real sobre los que se modifican generalmente los requisitos del
usuario.
Los mtodos de descomposicin orientada a objetos constituyen la tendencia ms
influyente observada en la ingeniera de sistemas de software en los ltimos aos.
Con ellos nos referimos a un conjunto de mtodos (an en fase de desarrollo o
evolucin) que permiten al analista y diseador concebir su sistema identificando
clases de objetos, operaciones permitidas y relaciones entre ellos como base para
la estructura del sistema a disear. En ellas, un objeto es un conjunto de datos y
funciones de manipulacin de los mismos encapsulados en una unidad que es
posible tratar como un todo (crear, copiar, destruir, etc.). Un objeto posee unas
operaciones visibles a otros objetos aunque stos no conocen cmo estn
implementadas. El diseador reconoce inicialmente clases de objetos de las que
se derivan los objetos concretos que utilizar en el diseo. Un objeto puede
construirse jerrquicamente empleando, a su vez, a otros objetos ms simples.
Una clase implica una generalizacin del concepto de objeto (identificando
similitudes entre objetos similares) y constituye la base a partir de las cuales se
construye el sistema. Existen varias tecnologas orientadas a objetos que, aunque
similares en su potencia expresiva, ofrecen algunas diferencias que las hacen ms
adecuadas para algn tipo concreto de sistemas. Podemos mencionar como una
de las ms representativas a OMT.
OMT est soportada por muchas herramientas CASE comerciales. Corresponde a
una notacin grfica que permite representarlas clases de objetos, sus relaciones
y la creacin de ejemplares delos mismos. Aunque bsicamente empleada para la
fase de anlisis de requisitos del sistema puede tambin emplearse para las
primeras fases del diseo. La descripcin del comportamiento se realiza
generalmente asociando a los objetos diagramas de transicin de estados
similares a los empleados en las tecnologas de software estructuradas (con los
mismos problemas de la explosin de estados).
Los mtodos de diseo orientados a objetos suelen facilitar el desarrollo de una
implementacin en un lenguaje de programacin orientado a objetos (C++, Ada95
o Eiffel). No obstante, la eleccin del lenguaje de implementacin no es realmente
importante y esta eleccin est condicionada por muchas otras razones. Justo es
reconocer, sin embargo, que ha sido la Programacin Orientada a Objetos la que
ha impulsado tambin la difusin de estas tcnicas. Las herramientas que
acompaan a las tecnologas orientadas a objetos y disponibles en sistemas
CASE comerciales no se diferencian en esencia de las que aparecen en las
tecnologas estructuradas. El nico aspecto destacable es la proliferacin de
catlogos de clases para aplicaciones determinadas y los mecanismos de
recuperacin y personalizacin asociados

32

Bibliografa 2:
Libro: Ingeniera de sistemas de Software.
Autor: Gonzalo Len Serrano.
Editorial: Isdefe
Captulo: Capitulo 3 Tecnologas de Software
Pginas:

101-106

1.5 DEFINICIN E HISTORIA DE LAS HERRAMIENTAS CASE

Herramientas CASE
Estas herramientas 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. Ya en los aos 70 un proyecto llamado ISDOS dise un
lenguaje y por lo tanto un producto que analizaba 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).
Historia
Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un
producto que analizaba la relacin existente entre los requisitos de un problema y
las necesidades que stos generaban, Aunque sos son los inicios de las
herramientas informticas que ayudan a crear nuevos proyectos informticos, la
primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y
trabajaba bajo una plataforma PC. Las herramientas CASE alcanzaron su techo a

33

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.

Linkografa 1:
Publicado por: Isabel Garca Mndez
Sitio web: http://ithuejutlaisabelgarciamendez.blogspot.mx/2013/02/1_9013.html

1.5 DEFINICIN E HISTORIA DE LAS HERRAMIENTAS CASE

CASE (Ingeniera del Software Asistida por computadora) comprende un amplio
abanico de diferentes tipos de programas que se utilizan para ayudar a las
actividades del proceso del software, como el anlisis de requerimientos, el
modelado de sistemas, la depuracin y las pruebas. En la actualidad, todos los
mtodos vienen con tecnologa CASE asociada, como los editores para las
notaciones utilizadas en el mtodo, mdulos de anlisis que verifican el modelo
del sistema segn las reglas del mtodo y generadores de informes que ayudan a
crear la documentacin del sistema. Las herramientas CASE tambin incluyen un
generador de cdigo que automticamente genera cdigo fuente a partir del
modelo del sistema y de algunas guas de procesos para los ingenieros de
software.
La tecnologa CASE est disponible para la mayora de las actividades rutinarias
en el proceso del software. Esto permite algunas mejoras en la calidad y
productividad del software, aunque estas sean menores que las predichas por los
primeros partidarios de CASE. Estos sugirieron que se tendra una mejora mayor
si se utilizaran entornos CASE integrados. En realidad, las mejoras reales son del
40% (Huff, 1992). Aunque esto es significante, las predicciones que se hicieron
cuando se introdujeron las herramientas CASE en los aos 80 y 90 fueron que el
uso de la tecnologa CASE generara enormes ahorros en los costos del proceso
del software.
Las mejoras por la utilizacin de CASE estn limitadas por dos factores:
1. Esencialmente, la ingeniera de software es una actividad de diseo que se
basa en la creatividad. Los sistemas CASE automatizan las actividades

34

rutinarias, pero pos intentos de utilizar la inteligencia artificial para

proporcionar ayuda al diseo no han tenido xito.
2. En la mayora de las organizaciones, la ingeniera del software es una
actividad de equipo, y los ingenieros invierten mucho tiempo interactuando
con los otros miembros del equipo. La tecnologa CASE proporciona mucha
ayuda para esto.
Actualmente la tecnologa CASE est madura y hay herramientas disponibles y
bancos de trabajo en un amplio rango de proveedores.

Bibliografa 2:
Libro: Ingeniera de Software, Sptima edicin.
Autor: Ian Sommerville
Editorial:
Captulo: 4
Pginas: 79
1.6. CLASIFICACIN DE LAS HERRAMIENTAS CASE
Las herramientas CASE se pueden clasificar por su funcin, por su papel como
instrumentos para administradores o personal tcnico, por su utilizacin en los
distintos pasos del proceso de ingeniera del software, por la arquitectura del
entorno (hardware y software) que les presta su apoyo, o incluso por su origen o
coste [QED89]. La taxonoma que se presenta a continuacin utiliza como criterio
principal la funcin.
Herramientas de ingeniera de procesos de negocio.
Al modelar los requisitos de informacin estratgica de una organizacin, las
herramientas de ingeniera de procesos de negocios proporcionan un
metamodelo del cual se derivan sistemas de informacin especficos.
En lugar de centrarse en los requisitos de una aplicacin especfica, estas
herramientas CASE modelan la informacin de negocio cuando sta se transfiere
entre distintas entidades organizativas en el seno de una compaa. El objetivo
primordial de las herramientas de esta categora consiste en representar objetos
de datos de negocio, sus relaciones y la forma en que fluyen estos objetos de
datos entre distintas zonas de negocio en el seno de la compaa.
Modelado de procesos y herramientas de gestin.
Si una organizacin trabaja por mejorar un proceso de negocio (o de software) lo
primero que debe hacer es entenderlo. Las herramientas de modelado de
procesos (llamadas tambin herramientas de tecnologiu de procesos) se utilizan
para representar los elementos clave del proceso de manera que sea posible
entenderlo mejor.

35

Estas herramientas tambin pueden proporcionar vnculos con descripciones de

procesos que ayuden a quienes estn implicados en el proceso de comprender las
tareas que se requieren para llevar a cabo ese proceso. Adems, las herramientas
de gestin de procesos pueden proporcionar vnculos con otras herramientas que
proporcionan un apoyo para las actividades de proceso ya definidas.
Herramientas de planificacin de proyectos. Las herramientas de esta
categora se centran en dos reas primordiales: estimacin de costes y de
esfuerzos del proyecto de software y planificacin de proyectos. Las herramientas
de estimacin calculan el esfuerzo estimado, la duracin del proyecto y el nmero
de personas recomendado para el proyecto. Las herramientas de planificacin de
proyectos hacen posible que el gestor defina todas las tareas del proyecto (la
estructura de desglose de tareas), que cree una red de tareas (normalmente
empleando una entrada grfica), que represente las interdependencias entre
tareas y que modele la cantidad de paralelismo que sea posible para ese proyecto.
Herramientas de anlisis de riesgos. La identificacin de posibles riesgos y el
desarrollo de un plan para mitigar, monitorizar y gestionar esos riesgos tienen una
importancia fundamental en los proyectos grandes.
Las herramientas de anlisis de riesgos hacen posible que el gestor del proyecto
construya una tabla de riesgos proporcionando una gua detallada en la
identificacin y anlisis de riesgos.
Herramientas de gestin de proyectos. La planificacin del proyecto y el plan
del proyecto debern ser rastreados y monitorizados de forma continua. Adems,
el gestor deber utilizar las herramientas que recojan mtricas que en ltima
instancia proporcionen una indicacin de la calidad del producto del software. Las
herramientas de esta categora suelen ser extensiones de herramientas de
planificacin de proyectos.
Herramientas de seguimiento de requisitos.
Cuando se desarrollan grandes sistemas, las cosas se derrumban. Es decir, el
sistema proporcionado suele no satisfacer los requisitos especificados por el
cliente.
El objetivo de las herramientas de seguimiento es proporciona run enfoque
sistemtico para el aislamiento delos requisitos, comenzando por el RFP del
cliente o por la especificacin. Las herramientas tpicas de seguimiento de
requisitos combinan una evaluacin de textos por interaccin humana, con un
sistema de gestin de bases de datos que almacena y categoriza todos y cada
uno de los requisitos del sistema que se analizan a partir de la RFP o
especificacin original.
Herramientas de mtricas y de gestin. Las mtricas del software mejoran la
capacidad del gestor para controlar y coordinar el proceso de ingeniera del
software y la capacidad del ingeniero para mejorar la calidad del software que se
produce. Las mtricas o herramientas de medidas actuales se centran en
caractersticas de procesos y productos. Las herramientas orientadas a la gestin

36

se sirven de mtricas especficas del proyecto (por ejemplo, LDC/persona-mes,

defectos por punto de funcin) que proporcionan una indicacin global de
productividad o de calidad. Las herramientas con orientacin tcnica determinan
las mtricas tcnicas que proporcionan una mejor visin de la calidad del diseo o
del cdigo.
Herramientas de documentacin. Las herramientas de produccin de
documentos y de autoedicin pres-tan su apoyo a casi todos los aspectos de la
ingeniera del software, y representan una importante oportunidad de
aprovechamiento para todos los que desarrollan software. La mayora de las
organizaciones dedicadas al desarrollo de software invierten una cantidad de
tiempo considerable en el desarrollo de documentos, y en muchos casos el
proceso de documentacin en s resulta bastante deficiente. Es frecuente que una
organizacin de desarrollo de software invierta en la documentacin hasta un 20 o
un 30 por 100 -de su esfuerzo global de desarrollo de software. Por esta razn, las
herramientas de documentacin suponen una oportunidad importante para
mejorar la productividad.
Herramientas de software de sistema. CASE es una tecnologa de estaciones
de trabajo. Por tanto, el entorno CASE deber adaptarse a un software de sistema
en red de alta calidad, al correo electrnico, a los tablones de anuncios
electrnicos y a otras posibilidades de comunicarse.
Herramientas de control de calidad. La mayor parte de las herramientas CASE
que afirman tener como principal inters el control de calidad son en realidad
herramientas de mtricas que hacen una auditora del cdigo fuente para
determinar si se ajusta o no a ciertos estndares del lenguaje. Otras herramientas
extraen mtricas tcnicas (Captulos 19 y 24) en un esfuerzo por extrapolar la
calidad del software que se est construyendo.
Herramientas de gestin de bases de datos. El software de gestin de bases de
datos sirve como fundamento para establecer una base de datos CASE
(repositorio), que tambin se denominar base de datos del proyecto. Dada la
importancia de los objetos de configuracin, las herramientas de gestin de bases
de datos para CASE pueden evolucionar a partir de los sistemas de gestin de
bases de datos relacionales (SGBDR) para transformarse en sistemas de gestin
de bases de datos orientadas a objetos (SGBDOO).
Herramientas de gestin de configuracin de software.
La gestin de configuracin de software (GCS) se encuentra en el ncleo de todos
los entornos CASE. Las herramientas pueden ofrecer su asistencia en las cinco
tareas principales de GCS -identificacin, control de versiones, control de cambios,
auditora y contabilidad de estados-. La base de datos CASE proporciona el
mecanismo de identificar todos los elementos de configuracin y de relacionarlo
con otros elementos; el proceso de control de cambios se puede implementar con
ayuda de las herramientas especializadas; un acceso sencillo a los elementos de
configuracin individuales facilita el proceso de auditora; y las herramientas de

37

comunicacin CASE pueden mejorar enormemente la Contabilidad de estados

(ofreciendo informacin acerca de los cambios a todos aquellos que necesiten
conocerlos).
Herramientas de anlisis y diseo. Las herramientas de anlisis y diseo hacen
posible que el ingeniero del software cree modelos del sistema que vaya a
construir. Los modelos contienen una representacin de los datos, funcin y
comportamiento (en el nivel de anlisis), as como caracterizaciones del diseo de
datos, de arquitectura, a nivel de componentes e interfaz'. Al efectuar una
comprobacin de consistencia y validez de los modelos, las herramientas de
anlisis y diseo proporcionan al ingeniero del software un cierto grado de visin
en lo tocante a la representacin del anlisis, y le ayudan a eliminar errores antes
de que se propaguen al diseo, o lo que es peor, a la propia implementacin.
Herramientas PROISIM. Las herramientas PRO/SIM (de construccin de
prototipos y simulacin) [MCW] proporcionan al ingeniero del software la
capacidad de predecir el comportamiento de un sistema en tiempo real antes de
llegar a construirlo. Adems, tambin le capacitan para desarrollar simulaciones
del sistema de tiempo real, lo que permitir que el cliente obtenga ideas acerca de
su funcionamiento, comportamiento y respuesta antes de la verdadera
implementacin.
Herramientas de desarrollo y diseo de interfaz. Las herramientas de
desarrollo y diseo de interfaz son en realidad un conjunto de herramientas de
componentes de programas (clases) tales como mens, botones, estructuras de
ventanas, iconos, mecanismos de desplazamiento de la pantalla, controladores de
dispositivos, etc. Sin embargo, estos conjuntos de herramientas se estn viendo
sustituidos por herramientas de construccin de prototipos de interfaz que
permiten una rpida creacin en pantalla de interfaces de usuario sofisticadas, que
se ajustan al estndar de interfaz que se haya adoptado para el software.
Herramientas de construccin de prototipos. Se puede utilizar toda una gama
de herramientas de construccin de prototipos. Los generadores de pantallas
permiten al ingeniero del software definir rpidamente la disposicin de la pantalla
para aplicaciones interactivas.
Otras herramientas de prototipos CASE ms sofisticadas permiten la creacin de
un diseo de datos, acompaado por diseos e informes de la pantalla. Muchas
herramientas de anlisis y diseo son ms extensas y proporcionan opciones de
construccin de prototipos. Las herramientas PRO/SIM generan un diseo
esquemtico de cdigo fuente en Ada y C para las aplicaciones de ingeniera (en
tiempo real). Por ltimo, una gama amplia de herramientas de cuarta generacin
poseen tambin caractersticas de construccin de prototipos.
Herramientas de programacin. La categora de herramientas de programacin
abarca los compiladores, editores y depuradores disponibles para apoyar a la
mayora de los lenguajes de programacin convencionales.

38

Adems, en esta categora tambin residen los entornos de programacin

orientados a objetos (00), los lenguajes de cuarta generacin, los entornos de
programacin grfica, los generadores de aplicaciones y los lenguajes de consulta
de bases de datos.
Herramientas de desarrollo de Webs. Las actividades asociadas a la ingeniera
Web estn apoyadas por una variedad de herramientas de desarrollo de
WebApps.
Entre estas herramientas se incluyen las que prestan ayuda en la generacin de
texto, grficos, formularios, guiones, applets y otros elementos de una pgina
Web.
Herramientas de integracin y pruebas. En el directorio de herramientas de
pruebas de software del Software Quality Engineering [SQE95], se definen las
categoras de herramientas de pruebas siguientes:
o Adquisicin de datos: herramientas que adquieren los datos que se
utilizarn durante la prueba; medida Esttica: herramientas que analizan el
cdigo fuente sin Ejecutar casos de prueba; medida dinmica: herramientas
que analizan el cdigo fuente durante la ejecucin;
o Simulacin: herramientas que simulan las funciones del hardware o de
otros elementos externos;
o Gestin de pruebas: herramientas que prestan su asistencia en la
planificacin, desarrollo y control de las pruebas;
o Herramientas de funcionalidad cruzada: se trata de herramientas que
atraviesan los lmites de las categoras anteriores.
Debera tenerse en cuenta que muchas de las herramientas de prueba poseen
caractersticas que abarcan dos categoras o ms de las anteriormente
mencionadas.
Herramientas de anlisis esttico. Las herramientas de anlisis esttico prestan
su asistencia al ingeniero del software a efectos de derivar casos prcticos. En la
industria se utilizan tres tipos distintos de herramientas estticas de prueba:
herramientas de prueba basadas en cdigo; lenguajes de prueba especializados y
herramientas de prueba basadas en requisitos. Las herramientas de prueba
basadas en cdigo admiten un cdigo fuente (o LDP) como entrada, y llevan a
cabo varios anlisis de los que se obtiene la generacin de casos de prueba. Los
lenguajes de prueba especializados (por ejemplo, ATLAS) hacen posible que el
ingeniero del software escriba especificaciones de prueba detalladas para
describir todos los casos de prueba y la logstica de su ejecucin. Las
herramientas de prueba basadas en requisitos aslan los requisitos del usuario y
sugieren los casos de prueba (o clases de prueba) que ejercitarn esos requisitos.
Herramientas de anlisis dinmico. Las herramientas de anlisis dinmico
interactan con el programa que se est ejecutando, prueban la cobertura de
rutas, prueban las afirmaciones acerca del valor de variables especficas e
instrumentan por otro lado el flujo de ejecucin del programa. Las herramientas
dinmicas pueden ser intrusivas, o no intrusivas. Las herramientas intrusivas
modifican el software que hay que comprobar mediante la insercin de sondas

39

(instrucciones adicionales) y que efectan las actividades mencionadas

anteriormente. Las herramientas de prueba no intrusivas utilizan un procesador
hardware por separado que funciona en paralelo con el procesador que contiene
el programa que se est probando.
Herramientas de gestin de pruebas. Las herramientas de gestin de pruebas
se utilizan para controlar y coordinar las pruebas del software por todos y cada
uno de los pasos principales de las pruebas. Las herramientas de esta categora
gestionan y coordinan las pruebas de regresiones, efectan comparaciones que
determinan las diferencias entre la salida real y la esperada y realizan pruebas por
lotes de programas con interfaces hombre- mquina interactivas. Adems de las
funciones indicadas anteriormente, muchas herramientas de gestin de pruebas
sirven tambin como controladores de pruebas genricos. Un controlador de
pruebas lee uno o ms casos de prueba de algn archivo de pruebas, aplica
formato a los datos de prueba para que se ajusten a las necesidades del software
que se est probando, e invoca entonces al software que es preciso probar.
Herramientas de pruebas cliente/servidor. El entorno C/S exige unas
herramientas de pruebas especializadas que ejerciten la interfaz grfica de usuario
y los requisitos de comunicaciones en red para el cliente y el servidor.
Herramientas de reingeniera. Las herramientas para el software heredado
abarcan un conjunto de actividades de mantenimiento que actualmente absorben
un porcentaje significativo de todo el esfuerzo relacionado con el software. La
categora de herramientas de reingeniera se puede subdividir en las funciones
siguientes:
o Herramientas de ingeniera inversa para producir
o Especificaciones: se toma el cdigo fuente como entrada y se generan
modelos grficas de anlisis y diseo estructurados, listas de utilizacin y
ms informacin sobre el diseo;
o Herramientas de reestructuracin y anlisis de
o Cdigo: se analiza la sintaxis del programa, se genera una grfica de
control de flujo y se genera automticamente un programa estructurado; y
o Herramientas de reingeniera para sistemas online: se utilizan para
modificar sistemas de bases de datos on-line (por ejemplo, para convertir
archivos IDMS o DB2 en un formato de entidades y relaciones).
Muchas de las herramientas anteriores se ven limitadas a lenguajes de
programacin especficos (aunque abarcan la mayora de los lenguajes
principales) y requieren un cierto grado de interaccin con el ingeniero del
software.
Bibliografa 1:
Libro: Ingeniera de Software, Un enfoque prctico, Quinta edicin.
Autor: Roger S. Pressman
Editorial: Mc Graw Hill
Captulo: 31
Pginas: 561-565

40

1.6. CLASIFICACIN DE LAS HERRAMIENTAS CASE

No existe una nica clasificacin de herramientas CASE y en ocasiones, es difcil
incluirlas en una clase determinada.

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

Las herramientas CASE se clasifican como de bajo nivel, de alto nivel e

integradas, estas ltimas combinando las de alto nivel en un solo conjunto.
Las herramientas CASE de alto nivel ayudan principalmente a los analistas y
diseadores, en tanto que las de bajo nivel son utilizadas con ms frecuencia por
programadores y trabajadores que deben implementar los sistemas diseados con
herramientas CASE de alto nivel.

Herramientas CASE de alto nivel

Da al analista la posibilidad de crear y modificar el diseo del sistema. Todo la
informacin relacionada con el proyecto relacionada con el proyecto se almacena
en una enciclopedia denominada deposito CASE, una enorme coleccin de
registros, elementos, diagramas, pantallas informes e informacin diversa.
Las herramientas CASE de alto nivel tambin pueden apoyar a la modelacin de
los requerimientos funcionales de una organizacin, ayudar a los analistas y
usuarios a definir el alcance de un proyecto determinado y visualizar la forma en el
que el proyecto se combina con otras partes de la organizacin.

Herramientas CASE de bajo nivel

Las herramientas CASE de bajo nivel se utilizan para generar cdigo fuente de
computadoras, eliminando as la necesidad de programar el sistema.
La generacin de cdigo tiene varias ventajas:
1. El sistema se puede generar ms rpido que si tuviera que escribir todos
los programas.
Es necesario ingresar por completo el diseo en el conjunto de
herramientas, tarea que poda considerar un tiempo considerable.
2. La generacin de cdigo reduce el tiempo invertido en el mantenimiento. No
hay necesidad de modificar, probar y depurar los programas de
computadora.

41

Bibliografa 2:
Libro: Anlisis de sistemas, Sexta edicin
Autor: E. Kendall, Kenneth y E. Kendall, Julie
Editorial: PEARSON
Captulo: 1
Pginas: 14-15

CONCLUSIN

En esta unidad se mostraron los aspectos bsicos de la ingeniera del software, tal
como lo dice el ttulo de la unidad, se abordaron los fundamentos de esta rama de
la ingeniera. Definicin de software, sus aplicaciones en varios campos
profesionales y las caractersticas que debe cumplir todo software Tambin se
hace un recorrido por las etapas de creacin del software, desde que se planea
hasta que se realiza y posteriormente hasta su mantenimiento y evolucin de ste.
Adems se muestra el papel evolutivo del software, el cual se clasific de acuerdo
a generaciones, y como se observa se ha ido cambiado la metodologa de la
ingeniera de software a travs de varios enfoques y paradigmas (Estructurados y
orientados a objetos), se explica de manera breve la evolucin del software desde
los inicios de la programacin (Aos 60) hasta hoy en da, donde el paradigma de
equipos potentes es el que predomina hoy en da. Tambin se menciona el uso de
las herramientas CASE, las cuales son aplicaciones que reducen el costo de
productividad (Tiempo y dinero) y cul fue el origen de dichas herramientas, las
cules salieron a la luz en los aos 80.
En conclusin general se destacan conceptos fundamentales que se necesitan
cubrir para tocar temas posteriores a esta unidad y que si bien son bsicos a estas
alturas del nivel acadmico cursado en la carrera de Ingeniera en Sistemas
computacionales, son la base para toda sta rama de la ingeniera y por ello es
que se hace enfoque en comprender dichos conceptos para que de alguna
manera queden bien plasmados y conceptos posteriores puedan entenderse con
mayor facilidad.

42

UNIDAD 2. INGENIERA DE REQUISITOS

INTRODUCCIN
La ingeniera de requisitos del software es un proceso de descubrimiento,
refinamiento, modelado y especificacin. Se refinan en detalle los requisitos del
sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la ingeniera de
requisitos un conjunto de actividades que son denominadas anlisis El cliente
intenta replantear un sistema confuso, a nivel de descripcin de datos, funciones y
comportamiento, en detalles concretos. El desarrollador acta como interrogador,
como consultor, como persona que resuelve problemas y como negociador.
El anlisis y la especificacin de requisitos pueden parecer una tarea
relativamente sencilla, pero las apariencias engaan. El contenido de
comunicacin es muy denso. Abundan las ocasiones para malas interpretaciones
o falta de informacin. Es muy probable que haya ambigedad. El dilema al que se
enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa
frase de un cliente annimo: S que cree que entendi lo que piensa que dije,
pero no estoy seguro de que se d cuenta de que lo que escuch no es lo que yo
quise decir.
El anlisis de requisitos es una tarea de ingeniera del software que cubre el
hueco entre la definicin del software a nivel sistema y el diseo de software. El
anlisis de requerimientos permite al ingeniero de sistemas especificar las
caractersticas operacionales del software (funcin, datos y rendimientos), indica la
interfaz del software con otros elementos del sistema y establece las restricciones
que debe cumplir el software.

43

2.1 TAREAS DE LA INGENIERIA DE REQUISITOS

El anlisis de requerimientos establece el proceso de definicin de requerimientos

como una serie de tareas o actividades mediante las cuales se busca ganar
conocimientos relevantes del problema, que se utilizaran para producir una
especificacin formal del software necesario para resolverlo.

En el proceso de anlisis de requerimientos del software se puede identificar cinco

tareas fundamentales.
1. Reconocimiento del problema: Se deben estudiar inicialmente las
especificaciones del sistema y el plan del proyecto del software. El analista
debe establecer un canal adecuado de comunicacin con el equipo de
trabajo involucrado en el proyecto. La funcin primordial es reconocer los
elementos del problema tal y como los percibe el usuario.
2. Evaluacin y sntesis: En esta etapa el analista debe centrarse en el flujo
y estructura de la informacin, definir las funciones del software, determinar
los factores que afectan el desarrollo de nuestro sistema.
3. Modelizacin: Se crean modelos para el diseo del software y como base
para la creacin de una especializacin
4. Especificacin: Intentan proporcionar una representacin del software
5. Revisin: Una vez que se han descrito la informacin bsica, se
especifican los criterios de validacin que han de servir para demostrar que
se han llegado a un buen entendimiento de la forma de implementar el
software con xito.

Bibliografa 1: Sedici.unlp.edu.ar/bitstream/handle/10915/4057/2__Ingenieria_de_requerimientos.pdf?sequence=4

44

2.1 TAREAS DE LA INGENIERIA DE REQUISITOS

La ingeniera de requisitos proporciona el mecanismo apropiado para entender lo

que el cliente quiere, analizar las necesidades, valuar la factibilidad, negociar una
solucin razonable, especificar la solucin sin ambigedades, validar la
especificacin, y administrar los requisitos conforme estos se transforman en un
sistema operacional.
Este proceso se lleva a travs de siete distintas funciones:
Inicio
En general, la mayora de los procesos comienzan cuando se identifica una
necesidad de negocios o se descubre un nuevo mercado o servicio potencial.
Al inicio del proyecto los ingenieros de software hacen una serie de preguntas. El
objetivo es establecer una comprensin bsica del problema, las personas que
quieren una solucin, la naturaleza de la solucin que se desea y la efectividad de
la comunicacin preliminar entre el cliente y el desarrollador.
Obtencin
Es preguntarle al cliente, a los usuarios y a otros usuarios cuales son los objetivos
para el sistema o producto, que es lo que se debe lograr, de que forma el producto
satisface las necesidades del negocio y como se utilizara el sistema o producto da
a da.
Cristal y Kang identifican una serie de problemas que ayudan a entender por qu
es difcil la obtencin de requisitos:

Problemas de mbito: El lmite del sistema est mal definido a los

clientes/usuarios especifican detalles tcnicos innecesarios que pueden
confundir, en lugar en clarificar, los objetivos generales del sistema.

Problemas de comprensin: Los clientes/usuarios no estn seguros por

completo de que es lo que se necesita, comprenden poco acerca de las
capacidades y limitaciones de su ambiente de cmputo, no comprenden de
todo el dominio del problema.

Problemas de volatilidad: Cambian los problemas conforme transcurre el

tiempo

45

Elaboracin
La informacin conseguida con el cliente durante el inicio y la obtencin se
expande y se refina durante la elaboracin. Esta actividad se enfoca en el
desarrollo de un modelo tcnico refinado de las funciones, caractersticas y
restricciones del software.
La obtencin es una accin del modelado del anlisis y se compone de una
serie de tareas de modelado y refinamiento. La elaboracin se conduce
mediante la creacin y el refinamiento de escenarios del usuario que
describen la forma en que el usuario final interacta con el sistema.
Cada escenario del usuario se analiza para obtener clases de anlisis y se
identifican los servicios que quiere cada clase.
Se identifican las relaciones y la colaboracin entre las clases y se produce
una variedad de diagramas UML complementarias.
Negociacin
El ingeniero de requisitos debe conciliar algunos conflictos por medio de un
proceso de negociacin. Se pide a los clientes, usuarios y a otros
interesados que ordenen sus requisitos y despus discutan los conflictos
relacionados con la prioridad.
Se identifican y analizan los riesgos asociados con cada requisito. Se hacen
estimaciones preliminares del esfuerzo requiriendo para su desarrollo y
despus se utilizan para evaluar el impacto de cada requisito en el costo del
proyecto y sobre el tiempo de entrega.
Especificacin
Una especificacin puede ser un documento escrito, un conjunto de
modelos grficos.
Algunos sugieren que para una especificacin se debe desarrollar y utilizar
una plantilla estndar [SOM197] argumenta que estos conducen a que los
requisitos sean presentados de una manera ms consistente y por ende
ms entendible.
La especificacin es el producto de trabajo final que genera la ingeniera de
requisitos.
Validacin
La calidad de los productos de trabaos de software procedentes de la
ingeniera de requisitos se evala durante un proceso de validacin.
La validacin de requisitos examina la especificacin para asegurar que
todos los requisitos de software se han establecido de manera precisa; que

46

se han detectado las inconsistencias, admisiones y errores y que estos han

sido corregidos y que los productos de trabajo cumplen con los estndares
establecidos para el proceso, proyecto y producto.
El equipo de revisin incluye: Ingenieros de software, clientes, usuarios y
otros interesados.

Gestin de requisitos
Es un conjunto de actividades que ayudan al equipo de proyecto a
identificar, controlar y rastrear los requisitos y los cambios a estos en
cualquier momento mientras se desarrolla el proyecto.
La gestin de requisitos comienza la identificacin los requisitos se
desarrollan las tablas de rastreabilidad.
Entre las muchas tablas posibles estn:
Tabla de rastreabilidad de las caractersticas: Muestra la manera en
que los requisitos se relacionan con las caractersticas del
sistema/producto observables para el cliente
Tabla de rastreabilidad de la fuente: Identifica la fuente de cada
registro
Tabla de rastreabilidad de dependencia: Indica la forma en que los
requisitos estn relacionados entre si
Tabla de rastreabilidad del subsistema: Establece categoras entre
los requisitos, de acuerdo con el subsistema que gobierna.
Tabal de rastreabilidad de la interfaz: Muestra la forma en que los
requisitos se relacionan con las interfaces internas y externas del
sistema.

Bibliografa 2: Ingeniera de Software. Un enfoque practico

Autor: Roger S. Presuman 6 edicin
Editorial Mc Graw Hill
Captulo 7 Paginas: 157-16

47

2. 2 TCNICAS DE LA INGENIERIA DE REQUISITOS

Se conocen varias tcnicas de la ingeniera de requisitos estas pueden ser
aplicables a las distintas fases del proceso de la ingeniera de requisitos. Las
tcnicas ms usadas son:
Entrevistas y cuestionarios: Estos se emplean para reunir informacin
proveniente de personas o grupos. El analista conversa con el entrevistado
y realiza preguntas relacionadas con varios aspectos de un sistema.
Sistemas existentes: Consiste en analizar distintos sistemas ya
desarrollados que estn relacionados con el sistema a ser construido se
puede analizar la interfaces de usuario observando el tipo de informacin
que se maneja y como es manejada.
Lluvia de ideas: Este modelo se usa para generar ideas. La intencin en
su aplicacin es la de generar la mxima cantidad posible de
requerimientos del sistema, la principal intencin es generar muchas ideas,
posteriormente se irn eliminando en base a distintos criterios como caro,
impecable, etc.
Prototipos: Para validar los requerimientos hallados, se construyen
prototipos. Los prototipos son simulaciones del posible producto, que luego
son utilizadas por el usuario final, permitiendo conseguir una importante
retroalimentacin en cuanto a si el sistema diseado con base a los
requerimientos recolectados que permiten al usuario realizar su trabajo de
manera eficiente y efectiva.
Herramientas automatizadas para la administracin de requerimientos:
Las herramientas CASE se le conoce a todo aquel software que es usado
para ayudar a las actividades del proceso de desarrollo del software. Estas
herramientas se concentran en capturar requerimientos, administrarlos y
producir una especificacin de requisitos. Entre otras cosas estas
herramientas permiten un mayor control en proyectos complejos, reducir
costos y retrasos en los proyectos.
Bibliografa 1: Instituto Tecnolgico de Huejutla
Institutotec.blogspot.mx/2013/03/22-tecnicas-de-la-ingenieria.html

48

2.2 TCNICAS DE LA INGENIERIA DE REQUISITOS

La comprensin de los requerimientos por parte del analista mejora en cada ciclo
de vida.
Se cubren tres tcnicas para la obtencin y anlisis de requerimientos.
Estas son:
Obtencin orientada a puntos de vista
Escenarios
Etnografa
Obtencin orienta a puntos de vista: Para cualquier sistema grande o de
mediano tamao, existen diferentes tipos de usuarios finales.
Aun para sistemas relativamente sencillos, existen muchos puntos de vista
diferentes que deben tomarse en cuenta.
Sus perspectivas no son completamente independientes sino que traslapan, por lo
que tienen requerimientos comunes.
Los enfoques orientados a puntos de vista para la ingeniera de requerimientos
toman en cuenta estos puntos de vista diferentes y los utilizan para estructurar y
organizar tanto el proceso de obtencin como los requerimientos mismos.
Las ventajas del punto de vista son:
1. Son externos al sistema por lo que son la forma natural para estructurar el
proceso de obtencin de requerimientos
2. Es relativamente fcil de decidir si algo es un punto de vista valido
3. Son una forma til de estructurar los requerimientos no funcionales
El mtodo VORD se ha diseado como un marco de trabajo orientado a servicios
para la obtencin y anlisis de requerimientos. Las etapas principales de este
modelo son:
1. Identificacin de puntos de vista: Implica descubrir los que reciben los
servicios del sistema e identificar los servicios especficos que se
suministran a cada punto de vista
2. Estructuracin de puntos de vista: Comprende agrupar los relacionados en
una jerarqua. Los servicios comunes se ubican en los niveles altos de
jerarqua y se heredan los puntos de vista de bajo nivel.
3. Documentacin de puntos de vista: Comprende refinar la descripcin de
estos y los servicios identificados.

49

4. Trazado del punto de vista del sistema: Comprende identificar los objetos
en un diseo orientados a objetos utilizando la informacin del servicio
encapsulado en los puntos de vista.

Etnografa: Es una tcnica de observacin que se puede utilizar para entender los
requerimientos sociales y organizacionales. Un analista se sumerge por si solo en
el entorno laboral donde el sistema se utilizara. El trabajo diario se observa y se
hacen notas de las tareas reales en las que los participantes estn involucrados.
Ayuda a descubrir los requerimientos implcitos que reflejan los procesos reales
ms que los formales en los que la gente est involucrada.
La etnografa es efectiva para descubrir dos tipos de requerimientos:
1. Los requerimientos que se derivan de la forma en la que la gente trabaja
realmente ms que de la forma en la que las definiciones de los procesos
establecen que debera trabajar.
2. Los requerimientos que se derivan de la cooperacin y conocimiento de las
actividades de la gente.

Anlisis
etnogrfico

Juntas de
trabajo

Desarrollo
del sistema
genrico

Construccin
del prototipo
del sistema

Anlisis
dirigido

Evaluacin
del prototipo

Evaluacin y construccin de prototipos para el anlisis de requerimientos

Escenarios: Los escenarios pueden ser especialmente tiles para agregar detalle
a un bosquejo de descripcin de requerimientos. Son descripciones de ejemplos
de las sesiones de interaccin. Cada escenario cubre a un nmero reducido de
interacciones.

50

 Escenarios de eventos: Las convenciones para los diagramas utilizados

en los escenarios de eventos son:
1. Los datos proporcionados desde un punto de vista se representan
como elipses
2. Las entradas y salidas de la informacin de control se ubican en la
parte superior de cada recuadro
3. Las salidas de datos se ubican a la derecha de cada recuadro. Si no
estn encerradas, significan que pertenecen a un sistema.
4. Las excepciones se muestran en la parte interior del recuadro
5. El nombre del siguiente evento esperado despus de completar el
escenario se muestra en un recuadro sombreado.
Casos de uso: identifica a los actores involucrados en una interaccin y nombra
el tipo de esta.
El conjunto de casos de uso representa todas las posibles interacciones que
ocurrirn en los requerimientos del sistema.

Servicios de
prstamo

Usuario de la
Biblioteca
Administracin de
usuarios

Personal de la
Biblioteca

Proveedor

Servicios de
catalogo

Bibliografa 2: Ingeniera de software 6 Edicin

Autor: Ian Somerville, Editorial: Pearson Educacin
Capitulo: 6, Paginas 126-1

51

2.3 MODELADO DE REQUISITOS

Este debe lograr tres objetivos primarios:
1. Describir lo que requiere el cliente
2. Establecer una base para la creacin de un diseo de software
3. Definir un conjunto de requisitos que se puede validar una vez que se
construya el software
Para lograr estos objetivos, el modelo de anlisis extrado toma la siguiente forma:

Descripcin:
o Diccionario de datos: Un almacn que contiene definiciones de todos los
objetos de datos consumidos y producidos por el software
o Modelos de herencia
o Agregacin de objetos
o Modelado del comportamiento de objetos

Tres diagramas diferentes rodean el ncleo:

Diagrama de entidad-relacin (DER): Representa las relaciones entre los
objetos de datos. Este se utiliza para realizar la actividad de modelado de
datos.
Diagrama de flujo de datos (DFD)
Sirve para dos propsitos:
1. Proporciona una indicacin de cmo se transforman los datos a
medida que se avanza en el sistema
2. Representan las funciones que transforman el flujo de datos.
Diagrama de transicin de datos (DTE): Indica cmo se comporta el
sistema a consecuencia de sucesos externos.
Modelado de datos: Este responde a una serie de preguntas especficas
importantes para cualquier aplicacin de procesamiento de datos.
Los mtodos de modelado de datos hacen uso del diagrama de entidad-relacin.
El modelo de datos se compone de tres piezas de informacin interrelacionadas;
el objeto de datos, los atributos que describen al objeto de datos y la relacin que
conecta objetos de datos entre s.

52

 Objeto de datos: Es una representacin de cualquier configuracin de

informacin que es procesada por el software.
Un objeto de datos puede ser:
Una entidad externa
Una cosa
Una ocurrencia o suceso
Un puesto
Una unidad de la organizacin
Una estructura
Atributos: Definen las propiedades de un objeto de datos y toman una de
las tres caractersticas diferentes.
Se puede usar para:
1. Nombrar una ocurrencia del objeto de datos
2. Describe la ocurrencia
3. Hace referencias a otra ocurrencia en otra tabla
Relaciones: Es la manera en que los objetos de datos estn conectados
entre s.
Ejemplo:

Librera

Libros

Bibliografa 1: Ingeniera de software

Autor: Ian Somerville, 7 Edicin
Editorial: Pearson Educacin
Captulo 7, pginas: 150-165

53

2.3- MODELADO DE REQUISITOS

Una representacin de un sistema debe mantener toda la informacin de la
entidad representada. Una abstraccin y selecciona las caractersticas ms
sobresalientes.
Los diferentes tipos del modelo del sistema se basan en varios enfoques de
abstraccin. Algunos modelos son:
Modelos de contexto: Es una de las primeras etapas de la obtencin de
requerimientos y del proceso de anlisis se deben definir lo lmites del sistema.
Esto comprende trabajar conjuntamente con lo stakeholders del sistema para
distinguir lo que es el sistema y su entorno. Se deben tomar esas decisiones al
inicio del proceso para delimitar los costos del sistema y el tiempo requerido para
el anlisis.
La definicin de un contexto del sistema no es una decisin arbitraria. Los
aspectos sociales y organizacionales implican que la posicin de un lmite del
sistema es determinado por los factores no tcnicos.
Una vez que se han tomado las decisiones sobre los lmites del sistema, una parte
de la actividad de anlisis de la definicin de este contexto y las dependencias que
un sistema tiene con su entorno Por lo regular, el primer paso de esta actividad es
la produccin de un modelo arquitectnico sencillo.
MODELOS DE COMPORTAMIENTO: Estos se utilizan para describir el
comportamiento del sistema. Se discuten dos tipos de modelos de
comportamiento, principalmente los de flujo de datos, que modelan el
comportamiento de datos en el sistema, y los modelos de mquinas de estado,
que modelan la forma en que reacciona el sistema a los eventos. Esos modelos se
pueden utilizar de manera conjunta o separad, dependiendo del tipo de sistema
que se est desarrollando.
Modelos de flujo de datos: Se utilizan para mostrar como fluyen los datos a
travs de una secuencia de pasos de procesamiento. Los datos se
trasforman en cada paso antes de moverse a la siguiente etapa. Si los
diagramas de flujo de datos se utilizan para documentar un diseo de
software, estos pasos de procesamiento o transformaciones se representan
por funciones en los programas.
Bibliografa 2- Ingeniera de software
Autor: Ian Somerville, 7 Edicin
Editorial: Pearson Educacin
Captulo 7, pginas: 150-16

54

2.4 HERRAMIENTAS CASE PARA LA INGENIERIA DE REQUISITOS

Un banco de trabajo CASE es un conjunto de herramientas que ayudan a una fase

particular del proceso del software como el diseo, la implementacin o las
pruebas. La ventaja de agrupar las herramientas CASE en un banco de trabajo
es que pueden trabajar en forma conjunta para suministrar una ayuda ms
completa que la que se puede dar con una sola herramienta.
Las herramientas del banco de trabajo se pueden integrar en archivos y depsitos
compartidos o estructuras de datos compartidos.
Los bancos de trabajo para el anlisis y diseo estn diseados para apoyar el
modelado del sistema durante las etapas de anlisis y diseo del proceso del
software.
Los mtodos orientados a los bancos de trabajo incorporan reglas y lineamientos
de los mtodos. Por lo tanto es posible llevar acabo la verificacin automtica de
diagramas.
El diagrama siguiente muestra las herramientas que pueden incluirse en un banco
de trabajo para el anlisis y el diseo.

Diccionario de datos

Generador de
cdigo

Herramientas de
creacin de
formularios

Herramientas de
diagramacin

Deposito central de
informacin

Herramientas de
diseo, anlisis y
verificacin

55

Recursos de
generacin de
informes

Recursos de
lenguajes de
consulta

Recursos de
importacin/exportacin

El banco de trabajo para el anlisis y el diseo del diagrama anterior incluyen:

1. Editores de diagramas: Para crear diagramas de flujo de
datos, jerarquas de objetos, diagramas entidad-relacin,
etc. Capturan la informacin de entidades y lo guardan en
el depsito central.
2. Herramientas de diseo, anlisis y verificacin: Que
procesan el diseo e informan los errores y anomalas.
Estas pueden ser integradas en la herramienta de edicin
de tal forma que los errores del usuario se detectan en una
etapa inicial del proceso.
3. Depsito de lenguajes de consulta: Que permiten al
diseador definir los diseos y la informacin asociada al
diseo en el depsito.
4. Un diccionario de datos: Que contiene la informacin de
las entidades utilizadas en un diseo del sistema.
5. Herramientas de definicin y generacin de informes:
Que toman la informacin del almacn central y que
generan automticamente la documentacin del sistema
6. Herramientas de definicin de formulario: Que permiten
especificar los formatos de pantalla y de documentos.
7. Recursos de importacin/exportacin: Que permiten el
intercambio de informacin del depsito central con otras
herramientas de desarrollo.
8. Generadores de cdigo: Que generan de forma
automtica cdigo o esqueletos de este a partir del dueo
capturado en el almacn principal

Bibliografa 1: Ingeniera de Software

Ian Somerville 7 edicin
Pearson Educacin
Captulo 7
Pg. 166-168

56

2.4- HERRAMIENTAS CASE PARA LA INGENIERIA DE REQUISITOS

Con el anuncio de facilitar las tareas de desarrollo de software, surgen

herramientas informticas que agilizan la labor en la ingeniera de requisitos.
Dichas herramientas se denominan CASE (Ingeniera de software asistido por
computadora), y sirven de apoyo para los desarrolladores, desde el principio hasta
el final del proceso.
Herramientas CASE, hacia la ingeniera de requisitos computarizada.
Estos incluyen un conjunto de programas que facilitan la optimizacin de un
proyecto ofreciendo apoyo permanente a los analistas, ingenieros de software y
desarrolladores.
Hasta hace poco tiempo las herramientas para la gestin de requisitos de software
se limitaban a editores de texto, las cuales hacen la tarea una labor tediosa y
confusa. Actualmente, se cuenta con mltiples opciones, como las que se
mencionan a continuacin:

Herramientas CASE

IRQA 4
Diseada para soportar las actividades realizadas en el proceso de especificacin
de sistemas. 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 solucin mediante el
apoyo metodolgico adaptable a cada cliente.
JEREMIA
No permite la posibilidad de trabajar en equipo, es exclusivamente del cliente.
Ayuda en el seguimiento de los cambios de los requisitos a lo largo del ciclo de
vida. Capta las necesidades, las analiza y las clasifica.
OSRMT
Sus principales caractersticas son:
1. Trabaja en arquitectura cliente/servidor
2. Desarrollada bajo Java
3. Genera la documentacin de requisitos tratados

57

RAMBUTAN
Est basada en XML, 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.
CONTROLA
Ofrece recursos importantes tales como:
1. Administracin de requisitos
2. Administracin de casos de uso
3. Administracin de casos de prueba y error
4. Planeamiento de liberaciones
5. Administracin de implementaciones
6. Control de dependencia entre implementaciones
7. Matriz de rastreabilidad
8. Rastreabilidad de los requisitos

RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos
funcionales del sistema, mediante tres tcnicas:
1. La definicin de la Misin del sistema
2. La construccin del rbol de refinamiento de funciones
3. El desarrollo de Modelo de casos de uso

Bibliografa 2: Herramientas CASE para la ingeniera de requisitos

Autor: Alarcn, Andrea y Sandoval, Erika
Cultura Cientfica JDC 2008

58

CONCLUSIN AUTOR I

El anlisis de requerimientos establece el proceso de definicin de requerimientos

como una serie de tareas o actividades mediante las cuales se busca ganar
conocimientos relevantes del problema, que se utilizaran para producir una
especificacin formal del software necesario para resolverlo.
Las ventajas del punto de vista son:
1. Son externos al sistema por lo que son la forma natural para estructurar el
proceso de obtencin de requerimientos
2. Es relativamente fcil de decidir si algo es un punto de vista valido
3. Son una forma til de estructurar los requerimientos no funcionales
Se cubren tres tcnicas para la obtencin y anlisis de requerimientos.
Estas son:
Obtencin orientada a puntos de vista
Escenarios
Etnografa
Las herramientas del banco de trabajo se pueden integrar en archivos y depsitos
compartidos o estructuras de datos compartidos.
Los bancos de trabajo para el anlisis y diseo estn diseados para apoyar el
modelado del sistema durante las etapas de anlisis y diseo del proceso del
software.
Hasta hace poco tiempo las herramientas para la gestin de requisitos de software
se limitaban a editores de texto, las cuales hacen la tarea una labor tediosa y
confusa.

59

CONCLUSION AUTOR II

La ingeniera de requisitos proporciona el mecanismo apropiado para entender lo

que el cliente quiere, analizar las necesidades, valuar la factibilidad, negociar una
solucin razonable, especificar la solucin sin ambigedades, validar la
especificacin, y administrar los requisitos conforme estos se transforman en un
sistema operacional.
La comprensin de los requerimientos por parte del analista mejora en cada ciclo
de vida.
Se cubren tres tcnicas para la obtencin y anlisis de requerimientos.
Se conocen varias tcnicas de la ingeniera de requisitos estas pueden ser
aplicables a las distintas fases del proceso de la ingeniera de requisitos.
Una representacin de un sistema debe mantener toda la informacin de la
entidad representada. Una abstraccin y selecciona las caractersticas ms
sobresalientes.
Este debe lograr tres objetivos primarios:
1. Describir lo que requiere el cliente
2. Establecer una base para la creacin de un diseo de software
3. Definir un conjunto de requisitos que se puede validar una vez que se
construya el software

Estos incluyen un conjunto de programas que facilitan la optimizacin de un

proyecto ofreciendo apoyo permanente a los analistas, ingenieros de software y
desarrolladores.
Hasta hace poco tiempo las herramientas para la gestin de requisitos de software
se limitaban a editores de texto, las cuales hacen la tarea una labor tediosa y
confusa.

60

UNIDAD 3. MODELO DE ANLISIS

INTRODUCCIN
El modelo de anlisis es la primera representacin tcnica de un sistema. Utiliza
una mezcla de formatos en texto y diagramas para representar los requisitos del
software, las funciones y el comportamiento. De esta manera se hace mucho ms
fcil de comprender dicha representacin, ya que es posible examinar los
requisitos desde diferentes puntos de vista aumentando la probabilidad de
encontrar errores, de que surjan debilidades y de que se descubran descuidos.
El anlisis de requisitos le proporciona al diseador de software una
representacin de datos, funcin y comportamiento que puede trasladar a diseos
arquitectnicos de interfaz. Este, junto al modelo de anlisis, ofrece al
desarrollador y al cliente los medios para evaluar la calidad una vez construido el
software.
El modelo de anlisis debe cumplir tres objetivos primarios:
1. Describir los que requiere el cliente
2. Establecer una base para la creacin de un diseo de software
3. Definir un conjunto de requisitos que pueda validarse una vez construido el
software.

61

3.1 ARQUITECTURA DE CLASES

El objetivo del modelo de anlisis es crear una arquitectura de objetos que sirva
como base para el diseo del sistema.
Dependiendo del tipo de aplicacin existen varias arquitecturas. Ellas se
distinguen segn la organizacin de los objetos de acuerdo a su funcionalidad.
Esto es llamado dimensin de arquitectura.
Dimensin de la arquitectura

- Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la

interaccin externa.
- Bidimensional: un grupo de objetos para manejar la funcionalidad y otros para
las interacciones externas.
-Tridimensional: La ms usada en los sistemas de informacin que siendo el
Modelo-Vista-Control.
Arquitectura Modelo-Vista-Control
Es un patrn de arquitectura de software que separa los datos de una aplicacin,
la interfaz del usuario y la lgica de negocio en tres componentes distintos. El
modelo es el sistema de gestin de base de datos y la lgica de negocio y el
controlador es el responsable de recibir los eventos de entrada desde la vista.
Modelo informacin
Vista presentacin con el usuario
Control comportamiento

Bibliografa
1:
http://dsc.itpn.mx/recursosisc/5semestre/fundamentoseningenieriadesoftware/Unid
ad%20III.pdf

62

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. Como se discuti en la
introduccin del libro, dependiendo del tipo de aplicacin existen diversas
arquitecturas que se pueden utilizar, siendo de nuestro inters aquellas
arquitecturas especialmente diseadas para el manejo de los sistemas de
informacin, las cuales involucran ricas interfaces de usuario y accesos a base de
datos como aspectos fundamentales de la arquitectura.
En trmino de las propias arquitecturas, 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 interfaces 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.
La vista o presentacin de la informacin corresponde a las interfaces que se le
presentan al usuario para el manejo de la informacin, donde por lo general
pueden existir mltiples vistas sobre un mismo modelo. Tpicamente la informacin
representa el dominio del problema y es almacenada en una base de datos. Por
otro lado el control corresponde a la manipulacin de la informacin a travs de
sus diversas presentaciones.
Y 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.

Bibliografa 2: http://ithabiezer.blogspot.mx/2013/04/31-arquitectura-declases.html

63

3.2 IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

La arquitectura de objetos debe considerar los tres tipos de estereotipos de
objetos.
Para ello se deben identificar primero las clases borde, las clases entidad y
finalmente las de Control.
En general, los cambios ms comunes a un sistema son los de funcionalidad y
bordes.
Los cambios de las interfaces deben afectar solo a los objetos borde. Los cambios
a la funcionalidad son ms difciles de administrar, ya que sta puede abarcar
todos los tipos de objetos.
Bordes
Toda la funcionalidad especificada en las descripciones de los casos de uso que
depende directamente de los aspectos externos del sistema, se ubica en los
objetos borde, pues a travs de ellos se comunican los actores con el sistema. La
tarea de una clase borde es traducir los eventos generados por un actor en
eventos comprendidos por el sistema, y traducir los eventos del sistema en una
presentacin comprensible para el actor.
Las clases borde en otras palabras, describen la comunicacin bidireccional entre
el sistema y los actores.
Las clases borde son bastante fciles de identificar, donde se cuenta con al menos
tres estrategias:
1. Se pueden identificar con base a los actores.
2. Se pueden identificar con base en las descripciones de las interfaces del
sistema que acompaan al modelo de requisitos.
3. Se pueden identificar con base en las descripciones de los casos de uso y
extraer la funcionalidad especfica a los objetos bordes.
Estrategia correspondiente a los actores.
Cada actor necesita su propia clase borde para comunicarse con el sistema. En
muchos casos un actor puede necesitar de varios objetos borde. Es evidente que
los objetos borde no son totalmente independientes de cada uno, ya que, en
ciertos casos deben saber la existencia de los dems.
Entidad
Se utilizan objetos entidad para modelar la informacin que el sistema debe
manejar a corto y largo plazo. La informacin a corto plazo existe durante la
ejecucin de un caso de uso, mientras que la informacin a largo plazo trasciende

64

los caso de uso, por lo que es necesario guardarla en alguna base de datos o
archivos. Durante la identificacin de objeto entidad, se encontrara que objetos
que objetos similares aparecen en varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar informacin exclusivamente
guardada en el registro de usuario, lo que se hace en la clase entidad
RegistroUsuario, utiliza tambin por el caso de uso RegistroUsuario.
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no
requiere
de
ninguna
clase
entidad.
Registrar Usuario: Este caso de uso requiere guardar informacin
exclusivamente acerca del usuario, lo que se hace en la clase entidad
RegistroUsuario.
Registrar Tarjeta: Este caso de uso requiere guardar informacin exclusivamente
acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
Consultar Informacin: Este casi de uso requiere de toda la informacin
relacionada con consultas. Se puede tomar las clases del dominio del problema y
quitar aquellas relacionadas con registros y reservaciones.
Hacer reservacin: Este caso de uso requiere de la informacin relacionada con
reservaciones. Se pueden tomar las clases del dominio del problema y quitar
aquellas relacionadas con registros.
Pagar Reservacin: Este caso de uso requiere de la informacin relacionada con
reservaciones. Dado que es una extensin al caso de uso Hacer Reservacin, no
es necesario volver a repetir todas las clases entidad, sino ms bien especificar
cualquier clase adicional.
Control
En la mayora de los casos de uso, existe un comportamiento que no se puede
asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una
posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la
solucin no es buena si se considera el aspecto de extensibilidad. Un cambio en el
comportamiento podra afectar varios objetos, dificultando su modificacin. Para
evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difcil lograr un buen balance en la distribucin del comportamiento del caso de
uso entre los objetos entidad, borde y control. Los objetos de control normalmente
proveen a administracin de los dems tipos de objetos.

Bibliografa 1: https://es.scribd.com/doc/246426519/24/Identificacion-de-clasessegun-estereotipos

65

3.2 IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

Para llevar a cabo la transicin del modelo de requisitos al modelo de anlisis se

deben identificar los objetos necesarios para implementar todos los casos de uso.
La arquitectura de objetos debe considerar los tres tipos de estereotipos de
objetos como se discuti anteriormente. Para ello, se deben identificar primero las
clases borde, luego las clases entidad y, finalmente, las de control. En general, se
desea asignar la funcionalidad general del caso de uso. Por otro lado, los objetos
entidad y borde deben contener funcionalidad local, limitando su efecto en los
dems objetos. El trabajo del analista consiste en distribuir de la mejor manera
posible el comportamiento especfico en el modelo de requisitos entre los
diferentes tipos de objetos de la arquitectura de anlisis.
La asignacin de funcionalidad es bastante difcil en la prctica, y afecta en gran
medida de la calidad y mantenimiento del sistema. Los buenos analistas
consideran desde un principio los posibles cambios futuros del sistema.
En general, los cambios ms comunes a un sistema son los de funcionalidad y
bordes. Los cambios de las interfaces deben afectar solo a los objetos borde. Los
cambios a la funcionalidad son ms difciles de administrar, ya que esta puede
abarcar todos los tipos de objetos.
A continuacin se describen se describirn con mayor detalle el proceso de
identificacin de los tres tipos de objetos, identificando las clases para cada caso
de uso segn sus estereotipos. El desafo principal en dicho proceso, es decidir
cuantas y cuales clases deben asignarse por cada caso de uso.
Borde
Toda la funcionalidad especificada en las descripciones de los caso de uso que
depende directamente de los aspectos externos del sistema, se ubica en los
objetos borde, pues a travs de ellos se comunican los actores con el sistema. La
tarea de una clase borde es traducir los eventos generados por un actor en
eventos del sistema en una presentacin comprensible por el actor. Las clases
borde, en otras palabras, describen la comunicacin bidireccional entre el sistema
y los actores.
Las clases borde son bastante fciles de identificar, donde se cuenta con al menos
tres estrategias:
Se puede identificar con base a los actores.
Se pueden identificar con base en las descripciones de las interfaces del sistema
que acompaan al modelo de requisitos.

66

Se pueden identificar con base en las descripciones

extraer la funcionalidad especfica a los objetos bordes.

de los casos de uso y

Comenzaremos utilizando la primera estrategia correspondiente a los actores.

Cada actor necesita su propia clase borde para comunicarse con el sistema. En
muchos casos un actor puede necesitar de varios objetos borde. Es evidente que
los objetos no son totalmente independientes de cada uno, ya que, en ciertos
casos deben saber de la existencia de los dems. Por ejemplo, el usuario debe
interactuar con las clases borde de la interface de usuario que a su vez se
comunican con las clases borde de las pantallas. Debe estar muy bien definida la
interaccin de estos dos grupos de clase borde, las pantallas e interface de
usuario.
Existen dos tipos de clase borde a modelar, dependiendo del tipo de actor: borde a
otros sistemas y bordes a usuarios humanos.
En el caso de objetos borde que se comunican con otros sistemas, es muy
comn que la comunicacin se describa mediante protocolos de comunicacin.
Los objetos bordes pueden traducir las seales del sistema a un protocolo de
comunicacin estandarizada, o simplemente enviar eventos producidos
internamente sin conversiones complejas. Una ventaja de esto, es que si se
cambia el protocolo, estos cambios sern locales al objeto borde. Un mayor
problema ocurre cuando existen seales continuas del mundo externo, como en
los sistemas de medicin o control. Entonces los objetos borde deben muestrear
la seal de entrada, ya que internamente el sistema se procesa en trminos de
eventos.
En el caso de los objetos borde que se comunican con usuarios humanos se
utilizan diversas tcnicas para el modelado de la interaccin. Es fundamental que
las interfaces con el usuario sean lgicas y coherentes. En general, en las
aplicaciones interactivas es comn que las interfaces de usuario sean un aspecto
fundamental y de mayos complejidad dentro de la aplicacin completa.
Aunque cada tipo de objeto tiene un propsito distinto, es evidente que los objetos
borde tienen como propsito principal el manejo de las presentaciones. Sin
embargo, tambin pueden administrar informacin y tener comportamiento. Debe
decidirse de manera individual la cantidad de informacin y tener comportamiento
de un objeto borde. En un extremo, el objeto borde solo debe enviar el evento que
recibe del actor a otros objetos en el sistema, sin participar activamente en el
curso de los eventos. En el otro extremo, el comportamiento del objeto borde
puede ser muy complejo, de manera que la informacin se procede dentro del
objeto borde, haciendo todo el procesamiento de eventos de manera local.
Para identificar que parte del flujo de un caso debe asignarse a los objetos borde,
se deben analizar las interacciones entre los actores y los casos de uso. Esto

67

significa buscar aspectos como, informacin que deba presentarse al actor y

funcionalidad que dependa del comportamiento del actor.

Entidad
Se utilizan objetos entidad para modelar la informacin que el sistema debe
manejar a corto y largo plazos. La informacin a corto plazo existe durante la
ejecucin de un caso de uso, mientras que la informacin a largo plazo trasciende
los casos de uso, por lo que es necesario guardarla en alguna base de datos o
archivo.
Los objetos entidad se identifican principalmente a partir del dominio del problema
del modelo de requisitos. Dado que es posible identificar un gran nmero de
entidades, se deben considerar nicamente aquellos necesarios para la
aplicacin. Los casos de uso deben usarse como guas para identificacin, y
solamente aquellos objetos entidad que puedan justificarse de la descripcin del
caso de uso deben incluirse.
Adicionalmente, no es fcil decidir cundo cierta informacin debe ser modelada
como objeto entidad o atributo. Esto depende de cmo se usara la informacin. Si
esta cuenta con cierta estructura ms all de un simple valor numrico, entonces
debe modelarse como un objeto entidad. Por otro lado, informacin que pueda
describirse mediante un simple valor, debe modelarse como un atributo de un
objeto entidad. Esta decisin es algo arbitraria, ya que cierta informacin puede
modelarse como objeto entidad en un sistema, mientras que en otro puede
representarse mediante un atributo.

Tambin es difcil identificar que operaciones y cuales atributos sern incluidos

dentro de estos objetos.
Dado que la nica forma para manipular un objeto entidad es por medio de sus
operaciones, se deben identificar suficientes operaciones para manipular
completamente al objeto entidad. La descripcin detallada de los casos de uso es
de nuevo un medio extremadamente valioso para identificar estas operaciones.
Las operaciones pueden ser sencillas, sirviendo de acceso a los valores de los
atributos, o complejas, como en el caso de ciertos clculos matemticos basados
en los valores de los atributos del objeto. Sea cual sea la complejidad, estas
operaciones deben depender y afectar solamente a la informacin local.
Durante la identificacin de objetos entidad, se encontrara que objetos similares
aparecen en varios casos de uso.

68

Control
Hasta ahora se han identificado objetos borde y entidad a partir de cada caso de
uso. En algunas situaciones, todo un caso de uso pudiera implementarse
exclusivamente mediante estos dos tipos de objetos. As no se necesitara ningn
objeto control para el respectivo caso de uso. Sin embargo, en la mayora de los
casos de uso, existe un comportamiento que no puede asignar de forma natural a
ninguno de los otros dos tipos de objetos. Una posibilidad es repartir el
comportamiento entre los dos tipos de objetos, pero la solucin no es buena si se
considera el aspecto de extensibilidad. Un cambio en el comportamiento podra
afectar varios objetos, dificultando su modificacin. Por lo tanto, para evitar estos
problemas, tal comportamiento se asigna a objetos control.
En general, es difcil lograr un buen balance en la distribucin del comportamiento
del caso de uso entre los objetos entidad, borde y control. Los objetos de control
normalmente proveen la administracin de los dems tipos de objetos,
dependiendo de la existencia del propio caso de uso. Por lo tanto, los objetos
control se especifica directamente de los casos de uso.
Como primera aproximacin, se especifica un objeto control para cada caso de
uso. Dado que se asigna inicialmente el comportamiento a los objetos borde y
entidad, el comportamiento restante se agrega a los objetos control. Una manera
de asignar el comportamiento es modelar inicialmente el caso de uso sin ningn
objeto control, en otras palabras, solo utilizando objetos borde y objetos entidad.
Cuando tal modelo se ha desarrollado, se ver que hay ciertos comportamientos
que no se asignan de forma natural, a los diversos objetos, o incluso, se distribuye
a varios objetos.
Estos comportamientos deberan asignarse a los objetos control. Otra situacin es
que los comportamientos, despus de distribuirse entre objetos borde y entidad,
sean demasiado complicados. En tal caso, los comportamientos pueden ser
distribuidos en varios objetos control.
En la mayora de los sistemas, se promueve la distribucin del manejo de un caso
de uso en un solo objeto control. Sin embargo, la estrategia de asignacin de
control se debe decidir de acuerdo a cada aplicacin.

Bibliografa 2: http://unidadiii-modelodeanalisis.blogspot.mx/2013/04/32identificacion-de-clases-segun.html

69

3.3 CLASES
Modelo de Anlisis
Un modelo conceptual explica los conceptos ms significativos en un dominio del
problema, identificando los atributos y las asociaciones
En POO se representa mediante un grupo de diagramas de estructura esttica, en
este caso un diagrama de clase
Diagrama de Clases
Son estticos muestran que elementos interactan pero no que sucede cuando
ellos hacen la interaccin. Los diagramas de clase son importantes no solo para la
visualizacin, especificacin y documentacin del modelo estructural, sino tambin
para la construccin de sistemas ejecutables.

Ejemplo

Elementos de un Diagrama de Clase

70

Clase OO
Nombre
Atributos
Mtodos

Relaciones entre Clases

Las relaciones entre clases representan asociaciones del mundo del problema.
Las relaciones entre las clases son conexiones entre dichas clases.

Relaciones entre Clases

Existen varios tipos de relaciones:
- Asociacin
- Agregacin
-Composicin
- Generalizacin (Herencia)
- Dependencia
Las relaciones tienen ciertas caractersticas:
- Roles
- Cardinalidad
-Navegabilidad

71

Asociaciones
Relaciones entre las clases que finalmente sern tambin relacin de objetos

Asociacin
Una relacin entre instancias de dos clases independientes entre ellas.
Las dos clases son de diferente naturaleza

Hay una asociacin entre dos clases si una instancia de una clase debe conocer
de la otra para poder ejecutar su trabajo.

72

Cardinalidad
La Cardinalidad o multiplicidad de una relacin es el nmero de posibles
instancias de la clase asociada con una simple instancia de la otra clase.
Las cordialidades pueden ser:
1 Exactamente una instancia
Sin lmite de instancias
0...1 Cero o una instancia
0...* Sin lmite de instancias incluido 0
1...* Al menos una instancia

Navegabilidad-Direccionalidad
La Asociacin es una conexin que tiene direccionalidad, esto es, las clases
involucradas en la relacin se navegan en determinado sentido.

73

Una flecha de navegabilidad en una asociacin muestra en cual direccin la

asociacin puede ser recorrida o consultada.
Relacin Unidireccional

Relacin Bidireccional

Roles
Una relacin tiene dos puntos finales, estos pueden tener un nombre de rol para
clarificar la naturaleza de la asociacin.
Un cliente solicita muchas rdenes y una orden est Asociada a un cliente. Una
persona es empleado de una compaa, una compaa es el empleador de una
persona.

74

Una clase es una construccin que se utiliza como un modelo (o plantilla) para
crear objetos de ese tipo. El modelo describe el estado y el comportamiento que
todos los objetos de la clase comparten. Un objeto de una determinada clase se
denomina una instancia de la clase. La clase que contiene (y se utiliz para crear)
esa instancia se puede considerar como del tipo de ese objeto. Por ejemplo, una
instancia del objeto de la clase "Persona" sera del tipo "Persona".
Una clase por lo general representa un sustantivo, como una persona, lugar o
(posiblemente bastante abstracta) cosa - es el modelo de un concepto dentro de
un programa de computadora. Fundamentalmente, encapsula el estado y el
comportamiento del concepto que representa. Encapsula el estado a travs de
marcadores de datos llamados atributos (o variable miembro o variables de
instancia), y encapsula el comportamiento a travs de secciones de cdigo
reutilizables llamados mtodos.
Bibliografa 1: https://es.scribd.com/doc/246426519/24/Identificacion-de-clasessegun-estereotipos

3.3 CLASES
Las clases son declaraciones o abstracciones de objetos, lo que significa, que una
clase es la definicin de un objeto. Cuando se programa un objeto y se definen
sus caractersticas y funcionalidades, realmente se programa una clase.
Una clase es un contenedor de uno o ms datos (variables o propiedades
miembro) junto a las operaciones de manipulacin de dichos datos
(funciones/mtodos). Las clases pueden definirse como estructuras (struct),
uniones (unin) o clases (class) pudiendo existir diferencias entre cada una de las
definiciones segn el lenguaje. Adems las clases son agrupaciones de objetos
que describen su comportamiento.
Clases
Las clases son lo ms simple de Java. Todo en Java forma parte de una clase, es
una clase o describe cmo funciona una clase. El conocimiento de las clases es
fundamental para poder entender los programas Java.
Todas las acciones de los programas Java se colocan dentro del bloque de una
clase o un objeto. Todos los mtodos se definen dentro del bloque de la clase,
Java no soporta funciones o variables globales. Esto puede despistar a los
programadores de C++, que pueden definir mtodos fuera del bloque de la clase,
pero esta posibilidad es ms un intento de no separarse mucho y ser compatible
con C, que un buen diseo orientado a objetos. As pues, el esqueleto de
cualquier aplicacin Java se basa en la definicin de una clase.

75

Todos los datos bsicos, como los enteros, se deben declarar en las clases antes
de hacer uso de ellos. En C la unidad fundamental son los ficheros con cdigo
fuente, en Java son las clases. De hecho son pocas las sentencias que se pueden
colocar fuera del bloque de una clase. La palabra clave import (equivalente al
#include) puede colocarse al principio de un fichero, fuera del bloque de la clase.
Sin embargo, el compilador reemplazar esa sentencia con el contenido del
fichero que se indique, que consistir, como es de suponer, en ms clases.
Bibliografa
2:
http://dsc.itpn.mx/recursosisc/5semestre/fundamentoseningenieriadesoftware/Unid
ad%20III.pdf

3.4 DIAGRAMAS DE SECUENCIAS

Un diagrama de secuencia es una forma de diagrama de interaccin que muestra
los objetos como lneas de vida a lo largo de la pgina y con sus interacciones en
el tiempo representadas como mensajes dibujados como flechas desde la lnea de
vida origen hasta la lnea de vida destino. Los diagramas de secuencia son
buenos para mostrar qu objetos se comunican con qu otros objetos y qu
mensajes disparan esas comunicaciones. Los diagramas de secuencia no estn
pensados para mostrar lgicas de procedimientos complejos.

Lnea de Vida
Una lnea de vida representa un participante individual en un diagrama de
secuencia. Una lnea de vida usualmente tiene un rectngulo que contiene el
nombre del objeto. Si el nombre es self entonces eso indica que la lnea de vida
representa el clasificador que posee el diagrama de secuencia.
Algunas veces un diagrama de secuencia tendr una lnea de vida con un smbolo
del elemento actor en la parte superior. Este usualmente sera el caso si un
diagrama de secuencia es contenido por un caso de uso. Los elementos entidad,
control y lmite de los diagramas de robustez tambin pueden contener lneas de
vida.

76

Mensajes
Los mensajes se muestran como flechas. Los mensajes pueden ser completos,
perdidos o encontrados; sncronos o asncronos: llamadas o seales. En el
siguiente diagrama, el primer mensaje es un mensaje sncrono (denotado por una
punta de flecha oscura), completo con un mensaje de retorno implcito; el segundo
mensaje es asncrono (denotado por una punta de flecha en lnea) y el tercero es
un mensaje de retorno asncrono (denotado por una lnea punteada).

Ocurrencia de ejecucin
Un rectngulo fino a lo largo de la lnea de vida denota la ocurrencia de ejecucin
o activacin de un foco de control. En el diagrama anterior hay tres ocurrencias de
ejecucin. El primero es el objeto origen que enva dos mensajes y recibe dos
respuestas, el segundo es el objeto destino que recibe un mensaje asncrono y
retorna una respuesta, y el tercero es el objeto destino que recibe un mensaje
asncrono y retorna una respuesta.
Mensaje Self
Un mensaje self puede representar una llamada recursiva de una operacin, o un
mtodo llamando a otro mtodo perteneciente al mismo objeto. Este se muestra
como cuando crea un foco de control anidado en la ocurrencia de ejecucin de la
lnea de vida.

77

Mensajes perdidos y encontrados

Los mensajes perdidos son aquellos que han sido enviados pero que no han
llegado al destino esperado, o que han llegado a un destino que no se muestra en
el diagrama actual. Los mensajes encontrados son aquellos que llegan de un
remitente no conocido, o de un remitente no conocido en el diagrama actual. Ellos
se denotan yendo o llegando desde un elemento de punto final.

Inicio y final de lnea de vida

Una lnea de vida se puede crear o destruir durante la escala de tiempo
representada por un diagrama de secuencia. En el ltimo caso, la lnea de vida se
termina por un smbolo de detencin, representado como una cruz. En el primer
caso, el smbolo al inicio de la lnea de vida se muestra en un nivel ms bajo de la
pgina que el smbolo del objeto que caus la creacin. El siguiente diagrama
muestra un objeto que fue creado y destruido.

Restricciones de tiempo y duracin

En forma predeterminada, un mensaje se muestra como una lnea horizontal. Ya
que la lnea de vida representa el pasaje de tiempo hacia abajo, cuando se modela
un sistema en tiempo real, o incluso un proceso de negocios en tiempo lmite,
puede ser importante considerar el tiempo que toma realizar las acciones. Al
configurar una restriccin de duracin para un mensaje, el mensaje se mostrar
como una lnea inclinada.

78

Bibliografa
1:
http://dsc.itpn.mx/recursosisc/5semestre/fundamentoseningenieriadesoftware/Unid
ad%20III.pdf

3.4 DIAGRAMA DE SECUENCIAS

Un diagrama de secuencia muestra: Interaccin de un conjunto de objetos en una
aplicacin a travs del tiempo. Un conjunto de mensajes, dispuestos en una
secuencia temporal. Cada rol en la secuencia como una lnea de vida, es decir:
una lnea vertical.
Un diagrama de secuencia representa una interaccin como un grfico
bidimensional.
La dimensin vertical: es el eje del tiempo.
La dimensin horizontal muestra los roles de clasificador que representan objetos
individuales en la colaboracin.
Un rol de clasificador
Es la descripcin de un objeto que desempea un determinado papel dentro de
una interaccin, distinto de los otros objetos de la misma clase.
La primera utilizacin de los diagramas de secuencia corresponde a la
documentacin de los casos de uso, se concentra en la descripcin de la
interaccin,
La segunda utilizacin corresponde a un uso ms informtico y permite la
representacin precisa de las interacciones entre objetos.

79

Por lo tanto puede mostrar:

Escenario como la historia individual de la transaccin que detalla los casos de
uso, aclarndolos al nivel de mensajes de los objetos existentes, como tambin
El uso de los mensajes de las clases diseadas en el contexto de una operacin.
Cuando est implementado el comportamiento, Cada mensaje en un diagrama de
secuencia. Corresponde a:
Una operacin en una clase, A un evento disparador, o A una transicin en una
mquina de estados.
Cuando est implementado el comportamiento, cada mensaje en un diagrama de
secuencia corresponde a:
Una operacin en una clase, A un evento disparador, o a una transicin en una
mquina de estados

Activacin
Es la ejecucin de un procedimiento, incluyendo el tiempo que espera a los
procedimientos anidados para ejecutarse.
- Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando
alguna operacin, bien sea por s mismo o por medio de delegacin a alguno de
sus atributos.
-Se denota como un rectngulo delgado sobre la lnea de vida del objeto.
El diagrama siguiente muestra el caso de un objeto A que activa otro objeto B.

80

Mensaje
El mensaje denota el hecho de aportar informacin de un objeto (u otra instancia)
a otro.
Puede ser una seal o llamadas a una operacin.
La notacin para UML del envo de mensajes entre objetos es con una flecha
dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.
-Cuando el diagrama de secuencia corresponde a un uso ms informtico, permite
la representacin precisa de las interacciones entre objetos.
-En este caso el concepto de mensaje unifica todas las formas de comunicacin
entre objetos, en particular la llamada de procedimiento, el evento discreto, la
seal entre flujos de ejecucin o la interrupcin de hardware.

Retorno de una llamada a procedimiento

La flecha de retorno puede suprimirse, por cuanto queda implcita al final de la
activacin

81

La flecha que simboliza un mensaje puede representarse oblicua para materializar

las demoras de transmisin respecto a la dinmica general de la aplicacin.

Un objeto puede enviarse un mensaje a s mismo, o sea un mensaje reflexivo que

se representa de la siguiente forma:

Ocurre una llamada recursiva cuando el control vuelve a entrar en una operacin
en un objeto, pero la segunda llamada es una activacin separada de la primera.

82

Lnea de vida de un objeto

La Lnea de vida de un objeto se representa como una lnea vertical punteada con
un rectngulo de encabezado y con rectngulos a travs de la lnea principal que
denotan la ejecucin de mtodos (activacin).
Creacin y destruccin de objetos
La creacin de objetos se representa haciendo apuntar el mensaje de creacin
sobre un rectngulo que simboliza el objeto creado.
La destruccin se indica por el fin de la lnea de vida y por una letra x, bien a la
altura del mensaje que causa la destruccin, o bien tras el ltimo mensaje enviado
por un objeto que se suicida.

Los diagramas de secuencia pueden completarse por indicaciones textuales,

expresadas en forma de texto libre o de pseudocdigo.
El instante de emisin de un mensaje llamado transicin, puede tener nombre en
el diagrama cerca del punto de partida de la flecha que simboliza el mensaje. Este
nombre sirve entonces, de referencia, por ejemplo, para construir restricciones
temporales.
Cuando la propagacin de un mensaje toma un tiempo significativo respecto a la
dinmica del sistema, los instantes de emisin y de recepcin de los mensajes se
materializan por un par (nombre, nombre primo).
Ejemplo del diagrama completo

83

Bibliografa 2: https://es.scribd.com/doc/246426519/24/Identificacion-de-clasessegun-estereotipos

84

3.5 DICCIONARIO DE CLASES SEGN MDULOS

Diccionario de datos
Los diccionarios de datos son el segundo componente del anlisis del flujo de
datos. En s mismos los diagramas de flujo de datos no describen por completo el
objeto de la investigacin. El diccionario de datos proporciona informacin
adicional sobre el sistema. Esta seccin analiza que es un diccionario de datos,
por qu se necesita en el anlisis de flujo de datos y como desarrollarlo. Se
utilizar el ejemplo del sistema de contabilidad para describir los diccionarios de
datos.
Un diccionario de datos es una lista de todos los elementos incluido en el conjunto
de los diagramas de flujo de datos que describen un sistema. Los elementos
principales en un sistema, estudiados en las secciones anteriores, son el flujo de
datos, el almacenamiento de datos y los procesos. El diccionario de datos
almacena detalles y descripciones de estos elementos.
Si los analistas desean conocer cuntos caracteres hay en un dato, con qu otros
nombres se le conocen en el sistema, o en donde se utilizan dentro del sistema
deben ser capaces de encontrar la respuesta en un diccionario de datos
desarrollado apropiadamente. El diccionario de dato se desarrolla durante el
anlisis de flujo de datos y ayuda el analista involucrado en la determinacin de
los requerimientos de sistemas. Sin embargo, como se ver ms adelante,
tambin el contenido del diccionario de datos se utiliza durante el diseo del
sistema.
En informtica, base de datos acerca de la terminologa que se utilizar en un
sistema de informacin. Para comprender mejor el significado de un diccionario de
datos, puede considerarse su contenido como "datos acerca de los datos"; es
decir, descripciones de todos los dems objetos (archivos, programas, informes,
sinnimos...) existentes en el sistema. Un diccionario de datos almacena la
totalidad de los diversos esquemas y especificaciones de archivos, as como sus
ubicaciones. Si es completo incluye tambin informacin acerca de qu programas
utilizan qu datos, y qu usuarios estn interesados en unos u otros informes. Por
lo general, el diccionario de datos est integrado en el sistema de informacin que
describe.
Bibliografa 1
Autor: Alfredo Hernndez Vega
Pgina web: http://alfredohedzvega.blogspot.mx/2013/04/fundamentos-deingenieria-de-software.html

85

3.5 DICCIONARIO DE CLASES SEGN MDULOS

El diccionario de clases o diccionario de datos, describe textualmente las clases

identificadas durante el modelo del dominio del problema. Este diccionario sirve
como un glosario de trminos.
Un diccionario de clases es un catlogo, un depsito, de los elementos en un
sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los
datos y la forma en que estn estructurados para satisfacer los requerimientos de
los usuarios y las necesidades de la organizacin. En un diccionario de datos se
encuentra la lista de todos los elementos que forman parte del flujo de datos en
todo el sistema. Los elementos ms importantes son flujos de datos, almacenes
de datos y procesos. El diccionario guarda los detalles y descripciones de todos
estos elementos.
El diccionario se desarrolla durante el anlisis de flujo de datos y auxilia a los
analistas que participan en la determinacin de los requerimientos de sistemas.
Importancia del diccionario
Los analistas utilizan los diccionarios de datos por cinco razones importantes:
1. Para manejar los detalles en sistemas grandes.
2. Para comunicar un significado comn para todos los elementos del sistema.
3. Para documentar las caractersticas del sistema.
4. Para facilitar el anlisis de los detalles con la finalidad de evaluar las
caractersticas y determinar dnde efectuar cambios en el sistema.
5. Localizar errores y omisiones en el sistema.

Manejo de detalles
Los sistemas grandes tienen enormes volmenes de datos que fluyen por ellos en
forma de documentos, reportes e incluso plticas. De manera similar, se llevan a
cabo muchas actividades que utilizan los datos existentes o que generan nuevos
detalles. Recurdese, como se mencion en la historia al inicio de este captulo,
que Lodos los sistemas experimentan cambios continuos y manejar de manera
completa todos los detalles es un desafi. Con franqueza, es imposible que los
analistas recuerden todo. Los que tratan de hacerlo cometen de manera invariable
equivocaciones u olvidan elementos importantes. Los mejores analistas no
intentan recordarlo todo, en lugar de hacerlo registran toda la informacin. Algunos
lo hacen sobre hojas de papel y otros quiz sobre tarjetas indexadas. Muchos
emplean para tal fin un procesador de palabras y una computadora personal por

86

supuesto. Los analistas mejor organizados y ms eficaces utilizan diccionarios de

datos automatizados diseados de manera especfica para el anlisis y diseo de
sistemas. Comunicacin de significados
Los diccionarios de datos proporcionan asistencia para asegurar significados
comunes para los elementos y actividades del sistema. Si se examina una
muestra de diagramas de flujo de datos para el procesamiento de pedidos, es
probable que se tengan pocas dificultades para comprender qu datos
representan a la factura y al cheque. Los dos son trminos comunes en el mundo
de los negocios y muchas personas conocen su significado. Los diccionarios de
datos registran detalles adicionales relacionados con el flujo de datos en el
sistema de tal forma que todas las personas participantes puedan localizar con
rapidez la descripcin de flujos de datos, almacenes de datos o procesos.

Bibliografa 2:
Pgina web: http://ithuejutlarodrigo.blogspot.mx/2013/04/35-diccionario-de-clasessegun-modulos.html

3.6 HERRAMIENTAS CASE PARA EL ANLISIS

Introduccin
De acuerdo con Kendall el desarrollo de sistema es asistida por ordenadores es la
aplicacin de informtica, es acelerar el proceso para que han sido desarrolladas.
En cambio la herramienta CASE (Computer-Aided Software Engineering) sirve
para apoyar una fase del ciclo de vida del sistema.
Cuando se planifica la base de datos permite escoger una herramienta CASE para
llevar de forma eficaz y posible las tareas, tambin suelen incluir.
Un diccionario para los datos de la aplicacin de base de datos.
Herramientas de diseo para dar apoyo al anlisis de datos.
Herramientas para desarrollar el modelo de datos corporativo, los esquemas
conceptual y lgico.
Herramientas para desarrollar los prototipos de las aplicaciones.
Con el uso de la herramienta CASE puede mejorar la productividad de
aplicaciones de base de datos.

87

Historia
En la dcada de los setenta el proyecto ISDOS desarrollo un lenguaje llamado
"Problem Statement Language" (PSL) para la solucin de un problema informtico
en un diccionario automatizado. Era un producto de que analizaba los problemas y
necesidades.
La primera herramienta era para PC llamada "Excelerator" en 1984, la oferta de
herramientas es muy amplia como es el EASYCASE o WINPROJECT.
Tecnologa
La tecnologa CASE es la automatizacin del desarrollo software para mejorar la
calidad del sistema de informacin.
Permitir aplicaciones prcticas de metodologas estructuradas, al ser realizadas
con una herramienta consigue agilizar el trabajo.
Facilitar la realizacin de prototipos y 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 software.
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la
utilizacin de grficos.

Bibliografa 1
Autor: Alfredo Hernndez Vega
Pgina web: http://alfredohedzvega.blogspot.mx/2013/04/fundamentos-deingenieria-de-software.html

3.6 HERRAMIENTAS CASE PARA EL ANLISIS

Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end,
orientadas a la automatizacin y soporte de las actividades desarrolladas durante
las primeras fases del desarrollo: anlisis y 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. Se tienen:

88

Herramientas de anlisis y diseo (Modelamiento).

Herramientas de creacin de prototipos y de simulacin.
Herramientas para el diseo y desarrollo de interfaces. Mquinas de anlisis y
diseo. (Modelamiento)
Erwin
PLATINUM Erwin es una herramienta de diseo de base de datos. Brinda
productividad en diseo, generacin, y mantenimiento de aplicaciones. Desde un
modelo lgico de los requerimientos de informacin, hasta el modelo fsico
perfeccionado para las caractersticas especficas de la base de datos diseada,
Erwin permite visualizar la estructura, los elementos importantes, y optimizar el
diseo de la base de datos.
Genera automticamente las tablas y miles de lneas de stored procedure y
triggers para los principales tipos de base de datos. Erwin hace fcil el diseo de
una base de datos. Los diseadores de bases de datos slo apuntan y pulsan un
botn para crear un grfico del modelo E-R (Entidad relacin) de todos sus
requerimientos de datos y capturar las reglas de negocio en un modelo lgico,
mostrando todas las entidades, atributos, relaciones, y llaves importantes.
PowerDesigner
PowerDesigner es una suite de aplicaciones de Powersoft para la construccin,
diseo y modelado de datos a travs de diversas aplicaciones. Es la herramienta
para el anlisis, diseo inteligente y construccin slida de una base de datos y un
desarrollo orientado a modelos de datos a nivel fsico y conceptual, que dan a los
desarrolladores Cliente/Servidor la ms firme base para aplicaciones de alto
rendimiento
Bibliografa 2
Pgina web: http://ithuejutlarodrigo.blogspot.mx/2013/04/36-herramientas-casepara-el-analisis.html

CONCLUSIN
En esta unidad nos dimos cuenta de lo necesario que es la etapa de modelo de
anlisis en la ingeniera de software, conocimos desde la arquitectura de clases, la
identificacin de las clases segn estereotipos, clases, los diagramas de
secuencias, el diccionario de clases segn mdulos y las herramientas CASE para
el anlisis. Todo esto es importante ya que seguimos con la etapa del diseo pero
el anlisis debe ser cuidadoso y extenso, todo es mejor y entendible de tal manera
que ha sido una unidad importante para el desarrollo del anlisis

89

UNIDAD 4. MODELO DE DISEO

INTRODUCCIN
El modelo de diseo es un modelo de objetos que describe la realizacin fsica de
los casos de uso centrndose en como los requisitos funcionales y no funcionales,
junto con otras restricciones relacionadas con el entorno de implementacin,
tienen impacto en el sistema a considerar. Adems, el modelo de diseo sirve de
abstraccin de la implementacin del sistema y es, de ese modo, utilizada como
una entrada fundamental de las actividades de implementacin.

El modelo del diseo es una jerarqua de subsistemas de diseo que contienen

clases del diseo, realizaciones de caso de uso-diseo e interfaces.

90

4.1 ESTRATEGIAS DE DISEO

A travs de la historia de la ingeniera de software ha evolucionado un conjunto de

conceptos fundamentales de diseo de software. Cada uno ofrece al ingeniero de
software un fundamento sobre el cual pueden aplicarse mtodos de diseo ms
elaborados. Los conceptos fundamentales del diseo de software ofrecen el marco
de trabajo necesario para hacer las cosas del modo correcto.
Estas son algunas estrategias del diseo:
Abstraccin
Para un problema determinado se pueden considerar muchos grados de
abstraccin. En un alto grado de abstraccin una solucin se establece en
trminos generales con el lenguaje de entorno del problema. En los grados de
menor abstraccin se proporciona una solucin ms detallada de la solucin. Una
abstraccin procedimental se refiere a una secuencia de instrucciones que tiene
una
funcin
especfica
y
limitada.
Una abstraccin de datos es una coleccin nombrada de datos que describe un
objeto de datos. Por ejemplo, se puede decir que la abstraccin procedimental
abrir
empleara la informacin contenida en los atributos de la abstraccin de datos
puerta.
Arquitectura
La arquitectura del software alude a la estructura general del software y las formas
en las que la estructura proporciona una integridad conceptual para un sistema. La
arquitectura es la estructura u organizacin de los componentes del programa

91

(mdulos), la manera en que estos componentes interactan, y la estructura de

datos que utilizan los componentes.
Patrones
Un patrn de diseo describe una estructura de diseo que resuelve un problema
recurrente de diseo particular dentro de un contexto especfico y en medio de
fuerzas que pueden tener un impacto en la manera en que se aplica y utiliza el
patrn.
Modularidad
Los patrones de arquitectura y diseo de software materializan la modularidad; es
decir, el software se divide en componentes con nombres independientes y que es
posible abordar en forma individual. Estos componentes llamados mdulos se
integran para satisfacer los requisitos del problema. La modularidad se basa en la
estrategia divide y vencers (es ms fcil resolver un problema complejo cuando
ste se divide en piezas ms manejables).

Ocultacin de informacin
El principio de ocultacin de informacin sugiere que los mdulos se caracterizan
por las decisiones de diseo que cada uno oculta a los otros. Los mdulos deben
especificarse y disearse de manera que la informacin (procedimientos y datos)
que est dentro del mdulo sea inaccesible para otros mdulos que no necesiten
esta informacin.

Independencia funcional
Es la suma de directa de la modularidad y de los conceptos de abstraccin y
ocultacin de informacin. La independencia funcional se consigue al desarrollar
mdulos con una funcin determinante y una aversin a la interaccin excesiva
con otros mdulos. Los mdulos independientes son ms fciles de mantener,
probar, modificar y se reduce la propagacin de errores.

Refinamiento
El refinamiento es una estrategia de diseo descendente. El desarrollo de un
programa se realiza al refinar de manera sucesiva los niveles de detalle
procedimentales. El
refinamiento hace que el diseador trabaje sobre el enunciado original y que
proporcione ms y ms detalles conforme se realiza cada refinamiento sucesivo.
La abstraccin y el refinamiento son conceptos complementarios.

92

La meta del diseo es crear un modelo de software que implemente todos los
requisitos del cliente de manera correcta y complazca a aqullos que lo usen. El
proceso de diseo avanza de una visin general del software a una visin ms
estrecha que define el detalle requerido para implementar un sistema.
El proceso de diseo comienza con un enfoque en la arquitectura. Se definen los
subsistemas, se establecen mecanismos de comunicacin entre los subsistemas;
se identifican los componentes y se realiza una descripcin detallada de cada
componente. Adems, se disean las interfaces internas, externas y del usuario.

4.1 ESTRATEGIA DE DISEO

El modelo de diseo es un refinamiento y formalizacin adicional del modelo del
anlisis, donde se toman en cuenta las consecuencias del ambiente de
implementacin. El resultado del modelo de diseo son especificaciones muy
detalladas de todos los objetos, incluyendo sus operaciones y atributos. El modelo
de
diseo
se
basa
en
el
diseo
por
responsabilidades.
Se requiere un modelo de diseo ya que el modelo de anlisis no es lo suficiente
formal para alcanzar el cdigo fuente. Por tal motivo se refinan los objetos,
incluyendo las operaciones y atributos. Adems se debe considerar aspectos
como, los requisitos del rendimiento, tiempo real, concurrencia, lenguaje de
programacin,
manejo
de
base
de
datos,
etc.
Otro objetivo del diseo es validar los resultados de los modelos de requisitos y
anlisis. Durante el diseo, se ve si los resultados anteriores son apropiados para
la implementacin. Si se descubren aspectos que no estn claros en algunos de
los modelos anteriores, estos se aclaran, posiblemente regresando a etapas
anteriores.
La transicin de anlisis a diseo debe decidirse por separado por cada aplicacin
en particular. Aunque es posible continuar trabajando sobre el modelo de anlisis.
Incluso durante la incorporacin del ambiente de implementacin, no es
recomendable, ya que aumenta su complejidad. Por tanto es conveniente tener un
modelo de anlisis ideal del sistema durante el ciclo de vida del sistema dado que
mucho de los cambios del sistema proviene de cambios en el ambiente de
implementacin. Tales cambios se incorporan fcilmente ya que el mismo modelo
del anlisis sirve de base para el modelo del diseo. De esta manera, el modelo
de diseo se ve como una especializacin del modelo de anlisis segn el
ambiente
especifico.

93

Si los cambios en el modelo del diseo provienen de un cambio en la lgica del

sistema, entonces deben hacerse cambios en el modelo de anlisis. Sin embargo,
si el cambio es una consecuencia de la implementacin, entonces los cambios no
deben incorporarse en el modelo de anlisis.
Las estructuras con las cuales se trabajan en el modelo del diseo son
bsicamente las mismas que en el modelo del anlisis. Sin embargo, el punto de
vista cambia, ya que se toma un paso hacia la implementacin. El modelo del
anlisis debe verse como un modelo conceptual y lgico del sistema, en tanto que
el modelo del diseo debe acercarse al cdigo fuente. Esto significa que se
cambia el punto de vista del modelo del diseo a una abstraccin del cdigo
fuente seal. Por lo tanto, el modelo de diseo debe ser una descripcin de cmo
debe estructurarse.
En general, los cambio en la arquitectura del sistema para mejorar su rendimiento
deben proponerse hasta que el sistema este (parcialmente) construido.
Se considera dos aspectos principales del modelo de diseo.
Diseo del objeto. Se refina y formaliza el modelo para generar especificaciones
muy detalladas de todos los objetos, incluyendo sus operaciones y atributos. Se
describe cmo interactan los objetos en cada caso de uso especfico,
especificando que debe hacer cada operacin en cada objeto. Este paso genera
las interfaces de los objetos, las cuales despus deben implementarse mediante
mtodos.
Diseo de sistema. El modelo se adapta al ambiente de implementacin. Este
paso incluye identificar e investigar las consecuencias del ambiente de
implementacin sobre el diseo. Aqu deben tomarse las decisiones de
implementacin estratgicas: como se incorporara una BD en el sistema: que y
como se usaran las bibliotecas de componentes: que lenguajes de programacin
se utilizaran: como se manejaran los procesos incluyendo comunicacin y
requisitos de rendimiento: como se disearan el manejo de excepciones y
recoleccin de basura, etc.
De manera homognea entre los objetos permite que cada objeto sepa menos
cosas.
Esto produce objetos ms pequeos y ms fciles de comprender. La desventaja
es que la inteligencia del sistema va de la mano con la especializacin de las
clases. Si todas las clases son inteligentes, esto significara que estas sern muy
especializadas dificultando la extensibilidad del sistema que requiere generalizar
ms las clases.

94

El tercer enfoque es encontrar un balance entre los dos primeros. La idea es

homogeneizar la inteligencia del sistema solo entre ciertas clases, como las de
control.
El resto de las clases, entidad y borde, sern tontas, generalmente sobreviviendo
a modificaciones en el sistema y manteniendo la lgica introducida durante el
modelo de requisitos y el modelo de anlisis posterior para lograr una mayor
robustez del sistema.
La robustez de un sistema debe ser uno de los objetivos principales del diseo. El
sistema debe estar protegido contra errores y ofrecer diagnsticos que permitan
identificar fallas, en particular aquellas que son fatales. Durante el desarrollo, a
veces es bueno insertar instrucciones internas en el cdigo para descubrir fallas,
aunque luego se eliminen durante la produccin. En general, se debe escoger
lenguajes de programacin que apoyen estos aspectos, como son el manejo de
excepciones. Las principales consideraciones relacionadas con la robustez de un
sistema son las siguientes:
El sistema debe estar protegido contra parmetros incorrectos proporcionados por
el usuario. Cualquier mtodo que acepte parmetros del usuario debe validar la
entrada para evitar problemas. El diseador de mtodos debe considerar dos tipos
de condiciones de error: i) errores lgicos que se identifican durante el anlisis y ii)
errores de implementacin, incluyendo errores del sistema operativo, como los
errores de asignacin de memoria, o errores de archivos de entrada y salida.
El sistema no debe optimizarse hasta que este funcione de manera correcta. Se
debe estudiar las alternativas, como aspectos de memoria, velocidad y simplicidad
de implementacin. No se debe optimizar ms de lo necesario, ya que la
optimizacin compromete la extensibilidad, reus y comprensin del sistema. .
El sistema debe instrumentar un monitoreo de rendimiento y bsqueda de errores.
El esfuerzo para llevarlo a cabo depende del ambiente de programacin. Si el
lenguaje de implementacin no proporciona ningn apoyo, se aaden mtodos de
impresin para cada clase. Tambin se aaden mensajes de entrada y salida a los
mtodos imprimiendo selectivamente estos valores.
El encapsulamiento es fundamental para la robustez del sistema. Ocultar la
informacin interna, atributos e implementacin de mtodos de una clase, permite
cambiarla sin afectar el resto del sistema. nicamente la interface de los mtodos
afecta a las dems clases.
REUSO
El reus es en aspecto fundamental del diseo. Cuanto ms se pueda reutilizar el
cdigo ser mejor la robustez del sistema las siguientes son algunas estrategias

95

para mejorar las posibilidades del reus de los diseo. A travs de la herencia se
incrementa el reuso del cdigo. Se toman los aspectos comunes a clases similares
utilizando superficies comunes. Este en enfoque es efectivo cuando las diferencias
entre las clases son pequeas y las similitudes son grandes. Es importante
considerar la naturaleza de cada herencia para asegurar que no se llegue a
extremos donde la aplicacin de la herencia sea inadecuada.
El uso impropio de la herencia hace que los programas sean difciles de mantener
y extender. Como alternativa, la delegacin provee un mecanismo para el reus
de cdigo, pero sin utilizar la herencia. Esto se basa en el uso de agregacin a
travs de clases intermediarias que ocultan la funcionalidad de las clases a las
cuales se delega.
Extensibilidad
Se debe encapsular otra vez la clase, ocultando su estructura internas a las otras
clases. Slo los mtodos de la clase deben accesar a sus atributos.
No se deben exportar estructuras de datos desde un mtodo. Las estructuras de
datos internas son especficas para el algoritmo del mtodo. Si se exportan las
estructuras se limita la flexibilidad para cambiar el algoritmo ms adelante.
Una clase particular debe tener un conocimiento limitado de la arquitectura de
clases del sistema. Este conocimiento abarcar nicamente las asociaciones entre
sta y sus clases vecinas directas. Cualquier interaccin con un vecino indirecto,
se
deber
hacer
mediante
llamadas
a
los
vecinos
directos
Se debe evitar expresiones que requieran un conocimiento explcito de los tipos de
objetos. En su lugar, se debe de aprovechar el polimorfismo a fin de seleccionar el
comportamiento a ejecutarse, basado en el tipo implcito del objeto.
Se debe distinguir entre operaciones privadas y pblicas. Se vuelve costoso
cambiar operaciones pblicas, debiendo ser definidas con cuidado. Las
operaciones privadas son internas en la clase y sirven nicamente de ayuda para
implementar operaciones pblicas. Las operaciones privadas pueden modificarse
sin afectar otras clases.

Bibliografa 2
Autor: Lenneidy Snchez
Pgina web: http://unudad1conceptos.blogspot.mx/2013/05/unidad4.html

96

4.2 DISEO DE OBJETOS.

Un sistema orientado a objetos est compuesto de objetos que interactan, los
cuales mantienen ellos mismos su estado local y proveen operaciones sobre su
estado. La representacin del estado es privada y no se puede acceder a ella
directamente desde fuera del objeto. El proceso de diseo de objetos comprende
el diseo de clases de objetos y las relaciones entre estas clases. El diseo
orientado a objetos comprende el desarrollo de un modelo orientado a objetos de
un sistema de software para implementar los requerimientos identificados. Los
objetos en un diseo orientado a objetos estn relacionados con el problema a
resolver. Un proceso general para el diseo orientado a objetos puede contener
las siguientes etapas:

Comprender y definir el contexto y los modos de utilizacin del sistema

Disear la arquitectura del sistema.
Identificar los objetos principales del sistema.
Desarrollar los modelos de diseo.
Especificar las interfaces de los objetos.

Para los sistemas es posible definir un diseo en pirmide con las siguientes
cuatro capas:

Subsistema. Contiene una representacin de cada uno de los subsistemas

que le permiten al software conseguir los requisitos definidos por el cliente e
implementar la infraestructura tcnica que los soporta.
Clases y Objetos. Contiene las jerarquas de clases que permiten crear el
sistema utilizando generalizaciones y especializaciones mejor definidas
incrementalmente. Tambin contiene representaciones de diseo para cada
objeto.
Mensajes. Contiene los detalles que permiten a cada objeto comunicarse
con sus colaboradores. Establece las interfaces externas e internas para el
sistema.
Responsabilidades. Contiene las estructuras de datos y el diseo
algortmico para todos los atributos y operaciones de cada objeto.

Todo el programa est construido en base a diferentes componentes (Objetos),

todo objeto del mundo real tiene 2 componentes: caractersticas y
comportamiento.
Una clase es una plantilla genrica para un conjunto de objetos de similares
caractersticas.
La herencia bsicamente consiste en que una clase puede heredar sus variables y
mtodos a varias subclases.

97

Por ejemplo:
Los mensajes son invocaciones a los mtodos de los objetos.
Esta es una tcnica de diseo, la cual se caracteriza por la determinacin y
delegacin de responsabilidades.

Anlisis orientado a objetos

El modelo del anlisis orientado a objetos ilustra informacin, funcionamiento y
comportamiento.
El diseo orientado a objetos transforma el modelo del anlisis en un modelo de
diseo que sirve como anteproyecto para la construccin de software.

Modelos del diseo

Estticos. Estructura de subsistemas y/o clases y sus relaciones.

Dinmicos. Se describen las estructuras que muestran la interaccin entre
objetos. Ejemplos de UML: diagramas de secuencia, diagramas de estado.

Son soluciones simples y elegantes a problemas especficos y comunes del

diseo orientado a objetos. Son soluciones basadas en la experiencia y que se ha
demostrado que funcionan.
Tipos: de creacin, estructurales, de comportamiento.

Bibliografa 1:

http://oscarhdeztorresunidad4.blogspot.mx/

98

4.2 DISEO DE OBJETOS.

Para los sistemas es posible definir un diseo en pirmide con las siguientes
cuatro capas:

Subsistema. Contiene una representacin de cada uno de los subsistemas

que le permiten al software conseguir los requisitos definidos por el cliente e
implementar la infraestructura tcnica que los soporta.
Clases y Objetos. Contiene las jerarquas de clases que permiten crear el
sistema utilizando generalizaciones y especializaciones mejor definidas
incrementalmente. Tambin contiene representaciones de diseo para cada
objeto.
Mensajes. Contiene los detalles que permiten a cada objeto comunicarse
con sus colaboradores. Establece las interfaces externas e internas para el
sistema.
Responsabilidades. Contiene las estructuras de datos y el diseo
algortmico para todos los atributos y operaciones de cada objeto.

Todo el programa est construido en base a diferentes componentes (Objetos),

todo objeto del mundo real tiene 2 componentes: caractersticas y
comportamiento. Una clase es una plantilla genrica para un conjunto de objetos
de similares caractersticas.
Por ejemplo: Esta es una tcnica de diseo, la cual se caracteriza por la
determinacin y delegacin de responsabilidades.
Anlisis orientado a objetos
El modelo del anlisis orientado a objetos ilustra informacin, funcionamiento y
comportamiento. El diseo orientado a objetos transforma el modelo del anlisis
en un modelo de diseo que sirve como anteproyecto para la construccin de
software.
Modelos del diseo

Estticos. Estructura de subsistemas y/o clases y sus relaciones.

Dinmicos. Se describen las estructuras que muestran la interaccin entre
objetos. Ejemplos de UML: diagramas de secuencia, diagramas de estado.

Son soluciones simples y elegantes a problemas especficos y comunes del

diseo orientado a objetos. Son soluciones basadas en la experiencia y que se ha
demostrado que funcionan.
Tipos: de creacin, estructurales, de comportamiento.
Bibliografa 2:
http://unudad1conceptos.blogspot.mx/2013/05/unidad4.html

99

4.3 DISEO DE SISTEMA.

Lenguajes de programacin.
Es importante sealar que un diseo orientado a objetos no necesariamente se
tiene que implementar mediante un lenguaje orientado a objetos. Sin embargo, es
ms natural hacerlo de esta manera. Esto es debido a que los lenguajes
orientados a objetos tienen un apoyo directo a los conceptos del anlisis orientado
a objetos (encapsulamiento, generalizacin, polimorfismo).
Sin embargo, se puede traducir cualquier concepto o mecanismo orientado a
objetos a otros existentes en los lenguajes no orientados a objetos. El problema
con este tipo de lenguajes es su conveniencia, mantenimiento y proteccin contra
errores. Un lenguaje orientado a objetos hace que la escritura, mantenimiento y
extensin de los programas sea ms fcil y segura.
Cabe mencionar que no todos los lenguajes de programacin orientados a objetos
implementan de la misma forma los conceptos de la metodologa orientada a
objetos. Aspectos como manejo de encapsulamiento, referencias, herencia
mltiple varan de manera importante entre los lenguajes de programacin.
Interfaces grficas.
Las interfaces grficas tienen como objetivo principal administrar la interaccin
entre el usuario mediante elementos grficos, como son botones, mens y textos.
Las aplicaciones interactivas donde el control del ratn y teclado desempean un
papel importante se conocen como sistemas controlados o dirigidos por eventos.
Estos eventos comprenden: mover el ratn, oprimir uno de sus botones, oprimir
una tecla, etc.
Bases de datos.
Las bases de datos son fundamentales en los sistemas de informacin. Una
decisin estratgica importante en tal contexto es si debe utilizar bases de datos
relacionales u orientados a objetos. En general se consideran tres modelos de
bases de datos principales:

Modelo relacional: se define una coleccin de tablas donde cada una tiene
un nmero especfico de columnas y un nmero arbitrario de filas. Cada
objeto se representa como una fila en una tabla y donde cada columna
corresponde a un atributo distinto en el objeto.
Modelo relacional extendido: el modelo relacional se extiende mediante
procedimientos, objetos, versiones y otras nuevas capacidades. No hay un
solo modelo relacional extendido, ms bien hay una variedad de ellos,
aunque todos comparten las tablas y consultas bsicas del modelo
relacional.

100

Modelo orientado a objetos: se define un modelo orientado a objetos donde

vara el tipo de encapsulamiento de datos y los procedimientos en el objeto.
El trmino orientado a objetos vara segn cada autor Las bases de datos
son depsitos de datos guardados en uno o ms archivos.

Archivos.
Aunque es ms efectivo trabajar con bases de datos, es posible utilizar archivos,
sobre todo cuando la especificacin del sistema as lo requiera. En el caso de usar
una base de datos, regularmente una clase se comunica con el DBMS para hacer
solicitudes a cualquier tabla.

Bibliografa 1:

http://oscarhdeztorresunidad4.blogspot.mx/

4.3 DISEO DEL SISTEMA.

Sin duda, realizar de manera adecuada cada una de las actividades que conlleva
la Ingeniera del Software es indispensable para la realizacin de un proyecto
software de calidad. Por lo tanto, no se puede decir que ninguna de estas
actividades sea ms importante que otra. Sin embargo, si podemos decir que la
actividad de diseo es la ms delicada y la ms laboriosa de llevar a cabo.
Es delicada porque si no se lleva a cabo correctamente se hace imposible el
codificar, de manera correcta, en la actividad de implementacin el modelo
obtenido en el anlisis del sistema, lo que puede repercutir en el desperdicio de
todo el esfuerzo realizado durante las primeras actividades de la Ingeniera del
Software.
Y es laboriosa porque las estrategias a seguir para conseguir que esta traduccin
entre modelo y cdigo se lleve a cabo correctamente son muy diversas y bastante
complejas.
Se puede decir, por tanto, que el diseo del sistema es la actividad de la
Ingeniera del Software en la que se identifican los objetivos finales del sistema y
se plantean las diversas estrategias para alcanzarlos en la actividad de
implementacin.
Sin embargo, el sistema no se suele disear de una sola vez sino que hay que
diferenciar entre el diseo y estructura de los datos que se van a manejar y el
diseo de la interfaz entre la aplicacin y el usuario. Estas dos fases del diseo no
se realizan de forma consecutiva una detrs de la otra sino que lo normal es
realizarlas de manera concurrente y finalizarlas a la vez.

101

La intencin de esta fase del diseo software es determinar la estructura que

poseen cada uno de los elementos de informacin del sistema, es decir, la
estructura de los datos sobre los que va a trabajar. Estos elementos son:

Las pelculas, de las que conocemos su nombre, su ano de produccin, su

fecha de estreno, el/los gneros a los que se adscribe y la URL de su
entrada en IMDB.
Los usuarios, de los que conocemos su edad, si es hombre o mujer, a que
se dedica y su cdigo postal adems de su identificador del sistema y el
nmero de pelculas que ha puntuado.
Las puntuaciones, de las que conocemos el usuario que las hace, las
pelculas que las reciben y, obviamente, el valor numrico de las mismas.
Las pelculas alquiladas por los usuarios pero todava no puntuadas.

Una vez determinados cuales son los elementos de informacin del sistema, se
deben obtener sus representaciones en forma de tablas de una base de datos.
Para ello, se debe realizar primeramente un diseo conceptual de la base de datos
para, posteriormente, obtener las tablas requeridas. Para realizar este diseo
conceptual se utilizara el modelo Entidad-Relacin.

Modelo Entidad-Relacin

El modelo Entidad-Relacin (tambin conocido por sus iniciales: E-R) es una

tcnica de modelado de datos que utiliza diagramas entidad-relacin. No es la
nica tcnica de modelado pero si es la ms extendida y utilizada.
Un diagrama entidad-relacin est compuesto por tres tipos de elementos
principales:

Entidades: objetos (cosas, conceptos o personas) sobre los que se tiene

informacin. Se representan mediante rectngulos etiquetados en su
interior con un nombre. Una instancia es cualquier ejemplar concreto de
una entidad.
Relaciones: interdependencias entre uno o ms entidades. Se representan
mediante rombos etiquetados en su interior con un verbo. Si la relacin es
entre una entidad consigo mismo se denomina reflexiva, si es entre dos
entidades se denomina binaria, ternaria si es entre tres y mltiple si es entre
ms (muy raro).
Atributos: caractersticas propias de una entidad o relacin. Se
representan mediante elipses etiquetados en su interior con un nombre.

102

En los diagramas entidad-relacin tambin hay que tener en cuenta otros aspectos
como pueden ser:

Entidades dbiles: son aquellas que no se pueden identificar

unvocamente solo con sus atributos, es decir, necesitan de estar
relacionadas con otras entidades para existir. Se representan con dos
rectngulos concntricos de distinto tamao con un nombre en el interior
del ms pequeo.
Cardinalidad de las relaciones: existen tres tipos de cardinalidades de
una relacin segn el nmero de instancias de cada entidad que involucren:
Uno a uno: una instancia de la entidad A se relaciona solamente con una
instancia de la entidad B. (1:1)
Uno a muchos: cada instancia de la entidad A se relaciona con varias de la
entidad B. (1:*)
Muchos a muchos: cualquier instancia de la entidad A se relaciona con
cualquier instancia de la entidad B. (*:*)
Claves: cada entidad de un diagrama entidad-relacin debe tener una
clave, debe estar formada por uno o ms de sus atributos.

Una vez conocidos los elementos que forman parte de un diagrama entidadrelacin podemos empezar a desarrollar el modelo entidad-relacin. Los pasos a
seguir son los siguientes:

Convertir el enunciado del problema (o, como es nuestro caso, los

elementos del sistema software) en un Esquema Conceptual del mismo.
Convertir este Esquema Conceptual (o EC) en uno ms refinado conocido
como esquema Conceptual Modificado (ECM).
Obtener las tablas de la base de datos a partir del Esquema Conceptual
Modificado.

Bibliografa 2:

http://unudad1conceptos.blogspot.mx/2013/05/unidad4.html

103

4.4 REVISIN DEL DISEO.

Es una herramienta que fue desarrollada sobre la base de la filosofa de que los
problemas de diseo se producen cuando se realizan cambios en los diseos de
ingeniera existentes que ya han sido probados con xito.
En ingeniera de software, una revisin estructurada es una forma de revisin de
software por colegas en la cual un diseador o programador lidera a los miembros
de un equipo de desarrollo y otra de las partes involucradas a travs de un
producto de software, y los participantes hacen preguntas y comentarios acerca de
posibles errores, violacin de estndares de desarrollo, y otros problemas.
El "producto de software" normalmente se refiera a un tipo de documento tcnico.
Tal como es indicado por la definicin de la IEEE, esto puede ser un documento
de diseo de software o cdigo fuente de un programa, pero tambin casos de
uso, definiciones del proceso de negocios, especificaciones de casos de prueba y
una variedad de otra documentacin tcnica tambin puede ser revisada.
Una revisin estructurada difiere de una revisin de software tcnica en la forma
abierta de su estructura y su objetivo de familiarizacin.

Bibliografa 1:

http://oscarhdeztorresunidad4.blogspot.mx/

4.4.- REVISIN DE DISEO.

Durante la revisin del diseo, se comprobar que se trabaja segn los requisitos
iniciales y cumpliendo las normas y estndares que hayan sido programados con
respecto a:

Gestin de contraseas.
Gestin de perfiles de usuario de la aplicacin.
Registro de accesos.
Funcionalidad definida para los distintos mdulos de trabajo.

Para verificar el diseo y con ello comprobar su correcto funcionamiento, se

efectuar el plan de pruebas. Este consistir en sucesivas entradas de datos en
diferentes situaciones, es decir, tanto situaciones rutinarias con operaciones
comunes como acciones ms complejas.

104

De su resultado se verificar el diseo del software o, por el contrario, en caso de

ser necesario se integrarn nuevos componentes y nuevas funcionalidades para
que el software tenga el rendimiento esperado.
Para un mejor control de las aplicaciones y siempre buscando la mejora continua
de esta fase, se emplear el Documento de Cambios donde se recoger
informacin delas distintas tipologas de las modificaciones a efectuar para que
sirva de retroalimentacin para futuros cambios.

Las inspecciones de software surgen a partir de la necesidad de producir software

de alta calidad
Algunos grupos de desarrollo creen que la calidad del software es algo en lo que
deben preocuparse una vez que se ha generado el cdigo. Error La garanta de
la calidad del software es una actividad de proteccin que se aplica a lo largo de
todo el proceso de ingeniera de software La SQA (Software QualityAssurance)
engloba:

Un enfoque de gestin de calidad

Tecnologa de Ingeniera de Software efectiva (mtodos y
herramientas)
Revisiones tcnicas formales que se aplican durante el proceso del
software
Una estrategia de prueba multiescalada
Un control de la documentacin del software y de los cambios
realizados
Un procedimiento que asegure un ajuste a los estndares de
desarrollo de software
Mecanismos de medicin y de generacin de informes

El control de la calidad es una serie de revisiones, y pruebas utilizados a los largo

del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos
que le han sido asignados.

Bibliografa 2:

http://unudad1conceptos.blogspot.mx/2013/05/unidad4.html

105

4.5 DIAGRAMAS DE SECUENCIAS DEL DISEO.

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin
entre objetos en un sistema.
Utilidad.
Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en
una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras
que permite el modelado de una vista business del escenario, el diagrama de
secuencia contiene detalles de implementacin del escenario, incluyendo los
objetos y clases que se usan para implementar el escenario y mensajes
intercambiados entre los objetos.
Tpicamente se examina la descripcin para determinar qu objetos son
necesarios para la implementacin del escenario. Si se dispone de la descripcin
de cada caso de uso como una secuencia de varios pasos, entonces se puede
"caminar sobre" esos pasos para descubrir qu objetos son necesarios para que
se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que
intervienen en el escenario con lneas discontinuas verticales, y los mensajes
pasados entre los objetos como flechas horizontales.
Tipos de mensajes.
Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes
sincrnicos se corresponden con llamadas a mtodos del objeto que recibe el
mensaje. El objeto que enva el mensaje queda bloqueado hasta que termina la
llamada. Este tipo de mensajes se representan con flechas con la cabeza llena.
Los mensajes asincrnicos terminan inmediatamente, y crean un nuevo hilo de
ejecucin dentro de la secuencia. Se representan con flechas con la cabeza
abierta.
Tambin se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas:

De instancia: describe un escenario especfico (un escenario es una

instancia de la ejecucin de un caso de uso).
Genrico: describe la interaccin para un caso de uso; Utiliza
ramificaciones.

Estructura.
Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a
la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el

106

anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un

mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre
'business' es reemplazado con el nombre del mtodo que est siendo llamado por
un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la
clase instan ciada por el objeto en la recepcin final del mensaje.

Bibliografa 1:

http://oscarhdeztorresunidad4.blogspot.mx/

4.5.- DIAGRAMAS DE SECUENCIA DE DISEO.

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin
entre objetos en un sistema segn UML. En ingls se pueden encontrar como
"sequencediagram", "event-trace diagrams", "eventscenarios" o "timing diagrams"

Utilidad
Un diagrama de casos de uso muestra la interaccin de un conjunto de objetos en
una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras
que el diagrama de casos de uso permite el modelado de una vista business del
escenario, el diagrama de secuencia contiene detalles de implementacin del
escenario, incluyendo los objetos y clases que se usan para implementar el
escenario y mensajes intercambiados entre los objetos.
Tpicamente se examina la descripcin de un caso de uso para determinar qu
objetos son necesarios para la implementacin del escenario. Si se dispone de la
descripcin de cada caso de uso como una secuencia de varios pasos, entonces
se puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios
para que se puedan seguir los pasos. Un diagrama de secuencia muestra los
objetos que intervienen en el escenario con lneas discontinuas verticales, y los
mensajes pasados entre los objetos como flechas horizontales.
Tipos de mensajes
Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes
sincrnicos se corresponden con llamadas a mtodos del objeto que recibe el
mensaje. El objeto que enva el mensaje queda bloqueado hasta que termina la
llamada. Este tipo de mensajes se representan con flechas con la cabeza llena.
Los mensajes asincrnicos terminan inmediatamente, y crean un nuevo hilo de

107

ejecucin dentro de la secuencia. Se representan con flechas con la cabeza

abierta.
Tambin se representa la respuesta a un mensaje con una flecha discontinua.
Pueden ser usados en dos formas
De instancia: describe un escenario especfico (un escenario es una instancia de
la ejecucin de un caso de uso).

Genrico: describe la interaccin para un caso de uso; Utiliza ramificaciones

("Branches"), condiciones y bucles.
Estructura
Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a
la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el
anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un
mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre
'business' es reemplazado con el nombre del mtodo que est siendo llamado por
un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la
clase instanciada por el objeto en la recepcin final del mensaje.
Bibliografa 2:

http://unudad1conceptos.blogspot.mx/2013/05/unidad4.html

4.6 HERRAMIENTAS CASE PARA EL DISEO DEL SOFTWARE.

Las computadoras afectan nuestras vidas nos guste o no. Utilizamos
computadoras en nuestra vida diaria, la mayor parte del tiempo sin reconocer
conscientemente
que
estamos hacindolo.
Las
utilizamos
en
aplicaciones domsticas como microondas, televisin, vdeo caseteras o fuera de
nuestras casas en mquinas para tarjetas de crdito, por ejemplo. La verdad es
que no podemos escapar de las computadoras. El rpido incremento en
performance de las computadoras junto al dramtico decremento en tamao y
costo, dio como resultado una explosin de tecnologa, generndose una larga
variedad de aplicaciones que stas pueden soportar. Desde el inicio de la escritura
de software, ha existido un conocimiento de la necesidad de herramientas
automatizadas para ayudar al diseador del software. Inicialmente, la
concentracin estaba en herramientas de apoyo a programas como traductores,
recopiladores, ensambladores, procesadores de macros, y montadores
y cargadores. Este conjunto de aplicaciones que pueden informatizarse, aument
dramticamente en un breve espacio de tiempo, causando una gran demanda por
nuevo software a desarrollar. A medida que se escriba nuevo software, haban ya
en existencia millones y millones de lneas de cdigo que necesitaban se
mantenidas y actualizadas.

108

Que son las herramientas

Se puede definir a las Herramientas CASE como un conjunto de programas y

ayudas que dan asistencia a los analistas, ingenieros de software
y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un
Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de
un Software son: Investigacin Preliminar, Anlisis, Diseo, Implementacin e
Instalacin. CASE se define tambin 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. Una innovacin en la organizacin, un concepto avanzado en la
evolucin de tecnologa con un potencial efecto profundo en la organizacin. Se
puede ver al
CASE como la unin de las herramientas automticas de software y
las metodologas de desarrollo de software formales.
La realizacin de un nuevo software requiere que las tareas sean organizadas
y completadas en forma correcta y eficiente. Las Herramientas CASE
fueron desarrolladas para automatizar esos procesos y facilitar las tareas de
coordinacin de los eventos que necesitan ser mejorados en el ciclo de desarrollo
de software.
La mejor razn para la creacin de estas herramientas fue el incremento en
la velocidad de desarrollo de los sistemas. Por esto, las compaas pudieron
desarrollar sistemas sin encarar el problema de tener cambios en las necesidades
del negocio, antes de finalizar el proceso de desarrollo. Tambin permite a las
compaas
competir
ms efectivamente
usando
estos
sistemas
desarrollados nuevamente para compararlos con sus necesidades de negocio
actuales. En un mercado altamente competitivo, esto puede hacer la diferencia
entre el xito y el fracaso. Las herramientas CASE tambin permiten a los
analistas tener ms tiempo para el anlisis y diseo y minimizar el tiempo para
codificar y probar. La introduccin de CASE integradas est comenzando a tener
un impacto significativo en los negocios y sistemas de informacin de las
organizaciones.

109

Con
un
CASE
integrado,
las
organizaciones
pueden
desarrollar
rpidamente sistemas de mejor calidad para soportar procesos crticos del negocio
y asistir en el desarrollo y promocin intensiva de la informacin de productos y
servicios. Estas herramientas pueden proveer muchos beneficios en todas las
etapas del proceso de desarrollo de software, algunas de ellas son:

Verificar el uso de todos los elementos en el sistema diseado.

Automatizar el dibujo de diagramas.
Ayudar en la documentacin del sistema.
Ayudar en la creacin de relaciones en la Base de Datos.
Generar estructuras de cdigo.

La principal ventaja de la utilizacin de una herramienta CASE, es la mejora de

la calidad de los desarrollos realizados y, en segundo trmino, el aumento de
la productividad. Para conseguir estos dos objetivos es conveniente contar con
una organizacin y una metodologa de trabajo, adems de la propia
herramienta. La mejora de calidad se consigue reduciendo sustancialmente
muchos de los problemas de anlisis y diseo, inherentes a los proyectos de
mediano y gran tamao (lgica del diseo, coherencia, consolidacin, etc.). La
mejora de productividad se consigue a travs de la automatizacin de
determinadas tareas, como la generacin de cdigo y la reutilizacin de objetos o
mdulos.

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. Las herramientas CASE, en funcin de las fases
del ciclo de vida abarcadas, se pueden agrupar

Bibliografa 1:

http://unudad1conceptos.blogspot.mx/2013/05/unidad4.html

110

4.6 HERRAMIENTAS CASE PARA EL DISEO.

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. Para mejorar la calidad y la productividad de los sistemas de
informacin a la hora de construir software se plantean los siguientes objetivos:
Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser
realizadas con una herramienta conseguimos 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 potabilidad de las aplicaciones.
Facilitar la re utilizacin de componentes software.
Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la
utilizacin de grficos.

Bibliografa 2:

http://oscarhdeztorresunidad4.blogspot.mx/

CONCLUSIN.
En conclusin se puede decir que el modelo de diseo dentro de lo que es la
ingeniera de requisitos es una etapa fundamental ya que en ella es donde
bsicamente se modela lo que es el proyecto a desarrollar y tambin se modela lo
que es el prototipo del sistema a desarrollar.
En esta unidad tambin se muestra la utilizacin de algunas herramientas CASE
las cuales son de gran utilidad al momento de desarrollar lo que es nuestro
modelo de diseo en el cual se va mostrando poco a poco el progreso general de
nuestro proyecto ya que en ella tambin se muestra lo que es el modelado de
diseo, revisin de diseo, diagramas de secuencias de diseo.
Ms que nada esto es un enfoque ms prctico de la versin grafica que tendr
nuestro proyecto es donde, como su nombre lo dice se har el diseo practico del
proyecto a desarrollar establecido con las especificaciones de nuestro cliente en
particular.

111

UNIDAD 5. MODELO IMPLEMENTACIN

INTRODUCCIN
La etapa de implementacin del desarrollo de software es el proceso de convertir
una especificacin del sistema en un sistema ejecutable. Siempre implica los
procesos de diseo y programacin de software, pero si se utiliza un enfoque
evolutivo de desarrollo, tambin puede implicar un refinamiento de la
especificacin del software.
Un diseo de software es una descripcin de la estructura del software que se va
a implementar, los datos que son parte del sistema, las interfaces entre los
componentes del sistema y algunas veces los algoritmos utilizados. Los
diseadores no llegan inmediatamente a un diseo detallado, sino que lo
desarrollan de manera iterativa a travs de diversas versiones. El proceso de
diseo conlleva agregar formalidad y detalle durante el desarrollo del diseo y
regresar a los diseos anteriores para corregirlos.
EL proceso de diseo puede implicar el desarrollo de varios modelos del sistema
con diferentes niveles de abstraccin. Mientras se descompone un diseo se
descubren errores y omisiones de las etapas previas. Esta retroalimentacin
permite mejorar los modelos de diseo previos.
Una especificacin para la siguiente etapa es la salida de cada actividad de
diseo. Esta especificacin puede ser abstracta y formal, realizada para clarificar
los requerimientos o puede ser una especificacin para determinar que parte del
sistema se va a construir. Durante todo el proceso de diseo, se detalla cada vez
ms esta especificacin.
El proceso es el conocimiento incorporado, y puesto que el conocimiento esta
inicialmente disperso, el desarrollo de software implcito, latente e incompleto en
gran medida es un proceso social de aprendizaje. El proceso es un dialogo en el
que se rene el conocimiento y se incluye en el software para convertirse en
software. El proceso proporciona una iteracin entre los usuarios y los
diseadores, entre los usuarios y las herramientas de desarrollo, y entre los
diseadores y las herramientas de desarrollo (tecnologa). Es un proceso
interactivo donde la herramienta de desarrollo se usa como medio de
comunicacin, con cada iteracin del dialogo se obtiene mayor conocimiento.
El ciclo de vida y los procesos
Todo proyecto tiene asociado, por ms pequeo que ste sea, pasos que se
deben seguir tales como: planificacin, estimacin de recursos, seguimiento y
control, y evaluacin del proyecto. La seleccin de un modelo de ciclo de vida est
asociada a un orden en la realizacin de las actividades a desarrollar.

112

La red de actividades, es la que permitir establecer a partir de la matriz de

precedencia el camino crtico, como la secuencia de tareas ms larga de principio
al fin.
El diagrama de Gantt, o los diagramas calendario permitirn establecer el estado
del proyecto en un determinado momento a partir de su inicio, en cuanto a
recursos se refiere.
Para estimar el tamao del producto o del programa a desarrollar, definido como la
cantidad de cdigo fuente, especificaciones, casos de prueba, documentacin del
usuario y otros productos, que han de ser desarrollados, se debe recurrir a datos
estadsticos propios o no. La estimacin consiste en la prediccin del personal, el
esfuerzo y el costo asociado para llevar a cabo todas las actividades del mismo.
Incluye las actividades de:

Investigacin preliminar.
Determinacin de requerimientos.
Diseo del sistema.
Desarrollo de software.
Pruebas del sistema.
Implementacin y evaluacin.
Sus caractersticas son:

Requerimientos del sistema de informacin son impredecibles.

Es manejable como un proyecto.
Requiere que los datos se encuentren en archivos o bases de datos.
Abarca varios departamentos.
Su tiempo de desarrollo es largo.
Es adecuado para todo tipo de aplicacin.
Un prototipo, es un modelo a escala de lo que puede ser realmente, pero no
equivalente a lo que puede ser realmente el producto final, dado que no siempre
cuenta con las funciones del sistema final, pero permite la retroalimentacin por
parte de los usuarios acerca del sistema.
El prototipo de sistemas, permite el desarrollo iterativo o bien la contina
evolucin, en donde el usuario participa directamente en el proceso de desarrollo
del mismo.

113

5.1 DIAGRAMA DE COMPONENTES

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de
Modelado. Un diagrama de componentes representa cmo un sistema
de software es dividido en componentes y muestra las dependencias entre estos
componentes.
Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas,
mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en
el campo de la arquitectura de software pero pueden ser usados para modelar y
documentar cualquier arquitectura de sistema
Un diagrama de componentes representa cmo un sistema de software es dividido
en componentes y muestra las dependencias entre estos componentes.
Los componentes fsicos incluyen algunos archivos, cabeceras, bibliotecas
compartidas, mdulos, ejecutables, o paquetes. Los diagramas de Componentes
prevalecen en el campo de la arquitectura de software pero pueden ser usados
para modelar y documentar cualquier arquitectura de sistema.

Debido a que los diagramas de componentes son ms parecidos a los diagramas

de casos de usos, stos son utilizados para modelar la vista esttica y dinmica de
un sistema. Muestra la organizacin y las dependencias entre un conjunto de
componentes. No es necesario que un diagrama incluya todos los componentes
del sistema, normalmente se realizan por partes. Cada diagrama describe un
apartado del sistema.
Es un acercamiento basado en la re utilizacin para definir, implementar, y
componer, componentes dbilmente acoplados en sistemas. Un componente de
software individual es un paquete de software, un servicio web, o
un mdulo que encapsula un conjunto de funciones relacionadas (o de datos).
Debido a este principio, con frecuencia se dice que los componentes son
modulares y cohesivos. Estas interfaces pueden ser vistas como una firma del
componente - el cliente no necesita saber sobre los funcionamientos internos del
componente (su Implementacin para hacer uso de ella. Este principio resulta en
componentes referidos como encapsulados Tiene como objetivo convertir el
diseo de datos, Interfaces y arquitectura en una representacin Intermedia que
se pueda transformar fcilmente en cdigo fuente. El nivel de abstraccin debe
ser muy prximo al Cdigo.

114

Programacin estructurada
Notaciones de diseo
Notaciones grficas
Notaciones tabulares
Lenguaje de diseo de programas
Referencias bibliogrficas

Programacin estructurada es una de las tcnica de diseo procedimental ms

Importantes. Se trata de un conjunto de construcciones con las que Se puede
restringir el diseo procedimental de un Software a un nmero de operaciones
predecibles. Tipos de construcciones estructuradas: secuenciales, Condicionales y
repetitivas.
Bibliografa : http://es.slideshare.net/jasc_584/ingenieriadesoftwareiansommerville7maedicion

5.1 DIAGRAMA DE COMPONENTES

En el diseo al nivel de componentes se presenta despus de que se han
planteado la primera iteracin del diseo arquitectnico. En esta etapa ya se han
establecido los datos generales y la estructura del programa. El objetivo es
traducir el mtodo de diseo en un software operacional. Pero el grado de
abstraccin del mtodo de diseo existente es relativamente elevado, y del
programa operacional, bajo. La traduccin llega a ser desafiante abriendo la
puerta para el ingreso de errores sutiles que resultan difciles de encontrar y
corregir en etapas posteriores del proceso de software.
Un diagrama de componentes es un conjunto de componentes de software que se
define durante el diseo arquitectnico, pero las estructuras de datos internas y el
procesamiento de detalles de cada componente no se represent6an en un grado
de abstraccin parecido al cdigo.
El diseo al nivel de componentes se define las estructuras de datos, los
algoritmos, las caractersticas de la interfaz y los mecanismos de comunicacin
asignados a cada componente de software.
Antes de construir el software debe de tener la capacidad de determinar si
funciona bien. El diseo al nivel de componentes representa el software de tal
manera que permite revisar si los detalles del diseo son correctos y consistentes
con las representaciones iniciales del diseo. Proporciona una manera de evaluar
si funcionaran las estructuras las interfaces y los algoritmos.

115

Las representaciones al nivel de diseos de datos, arquitectura e interfaces

representan la base del diseo al nivel de componentes. La definicin de clase o la
narrativa de procedimiento de cada componente se traducen en un diseo
detallado que usa diagramas o formas de texto que especifican estructuras de
datos internas, detalle de la interfaz local y lgica de procesamiento.
La notacin de diseo abarca diagramas UML y representaciones
complementarias. El diseo procedimental se especifica mediante un conjunto de
construcciones de programacin estructurada.
Un componente es un bloque de construccin modular para el software de
cmputo. De manera ms formal, la especificacin unificada de lenguaje de
modelo OMG define un componente como una parte modular desplegable y
reemplazable de un sistema que encapsula implementacin y expone un conjunto
de interfaces.
Como ya se ha observado el diseo al nivel de componentes
se basa en
informacin desarrollara como parte del modelo de anlisis y representa como
parte del modelo arquitectnico. Cuando se elige un mtodo de ingeniera de
software basado en componentes, el diseo al nivel de estos se concentra en la
elaboracin de las clases de anlisis y la definicin y la afinacin de las clases de
infraestructura. La descripcin detallada de los atributos, las operaciones y las
interfaces empleados por estas clases representa el detalle de diseo requerido
como un precursor de la actividad de construccin.

El principio abierto-cerrado: Esta frase parece ser una contradiccin pero

representa una de las caractersticas ms importantes de un buen diseo al nivel
de componentes. Para expresarlo de manera simple, el diseador debe de
especificar el componente de manera que permita extenderlo sin necesidad de
modificaciones internas al propio componente. Para ello el diseador crea
abstracciones que sirven como memoria intermedia entre la funcionalidad que tal
vez habr de entenderse y la propia clase de diseo.

Principio de sustitucin de Liskov: este principio de diseo que originalmente

propuso Brbara Liskov sugiere que un componente que use una clase principal
debe seguir funcionando apropiadamente si, en cambio se pasa al componente de
una clase derivada.
Principio de inversin de la dependencia: Como hemos visto en el anlisis de
principio de sustitucin de Liskov, las abstracciones son el lugar donde un diseo
se puede extender sin grandes complicaciones. Cuando ms depende un
componente de otros componentes concretos, ser ms difcil extenderlos.

116

Principio de segregacin de la interfaz:

Hay muchos casos en que varios componentes de cliente usan las operaciones
proporcionadas por una clase de servidor. El PSI sugiere que el diseador debe
de crear una interfaz especializada para servir a cada categora importante de
cada cliente. Solo las operaciones importantes para una categora especial de
clientes deben especificarse en la interfaz para esos clientes.
Si varios clientes necesitan las mismas operaciones deben especificarse en cada
una de las interfaces especializadas.

Bibliografa: http://es.slideshare.net/yvan66/11-modelos-segn-roger-s

5.2 DIAGRAMA DE DESPLIEGUE

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de
Modelado que se utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como
un prisma), componentes (representados como una caja rectangular con dos
protuberancias del lado izquierdo) y asociaciones.
El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de
Modelado que se utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos (representados como
un prisma), componentes (representados como una caja rectangular con dos
protuberancias del lado izquierdo) y asociaciones.
En el UML 2.0 los componentes ya no estn dentro de nodos. En cambio, puede
haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos
tambin aadir que no van a existir actores para relacionarse con los nodos (no es
un diagrama de casos de uso) si no que las relaciones que pueda haber
siempre sern entre los nodos y por ejemplo con una base de datos.
Usos
Algunos de los usos que se les da a los diagramas de despliegue son para
modelar:

Sistemas empotrados: Un sistema empotrado es una coleccin de hardware con

una gran cantidad de software que interacta con el mundo fsico.

117

Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del

espectro de los sistemas distribuidos y requieren tomar decisiones sobre la
conectividad de red de los clientes a los servidores y sobre la distribucin fsica de
los componentes software del sistema a travs de nodos.

Sistemas completamente distribuidos: En el otro extremo encontramos aquellos

sistemas que son ampliamente o totalmente distribuidos y que normalmente
incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias
versiones de componentes software, alguno de los cuales pueden incluso migrar
de un nodo a otro. El diseo de tales sistemas requiere tomar decisiones que
permitan un cambio continuo de la topologa del sistema.
Bibliografa :
http://es.slideshare.net/jasc_584/ingenieriadesoftwareiansommerville7maedicion

5.2 DIAGRAMA DE DESPLIEGUE

El diagrama de despliegue se utiliza para la arquitectura fsica sobre la que un

sistema de software es desplegado. Por tanto describe tanto a los dispositivos
fsicos como a los elementos de software
Un diagrama de despliegue cuenta con elementos como son el nodo artefacto y
despliegue.

Nodo
Dispositivo
o Entorno de ejecucin
Artefacto
Despliegue
o

Nodo: El nodo tiene sus entidades fiscas o software que son capaces de ejecutar
artefactos.
Artefacto: El artefacto es una pieza de informacin relacionada con el proceso de
desarrollo software:

Ejecutable
Manual de usuario
Script de BD
DDL

118

Despliegue: El despliegue es una relacin entre uno o ms artefactos y el o los

nodos donde estos se estn ejecutando.
Entorno de ejecucin v artefacto: Un mismo elemento dependiendo del punto de
vista puede ser considerado como un entorno de ejecucin o un artefacto.
Artefacto v componente: Los diagramas de componente y despliegue estn
relacionados entre s mediante componentes y artefactos.
Un artefacto manifiesta o implementa un componente.
Bibliografa: http://es.slideshare.net/yvan66/11-modelos-segn-roger-s

5.3 MODELOS DE PRUEBA

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.
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.
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 y Actualmente, existe un amplio nmero de
propuestas que describen cmo generar pruebas del sistema a partir de los casos
de uso.
Aunque la generacin de pruebas se adapta a la filosofa propuesta por MDA, tal
y como mostraremos a continuacin, ninguna de estas propuestas define su
proceso en base a las tcnicas de MDA. Por este motivo, una de las principales
carencias es la falta de modelos que recojan la informacin necesaria en el
proceso de generacin de pruebas.

119

Modelos de requisitos
Los nicos modelos de requisitos necesarios son los casos de uso y los requisitos
de almacenamiento, aunque otros modelos, como por ejemplo modelos de
interfaces o modelos de navegacin pueden enriquecer el proceso de prueba.
Actualmente existen varias propuestas de modelos de requisitos.
Modelo de interaccin
Una vez que se conocen las interfaces con las que las pruebas interactuarn,
expresadas mediante el modelo de interfaz abstracta, se refina el modelo de
comportamiento para indicar cmo realizar cada uno de los pasos del caso de uso
sobre dicha interfaz.
Modelo de comportamiento
Un gran nmero de tcnicas de requisitos estn basadas en casos de uso
definidos en prosa. Uno de ellos es el modelo WebRE utilizado en el punto
anterior. Pero no es sencillo manipular programticamente casos de uso escritos
en prosa. Por este motivo, el primer paso de nuestro proceso sistemtico de
generacin de pruebas consiste en expresar dicha prosa mediante un modelo
formal manipulable de manera automtica.
Modelo de datos de prueba
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.
Modelo de interfaz abstracta
Los modelos anteriores nos indican lo que una prueba debe hacer (ejecutar un
escenario posible de un caso de uso), qu informacin hay que suministrarle y qu
informacin nos va a devolver. Sin embargo estos modelos an son demasiado
abstractos y no se pueden convertir en modelos dependientes de la plataforma ni
en pruebas ejecutables de manera directa. Por este motivo, a partir de los
modelos anteriores, se obtienen los modelos de interfaz abstracta y de interaccin.

Bibliografa : http://es.slideshare.net/jasc_584/ingenieriadesoftwareiansommerville7maedicion

120

5.3 MODELOS DE PRUEBA

Modelos Prescriptivos
Los modelos prescriptivos de proceso se propusieron originalmente para ordenar
el caos de desarrollo de software. Los modelos prescriptivos de proceso definen
un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de
trabajo que se requieren para desarrollar software de alta calidad. Marco de
Trabajo: Comunicacin Planeacin Modelado Construccin.
Modelo en Cascada Tambin llamado el ciclo de vida clsico, sugiere un enfoque
sistemtico, secuencial hacia el desarrollo del software. Comunicacin Planeacin
Modelado inicio del proyecto Estimacin Anlisis recopilacin de requisitos
Itinerario diseo seguimiento Despliegue Construccin Entrega cdigo Soporte
prueba retroalimentacin.
Modelo en Cascada Desventajas -Los proyectos reales raramente siguen el flujo
secuencial que propone el modelo. -Normalmente, es difcil para el cliente
establecer explcitamente al principio todos los requisitos. -El cliente debe tener
paciencia. Hasta llegar a las etapas finales del proyecto, no estar disponible una
versin operativa del programa.
Modelo Incremental: El modelo incremental entrega el software en partes
pequeas, es iterativo. Incremento 2 Comunicacin Incremento n inicio del
proyecto recopilacin de requisitos Planeacin Estimacin Itinerario Incremento 1
seguimiento Modelado Comunicacin Anlisis inicio del proyecto diseo
recopilacin de requisitos Construccin Planeacin cdigo Estimacin prueba
Itinerario seguimiento Despliegue Modelado Entrega Anlisis Soporte diseo
retroalimentacin Construccin cdigo prueba Despliegue Entrega Figura Modelo
Incremental Soporte retroalimentacin
Modelo Incremental: Desventajas -Los primero incrementos son versiones
Incompletas del producto final, pero proporcionan al usuario la funcionalidad que
necesita y una plataforma para evaluarlo. -Con el pasar de los incrementos se
solicitara ms personal para implementar el incremento siguiente. Ventaja El
primer incremento se realiza con poca gente.
Modelo Prototipos: Pertenece a los modelos de desarrollo evolutivo. Construido en
poco tiempo, pocos recursos. El responsable del desarrollo del software est
inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema
operativo o de la forma que debera tomar la interaccin humana
Modelo Prototipos Ventajas -No modifica el flujo del ciclo de vida. -Reduce el
riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. -Exige disponer de las
herramientas adecuadas. -No presenta calidad ni robustez. -Una vez identificados
todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

121

Desventajas -El cliente ve funcionando lo que para l es la primera versin del

prototipo que ha sido construido con chicle y cable para embalaje, y puede
decepcionarse al indicarle que el sistema an no ha sido construido. -El
desarrollador puede caer en la tentacin de aumentar el prototipo para construir el
sistema final sin tener en cuenta las obligaciones de calidad y de mantenimiento
que tiene con el cliente.
Modelo en Espiral Anlisis de Planificacin Riesgos Anlisis de riesgo Anlisis de
riesgo Prototipo Anlisis de Operativo riesgo Prototipo 3 Revisin AR Prototipo 2
Prototipo 1 Plan de Simulaciones, Modelos, Estndares requisitos, Concepto de
Plan de ciclo operacin Requisitos de vida Software Plan de Validacin de Diseo
del desarrollo requisitos producto de software Diseo detallado Plan de
Codificacin prueba e Verificacin e Integracin validacin de Prueba de Unidad
diseo Prueba de Integracin Prueba de aceptacin Evaluacin del
Implementacin Ingeniera Cliente.

Bibliografa: http://es.slideshare.net/yvan66/11-modelos-segn-roger-s
CONCLUSIN
Los modelos de implementacin podemos concluir que es el proceso de convertir
una especificacin del sistema en un sistema ejecutable, prcticamente la parte
final, cuando se le da el ltimo retoque a la aplicacin. Para esto hay tres
subtemas que brotan de los modelos de implementacin y estos son los
diagramas de componentes que su concepto define que estos diagramas o
diagrama dividen componentes y muestra las dependencias entre estos
componentes. Despus estn los diagramas de despliegue los cuales tienen una
funcin se utilizan para modelar el hardware utilizado en las implementaciones de
sistemas y las relaciones entre sus componentes.
Y para finalizar estn los modelos de prueba y su objetivo es verificar el sistema
software para comprobar si este cumple sus requisitos.
Los modelos de implementacin son el conocimiento incorporado, y puesto que el
conocimiento esta inicialmente disperso, el desarrollo de software implcito, latente
e incompleto en gran medida es un proceso social de aprendizaje.
El diseo al nivel de componentes se presenta despus de que se han planteado
la primera iteracin del diseo arquitectnico. El diagrama de despliegue se utiliza
para la arquitectura fsica sobre la que un sistema de software es desplegado. Por
tanto describe tanto a los dispositivos fsicos como a los elementos de software.
Los modelos prescriptivos de proceso definen un conjunto distinto de actividades,
acciones, tareas, fundamentos y productos de trabajo que se requieren para
desarrollar software de alta calidad.

122