INGENIERA DE SOFTWARE

UNIDAD 1
INTRODUCCION A LA INGENIERIA DE SOFTWARE
1.1 Descripcin del curso, objetivo del curso y metodologa de evaluacin.
1.2 Importancia, presente y futuro de la Ingeniera de Software.

UNIDAD II
INGENIERIA DE SOFTWARE
2.1 Fundamento
2.2 Principios bsicos de la ingeniera del software.
2.3 Proceso de la ingeniera del software
2.4 Tecnologa CASE y entornos de desarrollo
2.5 Tendencias
2.6 Metodologas para la solucin de Problemas. (rboles, diagramas Venn, Karnaugth,
grafos,
integramas, cuadros de doble entrada).
2.6.1 Qu es un problema?
2.6.2 Tipos de solucin
2.6.3 Heursticas
2.7
El ciclo de vida.
2.7.1 Tradicional
2.7.2 Ejemplificar

UNIDAD III
HERRAMIENTAS DE MODELADO
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.2
3.3
3.4
3.5
3.6

Conceptos
Abstraccin
Refinamiento
Modularidad
Arquitectura del software
Jerarqua de control
Estructura de datos
Procedimiento del software
Ocultamiento de informacin
Caractersticas de las herramientas
Diagrama de flujo de datos.
El diccionario de datos
Especificaciones del proceso
Diagramas de entidad relacin

3.7 Diagramas de transicin de estados

3.8 Balanceo de modelos
3.9 Herramientas adicionales de modelado
3.9.1 Pensamiento lateral (6 sombreros)
3.10 Prototipos
3.10.1 Construccin de prototipos (Progresivo y espiral)
3.11 Metodologas
3.11.1 Anlisis tradicional
3.11.2 Anlisis Estructurado
3.11.3 Anlisis Orientado a Objetos

UNIDAD IV
ANALISIS
4.1 Anlisis estructurado
4.1.1 Conceptos
4.1.2 Principios
4.1.3 Ejemplo de aplicacin
4.2 Anlisis Orientado a Objeto
4.2.1 Conceptos
4.2.2 Principios
4.2.3 Mtodos de Anlisis
4.2.4 Ejemplo de aplicacin
4.3 Diferencias entre estructurado y orientado a objetos

UNIDAD V
DISEO
5.1 Diseo estructurado
5.1.1 Conceptual
5.1.2 Modelacin
5.1.3 Detallado
5.2 Diseo orientado a objetos
5.2.1 Mtodos de diseo
5.2.2 Multicapas y multicomponentes
5.3 Diseo Arquitectnico

INGENIERA DE SOFTWARE
FUNDAMENTACIN DE LA ASIGNATURA
El perfil del Licenciado en Ciencias de la Informtica requiere del conocimiento profundo y
especializado sobre un tema que hoy en da es vital para su formacin. El tema de
Ingeniera de Software representa el estudio organizado y disciplinado de tecnologa para el
anlisis, diseo, construccin e implantacin de sistemas de informacin.
La Ingeniera de Software, es actualmente reconocida como una disciplina legtima en el
mbito informtico y se puede aseverar que la imparticin de sta asignatura, fortalecer el
perfil del egresado de UPIICSA.

FUNDAMENTACIN
Se consideran los aos 90 como la dcada de la informacin, la construccin de piezas de
software de calidad que faciliten el manejo de la informacin, adquiere importancia de
diferencia competitiva en las organizaciones, y utilizar una tcnica clara y esquemtica
como lo es Ingeniera de Software toma importancia.
Los cambios tecnolgicos en equipos y programas, requieren de una actualizacin
constante en el proceso enseanza/aprendizaje para profesores y alumnos. El tema de
Ingeniera de Software tradicional era abordado por la mayora de las carreras de
informtica en captulos o temas individuales que se diseminaban en varias asignaturas
como por ejemplo, lenguajes de programacin, anlisis y diseo de sistemas de
informacin, bases de datos, etc. Sin que se tuviera un control u organizacin, del perfil de
informtico.
La idea de disear la asignatura de Ingeniera de Software para alumnos del segundo
semestre es muy importante para que el estudiante de este semestre tenga un panorama
general completo y abierto del ciclo de vida de un sistema de informacin.
La Ingeniera de Software asistida por computadora (CASE) sin ser un tema nuevo, es
importante que el estudiante tenga las bases tcnicas y conceptos de sta disciplina que
refuerza el concepto tradicional de Ingeniera de Software.
Las corrientes filosficas de desarrollo de sistemas estructurado y orientado a objetos
permiten que el estudiante obtenga un panorama general del ciclo de vida de los sistemas
aterrizado en estas metodologas.

METODOLOGIA DE LA ENSEANZA.
La metodologa general del proceso enseanza-aprendizaje para impartir esta asignatura,
consiste en la presentacin por parte del profesor de casos seleccionados; utilizando
tcnicas de anlisis, diseo y desarrollo de sistemas de informacin, tanto estructurados,
como orientado a objetos aplicados a casos especficos. Para este propsito se utilizaran
instrumentos didcticos tradicionales (pizarrn, acetatos, rotafolios, etctera, as como
instrumentos automatizados que asisten a la Ingeniera de Software). Los resultados que
deben alcanzar los alumnos en equipos por periodo departamental son : 1er. departamental,
se deber hacer el anlisis de requerimientos de un problema hasta llegar a su
planteamiento; en el 2do. departamental, el anlisis, diseo y construccin de un prototipo;
y en el 3er departamental, un producto de software completo y funcional. El cul servir de
base para la materia de sistemas de informacin 1 y probablemente para otras asignaturas
relacionadas..

UNIDAD 1. INTRODUCCIN A LA INGENIERA DE SOFTWARE.

1.1 DESCRIPCIN DEL CURSO, OBJETIVO DEL CURSO Y METODOLOGA DE
EVALUACIN.
La idea central de este curso es que el alumno identifique, se familiarice y aplique las
metodologas y herramientas ms importantes de la ingeniera de software. Para ello tomar
como base un pequeo caso de estudio y resolver un problema sencillo guiado por el
profesor.
La primera parte trata el concepto de Ingeniera de Software y de problemas de software,
sus principios, metodologas de solucin, herramientas y el ciclo de vida como campo de
aplicacin de stas.
Inmediatamente despus se presentan tcnicas para el modelado de sistemas y algunos
tpicos complementarios para la mayor apertura del alumno a la aceptacin y uso de
tcnicas diversas a las tradicionales.
Con los elementos conceptuales y los ejercicios de aplicacin al caso prctico se introduce
al alumno al anlisis formal de sistemas, de manera que adquiera los elementos para
conceptuar un sistema y establecer los elementos necesarios para la definicin formal de los
requerimientos y que sirvan de marco de referencia para un determinado sistema
seleccionado por el propio alumno..
Despus, el estudiante adquirir y aplicar los conocimientos de diseo para convertir la
especificacin de requerimientos en un modelo concreto, de manera que al finalizar el curso
el alumno presente un sistema debidamente diseado en un prototipo sencillo pero
conceptualmente completo y con las especificaciones suficientemente detalladas para

posteriormente, mediante la debida programacin, convertir ese modelo en un sistema

debidamente funcional
Finalmente, bajo la estrecha asesora y supervisin del profesor, se dar al alumno la
libertad de aplicacin de lo aprendido en el desarrollo anterior del curso para la obtencin
de un producto software sencillo pero funcional. El resultado de esta ltima etapa
depender de los antecedentes de programacin, la creatividad y la habilidad del alumno
para utilizar herramientas de desarrollo, pero de manera importante tambin depender del
apoyo que el profesor de la asignatura y profesores de asignaturas relacionadas como
Lenguajes de Programacin I y II puedan proporcionarle.
La metodologa general del proceso enseanza-aprendizaje para impartir esta asignatura,
consiste en la presentacin por parte del profesor de casos seleccionados; utilizando
tcnicas de anlisis, diseo y desarrollo de sistemas de informacin, tanto estructurados,
como orientado a objetos aplicados a casos especficos. Para lo cul se utilizaran
instrumentos didcticos tradicionales (pisaron, acetatos, rotatorios, etctera, as como
instrumentos automatizados que asisten a la Ingeniera de Software). Los resultados que
deben alcanzar los alumnos en equipos por departamental son: 1er. Departamental, se
deber hacer el anlisis de requerimientos de un problema hasta llegar a su planteamiento;
en el 2do. Departamental el anlisis, diseo y construccin de un prototipo; y en el 3ro
departamental un producto de software completo y funcional. El cul servir de base para la
materia de sistemas de informacin 1.
La forma de evaluacin del curso est estrechamente relacionada con esta metodologa, los
elementos que permitirn una apreciacin del desarrollo de la asignatura sern: Asistencia
de los alumnos y del profesor, disponibilidad y acceso al material didctico y las referencias
bibliogrficas, realizacin de las tareas, ejercicios y labores de investigacin, participacin
y motivacin en clase y los exmenes departamentales. Respecto a la calificacin final para
el alumno, de acuerdo a lo establecido en el programa de la asignatura, ser la suma de las
calificaciones de cada examen departamental dividido entre tres.
1.2. IMPORTANCIA, PRESENTE Y FUTURO DE LA INGENIERA DE
SOFTWARE.
El origen formal de la Ingeniera de Software se remonta al final de la dcada de los 60s,
impulsada por el Departamento de Defensa de los Estados Unidos de Norteamrica,
apoyada por los institutos y universidades de ese pas y gradualmente adoptada por los
desarrolladores de software ms importantes de todo el mundo.
La importancia de esta disciplina radica en dos puntos fundamentales:
Una propuesta de aplicacin del mtodo cientfico a la solucin de los problemas de
calidad, productividad y costo en la produccin, comercializacin y
aprovechamiento del software.

 La necesidad de colaboracin de un equipo interdisciplinario para el logro de

productos y procesos satisfactorios que tienen lugar en la industria de programas de
cmputo.
Estos dos puntos, pueden ser compartidos por otras ramas de la ingeniera y por otras
disciplinas, sin embargo, el distintivo caracterstico de la Ingeniera de Software es el
mismo producto que se pretende obtener al aplicarse: el software.
La naturaleza intangible del software le da propiedades que ningn otro producto tiene, por
ejemplo: la facilidad de reproduccin, la incertidumbre de su obsolescencia, la dificultad
para definir sus insumos, la necesidad de medios para el almacenamiento, la adecuacin de
mtodos para el control de sus inventarios y otros.
Esta naturaleza del software dificult en su origen, a travs del tiempo y en muchos casos
actuales, una adecuada administracin de su produccin, y por consiguiente los costos de
obtenerlo eran excesivamente altos, sin embargo, la tendencia, a partir del surgimiento de la
Ingeniera de Software y hacia la entrada al nuevo milenio, ha sido la obtencin masiva de
productos software de la ms amplia variedad y a costos comparativamente mnimos. Un
fenmeno que se est extendiendo en nuestros das y que parece tener una tendencia a
predominar es la disponibilidad de software gratuito tanto de desarrollo como de
productividad, sistemas operativos y aplicaciones de usuario ya sea de propsito
especfico o general.
As, podemos prever en el futuro inmediato y con tendencia creciente al mediano y largo
plazo (de hecho hemos iniciado una etapa dentro de este paradigma), software abundante,
elaborado en forma rpida, muy eficiente y a muy bajo costo o incluso gratuito para el
usuario. Organizaciones internacionales como la Free Software Foundation promueven esta
tendencia y han logrado una difusin y proliferacin de impacto en el mercado.
Sin embargo, la Ingeniera de Software no solamente ha contribuido a estas expectativas,
sino que avanza en apoyo de actividades complementarias al desarrollo de software,
proporcionando metodologas, herramientas y tcnicas para la planeacin de la produccin
de software, el anlisis y diseo de sistemas, apoyo a servicios como asesora y
capacitacin, implantacin y mantenimiento de sistemas de informacin y otras
aplicaciones.
En sntesis, el panorama que presenta la industria de software es sumamente atractivo para
el usuario final, tanto por disponibilidad como por costo, y el campo de aplicacin de la
Ingeniera de Software sigue siendo suficientemente amplio como para entender porqu
esta disciplina ocupa un lugar tan importante en los planes de estudio de informtica,
computacin, sistemas y reas afines de todas las universidades del mundo de prestigio y en
la industria de desarrollo de software e integracin de soluciones informticas en las
empresas.
Extrapolando los datos de Cuevas, [CUE95], las perspectivas por cuanto a la demanda y
oferta de software se pueden apreciar en la siguiente grfica:

Figura 1 de Cuevas

INSERTAR

Podemos darnos cuenta, en base a esta grfica, que mientras en 1982, para una demanda de
1000 unidades de software (productos), la productividad esperada era de aproximadamente
800 y el personal disponible suficiente para 500; en 1990 la brecha entre estas tres variables
se observa mucho mayor, ya que para una demanda de 2500, se cuenta con 1100 personas
con una productividad de 1600, la perspectiva hasta este punto parece dramtica, sin
embargo, en tiempos recientes (ltimos 5 aos), la disponibilidad de nuevas tcnicas y
herramientas hacen que la tendencia cambie de manera importante, reduciendo esta brecha
significativamente.
Por otra parte, los costos por lo que a hardware, software y mantenimiento se refiere,
muestran una evolucin muy favorable para el usuario, de acuerdo a la siguiente grfica
proporcionada por el mismo Cuevas.
Fig. 2 de Cuevas

INSERTAR

Lo importante de esta grfica es que puede observarse una disminucin muy significativa
en os costos del hardware e incluso del software, haciendo que la componente humanware
se convierta en la parte esencial, por cuanto a costo, de un proyecto o de un producto
software. La grfica muestra porcentajes, pero en trminos absolutos el costo total ha
disminuido tambin de manera considerable.

