Desarrollo de Sistemas

Desarrollo de Sistemas
Ms.C. . Washington G. Pombosa Junes
El Software ......Sus
definiciones
Ing. Gonzalo Pombosa J.
Para poder entender las mejor al

Software, debemos indicar sus
caractersticas:
CARACTERSTICA DEL SOFTWARE

El Software se desarrolla, no se fabrica,
en un sentido clsico

El Software no se atrofia, se deteriora
ndice de fallo
CURVA DE FALLOS DEL HARDWARE
Tiempo
CURVA DE FALLOS DEL SOFTWARE
ndice de fallo
(IDEALIZADA)
Tiempo
ndice de fallo
CURVA DE FALLOS DEL SOFTWARE
Cambio
Tiempo
La mayora del software se construye a
medida, en vez de ensamblar componentes

existentes
Paradigmas de la ingeniera
de software
Que buscan los paradigmas de diseo:
Las soluciones tienen que proporcionar
asistencia prctica a la persona que
desarrolla el software, mejorar la calidad
del software y, por ltimo, permitir al
mundo del software mantenerse en paz
con el mundo del hardware1
1. Ingeniera de Software, Roger S. Pressman, Pag. 24
10
Cmo llegar a ella?
Estructura de datos
Programa Operativo
Plan
Especificacin
de Requisitos
Diseo
Listado
Especificacin de la Prueba
11
Definicin de Ingeniera de
software
El establecimiento y uso de principios de
ingeniera robustos, orientados a obtener
software econmico que sea fiable y funcione
de manera eficiente sobre mquinas reales. 2
La ingeniera del software surge de la ingeniera
de sistemas y de Hardware. Abarca un conjunto
de tres elementos clave: MTODOS,
HERRAMIENTAS Y PROCEDIMIENTOS.
2. Fritz Bauer, Pag. 69
12
Elementos de la Ingeniera de
Software
Los Mtodos,
Mtodos son aquellos que indican
como construir tcnicamente el
software e incluye tareas tales como :
Planificacin, anlisis de requisitos,
diseo de las estructuras de datos,
arquitectura de programas y
procedimientos algortmicos,
codificacin, prueba y mantenimiento.
13
Software
Las Herramientas,
Herramientas de la ingeniera de
software suministran un soporte
automtico o semiautomtico para los
mtodos. Pueden ser herramientas :
CASE, el cual combina software,
hardware y bases de datos sobre
ingeniera, anlogo al CAD/CAM
14
Software
Los Procedimientos,
Procedimientos de la ingeniera de
software son el pegamento que junta los
mtodos y las herramientas y facilita un
desarrollo racional y oportuno del software
de computadora. Los procedimientos
definen la secuencia en la que se aplican los
mtodos , las entregas (documentos,
informes, etc.) que se requieren, los
controles que ayudan a asegurar la calidad .
15
Qu son los paradigmas?

Al conjunto de los mtodos, herramientas
y los procedimientos antes
mencionados, se denominan
frecuentemente paradigmas de la
ingeniera de software
La aplicacin de cualquiera de ellos depender del
problema y las herramientas a utilizar.
16
Ciclo de Vida Clsico
El Ciclo de Vida Clsico

Tambin se lo denomina modelo en
cascada. Este paradigma exige un
enfoque sistemtico y secuencial del
desarrollo de software que comienza en
el nivel del sistema y progresa a travs
del anlisis, diseo, codificacin prueba
y mantenimiento. Este abarca las
siguientes actividades.
18

Ing. Anlisis
del sistema
Anlisis
de requisitos
Diseo
Codificacin
Prueba
Mantenimiento
19

Ing. Anlisis
del sistema
Se encarga de establecer los
requisitos de todos los elementos

del sistema y luego asignando
algn subconjunto de stos
requisitos de software. Se
encargad de determinar las
interrelaciones entre el hardware,
personas y bases de datos.
20

Anlisis
de requisitos
Se encargad de comprender la
naturaleza de los programas que hay

que construir, el ingeniero de software
analista debe comprender el mbito
de la informacin del software, as
como la funcin, el rendimiento y las
interfaces requeridos.
Los requisitos tanto del sistema como del software, se documentan y se

revisan con el cliente
21

