ESCUELA DE INGENIERA EN COMPUTACIN TCNICO EN ING.

DE SISTEMAS INFORMTICOS

MDULO SELECCIN DE TCNICAS DE INGENIERA DE SOFTWARE

ELABORADO POR: LICDA. MARA ELENA DE LOBOS

NOMBRE DEL ALUMNO: __________________________________ PERODO: ___________ AO ________

SANTA TECLA, ENERO 2012

INDICE

Introduccin Objetivo General del Mdulo Objetivos del rea de Competencias Subcompetencias Duracin del Mdulo Esquema General del Mdulo Autoevaluacin Inicial Evaluacin Final Unidad Didctica I: Mtodos convencionales para la ingeniera del software Introduccin a la Unidad Resultados de Aprendizaje Secuencia de aprendizaje de la Unidad I Contenidos de la unidad 1. Ingeniera de Sistemas 1.1 Ingeniera de sistemas, productos y requisitos 1.2 Modelado del sistema 2. Modelado del anlisis 2.1 Identificacin, anlisis y especificacin de requisitos para el desarrollo SW 2.2 Principios de anlisis y prototipos 2.3 Modelado de datos, de flujo de informacin y comportamiento 2.4 Mecanismos del anlisis estructurado y diccionario de datos 3. Diseo Arquitectnico 3.1 Concepto, proceso, principios y modelos del diseo de software 3.2 Diseo Modular 3.3 Arquitectura del SW y diseo de datos transaccionales y transformaciones 3.4 Diseo de la interfaz del usuario con sus reglas, actividades y anlisis 3.5 Programacin estructurada 3.6 Comparacin de notaciones del diseo 4. Mtricas tcnicas del software

1 2 2 2 2 3 4 5 6 6 6 7 8 9 9 18 21 21 22 24 29 36 36 40 41 46 48 49 51

4.1 Factores de calidad del software 4.2 Mtricas para cada fase del ciclo de vida del desarrollo de sistemas Unidad Didctica II: Ingeniera de software orientada a objetos Introduccin a la Unidad Resultados de Aprendizaje Secuencia de aprendizaje para la unidad II Contenidos de la unidad 1. Anlisis Orientado a Objetos 1.1 Conceptos y principios orientados a objetos 1.2 El anlisis orientado a objetos 1.3 El modelo y el proceso del anlisis orientado a objetos 2. Diseo Orientado a Objetos 2.1 Modelos, Procesos y patrones del diseo orientado a objetos 2.2 Programacin orientada a objetos 2.3 Diseo en el nivel de componentes 3. Tcnicas y estrategias de Pruebas del software 3.1 Fundamentos y tipos de Pruebas realizadas al software 3.2 Estrategias de prueba para software 3.3 Visiones interna y externa de las pruebas Evaluacin Final

52 59 67 67 67 68 69 70 70 71 73 77 78 93 95 100 100 101 102 112

SELECCIN DE TCNICAS DE INGENIERA DE SOFTWARE

INTRODUCCIN
La Ingeniera de Software es una disciplina o rea de la informtica o ciencias de la computacin, que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Hoy en da es cada vez ms frecuente la consideracin de la ingeniera de software como una nueva era de la Ingeniera, y el Ingeniero de Software comienza a ser un profesional inmerso en el mundo laboral internacional, con derechos, deberes y responsabilidades que cumplir, junto a una ya reconocida consideracin social en el mundo empresarial y para esas personas con un brillante futuro. La Ingeniera de Software trata con reas muy diversas de la informtica y de las ciencias de la computacin, tales como construccin de compiladores, sistemas operativos o desarrollos en Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de informacin y aplicables a una infinidad de reas tales como: negocios, investigacin cientfica, medicina, produccin, logstica, banca, control de trfico, meteorologa, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc. Podramos decir entonces, que Ingeniera de Software es (segn la define la IEEE): La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de la ingeniera en el rea del software La ingeniera de software es un campo ms amplio que solamente desarrollar software, pues desarrollar software sin conocer de tcnicas de ingeniera no es una garanta de que se obtendrn las soluciones ms apropiadas y con el desempeo deseado. El presente manual ha sido diseado para constituirse en una gua que permita la utilizacin de tcnicas relacionadas con la formacin por competencias para lograr que el estudiante experimente la veracidad de la teora expuesta en cada tema de la ingeniera de software. El desarrollo del mdulo est dividido en dos grandes temas que son: 1. Mtodos convencionales para la ingeniera de software 2. Ingeniera del software orientada a objetos En estos dos apartados del conocimiento de ingeniera de software, aprenderemos la parte medular de cada uno partiendo de su aplicabilidad a nuestro mercado de desarrollo de software y las bases que, como futuros ingenieros de software, debemos poseer en forma competitiva.

OBJETIVO GENERAL DEL MDULO:

Al finalizar este mdulo, usted habr adquirido las competencias para aplicar las tcnicas de ingeniera de software que permitan obtener software econmico que sea fiable y funcione de manera eficiente sobre mquinas reales.

REA DE COMPETENCIAS:
Seleccionar tcnicas de ingeniera de software

SUBCOMPETENCIAS:
Conocer las tcnicas para el diseo de interfaces y componentes del software Dominar el concepto y principios del anlisis de sistemas Aplicar el modelado en la fase del anlisis del sistema Dominar el concepto y principios del diseo de sistemas Conocer las tcnicas de ingeniera asistida por computadora Dominar la tcnica para crear la arquitectura del software Aplicar diferentes modelos de anlisis para el proceso de desarrollo de software Dominar las tcnicas y estrategias para las pruebas del software Aplicar las mtricas tcnicas del software orientado a objetos Conocer el ciclo de desarrollo de sistemas orientados a objetos

DURACIN DEL MDULO: HORAS TERICAS: 30

100 HORAS.

HORAS PRCTICAS: 70

ESQUEMA GENERAL DEL MDULO

MDULO: SELECCIN DE TCNICAS DE INGENIERA DE SOFTWARE

UNIDAD 1: MTODOS CONVENCIONALES PARA LA INGENIERA DE SOFTWARE

TEMA 1: INGENIERA DE SISTEMAS

TEMA 2: MODELADO DEL ANLISIS

TEMA 3: DISEO ARQUITECTNICO

TEMA 4: MTRICAS TCNICAS DEL SOFTWARE

UNIDAD 2: INGENIERIA DEL SOFTWARE ORIENTADA A OBJETOS

TEMA 1: ANLISIS ORIENTADO A OBJETOS

TEMA 2: DISEO ORIENTADO A OBJETOS

TEMA 3: TCNICAS Y ESTRATEGIAS DE PRUEBAS DEL SOFTWARE

AUTOEVALUACIN INICIAL

En su rol de protagonista del proceso de aprendizaje, le proponemos completar el siguiente cuestionario previo al estudio del mdulo, con el objeto de que usted defina cules son sus conocimientos iniciales de los temas que se van a estudiar y, que evale su aprendizaje en el transcurso del desarrollo del mdulo. Finalmente puede comparar ambos procesos para que identifique los aprendizajes alcanzados al terminar el mdulo. Para tal propsito, complete el cuestionario utilizando la siguiente escala: 1. 2. 3. 4. No conozco ni s hacerlo (Nunca he ledo sobre este tema ni trabajado en l) He escuchado pero no he trabajado en ello. Tengo poco conocimiento del tema. Conozco y s hacerlo.

Coloque un cheque en la escala seleccionada.

Contenidos Explicar el uso de mtodos convencionales para la Ingeniera de Software Diseo Arquitectnico Aplicar Mtricas tcnicas del Software Significado de mtodos formales Aplicar tcnicas y estrategias de prueba del software Aplicar patrones de diseo Ingeniera de Software Basada en Componentes Elaborar diagramas de estado y despliegue Aplicar modelado de datos

EVALUACIN FINAL

SISTEMA DE EVALUACIN. Socializacin: Controles de lectura 100%

Porcentaje de socializacin 30% Prctica: Evaluacin de los temas 45% (3 exmenes prcticos 15% c/u) Ejercicios prcticos 25% Tarea significativa 30% 70%

Porcentaje de Prctica

TAREA SIGNIFICATIVA: La evaluacin final del mdulo consiste en la elaboracin de un documento que contiene el anlisis y diseo de un sistema de informacin: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Portada ndice Introduccin Objetivos (General y especficos) Planteamiento del problema Algoritmo general del sistema Descripcin de procesos (Diagramas de clases, objetos, componentes, secuencia, estados y Esquemas de men y Diseo de la interfaz del usuario Mtricas tcnicas del software Patrones de diseo Pruebas del software Bibliografa utilizada Anexos (si los hay)

despliegue)

Sugerencias para la presentacin del documento: Revise su ortografa y redaccin Incluya en forma completa, la bibliografa y sitios web consultados. Documento en formato de Word tamao carta, con mrgenes de 2.5 a cada lado. Tipo de letra verdana tamao 11 para textos y los ttulos en tamao 12. Interlineado 1.5. Entrega puntual, en la fecha estipulada.

UNIDAD DIDCTICA I. METODOS CONVENCIONALES PARA LA INGENIERA DEL SOFTWARE

INTRODUCCIN.
La ingeniera de software es una disciplina diferente a las dems, pues busca integrar principios de matemticas y ciencias de la computacin con principios de la ingeniera que permiten desarrollar el software de una manera ms completa pues hay toma de decisiones, anlisis de costos y beneficios, anlisis y diseo apropiado de un problema, basado en experiencia y validaciones propias que requiere esta disciplina. Una de las principales diferencias de la ingeniera de sistemas respecto a otras disciplinas de ingeniera tradicionales, consiste en que la ingeniera de sistemas no construye productos tangibles. Mientras que los ingenieros civiles podran disear edificios o puentes, los ingenieros electrnicos podran disear circuitos, los ingenieros de sistemas tratan con sistemas abstractos con ayuda de las metodologas de la ciencia de sistemas, y confan adems en otras disciplinas para disear y entregar los productos tangibles que son la realizacin de esos sistemas.1 En la ingeniera de software, los ingenieros realizan muchas tareas como la investigacin, desarrollo, diseo, pruebas, administracin, consultora, capacitacin, uso de herramientas para aplicar los procesos de manera sistemtica diseo de artefactos y reutilizacin de cdigo.

RESULTADOS DE APRENDIZAJE:
Realizar el levantamiento de procesos de un sistema en particular a partir de un anlisis previo de la organizacin. Documentar los requerimientos del sistema en base a un estudio de requerimientos tcnicos, operativos y econmicos utilizando entrevistas, observacin y otros mtodos de investigacin. Modelar el anlisis del sistema segn la estructura del diseo lgico planteado. Disear el sistema a partir del modelado del anlisis creado.

Tomado de www.sistemasusfq.com/ingenieria-en-sistemas

SECUENCIA DE APRENDIZAJE PARA LA UNIDAD I:

UNIDAD 1: MTODOS CONVENCIONALES PARA LA INGENIERA DE SOFTWARE

TEMA 1: INGENIERA DE SISTEMAS 1.1 Ingeniera de sistemas, productos y requisitos 1.2 Modelado del sistema TEMA 2: MODELADO DEL ANLISIS 2.1 Identificacin, anlisis y especificacin de requisitos para el desarrollo SW 2.2 Principios de anlisis y prototipos 2.3 Modelado de datos, de flujo de informacin y comportamiento 2.4 Mecanismos del anlisis estructurado y diccionario de datos TEMA 3: DISEO ARQUITECTNICO 3.1 Proceso, concepto, principios y modelos del diseo de software 3.2 Diseo modular 3.3 Arquitectura del SW y diseo de datos transacciones y transformaciones

3.4 Diseo de la interfaz del usuario con sus reglas, actividades y anlisis

3.5 Programacin estructurada 3.6 Comparacin de notaciones del diseo

TEMA 4: METRICAS TECNICAS DEL SOFTWARE

4.1 Factores de calidad del software

4.2 Mtricas para cada fase del ciclo de vida del desarrollo de sistemas

CONTENIDOS DE LA UNIDAD:

1. INGENIERA DE SISTEMAS 1.1 Ingeniera de sistemas, productos y requisitos 1.2 Modelado del sistema 2. MODELADO DEL ANLISIS 2.1 Identificacin, anlisis y especificacin de requisitos para el desarrollo SW 2.2 Principios de anlisis y prototipos 2.3 Modelado funcional, de datos, de flujo de informacin y comportamiento 2.4 Mecanismos del anlisis estructurado y diccionario de datos 3. DISEO ARQUITECTNICO 3.1 Proceso, principios, concepto y modelos del diseo de software 3.2 Diseo modular 3.3 Arquitectura del SW y diseo de datos transacciones y transformaciones 3.4 Diseo de la interfaz del usuario con sus reglas, actividades y anlisis 3.5 Programacin estructurada 3.6 Comparacin de notaciones del diseo 4. MTRICAS TCNICAS DEL SOFTWARE 4.1 Factores de calidad del software 4.2 Mtricas para cada fase del ciclo de vida del desarrollo de sistemas

TEMA 1. INGENIERA DE SISTEMAS

1.1

INGENIERA DE SISTEMAS, PRODUCTOS Y REQUISITOS

La ingeniera de sistemas es la actividad de especificar, disear, implementar, validar, utilizar y mantener los sistemas socio-tcnicos (sistemas que incluyen hardware, software y personas).2 La ingeniera de sistemas consta de las siguientes fases:

Definicin de Requerimientos

Diseo del sistema

Desarrollo del subsistema

Integracin del sistema

Instalacin del sistema

Evolucin del sistema

Desmantelamiento del sistema

La ingeniera de sistemas es una actividad interdisciplinaria que conjunta equipos de personas con diferentes bases de conocimiento. Roger Pressman la define enfatizando aspectos concretos de calidad: "establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico que sea fiable y funcione de manera eficiente sobre mquinas reales" Entre sus caractersticas se incluye su estructura de arriba-abajo que ve el sistema como un todo; una orientacin del ciclo de vida que considera todas las fases desde el diseo conceptual hasta la retirada del sistema; un enfoque interdisciplinar en equipo que incluya todas las disciplinas adecuadas de diseo de forma oportuna y concurrente; y la necesaria integracin para asegurar que todos los objetivos de diseo se han cumplido de forma efectiva y eficaz. Est orientada al proceso e incluye las provisiones esenciales de realimentacin y control.3 La ingeniera de software surge como consecuencia de la ingeniera de sistemas. En vez de centrarse nicamente en el software, la ingeniera de sistemas se centra en diversos elementos, analizando, diseando y organizando esos elementos en un sistema que puede ser un producto, un servicio o una tecnologa para la transformacin de informacin o control de informacin. La Ingeniera de Software es la disciplina tecnolgica y administrativa dedicada a la produccin sistemtica de productos de programacin, que son desarrollados y modificados a tiempo y dentro de un presupuesto definido. Es una de las disciplinas de la Informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. De esta forma se abren varios campos de estudio entre ellos Ingeniera del software orientada a objetos y temas avanzados varios como son la reutilizacin de software, reingeniera, ingeniera multicanal, etc. EL PRODUCTO.4 El proceso de ingeniera de sistemas es denominado ingeniera de procesos de negocio cuando el contexto del trabajo de ingeniera se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniera de producto. Hoy en da, el software tiene un doble papel. Es un producto y, al mismo tiempo, es el vehculo para entregarlo.
2 3 4

Tomado de Ingeniera del Software. Ian Sommerville.7 edicin. Tomado de Ingeniera de sistemas de software. Gonzalo Len Serrano. Tomado de Ingeniera del Software. Roger Pressman. 5 Edicin.

Como producto, hace entrega de la potencia informtica que incorpora el hardware informtico o, ms ampliamente, una red de computadoras que es accesible por hardware local. Como vehculo utilizado para hacer entrega del producto, el software acta como la base de control de la computadora (sistemas operativos), la comunicacin de informacin (redes) y la creacin de control de otros programas (herramientas de software y entornos). La meta de la ingeniera de producto es traducir el deseo de un cliente, de un conjunto de capacidades definidas, a un producto operativo. Para conseguir esta meta, la ingeniera de producto (como la ingeniera de proceso de negocio) debe crear una arquitectura y una infraestructura. La arquitectura comprende cuatro componentes de sistema distintos: 1. Software, 2. Hardware, 3. Datos (bases de datos) y 4. Personas. La ingeniera de productos es un enfoque de la ingeniera de sistemas que empieza con el anlisis del sistema. El ingeniero de sistemas identifica las necesidades del cliente, determina la viabilidad econmica y tcnica, y asigna funciones y rendimientos al software, hardware, personas y bases de datos; los componentes claves de la ingeniera. INGENIERA DE REQUISITOS. Un requisito segn la IEEE es definido como una especificacin de qu se debera implementar. Una condicin o capacidad que debe cumplir o poseer un sistema o componente de un sistema para satisfacer un contrato, estndar, especificacin u otro documento formalmente impuesto. CARACTERSTICAS DE LAS BUENAS DESCRIPCIONES DE REQUISITOS.

En la ingeniera de sistemas y la ingeniera de software la Ingeniera de requisitos comprende todas las tareas relacionadas con la determinacin de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos. Muchas veces se habla de requerimientos en vez de requisitos, esto se debe a una mala traduccin del ingls. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al ingls como request. La ingeniera de requisitos es la parte de la ingeniera del software que aborda el problema de la definicin de los servicios que el sistema ha de proporcionar y de establecer las restricciones

10

operativas del mismo. Los casos de uso se han convertido en una de las tcnicas de modelado ms utilizadas para la determinacin y documentacin de los requisitos funcionales de un sistema software.5 La ingeniera de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solucin razonable, especificando la solucin sin ambigedad, validando la especificacin y gestionando los requisitos para que se transformen en un sistema operacional. La correcta obtencin de los requisitos es uno de los aspectos ms crticos de un proyecto software, independientemente del tipo de proyecto que se trate, dado que una mala captura de los mismos es la causa de la mayor parte de los problemas que surgen a lo largo del ciclo de vida. El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigedades o contradicciones, etc. DEFECTOS Los Defectos comunes en los requisitos y sus consecuencias:

Desde un punto de vista conceptual, las actividades son 5:

Tomado de http://ocw.usal.es/enseanzas-tecnicas/ingenieria-del-software/materiales-de-clase

11

Obtener requisitos
A travs de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus deseos.

Analizar requisitos
Detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseo.

Documentar requisitos
Igual que todas las etapas, los requisitos deben estar debidamente documentados.

Verificar los requisitos

Consiste en comprobar el correcto funcionamiento de un requisito en la aplicacin.

Validar los requisitos

Comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretenda.

Para otros, el proceso de ingeniera de requisitos puede ser descrito en 6pasos distintos:

Identificacin de requisitos

Anlisis de requisitos y negociacin

Especificacin de requisitos

Modelado del sistema

Validacin de requisitos

Gestin de requisitos

Ingeniera de Requisitos:

12

Desarrollo de Requisitos:
Proceso de extraer, analizar, especificar y verificar los requisitos. El proceso de desarrollo de requisitos vara radicalmente de una organizacin a otra dependiendo de su madurez, cultura de la organizacin, dominio de aplicacin, implicacin, etc. No existen procesos ideales de desarrollo de requisitos y gestin de los requisitos.

13

BUENAS PRCTICAS Captura

Definir un proceso de desarrollo de requisitos Definir Visin y Alcance Identificar clases de usuarios Establecer grupos enfocados Identificar casos de uso Identificar eventos y respuestas del sistema Mantener workshops de captura Observar a los usuarios en la ejecucin de su trabajo Examinar informes de problemas Reutilizar requisitos

Anlisis
Dibujar un Diagrama de Contexto Crear prototipos Analizar la viabilidad Priorizar requisitos Modelar los requisitos Crear un Diccionario de Datos Asignar requisitos a subsistemas Aplicar QFD (Quality Function Deployment)

Especificacin
Adoptar una plantilla de ERS Identificar los orgenes de los requisitos Etiquetar de modo nico para cada requisito Registrar las reglas de negocio Especificar atributos de calidad

Validacin
Inspeccionar documentos requisitos Probar requisitos Definir criterios aceptacin los de los de

Gestin de Requisitos
Definir un proceso de control de cambios Establecer un grupo (o comit) de control de cambios Realizar anlisis de impacto sobre los cambios Crear lneas base y controlar las versiones de los requisitos Mantener la historia de los cambios Seguir el estado de los requisitos Medir la volatilidad de los requisitos Usar herramientas de gestin de requisitos Crear matrices de trazabilidad de los requisitos

14

15

MANEJO DE LOS REQUISITOS FUNCIONALES

Conceptual
Diagrama de Flujo de Datos (DFD) Funciones Desarrollo Estrucutrado Datos Diagrama de Descomposicin (DDF) Diagrama de Estructura de Datos (DED) Diagramas de Entidad Relacin Extendido Diagramas de Clases (Anlisis) Diagrama de Paquetes Desarrollo OO Tiempo Casos de Uso

Lgico
Diagrama de Estructura de Cuadros (DEC)

Fsico

Normalizacin Diagramas de Clases (Diseo) Diagramas de Paquetes Diagrama de Transicin de Estados (DTE) Diagramas de Interacccin de Objetos

Reglas de Obtencin del Modelo Fsico Optimizacin Diagramas de Componentes Diagramas de Despliegue

Funciones

De uso comn.
Tcnicas principales La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, as que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

16

Entrevistas Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallas. Las entrevistas pueden ser personales o grupales. Talleres Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los requisitos y para dirigir la discusin. Prototipos Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado. Casos de uso Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales.

EJERCICIO PRCTICO
En base a un sistema de informacin de pacientes en un hospital, plantee un plan de entrevistas para mdicos, enfermeras y tcnicos en radiologa y laboratorio, para identificar los requerimientos del sistema.

17

1.2 MODELADO DEL SISTEMA6

La ingeniera de sistemas de computadora es un proceso de modelado. Tanto si el punto de mira est en la visin global o en la visin detallada, el ingeniero crea modelos que: Definan los procesos que satisfagan las necesidades de la visin en consideracin; Representen el comportamiento de los procesos y los supuestos en los que se basa el comportamiento; Definan explcitamente las entradas exgenas y endgenas de informacin al modelo; Representen todos las uniones (incluyendo las salidas) que permitan al ingeniero entender mejor la visin. Para desarrollar el modelo del sistema, se emplea un esquema del modelado del sistema. El ingeniero de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del esquema: (1) interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema, (4) salida y (5) mantenimiento y autocomprobacin.

Proceso de Interfaz de Usuario

Proceso de Entrada Funciones de Proceso y Control
Mantenimiento y Autocomprobacin

