Temas IS

| |

Javier Martín
Centro Asociado de Móstoles /
Tres Cantos
UNED
|
ë JAV|ER MART|N (jmartin@escet.urjc.es)
£ TUTOR|AS: JUEVES/V|ERNES de 7 a 9
ë PLAN DE TRABAJO
£ Exposición de los temas y mediante
transparencia, abundando en los puntos
más importantes.
£ Resolución de dudas
£ Propuesta y resolución de ejercicios y
problemas
|NGEN|ERÍA DEL SOFTWARE Javier Martín ð

Î |NTRODUCC| N
Î ESPEC|F|CAC| N DEL SOFTWARE
Î FUNDAMENTOS DEL D|SEÑO
SOFTAWARE
Î TÉCN|CAS GENERALES DE D|SEÑO
SOFTWARE
Î COD|F|CAC| N Y PRUEBAS
Î AUTOMAT|AC| N Y PROCESO DE
DESARROLLO
|NGEN|ERÍA DEL SOFTWARE Javier Martín ·

|
|
|NGEN|ERÍA DEL SOFTWARE Javier Martín X

|!"
ë j
, conjunto de cosas que ordenadamente
relacionadas entre sí contribuyen a un determinado objeto. De forma
recursiva, las partes de un sistema pueden ser consideradas como
nuevos sistemas (subsistemas).
ë Los

están compuestos por ordenadores y sus
periféricos. Entre ellos podemos distinguir dos tipos de subsistemas:
£ Sistemas ù , son los elementos materiales, los que se
pueden tocar.
£ Sistemas a , los programas que gobiernan el
funcionamiento del computador.
ë El objetivo de los sistemas informáticos es el tratamiento de la
información: almacenamiento, elaboración y presentación de datos. De
esta forma se automatizan determinadas acciones.
ë En la concepción del sistema informático no solo se decide el trabajo a
realizar, sino también cómo ha de ser utilizado por los usuarios.
|NGEN|ERÍA DEL SOFTWARE Javier Martín

|!"# $%
ë Características del software (lo contrario para el hardware):
£ No se desgasta ni envejece, y por este motivo no requiere
reparaciones ocasionales
£ Su duplicación es poco costosa, lo caro es el desarrollo
£ Puede ser modificado fácilmente, tanto que es necesario un control
de versiones
ë La |ngeniería del Software comprende las técnicas y procedimientos
ingenieriles para el desarrollo del software.
ë La |S no se plantea solo una actividad de programación, previamente
son necesarias las fases de análisis y diseño y posteriormente la
integración y la verificación, incluso el manteniendo cuando el producto
ya está en explotación. (jj).
ë |nicialmente la tarea de desarrollo era realizada individualmente por
hábiles creativos, de forma poco disciplinada. El trabajo en equipo
supone la división y organización del trabajo utilizando

.
ë En los 70 y los 80 empiezan a usarse herramientas CASE (Computer
Aided Software Engineering). En los 90 |PSE e |CASE.
|NGEN|ERÍA DEL SOFTWARE Javier Martín U
# $%
ë Se produce cuando surge la necesidad de desarrollar
aplicaciones software demasiado complejas, a mediados
de los 60.
ë Para superar la crisis:
£ Aparición de metodologías concretas de desarrollo
£ Concepción de la |ngeniería del Software como disciplina
£ Trabajo en equipo y especialización (analistas,
programadores, ...)
ë No se ha llegado a una situación estable, sino a una
evolución permanente con avances continuos en la |S,
forzados por el rápido abaratamiento y aumento de
capacidad del hardware.
|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ

# $%
ë El hardware es mucho más importante que el
software
ë El software es fácil de desarrollar
ë El software consiste exclusivamente en programas
ejecutables
ë El desarrollo del software es sólo una labor de
programación
ë Es natural que el software contenga errores

#&# ##
ë La ingeniería supone la existencia de procesos bien
establecidos para la realización de actividades de
desarrollo, construcción, fabricación, etc.
ë El ciclo de vida es el proceso de desarrollo y
mantenimiento del software. Según el modelo elegido se
describen un conjunto de actividades para llevar a cabo el
ciclo de vida,
ë Los modelos clásicos:
£ MODELO EN CASCADA
£ MODELO EN V
ë Prácticamente identifican actividades similares y sólo se

diferencian en la forma de presentación.
|NGEN|ERÍA DEL SOFTWARE Javier Martín è

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

