Ingeniera de Software I

Programa Magisterial
Mara de los ngeles Cruz Sosa

SINOPSIS Se desarrolla los temas contemplados en el programa magisterial de la materia que consisten en principales mtodos de Anlisis y Diseo de Software Orientado a Objetos adems de tcnicas para verificar la calidad del software tomando en cuenta que la elaboracin del software se debe cumplir con eficiencia y eficacia.

Table of Contents
1. Tcnicas de modelacin de Objetos (OMT) ...................................................... 4
Modelo de Objetos .............................................................................................................................................. 5 Modelo Dinmico ................................................................................................................................................ 5 Modelo Funcional ............................................................................................................................................... 5 Anlisis .................................................................................................................................................................... 6 Documento del anlisis ................................................................................................................................ 6 Anlisis de Objetos ............................................................................................................................................. 6 Anlisis Dinmico ............................................................................................................................................... 6 Anlisis Funcional .............................................................................................................................................. 7 Diseo ...................................................................................................................................................................... 7 Diseo de sistemas ............................................................................................................................................. 7 Documento del diseo del sistema ........................................................................................................... 8 Diseo de Objetos ............................................................................................................................................... 8

2. Lenguaje de Modelado Unificado (UML) ............................................................ 9

Diagramas de UML .......................................................................................................................................... 10 Diagrama de clases ......................................................................................................................................10 Diagrama de objetos ...................................................................................................................................10 Diagrama de Casos de Uso ........................................................................................................................ 11 Diagrama de Estados ..................................................................................................................................11 Diagrama de secuencias ............................................................................................................................ 12 Diagrama de actividades........................................................................................................................... 12 Diagrama de colaboraciones ...................................................................................................................13 Diagrama de componentes ....................................................................................................................... 13 Diagrama de distribucin ......................................................................................................................... 13 Diagramas de Paquetes ............................................................................................................................. 14 Nota UML......................................................................................................................................................... 14 Estereotipos ....................................................................................................................................................14 Anlisis y Diseo Orientado a Objetos con UML ................................................................................ 15 Lenguaje de restriccin de objetos (OCL) ............................................................................................. 16 OCL Y UML en accin ...................................................................................................................................... 16

3. Patrones de diseo .......................................................................................... 17

Introduccin a los Patrones de Diseo ................................................................................................... 17 Estudio del catlogo de patrones .............................................................................................................. 18 Anlisis y Diseo utilizando Patrones de Diseo ............................................................................... 21

4. Sistemas de tiempo Real Orientado a Objetos.................................................. 21

Introduccin a Sistemas de tiempo real Orientado a Objetos ...................................................... 21 Anlisis de Requerimientos de Sistema de Tiempo Real O. O. ..................................................... 22 Anlisis: Definicin de la Estructura de Objetos ................................................................................ 23 Anlisis: Definicin de Comportamiento de Objetos ....................................................................... 23 Diseo de Sistemas de Tiempo Real Orientado a Objetos ............................................................. 24 Seleccin de plataforma ............................................................................................................................ 24 Identificacin de estmulos/respuestas ............................................................................................... 24 Anlisis de temporizacin ......................................................................................................................... 24 Diseo de procesos .......................................................................................................................................24 Diseo de algoritmo ....................................................................................................................................25 Diseo de datos .............................................................................................................................................25 Planeacin del proceso............................................................................................................................... 25

5.-Administracin de la fundamentacin ............................................................. 25

Conceptos de la fundamentacin .............................................................................................................. 26 Actividades de la fundamentacin: de los problemas de las decisiones. ................................ 27 Administracin de la fundamentacin ................................................................................................... 28

Pruebas Orientadas a Objetos ............................................................................. 28

Conceptos de las Pruebas ............................................................................................................................. 29 Actividades de las Pruebas .......................................................................................................................... 29 Pruebas Unitarias.........................................................................................................................................29 Pruebas de Integracion .............................................................................................................................. 30 Pruebas del Sistema ....................................................................................................................................31 Pruebas de Aceptacion ............................................................................................................................... 31 Pruebas de Regresion..................................................................................................................................32 Administracin de las Pruebas .................................................................................................................. 32

Mtricas Tcnicas para Sistemas Orientados a Objetos ........................................ 33

El Propsito de las Mtricas Orientadas a Objetos ........................................................................... 33 Caractersticas distintivas de las mtricas Orientadas a Objetos ............................................... 33 Mtricas para el modelo de Diseo Orientado a Objetos ............................................................... 34 Mtricas Orientadas a Clases ...................................................................................................................... 34 Mtricas Orientadas a Operaciones ......................................................................................................... 34 Mtricas para Pruebas Orientadas a Objetos ...................................................................................... 35

Mtodos Formales .............................................................................................. 36

Conceptos Bsicos ........................................................................................................................................... 36 Preliminares Matemticos ........................................................................................................................... 37 Aplicacin de la Notacin Matemtica para la Especificacin Formal ..................................... 37 Mtodos formales basados en Objetos ................................................................................................... 39

Ingeniera del Software de Sala Limpia ................................................................ 41

El enfoque de Sala Limpia ............................................................................................................................ 41 Especificacin funcional ............................................................................................................................... 42 Refinamiento y verificacin del Diseo ................................................................................................. 44 Prueba de Sala Limpia ................................................................................................................................... 45 Fuentes de Informacin ................................................................................................................................ 46

1. Tcnicas de modelacin de Objetos (OMT)

La metodologa de ingeniera del software es un proceso para producir software de una forma organizada, empleando una coleccin de tcnicas y convenciones de notacin predefinidas. La metodologa suele presentarse como una serie de pasos, con tcnicas y notaciones asociadas a cada paso. Los pasos de produccin de software suelen organizarse en un ciclo de vida que consta de varias fases de desarrollo. El ciclo de vida completo del software abarca desde la formulacin inicial del problema, pasando por el anlisis, diseo, implementacin y pruebas del software, hasta una fase operacional durante la cual se llevan a cabo el mantenimiento y las mejoras. Un modelo es una abstraccion de algo, cuyo objetivo es comprenderlo antes de construirlo. Dado que los modelos omiten los detalles no esenciales, es mas sencillo manipularlos que manipular la entidad original. La abstraccion es una capacidad humana fundamental que nos permite enfrentarnos a la complejidad. Los ingenieros, artistas y artesanos han estado constr uyendo modelos durante miles de anos para probar los disenos antes de ejecutarlos. El desarrollo de sistemas hardware y software no es una excepcion. Para construir sistemas complejos, el desarrollador debe abstraer distintas vistas del sistema, construir modelos utilizando notaciones precisas, verificar que los modelos satisfacen los requisitos del sistema y anadir, gradualmente, detalles para trasformar los modelos en una implementacion. (Rumbaugh, 1996) La metodologia OMT (Te cnica de Modelado de Objetos), cuyo creador es James Rumbaugh, incorpora el llamado Modelo Funcional despue s de haber modelado la estructura esta tica (Modelo de Objetos) y la estructura dina mica (Modelo Dina mico). Este modelo funcional describe las transformaciones de valores de datos que ocurren dentro del sistema es decir, que es responsable de capturar lo que hace el sistema independientemente de cua ndo se haga o de la forma en que se haga. OMT emplea tres clases de modelos para describir el sistema, a saber:

Figura 1 Clases de modelos en la OMT

Cada modelo describe un aspecto del sistema pero contiene referencias a los dema s modelos. Lo cual indica que los tres no son totalmente independientes.

Modelo de Objetos
El modelo de objetos es el mo delo ma s importante, ya que en e l se identifican las clases dentro del sistema junto con sus relaciones, asi como sus atributos y operaciones, lo que representa la estructura esta tica del sistema. El modelo de objetos se representa mediante un diagrama de clases. Los pasos para construir el modelo de objetos son los siguientes: a. b. c. d. e. f. Identificacio n de objetos y/o clases. Crear un diccionario de datos. Identificacio n de las asociaciones y agregaciones entre los objetos. Identificacio n de atributos y enlaces. Organizacio n y simplificacio n de las clases empleando herencia. Verificacio n de las vias de acceso necesarias para llevar a cabo las probables consultas. g. Realizar las iteraciones necesarias para el refinamiento del modelo. h. Agrupar las clases en mo dulos. Modelo de objetos = Diagrama de modelo de objetos + diccionario de datos.

Modelo Dinmico
Representa los aspectos temporales de comportamiento "de control" del sistema, mediante la secuencia de operaciones en el tiempo. Los pasos para construir el modelo dina mico son los siguientes: a. b. c. d. e. Preparacio n de escenarios de secuencias tipicas de iteracio n. Identificacio n de sucesos que actu an entre objetos. Preparar un seguimiento de sucesos para cada escenario. Construccio n de un diagrama de estado para cada objeto. Comparacio n de los sucesos intercambiados entre objetos para verificar la congruencia.

Modelo dina mico = Diagrama de estados + diagrama global de flujo de sucesos.

Modelo Funcional
Representa los aspectos transform acionales "de funcio n" del sistema, mediante la transformacio n de valores de los datos. Se representa mediante un diagrama de flujo. Los pasos para construir el modelo funcional son los siguientes: a. Identificacio n de los val ores de entrada y de salida. b. Construccio n de diagramas de flujo de datos que muestren las dependencias funcionales. c. Descripcio n de las funciones. d. Identificacio n de restricciones. e. Especificacio n de los criterios de optimizacio n. Modelo Funcional = Diagrama de flujo de datos + restricciones.

Anlisis
Se dedica a la comprensin y modelado de la aplicacin y del dominio en el cual funciona. La entrada inicial de la fase de anlisis en una descripcin del problema que hay que resolver y proporciona una visin general conceptual del sistema propuesto. Un dilogo subsiguiente con el cliente y un conocimiento de fondo del mundo real son entradas adicionales del anlisis. La salida del anlisis es el modelo formal que captura los tres aspectos esenciales del sistema: Los objetos y sus relaciones. El flujo dinmico de control. La transformacin funcional de datos que estn sometidos a restricciones.

El modelo de anlisis debera incluir aquella informacin que sea significativa desde el punto de vista del mundo real, y debe presentar el aspecto externo del sistema. El modelo de anlisis debera resultar comprensible para el cliente del sistema, y debera de proporcionar una base til para extraer los verdaderos requisitos del sistema. Los requisitos verdaderos son los que realmente se necesitan, son congruentes internamente y adems se pueden llegar a realizar. Documento del anlisis Son los artefactos que se prepararon durante la conceptualizacin y las fases de anlisis, de que representan los requisitos de proceso para un sistema propuesto. Incluye tpicamente el siguiente: Declaracin del Problema. Requisitos Formales del Sistema. Modelos del Anlisis. Descripcin de la Interfaz Utilizada.

Anlisis de Objetos
Los pasos de progresin del microproceso para el anlisis del modelo del objeto tratan la estructura de un sistema en trminos de la organizacin y de los lazos entre sus clases y objetos. El modelo del objeto - el modelo que muestra la estructura del sistema, y captura el siguiente como parte de su representacin:

Clases y objetos identificados (diagrama de la clase de UML). Asociaciones De la Clase (Diagrama De la Clase De Uml). Atributos De la Clase (Diagrama De la Clase De Uml). Organizacin de la clase usando generalizacin/especializacin y las asociaciones de la jerarqua (diagrama de la clase de UML). Clasifique las agrupaciones en los subsistemas (diagrama de la clase de UML).