Diseo
Este es un proceso multipaso que
se enfoca sobre cuatro atributos:
La Estructura de los Datos

La Arquitectura del Software
El Detalle Procedimental, y,
Caracterizacin de la Interfaz.
22

Diseo
El proceso de diseo traduce los

requisitos en una representacin del
software que pueda ser establecida en
forma que obtenga la calidad antes de
que comience la codificacin.
Al igual que los requisitos, el diseo se
docuementa y forma parte de la
configuracin del software
23

Codificacin
Se encarga de traducir el diseo
en una forma legible para la

mquina.
Si el diseo se realiza de manera
detallada; la codificacin puede
realizarce mecnicamente.
24

Prueba
La prueba se centra en la lgica
interna del software , asegurando que

todas las sentencias se han probado, y
en las funciones externas, realizando
pruebas que aseguren que la engrada
definida produce los resultados que
realmente se requieren.
25

Mantenimiento
El mantenimiento del softeare
aplica da a uno de los pasos

precedentes del ciclo de vida a un
programa existente en vez de a
uno nuevo. Se produce por la
modificaciones realizadas.
26
Construccin de Prototipos
Construccin de Prototipos
Se aplica especialmente cuando el programador no
identifica los requisitos detallados de entrada, proceso
o salida. Casos como eficiencia de un algoritmo, de la
adaptabilidad de un sistema operativo o de la forma
en que debe realizarse la interaccin hombre
mquina, pueden ser evaluados con este paradigma.
Facilita al programador la construccin de un modelo
software a construir. El modelo tomar una de las
tres formas:
28
Construccin de Prototipos.
Un Prototipo en papel o un modelo basado en Pc que
describa la interaccin Hombre mquina, de forma
que facilite al usuario la comprensin de cmo se
producir tal interaccin.
Un prototipo que implemente algunos subconjuntos
de la funcin requerida del programa deseado.
Un programa existente que ejecute parte o toda la
funcin deseada, pero que tenga otras caractersticas
que deban ser mejoradas en el nuevo trabajo de
desarrollo.
29
Recoleccin y
Refinamiento de
los requisitos
Diseo Rpido
Producto de
Ingeniera
Construccin del
Prototipo
Refinamiento del
Prototipo
Evaluacin del Prototipo
por el cliente
30
Por lo general se aplican los siguientes
pasos:
Paso 1: Evaluacin de la peticin de
software para determinar si el software
a desarrollarse es un buen candidato
para la construccin de un prototipo.
31
Paso 2: Dado un proyecto candidato
aceptable, el analista desarrolla una
representacin abreviada de los
requisitos.
Paso 3:Despus de revisar el modelo
de requisitos, se crea un conjunto
abreviado de especificaciones de
diseo para el prototipo
32
Paso 4:Creacin del software del
prototipo, prueba y refinamiento.
Paso 5:Una vez probado el prototipo,
presentacin al cliente, para que
conduzca una prueba de aplicacin y
suguiera modificaciones.
33
Paso 6: Repeticin de los pasos 4 y 5
de forma iterativa, hasta que todos los
requisitos queden formalizados o hasta
que el prototipo evolucione en el
sistema de produccin
Texto: Pressman, pag 201, Tercera Edicin.

34
Inquietudes?
Yo Si....
El anlisis de los requistos del software es sin duda el
paso de comunicacin ms intenso dentro del proceso de

ingeniera de software. Por qu se rompe tan
frecuentemente el camino de comunicacn?
Frecuentemente hay repercusiones npolticas al comienzo
del anlisis de los requisitos del software (yo el anlisis del

sistema). Por ejemplo, los trabajadores pueden creer que
su integridad en el trabajo peligra por la adquisicin de un
nuevo sistema automtico. Qu causa tales
problemas?Puede realizarce la tarea del anlisis de forma
que se minimicen esos aspectos polticos?
36
Yo Si....
Exponga sus ideas sobre el entrenamiento y los
conocimientos idelaes que debera tener el

Licenciado en Informtica Aplicada a la Educacin
para realizar tareas de este tipo.
Describa al cliente desde el punto de vista del
desarrollador de sistema de informacin, del

constructor de productos basados en
computadora y del constructor de sistemas .
37
Adicional.
Elabore un resumen de las metodologas hasta
ahora estudiadas, indique sus ventajas y