2. INGENIERA DE SOFTWARE
2.1 FUNDAMENTACIN
La justificacin de la existencia de la Ingeniera de Software la podemos encontrar en la
frecuencia con que situaciones como las que a continuacin se enlistan se presentan en el
desarrollo de proyectos y productos software:

Proyectos fuera de plazo y presupuesto.

Desarrollos lentos.
Elevadas cargas de mantenimiento.
Elevado coste de correccin de errores en el desarrollo.
Baja calidad y confiabilidad del producto.
Dependencia de los desarrolladores.

Cuevas [cue95] atribuye estas situaciones indeseables a las siguientes causas

principalmente:

Falta de formalismo y metodologa.

Falta de administracin eficaz.
Falta de herramientas de soporte.
Interfase humano inadecuado.
Consideracin del instrumento software como un fin en s mismo.

La Ingeniera de Software pretende proporcionar elementos para evitar estas causas de las
situaciones indeseables listadas y promover el uso de tcnicas, herramientas y metodologas
adecuadas a la solucin de problemas mediante software. .
2.2. PRINCIPIOS BSICOS DE LA INGENIERA DE SOFTWARE
Bohem propuso en 1985 siete principios bsicos de la Ingeniera de Software para asegurar
el xito en el desarrollo de un producto software. Estos principios han tenido una
aceptacin bastante generalizada en el mundo:
1.
2.
3.
4.
5.
6.
7.

Direccin por medio del uso de un plan por fases del Ciclo de Vida.
Realizacin de validaciones continuas.
Mantenimiento del control del producto estricto.
Uso de tcnicas modernas de programacin
Mantenimiento de una contabilidad clara de la situacin del proyecto
Usar menos y mejor personal
Mantener un compromiso de mejora del proceso

1. DIRECCIN POR MEDIO DEL USO DE UN PLAN

POR FASES DEL CICLO DE VIDA.
Metzger seala que de todos los proyectos realizados sin xito, el 50% lo han sido por una
deficiente planeacin. propone los siguientes puntos para ser incluidos en un plan:

Sumario del Proyecto.

Plan de hitos de las fases.
Plan de control del proyecto.
Plan de control del producto.
Plan de validacin
Plan de operaciones y mantenimiento

2. REALIZACIN DE VALIDACIONES CONTINUAS.

La importancia de detectar y corregir los errores cuanto antes estriba en evitar altos costos
de aplazar esta deteccin y correccin hasta finales del proyecto. En la fase ltima el
proceso resulta el ms costoso.
Dos razones principales hacen que este error sea tan indeseable:
Los errores han sido hechos antes del inicio de la codificacin, e irlos arrastrando significa
pasar por alto otros posibles errores o dificultades para realizar una evaluacin objetiva del
avance.
Cada fase del proceso de desarrollo del software requiere incluir una actividad de
validacin explcita.
3. MANTENIMIENTO DEL CONTROL DEL PRODUCTO ESTRICTO.
Difcilmente la compatibilidad entre la comprensin del proyecto por parte del usuario y
del desarrollador se da totalmente desde el principio del proyecto; por el contrario, esto va
logrndose en el transcurso del proceso de realizacin, lo cual implica, entre otras cosas, la
necesidad de acomodar cambios en los requerimientos. Estos cambios se hacen necesarios
adems por cambios en el entorno externo como las polticas gubernamentales o mejoras en
la tecnologa.
La importancia de mantener un control estricto del producto radica en que cuando los
usuarios se dan cuenta de que el sistema es diferente de aquel para el que han estado
preparndose, debido a la necesidad de los cambios mencionados, se necesita mucho

tiempo, dinero y esfuerzo para rectificar. El control estricto minimiza este tipo de
situaciones.
Un sistema efectivo de control del producto es el denominado lnea base, que consiste en
un documento programa que experimenta un proceso de aprobacin y despus puede ser
modificado slo mediante procedimientos formales.
4. USO DE TCNICAS MODERNAS DE PROGRAMACIN.
Hoy en da se dispone de gran cantidad de herramientas para el proceso de desarrollo de un
producto software, la orientacin a objetos, la programacin estructurada, la programacin
por componente y la programacin extrema entre otras facilitan el desarrollo y
mantenimiento de software, abatiendo los costos y el tiempo necesarios para la terminacin
del producto, pero sobre todo para lograr posibles correcciones y/o modificaciones de
manera eficiente.
5. MANTENIMIENTO DE UNA CONTABILIDAD CLARA
DE LA SITUACIN DEL PROYECTO
Como cualquier proyecto, las actividades que se llevarn a efecto durante el proceso de
desarrollo de un producto software sern consumidoras de recursos. Cada una de estas
actividades deber controlarse no solamente por cuanto al avance y logro de los objetivos,
sino por el consumo de recursos que originalmente se le haban asignado, evitando
ambigedades.
Para llevar a cabo esto de forma gil y a bajo costo se cuenta con herramientas de ayuda
que realizan clculos de planificacin, toman los datos sin intervencin manual y
proporcionan informes.
PRINCIPIO 6. Usar menos y mejor personal.
Una razn para este principio es la amplia gama de productividad software entre
individuos 26:1 han sido datos medidos.
Otra razn es la prdida de productividad de los programadores cuando se amplia el
grupo por la prdida de tiempo en las comunicaciones del grupo.
Estas prdidas vienen marcadas por la frmula K(n-1)n/2, donde K es la prdida por
comunicacin y (n-1)n/2 el nmero de enlaces de comunicacin establecidos por n
personas.
Esta segunda razn es tan fundamental que ha dado lugar a una definicin generalmente
aceptada establecida por Brooks: Cuando un proyecto est retrasado no se debe

intentar nunca recuperar el retraso aadiendo recursos. Si se procede de esta manera, se

retrasa ms
En general como tamao lmite de un grupo no debe superarse el valor 10. Si el
proyecto es de gran envergadura se dividir en subproyectos que no superen las
limitaciones anteriores.
PRINCIPIO 7. Mantener un compromiso de mejora del proceso.
Esto implica no solo analizar nuevas tcnicas prometedoras, sino tambin establecer
planes de evaluacin del efecto de la utilizacin de dichas tcnicas. Requiere recogida
de datos para ver donde estn los cuellos de botella, donde se gasta ms dinero y donde
las estimaciones son ms pobres. Pueden usarse para comparar el resultado con la
aplicacin de nuevas tcnicas y para la estimacin de nuevos proyectos.
Otro aspecto importante de este principio es mantener la perspectiva, es decir, debe
asegurase que los principios sirven de estmulo para la mejor realizacin del proyecto.
En caso de estar un principio en conflicto, el sentido comn debe prevalecer y deber
adaptarse el principio.
2.3. PROCESO DE LA INGENIERA DEL SOFTWARE.
Se puede definir como un conjunto de actividades, mtodos y prcticas que guan a las
personas (y sus herramientas software) en la produccin de software.
El proceso software es llevado a cabo por personas que usan: Herramientas, tcnicas y
metodologas. En la siguiente figura se muestran los aspectos a tener en cuenta para un
proceso efectivo.
Los factores que determinan el proceso software son: Poltica, Tecnologa, Economa e
Ingeniera del software, costumbre, cultura, estndares y obligaciones contractuales.

Interrelaciones de todas
las tareas requeridas

Herramientas y
Mtodos usados

Cualificacin, formacin
Motivacin, y direccin
personal.

Entre los beneficios de un buen proceso tenemos:

Mejora el uso de los recursos humanos

Proporciona un mecanismo para aprender experiencias de otros
Reduce repeticin de trabajos
Proporciona ms tiempo para gastar en los problemas que requieren energa y
creatividad
Incrementa la probabilidad de introducir tecnologa con xito
Proporciona mejora continuada de capacidades de produccin de software

En el proceso de la Inteligencia del software (en la siguiente figura) hemos de tener en

cuenta una serie de componentes a saber:
-

Formalismos o teoras base para el desarrollo de los dems componentes

Componentes de la administracin del proyecto
Tcnicas y metodologas de desarrollo y mantenimiento
Herramientas CASE

Ciclo de Vida

Admn.

* Requerimientos

MODELOS
DE

CASE

COMPUTACIN

INGENIERO
DE
SOFTWARE

Mtodologia

* Especificaciones
* Diseo
* Realizacin
* Mantenimiento

Experto

Todas las cuales permiten cubrir el ciclo de vida del software: requerimientos,
especificaciones, diseo, realizacin y mantenimiento.

Adems de estos componentes, otros dos fundamentales, son el usuario conocedor del
problema y de las necesidades y el ingeniero de software conocedor y dominador de los
componentes tcnicos y capaz de plasmar en un producto software en una organizacin, la
solucin a las necesidades planteadas por el usuario.
Se puede considerar la Ingeniera del software como una coleccin de tecnologas
entrelazadas que debern ser consideradas como un sistema. (Tecnologas de la ingeniera
de Software)

2.4 TECNOLOGAS CASE Y ENTORNOS DE DESARROLLO

Las ayudas que la automatizacin de procesos, es decir la computadora, proporciona a la
Ingeniera de software, en todas las fases del ciclo de vida de un producto software reciben
el nombre genrico de tecnologas CASE (Computer Aided Software Engineering) o
ayudas de la computadora a la ingeniera de software.
Una manera general de clasificar las tecnologa CASE es en base a las herramientas que
utilizan: As las herramientas para anlisis y diseo definen tecnologas CASE de FRONT
END, las herramientas para desarrollo y pruebas definen tecnologas CASE de BACK END
y herramientas integradas, aplicables a todo el ciclo de vida del software, definen las
llamadas tecnologas CASE de WORK BENCH
Estas ayudas o tecnologas, basadas fundamentalmente en herramientas automatizadas,
sustentan los mtodos y procedimientos utilizados en el desarrollo de productos software.

METODOS
Anlisis
Diseo
Codificacin
Pruebas

PROCEDIMIENTOS
Admn. De proyecto
Garanta de calidad
Software
Admn.Config. Software
Medidas de Seguimiento

CASE (HERRAMIENTAS)

De la misma manera, los procesos software se ven apoyados y acompaados por estas
tecnologas, desde el surgimiento de un problema software, el diseo, las pruebas, la
garanta de calidad, la configuracin del software, y la administracin de todo el proyecto,
incluyendo el establecimiento de su obsolescencia.
(Anlisis de los Requerimientos)

PROBLEMA

RECOLECCIN
DE
REQUERIMIENTOS PROTOTIPO
ESPECIFICACIONES
ESCRITAS

REVISIN
CLIENTE

(DISEO DE SOFTWARE) Ncleo tcnico de la ingeniera del software la fuente de la

calidad del software.

Diseo
Procedimiento
Diseo
Arquitectura
Diseo
Datos (Modelo de datos)

(PRUEBAS DEL SOFTWARE) Una de las reas ms exigentes y despreciadas de la

ingeniera del software son las pruebas. Este desprecio se debe a tres razones
fundamentales: La creencia de que resulta suficiente la funcionalidad observada por el
desarrollador, el costo y tiempo que consumen las pruebas mismas y su naturaleza
destructiva (la prueba solamente se considera exitosa cuando logra encontrar alguna falla).
No obstante, la Ingeniera de Software ha demostrado la rentabilidad de la inversin de
tiempo y esfuerzo en un adecuado diseo y desarrollo de pruebas.

DISEO DE
CASOS
PRUEBAS

Tcnicas caja
blanca

Pruebas
Sistemas

(DISEO)
Beta
Test

Tcnicas caja
Negra

ESTRATEGIAS
PRUEBAS

Pruebas
Unidades
Pruebas
Integrales

Pruebas
Validaciones

(GARANTA DE LA CALIDAD DEL SOFTWARE) Conjunto de actividades cuyo

principal propsito es asegurar la calidad del software.

REVISIONES

PRUEBAS

G.C.S
ADMINISTRACIN
CONFIGURACIN
SOFTWARE

ESTNDARES
Y
PROCEDIMIENTOS

(CONFIGURACIN DE SOFTWARE) Los cambios producen deterioro del software, los

controles deben establecerse para que los cambios no introduzcan defectos.

CONFIGURACION DE
SOFTWARE
Identificacin

Facilidad de
fabricacin

PROGRAMAS
DOCUMENTOS
DATOS

Control de
versin

Control
cambio

Informe de
Auditoria

(ADMINISTRACIN DEL PROYECTO SOFTWARE) Coleccin de actividades que

llevan a una planificacin y control efectivos de un proyecto software.

Planificacin del proyecto software (estimacin coste/esfuerzo)

Plan de proyecto (actividad)

Medida y Seguimiento
Garanta de Software
Administracin configuracin de software