Anlisis Dinmico
Los pasos de progresin del microproceso para el anlisis modelo dinmico tratan el comportamiento del sistema y de la evolucin temporal de sus objetos. El comportamiento de cada objeto se define en los trminos de los cambios que

experimenta en respuesta a interacciones con otros objetos, tanto en el interior como en el exterior el sistema. Esta tarea requiere que el anlisis modelo del objeto se haya realizado previamente. Modelo dinmico- el modelo que describe la evolucin temporal de los objetos en un sistema. Se define de la siguiente manera: Descripcin Del Estado. Descripcin Externa Del Acontecimiento. Diagramas de estado del ciclo vital para cada clase que exhibe el comportamiento dinmico (diagrama de estado de UML). Decorados primarios y alternos (refinados / revisados). Diagrama del rastro del acontecimiento / por el decorado (refinado / revisado) (diagramas del rastro del mensaje de UML).

Anlisis Funcional
Los pasos de progresin del microproceso para el anlisis modelo dinmico tratan todas las operaciones que el sistema debe realizarse. Esta tarea requiere que el modelo del objeto y el anlisis modelo dinmico se haya realizado previamente. Operaciones identificadas- una lista y una descripcin de cada operacin identificada en cada transicin del estado (diagrama de estado de UML). Modelo funcional- el modelo que describe todas las operaciones del sistema. Se define en trminos de: Utilizar las Descripciones del Caso. Decorados (refinados / revisados). Diagrama del rastreo del acontecimiento / por el decorado (refinado / revisado) (diagrama del rastro del mensaje de UML). Especificacin de la operacin de cada operacin identificada (especificacin de la operacin de UML). Diagramas De la Interaccin Del Objeto (Diagrama Del Mensaje Del Objeto De Uml / Diagrama Simultneo Del Mensaje Del Objeto). Diseos De la Operacin. Descripciones De Procesos/Funcin. Algoritmos/Cdigos.

Los datos de los diagramas de flujo de cada operacin identificarla, donde esa operacin implica ms de una clase u objeto.

Diseo Diseo de sistemas

El disen o del sistema es la estrategia de alto nivel para resolver el problema y construir una solucio n. Se determina la arquitectura global del sistema utilizando el modelo de objetos como gua, se organiza el sistema en subsistemas. La concurrencia se organiza agrupando objetos en tareas concurrentes. Se tomas decisiones globales acerca de la comunicacin entre procesos, almacenamiento

de datos e implementacin del modelo dinmico. Se establecen prioridades para hacer concesiones de diseo. Durante el disen o del sistema se an aden estructuras en el dominio de la solucio n. El modelo de disen o debe ser razonablemente eficiente y pra ctico a la hora de codificar, tratando detalles de bajo nivel que se omiten en el modelo de ana lisis. Documento del diseo del sistema Son los artefactos se prepararon durante la fase del diseo del sistema, se representa la configuracin y la estructura del sistema, pues debe ser puesta en ejecucin. Incluye tpicamente lo siguiente: Descripcin del Subsistema. Esqueleto de la Configuracin del Software lgico(a). Anlisis de Tarea Simultnea (Diagramas Simultneos Del Mensaje Del Objeto De UML). Anlisis del Almacenaje de datos (diagrama de la clase de UML). Opciones y Anlisis Razonado del Diseo. Diagramas de la Clase del Subsistema (Diagrama de la Clase de UML). Diagramas del Mdulo (Diagrama del Mdulo De UML). Diagramas de la Plataforma (Diagrama de la Plataforma de UML). Plan de la Reutilizacin del Subsistema/Componentes. Plan de Lanzamiento.

Diseo de Objetos
En el Disen o de Objetos se toman las decisiones necesarias para construir un sistema sin descender a los detalles particulares de un lenguaje o sistema de base de datos. El disen o de objetos es el comienzo de un desplazamiento con respecto al mundo real, en el mode lo de ana lisis, aproxima ndose a la orientacio n a la computadora, necesaria para una implementacio n pra ctica. Se elaboran los modelos de anlisis, se refinan, y despus se optimizan para producir un diseo prctico. Durante el diseo de objetos existe un desplazamiento de foco de atencin desde los conceptos de la aplicacin hasta los conceptos de la computadora. En primer lugar, se seleccionan los algoritmos bsicos para implementar todas las funciones fundamentales del sistema. Basndose en estos algoritmos, se optimiza entonces la estructura del modelo de objetos para una implementacin eficiente. El diseo tambin debe tener en cuenta la concurrencia y el flujo dinmico de control, segn hayan sido determinados durante el diseo del sistema. Se determina la implementacin de cada asociacin y de cada atributo. Finalmente, los subsistemas se empaquetan en mdulos.

2. Lenguaje de Modelado Unificado (UML)

Figura 2 Concepcion del UML

El UML es la creacin de Grady Booch, James Rumbaugh (OMT) e Ivar Jacobson. Estos tres amigos, trabajaban en empresas distintas durante la dcada de los 80s y principios de los 90s, cada uno dise su propia metodologa para el anlisis y diseo orientado a objetos. Sus metodologas predominaron sobre las de sus competidores. A mediados de los 90s empezaron a intercambiar ideas entre s y decidieron desarrollar su trabajo en conjunto. El UML una de las herramientas ms importantes en el desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseos que capturen sus ideas en una forma convencional y fcil de comprender para comunicarlas a otras personas. Considerndose como sistema una combinacin de software y hardware que da una solucin a un problema de negocios. El desarrollo de sistemas como la creacin de un programa para un cliente a quien se debe resolver cierto problema.

Es necesario el UML pues es necesario contar con un plan bien analizado especialmente en los negocios de alto riesgo. El cliente debe comprender qu har el equipo de desarrolladores (entendindose como los programadores que generarn el programa que resolver el problema y lo distribuirn en equipos de computacin). Mediante el UML es posible sealar los cambios que surjan durante el proceso o al definir las necesidades del cliente. El UML proporciona una organizacin de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con l.

Diagramas de UML
La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Un modelo UML describe lo que har un sistema, pero no dice cmo implementarlo. Diagrama de clases Un diagrama de clases representa la estructura esta tica que las clases poseen (Jacobson, 1992). Una clase es una categora o grupo de cosas que tienen atributos y acciones similares. Un rectngulo es el smbolo que representa a la clase, y se divide en tres reas. El rea superior contiene el nombre, el rea central contiene los atributos, y el rea inferior las acciones. Un diagrama de clases est formado por varios rectngulos de este tipo conectados por lneas que muestran la manera en que las clases se relacionan entre s.

Figura 3 Smbolo UML de una clase

Diagrama de objetos Un objeto es una instancia de una clase (una entidad que tiene valores especficos de los atributos y acciones). Un rectngulo es el smbolo que representa al objeto. El nombre de la instancia especfica se encuentra a la izquierda de los dos puntos (:), y el nombre de la clase a la derecha.

Figura 4 Smbolo UML del objeto

Diagrama de Casos de Uso El modelo de casos de uso consta de actores que representan los roles que los diferentes usuarios pueden desempen ar, y los casos de uso que representan lo que deben estar en capacidad de hacer los usuarios con el software por construir. Un diagrama de casos de uso muestra la funcionalidad que ofrece el sistema futuro desde la perspectiva de los usuarios externos al mismo (Jacobson, 1992). Es una descripcin de las acciones de un sistema desde el punto de vista del usuario. Es tcnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario.

Figura 5 Diagrama UML de casos de uso

Diagrama de Estados Se utilizan para describir el comportamiento de un sistema, representa los diferentes estados que puede adquirir una clase, como representarla a diferentes etapas de su vida. El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, adems, el estado de un objeto tambin se puede caracterizar por la existencia de un enlace con otro objeto. El smbolo que est en la parte superior de la figura representa el estado inicial y el de la parte inferior el estado final.

Figura 6 Diagrama de estados UML

Diagrama de secuencias Representa una interaccin de objetos entre s. Muestra la mecnica de la interaccin con base en tiempos.

Figura 7 Diagrama de secuencias UML

Diagrama de actividades Es una representacio n de una serie de acciones dentro de uno o varios hilos de proceso condicionadas por unos nodos de control

Figura 8 Diagrama de actividades UML

Diagrama de colaboraciones Esta diseado con el fin de representar cmo trabajan en conjunto los elementos de un sistema para cumplir con los objetivos del sistema.

Figura 9 Diagrama de colaboraciones UML

Diagrama de componentes Los diagramas de componentes describen los elementos fisicos del sistema y sus relaciones. Muestran las opciones de realizacio n incluyendo co digo fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricacio n de aplicaciones informa ticas , pueden ser simples archivos, paquetes, bibliotecas cargadas dina micamente, etc.

Figura 10 Diagrama de componentes UML

Diagrama de distribucin Muestra la arquitectura fsica de un sistema informtico. Puede representar los equipos y dispositivos, mostrar sus interconexiones y el software que se encontrar en cada mquina. Cada computadora est representada por un cubo y las interacciones entre las computadoras estn representadas por lneas que conectan a los cubos.

Figura 11 Diagrama de distribucin UML

Diagramas de Paquetes Los diagramas de paquetes se usan para reflejar la organizacin de paquetes y sus elementos. Cuando se usan para representaciones, los diagramas de paquete de los elementos de clase se usan para proveer una visualizacin de los espacios de nombres. Los usos ms comunes para los diagramas de paquete son para organizar diagramas de casos de uso y diagramas de clase.

Figura 12 Diagrama Paquete UML

Nota UML ser til para presentar una clara explicacin del porqu un diagrama esta all o la manera en que trabaja. Imaginando a una nota como el equivalente de un papel adhesivo. La nota es un rectngulo con una esquina doblada, y dentro del rectngulo se coloca la explicacin. Se adjunta la nota al elemento del diagrama conectndolos mediante una lnea discontinua.

Figura 13 Nota UML

Estereotipos Un estereotipo le permite crear nuevos elementos a partir de otros existentes. El concepto de una interfaz provee un buen ejemplo de un estereotipo. Una interfaz es una clase que realiza operaciones y que no tiene atributos, es un conjunto de acciones que tal vez quiera utilizar una y otra vez en su modelo. La forma de representar un esteriotipo es en el smbolo de una clase con <<Interfaz>> situada justo sobre el nombre de la clase. El modelo de interfaces especifica co mo interactu a el software por construir con actores externos al ejecutar los casos de uso; en particular, en los sistemas de informacio n ricos en interaccio n con el usuario, especifica co mo se visualizara n

las interfaces gra ficas de usuario y que funcionalidad ofrecera cada una de ellas (Weitzenfeld, 2005)

Figura 14 Estereotipo UML

Anlisis y Diseo Orientado a Objetos con UML