desventajas.
Realice un enfoque desde el punto de vista de
programador, sobre cuales sera las fases ms
importante.
Elabore el posible esquema que se debera seguir
para la implementacin de un sistema siguiendo el
modelo de Diseo de Prototipos.
38
Modelo en Espiral
MODELO EN ESPIRAL
Es un modelo creado combinando las
mejores caractersticas tanto del ciclo
de vida clsico como de la creacin de
prototipos, aadiendo al mismo tiempo
prototipos
un nuevo elemento que falta en esos
paradigmas, el cual es el anlisis de
riesgo.
40
MODELO EN ESPIRAL
El modelo en Espiral, define cuatro actividades
principales, representadas por los cuatro cuadrantes.
Planificacin
Anlisis de
Riesgo
Evaluacin
del cliente
Ingeniera
41
MODELO EN ESPIRAL
1. Planificacin : Determinacin de objetos, alternativas y
restricciones.
2. Anlisis de Riesgo: Anlisis de alternativas e
identificacin/resolucin de riesgos.
3. Ingeniera: Desarrollo del Producto de Siguiente Nivel
4. Evaluacin del Cliente: Valoracin de los resultados de
la Ingeniera.
42
MODELO EN ESPIRAL
Como se puede observar, cada iteracin alrededor del espiral se
construyen sucesivas versionas del software, cada vez ms
completas.
Durante la primera vuelta alrededor del espiral se definen los
objetivos, las alternativas y las restricciones y se analizan e
identifican los riesgos. Si el anlisis de riesgo indica que hay una
incertidumbre en los requisitos , se peuede crear la creacin
deprototipos en el cuarto cuadrante de ingeniera para dar
asistencia tanto al encargado del desarrollo como al cliente. Se
peuden usar simulaciones y otros modelos para definir ms el
problema y refinar los requisitos.
43
MODELO EN ESPIRAL
El cliente evala el trabajo de ingeniera (cuadrante de
evaluacin del cliente) y sugiere modificaciones. En base a
los comentarios del cliente se produce la siguiente fase de
planificacin y de anlisis de riesgo. En cada bucle alrededor
del espiral , la culminacin del anlisis de riesgo resulta en
una decisin de seguir o o seguir. Si los riesgos son
demasiado grandes se puede dar por terminado el proyecto.
Debe tenerse en cuenta que el nmero de actividades de
desarrollo que ocurren en el cuadrante inferiorderecho
aumenta al alejarse del centro de la espiral.
44
MODELO EN ESPIRAL
Ventajas:
Es el enfoque ms realista para el desarrollo de software y de

sistemas a gran escala.
Utiliza un nivel evolutivo para la ingeniera de software,

permitiendo al desarrollador y al cliente entender y reaccionar a
los riegos en cada nivel evolutivo.
Utiliza la creacin de prototipos como un mecanismo de

reduccin del riesgo, pero, lo que es ms importante permite
a quien lo desarrolla aplicar el enfoque de creacin de
prototipos en cualquier etapa de la evolucin del producto.
45
MODELO EN ESPIRAL
Ventajas:
El modelo en espiral demanda una consideracin directa de

riesgos tcnicos en todas las etapas del producto, y si se
aplica adecuadamente, debe reducir los riegos antes de que se
conviertan en problemticos.
Desventajas:
Puede ser dificil convencer a grandes clientes

(particularmente en situaciones bajo contrato) de que
el enfoque evolutivo es controlable.
46
MODELO EN ESPIRAL
Desventajas:
Requiere una considerable habilidad para la valoracin

del riesgo y cuenta con esta habilidad para el xito.
Si no se descubre un riego importante

indudablemente surgirn problemas.
47
Tcnicas de Cuarta Generacin
Tcnicas de Cuarta
Generacin
El trmino Tcnicas de Cuarta Generacin abarca un amplio
espectro de herramientas de software que tiene algo en comn:
todas facilitan, al que desarrolla el software, la especificacin
de algunas caractersticas del software de alto nivel
Luego, la herramienta genera automticamente el cdigo fuente
basndose en la especificacin del tcnico.
Cada vez parece ms evidente que cuanto mayor sea el nivel
en el que se especifique el software, ms rpido se podr
construir el programa
49
Tcnicas de Cuarta
Generacin
El paradigma T4G para la Ingeniera del Software se orienta
hacia la posiblilidad de especificar el software a un nivel ms
prximo al lenguaje natural o en una notacin que proporcione
funciones significativas.
T4G, pueden incluir aulgunas o todas las siguientes
herramientas: Lenguajes no procedurales para consulta a bases
de datos, generacin de informes, manipulacin de datos,
interaccin y definicin dempantallas, generacin de cdigo,
facilidades grficas de alto nivel y facilidades de hoja de
clculo.
50