2.5 TENDENCIAS
Indudablemente el uso de herramientas y tecnologa automatizadas para la Ingeniera de
Software se ha extendido rpidamente, dando lugar a otras herramientas y metodologas
para el desarrollo de software como son el uso de objetos y agentes. Esta tendencia parece
irreversible a favor de facilidades para el desarrollador y disminucin de tiempo y costo
para el usuario.
As, podemos prever en el futuro inmediato y con tendencia creciente al mediano y largo
plazo (de hecho hemos iniciado una etapa dentro de este paradigma), software abundante,
elaborado en forma rpida, muy eficiente y a muy bajo costo o incluso gratuito para el
usuario. Organizaciones internacionales como la Free Software Foundation promueven esta
tendencia y han logrado una difusin y proliferacin de impacto en el mercado.
Sin embargo, la Ingeniera de Software no solamente ha contribuido a estas expectativas,
sino que avanza en apoyo de actividades complementarias al desarrollo de software,
proporcionando metodologas, herramientas y tcnicas para la planeacin de la produccin
de software, el anlisis y diseo de sistemas, apoyo a servicios como asesora y
capacitacin, implantacin y mantenimiento de sistemas de informacin y otras
aplicaciones.
En sntesis, el panorama que presenta la industria de software es sumamente atractivo para
el usuario final, tanto por disponibilidad como por costo, y el campo de aplicacin de la
Ingeniera de Software sigue siendo suficientemente amplio como para entender porqu
esta disciplina ocupa un lugar tan importante en los planes de estudio de informtica,
computacin, sistemas y reas afines de todas las universidades del mundo de prestigio y en
la industria de desarrollo de software e integracin de soluciones informticas en las
empresas.
2.6 METODOLOGAS PARA LA SOLUCIN DE PROBLEMAS
Si consideramos un problema como una situacin que se presenta en la que se sabe ms o
menos, o con toda claridad, a dnde se quiere ir, pero no se sabe cmo; entonces resolver
un problema es precisamente aclarar dicha situacin y encontrar algn camino adecuado
que lleve a la meta.
A veces no sabremos si la herramienta adecuada para la situacin est entre la coleccin de
tcnicas que dominamos o ni siquiera si se ha creado una tcnica que pueda ser
suficientemente potente para resolver el problema. Esta es precisamente la circunstancia del
investigador, en matemticas y en cualquier otro campo, y por otra parte, sta es la
situacin en la que nos encontramos a veces en nuestra vida normal.
La destreza para resolver genuinos problemas es un verdadero arte que se aprende con
paciencia y considerable esfuerzo, enfrentndose con tranquilidad, sin angustias, a multitud
de problemas diversos, tratando de sacar el mejor partido posible de los muchos seguros
fracasos iniciales, observando los modos de proceder, comparndolos con los de los
expertos y procurando ajustar adecuadamente los procesos de pensamiento a los de ellos.

Es la misma forma de transmisin que la de cualquier otro arte, como el de la pintura, la

msica, etc.
Las estrategias que tendremos ocasin de aprender y ejercitar son:
A. Comenzar resolviendo un problema semejante ms fcil.
B. Hacer experimentos, observar, busca pautas, regularidades
C. Hacer conjeturas. Tratar de demostrarlas.
D. Dibujar una figura, un esquema, un diagrama.
E. Escoger un lenguaje adecuado, una notacin apropiada.
F. Induccin.
G. Supongamos que no es as.
H. Supongamos el problema resuelto.
I. Si tenemos una receta y estamos seguros de que se ajusta al problema, apliqumosla.
Lo que pretende un algoritmo es sintetizar de alguna forma una tarea, clculo o mecanismo
antes de ser transcrito al ordenador.
Los pasos que hay que seguir son los siguientes:
Anlisis previo del problema.
Primera visin del mtodo de resolucin.
Descomposicin en mdulos.
(Programacin estructurada).
Bsqueda de soluciones parciales.
Ensamblaje de soluciones finales.

Planteamiento algortmico de soluciones a un problema

Metodologa de desarrollo de software:: Existen muchos mtodos, metodologas,
principios, etc. para solucionar problemas. El ms utilizado en la mayora de las reas es el
de cascada. Llamado as por su semejanza con la naturaleza. Se hace una etapa, se termina,
se sigue con la siguiente, y as hasta terminar. A este tipo de metodologas le falta el
proceso de ITERACION, el cual es muy importante y bsico para realmente obtener una
solucin con calidad.

Anlisis
Diseo
Implementacin
Pruebas
Documentacin
Mantenimiento.

Anlisis

Qu se necesita obtener?.
Simplemente es describir lo que se busca resolver: CONTESTAR A LA PREGUNTA QUE.
Se tienen varios tipos de anlisis, dependiendo del problema que se requiera resolver y del
paradigma que se desee seguir (Top-Down, Bottom-Up, Estructurado, Orientado a Objetos,
HIPO, etc). Una manera de definir los requerimientos y salidas es usando el proceso TopDown. En este punto se listan las entradas, las salidas y los procesos.
Diseo
Escribir un algoritmo de solucin, es decir, encontrar la solucin al problema a lpiz. Se
escriben los pasos y secuencias necesarias para llegar a la solucin; es el definir con ms
exactitud el proceso que se describi en la fase del anlisis. El diseo es totalmente
independiente del lenguaje computacional y computadora que se van a utilizar.
As como en el anlisis, hay diversos tipos de elaborar el diseo (Diagrama de Flujo,
Estructurado, Top-Down, Orientado a Objetos, etc.): CONTESTAR A LA PREGUNTA
COMO
El algoritmo se puede elaborar en forma:
Grfica, usando un diagrama de flujo.
De pseudo cdigo.
Implementacin
Programar a partir del diseo usando un lenguaje computacional y compilarlo sin encontrar
errores. Si se encuentran estos ltimos, corregir y ciclar este proceso hasta que el programa
quede limpio de errores. Tratar de hacerlo bien la primera vez (calidad). Esta fase en
realidad depende del conocimiento que se tenga sobre el lenguaje con el cual se va a
desarrollar.
Cabe mencionar que la palabra "implementacin" no existe en el idioma espaol, esta fase
tambin se le conoce con el nombre de "desarrollo e implantacin".
Pruebas y validacin
Se corre el programa con datos reales y lmites permitidos para constatar si cumple con
todos los requerimientos planteados desde el anlisis.
Documentacin
La fase ms olvidada por todos los desarrolladores. El anlisis y diseo e implementacin
forman parte de la documentacin.
Dentro del programa
Se documenta el programa en el editor del lenguaje usado (si no se hizo mientras se
program)
Fuera del programa : Manuales
Se obtiene un manual del usuario o de operacin (especificando requerimientos, proceso de
inicio, etc. ) y uno tcnico (impresin de los listados actualizados).
Mantenimiento

Acoplar el programa a cambios externos que lo puedan afectar. No debe ser mantenimiento
correctivo.
Algoritmo de solucin.
Informalmente un algoritmo se define como cualquier procedimiento computacional bien
definido que toma algn(os) valor(es) como entrada y produce un(os) valor(es) de salida.
Un algoritmo es una secuencia de pasos que transforma esos datos de entrada en datos de
salida.
Analizamos algoritmos para predecir los recursos que los algoritmos consumir.
Ocasionalmente memoria, medios de comunicacin, pero el recurso ms importante que
medimos es el tiempo que tomar en ejecutarse el programa que tiene implementado
nuestro algoritmo.
Dentro del anlisis de algoritmos se concentran principalmente en determinar el peor de los
casos para el cual se ejecutar el algoritmo, se indican principalmente tres razones para
ello:
1. El saber el peor de los casos nos garantiza que nuestro algoritmo nunca tomar ms
tiempo del que ya sabemos.
2. Para algunos algoritmos, el peor de los casos ocurre ms frecuentemente que el
mejor de los casos, por ejemplo dentro de un manejador de base de datos.
3. El caso promedio es regularmente ms malo que el peor de los casos. Por qu?,
Porque para determinar el promedio que hacemos buscamos el mejor de los casos,
posteriormente buscamos el peor de los casos y sacamos promedio Ilgico, no?, Si
ya sabemos el peor de los casos para que determinamos el promedio.
Divide y conquistars.
Una de las tcnicas ms usadas en la implementacin de algoritmos es la recursin,
comnmente llamada "divide y conquistars".
Los algoritmos recursivos generalmente dividen el problema original en subproblemas
similares al original pero de tamao menor, los resuelven y posteriormente combinan las
soluciones parciales para llegar a una solucin general.
El paradigma de divide y conquistars involucra tres pasos para cada nivel de recursin:
Divide el problema en subproblemas.
1. Conquista los subproblemas resolvindolos recursivamente. Si el subproblema es
suficientemente pequeo resulvelo de la manera ms sencilla.
2. Combina la solucin de los subproblemas para obtener la solucin del problema
original.
Uno de los mejores ejemplos para el problema de divide y conquistars es el que se
presenta en el ordenamiento por mezcla (merge sort) el cual se presenta en la siguiente
seccin ordenamientos.
Un problema es resuelto algortmicamente, si se puede escribir un programa que pueda
producir la respuesta correcta de forma que para cualquier posible entrada, el programa

puede ser ejecutado el tiempo (finito) suficiente para resolverlo y cuenta adems con el
espacio requerido para resolverlo.
A principios del siglo XX, hubo una gran actividad para formalizar y estudiar el concepto
de algoritmo. Los algoritmos se consideraron desde entonces como un conjunto de
instrucciones simples, las cuales pueden ser interpretadas fcilmente, de modo que al
seguirlas se resuelva un problema se calcule el valor de una funcin.
Dentro de los investigadores de principios del siglo XX, destaca Allan Turing, por dos
razones:
1) El desarrollo de la Mquina de Turing y su relacin con los algoritmos. Dicha relacin
establece que todo algoritmo puede ser conceptualizado como una mquina, que ejecuta sus
instrucciones.
2) La demostracin de que no se puede resolver el problema denominado "Halting
Problem". Este problema consiste en determinar si existe no un algoritmo que determine
si un programa arbitrario de computadora, eventualmente termina para una entrada
cualquiera del programa. De acuerdo con Turing no existe ningn programa de
computadora que resuelva este problema.
Estos dos aspectos llevaron al desarrollo de la Teora de la Computabilidad (TC). Sin
embargo, aun cuando la TC es un aspecto fundamental en Ciencias Computacionales, el
saber que desde el punto de vista terico, un problema, puede o no ser resuelto en una
computadora, no es suficiente para decirnos si en la prctica ser. Se podra, por ejemplo
pensar en un procedimiento para que una mquina juegue ajedrez perfecto, tomando en
cuenta lo siguiente:
1) Existe solo un nmero finito de formas de arreglarlas piezas de ajedrez sobre el tablero.
2) Bajo ciertas reglas, el juego termina despus de un nmero finito de movimientos.
3) Considerar para cada posible movimiento de la computadora, todas las posibles
respuestas del oponente y, para cada una de estas, las posibles respuestas de la computadora
y, as sucesivamente, hasta que cada secuencia alcance el final. Entonces, conociendo el
ltimo resultado de cada movimiento, todo lo que se tendra que hacer es escoger el mejor
movimiento inicial.
Sin embargo, hay un inconveniente serio en el procedimiento anterior, el nmero de
posibles arreglos de piezas es alrededor de 10 50, de modo que un buen programa podra
tardar varios miles de aos.
Como consecuencia, no obstante que existe un procedimiento para el juego perfecto de
ajedrez, no existe an un algoritmo, que alguien podra escribir un programa siguiendo
dicho procedimiento
Como el anterior, hay muchos problemas, para las cuales se puede escribir un
procedimiento y por tanto podramos decir que pueden ser resueltas; es decir que se pueden

escribir programas para dichas aplicaciones y que por tanto podramos pensar que existen
algoritmos para ellos. Sin embargo, los requerimientos de tiempo y espacio de
almacenamiento son tan grandes que esos programas no son de importancia prctica. Estos
aspectos se estudian en un rea denominada Complejidad Computacional y, a la cual le
dedicaremos una sesin mas adelante.
La Complejidad Computacional cubre varios aspectos; una de ellas trata con aspectos
formales, que tratan sobre las bases matemticas para probar la computabilidad de
funciones computables. Esto es de inters para saber si en teora, para un problema existe o
no un algoritmo. Otro aspecto tiene que ver con la eficiencia de los algoritmos desde el
punto de vista de tiempo y espacio. En este ltimo aspecto, se centra el Anlisis de
Algoritmos. El anlisis de algoritmos estudia de esta forma en dos aspectos:
1) El anlisis de problemas especficos.
2) El anlisis de algoritmos especficos.
Dicho estudio permite determinar mtodos adecuados de diseo para problemas prcticos.
El anlisis de algoritmos permite entonces determinar, para un problema en particular, si un
algoritmo determinado cumple o no con los requerimientos mnimos de tiempo y espacio.
Esto lleva en consecuencia a una mejor toma de decisiones en la solucin de problemas.
Clasificacin de problemas
Antes de dar una clasificacin de problemas, conviene empezar a describir la palabra
problema.
Podremos pensar en problema de diferentes maneras, una de ellas es la siguiente [Gary &
Johnson]
"Un problema ser una cuestin general que debe ser contestada. Usualmente, un problema
posee varios parmetros, variables libres (cuyos valores son dejados sin especificar)".
De acuerdo con [Gary & Johnson], un problema queda descrito cuando se proporciona:
1) Una descripcin general de todos sus parmetros y
2) Una descripcin de cuales propiedades son requeridas para que la respuesta (o solucin)
sea satisfactoria
Una instancia de un problema se obtiene especificando valores particulares para todos los
parmetros del problema.
Consideremos por ejemplo el problema SAT, ste problema consiste en determinar valores
de verdad que satisfagan una formula lgica del tipo normal conjuntiva. De esta manera la
siguiente son instancias del problema SAT:
~X1 & (X2 V X3)
(X1 v ~X2) & (X1 v ~X3 v X4) & (X2 v ~X4)

Otro ejemplo, es el Problema del Agente viajero, que se describe a continuacin. Se trata de
recorrer N ciudades, partiendo de una ciudad origen, pasar por todas las otras ciudades una
sola vez y regresa a la ciudad destino con un recorrido total mnimo. Una instancia de ese
problema sera recorrer todas las ciudades del Estado de California, partiendo desde la
ciudad de los ngeles.
Si las ciudades se numeran digamos como C= {c1,c2, c3,..,} con distancias d = {d12,
d13 ...} entonces una solucin del problema del agente viajero, sera una secuencia de
elementos de C, Los diferentes posibles casos del problema del agente viajero, se conocen
como instancias.
Por otra parte, como ya hemos establecido, podemos pensar en los algoritmos como
procedimientos paso a paso, que resuelven problemas. Por esta razn, es lgico pensar, que
no todos los problemas tienen algoritmos eficientes para todas sus instancias.
Hacemos notar que cuando decimos que se tiene un algoritmo para un problema cuando es
capaz de encontrar una solucin para l; esto no significa que realmente lo resuelve!!. As
por ejemplo C' y C'' son soluciones que pudieron ser encontradas por un algoritmo, aun
cuando ninguna de ellas sea el recorrido mnimo.
Para cada algoritmo se puede, en principio construir las funciones del tiempo requerido por
el algoritmo, en trminos de la longitud de la entrada. De esta manera se puede obtener una
funcin del tamao del problema, contra el tiempo requerido para resolverlo. Esta funcin
es conocida como complejidad temporal del algoritmo.
Dado que cada instancia de un problema pudiera tener diferentes parmetros que pudieran
cambiar, con frecuencia se toma como medida del tiempo requerido para medir la
complejidad de un algortimo, el del peor caso. Esto tambin puede, desde luego, ser
realizado para el caso de la cantidad de memoria requerida (complejidad espacial).
El caso ms estudiado se refiere a la complejidad temporal. a continuacin se presenta una
clasificacin de algoritmos en trminos de su complejidad temporal que estudiaremos en
este curso:
lineal:
Cuadrada:
Cbica:
exponencial