ë ANÁL|S|S, determinar qué debe hacer el software ->
especificación
ë D|SEÑO, descomponer y organizar el sistema para que los
módulos puedan ser desarrollados por separado
ë COD|F|CAC| N, escribir el código fuente de cada módulo
y realizar sobre ellos las pruebas necesarias
ë |NTEGRAC| N, combinar todos los módulos y probar el
sistema completo antes de pasar a su explotación
ë MANTEN|M|ENTO, durante la explotación es necesario
realizar cambios ocasionales bien para corregir errores o
para introducir mejoras,
ë Se trata de aislar cada fase de las otras, lo que facilita la
especialización de los desarrolladores. Al final de cada fase
se requiere un proceso de revisión`para evitar que los
errores se propaguen a fases posteriores provocando la
vuelta atrás. |NGEN|ERÍA DEL SOFTWARE Javier Martín oo

|
|NGEN|ERÍA DEL SOFTWARE Javier Martín oð

ë Cada fase debe generar una información de salida precisa
y suficiente:
£ DOCUMENTOS DE REQU|S|TOS DEL SOFTWARE (SRD),
es una especificación precisa y completa a partir de los
requisitos establecidos por el cliente.
£ DOCUMENTO DE D|SEÑO DEL SOFTWARE
(SDD),descripción de la estructura global del sistema,
especificación de qué debe hacer cada uno de los módulos y
de cómo se combinan.
£ C D|GO FUENTE, el programa debidamente comentado
(documentación interna).
£ S|STEMA SOFTWARE, el ejecutable producto dela fase de
integración y la documentación de las pruebas realizadas.
£ DOCUMENTOS DE CAMB|OS, después de cada
modificación realizada en la fase de mantenimiento: problema
detectado y solución adoptada
|NGEN|ERÍA DEL SOFTWARE Javier Martín o·

'
|NGEN|ERÍA DEL SOFTWARE Javier Martín oX

' |

'
ë |ncluye fases similares a las del modelo en
cascada pero de forma jerárquica. En horizontal se
representa el avance en el desarrollo y en vertical
el nivel de detalle.
ë VER|F|CAC| N, comprobación de que una parte
del sistema cumple con sus especificaciones.
ë VAL|DAC| N, comprobación de que un elmento
satisface las necesidades del usuario identificadas
durante el análisis.
|NGEN|ERÍA DEL SOFTWARE Javier Martín oU

|

ë En los modelos clásicos se insiste en las actividades de
revisión de resultados al final de cada fase para evitar la
vuelta atrás, que no se contempla de una forma organizada
y resulta muy costosa. Están orientados a una forma de
desarrollo lineal.
ë PROTOT|PO, es un sistema auxiliar que permite probar
experimentalmente soluciones parciales a los requisitos del
sistema
ë Para que el coste de desarrollo del prototipo sea bajo en
relación al del sistema final podemos:
£ Limitar las funciones
£ Limitar su capacidad
£ Limitar su eficiencia
£ Evitar limitaciones de diseño, utilizando un hardware más
potente que el que ejecutará el sistema final
£ Reducir la parte a desarrollar
|NGEN|ERÍA DEL SOFTWARE Javier Martín oÑ

|
( |

ë Su finalidad es solo adquirir experiencia, no se
aprovechan como producto (usar y tirar). Se
denominan maquetas cuando su funcionalidad o
capacidad es muy limitada.
ë El sistema final se codifica totalmente partiendo de
cero, no se aprovecha el código del prototipo
ë Lo importante de estos prototipos es que se
desarrollen en poco tiempo.

|
( |

|NGEN|ERÍA DEL SOFTWARE Javier Martín oè

|
'
|'

ë En este caso se intenta aprovechar al máximo el código del
prototipo, y para ello se emplea el mismo
hardware/software del sistema final.
ë Se realizan fases de análisis y diseño parcial, que se van
ampliando hasta construir el sistema final mediante
adiciones sucesivas.
ë Se puede considerar un modelo en cascada en bucle, de
manera que en cada iteración se va avanzando en el
desarrollo.
ë HERRAM|ENTAS PARA EL DESARROLLO DE
PROTOT|POS, se emplean lenguajes de 4ª generación,
que son de alto nivel y de tipo declarativo. También se
emplean lenguajes de especificación, como VDM y . Si
disponemos del compilador correspondiente podemos
obtener automáticamente el código del prototipo.
ë En el desarrollo de prototipos es clave la reutilización de
software. |NGEN|ERÍA DEL SOFTWARE Javier Martín ð

|
'
|'

|NGEN|ERÍA DEL SOFTWARE Javier Martín ðo

|
ë Puede considerarse como un refinamiento del modelo
evolutivo general que introduce el análisis de riesgo como
elemento fundamental para guiar la evolución del proceso
de desarrollo.
ë En la dimensión radial se representa el esfuerzo realizado
en el desarrollo (siempre creciente)
ë En cada iteración 4 fases:
£ PLAN|F|CAC| N, determina que parte del desarrollo se
abordará en ese ciclo.
£ ANAL|S|S DE R|ESGO, evaluar diferentes alternativas para
esa parte del desarrollo seleccionando la más ventajosa y
tomando precauciones para evitar los posibles
inconvenientes.
£ |NGEN|ERÍA, las actividades de los modelos clásicos
£ EVALUAC| N, se analizan los resultados de la fase de
ingeniería.
|NGEN|ERÍA DEL SOFTWARE Javier Martín ðð

|
|NGEN|ERÍA DEL SOFTWARE Javier Martín ð·

||

ë El mantenimiento no representa una actividad específica,
sino que consiste en rehacer parte de las actividades
correspondientes a las otras fases del desarrollo para
introducir cambios sobre una aplicación ya en fase de
explotación.
ë MANTEN|M|ENTO CORRECT|VO, su finalidad es corregir
errores que no fueron detectados en el desarrollo del
producto.
ë MANTEN|M|ENTO ADAPTAT|VO, modificar una aplicación
para adaptarla a las nuevas necesidades del entorno.
ë MANTEN|M|ENTO PERFECT|VO, se trata de ir obteniendo
versiones mejoradas del producto
|NGEN|ERÍA DEL SOFTWARE Javier Martín ðX

| |

ë El mantenimiento supone la realización de una serie de
cambios sucesivos
ë Si afectan a la mayor parte del sistema se puede plantear
como un nuevo desarrollo.
ë Cada cambio debe ser documentado con:
£ |NFORME DEL PROBLEMA, que ocasiona el cambio. Suele
ser propuesto por el cliente.
£ |NFORME DE CAMB|O, describe la solución dada al
problema y el cambio realizado
ë RE|NGEN|ERÍA, es necesaria cuando el desarrollo de una
aplicación no está documentado y se dispone solamente
del código. Se llama también ingeniería inversa porque
supone reconstruir y documentar las fases de análisis y
diseño llegando a la estructura modular de la aplicación y
las dependencias entre módulos y funciones. Estas
actividades organizan y documentan un sistema deficiente.ð
|
ë Para evaluar la calidad son necesarias técnicas de aplicación de métricas precisas
tanto sobre los productos software como a sus procesos de desarrollo.
ë McCall propone un esquema basado en valoraciones a 3 niveles:
£ FACTORES, valoración significativa de la calidad en base a los criterios
establecidos
£ CR|TER|OS, aspectos de nivel intermedio que influyen en los factores de calidad
£ MÉTR|CAS, mediciones puntuales de determinadas características del producto.
ë Entre los factores de calidad tenemos:
£ CORRECC| N, grado en que cumple con las especificaciones
£ F|AB|L|DAD, grado de ausencia de fallos
£ EF|C|ENC|A, reilación entre la cantidad de resultados y los recursos requeridos
£ SEGUR|DAD, dificultad para el acceso a datos por personas no autorizadas
£ FAC|L|DAD DE USO, esfuerzo requerido para el aprendizaje de la aplicación
£ MANTEN|B|L|DAD. Facilidad para corregir el producto en caso necesario.
£ FLEX|B|L|DAD, facilidad para modificar el producto
£ FAC|L|DAD DE PRUEBA, depende del esfuerzo requerido para comprobar su
corrección o fiabilidad
£ TRANSPORTAB|L|DAD, facilidad para adaptar el producto a otra plataforma
£ REUSAB|L|DAD, facilidad para usar partes del producto en otros desarrollos
|NGEN|ERÍA DEL SOFTWARE Javier Martín ðU
£ |NTEROPERAT|V|DAD, facilidad del producto para trabajar con otros
|) *
ë Es un documento formal para organizar el proceso de
desarrollo software de manera que se asegure la calidad
del producto final. Debe contemplar:
£ Organización, dirección y seguimiento de los equipos de
desarrollo
£ Modelo de ciclo de vida a seguir, detallando fases y
actividades
£ Documentación requerida, determinando contenido y guión
de cada documento
£ Revisiones y auditorias, para garantizar que las actividades y
los documentos son correctos
£ Organización de las pruebas, a distintos niveles
£ Organización de la etapa de mantenimiento, determinando
cómo gestionar la realización de cambios
|NGEN|ERÍA DEL SOFTWARE Javier Martín ðÑ

'| |

ë Consiste en inspeccionar el resultado de una actividad para
determinar si es aceptable o contiene defectos que han de
ser subsanados.
ë Las revisiones deben ser formalizadas y contempladas en
el modelo de ciclo de vida:
£ Deben ser realizadas por un grupo de personas y no
individualmente
£ El grupo de be ser reducido
£ Debe ser imparcial, nada que ver con los desarrolladores
£ Se debe revisar el producto, pero no el productor ni el
proceso de producción
£ Se debe establecer de antemano una lista formal de
comprobaciones
£ Se debe levantar acta de la reunión de revisión, recogiendo
las decisiones tomadas

ë Consiste en hacer funcionar el producto o una
parte de él y comprobar si los resultados son
correctos.
ë No permite garantizar la calidad del producto. En
general no es posible probar un producto de forma
exhaustiva, debido a su complejidad.
|NGEN|ERÍA DEL SOFTWARE Javier Martín ðè

ë
|
||
jj, disposición de las partes que componen una cosa y le
dan su peculiar figura.
ë La jj a!" se refiere a la manera en que diversos
elementos se combinan para construir un producto software.
ë Se han de combinar todos los elementos que intervienen en el desarrollo:
£ Documentos del desarrollo
£ Código fuente
£ Programas, datos y resultado de las pruebas
£ Manuales de usuario
£ Documentos de mantenimiento, informes de problemas y cambios
£ Prototipos intermedios
£ Normas particulares del proyecto
ë Dado que los elementos software van evolucionando a lo largo del
desarrollo se requiere:
£ Control de versiones, almacenar de forma organizada las sucesivas
versiones de cada elemento de la configuración.
£ Control de cambios, garantizar que las diferentes configuraciones del
software se componen de elementos compatibles entre sí (línea base).

+ (
ë |EEE, |nstitute of Electrical and Electronics
Engineer de USA [|EEE93]
ë DoD, Departament od Defense de USA [DoD88]
ë ESA, Agencia Europea del Espacio [ESA91]
ë |SO, organismo internacional de normalización
(|nternational Standars Organization). En España
AENOR.
ë METR|CA-2, desarrollada por el Consejo Superior
de |nformática del MAP. Se basa en la
metodología de análisis y diseño de
Yourdon/DeMarco.
|NGEN|ERÍA DEL SOFTWARE Javier Martín ·o

,
|||

|NGEN|ERÍA DEL SOFTWARE Javier Martín ·ð

|
ë El análisis y la definición de los requisitos debe dar lugar a
la especificación software, en la que se concretan las
necesidades que se desean cubrir y se fijan las
restricciones con las que debe trabajar el software.
ë El modelado de los sistemas tiene como objetivo entender
mejor el comportamiento requerido y facilitar la
comprensión de los problemas planteados. Se trata de
establecer modelos conceptuales que reflejen la
organización de la información y las diversas
transformaciones que se deben llevar a cabo con dicha
información.
ë Las metodologías de análisis de requisitos tratan de
facilitara obtención de uno o varios modelos que detallen el
comportamiento deseado del sistema.
|NGEN|ERÍA DEL SOFTWARE Javier Martín ··

ë Un modelo conceptual es una abstracción lógico-

matemática del mundo real que facilita la comprensión del
problema a resolver. Se trata de ofrecer una visión de lato
nivel, sin descender a explicar detalles concretos del
mismo. |ndica QUÉ hace el sistema y no C MO lo debe
hacer.
ë Los OBJET|VOS a cubrir con los modelos son:
£ Facilitar la comprensión de l problema
£ Establecer un marco para la discusión que simplifique y
sistematice el análisis
£ Fijar las base para el diseño
£ Facilitar la verificación del cumplimiento de los objetivos del
sistema
|NGEN|ERÍA DEL SOFTWARE Javier Martín ·X

- |

)|
ë DESCOMPOS|C| N. MODELO JERARQU|ADO, aplica el ³divide y
vencerás´, y así el problema queda dividido en un subconjunto de
subproblemas. Se trata de una descomposición funcional que se
denomina horizontal o bien se descompone tratando de detallar la
estructura, de forma vertical. Para completar el modelado es necesario
establecer los interfaces entre las partes del sistema para posibilitar el
funcionamiento del sistema global.
ë APROX|MAC|ONES SUCES|VAS, podemos tomar como partida el
modelo de un sistema similar, y luego mediante la experiencia del
analista y el conocimiento del problema que proporciona el experto se
irán proponiendo modelos intermedios, discutiendo sus ventajas e
inconvenientes.
ë EMPLEO DE D|VERSAS ANOTAC|ONES, el lenguaje natural
introduce imprecisiones, repeticiones e incluso incorrecciones en el
modelo. Es recomendable emplear notaciones gráficas que sean
entendibles por todos los que participan en el proyecto. Se suele
recurrir a notaciones precisas que combinan texto, tablas, diagramas y
gráficos.
- |

)||
ë CONS|DERAR D|S|TNTOS PUNTOS DE V|STA, en la
elaboración del modelo es necesario adoptar un determinado
punto de vista. Si así la descripción es insuficiente conviene
adoptar más de uno.
ë REAL|AR UN ANÁL|S|S DEL DOM|N|O, es decir en campo
de aplicación en que se enmarca el sistema a desarrollar. Hay
que considerar:
£ Normativa que afecta al sistema
£ Otros sistemas semejantes
£ Estudios recientes en el campo de la aplicación, bibliografía, etc.
ë Las ventajas de realizar un modelos más general son:
£ Facilitar la comunicación entre el analista y el usuario del sistema,
p.e. usando la misma terminología.
£ Creación de elementos realmente significativos del sistema, si se
ajusta a la normativa específica establecida.
£ Reutilización posterior del software desarrollado.
|NGEN|ERÍA DEL SOFTWARE Javier Martín ·U
(| | *| |

ë El análisis es la fase de definición del futuro sistema y tiene una importancia decisiva
en el desarrollo de todas las etapas posteriores.
ë Con el análisis de requisitos se trata de caracterizar el problema a resolver. El
³cliente´ trabaja con el analista para elaborar las especificaciones y posteriormente
se encargarán de verificar el cumplimiento de las mismas (contrato).
ë El análisis debe producir un modelo válido necesario y suficiente para recoger todas
las necesidades y exigencias del sistema, así como las restricciones que los limiten.
Para una especificación correcta se requiere:
£ Completo y sin omisiones
£ Conciso y sin trivialidades
£ Sin ambigüedades
£ Sin detalles de diseño o implementación
£ Fácilmente entendible por el cliente
£ Separando requisitos funcionales u no funcionales (capacidades mínimas y
máximas, interfaces estándares, recursos necesarios, seguridad, fiabilidad,
mantenimiento, etc.
£ División y jerarquía del modelo global, con el fin de simplificar su comprensión
£ |ncluyendo los criterios de validación del sistema, para comprobar si se ajusta al
contrato inicial.
|NGEN|ERÍA DEL SOFTWARE Javier Martín ·Ñ

(| |
ë Dependiendo de las características y complejidad del sistema
se podrán seguir los siguientes pasos:
£ ESTUD|O DEL S|STEMA EN SU CONTEXTO, análisis del
dominio en un contexto globalizador
£ |DENT|F|CAC| N DE NECES|DADES, detectar necesidades de
medios dentro de plazos y presupuestos
£ ANÁL|S|S DE ALTERNAT|VAS Y ESTUD|O DE V|AB|L|DAD,
tanto técnica como económica
£ ESTABLEC|M|ENTO DEL MODELO DEL S|STEMA, para lo que
podemos usar técnicas gráficas, texto, herramientas CASE, etc.
£ ELABORAC| N DEL DOCUMENTO DE ESPEC|F|CAC| N DE
REQU|S|TOS, dónde se recogen las conclusiones del análisis y
sirve de punto de partida para el diseñador.
£ REV|S| N CONT|NUADA DEL ANÁL|S|S, a menudo en las
etapas de diseño e implementación se hace necesaria la revisión
de alguno de los requisitos, o bien por cambios de criterio del
cliente |NGEN|ERÍA DEL SOFTWARE Javier Martín ·

|
|||
ë La especificación es una descripción del modelo del
sistema a desarrollar.
ë Se debe usar una notación fácil de entender por el cliente:
£ Lenguaje natural, utilizando explicaciones más o menos
precisas y exhaustivas. Es posible limitar precisiones y
ambigüedades si se establecen reglas de uso del lenguaje.
£ Diagramas de flujo de datos
£ Diagramas de transición de estados
£ Descripciones funcionales. Pseudocódigo. Se emplea un
preciso lenguaje natural estructurado. No se debe detallar
demasiado el cómo, pues esto corresponde a la fase de
diseño, donde se usan lenguajes estructurados como PLD.
£ Descripción de datos, de trata de detallar la estructura interna
de los datos que maneja el sistema. En la metodología
Yourdon se conoce como diccionario de datos, incluyendo
nombre de cada dato, utilización y estructura.
£ Diagramas de modelos de datos
|NGEN|ERÍA DEL SOFTWARE Javier Martín ·è
| .

)
ë Se trata de realizar un modelo gráfico para representar el flujo de datos
que entra en el sistema, las transformaciones que debe realizar y la
salida producida. También se representan las entidades externas la
sistema que producen o consumen datos. El DFD inicial es el de
contexto, posteriormente y de forma jerárquica se van desarrollando
otros DFD¶s que detallan las transformaciones, las entradas y salidas
del diagrama detallado deben coincidir con el proceso correspondiente.
ë Recoge de forma estática los procesos, dónde en el último nivel de
refinamiento se especifican en lenguaje natural estructurado, y su
interrelación.

| ||

ë Describe el comportamiento dinámico del sistema
basándose en sus estados más importantes.
ë Al igual que en los autómatas de estados finitos,
los eventos motiva el cambio de estado del
sistema.
|NGEN|ERÍA DEL SOFTWARE Javier Martín Xo

|

ë Se trata de organizar e interrelacionar los datos
que utiliza el sistema.
ë El MODELO ENT|DAD-RELAC| N permite definir
todos los datos y establecer las relaciones que
deben existir entre ellos.
|NGEN|ERÍA DEL SOFTWARE Javier Martín Xð

/ ||| *| |

ë El documento o la especificación de requisitos (SRD o
SRS) recoge de forma integral los resultados del análisis.
ë Puede haber documentos previos al SRD, como estudios
de viabilidad o de alternativas posibles.
ë El SRD debe ser revisado con cierta frecuencia durante el
desarrollo y debe facilitar la varificación de las
especificaciones (contrato).
ë Diversos organismos de estandarización hacen propuestas
sobre la estructura del SRD: |EEE, DoD, etc. Vemos el
modelo de SRD de la Agencia Espacial Europea.
Dependiendo de las características y complejidad del
proceso tal vez no sea necesario cubrir todos los
apartados.
|NGEN|ERÍA DEL SOFTWARE Javier Martín X·

1. |ntroducción
1. Objetivo: objetivos, participantes, calendario,...
2. Ámbito, identificará y dará nombre al producto
3. Definiciones, siglas y abreviaturas
4. Referencias, la descripción bibliográfica de los documentos referenciados.
5. Panorámica del documento
2. Descripción general
1. Relación con otros proyectos, similares o complementarios
2. Relación con proyectos anteriores o posteriores
3. Objetivo y funciones
4. Consideraciones de entorno
5. Relaciones con otros sistemas, que utilicen entradas o salidas indirectas de
información
6. Restricciones generales: metodologías, lenguajes, de hardware,...
7. Descripción del modelo, es el apartado más extenso y más importante. Se
utilizan todas las notaciones y herramientas disponibles
|NGEN|ERÍA DEL SOFTWARE Javier Martín XX

3. Requisitos específicos, lista detallada y completa de los requisitos del sistema, indicando su
grado de cumplimiento (obligatorio, recomendable, opcional. No incluir aspectos de diseño o
desarrollo, ni tampoco soluciones particulares que no sean obligadas
3. Requisitos específicos, QUÉ debe hacer el sistema especificando el tratamiento de
la información.
4. Requisitos de interfase, conexión con otros sistemas con los que interactúa (bases
de datos, ficheros, SSOO,...).
5. Requisitos de operación, es decir, del interfaz de usuario
6. Requisitos de capacidad, volumen procesador, tiempo respuesta, tamaño ficheros.
Se debe cuantificar para el peor, el mejor y el caso más habitual.
7. Requisitos de verificación, que debe cumplir el sistema para que se posible verificar
su corrección
8. Requisitos de pruebas de aceptación
9. Requisitos de recursos, instalaciones y elementos necesarios para el
funcionamiento del sistema
10. Requisitos de documentación
11. Requisitos de transportabilidad, para adaptalo a otras plataformas
12. Requisitos de calidad, que no hayan sido recogidos en otros apartados
13. Requisitos de fiabilidad, imponiendo un límite aceptable de fallos
14. Requisitos de mantenibilidad
15. Requisitos de seguridad, contra utilización indebida
16. Requisitos de salvaguarda, para evitar consecuencias graves en equipos o en
personas
4. APEND|CES, para complementar el contenido del documento
'|
.
|
|NGEN|ERÍA DEL SOFTWARE Javier Martín XU

| | ||

|NGEN|ERÍA DEL SOFTWARE Javier Martín XÑ

| | ||


| | ||

|NGEN|ERÍA DEL SOFTWARE Javier Martín Xè

| | ||


| | ||


0

| 1


| 1
ë Descripción o bosquejo de alguna cosa hecho por

palabras.
ë En un sistema software la realización del diseño parte del
SRD y no es nada trivial. Cuando no se tiene experiencia
en el desarrollo concreto se hace de forma iterativa
mediante ensayo y error, en caso contrario se aprovecha el
³know-how´ (saber hacer).
ë Las técnicas para realizar diseños nuevos son empíricas y
no están suficientemente formalizadas, mientras que para
proyectos ya conocidos, como los de gestión, existen
herramientas tales como lenguajes de 4ª generación.
ë En el diseño se establece el C MO debe funcionar el
sistema, determinando la organización y la estructura del
software.
|'| | 1
| (|
ë D|SEÑO ARQU|TECT N|CO, se abordan los aspectos

estructurales y de organización del sistema, y su posible
división en subsistemas
ë D|SEÑO DETALLADO, organización y estructura de los
módulos
ë D|SEÑO PROCED|MENTAL, organización de las
operaciones o servicios que ofrecerá cada módulo. Se

suele realizar en pseudocódigo o PDL, pero desarrollando
sólo los aspectos más relevantes del algoritmo
ë D|SEÑO DE DATOS, organización de la base d edatos del
sistema. Se parte de los diagramas E-R.

ë D|SEÑO DE LA |NTERFA DE USUAR|O, organizar y
facilitar la utilización del sistema por parte del usuario

El resultado de estas actividades debe plasmarse en el
Documento d Diseño Software (SDD)
ë

| 1
#a!jj, identificar los elementos significativos del sistema y abstraer la utilidad específica de cada uno
£ ABSTRACC|ONES FUNC|ONALES, sirven para crear expresiones parametrizadas usando funciones o
procedimientos
£ T|POS ABSTRACTOS, junto con el tipo de datos se deben crear los métodos que manejan estos datos
£ MÁQU|NAS ABSTRACTAS, definición formal del comportamiento de una máquina
ë , el diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Sus
ventajas: claridad, reducción de costos y reutilización
ë !, a partir de una idea no muy concreta se va refinando mediante aproximaciones hasta el detalle
ë a!j!a!a, para organizar la información que maneja el sistema: registros, conjuntos, listas, pilas,
colas, árboles, grafos, tablas, ficheros, ...
ë j!j, de la organización de los datos internos y de los detalles del algoritmo, se muestra en el interfaz sólo
aquello que resultará invariable ante cambios. Ventajas: depuración, mantenimiento, ...
ë j, consiste en diseñar un elemento genérico, con las características comunes a todos los elementos
agrupados
ë ùj, los elementos hijos heredan del padre su estructura y operaciones para ampliarlos, mejorarlos o
adaptarlos. Es conveniente utilizar un lenguaje de programación orientado a objetos
ë ÿa, es la propiedad de los elementos que pueden variar su formar sin cambiar su naturaleza. Se
emplea el concepto de genericidad. En los hijos se puede producir la anulación de una operación. A veces en el
padre interesa declarar un método sin implementarlo, lo harán los hijos en diferido
ë jjj, se trata de aprovechar al máximo el procesador garantizando unos tiempos máximos de
respuesta para tareas críticas. Problemas de los sistemas con restricciones:
£ Tareas concurrentes, asegurar que todas cumplen sus restricciones
£ Sincronización de tareas, determinando los puntos de sincronización entre ellas
£ Comunicación entre tareas, unas serán productoras de datos y otras consumidoras. Para evitar la corrupción
de datos compartidos permitir sólo concurrencia en lectura con semáforos, monitores y regiones críticas
£ |nterbloqueos (deadlock) cuando varias tareas esperan un evento que nunca se producirá

|
| 1
ë Debe resultar precisa, clara y fácil de interpretar.

Se emplean notaciones formales
cuasimatemáticas
ë NOTAC|ONES ESTRUCTURALES, se desglosa y
estructura el sistema en sus partes
£ D|AGRAMAS DE BLOQUES
£ CAJAS ADOSADAS

|
)+
à

!"

!#$

%

"&'" %
$" %

(
) !""
*!+$ (

,

%

-

| 2|
)2345| 5
5

a
%

.
+)/"

0 12 3

/ 1
a

| .6
% 4

1
(
% 3
5%

1
5"

%
56%

%
% 4


|
(|
ë Describen las características estáticas del sistema, tales
como la organización de la información, sin tener en cuenta
su evolución durante el funcionamiento del sistema.
ë Las notaciones son las mismas que se emplean en la
especificación:
£ D|CC|ONAR|O DE DATOS, dónde se detalla la estructura
interna de los datos que maneja el sistema. En el diseño se
amplía y se completa el diccionario de la especificación hasta
el nivel de detalle necesario para iniciar la codificación.
£ D|AGRAMAS ENT|DAD-RELAC| N, definiendo las
relaciones entre datos y la organización de la información. Se
amplia y detalla el diagrama de la especificación con las
nuevas entidades y relaciones.

|
| (|
ë Permiten describir el funcionamiento del sistema
durante su funcionamiento.
ë Las notaciones son las misma utilizadas en la
especificación:
£ D|AGRAMAS DE FLUJO DE DATOS, serán mucho
más exhaustivos que los de la especificación.
£ D|AGRAMAS DE TRANS|C| N DE ESTADOS,
más detallados que reflejen las transiciones entre
estados internos.
£ LENGUAJE DE DESCR|PC| N DE PROGRAMAS
(PLD), permite realizar la especificación funcional
del sistema.
|NGEN|ERÍA DEL SOFTWARE Javier Martín Uo

|
2|| |
|

/
4
%

,
-
, % -1

7
à)$$&$aà$'a$)"a
%
%
3 1
%

7

2%
3
"&'

")à"

"/$)"a%

!
, %
-
%
% 7

%

%

1 % % %

(

% 7

%
7
|NGEN|ERÍA DEL SOFTWARE Javier Martín Uð

|
2|| |

.

a %

%

1
6 %
3
87 6
(

%

97
0 1 0
à % %

%
%
3
5!$a)*)$):a/)$!);$):"+)$
5"&/"a)):%

|NGEN|ERÍA DEL SOFTWARE Javier Martín U·

| 1

ë 87| | < / (

7!
%
aà
£ 878"
( 777
£ 879

£ 872à 1 (

£ 87=
ë 97/$"&)$à!a)a&$(
1

%
4
ë 27">"à!a)a&$% 6

£ 27à
6

ë =7à)a?"à!a)a&$ ( % 4

£ =78&
4
(
£ =79à %
% ( %
%
%%
ë @7à)a?"à!"a"&/"a % %
%
=79
£ @7)
%

£ @77% ,% %
%

£ @779"
( 6
%
£ @772* 0 %
£ @77=a
%

£ @77@à % 1
3( %
%

7
£ @77A)

%

B C
£ @77D
% %
£ @77E 0

6

£ @77F/

%
%
£ @77Gà
%

% ( %

ë A7H)$')!)à$à1 a"aa)&$à"a
ë D7&$);I )a)"a "&/"a %
1 %

|NGEN|ERÍA DEL SOFTWARE Javier Martín UX

| 1

/
87àa)/):$!
87)"à ):
878"
(
879

872à 1 (

87=
87@/
97"&$a"H)"a1/"à)&)"a
978 4 (
979 1 (

972 ( ,0 %
7-
97= %
97@+

/
97a/)*)$)"aàà)a?"à$!!$à"
7)
%
7)

79%
72"
(
7=*
7@a
7Aà %
7D)

7E
7F
7G/
7à

$/Jà)$7!)a$à"a*
$/Jà)7&$);I )a)"a "&/"a
7
- |
| 1

|NGEN|ERÍA DEL SOFTWARE Javier Martín UU

- | | 1
ë Los objetivos de las técnicas de diseño software son

fundamentalmente:
£ La descomposición modular del sistema
£ Los diseños de los algoritmos y estructuras de datos
fundamentales que se deben usar en el sistema
ë Primero veremos las características deseables de una
buena descomposición modular del sistema, y luego se
presentarán técnicas de diseño:
£ Diseño funcional descendente
£ Diseño orientado a objetos
£ Diseño de datos
|NGEN|ERÍA DEL SOFTWARE Javier Martín UÑ

||

ë Los pasos a seguir son:
1. |dentificar los módulos
2. Describir cada módulo
3. Describir las relaciones entre módulos
ë Tipos de módulos:
1. Código fuente, en el lenguaje de programación usado
2. Tabla de datos, para datos de inicialización u otros
3. Configuración, se agrupa en un módulo toda la información de
configuración en el entorno de trabajo
4. Otros: ficheros de ayuda en línea, manuales, etc.
ë Una descomposición modular debe poseer ciertas cualidades mínimas
para que se pueda considerar suficientemente válida
ë |ndependencia fucional
ë Acoplamiento
ë Cohesión
ë Comprensibilidad
ë Adaptabilidad

||
| | |

ë Al final de los documentos ADD y DDD debe haber una matriz
REQU|S|TOS/COMPONNETES. En principio, cada función será realizada en
un módulo distinto. Si las funciones son independientes los módulos tendrán
independencia funcional.
ë Cada módulo debe realizar una función concreta o un conjunto de funciones
afines. Es recomendable reducir las relaciones entre módulos al mínimo.
ë Para medir la independencia funcional hay dos criterios:
y
$ %.

||

|
El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la
complejidad de la interfase:
ë FUERTE,
ë POR CONTEN|DO, cuando desde un módulo se pueden cambiar datos locales de otro
ë COMÚN, se emplea una zona común de datos a la que tienen acceso varios módulos
ë MODERADO,
ë DE CONTROL, la zona común es un dispositivo externo al que están ligados los módulos,
esto implica que un cambio en el formato de datos afecta a todos estos módulos
ë POR ET|QUETA, en ontercambio de datos se realiza mediante una referencia a la
estructura completa de datos (vector, pila, árbol, grafo, ...)
ë DÉB|L,
ë DE DATOS, viene dado por los datos que intercambian los módulos. Es el mejor posible
ë S|N ACOPLAM|ENTO D|RECTO, es el acoplamiento que no existe
|NGEN|ERÍA DEL SOFTWARE Javier Martín Uè

||

2 |
ë Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el nº de
módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y
relacionados en un mismo módulo.
ë ALTA
ë COHES| N ABSTRACC|ONAL, se logra cuando se diseña el módulo como tipo abstracto
de datos o como una clase de objetos
ë COHES| N FUNC|ONAL, el módulo realiza una función concreta y específica
ë MED|A
ë COHES| N SECUENC|AL, los elementos del módulo trabajan de forma secuencial
ë COHES| N DE COMUN|CAC| N, elementos que operan con le mismo conjunto de datos
de entrada o de salida
ë COHES| N TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej.
Arrancar o parar dispositivos
ë BAJA
ë COHES| N L G|CA, se agrupan elementos que realizan funciones similares. Ejs.: módulos
de E/S o de tratamiento de errores
ë COHES| N CO|NC|DENTAL, es la peor y se produce cuando los elementos de un módulo
no guardan relación alguna
ë La descripción del comportamiento de un módulo permite establecer el grado de cohesión:
ë Si es una frase compuesta y contiene más de un verbo la cohesión será MED|A
ë Si contiene expresiones secuenciales (primero, entonces, cuando...), será temporal o secuencial
ë Si la descripción no se refiere a algo específico (Ej. Todos los errores), cohesión lógica
ë Si aparece ³inicializar´, ³preparar´, ³configurar´, probablemente sea temporal.

||

|||
ë Para facilitar los cambios, el mantenimiento y la reutilización de módulos es
necesario que cada uno sea comprensible de forma aislada. Para ello es bueno
que posea independencia funcional, pero además es deseable:
ë |DENT|F|CAC| N, el nombre debe ser adecuado y descriptivo
ë DOCUMENTAC| N, debe aclarar todos los detalles de diseño e
implementación que no queden de manifiesto en el propio código
ë S|MPL|C|DAD, las soluciones sencillas son siempre las mejores

||
||
ë La adaptación de un sistema resulta más dificil cuando no hay independencia
funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño
es poco comprensible. Otros factores para facilitar la adaptabilidad:
ë PREV|S| N, es necesario prever que aspectos del sistema pueden ser
susceptibles de cambios en el futuro, y poner estos elementos en módulos
independientes, de manera que su modificación afecte al menor número de
módulos posible
ë ACCES|B|L|DAD, debe resultar sencillo el acceso a los documentos de
especificación, diseño, e implementación para obtener un conocimiento
suficiente del sistema antes de proceder a su adaptación
ë CONS|STENC|A, después de cualquier adaptación se debe mantener la
consistencia del sistema, incluidos los documentos afectados
|NGEN|ERÍA DEL SOFTWARE Javier Martín Ño

- | | 1
|

ë La descomposición del sistema se hace desde un punto de vista funcional.
ë Desde el punto de vista de la codificación, cada módulo corresponde
esencialmente a un subprograma.
- | | 1
|

| |

|'
ë Esta técnica consiste en la aplicación de la fase de diseño de la programación

estructurada. Las estructuras básicas son la secuencia, la selección entre
alternativas y la iteración.
ë Cada paso en la descomposición consiste en refinar o detallar una parte del
programa global u operación, que a su vez podrá ser descompuesta en otras
operaciones. Los refinamientos se basan en la aplicación de estructuras de control
en el programa. Veamos como ejemplo ³obtener las raíces de una ec. de 2º grado´:

-->

-->
S| ENTONCES

S|-NO

F|N-S|

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñð
- | | 1
|

| .6
ë Esta técnica sigue las ideas de la programación estructurada (secuencia,

selección, iteración) y el método de refinamientos sucesivos pàra construir la
estructura del programa en forma descendente.
ë Se recomienda construir la estructura del programa de forma similar a las
estructuras de datos de entrada y de salida
ë Pasos de la técnica JSP:
1) Analizar el entorno del problema y describir las estructuras de datos a
procesar
2) Construir la estructura del programa basándose en las estructuras de
datos
3) Definir las tareas a realizar en cada módulo de la estructura del programa
ë Este tercer paso corresponde en su detalle a la fase de codificación
ë Ej.: Programa para justificar el texto, es decir, reagrupar las palabras en líneas
e intercalar los espacios adecuados para que se ajusten a los márgenes
ë PASO 1. Las estructuras de datos que reconocemos son
ë Texto de entrada = {[separador de párrafo | palabra]}
ë Texto de salida = {[línea ajustada | línea final | línea en blanco]}
|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ·

- | | 1
|

| .6
ë En el PASO 2 se trata de encontrar

una estructura del programa que se
ajuste a las estructuras de los datos
de entrada y salida
|NGEN|ERÍA DEL SOFTWARE Javier Martín ÑX

- | | 1
|

| 1

ë Según esta técnica, la tarea de diseño consiste en pasar de los DFDs a los
diagramas de estructura.
ë Hay que establecer una jerarquía o estructura de control entre los diferentes
módulos, que no está implícita en el modelo funcional descrito en los DFDs
ë Para dos módulos relacionados en el DFD (A) tenemos 3 posibilidades de
organización modular diferentes.

- | | 1
|

| 1

ë Para establecer la jerarquía de control entre módulos se recomienda hacer

ciertos análisis en el flujo de datos: de flujo de transformación y de flujo de
transacción. Para ello es recomendable construir un DFD con todos los
procesos contenidos en los primeros niveles prescindiendo de los almacenes.

0
7
! %
% 92
3

1
7
|NGEN|ERÍA DEL SOFTWARE Javier Martín ÑU

- | | 1
|

| 1

%
% % (
% 7

%

%

|NGEN|ERÍA DEL SOFTWARE Javier Martín ÑÑ

- | | 1
|

| 1

/./ | ||


- | | 1

|

ë La idea es que los módulos corresponden a funciones o a tipos abstractos de datos.
ë Los lenguajes que dan más facilidades para la implementación son los orientados a
objetos
- | | 1

|

||
|

ë Se trata de ampliar el lenguaje de programación con nuevas operaciones y tipos de
datos definidos por el usuario, de forma que se simplifique la escritura de los niveles
superiores del programa, basándose en módulos que realicen estas operaciones
ë Podemos identificar los tipos abstractos correspondientes a un número
ë complejo y a una ecuación de 2° grado y definir sobre dichos tipos abstractos las
siguientes operaciones:
Ecuación de 2° grado: Número complejo:

ë La estructura modular del programa sería:
|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñè

- | | 1

|
-

ë A partir de la descripción o especificación de los módulos es posible identificar las palabras o términos que
puedan corresponder a elementos significativos del diseño:
ë Tipos de datos, que aparecen como sustantivos genéricos
ë Atributos, son sustantivos en general
ë Operaciones, tienen la forma de verbos o nombres de acciones
ë Se subrayan en la descripción las palabras significativas haciendo una lista de nombres y otra de verbos u
operaciones. Hay que eliminar los términos irrelevantes o los sinónimos de palabras ya aparecidas
DATO Atributos Operaciones

Palabra Caracteres |mprimir
Párrafo Separador |niciar párrafo

Línea salida Poner palabra
Terminar párrafo
Separador de Líneas en blanco
párrafo Sangrado
Línea Sangrado |niciar línea
Palabras ¿cabe palabra?
Poner palabra
|mprimir sin ajustar
|mprimir ajustada

- | | 1

|
.

ë Es esencialmente igual al diseño basado en abstracciones, añadiendo la
herencia y el polimorfismo.
ë En la descomposición modular del sistema cada módulo contiene la
descripción de una clase de objetos o de varias clases relacionadas entre
sí.
ë PASOS:
£ Estudiar y comprender el problema a resolver
£ Desarrollar en líneas generales uan posible solución, al menos
informal
£ Formalizar dicha estrategía en términos de clases, objetos y sus
relaciones:
Î |dentificar los objetos, sus atributos y sus componentes
Î |dentificar las operaciones sobre los objetos y asociarlas a la clase
adecuada
Î Aplicar herencia donde convenga
Î Describir cada operación en función de las otras, y subsanar posibles
omisiones
Î Asignar clases y objetos a los módulos del sistema

- | | 1

ë Muchas aplicaciones necesitan almacenar información de forma permanente y la
mejor forma de hacerlo es crear una base de datos subyacente
ë Podemos enfocar la organización de la base de datos de 3 formas:
£ Nivel externo Esquemas de usuario
£ Nivel conceptual Esquemas lógicos
£ Nivel interno Esquemas físicos
ë El nivel externo corresponde a la visión del usuario, en la fase de análisis de pasa
al nivel conceptual, que establece la organización de los datos, y finalmente en la
etapa de diseño se pasa al nivel interno.
ë D|SEÑO DE BASES DE DATOS RELAC|ONALES, en este modelo la eficiencia se
basa en:
£ Las FORMAS NORMALES, que tienden a evitar las redundancias en los datos
almacenados
Î FN1, la información asociada a cada columna de la tabla es un único valor, y no
una colección
Î FN2, si hay una clave primaria que distingue e identifica cada fila, el resto de los
datos dependen de toda la clave primaria
Î FN3, el valor de cada columna que no es clave primaria depende directamente de
la clave primaria. Se puede conseguir si se separan las tablas.
£ Los |ND|CES, que mejoran la velocidad de acceso a los datos

- | | 1

| 1
|
ë En el modelo relacional cada entidad
del modelo E-R se traduce en una
tabla por cada clase de entidad, con
una fila por cada elemento de esa
clase y una columna por cada atributo
de esa entidad.
ë Entre las entidades relacionadas se
puede incluir una columna con un
número de referencia o identificador
que las relaciona, sirve como clave
primaria.
ë En el modelo E-R todas las
relaciones se consideran de
asociación, y la manera de trasladar
esto a las tablas depende de la
cardinalidad de la relación. La
relación se convierte en una tabla que
contiene referencias a las tablas de
las entidades relacionadas, así como
los atributos de la relación (cale para
cualquier cardinalidad, incluso N:N).
Si es 1:N es posible incluir los datos
de la relación en la tabla con
cardinalidad 1. Si la cardinalidad es
1:1 se pueden fundir las tablas de las
dos entidades.
- | | 1

|| +2 |
ë Las relaciones de COMPOS|C| N
se tratan como las de asociación, y
en ellas la cardinalidad del objeto
compuesto suele ser 1, por lo que
se puede aplicar la simplificación.
ë Cuando una clase tiene carias
subclases hay 3 formas de
amacenar las entidades ne tablas:
(a) Una tabla para la superclase con
los atributos comunes y una tabla
para cada subclase
(b) Desaparece la tabla de la
superclase y los atributos comunes
heredados se repiten en las
subclases
(c) Se prescinde de las tablas de la
subclase y se amplia la tabla de la
superclase con todos los atributos
de las subclases, de forma que
estos valores serán opcionales
para los elementos

8

||| +

||| | 1
ë Nos vamos a referir a las últimas fases del ciclo de vida: codificación,
pruebas de unidades, integración y pruebas de sistema.
ë Cuando alguna de las pruebas no resulta positiva es necesario repetir
la codificación o la integración y probar de nuevo.
ë La fase de codificación constituye el núcleo central en cualquiera de los
modelos y tiene una importancia fundamental ya que elabora los
programas fuente.
ë Previamente a la codificación es necesario elegir el lenguaje que se
empleará así como la metodología de programación. También se
pueden establecer en el equipo unas normas y un estilo de
programación común, lo que mejorará la coordinación y facilitará el
trabajo. Además se consigue facilitar el mantenimiento y mejorar la
reusabilidad del software.
ë Cuando el resultado de las pruebas no sea satisfactorio será necesario
modificar el código, lo que podrá introducir nuevos errores. Si la
programación es estructurada será más fácil localizar la disfunción y la
posterior modificación y las pruebas del código, dónde podemos
introducir puntos de test.

.
|
ë Aunque los lenguajes han evolucionado mucho desde los años 50 todavía están más próximos a la máquina que al pensamiento humano.
Los lenguajes suelen adoptar los avances metodológicos que se producen en el desarrollo del software. Ej.: C y C++
ë DESARROLLO H|ST R|CO, muchos han sido desarrollados con fines experimentales y muy pocos han llegado a ser utilizados
industrialmente:
£ 1ª GENERAC| N: muy próximos al lenguaje máquina
Î Ensamblador, asocia a cada instrucción de la máquina un nemónico
£ 2ª GENERAC| N: no dependen de la CPU, se programa de manera simbólica, en ³alto nivel´.
Î FORTRAN (FORula TRANslator), para aplicaciones científicas
Î COBOL, para procesamiento de información. Supone el 70 %
Î ALGOL, da gran importancia a la tipificación de datos
Î BAS|C, sencillo y fácil de aprender. Desarrollado para el PC.
£ 3ª GENERAC| N: programación estructurada con declaración de tipos. Los últimos van asociados a otros paradigmas.
Î PASCAL, fue diseñado para la enseñanza de la programación estructurada. Tipificación rígida y no contempla la codificación
por separado
Î M DULA-2, descendiente de pascal, se incorpora la estructura de módulo. Se mejora modularidad, concurrencia, abstracción
y ocultación
Î C, desarrollado para la codificación del UN|X. Flexible y potente. No hay restricciones sobre las operaciones con distintos
tipos.
Î ADA, descendiente de pscal, mucho más potente y complejo. |ncorpora modularidad, abstracción, ocultación, concurrencia y
sincronización entre tareas.
Î SMALLTALK, precursos de los lenguajes orientados a objetos
Î C++, incorpora en C los mecanismos de la POO: ocultación, clases, herencia y polimorfismo.
Î E|FFEL, permite la definición de clases genéricas, herencia múltiple y polimorfismo.
Î L|SP, lenguaje funcional usado en |A y sistemas expertos. Basado en listas admite recursividad. Maneja bien los símbolos
Î PROLOG, lenguaje lógico en que se construye una base de conocimiento basada en reglas a partir de la cual podemos inferir
nuevos hechos o reglas.
£ 4ª GENERAC| N: mayor grado de abstracción. Se agrupan en:
Î BASES DE DATOS; como SQL permiten acceder y manipular la información.
Î GENERADORES DE PROGRAMAS, son eficientes en un dominio de aplicaciones limitado. La mayoría producen
aplicaciones de gestión y la salida va en cobol, aunque se han desarrollado herramientas CASE que generan programas en
C++ o ADA.
Î CÁLCULO, hojas de cálculo, herramientas de simulación y diseño para el control, etc.
Î OTROS: herramientas para la especificación y verificación formal de programas, lenguajes de simulación, de prototipos, etc.
|

.

se incluyen aquí, además de las características propias de la programación estructurada, el
manejo de excepciones y la concurrencia.
£ Programación estructurada: secuencia, iteración y selección (verdadero-falso y por casos)
£ Manejo de excepciones: errores humanos, fallos hardware, errores software, datos de
entrada vacíos, valores fuera de rango, etc. (estructuras ! "# y ).
£ Concurrencia, tareas simultáneas, sincronización, comunicación e interbloqueos. Los
lenguajes han implementado la posibilidad de lanzar tareas concurrentes de distintas formas:
Î CORRUT|NAS, tienen una estructura semejante a subprogramas pero con una transferencia del
control más flexible. El avance en la ejecución de las corrutinas se produce según el avance entre
ellas.
Î FORK-JO|N, es la propuesta de UN|X.
Î COBEG|N-COEND, entre estas palabras se inician todas las tareas y se finalizan. Es posible el
anidamiento.
Î PROCESOS; cada tarea se declara como un proceso y estos y se ejecutan concurrentemente. En
algunos casos es posible lanzar dinámicamente nuevos procesos una vez iniciado el programa.
Î PARA LA COMUN|CAC| N ENTRE TAREAS.
VAR|ABLES COMPART|DAS
± SEMÁFOROS
± REG|ONES CRÍT|CAS
± MON|TORES
PASO DE MENSAJES
± CSP
± LLAMADA A PROCED|M|ENTOS REMOTOS
± REDENVOUS, DE ADA

|

.

£ DATOS S|MPLES. Para los eneros hay que tener en cuenta el rango posible y para los de coma flotante la
precisión. En ocasiones también permiten el manejo de complejos.
Î Otros tipos simples son char y string, para el manejo de cadenas. Los tipos enumerados también pueden
resultar útiles, un tipo enumerado muy frecuente son los booleanos.
Î En ocasiones los lenguajes permiten utilizar subrangos.
£ DATOS COMPUESTOS, son combinaciones de datos simples y compuestos ya definidos. Pueden ser
homogéneos como los ARRAYS y heterogéneos como los RECORDS o STRUCTS.
Î Para el manejo de estructuras dinámicas de datos muchos lenguajes incluyen punteros
£ CONSTANTES, en los lenguajes modernos se pueden declarar constantes simbólicas, sin indicar
directamente su valor numérico.
£ COMPROBAC| N DE T|POS, se pueden distinguir 5 niveles:
Î Nivel 0: sin tipos, no es posible declarar nuevos tipos y todos los datos deben pertenecer a tipos predefinidos
Î Nivel 1: tipado automático, el compilador decide cuál es el tipo más adecuado para cada dato.
Î Nivel 2: tipado débil, el compilador hace inferencias sobre los tipos y solo son posibles determinadas
conversiones
Î Nivel 3: tipado semirígido, todos los datos deben ser declarados con su tipo
Î Nivel 4: tipado fuerte, aquí además de declarar los tipos, el programador está obligado a hacer explícita cualquier
conversión de tipos.
£ ABSTRACC|ONES Y OBJETOS.
Î ABSTRACC|ONES FUNC|ONALES
Î T|POS ABSTRACTOS DE DATOS
Î OBJETOS
£ MOODULAR|DAD. Se requiere la compilación por separado. Además se introducen de forma redundante la
declaración y la definición de cada módulo, para permitir al compilador hacer comprobaciones acerca de la
consistencia. C y modula-2 lo tienen, pero pascal es monolítico.

||
| .
ë El lenguaje es uno de los elementos más importantes de cualquier desarrollo y tiene una
influencia decisiva en la depuración y el mantenimiento dela aplicación. Criterios:
£ |MPOS|C| N DEL CL|ENTE, a veces para disminuir los costes de desarrollo y
mantenimiento que se producen cuando una empresa utiliza lenguajes diferentes.
£ T|PO DE APL|CAC| N, hay lenguajes orientados a un campo de aplicación concreto.
Î Aplicaciones tiempo real críticas -> ensamblador
Î Gestión -> cobol
Î Área científico-técnica -> Fortran, Pascal, C
Î |nteligencia artificial -> Lisp, Prolog
Î Orientado a objeots ->> Eifel, C++
£ D|SPON|B|L|DAD Y ENTORNO, hay que comprobar los compiladores existentes para
la plataforma elegida. Estudio comparativo de eficiencia con un programa de prueba.
Herramientas del entorno de desarrollo: editor, montador, depurador, control versiones,
manejo de librerías, etc.
£ EXPER|ENC|A PREV|A, aprovechar la experiencia aumenta el rendimiento y disminuye
las posibilidades de error. La formación supone una fuerte inversión.
£ RESUAB|L|DAD, organización de librerías que faciliten la búsqueda y almacenamiento
de módulos reutilizables.
£ TRANSPORTAB|L|DAD, depende del lenguaje
£ USO DE VAR|OS LENGUAJES, no es aconsejable a no ser que las distintas partes
sean más fáciles de desarrollar en lenguajes concretos. Hay que tener en cuenta la
compatibilidad de los compiladores

|

ë Estos aspectos pueden mejorar la codificación bajo determinados puntos de vista: claridad, manejo de errores eficiencia y
transportabilidad.
ë Normas y estilo, para conseguir un trabajo del equipo homogéneo. Ejemplos:
£ Formato y contenido del as cabeceras de cada módulo
£ Formato y contenido para los comentarios
£ Uso del indentado
£ Elección de nombre y uso de mayúsculas
£ Restricciones sobre el tamaño del os módulos, evitar anidamiento excesivo, no usar goto, etc.
ë Manejo de errores. Las causas de los errores pueden estar en el hardware o en el software, incluso de pueden producir
por la introducción de datos incorrectos.
Î DEFECTO, incorrección en el software. Pueden permanecer ocultos hasta que no se ejecutan determinadas
partes del programa
Î FALLO, elemnto del programa que no funciona correctamente, produciendo un resultado erróneo
Î ERROR, estado no válido de un programa al que se llega como consecuencia de un fallo.
£ Al codificar podemos adoptar distintas actitudes ante los errores:
Î NO CONS|DERAR LOS ERRORES, no es realista esta postura
Î PREVENC| N DE ERRORES, consiste en detectar los fallos antes de que provoquen un error. Hay que
evitar la propagación de errores y tener siempre a la salida un resultado correcto o una señal de fallo.
Î RECUPERAC| N DE ERRORES, Cuando no es posible depurar todos los fallos es necesario hacer un
tratamiento de errores para devolver al programa a un estado válido y evitar que el error se propague
1. Detección del error
2. Recuperación del error. Se pueden usar dos esquemas en general:
1. RECUPERAC| N HAC|A DELANTE, hay que programas un mecanismo de excepciones para
que cuando se detecte el error se corrija el estado y se continúe correctamente la ejecución.
2. RECUPERAC| N HAC|A ATRÁS, corrige el estado no válido restaurando el programa a un
estado correcto anterior,
Una transacción es una operación que puede terminar con éxito o con fallo, en cuyo caso se
aborta y se restaura el estado de antes de comenzar dicha transacción.
|NGEN|ERÍA DEL SOFTWARE Javier Martín èo

|
|| |+

||
ë La potencia de cálculo y la cantidad de memoria disponible en los computadores actuales
hacer preferible la claridad en el código que la EF|C|ENC|A.
£ EF|C|ENC|A EN MEMOR|A, en la fase de diseño se estudian las posibles alternativas y
se opta por el algoritmo que optimiza el uso dela memoria.
£ EF|C|ENC|A DE T|EMPO, es importante en el desarrollo de sistemas de tiempo real
muy críticos. A veces se mejora la eficiencia de tiempo a costa de ocupar más memoria.
En el diseño se estudian las alternativas y se adopta el algoritmo más rápido. Técnicas
de codificación para aumentar la eficiencia de tiempo:
Î Tabular cálculo complejos
Î Expansión en línea, emplear macros en vez de subrutinas
Î Simplificar las expresiones aritméticas y lógicas
Î Sacar fuera de los bucles lo que no sea necesario repetir
Î Usar estructuras de datos de acceso rápido
Î Evitar operaciones en coma flotante, mejor en coma fija
Î Evitar conversiones innecesarias de tipos
ë TRANSPORTAB|L|DAD DEL SOFTWARE, no solo es rentable a corto plazo para obtener
versiones para diferentes plataformas, a medio y largo plazo facilita el mantenimiento y la
adaptación de la aplicación a las nuevas arquitecturas.
£ Los factores para la transportabilidad son:
Î Utilización de estándares
Î Aislar las peculiaridades, colocándolas en módulos separados. Se procurará evitar aquellos
elementos no consolidados y que pueden estar sujetos a futuros cambios o revisiones.
£ Las peculiaridades de los distintos tipos de computadores depende de la arquitectura y del
sistema operativo utilizado.
|NGEN|ERÍA DEL SOFTWARE Javier Martín èð
- |
ë Para garantizar su calidad es necesario someter al programa a diversas
pruebas para garantizar su funcionamiento correcto.
ë Se deben hacer pruebas a cada módulo, según avanza la codificación del
proyecto. Finalmente se harán las pruebas de integración entre módulos y
las pruebas de sistema
ë OBJET|VOS, el principal objetivo es conseguir que el programa funcione
incorrectamente para ir depurando los errores y que se descubran los
efectos. Para elaborar los casos de prueba:
£Una buena prueba encuentra los errores y no los encubre
£Para determinar si hubo error es necesario conocer el
resultado correcto
£Deben participar codificador y diseñador
£Al corregir un error se pueden introducir otros nuevos
£No es posible demostrar la ausencia de defectos mediante
pruebas
£No son posibles las pruebas exhaustivas. Con el menor
esfuerzo posible hay que detectar el máximo nº de defectos,
en especial los más graves.
£Las pruebas se realizan en un entorno de ejecución
controlado, para asegurar la estabilidad en los pruebas y
automatizar en lo posible este proceso.
|NGEN|ERÍA DEL SOFTWARE Javier Martín è·

- | | .
ë Las técnicas de pruebas de unidades siguen dos estrategias fundamentales:
£ PRUEBAS DE CAJA NEGRA, se ignora por completo la estructura interna del programa y se
comprueba la corrección de entradas y salidas del programa.
£ Lo importante es la elaboración de los casos de prueba con el objetivo de descubrir los errores e
incorrecciones. Métodos:
5/$)):!$aaàI )H$!)$

( %
% (
% (
%
(
7+ 1
3
5à
(
% %
5
% % (

( 1
( 7a %
% 0

(
7
5$!)a)aàH$!"a!#&)
% %
7
à
% % 3
5
% (
1

5a % (

1

5& %
4
% 1%

%
5 %
7a
K2G% G9G128
5"
% (
1
%
5"&/$$):àHa)"a ( (
% (
% 1 %

7
5&/!"à!$) )):
1 6% % %
C (
%
% 6%
7
|NGEN|ERÍA DEL SOFTWARE Javier Martín èX
- | | .
ë Se tiene en cuenta la estructura interna del módulo. Los
casos de prueba deben conseguir que:
£ Todas las decisiones se ejecuten en uno y otro sentido
£ Todos los bucles se ejecuten en los supuestos más
diversos posibles
£ Todas las estructuras de datos se modifiquen y
consulten alguna vez
ë La complejidad de los módulos dificulta realizar exhaustivas
pruebas de caja transparente. Conviene que participen
expertos con un conocimiento amplio de las estructura del
programa. Métodos:
')&)"!:)"
/ '$aà' !a

% 7a % 7 3
%

%

7 5' L
%
% G89

10
7
+ 1

% 5' L6 %
% G89
( 7

&N8&1&M8

L6 KL% M8 5' L % % %

7
( %

% &/!"à!$) )):

%

1
6% 7
$
( % %

L
(
- | | .
à 21 =% %
|NGEN|ERÍA DEL SOFTWARE Javier Martín èU

||

ë Resulta imposible demostrar que un módulo carece de
defectos, pero podemos hacer una estimación estadísitca
de erratas que permanecen sin detectar:
£ Anotar el nº de errores que se producen inicialmente al pasar
los casos de prueba.
£ Corregir el módulo hasta que sdesaparezcan todos esos
errores
£ |ntroducir en el módulo, de forma aleatoria un nº razonable de
errores
£ Someter al módulo nuevamente a los casos de prueba y ver
el nº de errores que se detectan
£ De esta forma podemos estimar el nº de errores que han
permanecido sin ser detectados en el programa
ë En función de los resultados se valorará la necesidad de
preparar nuevos casos de prueba.
|NGEN|ERÍA DEL SOFTWARE Javier Martín èÑ

| | |
ë Se integran los módulos del sistema para conformar el sistema completo. Causas de error:
£ Desacuerdos en el interfaz entre módulos
£ |nteracción indebida entre módulos
£ |mprecisiones acumuladas
ë Estrategias básicas para la integración:
£ |NTEGRAC| N B|G BANG, en un único paso se integran todos los módulos, de forma que todos
los defectos se manifiestan a la vez. Solo recomendable para sistemas pequeños.
£ |NTEGRAC| N DESCENDENTE, se parte de un módulo principal P, que se prueba con
³módulos de andamiaje´, los cuales van siendo sustituidos por los verdaderos de forma
progresiva por niveles. Los módulos de andamiaje;
Î No hacen nada y solo sirven para comprobar el interfaz
Î |mprimen un mensaje de seguimiento, con información de la llamada
Î Suministran un resultado fijo
Î Suministran un resultado aleatorio
Î Suministran un resultado tabulado u obtenido con un algoritmo simplificado
£ El trabajo de elaborar estos módulos puede ser aprovechado para hacer un prototipo y mostrar al
cliente un avance del programa. |nconvenientes:
Î |mpide el trabajo en paralelo en las pruebas
Î Es difícil buscar los casos de pruebas especiales o dirigidas a los últimos módulos integrados
£ |NTEGRAC| N ASCENDENTE, se codifican por separado y en paralelo todos los módulos del
nivel más bajo. Para probarlos se codifican módulos gestores o conductores que los hacen
funcionar independientemente o en combinaciones sencillas. Las ventajas son:
Î Facilita el trabajo en paralelo
Î Facilita el ensayo de situaciones especiales
£ La |ntegración Sandwich consiste en realizar integración ascendente con los módulos de nivel
más bajo y descendente con los de nivel más alto.
| | +
|NGEN|ERÍA DEL SOFTWARE Javier Martín èè

|
ë Se trata de probar el sistema completo para ver si realmente cumple las
especificaciones.
ë Se suelen emplear estrategias de caja negra. Podemos distinguir diferentes
clases de pruebas:
£ PRUEBAS DE RECUPERAC| N, para comprobar la capacidad del sistema
para recuperarse ante fallos
£ PRUEBAS DE SEGUR|DAD, par comprobar los mecanismos de protección
ante un acceso no autorizado
£ PRUEBAS DE RES|STENC|A, para comprobar el comportamiento del
sistema ante situaciones excepcionales
£ PRUEBAS DE SENS|B|L|DAD, para comprobar el tratamiento que da el
sistema a ciertas singularidades relacionadas casi siempre con los
algoritmos matemáticos utilizados
£ PRUEBAS DE REND|M|ENTO, para comprobar las prestaciones del
sistema que son críticas en tiempo
ë PRUEBAS ALFA Y BETA. Los usuarios también deben intervenir en las
pruebas finales del sistema
£ Pruebas alfa, son las primeras pruebas que se realizan en un entorno
controlado donde el usuario tiene el apoyo de alguien del equipo de desarrollo
£ Pruebas beta, los usuarios trabajan con el sistema en un entorno real y sin
ayuda, anotando los problemas que se le presentan
9

|:|

|NGEN|ERÍA DEL SOFTWARE Javier Martín o o

ë Entorno se refiere al contexto dentro del cual se desarrolla una determinada
actividad, o también a la combinación de instrumentos utilizados.
ë El entorno de desarrollo software, SEE, cuenta con una serie de técnicas de
automatización denominadas CASE.
ë Las primeras herramientas se referían a la fase de codificación, así el entorno
de programación clásico consiste en un compilador con editor, montador de
enlaces, etc. Posteriormente con el empleo del término CASE se ha extendido
la automatización a las fases de análisis y diseño.
ë Para las pruebas de integración se puede disponer de herramientas de ensayo
y para la fase de mantenimiento se dispone de soporte de gestión de
configuración, que incluye la gestión de versiones y el control de cambios.
ë El futuro de las técnicas CASE está en el soporte completo de todo el ciclo de
vida. Se ha denominado |PSE, |CASE e |SEE.
ë FORMAS DE ORGAN|AC| N:
£ En cadena, se combinan una serie de herramientas de manera que la
salida de cada una es la entrada de la siguiente. Ej.: editor-compilador-
montador
£ Con repositorio, las herramientas integradas guardan su información en
este almacén común. Una parte del repositorio es el diccionario de datos
£ Como una única herramienta global, capaz de realizar todas las
operaciones necesarias.
|NGEN|ERÍA DEL SOFTWARE Javier Martín o ð

.|'
+ |||

ë Dar soporte a la programación en un lenguaje concreto

ë Dar soporte a una metodología de desarrollo
ë Ayudar al desarrollo de entornos de desarrollo (meta-entornos)
ë CLAS|F|CAC| N, desde un punto de vista pragmático:
£ ENTORNOS ASOC|ADOS A UN LENGUAJE. % %

1

C%
%

( ,'$a)!)a/a O -7
£ ENTORNOS ASOC|ADOS A ESTRUCTURA.
%
%

1 %

6
7!
%

%

% %

7
%

,/! -7
£ ENTORNOS BASADOS EN HERRAM|ENTAS.

0
,
O

6-
(
%
%

6
B % 0 7a
%
(

%
% (
0
7a (

( 1 7
£ ENTORNOS ASOC|ADOS A UNA METODOLOGÍA. !

% CB
%
$a%

%

%
7 %

%
1 % 7
£ ENTORNOS DE 4ª GENERAC| N. a % 1

0
%
7
|NGEN|ERÍA DEL SOFTWARE Javier Martín o ·

|||

|'
ë Y u % %

%
( (
% , % -7
ë Y
`7/