Tcnicas de
Cuarta
Generacin
Recoleccin
de Requisitos
Estarategia
de diseo
Implementacin
en L4G
Prueba
51

En la fase de recoleccin de requisitos,
idealmente el cliente describe los requisitos, que
son, a continuacin traducidos directamente a
un prototipo operativo.
Esto no simpre es as pues el cliente puede no
estar seguro dfe lo que necesita; puede ser
ambiguoen la especificacin de los hechos que
son conocidos y puede no desear o ser incapaz de
especificar la informacin en la forma en que una
herramienta T4G puede aceptarla.
52

Para aplicaciones pequeas se puede ir
directamente desde el paso de recoleccin de
requisitos al paso de implementacin, usando un
Lenguaje de Cuarta Generacin no
procedimental.
El uso de T4G sin diseo (para grandes
proyectos)causar las mismas duficulatdes ( Poca
calidad, manteninimiento pobre, mala aceptacin por
el cliente) que se encuentran cuando se desarrolla
software mediante los enfoques convencionales.
53

Pros::
Pros
Reduccin drstica del tiempo de desarrollo del software

y una mejora significativa en la productividad de la
gente que construye software.
Contras:
Las herramientas actuales de T4G no son ms fciles

de utilizar que los lenguajes de programacin, que el
cdigo fuente producido por tales herramientas es
ineficiente y que el mantenimiento de grandes
sistemas es cuestinable.
54

Ventajas-desventajas:
Con muy pocas excepciones, el mbito de aplicacin actual de

las T4Gest limitado a las aplicaciones de sistema de
informacin de gestin, concretamente al anlisis de la
informacin y la obtencin de informes relativos a grandes
bases de datos. Sin embargo las nuevas herramientas CASE
soportan ahora el uso de T4G para la generacin automtica
de esquemas de cdigo para aplicaciones de ingeniera y de
tiempo real.
55

Ventajas-desventajas:
Los datos preliminares recogidos durante implementaciones

ya realizadas, que usan T4G, parecen indicar que el tiempo
requerido para producir software se reduce mucho para
aplicaciones pequeas y de tamao medio, y que la cantidad
de anlisis y diseo para las aplicaciones pequeas tambin se
reducen.
Sin embargo el uso de T4G para grandes trabajos de desarrollo
de software exige el mismo o ms tiempo de anlisis, diseo y
prueba, perdindose as un tiempo substancial que se ahorra
mediante la eliminacin de la codificacin.
56
Combinacin de Paradigmas
Ingeniera de Software
Todos los paradigmas antes
mencionados han sido tratados como
mtodos alternativos, para la
Ingeniera de Software, en lugar de
como
METODOS COMPLEMENTARIOS
58
En muchos casos los paradigmas deben
combinarse de forma que puedan

utilizarse las ventajas de cada uno de
ellos en un nico proyecto.
En la siguiente ilustracin se trata de
combinar los tres paradigmas antes

estudiados durante un trabajo de
desarrollo de software
59
Recoleccin preliminar de requisitos
Anlisis de requistos
Prototipado
T4G
Prototipado iteracin
n-sima
Diseo
Modelo en Espiral
T4G
Modelo en Espiral
Codificacin
Iteracin n-sima
T4G
Prueba
Sistema en Operacin
Mantenimiento
60
En todos los casos , el trabajo comienza con la
determinacin de objetivos, alternativas y
restricciones paso que a veces se llama
recoleccin de requisitos.
A partir de ese punto se puede tomar cualquiera