La orientacin a objetos es un paradigma que depende de algunos principios fundamentales. Un objeto es una instancia de una clase. Una clase es una categora genrica de objetos que tienen los mismos atributos y acciones. Cuando crea un objeto, el rea del problema en que trabaje determinara cuantos de los atributos y acciones debe tomar en cuenta. Cuando se desea analizar con el UML es importante entender los conceptos como los siguientes: La herencia es un aspecto importante de la orientacin a objetos, un objeto hereda los atributos y operaciones de su clase. Una clase tambin puede heredar atributos y acciones de otras. El polimorfismo es otro aspecto importante, ya que especifica que una accin puede tener el mismo nombre en diferentes clases y cada clase ejecutara tal operacin de forma distinta. Los objetos funcionan en conjunto mediante el envo de mensajes entre ellos. Los mensajes son peticiones para realizar operaciones. Por lo general, los objetos se asocian entre si y esta asociacin puede ser de diversos tipos. Un objeto en una clase puede asociarse con cualquier cantidad de objetos distintos en otra clase. La agregacin es un tipo de asociacin. Un objeto agregado consta de un conjunto de objetos que lo componen y una composicin es un tipo especial de agregacin. En un objeto compuesto, los componentes solo existen como parte del objeto compuesto. Para desarrollar un diseo de sistema desde el concepto hasta el diseo detallado orientado a objetos, hay muchas cuestiones por hacer: 1. Comprender y definir el contexto y las interacciones externas con el sistema. 2. Disear la arquitectura del sistema.

3. Identificar los objetos principales en el sistema. 4. Desarrollar modelos de diseo. 5. Especificar interfaces. El diseo no es un proceso secuencias tajante, se desarrolla al obtener ideas, proponer soluciones y corregirlas conforme la informacin se encuentra disponible.

Lenguaje de restriccin de objetos (OCL)

OCL es un lenguaje declarativo: a partir del cual se establece que debe ser hecho por el sistema, y no como debe ser hecho OCL es un lenguaje tipado. Todas las expresiones y subexpresiones tienen un tipo y se requiere conformidad de tipo. La clave de especificar modelos precisos, completos, detallados y consistentes es la construccin de modelos combinados UML/OCL Ejemplos de su utilidad: Definir precisamente un modelo expresado a partir de diagramas UML (diagramas de clase, diagrama de transicin de estados, casos de uso, etc.) Expresar la semntica de UML Especificar reglas de negocio Definir precisamente mtricas para modelos UML Definir precisamente estereotipos

OCL tiene sus palabras reservadas para referirse a objetos, restricciones, funciones entre otros. Los resultados obtenidos en varios ejemplos demuestran que usar OCL en el chequeo de reglas de consistencia del modelo UML es un muy buen acercamiento, ya que define todo lo concerniente a las reglas de consistencia de modelos UML en el nivel del metamodelo.

OCL Y UML en accin

Figura 15 Diagramas Casos de Uso y Clases

Classifier seif.UseCase->exists(us: Usecase, c: Class, x: integer, y: Integer | y > x and us.name.toUpper.substring(x,y)=c.name.toUpper)

3. Patrones de diseo
Introduccin a los Patrones de Diseo
Los patrones de diseo se derivaron de ideas planteadas por Christopher Alexander (Alexander et al., 1977), quien sugiri que haba ciertos patrones comunes de diseo de construccin que eran relativamente agradables y efectivos. Segn Christopher Alexander, cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, as como la solucin a ese problema, de tal modo que se pueda aplicar esta solucin un milln de veces, sin hacer lo mismo dos veces. Aunque se refera a patrones en ciudades y edificios, lo que dice tambin es vlido para patrones de diseo orientados a objetos. Los cuatro elementos de un patro n: El nombre, el problema, la solucio n y la consecuencia 1) El nombre del patro n: describe un problema con una o dos palabras, sus soluciones y la consecuencia. a. Nombrar un patro n incrementa los vocabularios de disen o. b. Nos permite disen ar con abstraccio n de un nivel ma s alta. 2) El problema: describe cua ndo se puede aplicar el patro n. Explica el problema y su contexto. a. Problemas especificos: tales co mo representar los algorit mos con objetos. b. Clases o estructuras de objetos que son sintoma ticas de un disen o inflexible. c. Una lista de condiciones que se tienen que satisfacer antes de aplicar el patro n. 3) La solucio n: describe los elementos que forman el disen o, sus relaciones, responsabilidades y cooperaciones. a. No describe ningu n disen o concreto. b. Un patro n es una plantilla para muchas situaciones diferentes. c. Un patro n dispone la descripcio n abstracta de un problema de disen o y co mo se resuelve con elementos (clases y objetos) generales. 4) Las consecuencias: los buenos resultados e inconvenientes de aplicar el patro n. a. Para evaluar las soluciones del patro n y entender los costes y beneficios de aplicar el patro n. b. El equilibrio entre el espacio y el tiempo. c. Puede tratar asuntos de lenguajes e implementaciones. d. El impacto sobre la flexibilidad, extensibilidad y portabilidad.

Estudio del catlogo de patrones

Un cata logo de patrones es una clasificacio n de un conjunto de patrones utilizando uno o ma s criterios, permitiendo que la bu squeda de una solucio n a un problema concreto sea ma s sencilla. Siguiendo con la analogia de los patrones de confeccio n textil, seria como organizar los patrones textiles por criterios tales como el tipo de prenda que queremos confeccionar (p.e. blusas, vestidos, faldas, pantalones) o por el tipo de elemento a confeccionar (p.e. perneras, cuerpos, mangas). El uso del cata logo consistiria en determinar primero que problema queremos resolver (p.e. confeccionar una blusa o la manga de una blusa), ir a esa categoria o interseccio n de categorias (p.e. blusas de manga larga, manga corta, sin manga, con pun o, sin pun o) y seleccionar de entre los patrones que se encuentran en dicha categoria, el patro n o patrones que mejor se ajusta a las necesidades especificas de nuestro problema. Por ejemplo, para confeccionar una blusa de manga con pun o abotonado probablemente usaremos un patro n para la blusa, otro para la manga con pun o y un tercer patro n para el pun o abotonado. Un cata logo presenta una coleccio n de soluciones relativamente independientes, mientras que un lenguaje de patrones es una organizacio n ma s compleja, en la cual subyace tambie n el conocimiento de co mo aplicar un conjunto de patrones y en que orden hay que hacerlo para que el proceso sea lo ma s efectivo posible. Esta efectividad resulta obvia si se cuenta con suficiente experiencia, pero es dificil de documentar y transmitir a los no expertos. La coleccio n de patrones que se recopilan en un lenguaje no son complet amente independientes, ya que tienen como objetivo comu n la resolucio n de un problema complejo (p.e. la confeccio n de una blusa), y por ello esta n interconectados entre si. Cada patro n resuelve parte del problema y guia hacia otros problemas que deben ser considerados (p.e. el patro n de la blusa nos llevara a elegir patrones para el cuerpo delantero, el cuerpo trasero, las mangas y el cuello). Asi se forma una red donde cada patro n depende de los patrones de menor escala que contiene (p.e. el patro n manga contiene el patro n pun o) y de los patrones de mayor escala en los que esta contenido (p.e. el patro n manga depende del patro n blusa), ayudando al disen ador a navegar entre la red de patrones para seleccionar aquellos que ayudan a solucionar de manera completa y satisfactoria un determinado problema. Si bien al hablar de confeccio n textil las relaciones pueden parecer obvias, las interrelaciones entre patrones software no son tan obvias para el disen ador, ma xime cuando nos encontramos con un dominio de disen o como el e-learning en el que se precisa conocimiento multidisciplinar. Es en este tipo de casos donde los lenguajes pueden demostrar su potencial utilidad, ayudando al disen ador novato a percibir problemas que ni siquiera imaginaba que podian existir, por estar e stos dentro de un a mbito de conocimiento ajeno a su especialidad.

Figura 16 Catlogo de patrones de diseo de Gamma et al. (1994)

Figura 17 Patrones organizados por niveles de uso

Los patrones de diseo resuelven muchos de los problemas diarios con los que se enfrentan los diseadores orientados a objeto, y lo hacen de formas diferentes. El modelado estricto del mundo real conduce a un sistema que refleja las realidades presentes pero no necesariamente las futuras. Las abstracciones que surgen durante el diseo son fundamentales para lograr un diseo flexible. Los patrones de diseo ayudan a identificar abstracciones menos obvias y los objetos que las expresan. Por ejemplo, los objetos que representan un proceso o algoritmo no tienen lugar en la naturaleza, y sin embargo son una parte crucial de los diseos flexibles. El patrn Strategy describe cmo implementar familias intercambiables de algoritmos. El patrn State representa cada estado de una entidad como un objeto.

Estos objetos rara vez se encuentran durante el anlisis o incluso en las primeras etapas del diseo; son descubiertos ms tarde, mientras se trata de hacer al diseo ms exible y reutilizable. El patrn Facade describe cmo representar subsistemas completos como objetos. El patrn Flyweight describe cmo permitir un gran nmero de objetos de granularidad muy na.

Otros patrones de diseo describen formas concretas de descomponer un objeto en otros ms pequeos. Los patrones Abstract Factory y Builder producen objetos cuya nica responsabilidad es crear otros objetos. El patrn Visitor y el Command dan lugar a objetos cuya nica responsabilidad es implementar una peticin en otro objeto o grupo de objetos.

Los patrones de diseo ayudan a denir interfaces identicando sus elementos clave y los tipos de datos que se envan a la interfaz. Un patrn de diseo tambin puede decir qu no debemos poner en la interfaz. El patrn Memento (Recuerdo) es un buen ejemplo de esto. Dicho patrn describe cmo encapsular y guardar el estado interno de un objeto para que ste pueda volver a ese estado posteriomente. El patrn estipula que los objetos Recuerdo deben denir dos interfaces: una restringida, que permita a los clientes albergar y copiar el estado a recordar, y otra protegida que slo pueda usar el objeto original para almacenar y recuperar dicho estado. Los patrones de diseo tambin especican relaciones entre interfaces. En concreto, muchas veces requieren que algunas clases tengan interfaces parecidas, o imponen restricciones a las interfaces de algunas clases. Por ejemplo, tanto el patrn Decorator como el Proxy requieren que las interfaces de los objetos Decorador y Proxy sean idnticos a los objetos decorado y representado, respectivamente. En el patrn Visitor, la interfaz Visitante debe reejar todas las clases de objeto que pueden ser visitados.

Figura 18 Relaciones entre los Patrones de Diseo

Anlisis y Diseo utilizando Patrones de Diseo

Para utilizar patrones en su diseo, se debe reconocer que cualquier problema de diseo que enfrente es posible que tenga un patrn asociado para aplicarse. 1) Sealar a varios objetos que cambiaron el estado de algn otro objeto. 2) Ordenar las interfaces en un nmero de objetos relacionados que a menudo se hayan desarrollado incrementalmente. 3) Proporcionar una forma estndar para ingresar a los elementos en una coleccin, sin importar cmo se implement dicha coleccin. 4) Permitir la posibilidad de extender la funcionalidad de una clase existente en tiempo de operacin. Los patrones soportan reutilizacin de concepto de alto nivel. Cuando intente reutilizar componentes ejecutables, estar restringido por decisiones de diseo detalladas que los implementadotes tomaron de dichos componentes. stas varan desde los algoritmos particulares usados para implementar los componentes, hasta los objetos y tipos en las interfaces del componente. Cuando dichas decisiones de diseo entran en conflicto con los requerimientos particulares, la reutilizacin de componentes resulta imposible o introduce ineficiencias en su sistema. El uso de patrones significa que se reutilizan las ideas, pero podra adaptar la implementacin para ajustarse al sistema que se desarrolla. El uso de patrones en un proceso de diseo implica el desarrollo de un diseo, experimentar un problema y luego, reconocer que puede usarse un patrn. Los patrones son una gran idea, pero para usarlos de manera efectiva se necesita experiencia en el diseo de software. Hay que reconocer las situaciones donde se aplicara un patrn.