Proceso de Salida

El esquema del modelado del sistema permite al analista crear una jerarqua en detalle, donde en el nivel ms alto de dicha jerarqua se encuentra el diagrama de contexto del sistema. Este diagrama establece el lmite de informacin entre el sistema que se est implementando y el entorno en que va a operar. En otras palabras, define todos los suministradores externos de informacin que emplea el sistema, todos los consumidores externos de informacin creados por el sistema y todas las entidades que se comunican a travs de la interfaz o realizan mantenimiento y autocomprobacin.

EVALUACIN DEL TEMA.

PARTE I. Tomando como referencia los libros de Ingeniera de Software de los autores IanSummerville y Roger Pressman, investigue y complete el siguiente cuestionario en hojas de papel bond tamao carta. 1. 2. 3.
6

Qu es software? Cules son los tipos de productos de software y en qu consisten? Qu es Ingeniera del Software?

Tomado de Ingeniera de Software. Roger Pressman. 5 Edicin. Pg. 167,176.

18

4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

14. 15.

Cul es la diferencia entre Ingeniera del Software y Ciencias de la Computacin? Cul es la diferencia entre Ingeniera del Software e Ingeniera de Sistemas? Mencione las actividades fundamentales que comprende el proceso de software? Qu es un modelo de procesos del software? Escriba tres ejemplos de modelos que se pueden producir y explquelos. Cules son los 3 modelos de desarrollo de software en los que se basan los modelos de procesos? Cmo se distribuyen los costos en la Ingeniera del Software? Haga un esquema de los diferentes mtodos de la Ingeniera del Software en el tiempo. Qu son las herramientas CASE y qu significan estas siglas? Explique en qu consisten las siguientes normas de comportamiento tico de los profesionales del Software: Confidencialidad, Competencia, Derechos de Propiedad Intelectual y Uso inapropiado de las Computadoras. En qu consiste el Cdigo de tica de la IEEE/ACM? Explique en qu consiste el Modelado de Sistemas?

PARTE II. Sopa de letras. En la siguiente sopa de letras, encontrar 11 trminos estudiados en este tema. Encierre en valos las palabras encontradas.

19

TERMINOLOGA APLICADA

Ingeniera de Requerimientos: es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. (Sommerville, 2005: 82)

Prototipos: son simulaciones del posible producto, que luego son utilizados por el usuario final, permitindonos conseguir una importante retroalimentacin en cuanto a si el sistema diseado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

Requerimientos: son las descripciones que hace el usuario de los deseos o necesidades que tiene frente a un producto a los ingenieros o desarrolladores del software, estos requerimientos originan unos requisitos que se deben cumplir para poder llegar a cumplir los requerimientos.

BIBLIOGRAFA

Ingeniera del Software. IanSommerville. 7 Edicin. Editorial Pearson. Mxico. Ingeniera del Software. Un enfoque prctico. Roger Pressman. 5 Edicin. Editorial McGraw Hill. Mxico. Ingeniera del Software. Un enfoque prctico. Roger Pressman. 6 Edicin. Editorial McGraw Hill. Mxico. Ingeniera de sistemas de software. Gonzalo Len Serrano. Documento pdf. Requisitos de Software. Juan Bernardo Quintero. Documento pdf.

SITIOS DE INTERNET:
Ingeniera de requisitos. http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/materiales-de-clase/

20

TEMA 2. MODELADO DEL ANLISIS

2.1 IDENTIFICACIN, ANLISIS Y ESPECIFICACIN DE REQUISITOS PARA EL DESARROLLO DEL SOFTWARE
Identificacin de Requisitos para el Software: Antes de que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a travs de un proceso de obtencin. Un cliente tiene un problema que pretende sea resuelto con una solucin basada en computadora. Un desarrollador responde a la solicitud de ayuda del cliente. En ese momento se est estableciendo una comunicacin. La tcnica ms usada para la obtencin de requisitos es la entrevista. Anlisis. El anlisis de los requisitos es una tarea de ingeniera del software que cubre el hueco entre la definicin del software a nivel sistema y el diseo del software (Fig.1). El anlisis de requisitos permite al ingeniero de sistemas especificar las caractersticas operacionales del software (funcin, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software. El anlisis de requisitos del software puede dividirse en cinco reas de esfuerzo: (1) reconocimiento del problema, (2) evaluacin y sntesis, (3) modelado, (4) especificacin y (5) revisin. Inicialmente, el analista estudia la Especificacin del Sistema (si existe alguna) y el Plan del Proyecto de Software.

Ingeniera de sistemas de computadora

Anlisis de requisitos del software

Diseo del Software

FIG.1 Por ejemplo, un mayorista de automviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rpidamente el estado de un componente; (2) dos o tres das de media para actualizar un archivo a base de tarjetas; (3) mltiples rdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes, etc. Una vez que se han identificado los problemas, el analista determina qu informacin va a producir el nuevo sistema y qu informacin se le proporcionar al sistema.

21

Especificacin de requisitos.7 La especificacin es un documento que define de forma completa, precisa y verificable, los requisitos, el diseo, el comportamiento u otras caractersticas de un sistema o componente de un sistema. La especificacin de requisitos del software se puede definir como la documentacin de los requisitos esenciales del software y de sus interfaces externos. Debe tener dos caractersticas fundamentales: 1. Debe incluir informacin cierta, es decir, coherente con las necesidades reales del usuario que se desean satisfacer. 2. Debe comunicar dicha informacin de forma eficaz, es decir, de tal manera que se pueda comprender perfectamente. Caractersticas de una buena especificacin de requisitos del software: 1. No ambigua 2. Completa 3. Fcil de verificar 4. Consistente 5. Clasificada por importancia o estabilidad 6. Fcil de modificar 7. Fcil identificacin del origen y de las consecuencias de cada requisito 8. De fcil utilizacin durante la fase de explotacin y mantenimiento. Uno de los aspectos ms importantes de la especificacin de requisitos es el de las interfaces externas del software, tanto por su influencia en la facilidad de uso del software como por ser lo que ms fcilmente percibe el usuario y donde ms influyen sus preferencias. Las interfaces con el exterior coinciden con lo que tradicionalmente se ha llamado las entradas y las salidas del sistema. En el caso del anlisis estructurado se pueden identificar fcilmente slo con fijarse en los flujos que entran y salen del sistema en el diagrama de contexto. La accin de modelar los requerimientos da como resultado uno o ms de los siguientes tipos de modelo: Modelos basados en el escenario de los requerimientos desde el punto de vista de distintos actores del sistema. Modelos de datos, que ilustran el dominio de informacin del problema. Modelos orientados a clases, que representan clases orientadas a objetos (atributos y operaciones) y la manera en que las clases colaboran para cumplir con los requerimientos del sistema. Modelos orientados al flujo, que representan los elementos funcionales del sistema y la manera como transforman los datos a medida que se avanza a travs del sistema. Modelos de comportamiento, que ilustran el modo en el que se comparte el software como consecuencia de eventos externos. 2.2 PRINCIPIOS DE ANLISIS Y PROTOTIPOS

Durante las dos pasadas dcadas, se han desarrollado un gran nmero de mtodos de modelado. Los investigadores han identificado los problemas del anlisis y sus causas y han desarrollado varias notaciones de modelado y sus correspondientes conjuntos de heursticas para solucionarlos. Cada mtodo de anlisis tiene su punto de vista. Sin embargo, todos los mtodos de anlisis se relacionan por un conjunto de principios operativos: 1. Debe representarse y entenderse el dominio de informacin de un problema. 2. Deben definirse las funciones que debe realizar el software.

Extracto tomado de Anlisis y diseo de aplicaciones informticas de Gestin. Mario Piattini.

22

3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos). 4. Deben dividirse los modelos que representan informacin, funcin y comportamiento de manera que se descubran los detalles por capas (o jerrquicamente). 5. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la implementacin. Adems de los principios operativos de anlisis mencionados anteriormente, se detallan un conjunto de principios directrices para la ingeniera de requisitos: Entender el problema antes de empezar a crear el modelo de anlisis. Desarrollar prototipos que permitan al usuario entender cmo ser la interaccin hombremquina. Registrar el origen y la razn de cada requisito Usar mltiples planteamientos de requisitos Dar prioridad a los requisitos Los modelos creados durante el anlisis de requisitos desempean unos papeles muy importantes: El modelo ayuda al analista a entender la informacin, la funcin y el comportamiento del sistema, haciendo por tanto ms fcil y sistemtica la tarea de anlisis de requisitos. El modelo se convierte en el punto de mira para la revisin y por tanto la clave para determinar si se ha completado, su consistencia yla precisin de la especificacin. El modelo se convierte en el fundamento para el diseo, proporcionando al diseador una representacin esencial del software que pueda trasladarse al contexto de la implementacin. CREACIN DE PROTOTIPOS Un prototipo es una versin preliminar, intencionalmente incompleta o reducida de un sistema. Los prototipos son estrategias aplicadas a la mayora de actividades del proceso de software, las cuales pueden estar relacionadas con aspectos tcnicos, funcionales, eficiencia o interfaces de usuario. El propsito de los prototipos es buscar de manera preliminar informacin necesaria para ayudar en la toma de decisiones. Se puede pensar en un prototipo como un medio para la especificacin de requisitos o un enlace de comunicacin entre el usuario final y el diseador. El anlisis hay que hacerlo independientemente del paradigma de ingeniera del software que se aplique. Sin embargo, la forma que toma este anlisis vara. En algunos casos es posible aplicar los principios operativos del anlisis y obtener un modelo de software del que se pueda desarrollar un diseo. En otras situaciones, se realizan recopilaciones de requisitos, se aplican los principios del anlisis y se construye un modelo del software a fabricar (prototipo) para que lo valore el cliente y el desarrollador. Finalmente, hay circunstancias que requieren la construccin de un prototipo al comienzo del anlisis, ya que el modelo es el nico medio a travs del cual se pueden obtener eficazmente los requisitos. El modelo evoluciona despus hacia la produccin del software.

ACTIVIDAD PARA EL ESTUDIANTE

CASO DE ESTUDIO Lea el siguiente caso y complete la historia segn considere que sera el final de la misma. Luego analice las causas por las cuales los proyectos se entregan tardamente y explique. A finales de los aos sesenta del siglo pasado, se eligi a un entusiasta joven ingeniero para que escribiera un programa de computadora para una aplicacin de fabricacin automatizada. La razn para su seleccin fue simple. El era la nica persona en su grupo tcnico que asisti a un seminario de programacin de computadoras. Saba los pros y los contras del lenguaje ensamblador y de FORTRAN,

23

pero nada conoca acerca de ingeniera de software incluso menos acerca de la calendarizacin y el seguimiento de proyectos. Su jefe le dio los manuales apropiados y una descripcin verbal de lo que tena que hacer. Se le inform que el proyecto deba estar terminado en dos meses. Ley los manuales, consider su enfoque y comenz a escribir el cdigo. Despus de dos semanas, el jefe lo llam a su oficina y le pregunt sobre cmo iban las cosas. Realmente grandiosas, dijo el ingeniero con entusiasmo juvenil. Esto fue mucho ms simple de lo que pens. Probablemente tenga ya un avance de 75 por ciento. El jefe sonri y alent al joven ingeniero a seguir con el buen trabajo. Planearon reunirse de nuevo en una semana. Una semana despus, el jefe llam al ingeniero a su oficina y le pregunt: Dnde estamos?. Todo est bien, dijo el joven, pero encontr algunos tropiezos. Los allanar y pronto estar de vuelta en el camino. Qu te parece la fecha lmite?, pregunt el jefe. No hay problema, dijo el ingeniero. Tengo un avance de cerca de 90 por ciento.

2.3

MODELADO DE DATOS, DE FLUJO DE INFORMACION Y COMPORTAMIENTO.

2.3.1 MODELADO DE DATOS Si los requerimientos del software incluyen la necesidad de crear, ampliar o hacer interfaz con una base de datos, o si deben construirse y manipularse estructuras de datos complejas, el equipo del software tal vez elija crear un modelo de datos como parte del modelado general de los requerimientos. Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Tpicamente un modelo de datos permite describir:

Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. Operaciones de manipulacin de los datos: tpicamente, operaciones de agregado, borrado, modificacin y recuperacin de los datos de la base.

El modelado de datos responde a una serie de preguntas especficas importantes para cualquier aplicacin de procesamiento de datos. Cules son los objetos de datos primarios que va a procesar el sistema?, Cul es la composicin de cada objeto de datos y qu atributos describe el objeto?, Dnde residen actualmente los objetos? Cul es la relacin entre los objetos y los procesos que los transforman? Para responder estas preguntas, los mtodos de modelado de datos hacen uso del diagrama de entidad-relacin (DER). Permite que un ingeniero del software identifique objetos de datos y sus relaciones mediante una notacin grfica. En el contexto del anlisis estructurado, el DER define todos los datos que se introducen, se almacenan, se transforman y se producen dentro de una aplicacin. El DER es especficamente til para aplicaciones en donde los datos son complejos.

24

Simbologa
Representa una Enti dad

Ejemplo de DER

Representa una Rel aci n

Representa un Atri buto

Conecta l os Smbol os

Ejemplo:

No. Pginas Nacionalidad

Fecha Pub

Nombre

Direccin

Fecha Nac.
AUTOR N
Escribe

Titulo

OBRA

Edita

EDITORIAL

Nombre

Representacin tabular de objetos de datos: Liga un objeto de datos con otro, en este caso el propietario Nombrar los atributos

Identificador

Atributos descriptivos

Atributos referenciales

Fabricante Lexus Chevy BMW Ford

Modelo LS400 Corvette 75Oil Taurus

Nmero de serie AB123 X456 XZ765 Q12A45

Carrocera Sedn Deportivo Cup Sedn

Color Blanco Rojo Blanco Azul

Propietario RSP CCD LJL BLF

Instancia

25

INVESTIGACIN INDIVIDUAL
INVESTIGUE Y CONTESTE. 1. Para qu sirve un diagrama entidad relacin? 2. Qu es una llave primaria? 3. Cules son los elementos de un DER? 4. Qu son los atributos? 5. En qu consiste la cardinalidad? 6. Qu son metadatos? 7. En qu difiere un DER de un DFD? 8. Cul es la relacin entre un DFD y un DER? 9. Cul es la relacin entre un DER y un Diccionario de datos? 10. Qu es la integridad referencial? 11. Investiga qu son las reglas de Codd y para qu sirven. Pon ejemplos.

2.3.2

MODELADO DE FLUJO DE INFORMACIN

La informacin se transforma a medida que fluye por un sistema basado en computadora. El sistema acepta entradas en una gran variedad de formas; aplica elementos de hardware, software y humanos para transformar la entrada en salida, y produce salida en una gran variedad de formas. La entrada puede ser una seal de control transmitida por un controlador, una serie de nmeros escritos por un enlace de una red o un archivo voluminoso de datos recuperado de un almacenamiento secundario. La transformacin puede ser, desde una sencilla comparacin lgica, hasta un complejo algoritmo numrico o un mecanismo de reglas de un sistema experto. El anlisis estructurado es una tcnica del modelado del flujo y del contenido de la informacin. La representacin del modelado de flujo de datos puede hacerse a travs de un Diagrama de Flujo de Datos. El modelado del flujo de datos es una actividad fundamental del anlisis estructurado. El modelado orientado al flujo da una indicacin de la forma en la que las funciones de procesamiento transforman los objetos de datos. Aunque algunos ingenieros de software perciben el modelado orientado al flujo como una tcnica obsoleta, sigue siendo una de las notaciones ms usadas actualmente para hacer el anlisis de los requerimientos. Los diagramas de flujo de datos se utilizan para complementar los diagramas UML y amplan la perspectiva de los requerimientos y del flujo del sistema. El diagrama de flujo de datos (DFD) es una tcnica que representa el flujo de la informacin y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida; ya que adopta un punto de vista del tipo entrada-proceso-salida para el sistema. Se puede usar el diagrama de flujo de datos para representar un sistema o un software a cualquier nivel de abstraccin. De hecho, los DFDs pueden ser divididos en niveles que representen un mayor flujo de informacin y un mayor detalle funcional. Por consiguiente, el DFD proporciona un mecanismo para el modelado funcional, as como el modelado del flujo de informacin. Un DFD de nivel 0, tambin denominado modelo fundamental del sistema o modelo de contexto, representa al elemento de software completo como una sola burbuja con datos de entrada y de salida representados por flechas de entrada y de salida, respectivamente. Al dividir el DFD de nivel 0 para mostrar ms detalles, es cuando empezamos a crear los DFDs por niveles.

26

Ward y Mellor amplan la notacin bsica del anlisis estructurado para que se adapte a las siguientes demandas impuestas por los sistemas de tiempo real: Flujo de informacin que es recogido o producido de forma contina en el tiempo. Informacin de control que pasa por el sistema y el procesamiento de control asociado. Ocurrencias mltiples de la misma transformacin que se encuentran a menudo en situaciones de multitarea. Estados del sistema y mecanismos que producen transicin de estados en el sistema.

EJEMPLO
A continuacin se presenta un DFD en varios niveles para un sistema de control de pedidos.

NIVEL DE CONTEXTO

27

28

EJERCICIOS PRCTICOS Elabore un DFD de contexto y DFD nivel 1 para los siguientes casos:

1. Sistema de Administracin de la Librera La Fuente de la Juventud. Esta librera distribuye libros y artculos varios a sus clientes. Consta del siguiente personal: 3 vendedores, un cajero, un vigilante que controla la entrada de clientes por medio de su identificacin personal y un encargado de la sucursal. El encargado solicita productos a sus proveedores y se encarga de llevar el control de todas las operaciones de la librera y registrarlas en reportes y facturas segn sea el caso. Adems de la planilla de pagos. 2. Sistema de Venta de Hamburguesas Quecos. La empresa consta de tres carros ambulantes que reportan diariamente las ventas, para lo cual anotan el detalle de la venta y el saldo, luego le dan una factura a sus clientes. El encargado de la empresa se surte de sus proveedores y realiza una planilla de pagos para los tres vendedores que tiene. 3. Con su equipo de trabajo elaboren los DFDs para cada nivel de su proyecto de mdulo.

2.3.3 MODELADO DEL COMPORTAMIENTO El modelado del comportamiento es uno de los principios fundamentales de todos los mtodos de anlisis de requisitos. El modelo de comportamiento indica la forma en la que responder el software a eventos o estmulos externos. Para generar el modelo deben seguirse los pasos siguientes: 1. Evaluar todos los casos de uso para entender por completo la secuencia de interaccin dentro del sistema. 2. Identificar los eventos que conducen la secuencia de interaccin y que entienden el modo en el que stos se relacionan con objetos especficos. 3. Crear una secuencia para cada caso de uso. 4. Construir un diagrama de estado para el sistema. 5. Revisar el modelo de comportamiento para verificar la exactitud y consistencia. El diagrama de transicin de estados (DTE) representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie su estado. Otros tipos de representacin del comportamiento son los llamados Diagramas de secuencia. 2.4 MECANISMOS DEL ANLISIS ESTRUCTURADO Y DICCIONARIO DE DATOS El modelo de anlisis acompaa representaciones de objetos de datos, funciones y control. En cada representacin los objetos de datos y/o elementos de control juegan un papel importante. Por consiguiente, es necesario proporcionar un enfoque organizado para representar las caractersticas de cada objeto de datos y elemento de control. Esto se realiza con el diccionario de datos. Se ha propuesto el diccionario de datos como gramtica casi formal para describir el contenido de los objetos definidos durante el anlisis estructurado. El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma comprensin de las entradas, salidas, de los componentes de los almacenes y tambin de los clculos intermedios.

29

DICCIONARIO DE DATOS El formato del diccionario vara entre las distintas herramientas, la mayora contiene la siguiente informacin: Nombre: el nombre principal del elemento de datos o de control, del almacn de datos, o de una entidad externa. Alias: otros nombres usados para la primera entrada. Dnde se usa y cmo se usa: un listado de los procesos que usan el elemento de datos o de control y cmo lo usan (por ejemplo, como entrada al proceso, como salida del proceso, como almacn de datos, como entidad externa). Descripcin del contenido: el contenido representado mediante una notacin. Informacin adicional: otra informacin sobre los tipos de datos, los valores implcitos (si se conocen), las restricciones o limitaciones, etc.

CONSTRUCCIN DE UN DICCIONARIO DE DATOS. Como primer paso en la construccin de un diccionario de datos se debe listar todas las entidades, flujos de datos, procesos y almacenes de todos los diagramas de un DFD propuesto. El siguiente paso es describir las estructuras de datos que componen cada uno de ellos. Por ltimo, se describen los datos que componen las estructuras. Existen muchos esquemas de notacin comunes utilizados por el analista de sistemas. El que se muestra a continuacin es de los ms comunes y utiliza varios smbolos sencillos: = est compuesto de + y () {} [] ** @ | optativo (puede estar presente o ausente) iteracin seleccionar una de varias alternativas comentario identificador (campo clave) para un almacn separa opciones alternativas en la construccin.

Definiciones: La definicin de un dato se introduce con el smbolo =. En este contexto, el = se lee: se define como, o se compone de, o significa. A = B+C (A se define como B y C). Por ejemplo, podemos definir: nombre = ttulo de cortesa + nombre + (segundo nombre) + apellido paterno + apellido materno ttulo de cortesa = [Sr. | Srta. | Sra. | Dr. | Profesor ] nombre = {caracter legal} apellido paterno = {caracter legal} apellido materno = {caracter legal}

30