f(n) = n
f(n) = n2
f(n) = n3
f(n) = 2 n, 3 n, 4 n, 2.71 n

Para un problema dado, los algoritmos que son una funcin polinomial del tamao de la
entrada (por ejemplo: n, n2 ,n3,..), mientras que aquellos que no lo son se llaman nopolinomiales.
2.7. EL CICLO DE VIDA

El primer modelo de proceso de desarrollo de software que se publico se deriv de otros

procesos de ingeniera (Royce.1970). ste se muestra en la figura 3.1 .Debido a la cascada
de una fase a otra, este modelo se conoce como modelos cascada o como un ciclo de vida
del software. Las principales etapas de este modelo se transforman en actividades
fundamentales de desarrollo:
1. Anlisis y definicin de requerimientos. Los servicios , restricciones y metas del
sistema se definen a partir de las consultas en detalle y sirven como una
especificacin del sistema.
2. Diseo de sistemas y software . El proceso de diseo de sistemas divide los
requerimientos en sistemas de hardware o de software. Establece una arquitectura
completa del sistema. El diseo de software identifica y describe las abstracciones
fundamentales del sistema de software y sus relaciones.
3. Implementacin y prueba del sistema. Durante esta etapa, el diseo de software se
lleva a cabo como un conjunto o unidades de programas. 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 la pruebas, el sistema de
software se entrega al usuario.
5. Operacin y mantenimiento. Por lo general (aunque no necesariamente) , sta es la
fase ms grande del ciclo de vida. El sistema se instala y
Definicin
de
pone en uso prctico. El mantenimiento implica corregir
Definicin de
errores no descubiertos en las etapas anteriores del
requerimientos
requerimientos
ciclo de vida, mejorar la implementacin de las
unidades del sistema y resaltar los servicios del
sistema una vez que se descubren nuevos
Diseo
de
sistemas
y
requerimientos.
Diseo de sistemas y
dedesoftware
software

Implementacin
Implementacinyy
prueba
pruebadedeunidades
unidades

Integracin
Integracinyyprueba
prueba
del
delsistema
sistema

Operacin
Operacinyy
mantenimiento

UNIDAD III
3. HERRAMIENTAS DE MODELADO
3.1. CONCEPTOS
Anlisis Tcnico
Durante el anlisis tcnico, evala los mritos tcnicos del concepto de sistema,
mientras que al mismo tiempo recoge informacin adicional sobre el rendimiento, la
fiabilidad, la facilidad de mantenimiento y la posibilidad de produccin. En algunos casos
la etapa de anlisis del sistema tambin incluye una cantidad limitada de investigacin y
diseo.
El anlisis tcnico empieza con una definicin de la viabilidad tcnica del sistema
propuesto.
Las herramientas disponibles para el anlisis tcnico se derivan de la modelizacin y
optimizacin matemticas, la probabilidad y estadstica, la teora de colas y la teora de
control, por nombrar una pocas. Es importante tener en cuenta que la evaluacin analtica
no es siempre posible.
La modelizacin
Es un mecanismo efectivo para el anlisis tcnico de sistemas basados en computadora, la
siguiente figura ilustra el flujo global de informacin en el proceso de modelizacin. Un
modelo se crea basndose en la observacin del mundo real o una aproximacin basada en
los objetivos del sistema.

MUNDO REAL

MODELO
* Observacin
* Medidas
* Suposiciones
* Aproximaciones
* Predicciones

Datos

Parmetros

Estructura
Percibida
* Verificacin
* Modificacin
* Interpretacin
Comportamiento
observado
* Intuicin
* Experiencia
* Teora

Representacin
Simblica

Modelo de
Comportamiento

El analista comprueba el comportamiento del modelo y lo compara con el mundo real o al

sistema esperado. Blanchard y Fabrycky definen un conjunto de criterios para el uso de
modelos durante el anlisis tcnico de los sistemas.
1. El modelo debe representar la dinmica de la configuracin del sistema que est
siendo evaluado de una forma que sea suficientemente simple de comprender y
manipular, y tambin que est lo suficientemente cerca de la realidad operativa
como para obtener resultados satisfactorios.
2. El modelo debe realzar aquellos factores que sean ms relevantes para el problema
en cuestin y suprimir aquellos que no sean importantes.
3. El modelo debe ser amplio para incluir todos los factores relevantes y ser fiable en
trminos de rentabilidad de resultados.

4. El diseo del modelo debe ser los suficientemente simple como para permitir una
rpida implementacin en la resolucin de problemas.
5. El diseo del modelo debe incorporar previsiones para poder modificarlo y/o
expandirlo fcilmente y permitir la evaluacin de factores adicionales si se
requieren. El desarrollo satisfactorio del modelo a menudo incluye una serie de
intentos antes de que el objetivos final se alcance. Los intentos iniciales pueden
sugerir lagunas de informacin que no son aparentes inmediatamente y en
consecuencia pueden sugerir cambios beneficiosos.
Los resultados obtenidos del anlisis tcnico forman la base para otra decisin en el
sistema de tipo seguir /o no seguir. Si el riesgo tcnico es alto, si los modelos indican
que la funcionalidad deseada o el rendimiento no puede ser alcanzado, si las piezas no
encajan bien, hay que volver a la mesa de trabajo.
3.2 CARACTERSTICAS DE LAS HERRAMIENTAS
En la pasada dcada se desarrollaron varios mtodos de anlisis y especificaciones del
software. Los investigadores han identificado los problemas y sus causas y desarrollado
reglas y procedimientos para resolverlos. Cada mtodo de anlisis tiene una nica
notacin y punto de vista. Sin embargo todos los mtodos de anlisis estn relacionados
por un conjunto de principios fundamentales:
1. El dominio de la informacin, as como el dominio funcional de un problema debe
ser representado y comprometido.
2. El problema debe subdividirse de tal forma que se descubran los detalles de una
manera progresiva (o jerrquica)
3. Deben desarrollarse las representaciones lgicas y fsicas del sistema.
Aplicando estos principios, el analista enfoca el problema sistemticamente. Se examina el
dominio de la informacin de forma que pueda comprenderse su funcin ms
completamente. La particin se aplica para reducir la complejidad.
EL DOMINIO DE LA INFORMACIN:
Todas las aplicaciones del software pueden colectivamente llamarse procesamiento de
datos. Este trmino contiene la clave de lo que entendemos por requerimientos de software.
El software se construye para procesar datos, para transformar de una forma a otra; esto es,
para aceptar entradas, manipularlas de alguna forma y producir una salida. Este
establecimiento fundamental de los objetivos es verdad tanto si construimos software por
lotes para un sistema de nminas, como software empotrado en tiempo real para controlar
el flujo de la gasolina de un motor de un automvil.

El dominio de la informacin contiene 3 visiones:

1. El flujo de informacin
2. El contenido de la informacin
3. La estructura de la informacin
El flujo de la informacin representa la manera en la que los datos cambian conforme pasan
a travs de un sistema. En la siguiente figura la entrada se transforma en datos intermedios
y ms adelante se transforman en la salida.

Datos de Entrada

TRANSFORMAR # 1

Datos Intermedios

Almacn de
Datos

TRANSFORMAR # 2

Datos de Salida

El contenido de la informacin representa los elementos de datos individuales que

componen otros elementos mayores de informacin. Por ejemplo, un registro de nmina

es un elemento de informacin que est formado por un nmero de empleado, un sueldo,

salarios anuales, impuestos anuales, etc.
El contenido de un registro de nmina queda definido por los elementos contenidos en
l.
La estructura de la informacin representa la organizacin lgica de los distintos
elementos de datos.
PARTICIN
Normalmente los problemas son demasiado grandes y complejos para ser comprendidos
como un todo. Por esta razn, tendemos a particionar (dividir) tales problemas en partes
que puedan ser fcilmente comprendidas y establecer interfaces entre las partes, de forma
que se realice la funcin global. Durante el anlisis de requerimientos, el dominio
funcional y el dominio de la informacin del software pueden ser particionados.
En esencia la particin descompone un problema en sus partes constituyentes.
Conceptualmente, establecemos una representacin jerrquica de la funcin o informacin
y luego partimos el elemento superior mediante:
1) Incremento de los detalles, movindonos verticalmente en la jerarqua.
2) Descomponiendo funcionalmente el problema, movindonos horizontalmente en
la jerarqua.
SCCT debe desarrollarse de forma que las cajas que se mueven a lo largo de la cinta
transportadora se identificarn y clasificarn en 6 cubos al final de la cinta. Las cajas
pasarn por una estacin de clasificacin donde sern identificadas.
Las caractersticas del software para SCCT puede establecerse en la siguiente forma:
El software SCCT recibir la informacin de entrada de acuerdo con un lector de
cdigos de barras a intervalos de tiempo que estn de acuerdo con la velocidad de la cinta
transportadora. Los datos del cdigo de barras se decodificaran en un formato de
identificacin de caja. El software examinar una base de datos de unas 1000 entradas
para determinar la posicin adecuada del cubo para la caja que actualmente est en el
lector. Se usar una lista FIFO para tomar nota de las posiciones de envo de cada caja
conforme se mueve por la estacin de clasificacin.
El software SCCT tambin recibir entrada de un tacmetro de pulso que se usar para
sincronizar la seal de control con el mecanismo de envo . Basndose en el nmero de
pulsos que se generarn entre la estacin de ordenacin y el envo, el software producir
una seal de control a la estacin de envo, indicando la posicin correspondiente de la
caja....

Los requerimientos para el software SCCT deben ser analizados subdividiendo el

dominio funcional del problema, la siguiente figura ilustra una descomposicin
horizontalmente en la jerarqua funcional. En el primer nivel de la jerarqua se encuentran
las cuatro funciones principales.
Software de SCCT

Leer datos del

Cdigo de barras

Decodificar el ID de las
Cajas y buscar la posicin

Leer pulso del

taqumetro

Generar seal de control para

Mecanismo de desviacin

Particin Horizontal

Las subfunciones asociadas con una funcin principal del SCCT, pueden examinarse
exponiendo los detalles verticalmente en la jerarqua, como se ilustra en la siguiente figura:
Software de SCCT

Leer datos del

Cdigo de barras

Decodificar el ID de las
Cajas y buscar la posicin

Aplicar el algoritmo de traduccin

Del cdigo de barras

Particin
Vertical

Ejecutar la
Validacin de datos

Leer pulso del

taqumetro

Generar seal de control para

Mecanismo de desviacin

Examinar el fichero de
datos

Procesar datos
No encontrados

Almacenar la posicin
en la lista FIFO

El mtodo de particin que hemos aplicado a la funciones de SCCT puede tambin

aplicarse al dominio de la informacin. De hecho particionar el flujo de informacin
conducir a una descomposicin horizontal de las funciones del programa.
Los elementos de datos que se mueven a travs de la interfase, deben ser restringidos a
las entradas requeridas para ejecutar la funcin establecida y las salidas requeridas por
las otras funciones o elementos del sistema.
VISIONES LGICAS Y FSICAS.

La visin lgica de los requerimientos del software presenta las funciones que han de
realizarse y la informacin que ha de procesarse independientemente de los detalles de
implementacin. Por ejemplo desde un punto de vista lgico, la funcin de leer datos del
cdigo de barras del programa SCCT no se refiere a la forma fsica de los datos o al tipo
del lector de cdigo de barras usado. De hecho, podra argumentarse, que leer datos
podra ser un nombre ms apropiado para esta funcin, puesto que no considera ni siquiera
el mecanismo de entrada. Igualmente un modelo de datos lgico tal como la tabla de los
nmeros de identificacin de paquetes de SCCT, representa sin considerar la estructura de
datos subyacente usada para implementar la tabla. Una representacin lgica de los requerimientos del
software es un fundamento esencial para el diseo.
La visin fsica de los requerimientos del software representa una manifestacin del mundo real de la
funciones de procesamiento y las estructuras de informacin. En algunos casos se desarrolla una
representacin fsica como el primer paso del diseo de software. Sin embargo, la mayora de los sistemas
basados en computador, se especifican de forma que se dictan ciertas recomendaciones fsicas.
Hemos observado que el anlisis de requerimiento de software debe enfocarse sobre lo que el software debe
realizar, en vez de cmo se implementar el procesamiento. Sin embargo, la visin fsica no debe ser
interpretada necesariamente como una representacin del cmo. En vez de ello, el modelo fsico representa
el modo real de operacin; esto es, la asignacin existente o propuesta para todos los elementos del sistema.
El modelo lgico es genrico en el sentido de que la realizacin de la funcin no est indicada
explcitamente.
McMenamin y Palmerham propuesto un mtodo de moderacin que separa la esencia de un sistema de sus
detalles de implementacin. El modelo esencial, como el modelo lgico, describe lo que un sistema debe
realizarse e incluye descripciones de las actividades esenciales y memoria esencial. El modelo de
materializacin, como el modelo fsico, suministra informacin sobre las ligaduras hardware, acoplamiento
del sistema operativo especfico, organizacin y acceso de la base de datos y otros detalles especficos de
implementacin. En muchos casos el anlisis de un sistema alterna entre la especificacin del modelo
esencial y la especificacin del modelo de materializacin.