4. Sistemas de tiempo Real Orientado a Objetos

Introduccin a Sistemas de tiempo real Orientado a Objetos
Un sistema de software de tiempo real es un sistema cuya correcta operacin depende tanto de los resultados producidos por el sistema como del tiempo en que se producen dichos resultados. Un sistema blando de tiempo real es un sistema cuya operacin se degrada si los resultados no se producen de acuerdo con los requerimientos de tiempo especificados. Si los resultados no se producen segn la especificacin de tiempo en un sistema dura de tiempo real, se considera una falla del sistema. La respuesta en tiempo real es la diferencia crtica entre los sistema embebidos y otros sistemas de software, tales como los sistemas de informacin, los basados en la Web o los de software personal, cuyo propsito fundamental es el procesamiento de datos. Para sistemas que no son de tiempo real, la correccin de un sistema se puede definir al especificar cmo las entradas del sistema se mapean a las salidas correspondientes que debe producir el sistema. En respuesta a una entrada, el sistema debe generar una salida correspondiente y, muchas veces, deben almacenarse algunos datos.

Los sistemas embebidos por lo general operan de manera continua, es decir, su operacin no tiene fin. Comienzan cuando el hardware se activa y deben ejecutarse hasta que el hardware se desactiva. Esto significa que tambin pueden usarse tcnicas para ingeniera de software fiable, para garantizar la operacin continua. El sistema de tiempo real puede incluir mecanismos de actualizacin que soporten reconfiguracin dinmica, de forma que el sistema pueda actualizarse mientras se encuentra en servicio. Los conflictos de proteccin y fiabilidad pueden dominar el diseo del sistema. Muchos sistemas embebidos controlan dispositivos cuyas fallas pueden tener altos costos humanos o econmicos. Por lo tanto, la confiabilidad es crtica y el diseo del sistema debe garantizar comportamiento crtico para la proteccin en todo momento. Con frecuencia, esto conduce al diseo a un enfoque conservador, en el que se usan tcnicas de probada eficacia en vez de tcnicas ms recientes que pueden introducir nuevo modos de falla.

Anlisis de Requerimientos de Sistema de Tiempo Real O. O.

Algunos requisitos temporales del Sistema de Tiempo Real Orientado a Objetos son los siguientes: Tiempo Real Crtico: una sola respuesta fuera de plazo hace que el sistema sea incorrecto. Tiempo Real Acrtico: se puede tolerar que se sobrepase algn plazo de forma ocasional.

En un mismo sistema pueden coexistir partes crticas y acrticas. Procesos Peridicos: bajo nivel, testeo de sensores, periodo dependiente de las caractersticas fsicas del sistema. Procesos Aperidicos: Aparecen como causa de eventos dinmicos: fallos, operacin, etc.

Cuando se analizan los requerimientos de temporizacin de los sistemas embebidos de tiempo real y se disean sistemas para cumplir dichos requerimientos, existen tres factores clave que se deben considerar: 1. Plazos: Tiempos en que deben procesarse los estmulos y producir alguna respuesta por parte del sistema. Si no se cumple un plazo, entonces, si es un sistema de tiempo real duro, se trata de una falla de sistema; en un sistema de tiempo real blando, el resultado es un servicio de sistema degradado. 2. Frecuencia: El nmero de veces por segundo que debe ejecutarse un procesa para tener la seguridad de siempre cumplir con los plazos. 3. Tiempo de ejecucin: Tiempo requerido para procesar un estmulo y producir una respuesta. Con frecuencia se debn tomar en cuenta dos tiempo de ejecucin: a. El tiempo de ejecucin promedio de un proceso b. El tiempo de ejecucin del peor escenario para dicho proceso. No siempre el tiempo de ejecucin es el mismo, debido a la ejecucin condicional del cdigo, demoras en espera de otros procesos, etctera. En

un sistema de tiempo real duro, tal vez deba hacer suposiciones con base en el tiempo de ejecucin del peor escenario para asegurarse de que no venzan los plazos. En los sistemas de tiempo real blandos, quiz deba basar sus clculos en el tiempo de ejecucin promedio.

Anlisis: Definicin de la Estructura de Objetos

Componentes de los sistemas integrados incluyen a muchos de los mismos componentes encontrados en las computadoras de escritorio y porttiles. Adems de software y sistemas operativos, sistemas incluyen procesadores, microcontroladores, sensores y de entrada-salida (I / O). Los sistemas de software que se disean para confiabilidad pueden incluir componentes redundantes con la misma funcionalidad que otros componentes del sistema. stos se sustituyen en el sistema a fallar los componentes primarios. Si los componentes redundantes son diversos (distintos de otros componentes), una falla comn de los componentes replicados no derivar en una falla de sistema. Tambin se proporciona redundancia al agregar un cdigo de comprobacin adicional, lo cual no es estrictamente necesario para la funcin del sistema. Este cdigo puede detectar ciertos tipos de fallas antes de que causen daos. Es posible que se requieran mecanismos de recuperacin para garantizar que el sistema contine en ejecucin. En los sistemas para los que la disponibilidad es un requerimiento crtico, por lo general se usan servidores redundantes. stos entran en operacin automticamente al fallar un servidor designado. Algunas veces, para garantizar que los ataques al sistema no puedan detonar una vulnerabilidad comn, dichos servidores son de diversos tipos y funcionan con sistemas operativos distintos. El uso de diferentes sistemas operativos es un ejemplo de diversidad y redundancia de software, donde la funcionalidad comparable se ofrece en diferentes formas.

Anlisis: Definicin de Comportamiento de Objetos

Los modelos de estado son una importante representacin de diseo para sistemas embebidos de tiempo real. Se usan para mostrar cmo reacciona el sistema a su entorno conforme los eventos de activacin cambian el estado del sistema. Existen varios patrones estndar que pueden observarse en diferentes tipos de sistemas embebidos. En ellos se incluye un patrn que monitoriza el entorno del sistema para eventos adversos, un patrn para control de actuador y un patrn de procesamiento de datos. Los diseadores de sistemas de tiempo real tienen que hacer un anlisis de temporizacin (timing), que es dirigido por los plazos para procesar los estmulos y responder a ellos. Tienen que decidir con qu frecuencia debe ejecutar cada proceso en el sistema y el tiempo de ejecucin esperado y del peor escenario para los procesos. Las interacciones con el entorno del sistema son incontrolables e impredecibles. En sistemas interactivos el ritmo de la interaccin se controla mediante el sistema y, al limitar las opciones del usuario, los eventos a procesar se conocen

por adelantado. En contraste, los sistemas embebidos de tiempo real deben responder en cualquier momento a sucesos inesperados. Esto conduce a un diseo de sistemas de tiempo real basado en concurrencia, con algunos procesos que se ejecutan en paralelo. Puede haber limitaciones fsicas que afecten el diseo de un sistema. Ejemplos de esto incluyen las limitaciones en la energa disponible al sistema y al espacio fsico que ocupa el hardware. Dichas limitaciones pueden generar requerimientos para el software embebido, tal como la necesidad de conservar energa y as prolongar la vida de la batera. Las limitaciones de tamao y peso pueden significar que el software debe hacerse cargo de algunas funciones de hardware debido a la necesidad de restringir el nmero de chips usados en el sistema. Tal vez se requiera interaccin directa con el hardware. En los sistemas interactivos y en los sistemas de informacin, hay una capa de software (los controladores del dispositivo) que ocultan el hardware del sistema operativo. Esto es posible porque slo se puede conectar ciertos tipos de dispositivos a dichos sistemas, tales como teclados, ratones, pantallas, etctera. En contraste, los sistemas embebidos deben interactuar con una amplia gama de dispositivos de hardware que no tienen controladores de dispositivos separados.

Diseo de Sistemas de Tiempo Real Orientado a Objetos

No existe un proceso de diseo del sistema embebido estndar. En vez de ello, se usan diferentes procesos que dependen del tipo de sistema, el hardware disponible y la organizacin que desarrolle el sistema. Las siguientes actividades pueden incluirse en un proceso de diseo de software de tiempo real: Seleccin de plataforma Se elige una plataforma de ejecucin para el sistema (hardware y sistema operativo de tiempo real a utilizar). Los factores que influyen dichas elecciones comprenden restricciones de temporizacin sobre el sistema, limitaciones en la energa disponible, experiencia del equipo de desarrollo y precio tope para el sistema entregado. Identificacin de estmulos/respuestas Implica identificar los estmulos que debe procesar el sistema y la respuesta o respuestas asociadas para cada estmulo. Anlisis de temporizacin Para cada estmulo y respuesta asociada se identifican las restricciones de temporizacin que se aplican tanto al estmulo como al procesamiento de la respuesta. Se usan para establecer los plazos de los procesos del sistema. Diseo de procesos En esta etapa se agrega el estmulo y el procesamiento de respuesta en algunos procesos concurrentes. Un buen punto de partida para disear la arquitectura del proceso lo constituyen los patrones arquitectnicos. Posteriormente, se optimiza la arquitectura del proceso para reflejar los requerimientos especficos que deben implementarse.

Diseo de algoritmo Para cada estmulo y respuesta se disean algoritmos que realizan los clculos requeridos. Tal vez se deban desarrollar los diseos de algoritmo en etapas relativamente tempranas del proceso de diseo, para dar un indicio de la cantidad de procesamiento requerido y del tiempo necesario para completar dicho procesamiento. Esto es especialmente importante para tareas de cmputo intenso, como el procesamiento de seales. Diseo de datos Se especifica la informacin que intercambian los procesos y eventos que coordinan el intercambio de informacin, y se disean las estructuras de datos para administrar este intercambio de informacin. Varios procesos concurrentes pueden compartir estas estructuras de datos. Planeacin del proceso Se disea un sistema de planeacin que garantice que los procesos iniciarn a tiempo para cumplir sus plazos.

5.-Administracin de la fundamentacin
La Administracin de la Configuracin del Software (SCM) es la disciplina de identificar la configuracin de un sistema en distintos puntos en el tiempo, con el propsito de controlar sistemticamente cambios en la configuracin del software y mantener la integridad y la rastreabilidad de la configuracin a travs del ciclo de vida del sistema. Tambie n traducida como Gestio n de configuraciones (CM) es el desarrollo y aplicacio n de esta ndares y procedi mientos para gestionar un sistema software evolutivo. Como se expuso en el tema 4 segundo subtema (Anlisis de Requerimientos de Sistemas en Tiempo Real Orientado a Objetos), los requerimientos del sistema siempre cambian durante su desarrollo y su uso, y se tienen que incorporar estos requerimiento s en nuevas versiones del sistema. Es necesario gestionar estos sistemas que evolucionan, porque es fa cil perder la pista de los cambios que se han incorpor ado dentro de cada versio n. Las versiones incorporan propuestas de cambios, correcciones de fallos y, adaptaciones para hardware y sistemas operativos diferentes. Pueden existir varias versiones en desarrollo y en uso al mismo tiempo. Si no se tienen unos procedimientos de gestio n de configuraciones adecuados, se puede hacer un esfuerzo inu til modificando la versio n erro nea de un sistema, entregar una versio n incorrecta a los clientes o perder la pista de do nde ha sido guardado el co digo fuente. Los procedimientos de gestio n de configuraciones definen co mo registrar y procesar los cambios propuestos al sistema, co mo relacionar e stos con los componentes del sistema y los me todos utilizados para identificar las diversas versiones del sistema. Las herramientas de gestio n de configuraciones se utilizan para almacenar las versiones de los componentes del sistema, construir sistemas a partir de estos componentes y llevar el registro de entregas de las versiones del sistema a los clientes.