Datos opcionales, son los que pueden estar o no presentes en un dato compuesto. Por ejemplo, el nombre del cliente pudiera no incluir el segundo nombre, el domicilio de un cliente pudiera incluir o no informacin secundaria, como el nmero de departamento. Domicilio de cliente = (domicilio de envo)+(domicilio para cuenta) Significa que el domicilio pudiera consistir en slo un domicilio de envo o bien slo un domicilio para enviar cuentas o ninguno de los dos. Esta ltima posibilidad es dudosa. Es mucho ms probable que el usuario quiera decir que el domicilio debe consistir en uno u otro o ambos. Esto se representa as: Domicilio del cliente = [domicilio de envo | domicilio para cuentas | domicilio de envo +domicilio para cuentas] Si se quiere que exista siempre domicilio de envo y que domicilio para cuentas sea opcional se representa as: Domicilio del cliente = domicilio de envo + (domicilio para cuentas) La notacin de iteracin se usa para indicar la ocurrencia repetida de un componente de un dato. Se lee como cero o ms ocurrencias de . Solicitud = nombre del cliente + domicilio de envo + {artculo} Significa que la solicitud siempre debe contener un nombre de cliente, un domicilio de envo y tambin cero o ms ocurrencias de un artculo. Tambin podemos especificar los lmites superior e inferior de la iteracin, que debe haber por lo menos uno y se permitirn cuando menos 10; esto puede indicarse as: Solicitud = nombre del cliente + domicilio de envo + 1{artculo}10. Se puede especificar slo uno de los lmites y es correcto. Seleccin La notacin de seleccin indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones alternativas. Las opciones se encierran entre corchetes y se separan por la barra vertical |. Sexo = [femenino | masculino] Tipo de cliente = [gobierno | industria | Universidad | otro] Es importante asegurarse de cubrir todas las posibilidades. Alias: es una alternativa de nombre para un dato. Esto es una ocurrencia comn cuando se trata con diversos grupos de usuarios en diferentes departamentos o ubicaciones geogrficas, que insisten en utilizar distintos nombres para decir lo mismo. El alias se incluye en el diccionario de datos para que est completo y se relaciona con el nombre primario u oficial del dato. Comprador = * alias de cliente * Cuando diseamos un Diccionario de Datos, debemos adoptar un formato particular para la descripcin de sus elementos. Lo que se debe describir en el Diccionario de Datos adems de su estructura de datos, ser cada uno de los elementos que forman un DFD. Ejemplos de llenado de un Diccionario de Datos:

31

32

33

EJERCICIOS PRCTICOS
1.

En base al proyecto de mdulo, con su equipo de proyecto elaboren el diccionario de datos respectivo para el ltimo nivel del DFD, indicando la estructura de datos completa y las llaves respectivas de la tabla en los almacenes. Utilicen los formatos anteriores para la elaboracin de dicho diccionario.

EVALUACIN DEL TEMA

Contesta las siguientes preguntas. Recuerda, si no lo sabes debes investigar.
1. Los elementos de un Diagrama de Flujo de Datos son: ________________________, __________________________, ________________________ y ________________________ 2. Los elementos de un Diagrama Entidad Relacin son: ________________________, _____________________ y ________________________

34

3. Qu es integridad referencial?___________________________________________________ ___________________________________________________________________________ 4. Qu es una llave primaria? _____________________________________________________ ___________________________________________________________________________ 5. Qu es una llave fornea? _____________________________________________________ ___________________________________________________________________________ 6. Qu es un alias en el Diccionario de Datos? ________________________________________ ___________________________________________________________________________ 7. Para qu sirve la especificacin de procesos?_______________________________________ ___________________________________________________________________________ 8. Qu son metadatos?__________________________________________________________ ___________________________________________________________________________ 9. Escriba tres ejemplos de relaciones 1:1, 1:M y M:N

10. Cul es la simbologa usada en el diccionario de datos para definir la estructura de datos?

35

TEMA 3. DISEO ARQUITECTNICO

INTRODUCCIN
El objetivo de los diseadores es producir un modelo o representacin de una entidad que ser construida despus. En cualquier proceso de diseo existen dos fases importantes: la diversificacin y la convergencia. La diversificacin es la adquisicin de un repertorio de alternativas, de un material primitivo de diseo: componentes, soluciones de componentes y conocimiento, todo dentro de catlogos, de libros de texto y en la mente. Durante la convergencia, el diseador elige y combina los elementos adecuados y extrados de este repertorio para satisfacer los objetivos del diseo, de la misma manera a como se establece en el documento de los requisitos, y de la manera en que se acord con el cliente.

3.1 CONCEPTO, PROCESO, PRINCIPIOS Y MODELOS DEL DISEO DE SOFTWARE.

3.1.1 CONCEPTO.

El diseo de la arquitectura define la relacin entre los elementos principales de la estructura del software, los estilos y patrones de diseo de la arquitectura que pueden usarse para alcanzar los requerimientos definidos por el sistema y las restricciones que afectan la forma en la que se implementa la arquitectura. El diseo del software siempre debe comenzar con el anlisis de los datos, pues son el fundamento de todos los dems elementos del diseo. Una vez obtenido el fundamento, se obtiene la arquitectura. Slo entonces deben realizarse otros trabajos del diseo. CONCEPTOS RELACIONADOS CON EL DISEO ARQUITECTNICO: DISEO DE DATOS Los objetos de datos y las relaciones definidas en el diagrama entidad-relacin y el contenido detallado de datos del diccionario de datos constituyen la base para el diseo de datos. Se obtiene a partir del modelo de anlisis y de la interaccin de subsistemas definidos dentro del modelo de anlisis. Describe como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean. Se obtiene a partir de la especificacin del proceso, la especificacin del control y el diagrama de transicin de estados

DISEO ARQUITECTNICO

DISEO DE INTERFAZ

DISEO PROCEDIMENTAL

COMPONENTES DEL DISEO.

SMBOLOS GRFICOS DICCIONARIOS DE DATOS

Identifica y describe los componentes de un sistema y las relaciones entre estos. Describe todos los datos utilizados en el sistema

36

DESCRIPCIONES DE PROCESOS Y PROCEDIMIENTOS REGLAS

pueden ser manual o automatizado. Descripcin tcnica para describir las actividades que se realizan los procesos. Pasos a seguir para describir y documentar de forma correcta y completa.

HERRAMIENTAS.

DIAGRAMA DE FLUJO DE DATOS

DICCIONARIO DE DATOS

DIAGRAMA ENTIDAD RELACIN (DER)

Es la base para otros componentes y describe como navegan los datos entre procesos y elementos relacionados. Contiene las caractersticas de los campos y/o descripcin detallada de los diferentes objetos que componen el sistema describe la relacin entre las entidades y los objetos (conjunta de informacin que contienen las entidades)

3.1.2 EL PROCESO DE DISEO

El diseo de software es un proceso iterativo por medio del cual se traducen los requerimientos en un plano para construir el software. Al principio, el plano ilustra una visin holstica del software. Es decir, el diseo se representa en un nivel alto de abstraccin, en el que se rastrea directamente el objetivo especfico del sistema y los requerimientos ms detallados de datos, funcionamiento y comportamiento. A medida que tienen lugar las iteraciones del diseo, las mejoras posteriores conducen a niveles menores de abstraccin. stos tambin pueden rastrearse hasta los requerimientos, pero la conexin es ms til.

El diseo de la arquitectura de software tiene en cuenta dos niveles de la pirmide del diseo mostrada en la figura: diseo de datos y diseo arquitectnico. El diseo de datos nos facilita la representacin de los componentes de datos de la arquitectura.

37

El diseo arquitectnico se centra en la representacin de la estructura de los componentes del software, sus propiedades e interacciones. La arquitectura del sistema afecta el rendimiento, solidez, grado de distribucin y mantenibilidad de un sistema. (Bosch, 2000). El estilo y estructura particulares elegidos para una aplicacin puede, por lo tanto, depender de los requerimientos no funcionales del sistema: 1. Rendimiento. Si el rendimiento es un requerimiento crtico, la arquitectura debera disearse para identificar las operaciones crticas en un pequeo nmero de subsistemas, con tan poca comunicacin como sea posible entre estos subsistemas. 2. Proteccin. Si la proteccin es un requerimiento crtico, debera usarse una arquitectura estructurada en capas, con los recursos ms crticos protegidos en las capas ms internas y aplicando una validacin de seguridad de alto nivel en dichas capas. 3. Seguridad. Si la seguridad es un requerimiento crtico, la arquitectura debera disearse para que las operaciones relacionadas con la seguridad se localizaran en un nico subsistema o en un pequeo nmero de subsistemas. Esto reduce los costes y los problemas de validacin de seguridad y hace posible crear los sistemas de proteccin relacionados con los de seguridad. 4. Disponibilidad. Si la disponibilidad es un requerimiento crtico, la arquitectura debera disearse para incluir componentes redundantes y para que sea posible reemplazar y actualizar componentes sin detener el sistema. 5. Mantenibilidad. Si la mantenibilidad es un requerimiento crtico, la arquitectura del sistema debera disearse usando componentes independientes de grano fino que puedan modificarse con facilidad. Los productores de los datos deberan separarse de los consumidores y deberan evitarse las estructuras de datos compartidas.

INVESTIGACIN INDIVIDUAL
Investigue en qu consisten el modelo de repositorio, cliente-servidor, de capas y centralizado. Elabora un reporte en hojas de papel bond tamao carta. Bibliografa de consulta: IanSommerville, captulo 11.

3.1.3 PRINCIPIOS DEL DISEO DE SOFTWARE

El Diseo de Software es una secuencia de pasos, no es una receta pues intervienen: La creatividad, experiencia y un compromiso con la calidad. Existen factores de calidad internos y externos. Externos. Propiedades que pueden ser observadas por los usuarios. Internas. Son buscados por el Ingeniero de Software.

El diseo del software es tanto un proceso como un modelo. El proceso de diseo es una secuencia de pasos que hacen posible que el diseador describa todos los aspectos del software que se va a construir. El modelo de diseo es equivalente a los planes de un arquitecto para una casa. Comienza representando la totalidad de todo lo que se va a construir (por ejemplo, una representacin en tres dimensiones de la casa) y refina lentamente lo que va a proporcionar la gua para construir cada detalle (por ejemplo, el diseo de fontanera). De manera similar, el modelo de diseo que se crea para el software proporciona diversas visiones diferentes de software de computadora. Segn Alan Davis, los principios de diseo son los siguientes:

38

1. En el proceso deben tomarse enfoques alternativos. 2. Deber rastrearse hasta el anlisis. 3. Se debe reutilizar. 4. Tratar de imitar el dominio del problema. 5. Uniformidad e integracin. 6. Deber estructurarse para admitir cambios. 7. Debe prever la adaptacin a circunstancias inusuales. 8. No codificar. 9. Evaluarse en funcin de calidad mientras estcreciendo. 10. Minimizar errores conceptuales.

3.1.4 MODELOS DEL DISEO DE SOFTWARE

Cuando se disea la interfaz entran en juego 4 modelos diferentes: 1. Modelo de diseo creado por el ingeniero de software. 2. Modelo del usuario: que puede ser creado por el ingeniero de software u otros ingenieros. 3. Percepcin del usuario. 4. Imagen del sistema creada por los que implementan el sistema. Estos 4 modelos se pueden reconciliar y derivar una representacin consecuente de la interfaz, para lo cual se deben conocer los perfiles de edad, sexo, habilidades fsicas, educacin, antecedentes culturales o tnicos, motivacin, objetivos y personalidad. Adems se pueden establecer las siguientes categoras de usuarios: Principiantes: no tienen conocimientos sintcticos ni conocimientos semnticos de la utilizacin de la aplicacin. Usuarios espordicos y con conocimientos: poseen un conocimiento semntico razonable, pero una retencin baja de la informacin necesaria para utilizar la interfaz. Usuarios frecuentes y con conocimientos: poseen el conocimiento sintctico y semntico suficiente, buscan modos abreviados de interaccin. Elementos del diseo Para elaborar el diseo de la interfaz se utilizarn las siguientes herramientas: 1. Diagrama de mens 2. Diseo de cada una de las pantallas del sistema de acuerdo con el diagrama jerrquico. 3. Conteo de Puntos de funcin Diferentes modelos arquitectnicos pueden ser producidos durante el proceso de diseo. Cada modelo presenta diferentes perspectivas de la arquitectura: Modelo esttico estructural que muestra los componentes principales del sistema. Modelo dinmico del proceso que muestra la estructura de proceso del sistema. Modelo de interfaz que define las interfaces de los subsistemas. Modelo de relaciones tales como un modelo de flujo de datos.

39

EJERCICIO PRCTICO:
Traslade el nmero de la izquierda al parntesis de la derecha segn corresponda. Sobran parntesis.

1. 2. 3. 4. 5.

Describe los datos utilizados en el sistema Se obtiene a partir del modelo de anlisis y de la interaccin de subsistemas Pasos a seguir para describir y documentar de forma correcta y completa Es la base para otros componentes y describe cmo navegan los datos entre procesos y elementos relacionados Identifica y describe los componentes de un sistema

( ) ( ) ( ) ( ) ( ) ( ) ( )

UML Diseo arquitectnico DFD Smbolos Grficos DER Reglas Diccionarios De Datos

3.2

DISEO MODULAR

El software se divide en componentes nombrados y abordados por separado, llamados frecuentemente mdulos, que se integran para satisfacer los requisitos del problema. Es ms fcil resolver un problema complejo cuando se rompe en piezas manejables. Un mdulo es normalmente un componente de un subsistema que proporciona uno o ms servicios a otros mdulos. A su vez ste usa los servicios proporcionados por otros mdulos. Los mdulos se componen normalmente de varios componentes del sistema ms simples. Se trata de dividir el software en componentes nombrados y abordados por separado llamados mdulos, que se integran para resolver los requisitos del problema. Segn G. Meyers, la modularidad es el nico atributo del software que permite gestionar un programa intelectualmente Un software monoltico (programa grande formado por un nico mdulo) no puede ser entendido fcilmente por el lector. Hay dos estrategias principales que se pueden usar cuando se descompone un subsistema en mdulos: 1. Descomposicin orientada a objetos, en la que se descompone un sistema en un conjunto de objetos que se comunican. Este criterio es el ms usado hoy da, y consiste en dividir el Problema principal, en mdulos (Objetos) que encapsulan juntas la definicin del objeto y todas sus operaciones. Se refiere a pequeos mdulos que van a realizar una tarea independiente y especfica, encaminada a la resolucin del problema principal pero sin depender de otro modulo; debido a esto es muy fcil modificar los mdulos sin afectar otros. 2. Descomposicin orientada a flujos de funciones, en la que se descompone un sistema en mdulos funcionales que aceptan datos y los transforman en datos de salida. Este criterio es el menos usado hoy en da y se refiere a dividir el programa principal en subprogramas que

40

agrupan funciones similares, es decir cada uno de estos Mdulos estn relacionados entre s, por tanto estos mdulos no son independientes, debido a esto resulta muy difcil modificarlos ya que el modificar alguno de los mdulos, implica modificar todos los dems Mdulos.

LECTURA INDIVIDUAL Leer sobre las dos estrategias de descomposicin en el libro de Ian Sommerville. Pgina 230-232. Elaborar un resumen en su cuaderno y poner otros ejemplos.
3.3 ARQUITECTURA DEL SOFTWARE Y DISEO DE DATOS TRANSACCIONALES Y TRANSFORMACIONES

QU ES ARQUITECTURA? Bass, Clements y Kazman definen este trmino como la estructura o estructuras d el sistema, que comprende a los componentes del software, sus propiedades externas visibles y las relaciones entre ellos. Es la representacin que capacita al ingeniero del software para: Analizar la efectividad del diseo para la consecucin de los requisitos fijados. Considerar las alternativas arquitectnicas en una etapa en la cual hacer cambios en el diseo es relativamente fcil. Reducir los riesgos asociados a la construccin del software. En el diseo arquitectnico, un componente del software puede ser tan simple como un mdulo de programa, pero tambin puede ser algo complicado como incluir base de datos y software intermedio (middleware) que permiten la configuracin de una red de clientes y servidores. Hay una diferencia entre los trminos arquitectura y diseo. Un diseo es una instancia de una arquitectura, similar a un objeto que es una instancia de una clase. Por ejemplo, considere la arquitectura cliente/servidor. Con esta arquitectura es posible disear de muchos modos un sistema de software basado en red, con el uso de una plataforma java (Java EE) o Microsoft (estructura .NET). Entonces hay una arquitectura, pero con base en ella pueden crearse muchos diseos. Por lo tanto no es vlido mezclar los trminos diseo y arquitectura. POR QU ES IMPORTANTE LA ARQUITECTURA? Facilitan la comunicacin entre todas las partes interesadas en el desarrollo de un sistema basado en computadora. Destaca decisiones tempranas de diseo que tendrn un profundo impacto en todo el trabajo de ingeniera del software. Constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo est estructurado el sistema y de cmo trabajan juntos sus componentes. En un sentido amplio podramos estar de acuerdo en que la Arquitectura del Software es el diseo de ms alto nivel de la estructura de un sistema, programa o aplicacin y tiene la responsabilidad de:

o o o

Definir los mdulos principales Definir las responsabilidades que tendr cada uno de estos mdulos Definir la interaccin que existir entre dichos mdulos: Control y flujo de datos Secuenciacin de la informacin Protocolos de interaccin y comunicacin Ubicacin en el hardware

41

INVESTIGACIN INDIVIDUAL
Investigar sobre estilos arquitectnicos y sub estilos. Luego contestar las siguientes preguntas. Elaborar un reporte en su cuaderno. Fuente de consulta: Libro de Roger Pressman.
1. 2. 3. 4. 5. Que es la arquitectura centrada a datos? Cundo se aplica la arquitectura de flujo? Qu nos permite la arquitectura de llamada y retorno? En que consiste la arquitectura de programa principal? Explique la arquitectura orientada a objetos

FLUJO DE TRANSACCIN: El flujo de transaccin se caracteriza por el movimiento de datos a travs de un camino de llegada que convierte la informacin del mundo exterior en una transaccin. Se evala la transaccin y de acuerdo con su valor, el flujo sigue por uno de los muchos caminos de accin. El centro del flujo de informacin desde el que emanan los caminos de accin se denomina Centro de Transaccin. Dentro de un flujo de transaccin, el flujo de informacin a travs de un camino de accin puede tener caractersticas de flujo de transformacin.

FLUJO DE TRANSFORMACIN: En un sistema, la informacin entra y sale en una forma del mundo exterior (entradas de teclado, tonos telefnicos, imgenes de visualizacin,...). Esos datos externos, deben ser convertidos auna forma adecuada para el procesamiento. La informacin entra al sistema mediante caminos que transforman los datos externos a una forma interna y se identifica como Flujo Entrante. En el interior del software se produce una transicin, los datos entrantes pasan a travs de un centro de transformacin, movindose ahora hacia la salida del software. Estos datos forman el Flujo Saliente. El flujo de datos global ocurre de forma secuencial y sigue uno o pocos caminos directos. Cuando una parte del DFD tiene estas caractersticas decimos que es un Flujo de Transformacin.

42

El Anlisis de Transformacin es una estrategia, no un algoritmo. Si se siguen los pasos de un algoritmo los resultados estn asegurados y son correctos, una estrategia consigue resultados buenos, pero no perfectos en una primera aproximacin. El anlisis de transformacin es un conjunto de pasos que permiten obtener, a partir de un DFD con caractersticas de transformacin, la estructura del sistema. El DFD con caractersticas de transformacin es aqul en el que se pueden distinguir tres zonas: 1. Flujo de llegada o entrada. 2. Flujo de transformacin o centro de transformacin. 3. Flujo de salida.

PASOS DEL ANALISIS DE TRANSFORMACION

1. 2. 3. 4.

Aislar el centro de transformacin. Realizar el primer nivel de factorizacin del Diagrama de Estructura de Cuadros. Elaborar el segundo nivel de factorizacin Refinar la estructura del sistema utilizando medidas y guas de diseo.

PASOS DEL DISEO DE TRANSFORMACIN: Los pasos empiezan con una reevaluacin del trabajo hecho durante el anlisis de requisitos y despus evoluciona hacia el diseo de la arquitectura del software. La transicin del DFD a una estructura de programa se hace en 7 pasos: 1. Revisar el modelo fundamental del sistema: revisar el DFD nivel 0 y la informacin complementaria. 2. Revisar y refinar los DFD del software: se examinan los DFD nivel 1, 2 y 3 hasta el nivel enque cada transformacin tiene una cohesin alta (es decir, cada transformacin ejecuta una funcin sencilla y diferenciada) pudindose implementar como un mdulo. En este paso se llega al nivel que contiene suficiente detalle como para establecer un diseo inicial para la estructura del programa. 3. Determinar si el DFD tiene caractersticas de transformacin o de transaccin: en general, el flujo de informacin de un sistema podr representarse siempre como una transformacin. Si tiene una caracterstica obvia de transaccin es conveniente tratarla como tal. El diseador selecciona la caracterstica general del flujo basndose en la naturaleza prevaleciente del DFD. Se aslan las regiones locales de flujo de transformacin o de transaccin, lo que nos permitir refinar la estructura del programa posteriormente. 4. Aislar el centro de transformacin especificando los lmites de los flujos entrante y saliente: La interpretacin de los lmites es algo subjetivo dependiente del diseador, as es posible obtener distintas soluciones alternativas variando los lmites del flujo. El diseador debe establecer unos lmites razonables. 5. Realizar una descomposicin de primer nivel: la estructura del programa representa una distribucin descendente del control. La descomposicin da como resultado una estructura de programa en la que los mdulos de nivel superior toman las decisiones de ejecucin y los mdulos de nivel inferior ejecutan la mayora del trabajo de entrada, de procesamiento y de salida. Los mdulos de nivel intermedio ejecutan algn control y realizan moderadas cantidades de trabajo.

43

En la parte superior de la estructura del programa se encuentra un mdulo de control, que sirve para coordinar las funciones de control subordinadas, que son: a) Controlador del procesamiento de la informacin entrante, que coordina la recepcin de todos los datos que llegan. b) Controlador del centro de transformacin, que supervisa todas las operaciones sobre los datos en su forma interna. c) Controlador del procesamiento de la informacin saliente, que coordina la produccin de la informacin que sale. Cada mdulo de control tiene un nombre que indica la funcin de los mdulos subordinados que controla. 6. Realizar descomposicin de segundo nivel: se realiza mediante la conversin de las transformaciones individuales (burbujas) de un DFD, en los mdulos correspondientes a la estructura del programa. Comenzando dentro de los lmites del centro de transformacin y movindose hacia fuera a travs de los caminos de entrada y luego de salida, las transformaciones se convierten en niveles subordinados de la estructura de control.

44