de los caminos indicados en la figura anterior.
La naturaleza de la aplicacin debe dictar
el mtodo a elegir .
61
Paradigma. Visin Genrica de la Ingeniera de Software
El proceso de desarrollo del software contiene tres fases
genricas , independientemente del paradigma de ingeniera
elegido. Estas son
Definicin, Desarrollo y Mantenimiento
Las cuales son independientes del rea de aplicacin, del
tamao del proyecto o de la complejidad.
62
La fase de definicin se centra sobre el que
Aqu se intenta identificar la informacin que ha de ser
procesada, que funcin y rendimiento se desea, que
interfases han de establecerse, que restricciones de
diseo existen y que criterios de validacin se
necesitan para definir un sistema correcto.
Aqu por lo general se producirn tres pasos: Anlisis del
Sistema, Planificacin del proyecto de Software y
anlisis de los requisitos.
63
Anlisis del Sistema:
Sistema Define el papel de cada elemento de un
sistema informtico, asignando finalmente al software el papel que
va a desempear.
Planificacin del proyecto de Software:
Software Una vez establecido el
mbito del software, se analizan los riesgos, se asignan los
recursos, se estiman los costos, se definen las tareas y se planifica
el trabajo.
Anlisis de requistos:
requistos El mbito establecido para el software
proporciona la direccin a seguir, pero antes de comenzar a
trabajar es necesario disponer de una informacin ms detallada
del mbito de informacin y de funcin del software.
64
La Fase de Desarrollo se centra en el como.
como
Aqu se intenta descubrir como han de disearse las
estructuras de datos y la arquitectura del software,
como han de implementarse los detalles
procedimentales, como a de traducirse el diseo a
un lenguaje de programacin y como ha de
realizarce la prueba.
De alguna forma se producirn tres pasos: Diseo de
Software, Codificacin y Prueba del Software
65
Diseo de Software:
Software El diseo traduce los requistos del
software a un conjunto de representaciones (algunas
grficas otras tabulareso basadas en lenguajes) que
describen la estructura de los datos , la arquitectura,
el procedimiento algortimico y las caractersticas de
la interfaz.
Codificacin: Las representaciones del diseo desen
Codificacin
ser traducidas a un lenguaje artificial (lenguaje de
programacin convencional o no procedimental
usado en T4G) dando como resultado unas
instrucciones ejecutables por la computadora.El paso
de la codificacin es el que lleva a cabo esa
traduccin.
66
Prueba de Software:
Software Una vez que el software ha
sido implementado en una forma ejecutable por
la mquina debe ser probado para descubrir los
defectos que puedan existir en la funcin, en la
lgica y en la implementacin.
67
La fase de Mantenimiento se centra en el
cambio que va asociado a la correccin de
errores y a las modificaciones debidas a los
cambios de los requisitos del cliente dirigidos a
reforzar o a ampliar el sistema.
Durante el mantenimiento se pueden encontrar
tres tipos de cambio: Correccin, Adaptacin y
Mejora.
68
Correccin Incluso llevando a cabo las mejores actividades
Correccin:
de garanta de calidad, es muy problable que el cliente
descubra defectos en el software. El Mantenimiento
Correctivo cambia el software para corregir los defectos.
Adaptacin Con el Paso del tiempo es problable que
Adaptacin:
cambie el entorno original (eje. El CPU, El Sistema
Operativo, Los Perifricos)para el que se desarrollo el
software. El Mantenimiento Adaptativo consiste en
modificar el software para acomodarlo a los cambios de
su entornoexterno.
69
Mejora : Conforme utilice el software el cliente
usuario puede descubriri funciones adicionales
que podran interesar que estuviesen
incorporadas al software . El Mantenimiento
Perfectivo, amplia el software ms all de sus
requistos funcionales originales.
70
Preguntas
Preguntas.
1. Investigue sobre los primeros aos de la
ingeniera de software, comenzando con

algunos artculos pioneros sobre diseo de
programas y continuando con los intentos
de desarrollo de una metodologa ms
amplia.
2. Investigue tres productos CASE disponibles
comercialmente y realice una comparacin
entre ellos usando los criterios que Ud.
mismo desarrolle
72
Preguntas.
3. Cul de los paradigmas de la ingeniera de
software presentados seran los ms tiles

para sus aplicaciones de software?Por
qu?.
4. Mucha gente argumenta que el trmino
mantenimiento es incorrecto aplicado al
software. Que las actividades asociadas
con el mantenimiento del software no son
mantenimiento del todo. Qu piensa Ud.?
73
PROXIMA CLASE PRUEBA