Algunas veces, la gestio n de configuraciones es parte de un proceso general de gestio n de la calidad del software, donde el mismo gestor comparte las responsabilidades de la gestio n de la calidad y de la configuracio n . Los desarrolladores del software entregan e ste al equipo de garantia de calidad, quienes son responsables de la comprobacio n de que el sistema es de calidad aceptable. Aqui comienza a ser un sistema controlado, lo que significa que los cambios en el sistema tienen que ser acordados y registrados antes de ser implementados. Algunas veces, los sistemas controlados se denominan lineas base puesto que son el punto de inicio para la evolucio n controlada. Hay muchas razones por las que los sistemas existen en diversas configuraciones. E stas se producen para diferentes computadoras, para diferentes sistemas operativos, para incorporar funciones especificas del cliente, etce tera. Los gestores de la configuracio n son responsables de llevar los registros de las diferencias entre las versiones del software, para asegurar que las nuevas versiones se deriven de forma controlada y para entregar las nuevas versiones a los clientes correctos en el momento justo. La definicio n y uso de gestio n de configuraciones es esencial para la certificacio n de calidad ISO 9000 y para los esta ndares C M M y CMMI (Paulk et al, 1995; Ahem et al 2001; Peach, 1996). Un ejemplo de tal esta ndar es el IEEE 828 -1998, que define un esta ndar para los planes de la gestio n de configuraciones. Dentro de una organizacio n, estos esta ndares se publican en un manual de gestio n de configuraciones o como parte del man ual de calidad. Los esta ndares extemos se utilizan como base para esta ndares organizacionales detallados y se ajustan a un entorno especifico.

Conceptos de la fundamentacin
Las cuatro principales funciones de la Gestin de Configuraciones pueden resumirse en: Llevar el control de todos los elementos de configuracin de la infraestructura TI con el adecuado nivel de detalle y gestionar dicha informacin a travs de la Base de Datos de Configuracin (CMDB). Proporcionar informacin precisa sobre la configuracin TI a todos los diferentes procesos de gestin. Interactuar con las Gestiones de Incidentes, Problemas , Cambios y Versiones de manera que estas puedan resolver ms eficientemente las incidencias, encontrar rpidamente la causa de los problemas, realizar los cambios necesarios para su resolucin y mantener actualizada en todo momento la CMDB. Monitorizar peridicamente la configuracin de los sistemas en el entorno de produccin y contrastarla con la almacenada en la CMDB para subsanar discrepancias.

Actividades de la fundamentacin: de los problemas de las decisiones.

Rol responsable Gestin del Gestor de proceso de configuracin gestin de configuracin Identificacin Gestor de de elementos configuracin de configuracin. Actividad Descripcin Documentar el plan de gestin de configuracin Entradas Necesidades del proyecto. Plan del proyecto Productos del de proyecto Salidas Plan de gestin de configuracin aprobado Elementos de configuracin identificados. Linea base. Estructura del directorio de gesitn de configuracin Registro de solicitud de cambio. Solicitud de cambio aprobada. Linea base

Identificar elementos configuracin. Crear estructura del directorio de gestin de configuracin

Mantenimiento y control de la gestin de configuracin

Responsible del elemento de configuracin

Informe de Gestor de estado de la configuracin configuracin Verificacin y Gestor de auditora configuracin

Control de cambios sobre elementos de configuracin y lineas base. Obtener aprobacin de solicitudes de cambio sobre productos de trabajo de linea base Mantener actualizado y publicar el estado de los elementos de configuracin Realizar auditoras de la gestin de configuracin

Peticiones del cambio

Elementos de Informe de configuracin estado de elementos de configuracin Registros de la gestin de configuracin. Linea base. Registro de cambios Informe de auditoria de gestin de configuracin

Tabla 1 Actividades del proceso de gestin de configuracin

Administracin de la fundamentacin
El informe del estado de la configuracin es la actividad de reportar la informacin necesaria para gestionar de forma efectiva la configuracin de software. En esta actividad se disea y opera un sistema para la captura y reporte de la informacin necesaria a medida que avanza el ciclo de vida. Como en cualquier sistema de informacin, la informacin sobre el estado de la configuracin que se quiere gestionar debe ser identificada, recogida y mantenida. Son necesarias diversas mtricas e informacin para dar soporte al proceso de gestin de configuracin. El tipo de informacin disponible incluye la identificacin de configuracin aprobada as como el estado actual de la implementacin de los cambios. Por ejemplo, informacin del tipo: Un registro de documentacin de configuracin aprobada. La designacin de un responsable de los elementos de configuracin del proyecto. El estado de cambios propuestos y desviaciones de la configuracin. La implementacin del estado de los cambios aprobados. La configuracin de todas las unidades de los elementos de configuracin en el inventario. Resultados de las auditoras.

Para llevar a cabo estas actividades de recogida de datos y generacin de informes se hace necesario el soporte de una herramienta automatizada. La actividad de auditora de configuracin de software determina en qu medida un elemento de configuracin satisface sus caractersticas funcionales y fsicas requeridas. Se pueden realizar auditoras de este tipo en puntos clave del ciclo de vida. El resultado satisfactorio de una auditora se puede utilizar como prerrequisito para establecer una lnea base del producto. El objetivo de las auditoras de gestin de configuracin es asegurarse de que: Los elementos de configuracin se encuentran en el directorio apropiado. El estado actual de los elementos de configuracin es consistente. La informacin de lnea base se mantiene de forma correcta. Se verifica la conformidad con estndares y procedimientos aplicables a la gestin de configuracin, por ejemplo, comprobando si se usa la versin correcta del documento de diseo para realizar la codificacin.

Como resultado de la auditora se deber generar un informe donde se registren todas las no conformidades detectadas y as iniciar un plan de mejora para solucionarlas. Despus de una auditora de configuracin exitosa se puede establecer una lnea base del producto. La verificacin no se realiza sobre los propios productos sino que consiste en comprobar que los productos que conforman una lnea base estn gestionados correctamente bajo el control de configuracin, que todos los cambios realizados sobre estos productos han sido registrados y, por tanto, se puede establecer una trazabilidad entre cambios y productos afectados.

Pruebas Orientadas a Objetos

Conceptos de las Pruebas
1. El objetivo es encontrar defectos. El propsito principal de las pruebas es validar la correccin de aquello que se este probando. En otras palabras, las pruebas exitosas encuentran defectos. 2. Se pueden validar todos los artefactos, no solamente el cdigo fuente. Como mnimo usted puede revisar los modelos y documentos y por lo tanto encontrar y corregir los defectos antes que lleguen al cdigo. 3. Probar frecuentemente y temprano. El potencial para el costo del cambio de aumentar exponencialmente lo motiva a probar tan temprano como sea posible (ver artculo "cost of change"). 4. Las pruebas construyen confianza. En "Extreme Programming Explained" Kent Beck realiza una observacin interesante de que cuando usted tiene un suite completa de pruebas ( una suite de pruebas es una coleccin de pruebas), y usted la ejecuta tan frecuentemente como sea posible, entonces eso le da el coraje para avanzar. Muchas personas temen realizar cambios al cdigo porque temen daarlo, pero como una suite completa de pruebas si se daa algo, se sabe que se detectar y entonces se corrige. 5. Probar contra el riesgo de un artefacto. Entre mas riesgoso es algo, mas necesario es que sea revisado y probado. En otras palabras, se debe invertir un gran esfuerzo en probar un sistema de control de trfico areo pero no mucho menos que para probar una aplicacin Hello World . 6. Una prueba vale mil opiniones. Puede decirse que la aplicacin funciona, pero mientras no se muestren los resultados de las pruebas, no ser creble.

Actividades de las Pruebas

La estrategia que se ha de seguir a la hora de evaluar dina micamente un sistema software debe permitir comenzar por los componente ma s simples y ma s pequen os e ir avanzando progresivamente hasta probar todo el software en su conjunto. Ma s concretamente, los pasos a seguir son: 1. Pruebas Unitarias. Comienzan con la prueba de cada mo dulo. 2. Pruebas de Integracio n. A partir del esquema del disen o, los mo dulos probados se vuelven a probar combinados para probar sus interfaces. 3. Prueba del Sistema. El software ensamblado totalmente con cualquier componente hardware que requiere se prueba para comprobar que se cumplen los requisitos funcionales. 4. Pruebas de Aceptacio n. El cliente comprueba que el software funciona segu n sus expectativas. Pruebas Unitarias La prueba de unidad es la primera fase de las pruebas dina micas y se realizan sobre cada mo dulo del software de manera independiente. El objetivo es comprobar que el mo dulo, entendido como una unidad funcional de un programa independiente, esta correctamente codificado. En estas pruebas cada mo dulo sera probado por separado y lo hara , generalmente, la persona que lo

creo. En general, un mo dulo se entiende como un componente software que cumple las siguiente caracteristicas: Debe ser un bloque ba sico de construccio n de programas. Debe implementar una funcio n independiente simple. Podra ser probado al cien por cien por separado. No debera tener ma s de 500 lineas de co digo.

Tanto pruebas de caja blanca como de caja negra han de aplicar para probar de la manera ma s completa posible un mo dulo. No tese que las pruebas de caja negra (los casos de prueba) se pueden especificar antes de que mo dulo sea programado, no asi las pruebas de caja blanca. Pruebas de Integracion Au n cuando los mo dulos de un programa funcionen bien por separado es necesario probarlos conjuntamente: un mo dulo puede tener un efecto adverso o inadvertido sobre otro mo dulo; las subfunciones, cuando se combinan, pueden no producir la funcio n principal deseada; la imprecisio n aceptada individuamente puede crecer hasta niveles inaceptables al combinar los mo dulos; los datos pueden perderse o malinterpretarse entre interfaces, etc. Por lo tanto, es necesario probar el software ensamblando todos los mo dulos probados previamente. E sta es el objetivo de la pruebas de integracio n. A menudo hay una tendencia a intentar una integracio n no incremental; es decir, a combinar todos los mo dulos y probar todo el programa en su conjunto. El resultado puede ser un poco cao tico con un gran conjunto de fallos y la consiguiente dificultad para identificar el mo dulo (o mo dulos) que los provoco . En contra, se puede aplicar la integracio n incremental en la que el programa se prueba en pequen as porciones en las que los fallos son ma s fa ciles de detectar. Existen dos tipos de integracio n incremental, la denominada ascendente y descendente. Veamos los pasos a seguir para cada caso: Integracio n incremental ascendente: 1. Se combinan los mo dulos de bajo nivel en grupos que realicen una subfuncio n especifica 2. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y salida de los casos de prueba. 3. Se prueba el grupo 4. Se eliminan los controladores y se combinan los grupos movie ndose hacia arriba por la estructura del programa. Integracio n incremental descendente: 1. Se usa el mo dulo de control principal como controlador de la prueba, creando resguardos (mo dulos que simulan el funcionamiento de los mo dulos que utiliza el que esta probando) para todos los mo dulos directamente subordinados al mo dulo de control principal.