As obtenemos una estructura de programa inicial, tambin llamada Diagrama de Estructura. Aunque hemos hecho una correspondencia uno a uno entre las burbujas del DFD y los mdulos del software, tambin se pueden combinar 2 3 burbujas, representndolas como un solo mdulo, o tambin puede dividirse una burbuja en dos o ms mdulos. Aunque los mdulos que forman la estructura de programa tienen un nombre que indica la funcin que realiza, se debe escribir para cada uno de ellos un breve texto que explique su procesamiento. La informacin que contendr es: La informacin que entra y la que sale del mdulo. La informacin que es retenida en el mdulo (ejemplo: en almacenamientos de datos). Explicacin del procedimiento, indicando los principales puntos de decisin y las tareas. Tratamiento de las restricciones y caractersticas especiales, si las hay. 7. Refinar la estructura inicial del programa usando heursticas para mejorar la calidad del software. La estructura inicial del programa siempre puede refinarse aplicando los fundamentos de diseo, por ello, se puede aumentar o reducir el nmero de mdulos para obtener una descomposicin con una buena cohesin, un mnimo acoplamiento, una estructura de fcil implementacin, prueba y mantenimiento. Los refinamientos se rigen por consideraciones prcticas y de sentido comn. Hay ocasiones en las que el controlador de flujo de datos entrante/saliente es innecesario, o se requiere un procesamiento de la entrada en un mdulo subordinado al controlador de transformaciones, o no se puede conseguir un bajo acoplamiento por la necesidad de trabajar con datos globales. El objetivo de los siete puntos anteriores es desarrollar una representacin general de software. Es decir, una vez que se ha definido la estructura, podemos evaluar y refinar la arquitectura del software vindola en su conjunto. ANALISIS DE TRANSACCION El anlisis de transaccin se aplica cuando un DFD toma una forma, en la que un dato determina la eleccin de uno o ms flujos de informacin. La transaccin es evaluada y, basndose en su valor, el flujo se inicia por uno de los muchos caminos de accin. El centro de flujo de informacin desde el que emanan varios caminos de accin se llama centro de transaccin. PASOS DEL ANALISIS DE TRANSACCION: Pasos a seguir: 1. Revisar el modelo fundamental del sistema. 2. Revisar y refinar los DFD. 3. Determinar si el DFD tiene caractersticas de transformacin o de transaccin. 4. Identificar el centro de transaccin y las caractersticas del flujo de cada camino de accin. El centro de accin se localiza fcilmente en el DFD, es el origen de varios caminos de informacin que fluyen radialmente de l. Tambin deben aislarse el camino entrante y todos los caminos de accin. 5. Transformar el DFD en una estructura de software adecuada al procesamiento de transacciones. El flujo de transaccin se convierte en una estructura de programa que contiene una rama entrante y una rama de distribucin. La rama entrante se obtiene igual que el anlisis de transformacin, desde el centro de transaccin hacia fuera, se convierten las burbujas en mdulos. La rama de distribucin tiene un mdulo distribuidor que controla todos los mdulos de accin subordinados.

45

El flujo de cada camino de accin del DFD se convertir en una estructura que se corresponda con las caractersticas del flujo (de transformacin o de transaccin). 6. Descomponer y refinar la estructura de transaccin y la estructura de cada camino de accin. Cada camino de accin del DFD tiene sus propias caractersticas de flujo de informacin no de transaccin. La subestructura de cada camino de accin se obtiene siguiendo los pasos del anlisis correspondiente. 7. Refinar la estructura inicial del software usando heursticas de diseo para mejorar la calidad. Igual al anterior. Shaw y Garlan [Sha95a] describen un conjunto de propiedades que deben especificarse como parte del diseo de la arquitectura: Propiedades estructurales. Este aspecto de la representacin del diseo arquitectnico define los componentes de un sistema (mdulos, objetos, filtros, etc.) y la manera en la que estn agrupados e interactan unos con otros. Por ejemplo, los objetos se agrupan para que encapsulen tanto datos como el procedimiento que los manipula e interacten invocando mtodos. Propiedades extra funcionales. La descripcin del diseo arquitectnico debe abordar la forma en la que la arquitectura del diseo satisface los requerimientos de desempeo, capacidad, confiabilidad, seguridad y adaptabilidad, as como otras caractersticas del sistema. Familias de sistemas relacionados. El diseo arquitectnico debe basarse en patrones repetibles que es comn encontrar en el diseo de familias de sistemas similares. En esencia, el diseo debe tener la capacidad de reutilizar bloques de construccin arquitectnica. Dada la especificacin de estas propiedades, el diseo arquitectnico se representa con el uso de uno o ms de varios modelos diferentes. Los modelos estructurales representan la arquitectura como un conjunto organizado de componentes del programa. Los modelos de marco aumentan el nivel de abstraccin del diseo, al tratar de identificar patrones de diseo arquitectnico repetibles que se encuentran en tipos similares de aplicaciones. Los modelos dinmicos abordan los aspectos estructurales de la arquitectura del programa e indican cmo cambia la estructura o la configuracin del sistema en funcin de eventos externos. Los modelos del proceso se centran en el diseo del negocio o proceso tcnico al que debe dar acomodo el sistema. Por ltimo, los modelos funcionales se usan para representar la jerarqua funcional de un sistema.

3.4 DISEO DE LA INTERFAZ DEL USUARIO CON SUS REGLAS, ACTIVIDADES Y ANLISIS.
El diseo de la interfaz de usuario crea un medio eficaz de comunicacin entre los seres humanos y la computadora. Siguiendo un conjunto de principios de diseo de la interfaz, el diseo identifica los objetos y acciones de sta y luego crea una pantalla que constituye la base del prototipo de la interfaz de usuario. Cules son los pasos? El diseo de la interfaz de usuario comienza con la identificacin de los requerimientos del usuario, la tarea y el ambiente. Una vez identificadas las tareas del usuario, se crean y analizan los escenarios para ste y se define un conjunto de objetos y acciones de la interfaz. Esto forma la base para crear una plantilla de la pantalla que ilustra el diseo grfico y la colocacin de los iconos, la definicin de textos descriptivos, la especificacin y ttulos de las ventanas, y la especificacin de aspectos mayores y menores del men. Con el empleo de herramientas, se hace el prototipo, se implementa en definitiva el modelo del diseo y se evala la calidad del resultado. El plano de una casa (su diseo arquitectnico) no est completo sin la representacin de puertas, ventanas y conexiones de servicios para el agua, electricidad y telfono (por no mencionar la televisin

46

por cable). Las puertas, ventanas y conexiones de servicios del software informtico es lo que constituye el diseo de la interfaz de usuario. El diseo de la interfaz se centra en tres reas de inters: (1) el diseo de la interfaz entre loscomponentes del software; (2) el diseo de las interfaces entre el software y los otros productores y consumidores de informacin no humanos (esto es, otras entidades externas) y (3) el diseo de la interfaz entre el hombre (esto es, el usuario) y la computadora.

3.4.1 REGLAS DE DISEO DE LA INTERFAZ DEL USUARIO

Existen tres reglas de oro para el diseo de la interfaz: 1. Dejar el control al usuario La mayor parte de las restricciones y limitaciones impuestas por el diseador se han pensado para simplificar el modo de interaccin. Pero, para quienes? En muchos casos es posible que el diseador introduzca limitaciones y restricciones para simplificar la implementacin de la interfaz. Y el resultado puede ser una interfaz fcil de construir, pero frustrante de utilizar. Se definirn una serie de principios de diseo que permiten que el usuario tenga el control: Definir los modos de interaccin de manera que no obligue a que el usuario realice acciones innecesarias o no deseadas. Tener en consideracin una interaccin flexible. Permitir que la interaccin del usuario sea interrumpible y tambin reversible. Facilitar la interaccin a medida que aumenta la habilidad y permitir que aquella se personalice. Ocultar los tecnicismos internos al usuario ocasional. Disear la interaccin directa con objetos que aparezcan en la pantalla. 2. Reducir la necesidad de que el usuario memorice Cuanto ms tenga que recordar un usuario, ms propensa a errores ser su interaccin con el sistema. Esta es la razn por la que una interfaz de usuario bien diseada no pondr a prueba la memoria del usuario. Siempre que sea posible, el sistema deber recordar la informacin pertinente y ayudar a que el usuario recuerde mediante un escenario de interaccin, se definen los principios de diseo que hacen posible que una interfaz reduzca la carga de memoria del usuario: Reducir la demanda de memoria a corto plazo. Cuando los usuarios se ven involucrados en tareas complejas, exigir una memoria a corto plazo puede ser significativo. La interfaz se deber disear para reducir los requisitos y recordar acciones y resultados anteriores. Hacer que lo preestablecido sea significativo. El conjunto inicial de valores por defecto tendr que ser de utilidad para al usuario, pero un usuario tambin deber tener la capacidad de especificar sus propias preferencias. Definir atajos que sean intuitivos. Cuando para disear un sistema se utiliza la mnemnica (por ejemplo, alt-P para invocar la funcin de imprimir), sta deber ir unida a una accin que sea fcil de recordar (por ejemplo, la primera letra de la tarea que se invoca). La distribucin visual de la interfaz debe basarse en una metfora del mundo real. Por ejemplo, en un sistema de pago de facturas se deber utilizar la metfora de la chequera y el registro del cheque para conducir al usuario por el proceso del pago de facturas. Revelar informacin de manera progresiva. La interfaz debe estar organizada de manera jerrquica. Es decir, la informacin acerca de una tarea, objeto o comportamiento debe presentarse primero en un nivel de generalizacin elevado. Despus de que con el ratn el usuario manifieste inters, deben darse ms detalles. Por ejemplo, para muchas aplicaciones de procesamiento de textos, se tiene la funcin de subrayar. La funcin en s es una de varias en el men estilo del texto. No obstante, no se enlista cada una de las herramientas para

47

subrayar. El usuario debe hacer clic en la opcin de subrayar; despus se presentan todas las opciones para esta funcin (una raya, doble raya, lnea punteada, etc.). 3. Hacer consistente la interfaz. La interfaz debe presentar y obtener informacin en forma consistente. Esto implica: 1) que toda la informacin se organice de acuerdo con reglas de diseo que se respeten en todas las pantallas desplegadas, 2) que los mecanismos de entrada se limiten a un conjunto pequeo usado en forma consistente en toda la aplicacin, y 3) que los mecanismos para pasar de una tarea a otra se definan e implementen de modo consistente. Estas reglas de oro forman en realidad la base para los principios del diseo de la interfaz de usuario que servirn de gua para esta actividad de diseo de software tan importante.

INVESTIGACIN INDIVIDUAL
Leer el tema Anlisis de la Interfaz, diseo de la interfaz de usuario, actividades y Etapas del diseo de la interfaz. Elaborar un resumen en su cuaderno. Fuente: Roger Pressman.

3.5 PROGRAMACIN ESTRUCTURADA8.

El objetivo principal del diseo arquitectnico es desarrollar una estructura de programa modular y representar las relaciones de control entre los mdulos. Mezcla la estructura de programas y la estructura de datos y define las relaciones que facilitan el flujo de los datos a lo largo del programa. Esta forma de programar se basa en un famoso teorema, desarrollado por Edsger Dijkstra, que demuestra que todo programa puede escribirse utilizando nicamente las tres estructuras bsicas de control siguientes: Secuencia: el bloque secuencial de instrucciones, instrucciones ejecutadas sucesivamente, una detrs de otra. Seleccin: la instruccin condicional con doble alternativa, de la forma "ifcondicintheninstruccin-1 elseinstruccin-2". Iteracin: el bucle condicional "whilecondicin do instruccin", que ejecuta la instruccin repetidamente mientras la condicin se cumpla. Los programas que utilizan slo estas tres instrucciones de control bsicas o sus variantes (como los bucles for, repeat o la instruccin condicional switch-case), pero no la instruccin goto, se llaman estructurados. Estas tres construcciones son fundamentales para la programacin estructurada, tcnica importante en el diseo en el nivel de componentes. Una caracterstica importante en un programa estructurado es que puede ser ledo en secuencia, desde el comienzo hasta el final sin perder la continuidad de la tarea que cumple el programa, lo contrario de lo que ocurre con otros estilos de programacin. Este hecho es importante debido a que es mucho ms fcil comprender completamente el trabajo que realiza una funcin determinada si todas las instrucciones que influyen en su accin estn fsicamente contiguas y encerradas por un bloque. La facilidad de lectura, de comienzo a fin, es una consecuencia de utilizar solamente tres estructuras de control, y de eliminar la instruccin de transferencia de control goto.

Fuente: http://www.mcgraw-hill.es/bcv/guide/capitulo/8448148703.pdf

48

Cuando en la actualidad se habla de programacin estructurada, nos solemos referir a la divisin de un programa en partes ms manejables (usualmente denominadas segmentos o mdulos). Una regla prctica para lograr este propsito es establecer que cada segmento del programa no exceda, en longitud, de una pgina de codificacin, o sea, alrededor de 50 lneas. Esta tcnica de programacin conlleva las siguientes ventajas: a) El coste de resolver varios subproblemas de forma aislada es con frecuencia menor que el de abordar el problema global. b) Facilita el trabajo simultneo en paralelo de distintos grupos de programadores. c) Posibilita en mayor grado la reutilizacin del cdigo (especialmente de alguno de los mdulos) en futuras aplicaciones. El carcter auto contenido de los mdulos o libreras hace que pueda ocultarse el funcionamiento interno de las funciones contenidas en un mdulo, ya que para utilizarlas basta con saber con qu nombre y argumentos se invocan y qu tipo de valores devuelven. Al reunirlas en un mdulo, se realza la relacin entre las mismas separndolas del resto del programa. Esta ocultacin de los detalles se denomina encapsulacin y se alcanza dividiendo el cdigo del programa en dos ficheros diferenciados: un fichero (con extensin ".h") que incluye la declaracin de los tipos de datos y de las funciones gracias a lo cual se sabe cmo acceder y utilizar cada una de las mismas y otro (con extensin ".c") que contiene el cdigo de cada una de las funciones declaradas en el .h. Al compilar este ltimo queda transformado en cdigo objeto (al cual ya no se puede acceder para su lectura o modificacin) y puede distribuirse conjuntamente con el fichero de declaracin (el que acaba en .h), para su uso por parte de terceros sin riesgo alguno de alteracin de la funcionalidad original (sta qued encapsulada u oculta). Esto es as porque para hacer uso de las funciones incluidas en el mdulo nicamente necesitaremos conocer la informacin que nos proporciona el fichero de declaracin: el nombre, tipos de datos de los argumentos y valores de retorno de las funciones. No es necesario conocer los detalles de implementacin (sentencias que se ejecutan dentro de una funcin).

3.6 COMPARACIN DE NOTACIONES DEL DISEO 3.6.1 NOTACIN GRFICA DE DISEO Entre las herramientas grficas de mucha utilidad tenemos los diagramas UML de actividades y los diagramas de flujo, los cuales constituyen patrones grficos tiles que ilustran fcilmente detalles de procedimiento. El diagrama de actividades permite representar la secuencia, condicin y repeticin todos los elementos de que consta la programacin estructurada- y es descendiente de un diseo grfico anterior (que todava se utiliza mucho) llamado diagrama de flujo. En este diagrama similarmente, se emplea un rectngulo para indicar un paso o procesamiento. Un rombo representa una condicin lgica y las flechas indican el flujo del control. Son las mismas representaciones que se utilizan en un flujograma. 3.6.2 NOTACIN DEL DISEO TABULAR En muchas aplicaciones de software, se requiere un mdulo para evaluar una combinacin compleja de combinaciones de condiciones y seleccionar acciones apropiadas con base en stas. Las tablas de decisin proporcionan una notacin que traduce las acciones y condiciones (descritas en la narracin del procesamiento o caso de uso) a una forma tabular.

49

3.6.3 NOTACIN DE DISEO DEL PROGRAMA El lenguaje de diseo del programa (LDP), tambin llamado castellano estructurado o seudocdigo, incorpora la estructura lgica de un lenguaje de programacin y la expresividad de forma libre de un lenguaje natural. Una sintaxis bsica de LDP debe incluir construcciones para: definir los componentes, describir la interfaz, hacer la declaracin de los datos, estructurar bloques, hacer construcciones condicionales, de repeticin y de entrada y salida.

EJERCICIOS PRCTICOS
Elabora un ejemplo para cada una de las notaciones de diseo descritas en este tema.

EVALUACIN DEL TEMA

I PARTE. Traslada el nmero de la respuesta correcta a la casilla del centro, segn corresponda.

1.

Software monoltico

Consiste en dividir el problema principal, en mdulos que encapsulan juntas la definicin del objeto y todas sus operaciones Define los componentes de un sistema y la manera en que estn agrupados e interactan unos con otros. Se basa en ciertos principios como permitir que la interaccin del usuario sea interrumpible y tambin reversible. Implica que toda la informacin se organice de acuerdo con reglas de diseo que se respeten en todas las pantallas desplegadas. Es un conjunto de pasos que permiten obtener, a partir de un DFD con caractersticas de transformacin, la estructura del sistema. 50

2. 3.

Anlisis de transformacin Anlisis de transaccin

4.

Diseo

5.

Propiedades estructurales

6. 7. 8. 9.

Dejar control al usuario Hacer consistente la interfaz Descomposicin orientada a objetos Notacin grfica de diseo

Se refiere a la divisin de un programa en partes ms manejables utilizando los tres tipos de estructuras bsicas. Utiliza diagramas UML de actividades y diagramas de flujo Es un programa grande formado por un nico mdulo Se aplica cuando un DFD toma una forma, en la que un dato determina la eleccin de uno o ms flujos de informacin Es una instancia de una arquitectura, similar a un objeto que es una instancia de una clase.

10.

Programacin Estructurada

TEMA 4. MTRICAS TCNICAS DEL SOFTWARE.

METRICAS DE UN PROYECTO. Uno de los elementos que permite dar garanta acerca de la calidad del software es la aplicacin de mtricas, estas son medidas estadsticas aplicadas a un software determinado, garantizando calidad as como lo afirma Pressman: La garanta de calidad del software, es una Actividad de proteccin que se aplica a lo largo de todo el proceso de ingeniera del software. Existen tres conceptos fundamentales que debemos tomar en cuenta en la medicin de un proyecto: medida, medicin y mtrica. Aunque estos tres trminos con frecuencia se usan de modo intercambiable, es importante observar las sutiles diferencias entre ellos. 1. Medida: Proporciona una indicacin cuantitativa de la extensin, cantidad, dimensin, capacidad o tamao de algn atributo de un producto o proceso. 2. Medicin: es el acto de determinar una medida. Es el proceso mediante el cual se asignan nmeros o smbolos a los atributos de las entidades en el mundo real, de manera que se les define de acuerdo con reglas claramente determinadas. 3. Mtrica: Es una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. Un indicador es una mtrica o combinacin de mtricas que proporcionan comprensin acerca del proceso de software, el proyecto de software o el producto en s. Un indicador proporciona comprensin que permite al gerente de proyecto o a los ingenieros de software ajustar el proceso, el proyecto o el producto para hacer mejor las cosas. 4.1 FACTORES DE CALIDAD DEL SOFTWARE Concepto de Calidad: Conjunto de propiedades y de caractersticas de un producto o servicio, que le confieren aptitud para satisfacer una necesidad explcita o implcita (ISO 8402).

51

Calidad del Software: Es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. Factores que determinan la calidad del software: Se pueden clasificar en dos grandes grupos (Pressman): 1. Medidas Directas: La medida o medicin decimos que es directa, cuando disponemos de un instrumento de medida que nos muestra un resultado (generalmente numrico). 2. Medidas Indirectas: Cuando hablamos de sistemas informticos no siempre es posible realizar una medida directa, porque no disponemos del instrumento adecuado que nos permita realizar esa medicin. MTRICAS DEL SOFTWARE. Son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad, eficiencia. Entre las mtricas del software tenemos las siguientes: 1. Mtricas tcnicas: Se centran en las caractersticas del software. Aqu medimos la complejidad lgica y el grado de modularidad del sistema. Mide la estructura del sistema, el cmo est hecho. 2. Mtricas de calidad: Son todas las mtricas de software que definen de una u otra forma la calidad del software; tales como correccin, exactitud, integridad, facilidad de uso, estructuracin o modularidad, pruebas, facilidad de mantenimiento, reusabilidad, cohesin del mdulo, acoplamiento del mdulo, etc. Estas son los puntos crticos en el diseo, codificacin, pruebas y mantenimiento. Proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente. Correccin: es el grado en que el software desempea la funcin para la que fue creado y se mide en defectos por KLDC. Facilidad de Mantenimiento: es la sencillez con que un programa puede corregirse si se encuentra un error, al adaptarse si su entorno cambio o mejorar si el cliente cambia los requisitos y se mide en forma indirecta en TMC (Tiempo Medio de Cambio) Integridad: es la habilidad de un sistema para resistir ataques que requiere la definicin de amenaza y seguridad y se calcula: integridad = 1 (amenaza * (1 seguridad)). Por ejemplo, dados los siguientes valores de un paquete de base de datos en dos proyectos, podemos calcular la integridad:

52

Integridad para el proyecto 1: Integridad = 1 0.7 * (1 0) = 0.3 Integridad para el proyecto 2: Integridad = 1 0.2 * (1 - 0.8) = 0.96 Si la amenaza (probabilidad de que un ataque ocurrir) es 0.25, y la seguridad (posibilidad de repeler un ataque) es 0.95, la integridad del sistema es 0.99 (muy elevada). Si por otra parte, la probabilidad de amenaza fuera 0.5 y la posibilidad de repeler un ataque es solo 0.25, la integridad del sistema es 0.63 (inaceptablemente baja). Facilidad de uso: es el intento por cuantificar la sencillez de una aplicacin al utilizarla. 3. Mtricas de Productividad: Se centran en el rendimiento del proceso de la ingeniera del software. Es decir qu tan productivo va a ser el software que voy a disear. Se refiere a las caractersticas del software. 4. Mtricas de costo: se centra en el costo total del sistema informtico. 5. Mtricas orientadas al tamao: Esta nos permite conocer el tiempo en el que se terminar el software y cuntas personas se necesitan para su desarrollo, aqu medimos las variables con las que desarrollamos el software. Si una organizacin de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamao, como la que muestra la figura, que lista cada proyecto de desarrollo de software y las medidas correspondientes de cada proyecto.

Refirindonos a la entrada de la figura del proyecto alfa: se desarrollaron 12,100 lneas de cdigo (LDC) con 24 personas-mes y con un costo de $168,000 dlares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla incluyen todas las actividades de ingeniera del software (anlisis, diseo, codificacin y prueba) y no slo la codificacin. Otra informacin sobre el proyecto alfa indica que se desarrollaron 365 pginas de documentacin, se registraron 134 errores antes de que el software se entregara al cliente y se encontraron 29 errores despus de entregrselo al cliente dentro del primer ao de utilizacin. Tambin sabemos que trabajaron tres personas en el desarrollo del proyecto alfa. LDC: Nmero de lneas de cdigo. Esfuerzo: Nmero de horas invertidas en la realizacin del sistema. $(000): Costo total del sistema informtico Pp.doc.: El nmero de pginas de los manuales de documentacin del sistema. Errores: Errores detectados antes de la entrega del sistema. Defectos: Errores detectados despus de la entrega del sistema. Personas: Personal que realiz el proyecto. Con los datos registrados durante la elaboracin del proyecto podemos generar al final de dicho proyecto el siguiente conjunto de mtricas:

53

Productividad = KLDC /Esfuerzo Calidad = Errores / LDC Documentacin = Pp.doc./LDC Costo = $(000)/LDC

EJERCICIOS DE APLICACIN
Calcular las mtricas orientadas al tamao para los proyectos alfa, beta y gamma.

6. Mtricas orientadas a la funcin o puntos de funcin: Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcular las lneas de cdigo LDC, las mtricas de funcin se centran en la funcionalidad o utilidad del programa. Los puntos de funcin nos indican la medida de la productividad. Los puntos de funcin se obtienen utilizando una funcin emprica basado en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivas de la complejidad del software. Se calculan los puntos de funcin en base a la siguiente tabla:

Parmetros de medicin Nmero de entradas del usuario Nmero de salidas del usuario Nmero de consultas del usuario Nmero de archivos Nmero de interfaces externas Total puntos de funcin sin ajustar

Cuenta X X X X X TABLA 1

Factor de ponderacin Simple Media Compleja 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10

= = = = =

Valor con peso de complejidad = Suma del nmero de apariciones del elemento i (por ejemplo salidas) para cada nivel de complejidad (bajo, medio, alto). Sentencias semnticas pasos del proceso 1 10 11 20 21 - +

1 -5 BAJO BAJO MEDIO

6 - 10 BAJO MEDIO ALTO

11 - + MEDIO ALTO ALTO

TABLA 2

Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin apropiada de la tabla. Los valores del mbito de informacin estn definidos de la siguiente manera: 1. Nmeros de entradas de usuario: se cuenta cada entrada del usuario que proporcione al software diferentes datos orientados a la aplicacin. Las entradas deben ser distinguidas de las peticiones que se contabilizan por separado. El flujo de datos deber tener una sola direccin, del exterior al interior. Como consecuencia de una entrada siempre deber actualizarse un archivo lgico interno. Ej. Pantallas de entrada de datos, lector de cdigos de barras, lector de tarjetas magnticas y electrnicas, captura de imgenes, voz, etc.

54

Clasificacin de las entradas:

2. Nmero de salidas del usuario: se encuentra cada salida que proporciona al usuario informacin orientada a la aplicacin. En este contexto las salidas se refieren a informes, pantallas de salida de datos, grabacin de bandas magnticas, listados, mensajes de error, Transferencia de datos a otras aplicaciones, ya sea mediante archivos o transmisin de datos. Los elementos de datos individuales dentro de un informe se encuentran por separado. Son todos aquellos procesos que hacen llegar datos desde la aplicacin hacia el exterior, a un usuario o a otra aplicacin. El flujo de datos deber tener una sola direccin, del interior al exterior. Clasificacin de las salidas:

3. Nmeros de consultas al usuario: una peticin o consulta est definida como una entrada interactiva que resulta de la generacin de algn tipo de respuesta en forma de salida interactiva (en lnea). Se cuenta cada peticin por separado. Son todos aquellos procesos que estn formados por una combinacin de entradas y salidas, produciendo una consulta a los datos. El flujo de datos deber tener dos direcciones. Como consecuencia de una consulta no se modifican los datos del sistema. (Igual a tabla de entradas) 4. Numero de archivos lgicos internos: Es un grupo de datos relacionados, tal como los percibe el usuario y que son mantenidos por la aplicacin. Se cuenta cada archivo maestro lgico, o sea una agrupacin lgica de datos que puede ser una parte en una gran base de datos o un archivo independiente. Los archivos se cuentan una sola vez, independientemente del nmero de procesos que los acceden. Ejemplos: Clientes, Socios, Artculos, Proveedores. Clasificacin de los archivos lgicos internos:

55

5. Nmero de interfaces externas: agrupamiento lgico de datos que reside fuera de la aplicacin, pero que proporciona informacin que puede usar la aplicacin. Se cuentan todas las interfaces legibles por la mquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir informacin a otro sistema. Son archivos internos de otra aplicacin. Clasificacin de los archivos de interfaz:

En base a las tablas anteriores, se coloca el nmero de elementos de las caractersticas de nuestro sistema en el peso correspondiente a la tabla de valores de pesos y puntos de funcin sin ajustar. BAJA CARACTERISTICA Entradas Salidas Consultas Archivos Interfaces externas CANT PESO 3 4 3 7 5 RESUL CANT MEDIA PESO 4 5 4 10 7 Total caractersticas PFSA RESUL CANT ALTA PESO 6 7 6 15 10 RESUL TOTAL

TABLA 3 (Tabla de valores de pesos y puntos de funcin sin ajustar)

56

Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada cuenta. Las organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinacin de la complejidad es algo subjetivo. Para calcular los puntos de funcin se utiliza la siguiente relacin. PFA = Puntos de Funcin Ajustados = PFSA * [0.65 + 0.01 * (fi)] Donde PFSA es la suma de todas las entradas de puntos de funcin sin ajustar obtenidas de la tabla anterior. Los valores 0.65 y 0.01 son valores establecidos por Albrecht obtenidos a partir de datos procedentes de diferentes proyectos referentes al nivel de error producidos en un promedio de 5000 proyectos. Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las respuestas a las cuestiones sealadas en la siguiente tabla (Tabla 4). Fi = total de factores de correccin. Los valores constantes de la ecuacin anterior y los factores de peso aplicados en las encuestas de los mbitos de informacin han sido determinados empricamente. Evaluar cada factor de complejidad en escala 0 a 5. TABLA 4

Le asignamos una puntuacin a cada factor de correccin FC:

57

TABLA 5

INVESTIGACIN INDIVIDUAL
Investigar sobre la importancia del uso de las mtricas del software y la oposicin que presentan algunos desarrolladores. Elabore un ensayo que tenga como mximo 5 pginas (sin incluir la portada) para justificar su punto de vista al respecto. 4.2 MTRICAS PARA CADA FASE DEL CICLO DE SISTEMAS.
4.2.1 MTRICAS PARA ANLISIS En esta fase es deseable que las mtricas tcnicas proporcionen una visin interna a la calidad del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el tamao del sistema resultante; es probable que el tamao y la complejidad del diseo estn directamente relacionados. Entre las Mtricas para el modelo de anlisis tenemos: LA MTRICA BANG puede aplicarse para desarrollar una indicacin del tamao del software a implementar como consecuencia del modelo del anlisis. MTRICAS PARA CALIDAD DE LA ESPECIFICACIN: En estas mtricas se emplea una lista de caractersticas que pueden emplearse para valorar la calidad del modelo de anlisis y la correspondiente especificacin de requerimientos: especificidad (falta de ambigedad), completitud, correccin, comprensibilidad, verificabilidad, consistencia interna y externa, factibilidad, concisin, rastreabilidad, modificabilidad, precisin y reusabilidad. MTRICAS BASADAS EN LA FUNCIN La mtrica de punto de funcin (PF) puede usarse de manera efectiva como medio para medir la funcionalidad que entra a un sistema. Esta mtrica puede usarse para: 1) estimar el costo o esfuerzo requerido para disear, codificar y probar el software; 2) predecir el nmero de errores que se

VIDA DEL DESARROLLO DE

58

encontrarn durante las pruebas, y 3) prever el nmero de componentes y/o de lneas fuente proyectadas en el sistema implementado. 4.2.2 MTRICAS PARA EL MODELO DE DISEO En este se genera la definicin de la arquitectura del sistema y del entorno tecnolgico que le va a dar soporte, junto con la especificacin detallada de los componentes del Sistema de Informacin. METRICAS DE ALTO NIVEL: Las mtricas de alto nivel nos ayudan a localizar los mdulos ms complejos y, por lo tanto, aquellos en los que debemos poner especial atencin. Tambin es utilizada para saber el nmero de mdulos asignados a cada trabajador. METRICAS DE BAJO NIVEL: Las mtricas de bajo nivel tambin llamadas mtricas de caja blanca son las que nos ayudan a conocer las interioridades del sistema. Hay tres tipos de mtricas de bajo nivel: De cohesin De acoplamiento De complejidad MTRICAS DEL DISEO ARQUITECTNICO. Se enfocan en caractersticas de la arquitectura del programa con nfasis en la estructura arquitectnica y en la efectividad de los mdulos o componentes dentro de la arquitectura. Dichas mtricas son caja negra en tanto no requieren conocimiento alguno del funcionamiento interior de un componente de software particular. Card y Glass definen tres medidas de complejidad del diseo de software: complejidad estructural, complejidad de datos y complejidad del sistema. MTRICAS PARA DISEO ORIENTADO A OBJETOS Whitmire describe nueve caractersticas distintas y mensurables de un diseo OO: Tamao. El tamao se define en funcin de poblacin, volumen, longitud y funcionalidad. Complejidad. Whitmire ve la complejidad en trminos de caractersticas estructurales al examinar cmo se relacionan mutuamente las clases de un diseo OO. Acoplamiento. Las conexiones fsicas entre elementos del diseo OO representan el acoplamiento dentro de un sistema OO. Suficiencia. Whitmire define suficiencia como el grado en el que una abstraccin posee las caractersticas requeridas de l o en el que un componente de diseo posee caractersticas en su abstraccin, desde el punto de vista de la aplicacin actual. Completitud. La nica diferencia entre completitud y suficiencia es el conjunto de caractersticas contra las cuales se compara la abstraccin o el componente de diseo. Cohesin. La cohesividad de una clase se determina al examinar el grado en el que el conjunto de propiedades que posee es parte del problema o dominio de diseo. Primitivismo. Una caracterstica que es similar a la simplicidad, es el grado en el que una operacin es atmica, es decir, la operacin no puede construirse a partir de una secuencia de otras operaciones contenidas dentro de una clase. Una clase que muestra un grado de primitivismo encapsula slo operaciones primitivas. Similitud. El grado en el que dos o ms clases son similares en trminos de su estructura, funcin, comportamiento o propsito se indica mediante esta medida. Volatilidad. La volatilidad de un componente de diseo OO mide la probabilidad de que ocurrir un cambio.

59

MTRICAS ORIENTADAS A LA CLASE. Las medidas y mtricas para una clase individual, la jerarqua de clase y las colaboraciones de clase sern invaluables cuando se requiera valorar la calidad del diseo OO. Chidamber y Kemerer propusieron uno de los conjuntos de mtricas de software OO, en ocasiones llamada suite de mtricas CK que incluyen 6 mtricas de diseo basadas en clase para sistemas OO: 1. Mtodos ponderados por clase (MPC) 2. Profundidad del rbol de herencia (PAH) 3. Nmero de hijos (NDH) 4. Acoplamiento entre clases de objetos (ACO) 5. Respuesta para una clase (RPC) 6. Falta de cohesin en mtodos (FCOM) 4.2.3 MTRICAS PARA CDIGO FUENTE La teora de Halstead de la ciencia del software, propuso las primeras leyes analticas para el software de computadora. Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el cdigo despus de completar el diseo. Las medidas son: n1: nmero de operadores diferentes que aparecen en el programa. n2: nmero de operandos diferentes que aparecen en el programa. N1: nmero total de veces que aparece el operador. N2: nmero total de veces que aparece el operando

4.2.4 MTRICAS PARA PRUEBAS La mayora de las mtricas para pruebas se concentran en el proceso de prueba, no en las caractersticas tcnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las mtricas de anlisis, diseo y cdigo para que sirvan de gua en el diseo y ejecucin de los casos de prueba. El esfuerzo de las pruebas tambin se puede estimar utilizando mtricas obtenidas de las medidas de Halstead. Usando la definicin del volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software puede calcularse como: NP = 1/ [(n1/2) x (N2/n2)] n1: no de operadores diferentes n2: no de operandos diferentes N2: no total de Operandos 4.2.5 MTRICAS PARA MANTENIMIENTO. IEEE Std. Sugiere un ndice de madurez de software (IMS) que proporcione un indicio de la estabilidad de un producto de software (con base en cambios que ocurran para cada liberacin del producto). Para ello, se determina la siguiente informacin:

MT= nmero de mdulos en la liberacin actual Fc= nmero de mdulos en la liberacin actual que cambiaron Fa = nmero de mdulos en la liberacin actual que se agregaron Fd = nmero de mdulos de la liberacin anterior que se borraron en la liberacin actual.
El ndice de madurez del software se calcula de la forma siguiente:

IMS = MT (Fa + Fc+ Fd) MT

Conforme el IMS tiende a 1.0, el producto comienza a estabilizarse. El IMS tambin puede usarse como una mtrica para planificar actividades de mantenimiento de software.

60

EJEMPLO
El siguiente ejercicio se basa en un sistema de facturacin. Aplicar mtricas orientadas a la funcin y al tamao.

Actividades observadas. 1. El cliente pide informacin sobre los productos 2. El vendedor da la informacin de los productos 3. El cliente realiza un pedido 4. El vendedor atiende el pedido 5. El vendedor llena el encabezado de la factura 1. Cada factura tiene un nmero impreso y el logo de la empresa 2. Llena el cdigo del vendedor 3. Selecciona el tipo de factura (crdito fiscal o consumidor final) 4. Llena los datos del cliente 1. Nombre 2. Direccin 3. Telfono 6. El vendedor llena el detalle de la factura 1. Cantidad del producto 2. Nombre del producto 3. Precio unitario del producto 4. Total producto 7. El vendedor suma los totales de los productos de la factura y lo escribe en el campo Sub-total 8. Se le aplica al Sub-total + el IVA y lo escribe en el campo Total 9. Se suma el Sub-total + el IVA y lo escribe en el campo Total 10. Se le entrega una factura al cliente para que la cancele 11. El cliente cancela la factura 12. Finalmente los productos son entregados al cliente.

DIAGRAMA ENTIDAD RELACIN:

61

Se obtienen 6 tablas normalizadas:

62

DIAGRAMA DE CASOS DE USO:

63

FACTIBILIDAD ECONMICA De la factibilidad econmica determinamos los costos directos e indirectos del nuevo sistema.

64

INVERSIN PERMANENTE CONCEPTO Inversin Inicial Recurso Humano. Analista Programador Tipo de Equipo Cantidad Hardware 2 Computadoras 1 Servidor 1 Impresora de red 1 Cable de red 1 Switch de 8 puertos Cantidad Software 2 Sistema Operativo Windows XP 2 Office 2010 4 Antivirus Nod 32 Cantidad Materiales 10 Resmas de Papel 500 hojas 3 Cartuchos de tinta Total Inversin Inicial

Precio/ Hora $10.00 $6.00

Proy. Horas/ao 120 120

Gasto Anual

$1,200.00 $ 720.00

$ 1,400.00 $ 900.00 $ 94.00 $ 7.00 $ 18.00 $ 1,000.00 $ 1,000.00 $ 120.00 $ 40.00 $ 500.00 $ 4,539.00 Total anualidad $2,460.00

FACTORES DE CORRECCIN (TABLA 5) Factor 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. total Comunicacin de los datos Proceso distribuido Objetivos de rendimiento Configuracin de produccin usada por otros Tasa de transacciones Entrada de datos en lnea Eficiencia con el usuario final Actualizacin en lnea Lgica de proceso interno compleja Reutilizacin de cdigo Contempla la conversin e instalacin Facilidad de operacin Instalaciones mltiples Facilidad de cambios de factores de correccin Puntuacin 3 1 4 2 3 4 4 4 3 2 3 4 2 3 42 65

MTRICAS ORIENTADAS AL TAMAO

(TABLA 6) Esfuerzo

Entorno y lenguaje Lenguajes de 2GL (Ensamblador) Lenguajes de 3GL (Cobol) Lenguajes de 4GL (Visual)

Lneas de cdigo por Punto de Funcin (LPF) 300 100 20

Horas por Punto Funcin (HPF) 20 - 30 10 - 20 5 - 10

de

EVALUACIN DEL TEMA

El Despacho Contable Arrisgate conmigo, desea crear un sistema para el control de clientes, que dispondr de la siguiente informacin. Aplicar las mtricas de puntos de funcin y orientadas al tamao.
Pantallas de entrada para: 1. capturar informacin del cliente (20 campos) 2. Detalle de factura (4 campos) Consulta y Reportes de: 1. Informacin del cliente (16 campos) 2. Factura (9 campos) 3. Datos del cliente que genera alrededor de 15 peticiones al usuario. El sistema consta de 5 tablas en el DER, 3 de ellas constan de 3 12 campos y el resto tienen ms de 21 campos; adems de estar conectado a un fax y una impresora (cada una genera de 4 a 17 registros). El sistema ser diseado en el lenguaje Visual Basic.Net. El proyecto ser desarrollado por un analista (salario $7 por hora), un programador (salario $5 por hora) y un diseador de base de datos (salario $8 por hora), quienes estarn trabajando 8 horas diarias. Se tiene una inversin inicial de $14,700 y una anualidad total de $12,300 para el proyecto. Se estiman 7 horas de esfuerzo por punto de funcin (HPF), 275 pginas por documento, 9 errores y 2 defectos. Calcular: Mtricas de Puntos de Funcin: 1. Tabla de valores y pesos y Puntos de funcin sin ajustar PFSA. 2. Puntos de funcin ajustados PFA. Mtricas orientadas al tamao: a. Lneas de cdigo para el sistema, Esfuerzo horas persona, Duracin del proyecto, Costo del proyecto, hacer la tabla. b. Productividad, calidad, documentacin, costo por lneas de cdigo. Se tomarn las tablas 5 y 6 como informacin por defecto.

BIBLIOGRAFA
Ingeniera de software. Un enfoque prctico. Roger S. Pressman - V Edicin. Blanchard, B.S., System Engineering Management 2.da. 1997.

66

UNIDAD DIDCTICA II. INGENIERA DEL SOFTWARE ORIENTADA A OBJETOS

INTRODUCCIN9.
Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser clasificados, descritos, organizados, combinados, manipulados y creados. Por eso no es sorprendente que se proponga una visin orientada a objetos para la creacin de software de computadora, una abstraccin que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los aos sesenta. Sin embargo, las tecnologas de objetos han necesitado casi veinte aos para llegar a ser ampliamente usadas. Durante los aos 90, la ingeniera del software orientada a objetos se convirti en el paradigma de eleccin para muchos productores de software y para un creciente nmero de sistemas de informacin y profesionales de la ingeniera. El anlisis orientado a objetos y su diseo se enfoca en los objetos. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactan y funcionan. No se intenta proporcionar un orden para las acciones al momento del diseo debido a que los objetos funcionan basados en la manera en que funcionan otros objetos. La programacin orientada a objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real. El enfoque orientado a objetos permite que los objetos estn auto contenidos. Los objetos existen por s mismos, con una funcionalidad para invocar comportamientos de otros objetos. Al utilizar un enfoque orientado a objetos, los desarrolladores pueden crear aplicaciones que reflejan objetos del mundo real, como rectngulos, elipses y tringulos, adems de dinero, nmeros de partes y elementos en un inventario. En la presente unidad, estudiaremos el anlisis y el diseo orientado a objetos; as como las pruebas y mtricas que se aplican a dicha metodologa.

RESULTADOS DE APRENDIZAJE:
Crear un plan de pruebas al diseo en base a estrategias tcnicas del software y a criterios especficos de diseo. Realizar pruebas y documentarlas a fin de cumplir con las necesidades y expectativas del cliente. Modelar el anlisis del sistema segn la estructura del diseo lgico planteado. Disear el sistema a partir del modelado del anlisis creado.

Tomado de http://www.solotuweb.com/fs~id~6195.html. Autor: ArbisPercy Reyes Paredes

67

SECUENCIA DE APRENDIZAJE PARA LA UNIDAD II:

UNIDAD 2: INGENIERA DE SOFTWARE ORIENTADA A OBJETOS

TEMA 1: ANLISIS ORIENTADO A OBJETOS 1.1 Conceptos y principios orientados a objetos 1.2 El anlisis orientado a objetos: Dominio y componentes 1.3 El proceso del anlisis orientado a objetos

TEMA 2: DISEO ORIENTADO A OBJETOS 2.1 Modelos, procesos y patrones del diseo orientado a objetos 2.2 Programacin orientada a objetos

2.3 Diseo en el nivel de componentes

TEMA 3: TCNICAS Y ESTRATEGIAS DE PRUEBAS DEL SOFTWARE

3.1 Fundamentos y tipos de Pruebas realizadas al software

3.2 Estrategias de prueba para software

68

CONTENIDOS DE LA UNIDAD:

1.

ANLISIS ORIENTADO A OBJETOS 1.1 Conceptos y principios orientados a objetos 1.2 El anlisis orientado a objetos: dominio y componentes 1.3 El proceso del anlisis orientado a objetos

2.

DISEO ORIENTADO A OBJETOS 2.1 Modelos, procesos y patrones del diseo orientado a objetos 2.2 Programacin orientada a objetos 2.3 Diseo a nivel de componentes

3.

TCNICAS Y ESTRATEGIAS DE PRUEBAS ORIENTADAS A OBJETOS 3.1 Fundamentos y tipos de pruebas realizadas al software 3.2 Estrategias de prueba para software 3.3 Visiones interna y externa de las pruebas

69

TEMA 1. ANLISIS ORIENTADO A OBJETOS

1.1

CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS 10

ANLISIS ORIENTADO A OBJETOS (AOO): [Booch 94] Es un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. La orientacin a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan software que facilitan la construccin de sistemas complejos a partir de componentes. En el contexto del desarrollo de sistemas de software con orientacin a objetos, se entiende por Anlisis Orientado a Objetos al proceso de construccin de modelos del dominio del problema, identificando y especificando un conjunto de objetos semnticos que interactan y se comportan de acuerdo a los requerimientos del sistema. Los objetos semnticos son aquellos que poseen un significado especfico en el dominio del problema, segn [Monarchi&Puhr92].

ACTIVIDAD PARA EL ESTUDIANTE:

Escribe en los espacios en blanco, los conceptos que existen en el modelado Orientado a Objetos para recordar lo que estudiamos en el mdulo anterior.
1. Qu es una clase? ____________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 2. Qu es un objeto?____________________________________________________________ ___________________________________________________________________________ 3. Qu son atributos?___________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 4. Qu son mtodos?____________________________________________________________ ___________________________________________________________________________ 5. Para qu sirven los casos de uso?_______________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ DOCUMENTOS BSICOS DEL ANLISIS ORIENTADO A OBJETOS Documentos de anlisis. Contiene la documentacin que aporta el cliente que encarga la aplicacin. Tambin contiene las actas de las reuniones de trabajo del grupo de anlisis. Especificacin de requisitos o requerimientos. La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difciles, lo que se debe construir. La captura de requisitos es complicada pues a veces los usuarios no explican bien lo que quieren, o por ser difcil tener una visin global del problema a resolver. Diagramas de casos de uso. Es uno de los 5 tipos de diagramas UML que se utilizan para el modelado de los aspectos dinmicos de un sistema. Estos representan una vista externa del