3.3.

DIAGRAMA DE FLUJOS DE DATOS

La informacin se transforma como un flujo a travs de un sistema basado en

computadora. El sistema acepta entrada de distintas formas; aplica un hardware, software
y elementos humanos para transformar la entrada en salida produce una salida en distintas
formas. La entrada puede ser una seal de control transmitida por un transductor, una serie
de nmeros escritos por un operador humano, un paquete de informacin transmitido por
un enlace a un voluminoso archivo de datos almacenado en memoria secundaria. La
transformacin puede comprender una sencilla comparacin lgica un complejo
algoritmo numrico o un mtodo de inferencia basado en regla de un sistema experto. La
salida puede encender un sencillo Led o producir un informe de 200 pginas. En efecto, un
modelo de flujo de datos puede aplicar cualquier sistema basado en computadora
independientemente del tamao y complejidad.
Una tcnica para representar el flujo de informacin a travs del sistema basado en
computadora se ilustra en la siguiente figura:

Entrada 1

Entrada 2

Sistema
basado en

Salida 1

Salida 2

Computadora
Entrada n

Salida m

La funcin global del sistema se representa como una transformacin sencilla de la

informacin representada como una burbuja. Una o ms entradas, representadas como
flechas con etiqueta, conducen la transformacin para producir el proceso de salida. Puede
tambin observarse que el modelo puede aplicarse a todo el sistema o slo a un elemento
software. La clave es representar la informacin dada y producida por la transformacin.
Conforme la informacin se mueva a travs del software, se modifica mediante una serie
de transformaciones. Un diagrama de flujos de datos (DFD), es una tcnica grfica que
describe el flujo de informacin y las transformaciones que aplican a los datos, conforme se
mueven de la entrada a la salida.

La forma bsica de un DFD se ilustra en la siguiente figura:

Datos 2

Entidad
1

Transfor
m
1
Datos 1

Transfor
m
2

Datos 3

Datos 4

Almacn de Datos

Datos 5
Transfor
m
3

Datos 6
Entidad
2

El diagrama es similar en comparacin de otros diagramas de flujos de actividades.

El DFD puede usarse para representar un sistema o software a cualquier nivel de
abstraccin.
La simbologa de un DFD se ilustra en la siguiente figura:
Entidad Externa:

Una fuente de entradas al sistema, o

fuente de salidas del sistema.

Proceso:

Ejecuta alguna transformacin de sus

datos de entrada, produciendo sus
datos de salida.
Se usa para conectar los procesos
entre si, las fuentes o a los
sumideros; la cabeza de las fechas
indica la direccin de transparencia
de los datos.
Un depsito de datos, la cabeza de
las flechas indica las entradas y
salidas del almacn.

Flujo de datos:

Almacn de datos

Como ejemplo sencillo de un diagrama de flujo de datos, consideremos el flujo de

informacin para una tpica llamada telefnica, siguiente figura:

Voz

El que
llama

Llamada de
Telfono

Sonido

Receptor

Nmero de
Telfono
pulsado

Voz
Vibrador
Al
traductor
de seales

Seal
Electrnica
Sistema
De
comunicacin

Frecuencias
Seal,
teclas y
electrnica

Seal
Electrnica
Seal al
transductor
de
vibraciones

Nmero de
Telfono
pulsado

Como otro ejemplo del uso de diagramas de flujos de datos, consideremos el flujo de
informacin de un sistema de monitorizacin del paciente (SMP) que ha de instalarse en
un hospital, ilustrado con el modelo de DFD de nivel 01 en la siguiente figura:

Sonido

Paciente

Constantes
vitales

Mensaje de
aviso

Sistema de
Monitorizacin
de
pacientes

Informe
Enfermera
Peticin de
Informe
Datos de
informacin

Enfermera
Informacin de Pacientes
Monitoriza las seales vitales de todos los pacientes de una sala, mantiene los requisitos
actualizados sobre todos y cada uno de los pacientes, si algo va mal y produce un informe
de los pacientes segn peticin.
Al llevar el anlisis de los requerimientos del sistema podemos refinar el flujo de
informacin en un DFD de nivel 02 como muestra la siguiente figura:

Paciente

Constante
Vitales

Sistema
De
Monitorizacin
De pacientes

Lmites de los Pacientes

Datos del paciente

Monitorizacin
central
Mensaje de aviso

Lmites de las Constantes

Vitales

Datos del paciente

formateados
Sistema
De
Monitorizacin
De pacientes

Enfermera

Informe

Generador
De informes

Peticin de Informe
Enfermera

Datos de
Informacin

Datos de
Informacin

Informacin de pacientes
El nivel 01 ha sido refinado para mostrar 4 funciones importantes: monitorizacin local
ejecutada por un monitor a lado de la cama, monitorizacin central ejecutada por un cuerpo
de enfermeras, actualizacin de la informacin sobre el paciente y generacin de informes
en la estacin de enfermeras.
El flujo de datos SMP es adems refinado a un nivel 03 en la siguiente figura se muestra la
burbuja de monitorizacin central la cual ha sido refinada para indicar un mayor detalle.

Datos del Paciente

Constantes

Evaluar
Sin
violacin
De lmites

Reloj
Produccin
De
mensaje
De aviso

Formatear
Datos del
paciente

3.4 EL DICCIONARIO DE DATOS

Un diccionario de datos es, simplemente, una lista alfabtica de los nombres que se
incluyen en los diferentes modelos del sistema. Adems del nombre. El diccionario incluye
una descripcin asociada de la entidad nombrada y, si el nombre representa un objeto
compuesto, habr una descripcin de la composicin .Tambin se puede incluir otro tipo de
informacin como la fecha de creacin. el creador y la representacin de la entidad
dependiendo del tipo de modelo que se este desarrollando.
3.5. ESPECIFICACIN DEL PROCESO
Una especificacin de proceso es una descripcin de un proceso del software que se
presenta desde una perspectiva particular. Por su naturaleza, los modelos son
simplificaciones, por lo tanto un modelo de procesos del software es una abstraccin de un
proceso real. Estos modelos incluyen actividades que son parte de los procesos y productos
de software y el papel de la gente involucrada en la ingeniera de software. Algunos
ejemplos de estos tipos de modelos que se pueden producir son:
1. Un modelo de flujo de trabajo. Muestra la secuencia de actividades en el proceso en
conjuncin con sus entradas, salidas y dependencias. Las actividades en este modelo
representan acciones humanas.
2. Un modelo de flujo de datos o actividad. Representa el proceso como un conjunto
de actividades, cada una de las cuales lleva a alguna transformacin en los datos .
Muestra cmo la entrada en el proceso, por ejemplo una especificacin, se
transforma en una salida como un diseo . Estas actividades son de menor nivel que
las de un modelo de flujo de trabajo. Pueden representar transformaciones llevadas
a cabo por la gente o por las computadoras.
3. Un modelo de rol / accin .Representa los roles de la gente involucrada en el
proceso de software y las actividades de las que son responsables.
3.6. DIAGRAMAS ENTIDAD - RELACIN
Muchos de los sistemas de software grandes utilizan bases de datos de informacin de gran
tamao. En algunos casos, esta base de datos existe de forma independiente del sistema de
software. En otros se crea para el sistema que se est desarrollando. Una parte importante
del modelado de sistemas es diferir la forma lgica de los datos procesados por el sistema.
La tcnica de modelado de datos ms utilizada es la de entidad-relacin-atributo (modelado
ERA) que muestra las entidades de datos, sus atributos asociados y las relaciones entre
entidades. Este enfoque de modelado fue propuesto inicialmente a mediados de los 70 por
Chen (1976), con diversas variantes desarrolladas desde entonces Codd, (1979); Hammer y
McLeod, (1981); Hull y King, (1987 ). Sin embargo, todos estos tienen la misma forma
bsica.

UML no incluye una notacin especfica para este tipo de modelado de datos ya que
supone un proceso de desarrollo orientado y modela los datos utilizados por objetos y sus
relaciones . Sin embargo, es posible considerar a las entidades como clases simplificadas de
objetos( no tiene operaciones) y utilizar los modelos de clases de UML, con asociaciones
etiquetadas entre stas , como modelos de datos. Aunque los modelos de datos resultantes
no estn en buen UML, esto se hace por la convivencia de utilizar la notacin estndar.
A menudo , los modelos de datos se utilizan en conjunto con los flujos de datos para
describir la estructura de la informacin que se est procesando . Esto se ilustra incluyendo
un modelo de datos de un diseo de software ( vea la figura 21.) Tal diseo podra ser
procesado por varios de los componentes del conjunto de herramientas CASE mostradas en
la figura 7.4 .
Los diseos son grafos dirigidos. Consiste en un conjunto de nodos de diferentes tipos
conectados por vnculos que representan las relaciones entre nodos del diseo. Existe una
representacin en pantalla de este grafo que es un diagrama del diseo y una
representacin de la base de datos correspondiente. Cada vez que se dibuja un diagrama, el
sistema de edicin lleva a cabo una correspondencia que va de la representacin de la base
de datos a la de pantalla. La informacin que produce el editor para las otras herramientas
de anlisis del diseo incluye la representacin lgica del grafo del diseo. Sin embargo,
estas herramientas de anlisis no toman en cuenta los detalles de la representacin fsica en
la pantalla. Procesan las entidades, sus atributos lgicos ( como sus nombres)y sus
relaciones.
La figura 21 muestra que un diseo tiene atributos cuyos valores son el nombre del diseo,
una descripcin de ste, una fecha de creacin (fecha C) y una de modificacin (fecha M).
El diseo esta compuesto de un conjunto de nodos y uno de vnculos. Los nodos tienen
vnculos asociados entre ellos. Los nodos y los vnculos tiene atributos de nombre y tipo.
Tienen un conjunto de etiqueta asociado que almacenan cierta informacin descriptiva .
Cada etiqueta tiene un icono y texto asociados.
Los modelos entidad- relacin se han utilizado ampliamente en el diseo de bases de datos.
Naturalmente, los esquemas de bases de datos relacionales derivados de esos modelos estn
en la tercera forma normal, la cual es una caracterstica aprovechable ( Barker, 1989).
Adems , debido a la asignacin explcita de tipos y al reconocimiento de sub y supertipos,
la implementacin de estos modelos utilizando bases de datos orientadas a objetos es
directa.

Diseo

Nombre
Descripcin
Fecha de C
Fecha de M

Modelo de datoa
de un diseo
de
software.
Tiene nodos

semntico

Es un

Tiene vnculos
1
n

n
Nodo

1
1

Tiene vnculos

Nombre
Tipo

Vnculo
Nombre
Tipo

Vnculos

Tiene etiquetas

Tiene etiquetas
Etiqueta

Nombre
Texto
Icono

Como los modelos grficos, los modelos ERA carecen de detalle y deben complementarse
con descripciones ms detalladas de la entidades, las relaciones y los atributos que se
incluyen en el modelo. Estas descripciones detalladas su pueden recolectar en un
repositorio o diccionario de datos. De forma general, los diccionarios de datos son tiles
cuando se desarrollan modelos del sistema y se utilizan para administrar toda la
informacin proveniente de todos los tipos de dichos modelos.
3.9 HERRAMIENTAS ADICIONALES DE MODELADO
Otras herramientas tiles al construir un modelo se pueden encontrar dentro del mismo
enfoque con el cual se desarrolle un proyecto o se planifique un producto. En ocasiones un
proyecto fracasa porque durante la fase de planeacin se utiliz un enfoque errneo, bien
sea influenciado por las imposiciones o expectativas del decisor, o por los temores que
generan mrgenes de seguridad que elevan innecesariamente los tiempos y costos
estimados para un proyecto.
De esta manera, el enfoque adoptado durante la planeacin del proyecto, sea demasiado
pesimismo o demasiado optimismo, exceso de temores o falta de previsin, puede influir en
el xito o fracaso del mismo proyecto, incluso ser definitivo antes de que ste nazca.

El llamado pensamiento lateral propone que se adopten diversas posiciones o enfoques

durante la planeacin del proyecto, particularmente seis formas de pensamiento que
identifica con sombreros de diferentes colores, cada uno asociado a un enfoque distinto, a
saber:
Sombrero blanco.- Al colocarse este sombrero, la planeacin se basa en cifras y hechos
puros, se recopilan y observan los datos en forma puramente objetiva, sin asignarles
interpretacin o significados particulares.
Sombrero rojo.- Quien utiliza este sombrero planea con bases emotivas, obedece a su
intuicin y presentimientos, pondr en marcha el proyecto si le late que tendr xito, de
otra manera lo descarta.
Sombrero negro.- Bajo el enfoque asociado a este sombrero, la planeacin se realiza con
una tendencia pesimista, encuentra todas las razones por las que el proyecto no debe
ponerse en marcha, este pensamiento negativo plantea el fracaso absoluto.
Sombrero amarillo.- En contraposicin, esta forma de pensamiento es absolutamente
positiva, con marcada tendencia optimista, establece todas las razones para poner en
marcha el proyecto con la seguridad de que todo marchar sobre ruedas hasta el xito
total.
Sombrero verde.- Este enfoque implica creatividad, reconoce puntos fuertes y dbiles del
proyecto y se centra en la bsqueda de formas para aprovechar las fortalezas y subsanar las
debilidades, de manera que el xito o el fracaso del proyecto depender de la
predominancia de sus pros o de sus contras y de la habilidad para manejar ambas.
Sombrero azul.- Este es el sombrero de control. Representa el pensamiento para pensar,
prev lo necesario para armonizar los dems enfoques de manera que el proyecto se pueda
llevar a cabo bajo las adecuadas condiciones establecidas por los diversas formas de
pensamiento.
3.10 PROTOTIPOS
Asumiremos como "prototipo" un sistema que funciona, evitando usar el trmino para
referirnos a un sistema en proceso o que algo le falta para considerarse completo, la
diferencia es la condicionante de funcionalidad, sujeta a modificaciones que como
anteriormente se ha establecido, resultan inevitables trtese del sistema que se trate.
La ventaja ms importante de esta metodologa es que a un costo aceptablemente bajo se
crean prototipos rpidamente, ya que las etapas de anlisis y diseo se realizan en un
tiempo mnimo. En cambio, la interaccin con el usuario durante la fase de desarrollo,
permite probar y modificar varias suposiciones respecto a las caractersticas requeridas por
el sistema.