2. Dependiendo del enfoque e integracio n elegido (es decir, primero -enprofundidad, o primero-en-anchura) se van sustituyendo uno a uno los resguardos subordinados por los mo dulos reales. 3. Se llevan a cabo pruebas cada vez que se integra un nuevo mo dulo. 4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el mo dulo real. Para la generacin de casos de prueba de integracin, ya sea descendente o ascendente se utilizan tcnicas de caja negra. Pruebas del Sistema Este tipo de pruebas tiene como propsito ejercitar profundamente el sistema para verificar que se han integrado adecuadamente todos los elementos del sistema (hardware, otro software, etc.) y que realizan las funciones adecuadas. Concretamente se debe comprobar que: - Se cumplen los requisitos funcionales establecidos. - El funcionamiento y rendimiento de las interfaces hardware, software y de usuario. - La adecuacin de la documentacin de usuario. - Rendimiento y respuesta en condiciones lmite y de sobrecarga. Para la generacio n de casos de prueba de sistema se utilizan te cnicas de caja negra. Este tipo de pruebas se suelen hacer inicialmente en el entrono del desarrollador, denominadas Pruebas Alfa, y seguidamente en el entrono del cliente denominadas Pruebas Beta. Pruebas de Aceptacion A la hora de realizar estas pruebas, el producto esta listo para implantarse en el entorno del cliente. El usuario debe ser el que realice las pruebas, ayudado por personas del equipo de pruebas, siendo deseable, que sea el mismo usuario quien aporte los casos de prueba. Estas pruebas se caracterizan por: - Participacio n activa del usuario, que debe ejecutar los casos de prueba ayudado por miembros del equipo de pruebas. - Esta n enfocadas a probar los requisitos de usuario, o mejor dicho a demostrar que no se cumplen los requisitos, los criterios de aceptacio n o el contrato. Si no se consigue demostrar esto el cliente debera aceptar el producto - Corresponden a la fase final del proceso de desarrollo de software. Es muy recomendable que las pruebas de aceptacio n se realicen en el entorno en que se va a explotar el sistema (incluido el personal que lo maneje). En caso de un producto de intere s general, se realizan pruebas con varios usuarios que reportara n sus valoraciones sobre el producto. Para la generacio n de casos de prueba de aceptacio n se utilizan te cnicas de caja negra.

Pruebas de Regresion La regresio n consiste en la repeticio n selectiva de pruebas para detectar fallos introducidos durante la modificacio n de un sistema o componente de un sistema. Se efectuara n para comprobar que los cambios no han originado efectos adversos no intencionados o que se siguen cumpliendo los requisitos especificados. En las pruebas de regresio n hay que: Probar integramente los mo dulos que se han cambiado. Decidir las pruebas a efectuar para los mo dulos que no han cambiado y que han sido afectados por los cambios producidos.

Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el software, como durante el mantenimiento.

Administracin de las Pruebas

La metodologa de Pruebas Orientada a Objetos para el Ciclo de Vida Completo(en ingles "Full Life-Cycle Object-Oriented Testing", FLOOT) es una coleccin de tcnicas para verificar y validar software orientado a objetos. El ciclo de vida FLOOT, que se puede ver en la Figura 19, indica una amplia variedad de tcnicas que estn disponibles en todos los aspectos del desarrollo de software. La lista de tcnicas no pretende ser completa por el contrario su objetivo es hacer explcito el hecho de que usted cuenta con un amplio rango de opciones disponibles . Es importante entender que aunque el mtodo FLOOT es presentado como una coleccin de fases secuenciales no necesariamente tiene que ser as: las tcnicas de FLOOT pueden ser aplicadas tambin con procesos giles/evolutivos. La razn por la que se presenta FLOOT de una forma tradicional es para poner en claro el hecho de que en realidad usted puede realizar pruebas en todos los aspectos del desarrollo de software no solamente durante la codificacin.

Figura 19 Ciclo de Vida FLOOT

Mtricas Tcnicas para Sistemas Orientados a Objetos

Como en todas las me tricas los objetivos principales de las me tricas OO se derivan del software convencional: comprender mejor la calidad del producto, estimar la efectividad del proceso y mejorar la calidad del trabajo realizado a nivel del proyecto. Lamentablemente, la utilizacio n de me tricas para sistemas orientados a objetos ha progresado con mucha ma s lentitud que la utilizacio n de los dema s me todos OO [Luis A. Laranjeira 90]. Sin embargo, a medida que los sistemas OO van siendo ma s habituales, resulta fundamental que los ingenieros del software dispongan de mecanismos cuantitativos para estimar la calidad de los disen os y la efectividad de los programas OO.

El Propsito de las Mtricas Orientadas a Objetos

Los objetivos principales de las me tricas orientadas a objetos son los mismos que los existentes para las me tricas surgidas para el software estrucutrado: Comprender mejor la calidad del producto Estimar la efectividad del proceso Mejorar la calidad del trabajo realizado en el nivel del proyecto.

Cada uno de estos objetivos es importante en si, pero para el ingeniero de software, la calidad del producto debe de ser lo esencial.

Caractersticas distintivas de las mtricas Orientadas a Objetos

Las me tricas para sistemas OO deben de concordarse a las caracteristicas que distinguen el software OO del software convencional. Berard [Laranjeira 90] define cinco caracteristicas que dan lugar a unas me tricas especializadas: Localizacio n. Es una caracterstica del software que indica la forma que se concentra la informacin dentro de un programa. Las mtricas de software se han centrado en la estructura interna o complejidad de las funciones (p. ej.: longitud del mdulo, cohesin, o complejidad ciclomtica) o bien en la forma en que las funciones se conectan entre s (p. ej.: acoplamiento de mdulos). Las mtricas deberan de ser aplicables a la clase (objeto) como si se tratara de una entidad completa y deben de ser capaces de adaptarse a las relaciones uno-a-muchos y muchos-a-uno. Encapsulamiento. El encapsulamiento influye en las mtricas cambiando el objetivo de la medida, que pasa de ser un nico mdulo a ser un paquete de datos (atributos) y de mdulos de procesamiento (operaciones). Adems, el encapsulamiento impulsa a la medida hasta un nivel de abstraccin ms elevado. Ocultamiento de informacio n. Aquellas mtricas que proporcionen una indicacin del grado en que se ha logrado el ocultamiento proporcionarn una indicacin de la calidad del diseo OO. Herencia. Dado que la herencia es una caracterstica fundamental de muchos sistemas OO, hay muchas mtricas OO que se centran en ella. Esto

se conocer entre los ejemplos que se tratarn ms adelante: se cuentan el nmero de descendientes (nmero de instancias inmediatas de una clase), nmero de predecesores (nmero de generalizaciones inmediatas), y grado de anidamiento de la jerarqua de clases (profundidad de una clase dentro de una jerarqua de herencia) y otros. Te cnicas de abstraccio n de objetos. Dado que una clase es una abstraccin que se puede visualizar con muchos niveles distintos de detalles, y de muchas maneras diferentes, las mtricas OO representan la abstraccin en trminos de medidas de una clase (p.ej.: nmero de instancias por clase por aplicacin).

Mtricas para el modelo de Diseo Orientado a Objetos

A medida que los modelos de disen o OO van creciendo de taman o y complejidad, puede resultar beneficiosa una visio n ma s objetiva de las caracteristicas del disen o, tanto para el disen ador experimentado como para el menos experimentado. Una visio n objetiva del disen o deberia de tener un componente cuantitativo y esto nos lleva a las me tricas OO, en donde se pueden aplicar no solo al modelo de disen o, sino tambie n al modelo de ana lisis [Laranjeira.90].

Mtricas Orientadas a Clases

En el libro de me tricas realizado por Lorenz y Kidd [Laranjeira 90], dividen las me tricas basadas en clases en cuatro categorias: taman o, herencia, valores internos y valores externos. Las me tricas orientadas a taman os para una clase OO se centran en ca lculos de atributos y de operaciones para una clase individual, y promedian los valores para el sistema OO en su totalidad. Las me tricas basadas en herencia se centran en la forma en que se reutilizan las operaciones a lo largo y ancho de la jerarquia de clases. Las me tricas para valores internos de clase examinan la cohesio n y asuntos relacionados con el co digo. Las me tricas orientadas a valores externos examinan el acoplamiento y la reutilizacio n.

Mtricas Orientadas a Operaciones

Los resultados de los u ltimos estudios indican que los me todos tienden a ser pequen os, tanto en te rminos del nu mero de sentencias como en te rminos de su complejidad lo gica [WIL92], lo cual sugiere que la estructura de conectividad de un sistema pueda resultar ma s importante que el contenido de los mo dulos individuales. Existen algunas ideas que pueden llegar a estimarse, se indican a continuacio n tres me tricas sencillas propuestas por Lorenz y Kidd [Pressman 98]: Taman o medio de operacio n (TOavg). El nu mero de mensajes enviados por la operacio n proporciona una alternativa para el taman o de la operacio n. A medida que asciende el nu mero de mensajes enviados por

una u nica operacio n, es posible que las responsabilidades no hayan sido bien estipuladas dentro de la clase. Complejidad de operacio n (CO). La complejidad de una operacio n se consigue calcular empleando cualquiera de las me tricas de complejidad propuestas para el software convencional s abiendo que las operaciones convendrian limitarlas a una responsabilidad especifica, en donde el disen ador deberia esforzarse por mantener el valor de CO tan bajo como sea posible. Nu mero Medio de Para metros por operacio n (NPavg). En cuanto sea ma s grande el nu mero de para metros de la operacio n, sera ma s compleja la colaboracio n entre objetos. En general, NPavg deberia de mantenerse tan bajo como sea posible.

Mtricas para Pruebas Orientadas a Objetos

Binder [Pressman 98] sugiere una amplia gamma de me tricas de disen o que tienen influencia directa en la comprobabilidad de u n sistema OO. Las me tricas se crean en categorias que reflejan caracteristicas de disen o importantes: Encapsulamiento: Carencia de Cohesio n en Me todos (CCM). Cuanto ma s alto sea el valor de CCM, ma s estados tendra n que ser probados para asegurar que los me todos no den lugar a efectos secundarios. Porcentaje Pu blico y Protegido (PPP). Los atributos pu blicos se heredan de otras clases, y por tanto son visibles para esas clases. Los atributos protegidos son una especializacio n y son privados de alguna subclase especifica. Esta me trica indica el porcentaje de atributos de clase que son pu blicos. Unos valores altos de PPP incrementan la probabilidad de efectos colaterales entre clases, y por lo tanto es preciso disen ar comprobaciones que aseguren que se descubran estos efectos colaterales. Acceso Pu blico a Datos miembros (APD). Esta me trica muestra el nu mero de clases (o me todos) que pueden acceder a los atributos de otra clase, violando asi el encapsulamiento. Unos valores altos de APD dan lugar a un potencial de efectos colaterales entre clases. Es preciso disen ar comprobaciones para asegurar que se descubran estos efectos colaterales. Herencia: Nu mero de Clases Raiz (NCR). Esta me trica es un recuento de las jerarquias de clases distintas que se describen en el modelo de disen o, en donde sera preciso desarrollar conjuntos de pruebas para cada una de las clases raiz, y para la correspondiente jerarquia de clases. A medida que crece NCR crece tambie n el esfuerzo de comprobacio n. ADMisio n (ADM). Cuando se utiliza en el contexto 00, la admisio n es una indicacio n de herencia mu ltiple. Cuando la ADM sea mayor a 1, indica que una clase hereda sus atributos y operaciones de ma s de una clase raiz. Siempre que sea posible, es preciso evitar un valor de ADM mayor a 1.