10

Tomado de http://www.solotuweb.com/fs~id~6195.html.

70

sistema. Un modelo de casos de uso se construye mediante un proceso iterativo durante las reuniones entre los desarrolladores del sistema y los clientes, conduciendo a una especificacin de requisitos sobre la que todos coinciden. Escenarios y subescenarios. Cada caso de uso da lugar a mltiples escenarios. Se codifican siguiendo la codificacin de los casos de uso. Se estudia cada escenario utilizando guiones como los que usan en el cine. Cada equipo que pasa por un escenario identifica los objetos y sus responsabilidades, as como los mecanismos que relacionan los objetos. Prototipos y su evaluacin. El prototipado consiste en la elaboracin de un modelo o maqueta que se construye para evaluar mejor los requisitos que se desea que cumpla. Estos modelos o prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas (que no son totalmente operativos) de la aplicacin pedida.

PRINCIPIOS DEL ANLISIS ORIENTADO A OBJETOS11 Al examinar el dominio de la informacin, se emplean modelos para poder comunicar de forma compacta las caractersticas de la funcin y su comportamiento. El anlisis orientado a objetos se basa en un conjunto de principios bsicos para construir un modelo de anlisis: 1. 2. 3. 4. 5. Se modela el dominio de la informacin Se describe la funcin Se representa el comportamiento del modelo Los modelos de datos, funcional y de comportamiento se dividen para mostrar ms detalles Los modelos iniciales representan la esencia del problema mientras que los ltimos aportan detalles de la implementacin.

1.2

EL ANLISIS ORIENTADO A OBJETOS

En el anlisis orientado a objetos se desarrollan una serie de modelos que describen el software de computadora a trabajar, para satisfacer un conjunto requisitos definidos por el cliente. El modelo del anlisis orientado a objetos ilustra informacin, funcionamiento y comportamiento. El propsito del AOO es definir todas las clases que son relevantes al problema que se va a resolver, las operaciones y atributos asociados, las relaciones y comportamientos asociadas con ellas. Para cumplirlo se deben ejecutar las siguientes tareas: 1. Los requisitos bsicos del usuario deben comunicarse entre el cliente y el ingeniero del software. 2. Identificar las clases (es decir, definir atributos y mtodos). 3. Se debe especificar una jerarqua de clases. 4. Representan las relaciones objeto a objeto (conexiones de objetos). 5. Modelar el comportamiento del objeto. 6. Repetir iterativamente las tareas de la 1 a la 5 hasta completar el modelo.

11

Tomado de Ingeniera del Software. Un enfoque prctico. Roger Pressman. 5. Edicin.

71

INVESTIGACIN INDIVIDUAL
Investiga y explica lo siguiente: Es el anlisis orientado a objetos realmente diferente del enfoque del anlisis estructurado? Realiza una comparacin entre ambos enfoques.

1.2.1 ANLISIS DEL DOMINIO ORIENTADO A OBJETOS.

Como crear el modelo del dominio El modelo del dominio es un documento donde captura todo lo que sabe acerca del dominio. Dominio: El campo comercial en el que se est trabajando Como parte del modelo de dominio, debe crear objetos que describan a todos los objetos mencionados en los casos de uso. NO CONFUNDIR LOS OBJETOS DE DOMINIO CON OBJETOS DE DISEO. El anlisis del dominio del software es la identificacin, anlisis y especificacin de los requerimientos comunes, a partir de un dominio de aplicacin especfica, normalmente para usarlo varias veces en mltiples proyectos dentro del dominio de la aplicacin. El anlisis del dominio orientado a objetos es la identificacin, anlisis y especificacin de capacidades comunes y reutilizables dentro de un dominio de aplicacin especfica en trminos de objetos, clases, subensambles y estructuras comunes. El dominio contiene tres visiones diferentes de los datos y del control a medida que se procesa cada uno en un programa de computadora: 1. Contenido de la informacin y relaciones 2. Flujo de la informacin y 3. Estructura de la informacin. El contenido de la informacin representa los objetos individuales de datos y de control que componen alguna coleccin mayor de informacin a la que transforma el software. El flujo de la informacin representa cmo cambian los datos y el control a medida que se mueven dentro de un sistema. La estructura de la informacin representa la organizacin interna de los elementos de datos o de control. El objetivo del anlisis del dominio es definir el conjunto de clases (objetos) que se encuentran en el dominio de la aplicacin. Dichas clases podrn reutilizarse muchas veces. La reutilizacin es la piedra angular de la ingeniera del software basada en componentes. El dominio del problema consta de:

Anlisis esttico (Modelos conceptuales) Anlisis dinmico (casos de uso) Diseo preliminar de interfaces (Web, GUI, Comandos, voz)

1.2.2 COMPONENTES DEL ANLISIS ORIENTADO A OBJETOS.

Monarchi y Puhr definen un conjunto de componentes de representacin genricos que aparecen en todos los modelos de anlisis OO. Estos pueden ser estticos o dinmicos. Los componentes estticos son estructurales por naturaleza, e indican caractersticas que se mantienen durante toda la vida operativa de una aplicacin. Los componentes dinmicos se centran en el control, y son sensibles al tiempo y al tratamiento de sucesos. La siguiente figura muestra la relacin entre los componentes:

72

1. Se hace una vista esttica de las clases donde se imponen los requisitos y se extraen las clases como parte del modelo

2. La vista esttica de los atributos donde se explican todos los atributos asociados con las clases.

3. La vista esttica de relaciones donde se ve como estn conectados los objetos

4. La vista de comportamiento donde se define el conjunto de comportamientos adaptado al escenario (caso de uso) a travs de la definicin de una secuencia de operaciones que ejecuta.

5. La vista dinmica de la comunicacin de unos objetos a otros

6. El control dinmico y manejo de tiempo de la duracin de los eventos que provocan cambios de estado

ACTIVIDAD PARA EL ESTUDIANTE:

Investigue y explique las diferentes vistas en los componentes del anlisis OO. Elaborar un resumen en hojas de papel bond.

Vista esttica de los atributos Vista esttica de las relaciones Vista esttica de los comportamientos Vista dinmica de la comunicacin Vista dinmica del control y manejo del tiempo

1.3 MODELO Y EL PROCESO DEL ANLISIS ORIENTADO A OBJETOS.

1.3.1 MODELO DEL ANLISIS ORIENTADO A OBJETOS. La popularidad de las tecnologas de objetos ha generado varios mtodos de AOO desde finales de los 80 y durante los 90. Cada uno de ellos introduce un proceso para el anlisis de un producto o sistema, un conjunto de modelos que evoluciona fuera del proceso y una notacin que posibilita al ingeniero del software crear cada modelo de una manera consistente. Entre los ms ampliamente utilizados se encuentran (se aplican tanto para el anlisis como para el diseo):

73

El El El El El

mtodo mtodo mtodo mtodo mtodo

de Booch. de Rumbaugh. Jacobson de Coad y Yourdon. de Wirfs-Brock.

ACTIVIDAD EN EQUIPO: Formar 5 equipos e investigar cada uno de los mtodos anteriores. Preparar una exposicin y un documento de investigacin explicando cada uno, segn se le haya asignado.
Estos mtodos se basan en ciertos modelos. Segn Coad y Yourdon, el anlisis orientado a objetos est basado en un modelo de cinco capas12: 1. 2. 3. 4. 5. Capa Capa Capa Capa Capa clase/objeto. de estructura. de atributos. de servicios de tema.

Podemos visualizar el proceso completo de anlisis y diseo como formando el desarrollo y ensamble de estas cinco capas en un paquete de diseo laminado. La figura ilustra cmo se entrelazan estas cinco capas. 1. Capa Clase/Objeto. Esta capa indica la clase y objetos. 2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos, tales como las relaciones uno a muchos y la herencia. Se identifican dos estructuras completamente distintas: Estructuras de clasificacin Estructuras de composicin 3. Capa de Atributos. Esta capa detalla los atributos de las clases. Se especifican las relaciones de modalidad y multiplicidad. 4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto (servicios y mtodos). 5. Capa de Tema. Esta capa divide el diseo en unidades de implementacin o asignaciones de equipos. Son de tamao tratable en cuanto contendrn solo entre aproximadamente 5 y 9 objetos.

12

Tomado de Anlisis y Diseo de Sistemas. Kendall & Kendall. Tercera Edicin.

74

Hay 5 tipos generales de objetos que pueden descubrirse durante el anlisis. Los objetos a veces representan cosas tangibles como vehculos, dispositivos y libros. Algunas veces los objetos representan papeles actuados por personas u organizaciones. Los papeles incluyen objetos como cliente, propietario o departamento. Los objetos tambin pueden ser derivados de incidentes o eventos, tales como vuelo, accidente o reunin. Los incidentes suceden tpicamente en un momento especfico. Otros objetos pueden indicar interacciones tales como una venta o un matrimonio. Las interacciones tienen una cualidad de transaccin o contrato. Cuando una clase aparece sin objetos, puede ser solamente una clase base, debido a que la nica razn para tal clase sin objetos es que sea un medio para agrupar atributos y servicios que sern heredados por varias otras clases. 1.3.2 PROCESO DEL ANLISIS ORIENTADO A OBJETOS El proceso comienza con la distincin de los objetos es decir cmo se va a usar el sistema, cmo de desenvuelve con otros procesos y programas y, si coordina o controla otras aplicaciones. De all comienza el modelado de software usando diferentes tcnicas: Caso de uso Modelado de clases Definicin de estructuras jerrquicas Definicin de temas y subsistemas

Tambin se hace el modelado de clase-responsabilidad-colaborador donde las clases se definen con su documentacin atributos y operaciones y las colaboraciones entre ellas. Luego se hace el modelo objeto relacin para relacionar las clases entre ellas. Posterior a esto se hace el modelo objeto comportamiento donde se representan los comportamientos individuales y globales.

EVALUACIN DEL TEMA

I PARTE. Investiga y contesta las siguientes preguntas.
1. Segn Coad y Yourdon, el anlisis orientado a objetos est basado en un modelo de cinco capas, que son: _____________________________ , ________________________________ , _____________________________ , ________________________________, _____________________________ 2. El mtodo OMT fue desarrollado por: ______________________ y sus siglas significan:

_______________________________________________________. 3. El mtodo OOSE fue desarrollado por: ___________________________ y sus siglas significan:

_______________________________________________________.

75

4.

El mtodo OOD fue desarrollado por: ___________________________ y sus siglas significan:

_______________________________________________________. 5. Combina las tcnicas del modelado de datos (DER), modelado de negocios (Worksflow), modelado de objetos y modelado de componentes: _________________________________________

II. PARTE. PARA DESARROLLAR EN EQUIPO. Formar 4 equipos de trabajo y cada uno investigar un modelo. Luego elaborarn un resumen incluyendo ejemplos. Luego expondrn al pleno y proporcionarn el documento en digital para sus compaeros.

76

TEMA 2 DISEO ORIENTADO A OBJETOS

El diseo Orientado a Objetos (DOO) difiere considerablemente del diseo estructurado ya que en DOO no se realiza un problema en trminos de tareas (subrutinas) ni en trminos de datos, sino que se analiza el problema como un sistema de objetos que interactan entre s. Un problema desarrollado con tcnicas orientadas a objetos requiere, en primer lugar saber cules son los objetos del programa. Como tales objetos son instancias de clases, la primera etapa en el desarrollo orientado a objetos requiere de la identificacin de dichas clases (atributos y comportamiento), as como las relaciones entre stas y su posterior implementacin en un lenguaje de programacin. Aunque no siempre estn bien delimitadas las etapas de anlisis y diseo en la OO, se pueden sintetizar de alguna forma las ideas claves de las distintas tecnologas existentes dentro del desarrollo orientado a objetos al que denominaremos diseo. En el diseo orientado a objetos, los objetos necesitan interactuar y comunicarse, para realizar dicha comunicacin, los objetos utilizan su propia interfaz pblica, dicha interfaz se compone principalmente de mtodos y propiedades. El diseo orientado a objetos transforma el modelo del anlisis en un modelo de diseo que sirve como anteproyecto para la construccin de software. Caractersticas principales del Diseo Orientado a Objetos: Los objetos son abstracciones del mundo real o entidades del sistema que se administran entre ellas mismas. Los objetos son independientes y encapsulan el estado y la representacin de informacin. La funcionalidad del sistema se expresa en trminos de servicios de los objetos. Las reas de datos compartidas son eliminadas. Los objetos se comunican mediante paso de parmetros. Los objetos pueden estar distribuidos y pueden ejecutarse en forma secuencial o en paralelo Ventajas del Diseo Orientado a Objetos:

Fcil de mantener, los objetos representan entidades auto-contenidas Los objetos son componentes reutilizables Para algunos sistemas, puede haber un mapeo obvio entre las entidades del mundo real y los objetos del sistema

Componentes del Diseo Orientado a Objetos

La identificacin de objetos, sus atributos y servicios La organizacin de objetos dentro de una jerarqua La construccin de descripciones dinmicas de objetos que muestran como se usan los servicios La especificacin de interfaces de objetos

77

2.1 MODELOS, PROCESOS Y PATRONES DEL DISEO ORIENTADO A OBJETOS. 2.1.1 MODELO DEL DISEO ORIENTADO A OBJETOS. El modelo del diseo puede verse en dos dimensiones distintas, como se ilustra en la figura. La dimensin del proceso indica la evolucin del modelo del diseo conforme se ejecutan las tareas de ste como parte del proceso del software. La dimensin de la abstraccin representa el nivel de detalle a medida que cada elemento del modelo de anlisis se transforma en un equivalente de diseo y luego se mejora en forma iterativa.

En la figura, la lnea punteada indica la frontera entre los modelos de anlisis y de diseo. En ciertos casos, es posible hacer una distincin clara entre ambos modelos. En otros, el modelo de anlisis se mezcla poco a poco con el de diseo y la distincin es menos obvia. Los modelos del diseo pueden ser estticos y dinmicos. Estticos: estructura de subsistemas y/o clases, y sus relaciones. Se describe la estructura esttica (de datos), de los objetos del sistema (identidad, atributos y operaciones) y tambin sus relaciones. El modelo de objetos contiene diagramas de objetos. Un diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones entre las clases. El diagrama contiene clases de objetos organizados en jerarquas que comparten una estructura y comportamiento comunes y que estn asociadas a otras clases. Estas clases definen los

78

atributos que lleva cada instancia de objeto y las operaciones que efecta o sufre cada uno. En cada instancia de la clase se guardan los valores de esos atributos. Dinmicos: Se describen las estructuras que muestran la interaccin entre objetos. Ejemplos de UML: diagramas de secuencia, diagramas de estado. Describe los aspectos de comportamiento (de control) de un sistema que cambian con el tiempo. El modelo dinmico se utiliza para especificar e implementar los aspectos del control del sistema. Los modelos dinmicos contienen diagramas de estados. Un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por sucesos o eventos. Se especifican en este modelo la temporizacin y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos), y la organizacin de sucesos y de estados. El modelo dinmico captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en la que estn implementadas. Las acciones de los diagramas de estado se corresponden con funciones procedentes del modelo funcional; los sucesos de un diagrama de estado pasan a ser operaciones que se aplican a objetos dentro del modelo de objetos.

EJERCICIOS PRCTICOS
Con su equipo de trabajo de proyecto, retomen el diagrama de clases, de objetos y de secuencia que elaboraron en el mdulo anterior y hagan las modificaciones necesarias para que los diagramas queden bien elaborados.

DIAGRAMAS DE ESTADOS.
Los diagramas de estado son una tcnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a l. En la mayor parte de las tcnicas Orientadas a Objetos, los diagramas de estado se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida. Dentro de la notacin se utilizan los siguientes smbolos:

79

De los cuales los ms utilizados son: Estado Identifica un periodo de tiempo del objeto (no instantneo) en el cual el objeto est esperando alguna operacin, tiene cierto estado caracterstico o puede recibir cierto tipo de estmulos. Se representa mediante un rectngulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor caracterstico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente). Eventos Es una ocurrencia que puede causar la transicin de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas:

Condicin que toma el valor de verdadero o falso Recepcin de una seal de otro objeto en el modelo Recepcin de un mensaje Paso de cierto perodo de tiempo, despus de entrar al estado o de cierta hora y fecha particular

El nombre de un evento tiene alcance dentro del paquete en el cual est definido, no es local a la clase que lo nombre. Envo de mensajes Adems de mostrar la transicin de estados por medio de eventos, puede representarse el momento en el cual se envan mensajes a otros objetos. Esto se realiza mediante una lnea punteada dirigida al diagrama de estados del objeto receptor del mensaje.

80

Transicin simple Una transicin simple es una relacin entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se representa como una lnea slida entre dos estados, que puede venir acompaada de un texto con el siguiente formato: event-signature "[" guard-condition] "/" action-expression "^"send-clause event-signature es la descripcin del evento que da lugar la transicin, guard-condition son las condiciones adicionales al evento necesarias para que la transicin ocurra, action-expression es un mensaje al objeto o a otro objeto que se ejecuta como resultado de la transicin y el cambio de estado y send-clause son acciones adicionales que se ejecutan con el cambio de estado, por ejemplo, el envo de eventos a otros paquetes o clases. Transicin interna Es una transicin que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado. Acciones: Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transicin. Se puede especificar el ejecutar una accin como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento. Generalizacin de Estados:

Podemos reducir la complejidad de estos diagramas usando la generalizacin de estados. Distinguimos as entre superestado y subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las transiciones externas. La agregacin de estados es la composicin de un estado a partir de varios estados independientes.

La composicin es concurrente por lo que el objeto estar en alguno de los estados de cada uno de los subestados concurrentes. La destruccin de un objeto es efectiva cuando el flujo de control del autmata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto. Subestados Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. Transicin Compleja Una transicin compleja relaciona tres o ms estados en una transicin de mltiples fuentes y/o mltiples destinos. Representa la subdivisin en threads del control del objeto o una sincronizacin. Se representa como una lnea vertical de la cual salen o entran varias lneas de transicin de estado.

81

Transicin a estados anidados Una transicin hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad). Transiciones temporizadas

Las esperas son actividades que tienen asociada cierta duracin. La actividad de espera se interrumpe cuando el evento esperado tiene lugar.

Este evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado.

ACTIVIDAD DE INVESTIGACIN EN EQUIPO.

Elaborar investigacin en equipos de 3 integrantes, presentar un reporte y luego pasar a exponer lo siguiente: Cundo utilizar los Diagramas de Estado? Qu son los Diagramas de estados concurrentes? Realizar un ejemplo aplicando un Diagrama de estado concurrente.

EJEMPLO:
En el siguiente ejemplo se muestra un diagrama de estados de UML para un pedido del sistema de procesos de pedidos. El diagrama indica los diversos estados de un pedido. Comenzaremos en el punto de partida y mostramos una transicin inicial al estado de Comprobacin. Esta transicin esta etiquetada como obtener el primer artculo. La sintaxis de una etiqueta de transicin tiene tres partes, las cuales son optativas: Evento [Guard guardia] Accin. En este caso solo tenemos la accin obtiene primer artculo Una vez realizada tal accin, entramos al estado de comprobacin. Este estado tiene una actividad asociada con l, la cual se indica mediante una etiqueta con la sintaxis hace/actividad. En este caso, la actividad se llama comprueba articulo.

82

Ntese que se utilizan los trminos accin para indicar la transicin, y actividad para indicar el estado. Aunque son procesos, implementados caractersticamente mediante algn mtodo sobre Pedido, se tratan de manera diferente. Las acciones se asocian con las transiciones y se consideran como procesos que suceden con rapidez y no son interrumpibles. Las actividades se asocian con los estados y pueden tardar ms. Una actividad puede ser interrumpida por algn evento. Advirtase que la definicin de rpidamente depende del tipo de sistema que se es ta produciendo. En un sistema de tiempo real, rpidamente puede significar unas pocas lneas de cdigo de m quina; en los sistemas de informacin normales, rpidamente puede significar menos de unos cuantos segundos. Cuando una transicin no tiene evento alguno en su etiqueta, significa que la transicin se da tan pronto como se completa cualquier actividad asociada con el estado dado. En este caso, ello significa tan pronto termine la Comprobacin. Del estado Comprobacin se derivan tres transiciones. Las tres solo tienen guardias en su etiqueta. Un guardia es una condicin lgica que solo devuelve verdadero o falso Una transicin de guardia ocurre solo si el guardia se resuelve como verdadero. Solo se puede tomar una transicin de un estado dato, por lo que tratamos de que los guardias sean mutuamente excluyentes para cualquier evento. En la figura 1 abarcamos tres condiciones: 1. Si no hemos comprobado todos los artculos, tomamos el siguiente artculo y regresamos al estado de comprobacin para comprobarlo. 2. Si hemos comprobado todos los artculos y todos estn en existencia, hacemos la transicin al estado de Despachando. 3. Si hemos comprobado todos los artculos pero no todos estn en existencia, hacemos la transicin al estado espera.

83

Veamos, en primer lugar, el estado Espera. Como no hay actividades para este estado, el pedido se detiene en el esperando un evento, ambas transiciones del estado espera se etiquetan con el evento Articulo recibido. Esto significa que el pedido espera hasta que detecta este evento. Llegado ese momento, evala los guardias de las transiciones y hace la transicin apropiada. Dentro del estado despachando, tenemos actividad que inicia una entrega. Tambin hay una transicin simple no guardada, disparada por el evento Entregado. Esto significa que la transicin ocurrir siempre que tenga lugar el evento. Sin embargo, ntese que la transicin no sucede cuando termina la actividad; por el contrario, una vez terminada la actividad iniciar entrega, el pedido se mantiene en el estado Despachando, hasta que ocurre el evento Entregado La ltima cuestin a considerar es la transicin denominada cancelado. Queremos tener la posibilidad de cancelar un pedido en cualquier momento, antes de que sea entregado. Podramos hacerlo dibujando transiciones separadas desde cada uno de los estados, Comprobacin, Espera y Despachando. Una alternativa til es crear un Superestado con los tres estados, y despus dibujar una transicin simple, a partir de l. Los subestados simplemente heredan todas las transiciones sobre el superestado.

84

EJERCICIOS PRCTICOS