La principal premisa que hizo desmerecer la metodologa clsica o tradicional, es que el

origen de un sistema de informacin es la existencia de necesidades y deseos insatisfechos
de los usuarios, y que stos no siempre pueden plantear correctamente sus requerimientos y
menos hacer una debida especificacin de ellos. La metodologa de prototipos hace
innecesario este punto de partida y en cambio permite que los requerimientos del sistema
vayan apareciendo durante la interaccin del usuario con el desarrollador.
Entre otras ventajas, esto evita reprocesos largos y costosos al final del ciclo de vida del
sistema, ya que las modificaciones al sistema se hacen prcticamente todas en la fase de
desarrollo.
Los principales promotores de esta metodologa fueron los fabricantes de software, tales
como Unisys que presenta una herramienta llamada MAPPER, capaz de generar
rpidamente aplicaciones, IBM que proporciona un programa de consulta y recuperacin de
datos llamado SQL (Single Query Language por sus siglas en ingls) que por si mismo
puede considerarse otra metodologa, Hotware de Mxico, que fabric una herramienta de
desarrollo rpido de aplicaciones para transacciones, y muchos otros que proporcionan sus
propios SQLs, Generadores de reportes, herramientas de desarrollo rpido o una
combinacin de varias de stas herramientas.
EL MODELO EN ESPIRAL
Este modelo, propuesto por Bohem en 1988, es un modelo de proceso de software
evolutivo que acompaa la naturaleza evolutiva de los sistemas con los aspectos
controlados y sistemticos del ciclo de vida tradicional. Proporciona el potencial para el
desarrollo rpido de versiones incrementales del software. En este modelo, el sistema se
desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la
versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas
iteraciones se producen versiones cada vez ms completas de ingeniera del sistema. .
El Modelo en Espiral se divide en un nmero de actividades estructurales, tambin
llamadas "regiones de tareas" . Generalmente existen entre tres y seis regiones de tareas:

Comunicacin con el cliente.- Las tareas requeridas para establecer comunicacin

entre el desarrollador y el cliente, sea revisar especificaciones, plantear necesidades,
etc.
Planificacin.- Las tareas requeridas para definir recursos, tiempos e informacin
relacionada con el proyecto.
Anlisis de riesgos.- Las tareas requeridas para evaluar riesgos tcnicos y de gestin.
Ingeniera.- Las tareas requeridas para construir una o ms representaciones de la
aplicacin
Construccin y adaptacin.- Las tareas requeridas para construir, probar, instalar y
proporcionar soporte al usuario.

Evaluacin del cliente.- Las tareas requeridas para obtener la reaccin del cliente,
segn la evaluacin de las representaciones del software creadas durante la etapa de
ingeniera e implementada durante la etapa de instalacin

Cada una de las regiones estn pobladas por una serie de tareas que se adaptan a las
caractersticas del proyecto que va a emprenderse. Para proyectos pequeos el nmero de
tareas y su formalidad es bajo, para proyectos mayores y ms crticos, cada regin contiene
tareas que se definen para lograr un nivel ms alto de formalidad.
Cuando empieza este proceso evolutivo, el equipo de trabajo gira alrededor de las agujas
del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de
una especificacin de productos, los pasos siguientes en la espiral se podran utilizar para
desarrollar un prototipo y progresivamente versiones ms sofisticadas del software. Cada
paso de la regin de planificacin produce ajustes en el plan del proyecto. . El coste y la
planificacin se ajustan en funcin de la evaluacin del cliente. Adems, el gestor del
proyecto ajusta el nmero planificado de iteraciones requeridas para completar el proyecto
o el producto software de que se trate.
La siguiente figura muestra grficamente el Modelo Espiral, para las seis regiones de tareas
y suponiendo un proyecto tal que forzosamente requiere iniciar en la conceptualizacin
previa a la vuelta de desarrollo, an cuando hemos dicho que frecuentemente se puede
iniciar desde esta tarea. Asimismo, se presenta la terminacin del proyecto en la ltima
vuelta, como mantenimiento del mismo proyecto, pareciese que ah terminase el ciclo, sin
embargo, la vuelta siguiente existe y correspondera al inicio de un nuevo proyecto que
puede o no tomar como base el proyecto anterior.

planificacin
Anlisis de riesgo
con
Evaluacin Comunicacin
del cliente
el cliente
INICIO
Ingeniera
DESARROLLO
AJUSTES
Evaluacin del cliente
Construccin y
adaptacin
MANTENI
MIENTO

Comunicacin con el cliente

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software en gran

escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y
el usuario comprenden y reaccionan mejor ante riesgos en cada uno de los niveles
evolutivos. El modelo en espiral utiliza la construccin de prototipos como mecanismo de
reduccin de riesgos, pero lo que es ms importante, permite a quien lo desarrolla aplicar el
enfoque de construccin de prototipos en cualquier etapa de evolucin del producto.
Mantiene el enfoque sistemtico de los pasos sugeridos por el ciclo de vida clsico, pero lo
incorpora al marco de trabajo interactivo que refleja mejor el mundo real. El modelo
demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto,
y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en
problemticos.
Pero al igual que otros modelos, ste no es la panacea. Puede resultar difcil convencer a
grandes clientes, (particularmente en situaciones bajo contrato) de que el enfoque evolutivo
que presenta este modelo es controlable. Requiere una considerable habilidad para la
evaluacin del riesgo, y de ello depende el xito. Si un riesgo importante no es descubierto
y gestionado, indudablemente surgirn problemas. Finalmente, en si mismo, el modelo es
relativamente nuevo y no se ha utilizado tanto como otros. Todava tendr que pasar
muchas pruebas para certificar los beneficios que la utilizacin de este prometedor modelo
parece ofrecer para el desarrollo de sistemas de informacin.
De hecho, cada metodologa de desarrollo y cada paradigma que por ellos se establece,
tiene caractersticas que vale la pena considerar por separado. A continuacin se tratar un
poco ms de las metodologas ms usuales

3.11

METODOLOGAS

Existe una gran variedad de modelos generales diferentes o paradigmas de desarrollo de

software :
1. El enfoque en cascada. Considera las actividades anteriores y las representa como
fases de procesos separados, como las especificaciones de requerimientos, el diseo
del software, la implementacin, las pruebas, etctera. Despus de que cada etapa
queda definida se firma y el desarrollo contina con la siguiente etapa.
2. Desarrollo evolutivo. Este enfoque entrelaza las actividades de especificacin ,
desarrollo y validacin. Un sistema inicial se desarrolla rpidamente a partir de
especificaciones muy abstractas. ste se redefina basndose en las peticiones del
cliente para producir un sistema que satisfaga las necesidades de dicho cliente.
Entonces el sistema se libera. De forma alternativa, se puede reimplantar utilizando
un enfoque ms estructurado para producir un sistema ms robusto y mantenible.

3. Transformacin formal. Este enfoque se basa en la produccin de la especificacin

matemtica formal del sistema y la transformacin de esta especificacin a un
programa utilizado mtodos matemticos. Estas transformaciones conservan las
correcciones anteriores. Esto significa que puede estar seguro de que le desarrollo
del programa cumple con la especificacin.
4. Sistema de ensamblaje de componentes reutilizables. Esta tcnica supone que las
partes del sistema existen. El proceso de desarrollo del sistema se enfoca a la
integracin de esas partes ms que a construirlo desde sus inicios.

El modelo de cascada
El primer modelo de proceso de desarrollo de software que se publico se deriv de otros
procesos de ingeniera (Royce.1970). ste se muestra en la figura 3.1 .Debido a la cascada
de una fase a otra, este modelo se conoce como modelos cascada o como un ciclo de vida
del software. Las principales etapas de este modelo se transforman en actividades
fundamentales de desarrollo:
6. Anlisis y definicin de requerimientos. Los servicios , restricciones y metas del
sistema se definen a partir de las consultas en detalle y sirven como una
especificacin del sistema.
7. Diseo de sistemas y software . El proceso de diseo de sistemas divide los
requerimientos en sistemas de hardware o de software. Establece una arquitectura
completa del sistema. El diseo de software identifica y describe las abstracciones
fundamentales del sistema de software y sus relaciones.
8. Implementacin y prueba del sistema. Durante esta etapa, el diseo de software se
lleva a cabo como un conjunto o unidades de programas. La prueba de unidades
implica verificar que cada una cumpla su especificacin.
9. 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 la pruebas, el sistema de
software se entrega al usuario.
10. Operacin y mantenimiento. Por lo general (aunque no necesariamente) , sta es la
fase ms grande del ciclo de vida. El sistema se instala y pone en uso prctico. El
mantenimiento implica corregir errores no descubiertos en las 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.

Figura 3.1 El ciclo de vida del software

Definicin
Definicindede
requerimientos
requerimientos

Diseo
Diseodedesistemas
sistemasyy
dedesoftware
software

Implementacin
Implementacinyy
prueba
pruebadedeunidades
unidades

Integracin
Integracinyyprueba
prueba
del
delsistema
sistema

Operacin
Operacinyy
mantenimiento
mantenimiento

4.2 ANLISIS ORIENTADO A OBJETOS

El proceso de anlisis para identificar objetos y clases de stos es una de las reas ms
difciles del desarrollo orientado a objetos . La identificacin de stos bsicamente la
misma para el anlisis y el diseo. Se puede utilizar los mtodos de identificacin de
objetos. Aqu se hace nfasis en algunos de los modelos de objetos que se podran generar
durante el proceso de anlisis.
Se propusieron varios mtodos de anlisis orientado a objetos en los 90(Booch, 1994;
Coad y Yourdon, 1990; Rumbaugh y Jacobson) decidieron integrar sus enfoques para
producir un mtodo unificado( Rumbaugh et al., 1999 b ). UML (Lenguaje Unificado de
Modelado), que se utiliza en este mtodo unificado, se ha convertido en un estndar
efectivo para el modelado de objetos. UML incluye notaciones para diferentes tipos de
modelados de sistemas.
Una clase de UML, como se ilustra en los ejemplos de la figura 7.10, se representa como un
rectngulo vertical con tres secciones:

Figura 7.10 Parte de una jerarqua de clases de un sistema de biblioteca

Artculo de Biblioteca
Nmero de catlogo
Fecha de adquisicin
Costo
Tipo
Estado
Nmero de copias
Adquirir ()
Catalogar ()
Disponer ()
Nmero de publicacin ()
Regresar ()

Artculo publicado

Artculo registrado

Ttulo
Editor

Libro
Autor
Edicin
Fecha de
publicacin
ISBN

Ttulo
Medio

Revista
Ao
Expedir

Pelcula
Director
Fecha de
liberacin
Distribuidor

Programa de
Computadora

Versin
Plataforma

Continuacin de la pagina 160-166

Texto despus de la figura 7.10

1. El Nombre de la clase de objetos est en la seleccin superior.

2. Los atributos de la clase estn en la seccin media.
3. Las operaciones asociadas con la clase de objetos estn en la seccin inferior del
rectngulo.
No existe suficiente espacio para cubrir todo con UML, por lo que la atencin se
concentrar en modelos de objetos que muestren cmo se clasifican los objetos y cmo
heredan los atributos y operaciones de otros objetos, los modelos de agregacin que
muestran cmo se componen los objetos, as como los modelos de comportamiento que
muestran las interacciones de los objetos.

UNIDAD V
DISEO

5.1. DISEO ESTRUCTURADO

Los mtodos estructurados __ son un conjunto de notaciones y lineamientos para el
diseo de software___ que propone un enfoque metdico. Ejemplos de estos mtodos son
el Diseo Estructurado ( Constantine y Yourdon, 1979), el Anlisis Estructurado de
Sistemas (Gane y Sardon, 1979). EL Desarrollo de Sistemas de Jackson (Jackson, 1983) y
los diversos enfoques de diseo orientado a objetos (Robinson, 1992; Booch, 1994;
Rumbaugh et al., 1991; Boch et al ., 1999 Rumbaugh et al ., 1999 a. 1999 b ).
El uso de mtodos estructurados normalmente incluye la produccin de modelos grficos
del sistema y conduce a una gran cantidad de documentacin de diseos .Las herramientas
CASE se han desarrollado para ayudar a mtodos particulares. Los mtodos estructurados
se han aplicado exitosamente en muchos proyectos grandes. Comprenden gran reduccin en
los costos debido al uso de notaciones estndar y aseguran la produccin de documentacin
estndar del diseo. No se puede demostrar que algn mtodo sea mejor o peor que otro. A
menudo, el xito de los mtodos depende de que stos sean apropiados para un dominio de
aplicacin.
Un mtodo estructurado incluye un modelo de proceso de diseo, notaciones para
representar el diseo, formatos de informes, reglas y lineamientos de diseo. Aunque exista