Mtodos Formales
Los mtodos formales son un conjunto de tendencias de desarrollo de software y hardware en donde la especificacin, verificacin y diseo de componentes se realiza mediante notaciones, lenguajes, herramientas y tcnicas basadas en teoras con slido fundamento matemtico.

Conceptos Bsicos
No so lo incluyen fundamentos matema ticos y sobre orientacio n a objetos sino tambie n fundamentos sobre procesos de produccio n de software . Los mtodos formales que se utilizan para describir sistemas de computadoras son tcnicas de base matemtica para describir las propiedades del sistema. Estos mtodos formales proporcionan marcos de referencia en el seno de los cuales las personas pueden especicar, desarrollar y vericar los sistemas de manera sistemtica, en lugar de hacerlo ad hoc. Se dice que un mtodo es formal si posee una base matemtica estable, que normalmente vendr dada por un lenguaje formal de especicacin. Esta base proporciona una forma de denir de manera precisa nociones tales como la consistencia y completitud, y, lo que es aun ms relevante, la especicacin, la implementacin y la correccin.

Conceptos Bsicos
Fundamentos bsicos matemticos Fundamentos sobre OO Proceso de desarrollo de software

Modelos Matemticos
Lgica de primer orden Especificaciones algebraicas Redes de petri Lgica Temporal

Mtodos Formales OO

Mtodos semi-formales
Mtodos generalistas Mtodos orientados a sistemas reactivos Mtodos orientados a componentes

Mtodos Formales
Mtodos basados en lgica de primer orden Mtodos basados en formalismos algebricos Mtodos basados en lgica temporal

Figura 20 Descomposicin de temas por niveles

Preliminares Matemticos
Se pueden encontrar multitud de mtodos y tcnicas formales con lo que los criterios de clasificacin son bastante variados. La clasificacin ms comn se realiza en base al modelo matemtico subyacente en cada mtodo, de esta manera podran clasificarse en: Especificaciones basadas en lgica de primer orden y teora de conjuntos: permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se describen en detalle y sus propiedades se expresan en lgica de primer orden. La semntica de los lenguajes est basada en la teora de conjuntos. Los mtodos de este tipo ms conocidos son: Z, VDM y B. Especificaciones algebraicas: proponen una descripcin de estructuras de datos estableciendo tipos y operaciones sobre esos tipos. Para cada tipo se define un conjunto de valores y operaciones sobre dichos valores. Las operaciones de un tipo se definen a travs de un conjunto de axiomas o ecuaciones que especifican las restricciones que deben satisfacer las operaciones. Mtodos ms conocidos: Larch, OBJ, TADs. Mtodos basados en Redes de Petri: una red de petri es un formalismo basado en autmatas, es decir, un modelo formal basado en flujos de informacin. Permiten expresar eventos concurrentes. Los formalismos basados en redes de petri establecen la nocin de estado de un sistema mediante lugares que pueden contener marcas. Un conjunto de transiciones (con pre y post condiciones) describe la evolucin del sistema entendida como la produccin y consumo de marcas en varios puntos de la red. Mtodos basados en lgica temporal: se usan para especificar sistemas concurrentes y reactivos. Los sistemas reactivos son aquellos que mantienen una continua interaccin con su entorno respondiendo a los estmulos externos y produciendo salidas en respuestas a los mismos, por lo tanto el orden de los eventos en el sistema no es predecible y su ejecucin no tiene por qu terminar. Una especificacin escrita en lgica temporal describe las secuencias admisibles de estado (incluyendo estados concurrentes) para el sistema especificado.

Aplicacin de la Notacin Matemtica para la Especificacin Formal

Existe un supuesto conjunto BLOQUES, que se compone de un conjunto formado por todos los nmeros de bloque, y un conjunto TodosLosBloques, que es un conjunto de bloques entre 1 y BloquesMax. Su estado se modelar mediante dos conjuntos y una sucesin. Los dos conjuntos son usados y libres. Ambos contienen bloques, es decir, el conjunto usados contiene los que se estn utilizando actualmente en los archivos, y el conjunto libres contiene los que estn disponibles para los archivos nuevos. La sucesin contendr los conjuntos de bloques listos para ser liberados procedentes de archivos que se han borrado. El estado se puede describir de la siguiente forma usados, libres: P BLOQUES ColaBloques: seq P BLOQUES

Esta descripcin de estado se asemeja a la declaracin de variables de un programa. Afirma que usados y libres sern los conjuntos de bloques y que ColuBloques ser una sucesin, cada uno de cuyos elementos ser un conjunto de bloques. El invariante de datos se escribir de la siguiente manera:

Los componentes matemticos del invariante de datos se corresponden con los cuatro componentes del lenguaje natural marcados que se han descrito anteriormente. En la primera lnea del invariante de datos se establece que no habr bloques comunes en la coleccin de bloques usados y en la coleccin de bloques libres. En la segunda lnea se establece que la coleccin de bloques usados y de bloques libres ser siempre igual a la coleccin completa de bloques del sistema. La tercera lnea indica que el elemento i-simo de la cola de bloques ser siempre un subconjunto de los bloques usados. La ltima lnea afirma que si dos elementos de la cola de bloques no son iguales, entonces no existirn componentes comunes en estos dos elementos. Los dos ltimos componentes en lenguaje natural del invariante de datos se implementan como consecuencia del hecho consistente en que usados y libres son conjuntos, y por tanto no contendrn duplicados. La primera operacin que se va a definir es la que elimina un elemento de la parte anterior de la cola de bloques. La precondicin es que debe de existir al menos un elemento en la cola: #ColaBloques > O, La postcondicin es que es preciso eliminar la cabeza de la cola y es preciso ubicarla en la coleccin de bloques libres, y es preciso ajustar la cola para mostrar esa eliminacin:

Una convencin que se utiliza en muchos mtodos formales es que el valor de una variable despus de una cierta operacin lleva el signo prima. Por tanto, el primer componente de la expresin anterior afirma que el nuevo conjunto de bloques usados (usados) ser igual al conjunto bloques usados anterior menos los bloques que hayan sido eliminados. El segundo componente afirma que el nuevo conjunto de bloques libres (libres) ser el conjunto viejo de bloques libres despus de aadir la cabeza de la cola de bloques. El tercer componente afirma que la cola nueva de bloques ser igual a la cola del viejo valor de la cola de bloques, es decir, a todos los elementos de la cola salvo el primero. Una segunda operacin es la que se encarga de aadir una cola de bloques BloquesA a la cola de bloques. La precondicin es que BloquesA sea en ese momento un conjunto de bloques usados:

Cmo se pueden representar las precondiciones y las postcondiciones? La postcondicin es que el conjunto de bloques se aade al final de la cola de bloques y el conjunto de bloques libres y usados permanece invariable:

No cabe duda de que la especificacin matemtica de la cola de bloques es considerablemente ms rigurosa que una narracin en lenguaje natural o un modelo grfico. Este rigor adicional requiere un cierto esfuerzo, pero los beneficios ganados a partir de una mejora de la consistencia y de la completitud puedan justificarse para muchos tipos de aplicaciones.

Mtodos formales basados en Objetos

Es importante presentar los me todos formales clasificados por el formalismo matema tico subyacente, por los criterios de orientacio n a objetos considerados y por la integracio n en un entorno de desarrollo de software con uso pra ctico y con existencia o no de herramientas. De esta forma, el lector interesado en el tema podria evaluar de forma efectiva que me todo elegir segu n sus necesidades. El formalismo matema tico subyacente condiciona en gran medida al MFOO. Por ello, se propone una primera clasificacio n de los MFOOs basada en el formalismo matema tico. Se distinguen cuatro catgorias: MFOOs basados en Lo gica de Primer Orden, MFOOs basados en A lgebras, MFOOs basados en Redes de Petri y MFOOs basados en Lo gica Temporal. Una vez realizada la primera clasificacio n se mide el nivel de orientacio n a objeto de tales me todos. Los criterios OO se dividen en dos categorias: criterios basados en objeto y criterios orientados a objeto. Los criterios basados en objeto suministran principalmente encapsulacio n y me todos para acceder al estado de una forma controlada. Los criterios orientados a objetos suministran capacidad de herencia, tipado/subtipado y criterios de genericidad/parametrizacio n. Se han seleccionado un conjunto representativo (no completo) de MFOOs presentes en la literatura. Una vez clasificados los MFOOs, se ha establecido una breve caracterizacio n para cada uno de ellos mediante el uso de tablas. En dichas tablas, la 1a columna indica el criterio o caracteristica estudiado y la 2a columna indica si tal caracteristica se encuentra en lenguaje (valor SI o NO respectivamente) . Tambie n se aceptan los valores SI? y NO? si la caracteristica esta presente parcialmente y ? para situaciones inciertas. La 3a columna permite aclaraciones y comentarios.

Figura 21 Criterios basados en objetos en Object-Z

Figura 22 Criterios basados en objetos en Object-Z

Figura 23 Grado de formalizacin en Object-Z

Ingeniera del Software de Sala Limpia

El enfoque de Sala Limpia
La ingeniera del software de sala limpia es un enfoque formal para el desarrollo del software, que puede dar lugar a un software con una calidad notablemente alta. Emplea la especificacin de estructura de cajas para el modelado de anlisis y diseo, haciendo hincapi en la verificacin de la correccin, ms que en la comprobacin, como mecanismo fundamental para encontrar y eliminar errores. Se aplica una comprobacin estadstica de uso para desarrollar la informacin relativa a la tasa de fallos necesaria para certificar la fiabilidad del producto software. La filosofa de sala limpia es un enfoque riguroso de la ingeniera del software. Se trata de un modelo de proceso del software que hace hincapi en la verificacin matemtica de la correccin, y en la certificacin de la fiabilidad del software. El resultado final es una tasa de fallo extremadamente baja, que sera difcil o imposible de conseguir empleando mtodos menos formales. Una vez asignada la funcionalidad al elemento de software del sistema, el tubo de la sala limpia comienza sus incrementos y se producen las siguientes tareas: Planificacin de incrementos: Permite la calidad temprana y continua interaccin con el usuario. Facilita mejoras de proceso mientras progresa el desarrollo. El acercamiento incremental evita los riesgos inherentes a la integracin tarda en el ciclo de desarrollo. Recoleccin de requisitos: Define requisitos para el producto software, incluyendo funcin, uso, ambiente, y funcionamiento; la parte complementaria constituye el obtener un acuerdo con el cliente en los requisitos como base para la funcin y especificacin de uso. Especificacin de la estructura de cajas: Tres tipos especiales de funciones matemticas son importantes en el desarrollo de sala limpia, debido a su correspondencia y correlacin en el proceso de descomposicin y verificacin. Estas funciones son conocidas como la caja negra, la caja de estado y caja limpia. En la estructura de las cajas se pueden aplicar una variedad de estrategias de descomposicin, adems se puede incluir funcionalidad y orientacin a objeto. Diseo formal: Mediante el uso del enfoque de estructura de cajas, el diseo de sala limpia es una extensin natural y sin discontinuidades de la especificacin. Los participantes proporcionan los objetivos, los criterios de entrada, las tareas, la verificacin, las medidas y los criterios comunes de la salida en los procesos, as como elementos de proceso comn. Verificacin de correccin: El equipo de sala limpia lleva a cabo una serie de rigurosas actividades de verificacin de correccin, las cuales se aplican primero al diseo y despus al cdigo. El propsito del proceso de verificacin de la correccin, es verificar la correccin del incremento asociado al producto de software utilizando tcnicas matemticas. Generacin de cdigo, inspeccin y verificacin: Las especificaciones de estructura de caja que se representan mediante un lenguaje especializado se traducen en un lenguaje de programacin adecuado. Planificacin de la comprobacin estadstica: El propsito es demostrar la aptitud del software para el uso en un experimento estadstico formal. Se la define con respecto a los modelos de uso y a las metas de la