1. Realizar un diagrama de estado para la implementacin de un Sistema Clnico, en el cual se efecta la administracin de pacientes y citas; se llevan a cabo los siguientes procesos: Administrar la informacin de cada mdico de la clnica y personal administrativo que utiliza el sistema. Administrar el expediente del paciente Agregar pacientes, actualizar datos del historial clnico de los pacientes, borrar, revisar historial mdico, implementar bsquedas avanzadas, etc. Realizar la asignacin y control de citas para pacientes Gestionar consultorios y horario de los mdicos Ms opciones que el grupo de trabajo determine.

2. Elaborar un diagrama de estado para la implementacin de un Sistema Bancario en el cual se realizan procesos de ahorro y prstamos a sus clientes y se efectan de la siguiente forma: Administrar cuentas de ahorro y prstamos bancarios (Apertura, cierre, modificaciones, eliminaciones, bsquedas, abonos, retiros, etc.) Aplicar condiciones al momento de adquirir prstamos o por la apertura de una cuenta de ahorros en el sistema. Manejar la informacin del cliente y de su cuenta o deuda adquirida con la empresa bancaria.

85

2.1.2

Aplicar tasas de inters a prstamos por periodos o plazos especficos Llevar un control de abonos y retiros para cuentas de ahorro y prstamo. Realizar cargos por mora sobre el pago de prestamos Ms opciones que el grupo de trabajo determine. PROCESO DEL DISEO ORIENTADO A OBJETOS

El diseo de software es un proceso iterativo por medio del cual se traducen los requerimientos en un plano para construir el software. Al principio, el plano ilustra una visin holstica del software. Es decir, el diseo se representa en un nivel alto de abstraccin, en el que se rastrea directamente el objetivo especfico del sistema y los requerimientos ms detallados de datos, funcionamiento y comportamiento. A medida que tienen lugar las iteraciones del diseo, las mejoras posteriores conducen a niveles menores de abstraccin.

Lineamientos y atributos de la calidad del software.

El diseo es importante porque permite que un equipo de software evale la calidad de ste antes de que se implemente, momento en el que es fcil y barato corregir errores, omisiones o inconsistencias. Durante el diseo, la calidad se evala por medio de la realizacin de una serie de revisiones tcnicas. Una revisin tcnica es una reunin celebrada por miembros del equipo de software. Por lo general, participan dos, tres o cuatro personas, en funcin del alcance de la informacin del diseo que se revisar. Lineamientos para el diseo: 1. Debe tener una arquitectura que a) se haya creado con el empleo de estilos o patrones arquitectnicos reconocibles, b) est compuesta de componentes con buenas caractersticas de diseo y c) se implementen en forma evolutiva de modo que faciliten la implementacin y las pruebas. 2. Debe ser modular, es decir, el software debe estar dividido de manera lgica en elementos o subsistemas. 3. Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes. 4. Debe conducir a estructuras de datos apropiadas para las clases que se van a implementar y que surjan de patrones reconocibles de datos. 5. Debe llevar a componentes que tengan caractersticas funcionales independientes. 6. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes y el ambiente externo. 7. Debe obtenerse con el empleo de un mtodo repetible motivado por la informacin obtenida durante el anlisis de los requerimientos del software. 8. Debe representarse con una notacin que comunique con eficacia su significado.

INVESTIGUE Y COMPLETE
Hewlett-Packard desarroll un conjunto de atributos de la calidad del software a los que se dio el acrnimo de FURPS. Investigue qu significan las siglas y explique en su cuaderno de trabajo.

86

2.1.3

PATRONES DEL DISEO ORIENTADO A OBJETOS

Son soluciones simples y elegantes a problemas especficos y comunes del diseo orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan. Un patrn es una descripcin del problema y la esencia de su solucin, que se puede reutilizar en casos distintos. Est claro que un equipo de desarrollo no se limita a aplicar los principios del diseo orientado a objetos una vez tras otra, lo ms seguro es que se aprovechen de las soluciones aplicadas en el pasado para resolver los problemas del presente. La solucin a algunos problemas del desarrollo viene en forma de bloques de cdigo y de esqueletos de una solucin, a estos bloques de cdigo se les conoce como patrones. Podramos definir un patrn de la siguiente manera: Un patrn describe un problema que ocurre de forma iterativa en nuestro entorno, tambin describe la solucin a dicho problema de tal forma que podemos usar la misma solucin todas las veces que sea necesario. Tipos de patrones: Estructurales De creacin De comportamiento Los patrones de diseo son un conjunto de prcticas de ptimo diseo que se utilizan para abordar problemas recurrentes en la programacin orientada a objetos. Objetivos de los patrones Los patrones de diseo pretenden:

Proporcionar catlogos de elementos reusables en el diseo de sistemas software. Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente.

Asimismo, no pretenden:

Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo.

En General un patrn tiene cuatro elementos esenciales: 1. El nombre del patrn: permite describir en una o dos palabras, un problema de diseo junto con sus soluciones y consecuencias. 2. El Problema describe cuando aplicar el patrn. Explica el problema y su contexto. A veces el problema incluye una serie de condiciones que deben darse para que tenga sentido aplicar el patrn. 3. La Solucin describe los elementos que constituyen el diseo, sus relaciones, responsabilidades y colaboraciones. La solucin no describe un diseo o implementacin en concreto, sino que un patrn es ms bien como una plantilla que puede aplicarse en muchas situaciones diferentes.

87

4. Las Consecuencias son los resultados as como las ventajas e inconvenientes de aplicar el patrn. Estas son fundamentales para evaluar las alternativas de diseo y conocer los costos y beneficios de aplicar el patrn. Uso de patrones en el diseo Los patrones de diseo pueden usarse aplicando mecanismos diferentes: herencia y composicin. La composicin de objetos debe ser favorecida por encima de la herencia cuando existen ambas opciones. Antes de crear grandes e inmanejables jerarquas de clases (la consecuencia del sobreuso de la herencia), la composicin favorece pequeas jerarquas de clases y objetos que permanecen centrados en un objetivo. La composicin usa patrones de diseo existentes de forma inalterada. En ingeniera de software, disponemos de 3 familias de patrones:

Patrones de refactorizacin Para trabajar con patrones de diseo debemos identificar el problema y aplicar el patrn que nos da la solucin, nunca debemos aplicarlos a un problema cuya descripcin no coincide exactamente con la definicin del patrn. Un patrn de diseo puede considerarse como un documento que define una estructura de clases que aborda una situacin particular. Los patrones de diseo se dividen en tres grupos principales:

Patrones de diseo Patrones de arquitectura

Patrones de creacin: Los patrones de creacin proporcionan ayuda a la hora de crear objetos, principalmente cuando esta creacin requiere tomar decisiones. La toma de decisiones utilizando patrones puede ser dinmica. Estos patrones ayudan a estructurar y encapsular estas decisiones. En algunas ocasiones existe ms de un patrn que se puede aplicar a la misma situacin. En otras ocasiones se pueden combinar mltiples patrones convenientemente. Algunos de los patrones de creacin ms utilizados son los siguientes: Patrn de Fbrica Abstracta, Patrn Constructor, Patrn del Mtodo de Fabricacin, Patrn Prototipo, Patrn de Instancia nica (Singleton). Ejemplo de Patrn de Fbrica (Factory Pattern):

88

Patrones estructurales: Los patrones estructurales describen como los objetos y las clases pueden ser combinados para formar estructuras ms grandes, es decir, proporcionan los mecanismos para este hecho. La diferencia entre el modelo de clases y el modelo de objetos es que las clases desarrollan la abstraccin con la ayuda de la herencia y como estos pueden ser ms utilizados para proporcionar ms utilidad al programa de interfaz. Por otro lado los patrones estructurales describen como los objetos pueden ser asociados y combinados para formar estructuras ms grandes y ms complejas. Algunos de los patrones estructurales ms utilizados son los siguientes: Patrn Adaptador, Patrn Puente, Patrn Compuesto, Patrn Decorador, Patrn de Fachada, Patrn de Peso Mosca, Patrn Apoderado.

Patrones funcionales: Los patrones funcionales tratan especficamente la comunicacin entre los objetos. Patrn de Cadena de Responsabilidad, Patrn de Comando, Patrn Intrprete, Patrn Iterador, Patrn Mediador, Patrn Memento, Patrn Observador, Patrn de Estado, Patrn de Estrategia, Patrn del Mtodo Plantilla, Patrn Visitante.

Patrn de diseo Prototipo: Prototype

El patrn Prototype es un patrn de diseo creacional en el que los objetos se crean a partir de una instancia prototpica, que es clonada para dar lugar a nuevos objetos. Este patrn se usa en los siguientes casos:

Para evitar las subclases de un objeto creador como hace el patrn Abstract Factory. Para evitar el costo inherente a la creacin de un objeto nuevo mediante el operador new cuando esto demasiado costoso para la aplicacin.

Estructura

Para implementar este patrn, se declara una clase base abstracta que tiene un mtodo clone(). Cualquier clase que necesite un constructor deriva de la clase abstracta e implementa el mtodo clone(). El cliente, en vez de escribir codigo que hace uso del operador new sobre una clase especfica, llama al mtodo clone() de la clase prototipo, o llama a un mtodo factora con un parmetro que especifica la clase deseada, o invoca el mtodo clone() de la clase de alguna otra forma.

Ejemplo: 89

Public class Copiame implements Cloneable { Object clone =null; try{ clone=super.clone( ); } catch (CloneNotSupportedException e) { e.printStackTrace( ); } return clone;

}
En el ejemplo Clonable es una interfaz vaca, hace una copia de los valores de los campos de un objeto, no de los objetos a los que apunta. En otras palabras, el objeto clonado apuntar a los mismos objetos que el objeto antiguo apuntaba. Otra cosa a tomar en cuenta es que clone() devuelve siempre un Object. Tambin notemos que clone es un mtodo protected que puede ser llamado solo por la misma clase o el paquete que la contiene. Para qu nos sirve clonar objetos? Nos sirve para copiar objetos que tardan mucho en crear, o que son complejos de crear. Por ejemplo una lista grande que es difcil de obtener y que se desea ordenar de dos maneras distintas. Para el ejemplo anterior vamos a hacer una clase Persona y luego llenar la persona con los datos de dos hermanos: Juan y Mara que sern ingresados a un sistema x. Package nombrePack; public class Persona implements Cloneable { Public String nombres; Public String appellidos; Public String nombrePadre; public String nombreMadre; public String direccion; public String telCasa; public String nacionalidad; public String ciudadEnQueVive; public String nombreMascota; public Persona( ) {

90

/*Aqui va codigo de Set y get....*/

} Y un cliente que crea la Persona: public static void main(String[ ] args) { Persona juan = new Persona( ); juan.setNombres("Juan Jos"); juan.setAppellidos("Prez Ramirez"); juan.setNombrePadre("Juan Prez Martinez"); juan.setNombreMadre("Mara Ramirez"); juan.setDireccion("9a. Ave. 43-12 Z.1"); juan.setTelCasa("34567890"); juan.setNacionalidad("Guatemalteca"); juan.setCiudadEnQueVive("Guatemala"); juan.setNombreMascota("Pepito");

//Hacer algo con Juan, ingresarlo al sistema, etc...

System.out.println("Ingresando al sistema :"+juan.toString( )); Persona maria= (Persona) juan.clone(); maria.setNombres("Mara Ins"); System.out.println("Ingresando al sistema :"+maria.toString( ));

//ingresar a Maria al sistema....

}
Como se puede observar, ahora no se tuvieron que ingresar todos los campos de Mara sino, solo aquellos que la diferenciaban de su hermano Juan. Hay que recordar que si hubiese objetos en el ejemplo estos se clonan por referencia, es decir las referencias de ambos objetos son las mismas. Ahora vamos a implementar la clonacin a mano. Le vamos a aadir a Persona este mtodo: public Persona creaPrototipo( ) { Persona p = new Persona( ); p.setNombres(this.nombres); p.setAppellidos(this.appellidos); p.setNombrePadre(this.nombrePadre);

91

p.setNombreMadre(this.nombreMadre); p.setDireccion(this.direccion); p.setTelCasa(this.telCasa); p.setNacionalidad(this.nacionalidad); p.setCiudadEnQueVive(this.ciudadEnQueVive); p.setNombreMascota(this.nombreMascota); System.out.println("Creado prototipo de Persona"); return p; } Entonces en el cliente podemos hacer esta llamada

Persona maria = juan.creaPrototipo();

Entonces, el patrn prototipo es un modelo sencillo: permite crear una copia de un objeto para ahorrarnos los pasos de su creacin, o para optimizar accesos o procesos que ya se hicieron en un objeto similar y crear una copia del objeto ya con esos datos ingresados.

Cmo se describe un patrn de diseo?

Describe las clases que se requieren para implementar la solucin Se describen las clases responsables de la construccin de un objeto y su comportamiento. Lineamientos que conduzcan a una implementacin efectiva por el programador. Se describen ejemplos de cdigo fuente. El programador deber observar cada oportunidad en la que puedan reutilizarse patrones ya existentes en vez de crear otros.

ESTRUCTURAS13 Una estructura no es un patrn arquitectnico, sino un esqueleto con varios puntos de conexin que permiten adaptarlo a un dominio de problema especfico. Los puntos de conexin permiten integrar clases o funciones especficas de un problema dentro del esqueleto. En un contexto orientado a objetos, una estructura es un conjunto de clases que cooperan. Diferencias entre patrones de diseo y estructuras: 1. Los patrones de diseo son ms abstractos que las estructuras. Las estructuras estn incrustadas en el cdigo, pero en ste solo es posible incrustar ejemplos de patrones. Una ventaja de las estructuras es que se escriben en lenguajes de programacin y no slo son estudiadas, sino ejecutadas y reutilizadas directamente. 2. Los patrones de diseo son elementos arquitectnicos ms pequeos que las estructuras. Una estructura normal contiene varios patrones de diseo, pero lo contrario nunca se cumple. 3. Los patrones de diseo estn menos especializados que las estructuras. Las estructuras siempre tienen un dominio particular de aplicacin. En contraste, los patrones de diseo se

13

Tomado de Ingeniera de Software. Un enfoque prctico. Roger Pressman. 7 Edicin.

92

usan en casi cualquier tipo de aplicacin. Si bien es posible tener patrones de diseo ms especializados, incluso stos no imponen la arquitectura de una aplicacin. Estructuras o plantillas de patrones Para describir un patrn se usan plantillas ms o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicacin uniforme entre diseadores. Varios autores eminentes en esta rea han propuesto plantillas ligeramente distintas. Si bien la mayora definen los mismos conceptos bsicos. La plantilla ms comn es la utilizada por el GoF y consta de los siguientes apartados:

Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la comunidad (normalmente se expresan en ingls). Clasificacin del patrn: creacional, estructural o de comportamiento. Intencin: Qu problema pretende resolver el patrn? Tambin conocido como: Otros nombres de uso comn para el patrn. Motivacin: Escenario de ejemplo para la aplicacin del patrn. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrn. Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que participan en el patrn. Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del patrn. Implementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn. Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn. Usos conocidos: Ejemplos de sistemas reales que usan el patrn. Patrones relacionados: Referencias cruzadas con otros patrones.

2.2 PROGRAMACIN ORIENTADA A OBJETOS

El atractivo intuitivo de la orientacin a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Estos conceptos y herramientas orientados a objetos son tecnologas que permiten que los problemas del mundo real sean expresados de modo fcil y natural. Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para construir sistemas de software complejos a partir de unidades de software modularizado y reutilizable. Se necesita un nuevo enfoque para construir software en la actualidad. Este nuevo enfoque debe ser capaz de manipular tanto sistemas grandes como pequeos y debe crear sistemas fiables que sean flexibles, mantenibles y capaces de evolucionar para cumplir las necesidades del cambio. La orientacin a objetos trata de cubrir las necesidades de los usuarios finales, as como las propias de los desarrolladores de productos software. Estas tareas se realizan mediante la modelizacin del mundo real. El soporte fundamental es el modelo objeto. Abstraccin: La abstraccin es la propiedad que permite representar las caractersticas esenciales de un objeto, sin preocuparse de las restantes caractersticas (no esenciales). Abstraccin es la tcnica de quitarle a una idea o a un objeto todos los acompaamientos innecesarios hasta que los deja en una forma esencial y

93

mnima. Una buena abstraccin elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes. El elemento clave de la programacin orientada a objetos es la clase. Una clase se puede definir como una descripcin abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado especfico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, una pluma estilogrfica es un objeto que tiene un estado (llena de tinta o vaca) y sobre la cual se pueden realizar algunas operaciones (escribir, poner o quitar la tapa, llenar de tinta si est vaca, etc.). Los lenguajes orientados a objetos proporcionan la Encapsulacin. La encapsulacin se puede utilizar para aplicar el concepto de Abstraccin. Encapsulamiento El Encapsulamiento o encapsulacin es la propiedad que permite asegurar que el contenido de la informacin de un objeto est oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulacin (tambin se conoce como ocultacin de la informacin), en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus caractersticas esenciales. La encapsulacin permite la divisin de un programa en mdulos. Estos mdulos se implementan mediante clases, de forma que una clase representa la encapsulacin de una abstraccin. En la prctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementacin. La interfaz de una clase captura slo su vista externa y la implementacin contiene la representacin de la abstraccin, as como los mecanismos que realizan el comportamiento adecuado. Encapsulacin es la capacidad de contener y controlar el acceso a un grupo de elementos asociados. Las clases proporcionan una de las formas ms comunes para encapsular elementos.

ACTIVIDAD.
Investiga los siguientes conceptos y elabora un reporte escrito: Modularidad, herencia y polimorfismo. Propiedades de los objetos: concurrencia, persistencia, genericidad, manejo de excepciones. Conceptos de orientacin a objetos: clases, objetos, atributos, mensajes, mtodos y eventos.

EJERCICIOS PRCTICOS
Realiza en tu cuaderno los siguientes ejercicios:
1. Elabora una representacin para la clase vehculo. Debe contener atributos y mtodos. 2. Crea tres objetos a partir de la clase vehculo. 3. Escribe un ejemplo de diagrama de clases que utiliza herencia

Clasificacin de los lenguajes orientados a objetos14.

Existen varias clasificaciones de lenguajes orientados a objetos, atendiendo a criterios de construccin o caractersticas especficas de los mismos. Una clasificacin es la de Wegner, que es muy aceptada y difundida.

14

Tomado de Programacin Orientada a Objetos. Luis Joyanes Aguilar.

94

1.

2.

Lenguajes basados en objetos que soportan objetos. Es decir, disponen de componentes caracterizados por un conjunto de operaciones (comportamiento) y un estado. (Encapsulamiento + identidad de objetos) Lenguajes basados en clases, que implican clases y objetos. Es decir, disponen de componentes tipo clase con operaciones y estado comn. Una clase de un objeto se construye con una interfaz que especifica las operaciones posibles y un cuerpo que implementa dichas operaciones. (Basado en objetos + abstraccin de conjunto).

Lenguajes Orientados a Objetos que adems de objetos y clases ofrecen mecanismos de herencia entre clases. Esto es, la posibilidad de derivar operaciones y atributos de una clase (superclase) a sus subclases. (Basados en clases + herencia + autorrecursin).

Basados en objetos

+ clases Basados en clases

Basados en objetos

+ Herencia

Orientados a objetos

2.3 DISEO EN EL NIVEL DE COMPONENTES. El diseo en el nivel de componentes tiene lugar una vez terminado el diseo de la arquitectura. En esta etapa se ha establecido la estructura general de los datos y del programa del software. El objetivo es traducir el modelo del diseo a software operativo. El diseo de datos a nivel de componentes se centra en la representacin de estructuras de datos a las que se accede directamente a travs de uno o ms componentes del software. El diseo en el nivel de componente transforma los elementos estructurales de la arquitectura del software en una descripcin de sus componentes en cuanto a procedimiento. La informacin obtenida a partir de los modelos basados en clase, flujo y comportamiento sirve como la base para disear los componentes. Un componente es un bloque de construccin de software de cmputo. Desde la visin orientada a objetos, un componente contiene un conjunto de clases que colaboran. Cada clase dentro de un componente se elabora por completo para que incluya todos los atributos y operaciones relevantes para su implantacin. En el contexto de la ingeniera de software tradicional, un componente es un elemento funcional de un programa que incorpora la lgica del procesamiento, las estructuras de datos internas que se requieren para implantar la lgica del procesamiento y una interfaz que permite la invocacin del componente y el paso de los datos. Dentro de la arquitectura del software se encuentra un componente tradicional, tambin llamado mdulo, que tiene tres funciones importantes: 1) como componente de control que coordina la invocacin de todos los dems componentes del dominio del

95

problema, 2) como componente del dominio del problema que implanta una funcin completa o parcial que requiere el cliente y 3) como componente de infraestructura que es responsable de las funciones que dan apoyo al procesamiento requerido en el dominio del problema. Los componentes son entidades desplegables. Es decir, no son compilados en un programa de aplicacin, sino que se instalan directamente sobre una plataforma de ejecucin. Los mtodos y atributos definidos en sus interfaces pueden ser accedidos por otros componentes.

Ejemplo. Un modelo de componente de recopilacin de datos. Los pasos siguientes representan un conjunto de tareas comunes para el diseo en el nivel de componentes cuando se aplica a un sistema orientado a objetos: Paso 1. Identificar todas las clases de diseo que correspondan al dominio del problema . Con el uso del modelo de requerimientos y arquitectnico, se elabora cada clase de anlisis y componente de la arquitectura. Paso 2. Identificar todas las clases de diseo que correspondan al domino de la infraestructura. Estas clases no estn descritas en el modelo de los requerimientos y con frecuencia se pierden a partir del modelo arquitectnico; sin embargo, deben describirse en este punto. Paso 3. Elaborar todas las clases de diseo que no sean componentes reutilizables. La elaboracin requiere que se describan en detalle todas las interfaces, atributos y operaciones necesarios para implantar la clase. Mientras se realiza esta tarea, deben considerarse los heursticos del diseo. Paso 4. Describir las fuentes persistentes de datos (bases de datos y archivos) e identificar las clases requeridas para administrarlos. Paso 5. Desarrollar y elaborar representaciones del comportamiento para una clase o componente. Los diagramas de estado UML fueron utilizados como parte del modelo de los requerimientos para representar el comportamiento observable desde el exterior del sistema y el ms localizado de las clases de anlisis individuales. Paso 6. Elaborar diagramas de despliegue para dar ms detalles de la implementacin. Los diagramas de despliegue se utilizan como parte del diseo de la arquitectura y se representan en forma de descriptor. Durante el diseo en el nivel de componentes pueden elaborarse diagramas de despliegue que representen la ubicacin de paquetes de componentes clave. Paso 7. Redisear cada representacin del diseo en el nivel de componentes y siempre considerar alternativas.