una gran variedad de mtodos, todos tiene mucho en comn. Los mtodos estructurados
ayudan a todos o alguno de los siguientes modelos de un sistema:
1. Un modelo de flujo de datos en el que el sistema se modela utilizando la
transformacin de datos que tiene lugar cuando se procesan.
2. Un modelo entidad-relacin el cual se utiliza para describir las entidades
fundamentales en el diseo y las relaciones entre ellas. Los modelos entidadrelacin son la tcnica normal que se para describir las estructuras de las bases de
datos.
3. Un modelo estructural en el cual se documentan los componentes del sistema y sus
interacciones.
4. Los mtodos orientados a objetos incluyen un modelo de herencia del sistema,
modelos de relaciones estticas y dinmicas entre los objetos y un modelo de
interaccin de los objetos cuando el sistema se ejecuta.
Algunos mtodos particulares complementan stos con otros modelos del sistema, como
diagramas de transicin de estados, narrativas del periodo de vida de una entidad que
muestran la manera en que sta se transforma y procesa, etctera. Muchos mtodos
sugieren el uso de un depsito para la informacin del sistema o de un diccionario de datos.
En la prctica, la gua que proporciona los mtodos es informal, de tal manera que
diferentes diseadores desarrollan diferentes diseos. Estos mtodos son realmente
notaciones estndar que comprenden prcticas aceptables. Si se siguen y aplican estos
mtodos, puede surgir un diseo razonable. La creatividad del diseador se requiere para
decidir la descomposicin del sistema y asegurar que el diseo capture de forma adecuada
la especificacin del mismo . Los estudios empricos de los diseadores (Bansler y Bodker,
1993 ) raramente siguen los mtodos convencionales. Seleccionan y eliminan temas de los
lineamientos ,dependiendo de las circunstancias locales.

5.2. DISEO ORIENTADO A OBJETOS

Actualmente es comn utilizar un enfoque orientado a objetos para el desarrollo completo
del software , en particular para el desarrollo de sistemas interactivos. Estos significa
expresar los requerimientos del sistema utilizando un modelo de objetos llevar a cabo el
diseo utilizando objetos y desarrollar el sistema en un lenguaje de programacin orientado
a objetos como Java o C++.
Los modelos de objetos desarrollados durante el anlisis de requerimientos se utilizan para
representar los datos del sistema y su procesamiento. A este respecto, combinan algunas de
las formas de utilizacin de los modelos de flujo de datos y semnticos de datos. Tambin
son tiles para mostrar la manera en que las entidades en el sistema se clasifican y se
componen de otras entidades.

Para algunas clases de sistemas, los modelos de objetos son la forma natural de reflejar las
entidades del mundo real que manipulan el sistema. Esto es particularmente cierto cuando
el sistema procesa informacin de entidades concretas como autos, aviones, libros etctera,
los cueles tienen atributos claramente identificados. De forma ms abstracta, las entidades
de alto nivel, como el concepto de biblioteca, un sistema mdico o un procesador de texto
difciles de modelar como clases de objetos. No necesariamente tienen una interfaz sencilla
que ste compuesta de atributos y operaciones independientes.
Indudablemente, los modelos de objetos desarrollados durante el anlisis de requerimientos
simplifican la transicin al diseo y programacin orientados a objetos. Sin embargo , a
menudo se observa que los usuarios finales de un sistema encuentran dichos modelos poco
naturales y difciles de comprender. Frecuentemente, prefieren adoptar una visin ms
funcional del procesamiento de datos. Por lo tanto, algunas veces es de gran ayuda
complementar dichos modelos con los flujos de datos que muestran el procesamiento de
datos en el sistema.
Una clase de objetos es una abstraccin sobre un conjunto de objetos que identifican los
atributos comunes ( como el modelo semntico de datos ) y los servicios u operaciones que
provee cada objeto. Los objetos son entidades ejecutables con los atributos y servicios de la
clase de objetos. stos son instancias de dicha clase, de tal forma que se puedan crear
diferentes objetos a partir de una clase. De forma general los modelos desarrollados se
centran en estas clases y sus relaciones.
Los modelos de sistemas que se desarrollan durante el anlisis de requerimientos modelan
entidades del mundo real utilizando clases de objetos. No incluyen detalles de los objetos
individuales del sistema. Se pueden producir varios tipos de modelos de objetos que
muestran la manera en que las clases se relacionan entre ellas, la manera en que los objetos
se agregan para formar otros, como interactan con otros, etctera. Todo esto se puede
agregar a la compresin del sistema que se especifica.

Modelos de Herencia.
El modelado orientado a objetos implica la identificacin de clases de objetos que son
importantes en el dominio de estudio. Estos objetos se organizan en una taxonoma. Una
taxonoma es un esquema de clasificacin que muestra la manera en que una clase de
objetos esta relacionada con otras clases a travs de atributos y servicios comunes.
Para desplegar esta taxonoma, las clases se organizan en una jerarqua de herencia en la
que las clases de objetos ms generales se encuentran en la parte alta de la jerarqua. Los
objetos ms especializados heredan sus atributos y servicios. Estos objetos tienen sus
propios atributos y servicios.

La figura 7.10 ilustra parte de una jerarqua de clases simplificada para un modelo de
sistema de biblioteca. Esta jerarqua da informacin acerca de los elementos contenidos en
la biblioteca. sta tiene varios tipos de artculos como libros, msica, cintas, revistas,
peridicos, etctera. En la figura 7.10, el artculo ms general se encuentra en la cima del
rbol y tiene un conjunto de atributos y servicios que son comunes para todo los artculos
de la biblioteca. stos son heredados por las clases Artculo publicado y Artculo registrado
que agregan sus propios atributos y despus se heredarn a los artculos de los niveles
inferiores.
La figura 7.11 es un ejemplo de otra jerarqua de herencia que podra ser parte de un
modelo de biblioteca. En este caso, se muestran los usuarios de una biblioteca. Existen dos
clases de usuarios: aquellos a los que se les prestan libros y aquellos que slo lo consultan
en la biblioteca sin retirarlos de ella..
En la notacin UML, la herencia se muestra haca arriba y no hacia abajo como en otras
notaciones orientadas a objetos. Esto es, la cabeza de la flecha (con forma de tringulo)
apunta de la clase que hereda atributos y operaciones a la superclase. En lugar de utilizar el
trmino herencia, UML le llaman relacin de generalizacin.
El diseo de jerarquas de clases no es fcil. Una ventaja al desarrollar tales modelos es
que el analista necesita comprender, en detalle, el dominio en el que el sistema se instalar.
Como un ejemplo de los problemas que surgen en la prctica, considere la jerarqua de
artculos de la biblioteca. Parecera que el atributo Ttulo debe estar en el artculo ms
general y que se debe heredar a los artculos en los niveles inferiores.
Clase jerrquica del usuario

Usuario de Biblioteca
Nombre
Direccin
Telfono
# de registro
Registrar ()
Quitar registro ()

Lector

Prestatario

Afiliacin

Artculos en prstamo
Prstamo mximo

Personal
Departamento
Telfono del departamento

Estudiante
Tema principal
Direccin

Figura 7.12 Herencia de mltiple

Libro

Grabacin de voz

Autor
Edicin
Fecha de publicacin
ISBN

Altavoz
Duracin
Fecha de grabacin

Audiolibro
# de cintas

Sin embargo, aunque todo en la biblioteca debe tener algn tipo de identificador o un
nmero de registro, esto no significa que todo deba tener un ttulo. Por ejemplo una
biblioteca puede tener los discursos personales de un poltico retirado. Muchos de esos
artculos no tiene un ttulo explicito. Estos se clasifican utilizando otra clase (que no se
muestra aqu) que tiene un conjunto diferente de atributos.
Las figuras 7.10 y 7.11 muestran jerarquas de herencia de clases en las que cada una
hereda sus atributos y operaciones de una clase madre nica. Tambin se puede construir
modelos de herencia mltiple en los cuales una clase tiene varias madres. Sus atributos y
servicios heredados son una conjuncin de aquellos heredados de cada superclase. La
figura 7.12 muestra un ejemplo de un modelo de herencia mltiple que tambin podra ser
parte de una biblioteca.
El problema principal de la herencia mltiple es disear un grafo de herencia en el cual los
objetos no heredan atributos innecesarios. Otros problemas que se presentan son la
dificultad de reorganizar dicho grafico cuando se solicitan cambios y cuando los nombres
chocan entre s al existir dos o ms superclases que se tiene atributos con el mismo nombre
pero con diferentes significados. En cada nivel del modelo del sistema, tal coche es
respectivamente fcil de resolver de forma manual alterando el modelo de objetos. Pero
provoca problemas en la programacin orienta a objetos.

Agregacin de objetos
As como se adquieren atributos y servicios a travs de una relacin de herencia con otros
objetos, algunos objetos estn hechos de otros objetos. Esto es, un objeto es un agregado de
un conjunto de otros objetos. Las clases que representan a stos se modelan utilizando un
modelo de agregacin de objetos como se muestra en la figura 7.13. En este ejemplo, se ha
modelado un artculo de biblioteca, el cual es un paquete de estudio para un curso
universitario. Este paquete incluye notas de clase, ejercicios, soluciones de muestra, copias
de las transparencias utilizadas en las clases y videos.
La notacin UML, para la agregacin es representar la composicin a travs de una figura
de diamante colocada en la fuente del vnculo. Por lo tanto, la figura 7.13 se puede leer
como Un paquete de estudio se compone de una o ms tareas, paquetes de diapositivas
OHP, notas de clase y videos.
Figura 7.13 Representacin de un curso mediante una agregacin de objetos.
Paquete de estudio
Ttulo del curso
Nmero
Ao
Instructor

Diapositivas
OHP

Tarea

Notas de clase
Texto

Crditos

Diapositivas

Ejercicios

Soluciones

# problemas

Texto
Diagramas

descripcin

Modelado del comportamiento de objetos.

Vdeo
Identificacin de
cintas

Para modelar el comportamiento de los objetos, se tiene que mostrar cmo se utilizan las
operaciones de stos. En UML, se modelan utilizando escenarios basados en los casos de
uso. Un ejemplo de modelado de comportamiento se muestra en la figura 6.13 que ilustra
la administracin de un catlogo de biblioteca. As como los diagramas de colaboracin que
muestran la secuencia de mensajes intercambiados por los objetos. Son similares a los
diagramas de secuencia y no se cubren aqu.
Para ilustrar cmo se utilizan los diagramas de secuencia para modelar el comportamiento,
se describe un escenario en el que los usuarios solicitan prstamos a la biblioteca de forma
electrnica. Por ejemplo, imagine una situacin en las que los paquetes de estudio
mostrados en la figura 7.13 se mantienen electrnicamente y se descargan a la
computadora del estudiante.
La figura 7.14 muestra un diagrama de secuencia con los objetos en la parte alta de
diagrama. Las operaciones se indican por las etiquetas de las flechas y las secuencia de
operaciones es de arriba hacia abajo. En este escenario, el usuario tiene acceso al catlogo
para ver si el artculo requerido esta disponible electrnicamente y, si es as, lo solicita. Por
razones de derechos de autor, a este artculo se le designa una licencia de tal forma que
existe una transaccin entre al artculo solicitado se enva a una red de servidores de objetos
para su comprensin de ser enviado al usuario.
Figura 7.14 Expedicin de artculos electrnicos

Catlogo
Ecat

Artculo de
Biblioteca

Bib 1 :Servidor
de red

Usuario de Biblioteca

Buscar

Desplegar

Expedir

Expedir
licencia

Aceptar
licencia

Diseo

Arquitectnico
Comprimir
Entregar