certificacin empleados en el proceso de prueba. Las metas de certificacin, primero establecidas en el plan de medida y refinadas en el plan de prueba de incremento, se pueden expresar en trminos tales como el ndice de confiabilidad del software. Mediante un proceso de refinamiento progresivo, se van refinando las cajas para formar una jerarqua en la cual cada caja tiene una transferencia. Para esto, al interior de la ingeniera del software de sala limpia, se utilizan tres tipos de cajas: Caja negra: Especifica el comportamiento del sistema, o de una parte de un sistema. Caja de estado: Esta caja encapsula los datos de estados y de servicios de forma anloga a los objetos. En esta vista de especificacin, se representan las entradas a la caja de estados y sus salidas. Caja transparente: Las funciones de transicin que estn implicadas en la caja de estados se definen en la caja transparente. La ingeniera del software de sala limpia se diferencia de otros mtodos o paradigmas por las siguientes razones: Hace uso explcito del control estadstico de calidad. Verifica la especificacin del diseo empleando una demostracin de correccin basada en las matemticas. Hace mucho uso de la comprobacin estadstica de utilizacin para descubrir errores de especial incidencia.

Especificacin funcional
Caja Negra Una especificacin de caja negra describe una abstraccin, estmulos y respuestas. La funcin f' se aplica a una secuencia, S*, de entradas (estmulos) y esta funcin los transforma en una salida (respuesta), R. Para componentes sencillos de software, f; puede ser una funcin matemtica, pero en general f se describe empleando el lenguaje natural (o bien un lenguaje de especificacin formal). Muchos de los conceptos introducidos para sistemas orientados a objetos son aplicables tambin para la caja negra. Las abstracciones de datos y las operaciones que manipulan estas abstracciones, se ven encapsuladas por la caja negra. Al igual que una jerarqua de clases, la especificacin de caja negra puede mostrar las jerarquas de utilizacin en que las cajas de nivel inferior heredan las propiedades de las cajas de nivel superior dentro de la estructura de rbol.

Figura 24 Especificacin de caja negra

Caja de estado La caja de estado es una generalizacin sencilla de una mquina de estado. Recordando la descripcin del modelado de comportamiento y de los diagramas de transicin de estados, un estado es algn modo observable de comportamiento del sistema. A medida que se produce el procesamiento, el sistema va respondiendo a sucesos (estmulos) efectuando una transicin que parte del estado y llega a algn nuevo estado. A medida que se efecta la transicin, puede producirse una accin. La caja de estado utiliza una abstraccin de datos para determinar la transicin al estado siguiente (respuesta) que se producir como consecuencia de la transicin.

Figura 25 Una especificacin de caja de estado

La caja de estado contiene una caja negra. El estmulo, S, que se introduce en la caja negra, procede de alguna fuente externa y de un conjunto de estados internos del sistema, T. Mills proporciona una descripcin matemtica de la funcin f, de la caja negra contenida en el seno de la caja de estado:

donde g es una subfuncin que est asociada a un estado especfico t. Cuando se consideran en su conjunto, las parejas de estados y subfunciones (t, g) definen la funcin de caja negra. Caja transparente o limpia La especificacin de caja limpia est ntimamente relacionada con el diseo de procedimientos y con la programacin estructurada. En esencia, la subfuncin g, que se encuentra dentro de la caja de estado, se ve sustituida por las estructuras de programacin estructurada que implementa g.

Figura 26 Una especificacin de caja transparente

Como ejemplo, considrese la caja limpia que se muestra en la Figura 26 La caja negra g, que se muestra en Figura 25 se ve sustituida por una sucesin de estructuras que contienen una estructura condicional. stas, a su vez, se pueden refinar para formar cajas transparentes del interior a medida que vaya avanzando el procedimiento de refinamiento progresivo. Es importante tener en cuenta que la especificacin de procedimientos descrita en la jerarqua de caja limpia se puede demostrar a efectos de correccin. Este tema se considerar en la seccin siguiente Refinamient o y verificacin del diseo.

Refinamiento y verificacin del Diseo

El enfoque del disen o que se utiliza en la ingenieria del software de sala limpia hace mucho uso de la filosofia de programacio n estructurada. Pero dicha programacio n se aplica mucho ma s rigurosa. Las funciones ba sicas de procesamiento se refinan ahora utilizando una expansio n progresiva de funciones matema ticas en estructuras de conectivas lo gicas y subfunciones, en donde la expansio n se efectu a hasta que todas las funciones identificadas pudieran ser enunciadas directamente en el lenguaje de programacio n utilizado para la implementacio n Cada especificacio n de caja transparente representa el disen o de un procedimiento necesario para efectuar una transicio n de caja de estado. Mediante la caja transparente, se utilizan las estructuras de programacio n estructurada y de refinamiento progresivo.

Figura 27 Refinamiento progresivo

En cada nivel de refinamiento, el equipo de sala limpia lleva a cabo una verificacio n formal de correccio n. Para lograr esto, se asocia un conjunto de condiciones gene ricas de correccio n a las estructuras de programacio n estructurada. Si se expande una funcio n f para dar sucesio n a g y h entonces la condicio n de correccio n para todas las entradas de f es:

Es cierto que g seguido por h da lugar a f? Si se refina una funcio n p para llegar a una estructura condicional (si -entoncessino), la condicio n de correccio n para toda entrada de p es: Siempre que sea cierta la condicion (c) es ciert o que q realiza p y siempre que (c) sea falsa, es cierto que y realiza p? Si se refina una funcio n m en forma de bucle, las condiciones de correccin para todas las entradas de m son: Esta garantizada la finalizacion? Siempre que (c) sea verdadera es cierto que n seguido por m, siempre que (c) sea falso sigue realizandose m si se obvia el bucle? Cada vez que se refina una caja limpia hasta el siguiente nive l de detalle, se aplican las condiciones de correccio n indicadas anteriormente.

Prueba de Sala Limpia

Es algo fundamentalmente distinto de los enfoques convencionales de comprobacio n. Los me todos convencionales derivan de un conjunto de casos de prueba para descubrir errores de disen o y de codificacio n. El objetivo de comprobacio n de sala limpia es validar los requisitos de software mediante la demostracio n de que una muestra estadistica de casos pra cticos se ha ejecutado con e xito. El usuario de un programa no suele necesitar comprender los detalles te cnicos del disen o. El comportamiento visible para el usuario de ese programa esta controlado por las entradas y sucesos que suelen ser producidos por el usuario. Pero en casos complejos, el espectro posible de entradas y sucesos (casos pra cticos) pueden ser extremadamente variables. Entonces Cua l es el subconjunto de casos pra cticos que verifica adecuadamente el comportamiento del programa? E sta es la primera cuestio n que aborda la prueba estadistica de casos pra cticos. La comprobacio n estadistica de casos pra cticos equivale a comprobar el software en la forma en que los usuarios tienen intencio n de utilizarlo. Para lograr esto, los equipos de comprobacio n de sala limpia deben determinar la distribucio n de probabilidad de utilizacio n correspondiente al software. La especificacio n (caja negra) de cada incremento del software se analiza para definir un conjunto de estimulos (entradas o sucesos) que pueden dar lugar a que el software modifique su comportamiento. Basa ndose en entrevistas con usuarios potenciales, en la creacio n de escenarios de utilizacio n, y en una comprensio n general del dominio de la aplicacio n, se asigna una probabilidad de utilizacio n a cada uno de los estimulos. Los casos pra cticos se generan para cada uno de los estimulos de acuerdo con la distribucio n de probabilidad de utilizacio n.

Fuentes de Informacin
Modelado y Diseo Orientados a Objetos, metodologa OMT. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Tcnica de Modelado de Objetos (OMT). J. Rumbaugh. Anlisis y Diseo Orientado a Objetos. Instituto Tecnolgico de la Laguna. Paola Romero Guille n . http://usuarios.multimania.es/nmartinez/omt.htm Metodologa OMT (Object Modeling Technique). Instituto Profesional La Araucana. Nelson y Cia. http://www.slideshare.net/guest5ed375/diagramas-de-estado http://www.vico.org/aRecursosPrivats/UML_TRAD/talleres/mapas/UM LTRAD_101A/LinkedDocuments/UML_diagActividad.pdf OCL Object Constraing Language. Mg. Luis Reynoso http://www.dsi.uclm.es/asignaturas/42530/pdf/M2tema12.pdf Especificacin Formal en OCL de Reglas de Consistencia Entre Los Diagramas de Clases y de Casos de Uso de UML y El Modelo de Interfaces. Revista Ingenieras Universidad de Medellin. Carlos Mario Zapata', Guillermo Gonzlez. Patrones de Diseo, Elementos de Software Orientado a Objetos Reutilizable. Erich gamma et al. http://dmi.uib.es/~yuhua/APOO/Tema1.pdf http://ares.cnice.mec.es/informes/21/versionpdf.pdf Ingeniera de Software. Pearson Tcnicas de Evaluacin de Software. Natalia Juristo, Ana M. Moreno, Sira Vegas http://sophia.javeriana.edu.co/~lcdiaz/ingSw20063/EXP_VersionesCambios_fCamargo_fAragon.pdf http://www.mejorasalproceso.com/docs/IngConfiguracion.htm http://www.ambysoft.com/essays/flootSpanish.html http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/cap itulo6.pdf Me todos Formales Orientados a Objetos . Francisco Jose Gala n Morillo Jose Miguel Can ete Valdeo n http://campusvirtual.unex.es/cala/epistemowikia/index.php?title=Intro duccin_a_los_Mtodos_Formales http://www.utm.mx/edi_anteriores/temas43/1ENSAYO_43_1-R.pdf http://webcache.googleusercontent.com/search?q=cache:R6EiSpiiJusJ:cis .fim.uclv.edu.cu/Bibliografia/libros/ciencia/Ingenieria_de_software/Cap %25A1tulo%252024.pdf+conceptos+b%E1sicos+metodos+formales&cd =4&hl=es-419&ct=clnk&gl=mx&client=safari http://www.lsi.us.es/docs/informes/MFOO.pdf http://aurarivera4.blogspot.mx/2010/11/sala-limpia.html http://aurarivera4.blogspot.mx/2010/11/continuacion-sala-limpia.html http://isoftwareunesum.wordpress.com/2011/04/28/ingenieria-delsoftware-de-sala-limpia/ http://menteerrabunda.blogspot.mx/2008/06/ingeniera-del-softwarede-sala-limpia.html

Gua prctica de gestin de configuracin. Instituto Nacional de Tecnologas de la Comunicacin.