En caso de inquietudes, acudir al
Docente para su mejor comprensin.

Si es necesario hacer una revisin total
de la materia, se suguiere consultar a :
Roger S. Pressman, Tercera edicin,
Pags. 3 a la 40.
74
Gestin del Proyecto

Mtricas de Software
76
UML
78
Modelando objetos de Visual FoxPro:

Visual UML Jos Luis Santana Blasco
Por qu una herramienta de modelado de
objetos?
Con la llegada de la programacin orientada a
objetos en la versin 3.0 de Visual Foxpro, muchas
de las tcnicas que emplebamos para realizar
nuestras aplicaciones quedaron completamente
obsoletas. En un principio, lo difcil era saber cual
era el mtodo ms idneo, o cual el objeto ms
adecuado, para escribir nuestro cdigo funcional
en los objetos que VFP nos proporcionaba
79

Con el tiempo, empezamos a aprender que la verdadera potencia
de la OOP no est en los objetos visuales, sino en los objetos
no visuales, que son los que realmente mueven nuestras
aplicaciones. Cuando ya superamos esta fase, llegamos a la
fase en el que empezamos a programar las reglas de nuestro
negocio dentro de los llamados objetos de negocio. Nuestras
aplicaciones empiezan a funcionar como un largo dialogo
entre objetos en diferentes capas. Cuando llegamos a esta
situacin, o empleamos una herramienta que nos ayude a
tener todos nuestros objetos bajo control, o nuestro proyecto
tiene grandes posibilidades de ser uno de tantos proyectos
orientados a objetos que no llegan al final de su desarrollo, o
llegan como una extraa mezcla de programacin funcional y
orientada a objeto de mantenimiento imposible.
80

Una vez que hemos llegado a este punto nos planteamos dos preguntas:
Qu metodologa emplear?
Qu aplicacin podemos emplear con esta metodologa?
La primera pregunta cada vez resulta ms fcil contestar. El Lenguaje
Unificado de Modelado, o UML como es ms conocido, se ha
convertido en un estndar de la industria desde que las principales
metodologas de modelado de objetos fueron integradas en este
lenguaje gracias al trabajo de Rumbaugh, Booch y Jacobson, y
gracias al inters de la empresa Rational Software Corporation.
Este lenguaje permite definir todos los aspectos y fases del
desarrollo del software, desde las fases iniciales de anlisis hasta
las fases finales de implantacin, todo ello de forma precisa,
completa, detallada, y con total independencia de las herramientas
de software que se vaya a emplear para su programacin.
81

La segunda pregunta es algo ms complicada de
responder, en especial si nuestro enfoque no se centra
exclusivamente en el desarrollo en VFP. Debido a la
gran difusin que est alcanzando UML, existen en el
mercado una gran cantidad de productos que permiten
realizar los diagramas y artefactos que requiere UML, y
en muchos casos, permiten tambin realizar la
generacin del cdigo fuente de las clases modeladas, o
realizar la lectura de los ficheros de definicin de clases
de un determinado lenguaje, y crear los diagramas UML
de estas clases. Esto ltimo es lo que se conoce como
reingeniera inversa.
82
Si nos centramos en herramientas que sean capaces de generar

cdigo VFP, o que puedan leer los archivos de definicin de
clases de VFP, el nmero de aplicaciones se reduce bastante,
quedndose este nmero en slo dos aplicaciones: MS Visual
Modeler y Visual UML.
MS Visual Modeler es una aplicacin que forma parte de la suite MS
Visual Studio 6.0 Enterprise. Es una versin muy recortada del
excelente producto Rational Rose, pero cumple su funcin si
nuestro inters se centra nicamente en la documentacin de
nuestras clases, o en un modelado simple. Una de las
actualizaciones del Visual Studio incorpor un asistente para su
uso desde y hacia Visual FoxPro. Dado que no viene con la
versin 7.0, y dado que MS est potenciando como herramienta
de modelado el producto MS Visio, no comentaremos ms sobre
este producto en el artculo.
83
Con lo dicho en el prrafo anterior, Visual UML queda como