Contenido
10.1. Estructuracin del sistema
10.2 .Modelos de control
10.3 Descomposicin modular
10.4. Arquitecturas de dominio especifico
Introduccin
Los sistemas grandes siempre se descomponen en subsistemas que suministran algn
conjunto relacionado de servicios. El proceso de diseo inicial para identificar estos
subsistemas y establecer un marco de trabajo para el control y comunicacin de los
subsistemas y establecer un marco de trabajo para el control y comunicacin de los
subsistemas se llama diseo arquitectnico y lo que produce este proceso de diseo es una
descripcin de la arquitectura de software.
La estructura completa del proceso de diseo se discuti en la seccin 3.4. En la figura 3.9
se presento un modelo de proceso de diseo donde el diseo arquitectnico es la primera
etapa en el proceso y representa un vnculo crtico entre el diseo y los procesos de
ingeniera de requerimientos. De forma ideal, una especificacin no debe incluir ninguna
formacin del diseo. En la prctica, esto no es real excepto para los sistemas muy
pequeos. La descomposicin arquitectnica es necesaria para estructurar y organizar la
especificacin. Un buen ejemplo se mostr en la figura 2.4, que ilustra la arquitectura de un
sistema de control de trfico areo. El modelo arquitectnico es a menudo el punto inicial
para la especificacin de diversas partes del sistema.
El proceso de diseo arquitectnico comprende el establecimiento de un marco de trabajo
estructural bsico para un sistema. Esto implica identificar los componentes principales del
sistema. Esto implica identificar los componentes principales del sistema y la comunicacin
entre ellos. Bass et al. (1998) plantean tres ventajas de la especificacin del diseo y la
documentacin de una arquitectura de software:
1. Comunicacin entre los stakeholders. La arquitectura es una presentacin de alto
nivel del sistema que es utilizada como punto de discusin `por un rango de
stakeholders diferentes.
2. Anlisis del sistema. Hacer explicita la arquitectura del sistema en una etapa inicial
del desarrollo del sistema, significa que debe de llevar a cabo cierto tipo de anlisis.
Las decisiones en el diseo arquitectnico tienen un efecto profundo sobre cundo
el sistema puede cumplir los requerimientos crticos como el desempeo, la
fiabilidad y la mantenibilidad.

3. Reutilizacin a una gran escala. Una arquitectura del sistema es una descripcin
compacta y manejable de cmo se organiza el sistema y cmo interoperan los
componentes. La arquitectura se puede transferir a lo largo de los sistemas con
requerimientos similares y as poder reutilizar software a gran escala, Es posible
desarrollar arquitecturas de lneas de productos donde la misma arquitectura se
utilicen en varios sistemas relacionados. Esto se discute en la seccin 10.4 y el
captulo 14.
Diversos diseadores enfocan el proceso de diseo arquitectnico de diferentes formas. El
proceso utilizado depende del conocimiento de la aplicacin y de la capacidad e intuicin
de los arquitectnicos del sistema. Sin embargo, las siguientes actividades son comunes
para todos los procesos de diseo arquitectnico:
1. Estructuracin del sistema. El sistema se estructura en varios subsistemas
principales, donde un subsistema es una unidad de software independiente. Se
identifican las comunicaciones entre los subsistemas. Esto se cubre en la seccin
10.1
2. Modelado del control. Se establece un modelo general de las relaciones de control
entre las partes del sistema. Este se cubre en la seccin 10.2.
3. Descomposicin modular. Cada subsistema identificado se descompone en mdulos.
El arquitecto debe decidirse sobre los tipos de mdulos y sus interconexiones.
Este se cubre en la seccin 10.3
Por lo general, estas actividades estn entrelazadas ms que llevarse a cabo de forma
secuencial. Durante cualquiera de estos procesos, se tiene que desarrollar el diseo en ms
detalle para descubrir si las decisiones en el diseo arquitectnico permite al sistema
cumplir sus requerimientos.
No existe una distincin clara entre los subsistemas y mdulos, pero es til distinguirlos
como se muestra a continuacin:
1. Un subsistema es un sistema que por si mismo cuya operacin no depende de los
servicios suministrados por otros subsistemas. Los subsistemas se componen de
mdulos y tiene interfaces definidas que se utilizan para la comunicacin con otros
subsistemas.
2. Un mdulo es por lo regular un componente del sistema que suministra uno o ms
servicios a otros mdulos. Utiliza los servicios suministrados por otros mdulos.
Por lo general no se considera un sistema independiente. Generalmente, los
mdulos estn compuestos de varios componentes simples del sistema.
La salida del proceso de diseo arquitectnico es un documento de diseo arquitectnico.
ste consiste de varias representaciones grficas de los modelos del sistema junto con el
texto descriptivo asociado. Describe cmo se estructura el sistema en subsistemas y cmo
cada subsistema se estructura en mdulos. Los diversos modelos grficos del sistema

muestran diferentes perspectivas de la arquitectura. Los modelos arquitectnicos que se

pueden desarrollar son:
1. Un modelo estructural esttico que muestran los subsistemas o componentes a
desarrollar como unidades independientes.
2. Un modelo de proceso dinmico que muestra cmo se organiza el sistema en tiempo
de ejecucin. Este modelo puede ser diferente al modelo esttico.
3. Un modelo de interfaz que define los servicios ofrecidos por cada subsistema a
travs de su interfaz pblica.
4. Modelos de relacin que se muestran las relaciones de, por ejemplo, el flujo de
datos entre los subsistemas.
Varios investigadores han propuesto la utilizacin de ADLs ( lenguajes de descripcin
arquitectnica) para describir las arquitecturas del sistema. Bass et al (1998) describe las
caractersticas principales de estos lenguajes. Los elementos bsicos del ADLs son
componentes sy conectores que incluyen reglas y lineamientos para arquitecturas bien
arquitecturas bien formadas. Sin embargo, como otros lenguajes especializados, tiene la
desventaja de que slo los expertos en el lenguaje los comprenden- son inaccesibles para
los especialistas en el dominio y en la aplicacin. Esto hace difcil analizarlos desde una
perspectiva prctica. Por lo tanto, se utilizan en un nmero reducido de aplicaciones. En su
lugar, los modelos y notaciones informales como UML, son ms tiles en la descripcin
arquitectnica.
El diseo arquitectnico se basa en un modelo o estilo arquitectnico particular (Garlan y
Shaw, 1993. Por lo tanto, es importante conocer estos modelos, sus aplicaciones, fortalezas
y debilidades. En este captulo se describen varios modelos estructurales diferentes,
modelos de control y modelos de descomposicin.
Sin embargo, las arquitecturas de muchos sistemas grandes comprenden ms de un
modelo. Las diversas partes del sistema se disean utilizando diferentes modelos
arquitectnicos. Ms an, en algunos casos, la arquitectura del sistema es una arquitectura
compuesta. sta se crea al combinar diferentes modelos arquitectnicos. Los diseadores
deben encontrar el modelo ms apropiado y modificarlo acorde a los requerimientos del
problema. Un ejemplo de esto se muestra en la seccin 10.4, la discusin de la arquitectura
de un compilador donde un modelo de depsito se combina con un modelo de flujo de
datos.
La arquitectura del sistema afecta al desempeo, la robustez, la distributibilidad y la
mantenibilidad de un sistema. Por lo tanto, el estilo particular y la estructura elegida para
una aplicacin pueden depender de los requerimientos no funcionales del sistema:
1. Desempeo. Si el desempeo es un requerimiento crtico, esto sugiere que la
arquitectura se debe disear para localizar las operaciones crticas dentro de un
nmero reducido de subsistemas. Esto significa utilizar componentes de grano
grueso ms que de grano fino para reducir los componentes de comunicacin.

2. Seguridad. Si la seguridad es un requerimiento crtico, esto sugiere que la estructura

en capas ms internas y con un alto nivel de validacin de la seguridad aplicado a
esas capas.
3. Proteccin. Si la proteccin es un requerimiento crtico esto sugiere que la
arquitectura se debe disear de tal forma que las operaciones relacionadas con la
proteccin se localicen en un solo subsistema o en un nmero reducido de
subsistemas. Esto reduce los costos y los problemas de validacin y hace posible
crear sistemas de proteccin relacionados.
4. Disponibilidad. Si la disponibilidad es un requerimiento crtico, esto sugiere que la
arquitectura debe disearse para incluir componentes redundantes de tal forma que
sea posible reemplazar a actualizar los componentes sin detener el sistema. En el
captulo 18 se cubren las arquitecturas de sistemas tolerantes a fallas para sistemas
de alta disponibilidad.
5. Mantenibilidad. Si la mantenibilidad es un requerimiento crtico, esto sugiere que la
arquitectura del sistema se debe disear utilizando componentes auto contenidos de
grano fino que pueden cambiarse con facilidad. Los productores de datos deben
estar separados de los consumidores y las estructuras de datos compartidas deben
evitarse.
Obviamente existe un conflicto potencial entre algunas de estas arquitecturas. Por
ejemplo, el desempeo se mejora utilizando componentes de grano grueso y el
mantenimiento utilizando componentes de grano fino. Si ambos son requerimientos
importantes del sistema, se deben encontrar una solucin mediadora como se discuti
anteriormente, algunas veces esto se puede llevar a cabo utilizando estilos
arquitectnicos para las diversas partes del sistema.
10.1 Estructuracin del sistema

La primera fase de la actividad de diseo arquitectnico se refiere, por lo general, a la descomposicin del
sistema en conjunto de subsistemas que interactan. En el nivel ms abstracto, un diseo arquitectnico se
puede ver como un diagrama de bloques en el que cada cuadro del diagrama representa un subsistema. Los
cuadros dentro de otros cuadros indican que el subsistema a se ha descompuesto en subsistemas. Las fechas
indican que los datos y/o el control se pasan de un subsistema a otro subsistema en la direccin de las flechas.
Un diagrama arquitectnico de bloques presenta un panorama general de la estructura del sistema. Por lo
general, ste es comprensible por los diversos ingenieros que estn involucrados en el proceso de desarrollo.

La figura 10.1 es un modelo estructural de la arquitectura de un sistema robot de

embalajes. Este sistema puede empacar diferentes tipos de objetos. Utilizan un sistema de
visin para seleccionar los objetos de una banda transportadora, identifican el tipo de
objetos y seleccionan el tipo de embalaje correcto. Despus mueve los objetos de la banda
transportadora para empacarlos. Los objetos empaquetados se colocan en una banda

transportadora. En las figuras 2.2 y 2.4 se muestran otros ejemplos de diseo arquitectnico
a este nivel.
Figura 10.1 Diagramas de Bloques de un sistema robot de control de embalajes.
Sistema
de
visin

Sistema de
identificacin
de objetos

Controlar
Controlar
de brazo
de brazo

Controlador
Controlador
del asidero
del asidero

Sistema de
seleccin de
embalajes

Sistema de
Sistema de
embalaje
embalaje

Controlador de la banda
Controlador de la banda
transportadora
transportadora

Bass et al ( 1998) sealan que los diagramas de cuadros y flechas no son representaciones
arquitectnicas tiles puesto que no muestran la naturaleza de las relaciones entre los
componentes del sistema ni sus propiedades visibles externas. Desde una perspectiva de un
diseador de software, esto es absolutamente correcto. Sin embargo, este tipo de modelo es
efectivo para la comunicacin con los stakeholders del sistemas y los planeadores del
proyecto. Puesto que no muestra los detalles, los gestores lo relacionan con el sistema y
tiene una visin abstracta de l. Identifica a los subsistemas clave a desarrollar de forma
independiente de tal forma que los administradores pueden iniciar asignando personas al
plan de desarrollo de esos sistemas. Los diagramas de cuadros y flechas no son la nica
representacin arquitectnica que se utiliza; sin embargo, es uno de los modelos de
representacin arquitectnica tiles.
Se pueden desarrollar modelos ms especficos de la estructura qu muestren cmo los
subsistemas comparten datos, cmo estn distribuidos y cmo se conectan entre ellos. En
est seccin se discuten tres de esos modelos estndar: el modelo de depsito, el modelo
cliente- servidor y el modelo de mquina abstracta.

10.1.1 El modelo de depsito

Los subsistemas que componen un sistema debe intercambiar informacin con el fin de que
puedan trabajar de forma conjunta y efectiva. Existen dos formas fundamentales de lograr
esto.
1. Todos los datos compartidos se ubican en una base de datos central que puede ser
accedida por todos los subsistemas. Un modelo del sistema basado en una base de
datos compartida se denomina algunas veces modelo de depsito.
2. Cada subsistema tiene su propia base de datos. Los datos se intercambian con otros
subsistemas pasando mensajes entre ellos.
La mayora de los sistemas que utilizan grandes cantidades de datos se organizan alrededor
de una base de datos compartida o depsito. Por lo tanto, este modelo es adecuado para
aplicaciones donde los datos sean generados por un subsistema y utilizados por otro.
Ejemplo de este tipo de sistemas son los sistemas de mando y control, los sistemas de
administracin de la informacin, los sistemas CAD y los conjuntos de herramientas
CASE.
La figura 10.2 es un ejemplo de una arquitectura para un conjunto de herramientas CASE
basada en un depsito compartido. El primer depsito compartido para las herramientas
CASE se desarroll probablemente a principios de los 70 por una compaa del Reino
Unido, denominada ICL, como ayuda al desarrollo de su sistema operativo (Mc-Guffin et
al. 1979). Este modelo lleg a ser ampliamente conocido cuando Bouxton (1980) hizo las
propuestas para el entorno Stoneman como ayuda al desarrollo de sistemas escritos en
Ada. Desde entonces, muchos de los conjuntos de herramientas CASE se han desarrollado
alrededor de un depsito compartido.
Las ventajas y desventajas de un depsito compartido son:
1. Es una forma eficiente de compartir grandes cantidades de datos. No existe la
necesidad de transmitir datos explcitamente de un subsistema a otro.
2. Sin embargo, los subsistemas deben estar acordes al modelo de depsito de datos.
De forma inevitable, esto es un compromiso entre las necesidades especficas de
cada herramienta. El desempeo se puede ver afectado por este compromiso. Puede
ser difcil o imposible integrar los nuevos subsistemas si sus modelos datos no se
ajustan al esquema acordado.
3. Los subsistemas que producen datos no necesitan saber cmo son utilizados esos
datos por otros subsistemas.
4. Sin embargo, si se genera un gran volumen de informacin, ser difcil evolucionar
si se ha acordado un modelo de datos. Traducir esto a un nuevo modelo ser
costoso; puede ser difcil o incluso imposible.
5. Las actividades como las de respaldo, seguridad, control de acceso y recuperacin
de errores estn centralizados. Son las responsables de administrar el depsito. Las
herramientas se enfocan a su funcin principal ms que a estas cuestiones.

6. Sin embargo, varios subsistemas tienen diferentes requerimientos de polticas de

seguridad, recuperacin y respaldo. El modelo de depsito fuerza a la misma
poltica para todos los subsistemas.
7. El modelo de comparacin es visible a lo largo del esquema de depsito. De forma
directa se integran las nuevas herramientas puesto que son compatibles con el
modelo de datos acordado.
8. Sin embargo, es difcil distribuir el depsito en varias mquinas. Aunque es posible
distribuir un depsito centralizado lgicamente, habr problemas con la reduncia e
inconsistencia en los datos.
Figura 10.2 La arquitectura de un conjunto integradp de herramientas CASE
Editor de
Editor de
diseo
diseo

Traductor de
Traductor de
diseo
diseo

Generador de
Generador de
cdigo
cdigo

Depsito de proyectos
Depsito de proyectos

Analizador de
Analizador de
diseo
diseo

Editor de
Editor de
programas
programas

Generador de
Generador de
Informes
Informes

En el modelo anterior, el depsito es pasivo y el control es responsabilidad de los subsistemas que utiliza el
depsito .Existe un enfoque altrnativo para los sistenas IA que utilizan un modelo de pizarrn en el cual
dispara subsistemas cuando estn disponibles ciertos datos. Esto es apropiado cuando la forma del depsito de
datos no es tan estructurada.Las decisiones sobre que herramienta activar se toman cuando los datos ser han
analizado. Nii ( 1986) trata este modelo.