96

Estudiaremos ms a profundidad los diagramas de despliegue o distribucin.

DIAGRAMA DE DESPLIEGUE O DISTRIBUCION

Un diagrama de despliegue muestra la configuracin de nodosque participan en la ejecucin y los componentes que residenen ellos. NODO Es un objeto fsico en tiempo de ejecucin que representa un recurso computacional generalmente tiene memoria y capacidad de procesamiento. Los nodos pueden contener objetos, instancias del componente. Un nodo representa tpicamente un procesador o un dispositivo sobre el que se pueden desplegar los componentes.

Grficamente un nodo se representa como un cubo 3D.

Cada nodo debe tener un nombre que lo distinga del resto (nombre simple o nombre compuesto).

Servidor::

Ventas

Copia de Seguridades

EJEMPLOS:
EJEMPLO 1. Diagrama de despliegue o Distribucin de un usuario conectndose a Internet, el cual est compuesto por lo siguiente:

El usuario hace la peticin por medio del teclado y a travs del monitor que quiere conectarse a Internet. En la estacin de trabajo se tiene instalado un navegador web que es el que recibe la peticin del usuario. El navegador Web enva un mensaje de peticin de conexin mediante un protocolo HTTP o HTTPS al servidor Web. El servidor Web recibe el mensaje en la interfaz Web de la capa de aplicacin y manda la peticin a la interfaz de la base de datos que se quiere consultar. La Interfaz manda un mensaje al servidor de la base de datos y al archivo log donde quedara almacenada ese proceso.

97

Y por ltimo la peticin del usuario llega hasta la base de datos creada en el gestor de base de datos MySQL y alojada en el servidor de base de datos. Dicho enlace se da ya sea por medio del protocolo TCP/IP o por medio de una conexin local o socket. Aqu tenemos dos nodos, el cliente y el servidor, cada uno de ellos contiene componentes. El componente del cliente utiliza una interface de uno de los componentes del servidor. Se muestra la relacin existente entre los nodos. A esta relacin podramos asociarle un estereotipo para indicar qu tipo de conexin disponemos entre el cliente y el servidor, as como modificar su cardinalidad para indicar que soportamos diversos clientes. Como los componentes pueden residir en ms de un nodo, podemos situar el componente de forma independiente, sin que pertenezca a ningn nodo y relacionarlo con los nodos en los que se sita.

EJEMPLO 2:
Diagrama de distribucin de una motherboard agrupado en un paquete, la cual contiene un teclado y un monitor LCD.

98

EJERCICIOS PRCTICOS
Elaborar el diagrama de distribucin de un nodo(estacin de trabajo o PC) que desea conectarse a Internet, el cual contiene 3 componentes de software (Windows, Office e Internet Explorer), y desea imprimir un documento elaborado en un editor de texto(Microsoft Word)que investigar en Internet).

EVALUACIN DEL TEMA

PARTE I. Investigue y conteste las siguientes preguntas:

1. 2. 3. 4. 5. 6. 7.

Cules son los elementos de un modelo Orientado a Objetos? Qu es reutilizacin de cdigo? Escriba los nombres de 4 patrones de creacin En que consiste el patrn de diseo prototipo? Cul es la caracterstica del mtodo singleton? Cul es la caracterstica de los patrones estructurales? Cules son las caractersticas del patrn compuesto?

PARTE II. Traslade el nmero de la respuesta correcta al espacio de en medio segn corresponda. Si no sabe la respuesta, debe investigar en alguna fuente bibliogrfica o en Internet.

1.

Estructura

Nombre con los que tambin se conocen los patrones de diseo. Patrones de bajo nivel especficos para un lenguaje de programacin o entorno concreto. Aqullos que expresan un esquema organizativo estructural fundamental para sistemas software.

2.

Objetivos de los patrones de diseo DesignPatterns

3.

99

4.

Patrones de arquitectura Patrones de Idiomas Patrones de diseo

Interpreter, observer, visitor, strategy, template method command, iteraator, mediator, memento state. Abstract Factory, Builder, prototype, etc. Adapter, bridge, decorator, composite, facade, proxy, flyweight. Proporcionar catlogos de elementos reusables en el diseo de sistemas software y evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Esqueleto con varios puntos de conexin que permiten adaptarlo a un dominio de problema especfico. Aqullos que expresan esquemas para definir estructuras de diseo (o sus relaciones) con las que construir sistemas software Son los detalles de la implementacin de un patrn de diseo.

5. 6.

7.

Estrategia

8.

Patrones de comportamiento Patrones de Creacin

9.

10. Patrones estructurales

TEMA 3. TCNICAS Y ESTRATEGIAS DE PRUEBAS DEL SOFTWARE

3.1 FUNDAMENTOS Y TIPOS DE PRUEBAS REALIZADAS AL SOFTWARE.
La prueba es un proceso que se enfoca sobre la lgica interna del software y las funciones externas. Objetivos de las pruebas: 1. La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error. 2. Un buen caso de prueba es aquel que tiene una alta probabilidad de descubrir un error no encontrado hasta entonces. 3. Una prueba tiene xito si descubre un error no detectado hasta entonces. No slo se prueba el cdigo: tambin documentacin y ayuda. Principios de las pruebas A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente. Las pruebas deberan planificarse mucho antes de que empiecen. Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande. No son posibles las pruebas exhaustivas. Para ser ms eficaces (pruebas con la ms alta probabilidad de encontrar errores), las pruebas deberan ser realizadas por un equipo independiente. Se debe inspeccionar a conciencia el resultado de cada prueba para, as, poder descubrir posibles sntomas de defectos. Cada caso de prueba debe definir el resultado de salida esperado. Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados

100

Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo) Probar si el software no hace lo que debe hacer Probar si el software hace lo que no debe hacer, es decir si provoca efectos secundarios Se deben evitar los casos desechables. No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los programas, y dedicando pocos recursos a las pruebas. La experiencia indica que donde hay un defecto hay otros. Las pruebas son una tarea creativa como el desarrollo de software. Las pruebas deben ser realizadas por un equipo independiente al que realiz el software, porque este inconscientemente tratar de demostrar que el software funciona y no que no lo hace, por lo que la prueba puede tener menos xito. Fiabilidad: Probabilidad de operacin libre de fallos de un programa de computadora en un entorno determinado y durante un tiempo especfico.

3.2

ESTRATEGIAS DE PRUEBA PARA SOFTWARE

Existen muchas estrategias que pueden usarse para probar el software. En un extremo, puede esperarse hasta que el sistema est completamente construido y luego realizar las pruebas sobre el sistema total, con la esperanza de encontrar errores. Este enfoque, aunque atractivo, simplemente no funciona. En el otro extremo, podran realizarse pruebas diariamente, siempre que se construya alguna parte del sistema. Este enfoque, aunque menos atractivo para muchos, puede ser muy efectivo. Una estrategia de prueba que eligen la mayora de los equipos de software se coloca entre los dos extremos. Toma una visin incremental de las pruebas, comenzando con la de unidades de programa individuales, avanza hacia pruebas diseadas para facilitar la integracin de las unidades y culmina con pruebas que ejercitan el sistema construido. Los 5 tipos de prueba del software Especificacin: Este tipo de prueba incluye probar la aplicacin en contra de la documentacin que se hizo antes, por ejemplo, que los procesos concuerden con los algoritmos hechos a papel, o que la aplicacin tenga todas las funciones que se haban planeado. Usabilidad: Este tipo de prueba se refiere a asegurar de que la interfaz de usuario (o GUI) sea intuitiva, amigable y funcione correctamente. Unidad: Este tipo de prueba solo aplica a proyectos grandes. Se divide el proyecto a unidades y cada unidad es sometida a prueba individualmente. Integracin: Prueba varias unidades juntas para asegurar que funcionen bien. Tambin se asegura de que las nuevas aplicaciones se integren con aplicaciones antiguas o aplicaciones complementarias. Regresin: Esta prueba incluye todas las pruebas anteriores en caso de que se le haga algn cambio a algn modulo despus de haber sido puesto en ambiente de produccin.

VERIFICACIN Y VALIDACIN La prueba del software es un elemento de un tema ms amplio que suele denominarse verificacin y validacin. Verificacin: Es el conjunto de tareas que garantizan que el software implementa correctamente una funcin especfica Estamos construyendo el producto correctamente?

101

Validacin: Es un conjunto diferente de actividades que aseguran que el software que se construye sigue los requerimientos del cliente Estamos construyendo el producto correcto?

PRUEBAS ALFA Y BETA La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de manera natural, con el encargado de desarrollo "mirando por encima del hombro" del usuario" y registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta se lleva a cabo en uno o ms lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado de desarrollo, normalmente, no est presente. La prueba beta es una aplicacin "en vivo" del software en un entorno que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra y los informa a intervalos regulares. Como resultado, el equipo de desarrollo lleva a cabo modificaciones y as prepara una versin del producto para toda la base de clientes.

INVESTIGACIN INDIVIDUAL
Investiga en qu consisten las pruebas de recuperacin, pruebas de seguridad, de esfuerzo, de rendimiento y de despliegue. Elabora un resumen en tu cuaderno de trabajo. 3.3 VISIONES INTERNA Y EXTERNA DE LAS PRUEBAS.
Los Mtodos de Prueba de Softwaretienen el objetivo de disear pruebas que descubran diferentes tipos de errores con menor tiempo y esfuerzo. A continuacin se presentan los Mecanismos de Prueba de Software ms conocidos: La lgica interna del programa utilizando tcnicas de diseo de casos de prueba de "caja blanca Las pruebas de caja blanca se basan en un examen minucioso de los detalles procedimentales, comprobando los caminos lgicos del programa, comprobando las condiciones y ciclos; examinando el estado del programa en varios puntos. (Criterios basados en el contenido de los mdulos).

Los requisitos del software utilizando tcnicas de diseo de casos de prueba de "caja negra" Las pruebas de caja negra se aplican a la interfaz del software, examinando el aspecto funcional del sistema. Pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta. (Criterios basados en las interfaces y las especificaciones de los mdulos).

102

3.3.1 MTODO DE LA CAJA NEGRA A la mayor parte de los usuarios de programas extensos no les interesa los detalles de su funcionamiento; lo nico que desean es conseguir respuestas. Es decir, desean tratar el programa como una caja negra a la cual le introducen datos de entrada y obtienen de ella los datos de salida que esperan. De ah el nombre de este mtodo. De manera anloga, los datos de prueba se escogern atendiendo a las especificaciones del problema, sin importar los detalles internos del programa, a fin de verificar que ste corra bien. El Mtodo de la Caja Negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa. Con este tipo de pruebas se intenta encontrar: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a las bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin. TIPOS DE PRUEBA DE CAJA NEGRA: Mtodos grficos de prueba Particin Equivalente Anlisis de valores lmite Prueba de tabla ortogonal Pruebas de interfaces grficas Prueba de arquitectura cliente/servidor Pruebas de servidor Pruebas de base de datos Pruebas de transaccin Pruebas de comunicacin de red Pruebas de documentacin Pruebas de sistemas de tiempo real A continuacin se citan los criterios mnimos que deben guiarnos al escoger los datos de prueba de nuestros programas:

103

1. Valores fciles El programa se depurar con datos de fcil comprobabilidad. Ms de un estudiante, que ensay un programa exclusivamente con datos complicados y que crey que funcionaba bien, se ha sentido apenado cuando su instructor aplic el programa a un ejemplo trivial. 2. Valores tpicos realistas Siempre se ensayar un programa con datos seleccionados para que representen cmo se aplicar. Tales datos han de ser suficientemente sencillos, de modo que los resultados sean verificables en forma manual. 3. Valores extremos Muchos programas cometen errores en los lmites de sus rangos de aplicaciones. Es muy fcil que las instrucciones que incluyen a los contadores de ciclos o que hacen referencia a las dimensiones de un arreglo se equivoquen por uno. 4. 4. Valores ilegales "Basura entra, basura sale" es un viejo refrn en los crculos de computacin y conviene respetarlo. Cuando en un programa entra basura, su reaccin inmediata habr de ser por lo menos un mensaje de error adecuado para el usuario. Es preferible que el programa ofrezca a ste alguna indicacin de probables errores detectados en los datos de entrada que se han ingresado y que realice clculos que sigan siendo factibles luego de desechar la entrada equivocada, o intente funcionar con datos predefinidos evitando as que el programa colapse. 3.3.2 PRUEBA DE LA CAJA BLANCA Las pruebas de caja blanca intentan garantizar que: Se ejecutan al menos una vez todos los caminos independientes de cada mdulo Se ejecutan las decisiones en su parte verdadera y en su parte falsa Se ejecuten todos los bucles en sus lmites Se utilizan todas las estructuras de datos internas para comprobar su validez. Tipos de Prueba de Caja Blanca: Prueba de la Ruta Bsica Pruebas de la estructura de control Prueba de condicin Prueba del flujo de datos Prueba de bucles

A continuacin, estudiaremos las pruebas de Caja Blanca. PRUEBA DE CAMINO BSICO O RUTA BSICA (Mc Cabe) Permite obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Hace uso de la representacin del flujo de control mediante un grafo de flujo (o grafo del programa). Se basa en la representacin del cdigo a probar a travs de crculos y arcos que indican el flujo de control. Cada crculo representa una o ms sentencias. a realizar para aplicar esta tcnica: Representar el programa en un grafo de flujo Calcular la complejidad ciclomtica del grafo obtenido Determinar el conjunto bsico de caminos independientes. Derivar los casos de prueba que fuerzan la ejecucin de cada camino (que permitan la ejecucin de cada camino bsico). Ejecutar cada paso de prueba y comparar con los resultados esperados.

Pasos

104

Camino independiente es aquel que introduce un nuevo conjunto de sentencias o una nueva condicin. Una arista que no haya sido recorrida antes. Elementos: Nodos: representan condiciones o secuencias de instrucciones. Cero, una o varias sentencias en secuencia. Comprende como mximo una sentencia de decisin. Arcos, Aristas o enlaces: representan flujo de control del programa. Son las lneas que unen dos nodos. Regin: rea que se limita por aristas y nodos. Cuando se contabilizan las regiones de un programa debe incluirse el rea externa como una regin ms. Nodo predicado: Es un nodo que contiene una condicin y se caracteriza porque de l salen dos o ms aristas. Una de las caractersticas para comprobar si un grafo de flujo est bien diseado es que los nicos nodos de los que pueden partir dos aristas son los nodos predicado. Cuando en una condicin aparecen uno o ms operadores lgicos (and, or, xor,..) se crea un nodo distinto por cada una de las condiciones simples. Cada nodo generado de esta forma se denomina nodo predicado.

Estructuras en forma de grafo de flujo:

CARACTERISTICAS DEL GRAFO DE FLUJO: Existe un solo nodo inicial Existe un solo nodo final Cada nodo representa una secuencia de instrucciones, que puede ser vaca

105

Un nodo puede tener uno o dos sucesores Un nodo puede tener uno o muchos antecesores Un nodo tendr dos sucesores, si existen dos caminos posibles, dependiendo de una condicin. Los casos de for, while, Repeat y Case, se pueden reducir a grupos de nodos con dos sucesores

El grafo contendr dos tipos de elementos: a) nodos que representan una o ms instrucciones secuenciales, y b) arcos que representan cambios de direccin En principio cada instruccin se representar como un nodo. Existen dos tipos de instruccin: a) Las que tienen un sucesor nico, como las asignaciones y las instrucciones de lectura. b) Las que tienen dos o ms sucesores posibles, como el If, la condicin del For y el case. Las instrucciones con sucesor nico, es decir las secuenciales, pueden representarse una sola en cada nodo o varias de ellas en uno solo, ya que si se ejecuta la primera se ejecutarn las siguientes una tras otra. Formas de representar una sucesin de instrucciones, siendo todas ellas equivalentes para los propsitos de clculo de complejidad y de preparacin de pruebas.

Una arista debe de terminar en un nodo incluso si el nodo no representa ningn enunciado de procedimiento. Una secuencia de cajas de proceso y un rombo de decisin pueden mapearse en un solo nodo. Cuando se cuentan las regiones, el rea afuera del grfico se incluye como regin.

106

107

COMPLEJIDAD CICLOMTICA Es una medida del software que aporta una valoracin cuantitativa de la complejidad lgica de un programa. Dentro del contexto del mtodo de pruebas del camino bsico define el nmero de caminos independientes de un programa. Por camino independiente se entiende aquel que introduce un nuevo conjunto de sentencias o una nueva condicin. En trminos del grafo, por una arista que no haya sido recorrida antes. Nos da una cota o lmite superior para el nmero de casos de prueba. Existen varias formas de calcular la complejidad ciclomtica de un programa a partir de un grafo de flujo: 1. El nmero de regiones del grafo coincide con la complejidad ciclomtica, V (G). 2. La complejidad ciclomtica, V (G), de un grafo de flujo G se define como V (G) = Aristas Nodos + 2 V (G) = A N + 2 3. La complejidad ciclomtica, V (G), de un grafo de flujo G se define como V (G) = Nodos Predicado +1 V (G) = P + 1 4. A travs de la matriz del Grafo y de Conexiones T V (G) = T + 1 La siguiente Figura representa, por ejemplo, las cuatro regiones del grafo de flujo, obtenindose as la complejidad ciclomtica de 4. Anlogamente se puede calcular el nmero de aristas y nodos predicados para confirmar la complejidad ciclomtica. As: V (G) = Nmero de regiones = 4 V (G) = Aristas Nodos + 2 = 11-9 + 2 = 4 V (G) = Nodos Predicado + 1 = 3 +1 = 4

108

Matriz del Grafo Es una matriz cuadrada cuya longitud es el nmero de nodos del grafo de flujo. Cada fila y columna se corresponden a un nodo especfico y el contenido de la matriz son las aristas del grafo, estas pueden llevar un peso de enlace que da informacin sobre el flujo de control. Puede ser 0 1, indicando si existe o no conexin entre los nodos. A la matriz resultante se le denomina matriz de conexiones. A partir de ella se puede calcular V (G) y el conjunto bsico de caminos.

109

EJERCICIOS PRCTICOS
Realiza los siguientes ejercicios en tu cuaderno de trabajo. Disear el conjunto de casos de prueba mediante el mtodo de la complejidad ciclomtica para el siguiente cdigo:

Ejercicio 1. Begin r:=0; If (x<0 or y<0) then Writeln( x e y deben ser positivos) Else r:=(x+y)/2; writeln(la media es:, r) End_ if End

Ejercicio 2.

Inicio

Fin

110

Ejercicio 3.

EVALUACIN DEL TEMA

Traslada el nmero de la respuesta correcta a la casilla de en medio, segn corresponda.

1. 2.

Prueba alfa Prueba beta

3. 4. 5. 6. 7. 8. 9. 10.

Verificacin Validacin Pruebas de caja blanca Pruebas de caja negra Prueba de ruta bsica Camino independiente Nodo Predicado Complejidad ciclomtica

Es el conjunto de tareas que garantizan que el software implementa correctamente una funcin especfica. Se basan en un examen minucioso de los detalles procedimentales, comprobando los caminos lgicos del programa, comprobando las condiciones y ciclos y examinando el estado del programa en varios puntos. Se basa en la representacin del cdigo a probar a travs de crculos y arcos que indican el flujo de control. Se caracteriza porque de l salen dos o ms aristas. Se llevan a cabo en entornos controlados. El cliente va a lugar de desarrollo a probar el software. Es aquel que introduce un nuevo conjunto de sentencias o una nueva condicin. Es una arista que no ha sido recorrida antes. Define el nmero de caminos independientes de un programa. Es un conjunto diferente de actividades que aseguran que el software que se construye sigue los requerimientos del cliente. Son criterios basados en las interfaces y las especificaciones de los mdulos. Es una aplicacin en vivo del software en un entorno que no puede ser controlado por el equipo de desarrollo. El encargado de desarrollo no est presente.

111

BIBLIOGRAFA

Ingeniera de software. Un enfoque prctico. Roger S. Pressman5. Edicin. Ingeniera de software. Un enfoque prctico. Roger S. Pressman7. Edicin. System Engineering Management. Blanchard, B.S. 2da. Edicin. 1997. Ingeniera de Software. IanSommerville. 7a. Edicin. Anlisis y Diseo de Sistemas. Kendall y Kendall. 6a. Edicin.

EVALUACIN FINAL DE TAREA SIGNIFICATIVA

La siguiente rbrica es para evaluar su trabajo final (Tarea significativa del mdulo.
Nombre del Evaluado:_____________________________________________________________ Nombre del evaluador: _____________________________________________________________ Ttulo de la Tarea: ____________________________________________________________ Fecha de evaluacin: ________________________ OBJETIVO: Evaluar la aplicacin de conocimientos adquiridos durante el mdulo, en la elaboracin de una tarea significativa. Para su valoracin se establece una escala numrica que contiene 10 aspectos o criterios para un total de 100 puntos y cuyo valor porcentual del total asignado al mdulo es del 30% de la prctica. La escala numrica tiene 5 opciones para evaluar los aspectos a observar: 5. Excelente 4. Muy Bueno 3. Bueno 2. Regular 1. Deficiente

CRITERIOS DE EVALUACIN 1. 2. Presentan documento con portada, ndice, introduccin y objetivos, en la fecha y hora establecidas. Realizaron planteamiento del problema y algoritmo general del sistema.

VALORACIN
5 4 3 2 1

112

3. 4. 5. 6. 7. 8. 9. 10.

Presentan Presentan despliegue.

diagrama diagrama

de de

clases,

objetos

secuencia y de

modificados. componentes, estados

Elaboraron esquemas de men y diseo de la interfaz del usuario. Aplicaron mtricas tcnicas al problema. Elaboraron patrones del diseo para el problema. Realizaron pruebas del software aplicando mtodos

estudiados en el mdulo. Aplicaron reglas de ortografa y tcnicas de redaccin en forma completa. Demuestran dominio del tema en forma Individual. Total de puntos obtenidos

BIBLIOGRAFA

Ingeniera de software. Un enfoque prctico. Roger S. Pressman5. Edicin. Ingeniera de software. Un enfoque prctico. Roger S. Pressman7. Edicin. System Engineering Management. Blanchard, B.S. 2da. Edicin. 1997. Ingeniera de Software. IanSommerville. 7a. Edicin. Anlisis y Diseo de Sistemas. Kendall y Kendall. 6a. Edicin.

113