nica alternativa posible si a nuestra herramienta de
diseo le pedimos que sea capaz de generar y leer
cdigo VFP. La opcin de generar cdigo nos va a
permitir, en fases avanzadas de nuestro diseo, crear el
esqueleto de las libreras de clases VFP que hayamos
definido en el modelo. Mientras que la opcin de leer las
libreras de clases de VFP nos permitir actualizar
nuestro modelo con las modificaciones introducidas en
VFP, o crear uno nuevo modelo de clases ya existentes
para, por ejemplo, realizar un proceso de refactorizacin.
84
Qu nos ofrece VisualUML?

Visual UML nos ofrece la posibilidad de crear
todos y cada uno de los artefactos y diagramas
que se definen en la especificacin de UML
1.3, manteniendo todos los componentes
enlazados mediante un repositorio, al que
podemos acudir para redefinir cualquier
aspecto del modelo, vindose inmediatamente
afectadas todos las objetos del modelo que
tengan relacin con nuestro cambio.
85
...Modelando objetos de Visual FoxPro: Visual UML

Nos ofrece tambin un gran nmero de posibilidades de
exportacin de la informacin generada, pudiendo llevar
nuestros diagramas a los ms conocidos formatos grficos,
publicarlos en HTML, o incluso exportarlos a XML.
La importacin, si bien ms limitada en principio que la
exportacin, nos permite tomar datos de otros diagramas
generados con VisualUML, y del estndar de definicin XML,
empleado este mtodo como sistema de importacin desde
otras aplicaciones de modelado. De todas formas, se hecha
en falta la posibilidad de importar modelos desde ficheros
nativos de otras herramientas de modelado tan comunes
como Rational Rose o Together.
Nuestro inters por esta herramienta se centra en sus
Gonzalo Pombosa J.
86
capacidades para generar yIng.leer
definiciones de clases en
VFP. Visual UML, sin embargo, no est orientada nicamente
al mundo Fox, como buena herramienta de modelado, es

Antes de crear el fichero del modelo, Visual UML an nos pedir
un dato ms: Qu herramienta vamos a emplear para generar
cdigo?.
Esta pregunta no nos debe preocupar en este momento, pues lo
que contestemos no nos condiciona el modelado inicial, y
podremos cambiar la respuesta cuando lo necesitemos (en las
fases finales de diseo), incluso podremos cambiar nuestra
respuesta cuantas veces queramos a lo largo de la creacin del
modelo, lo que nos permitir la definicin de las caractersticas
particulares de cada lenguaje en todas nuestras clases, en el
caso de que trabajemos con varios lenguajes.
Una vez creado el modelo en blanco, VisualUML nos ofrece un

Treeview con todos los posibles artefactos y diagramas que se
87
pueden realizar con el programa.
VisualUML no nos dirige en ningn momento en la creacin de los
diagramas o artefactos, somos nosotros los que iremos
88
Modelando objetos de Visual FoxPro: Visual UML

UML es muy extenso, y la gente de Visual Object Modelers
han intentado que su producto permita modelizar hasta el
ltimo detalle del lenguaje. Para ello, detrs de todos los
artefactos y diagramas que podemos realizar en la
aplicacin se "esconden" un sin fin de ventanas de dialogo
anidadas, llenas de marcos de pginas, llenos estos a su
vez de una gran cantidad de casillas de verificacin, grids, y
cuadros combinados, todo ello buscando permitir al usuario
describir con la precisin que ofrece UML 1.3 los artefactos
que intervienen en un modelo.
Con esto no quiero decir que Visual UML sea una aplicacin
difcil de emplear, pero dado que es una herramienta muy
extensa en opciones y muy configurable, es necesario
dedicarle mucho tiempo para
sacarle
todo
el partido posible
Ing. Gonzalo
Pombosa
J.
de sus mltiples opciones.
89
90

Si bien el proceso de generacin de cdigo resulta sencillo y
efectivo, cuando el modelo llega a un considerable tamao, la
generacin de cdigo resulta algo engorrosa, al deber realizar la
generacin librera a librera, dado que no permite indicar
individualmente la librera de clase donde se debe almacenar
cada clase.
Por otro lado hay que resaltar una limitacin del generador de
cdigo, que dependiendo de nuestras necesidades, puede ser
ms o menos importante. El generador de cdigo slo trabaja con
libreras VCX, por lo que no es posible generar clases que
hereden de tipos base de VFP como Session, Relation o Cursor,
por poner un ejemplo.
Resulta curioso comprobar que esta limitacin no se encuentra en
91
la definicin del modelo, lo que nos dara una solucin alternativa,
pero costosa, realizando nuestro propio generador para estas
clases mediante las herramientas de programacin que ofrece la
92