%
(

( % %

( ( 7
,

6
-7
ë Y
%
%
$a

%
%

(
%
% 7

( 0

7

(

% 7
ë ? u /
$a %
% %

,)/a )$a-7
! % ( ( 7
|NGEN|ERÍA DEL SOFTWARE Javier Martín o X

2|

ù ` `
`
5? 7
5

5
7
1
( 0
7
5
7 0
7
5 ?P7$

0 %

7
5 7

1
% %
, (
1
0
-7 (
%
1 7
5
7/
%

( 7)1 %
1

C%
0

%
7 1
% 7
5
7
%
7
1 0 % 1

% 7
5
7
%
% 7
ù ` ` ``
5?

7a

7
5 ? 7a % Q&$RP % 7
5 7$ 1
(

7a

&$R % % 7
5!
" 7% %
0
%
6

%

S
7
%
% % 7
5! 7 % % %

7
5
7$1 %

7
5
7$1 1

% 7
5! # 7
ù ` ` `
+ 7/

! =T 7
% 7

|

| ` ` a

%

0
7à 3
U)
%
(
0
7
U

U

7
U/
0

7
!

% ( 3
5T # 7
% % 6 7 % %
0
0

7
5T #u 76

,à)*-7
5T 7$

(
1%

1

7
5$ % u a

( 7
| `
6 % % %
% 1
(
0 1
7 1 0
% (
0
76
% % (

7
| ` ` `

%
0
7/
(
3
[ !
B

7
[
1%

7
[ a

% %
% 1 ( %

7
[ &
B
% 7
| `
0
% 1

7
6

1
7 % %

7
5 %

%
,% % ( ààà-7
5 (

% 1 %
, % -7
5

% 7

% 6
% (
1

%
1

7
|NGEN|ERÍA DEL SOFTWARE Javier Martín o U

|

|
|

? ? ? C B

% % % 0

7 %

1 %

1

7$ %

( 1

7
/ % %
1 %
3
5 (
%

0
%
7
5 (
1
, 1- %
1 %

%
7
5 ( (
%

1 %

1

( 1
0 1

7
5 (

%
1 6%

0 6
7
|NGEN|ERÍA DEL SOFTWARE Javier Martín o Ñ

*|
.

0
% %

% %

( 7
3
[ )
%

[ )

[ )

,%

%
B-7
a B
( %

%

3
5% 1 4 3+
$a $a% 7 %

7 &0 , 1 4 -

7
%
B

%
7
5
% 7
%
( %C 6

4
1 % 7
5% ( 1( 3 %

% 1% 1

7a

% 7/ 3
U$

( C
1

1 7
U
7
U
%

1 7
5%

7/

7
5%
7/

(
% 1

1
( 7
5% ( 7à
6
4

%

6

7
5%
% 1
7*
%

% 1

1
7

|

à % %

( ( 7

)/a)$a )a7!

%%

% %
6%
7

%

%

1
%
7
/
(

% 7$

% 1 4

% %

7 )a %
3
5
% 7
5$ % %
7
$ 6

)a% 6

% 0 0

7
$ 3
U/,/
(
-7

%

B7a
%%
%
7a C% % 0

( % (
% 76
%
%

% % /1
C 0
% 1
/$7
Ua*, O a
*
1-7à

1

Q
P
%
6 0
7a

0
3 ( 1 0

7! ( %
%

1
(

7! 0

%
% %
1 (
(C
7
U& )a &$7
%

%
%
% %

%
B
%

%

% 1 7
% %
%

0
7
$
%
$a
%
%
%

7
|NGEN|ERÍA DEL SOFTWARE Javier Martín o è

Temas IS

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Temas IS

Cargado por

Copyright:

Formatos disponibles

| |

|NGEN|ERÍA DEL SOFTWARE Javier Martín ð

|NGEN|ERÍA DEL SOFTWARE Javier Martín ·

|NGEN|ERÍA DEL SOFTWARE Javier Martín X

|NGEN|ERÍA DEL SOFTWARE Javier Martín 

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ

|NGEN|ERÍA DEL SOFTWARE Javier Martín 

ë Prácticamente identifican actividades similares y sólo se

|NGEN|ERÍA DEL SOFTWARE Javier Martín è

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín oð

|NGEN|ERÍA DEL SOFTWARE Javier Martín oX

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín oU

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín oè

|NGEN|ERÍA DEL SOFTWARE Javier Martín ðo

|NGEN|ERÍA DEL SOFTWARE Javier Martín ð·

|NGEN|ERÍA DEL SOFTWARE Javier Martín ðX

|NGEN|ERÍA DEL SOFTWARE Javier Martín ðÑ

|NGEN|ERÍA DEL SOFTWARE Javier Martín ðè

|NGEN|ERÍA DEL SOFTWARE Javier Martín ·o

|NGEN|ERÍA DEL SOFTWARE Javier Martín ·ð

|NGEN|ERÍA DEL SOFTWARE Javier Martín ··

ë Un modelo conceptual es una abstracción lógico-

|NGEN|ERÍA DEL SOFTWARE Javier Martín ·X

|NGEN|ERÍA DEL SOFTWARE Javier Martín ·Ñ

|NGEN|ERÍA DEL SOFTWARE Javier Martín X

|NGEN|ERÍA DEL SOFTWARE Javier Martín Xo

|NGEN|ERÍA DEL SOFTWARE Javier Martín Xð

|NGEN|ERÍA DEL SOFTWARE Javier Martín X·

|NGEN|ERÍA DEL SOFTWARE Javier Martín XX

|NGEN|ERÍA DEL SOFTWARE Javier Martín XU

|NGEN|ERÍA DEL SOFTWARE Javier Martín XÑ

|NGEN|ERÍA DEL SOFTWARE Javier Martín X

|NGEN|ERÍA DEL SOFTWARE Javier Martín Xè

|NGEN|ERÍA DEL SOFTWARE Javier Martín 

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín ð

ë Descripción o bosquejo de alguna cosa hecho por

ë D|SEÑO ARQU|TECT N|CO, se abordan los aspectos

operaciones o servicios que ofrecerá cada módulo. Se

sistema. Se parte de los diagramas E-R.

facilitar la utilización del sistema por parte del usuario

|NGEN|ERÍA DEL SOFTWARE Javier Martín 

ë Debe resultar precisa, clara y fácil de interpretar.

|NGEN|ERÍA DEL SOFTWARE Javier Martín U

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ

|NGEN|ERÍA DEL SOFTWARE Javier Martín 

|NGEN|ERÍA DEL SOFTWARE Javier Martín è

|NGEN|ERÍA DEL SOFTWARE Javier Martín U

|NGEN|ERÍA DEL SOFTWARE Javier Martín Uo

|NGEN|ERÍA DEL SOFTWARE Javier Martín Uð

|NGEN|ERÍA DEL SOFTWARE Javier Martín U·

£ @772*   0   %  

£ @77E     0 

|NGEN|ERÍA DEL SOFTWARE Javier Martín UX

|NGEN|ERÍA DEL SOFTWARE Javier Martín UU

ë Los objetivos de las técnicas de diseño software son

|NGEN|ERÍA DEL SOFTWARE Javier Martín UÑ

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ño

ë Esta técnica consiste en la aplicación de la fase de diseño de la programación

| |

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín X

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín ð

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín U

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín è

£ @772* 0 %

£ @77E 0

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ

|NGEN|ERÍA DEL SOFTWARE Javier Martín Ñ

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín ð

|NGEN|ERÍA DEL SOFTWARE Javier Martín X

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín U

|NGEN|ERÍA DEL SOFTWARE Javier Martín

|NGEN|ERÍA DEL SOFTWARE Javier Martín è

5a % (

|NGEN|ERÍA DEL SOFTWARE Javier Martín o

|NGEN|ERÍA DEL SOFTWARE Javier Martín o