Conclusiones
En este artculo he querido presentar un producto que cuanto
ms se conoce ms gusta al desarrollador, pues realmente
resulta de gran ayuda para esa difcil tarea que es crear
aplicaciones para nuestros clientes. Todo en esta vida es
mejorable, y en mi opinin hay dos aspectos que exigen una
urgente mejora en el producto: la implementacin de los
paquetes, y la interfaz.
Es difcil encontrar un aspecto de UML que no est
contemplado en Visual UML, pero an podemos encontrarnos
algunos que no cumplen completamente con la especificacin
UML 1.3. El caso ms destacable es el de los paquetes y los
diagramas de paquetes. En los paquetes de Visual UML no
podemos definir visibilidad,
por lo que la implementacin 93
queda como una simple agrupacin de artefactos, lo que deja
muy limitada su utilidad en comparacin de la utilidad que
ANEXOS
Riegos.
Cuando consideramos el riesgo con el
contexto de la ingeniera del software,

siempre se hacen evidentes las tres
consideraciones conceptuales de Robert
Charette.
95
Riegos.
Nos concierne el Futuro. - Cules son los riegos
que pueden hacer que fracase el proyecto de

software?
Nos conciernen los cambios.- Cmo afectarn al
xito global y a los plazos los cambios en los
requisitos del cliente, en las tecnologas de desarrollo,
en las computadores destino y en todas las dems
entidades relacionadas con el proyecto?.
Nos enfrentamos con elecciones.- Qu mtodo y
herramientas debemos hay que darle a la calidad?
usar, cuanta gente debe estar involucrada, cuanta
importancia
96

Desarrollo de Sistemas

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo de Sistemas

Cargado por

Copyright:

Formatos disponibles

Desarrollo de Sistemas

Ms.C. . Washington G. Pombosa Junes

Ing. Gonzalo Pombosa J.

Para poder entender las mejor al

Ing. Gonzalo Pombosa J.

CARACTERSTICA DEL SOFTWARE

Ing. Gonzalo Pombosa J.

CARACTERSTICA DEL SOFTWARE

Ing. Gonzalo Pombosa J.

CURVA DE FALLOS DEL HARDWARE

CURVA DE FALLOS DEL SOFTWARE

medida, en vez de ensamblar componentes

Ing. Gonzalo Pombosa J.

Cmo llegar a ella?

Ing. Gonzalo Pombosa J.

Qu son los paradigmas?

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

Se encarga de establecer los

requisitos de todos los elementos

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

naturaleza de los programas que hay

Los requisitos tanto del sistema como del software, se documentan y se

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

Este es un proceso multipaso que

se enfoca sobre cuatro atributos:

La Estructura de los Datos

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

El proceso de diseo traduce los

El Ciclo de Vida Clsico

Se encarga de traducir el diseo

en una forma legible para la

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

La prueba se centra en la lgica

interna del software , asegurando que

Ing. Gonzalo Pombosa J.

El Ciclo de Vida Clsico

El mantenimiento del softeare

aplica da a uno de los pasos

Ing. Gonzalo Pombosa J.

Ing. Gonzalo Pombosa J.

Ing. Gonzalo Pombosa J.

Ing. Gonzalo Pombosa J.

Ing. Gonzalo Pombosa J.

Texto: Pressman, pag 201, Tercera Edicin.

paso de comunicacin ms intenso dentro del proceso de

del anlisis de los requisitos del software (yo el anlisis del

conocimientos idelaes que debera tener el

desarrollador de sistema de informacin, del

ahora estudiadas, indique sus ventajas y

Ing. Gonzalo Pombosa J.

Es el enfoque ms realista para el desarrollo de software y de

Utiliza un nivel evolutivo para la ingeniera de software,

Utiliza la creacin de prototipos como un mecanismo de

El modelo en espiral demanda una consideracin directa de

Puede ser dificil convencer a grandes clientes