CAPITULO 8 MODELADO DEL ANALISIS Modelo de Anlisis En el mbito tcnico, la ingeniera de software comienza con una serie de tareas

s de modelado que conducen a una especificacin de requisitos y a una representacin completa del diseo del software que se construir.

Anlisis de requisitos. Genera la especificacin de caractersticas operacionales del software, indica la interfaz del software con otros elementos del sistema, y establece las restricciones que debe tener el software.

Filosofa y objetivos generales. El modelo de anlisis debe cumplir con tres objetivos primarios: 1. Describir lo que requiere el cliente. 2. Establecer una base para la creacin de un diseo de software. 3. Definir un conjunto de requisitos que puedan validarse una vez construido el software. Reglas prcticas de anlisis. El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. Cada elemento del modelo de anlisis debe agregarse a un acuerdo general de los requisitos del software y proporcionar una visin interna del dominio de informacin. Debe retrasarse la consideracin de la infraestructura y otros modelos no funcionales hasta el diseo. Se debe minimizar el acoplamiento de todo el sistema. Es importante representar las relaciones entre clases y funciones. Se debe tener la seguridad de que el modelo de anlisis proporciona valor a todos los interesados. Cada circunscripcin tiene su propio uso del modelo. El modelo debe mantenerse tan simple como sea posible. No se deben agregar diagramas adicionales cuando estos no ofrezcan informacin nueva.

ENFOQUES DEL MODELADO DEL ANALISIS

Una visin del modelado del anlisis, llamado anlisis estructurado, considera que los datos y el proceso que transforman los datos son entidades separadas. Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Un segundo enfoque del modelado del anlisis, llamado anlisis orientado a objetos, se centra en la definicin de clases y en la manera en que estas colaboran entre ellas para efectuar los requisitos del cliente.

CONCEPTOS DEL MODELADO DE DATOS El modelado del anlisis a menudo comienza con el modelado de datos. El ingeniero o analista de software define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos, adems de otra informacin pertinente para las relaciones. Objetos de datos. Un objeto de datos es una representacin de casi cualquier informacin compuesta que el software debe entender. Atributos. Definen las propiedades de un objeto y toman una de las tres caractersticas diferentes. 1) Nombrar una ocurrencia del objeto de datos. 2) Describir la ocurrencia. 3) Hacer una referencia a otra ocurrencia. Relaciones. Los objetos de datos estn conectados entre si de muchas maneras diferentes.

MODELO BASADO EN ESCENARIOS El xito de un sistema de computadora puede medirse de muchas formas, pero lo ms importante es la satisfaccin del usuario. Si los ingenieros de software entienden la manera en que los usuarios finales quieren interactuar con el sistema, el equipo de software ser capaz de caracterizar de forma apropiada los requisitos y construir modelos significativos de anlisis de diseo. El modelo de anlisis con UML comienza con la creacin de escenarios en la forma de casos de uso, diagramas de actividad y diagramas de carril. Estructura de casos de uso Un caso de uso captura las interacciones que ocurren entre los productores y los consumidores de informacin y del sistema en s mismo. Para que los casos de uso tengan valor como herramienta para el modelado del anlisis deben responderse estas preguntas: 1) Sobre qu escribir?, 2) cunto escribir?, 3) qu tan detallada debe ser la descripcin? y

4) cmo organizar la descripcin? Los casos de uso son simplemente una ayuda para definir lo que existe fuera del sistema (actores) y lo que debera realizar el sistema (casos de uso) Ivar Jacobson Las primeras 2 tareas de la ingeniera de requisitos _inicio y obtencin_ proporcionan la informacin necesaria para comenzar a escribir casos de uso. Las reuniones para recopilacin de requisitos, el despliegue de la funcin de calidad (QFD) y otros mecanismos se utilizan para identificar a los interesados, definir el mbito del problema, especificar las metas operativas globales, esquematizar todos los requisitos funcionales conocidos y describir los objetivos que manipular el sistema. Sobre qu escribir? El desarrollo de una serie de casos de uso comienza haciendo una lista de las actividades que realiza un actor. Estas pueden obtenerse de una lista de funciones requeridas del sistema por medio de conversaciones con los usuarios finales o mediante la evaluacin de los diagramas de actividad desarrollados como parte del modelo de anlisis. Conforme se realizan las conversaciones posteriores con el interesado, el equipo de recopilacin de requisitos desarrolla casos de uso para cada una de las funciones. En general los casos de uso se escriben primero en un estilo narrativo informal. Cada paso en el escenario primario se evala realizando las siguientes preguntas: El actor puede ejecutar otra accin en ste punto?, es posible que el actor encuentre alguna condicin de error?, es posible que el actor encuentre algn otro comportamiento provocado por algn evento fuera de su control? El resultado de las respuestas es la creacin de escenarios secundarios que son parte del caso de uso original pero que representan comportamientos alternativos. Desarrollo de un diagrama de actividad Un diagrama de actividad utiliza rectngulos redondeados para indicar una funcin especfica del sistema, flechas para representar el flujo a travs del sistema, rombos de decisin para mostrar una ramificacin por decisin y las lneas horizontales slidas para indicar que ocurren actividades paralelas. Diagrama de carril Es una variacin del diagrama de actividad que permite la representacin del flujo de actividades descritas por el caso de uso, y al mismo tiempo, indicar que actor o clase de anlisis tiene la responsabilidad de la accin. Las responsabilidades se representan como segmentos paralelos que dividen el diagrama en forma vertical.

MODELO ORIENTADO AL FLUJO Es una de las notaciones de anlisis ms usadas. Aunque los DFD, diagramas y la informacin relacionados no son parte formal de conocimiento adicional de los requisitos y el flujo del sistema. El DFD tiene una visin del sistema del tipo entrada-proceso-salida. Creacin de un modelo de flujo de datos El modelo de flujo de datos es una actividad de modelado esencial en el anlisis estructurado. Unas pocas directrices permiten obtener una ayuda invaluable durante la creacin de un diagrama de flujo de datos. 1. El nivel 0 del DFD debe representar al software/sistema como una sola burbuja. 2. La entrada y la salida primaria deben establecerse con cuidado. 3. La refinacin debe comenzar por el aislamiento de procesos, objetos de datos y almacenes de datos candidatos a ser representados en el siguiente nivel. 4. Todas las flechas y burbujas se deben rotular con nombres significativos. 5. Se debe mantener la continuidad del flujo de informacin al cambiar de nivel a nivel. 6. La refinacin de las burbujas debe hacerse una por una. La refinacin se los DFD contina hasta que cada burbuja realiza una sola funcin, es decir, hasta que el proceso que representa la burbuja desempee una funcin que podra implementarse con facilidad como un componente de programa. Se busca refinar los DFD hasta que cada burbuja tenga "un slo significado". Creacin de un modelo del Flujo En muchos tipos de aplicaciones el modelo de datos y el diagrama de flujo de datos son todos lo que se necesita para obtener una visin significativa de los requisitos del software. Ya se ha mencionado que en un evento o elemento de control se implementa como un valor booleano. En la seleccin de los eventos que son candidatos potenciales se sugiere las siguientes directrices: Hacer una lista de todos los sensores que el software lee. Listar todas las condiciones de interrupcin. Listar todos los interruptores que manejan un operador. Listar todas las condiciones de datos. Revisar todos los elementos de control.

Describir el comportamiento de un sistema mediante la idea. De sus estados Especificacin de Control La Especificacin de control representa el comportamiento del sistema de dos maneras diferentes. La EC contiene un diagrama de estado que es una especificacin secuencial del comportamiento. Tambin puede contener una tabla de activacin del programa: una especificacin combinatoria del comportamiento. Especificacin de Proceso La especificacin de proceso se utiliza para describir todos los procesos del modelo de flujo que aparecen en el nivel final de refinacin. El contenido de la especificacin de proceso puede incluir texto narrativo, una descripcin en lenguaje de diseo de programas del algoritmo del proceso, ecuaciones matemticas, tablas, diagramas o grficas.

MODELADO BASADO EN CLASES

Qu se debe hacer para desarrollar los elementos basados en clases de un modelo de anlisis: clases y objetos, atributos, operaciones, paquetes, modelos CRC y diagramas de colaboracin? Las secciones siguientes presentan una serie de directrices informales que ayudaran a identificarlos y representarlos. Identificacin de clases de anlisis Al observar el interior de una habitacin se ver que existe un conjunto de objetos fsicos que pueden identificarse, clasificarse y definirse con facilidad. Pero cuando se observa el espacio del problema de una aplicacin se software, quiz las clases sean ms difciles de comprender. Coad y Yourdon sugieren seis caractersticas de seleccin que se deben usar cuando un analista considera cada clase potencial para incluirlas en el modelo de anlisis: 1. Informacin referida. La clase potencial ser til durante el anlisis solo si la informacin acerca de ella debe recordarse para que el sistema pueda funcionar.

2.

Servicios requeridos. La clase potencial debe tener un conjunto de operaciones identificables que puedan cambiar el valor de sus atributos de alguna manera. Atributos mltiples. Una clase con un solo atributo puede, de hecho, ser til durante el diseo, pero probablemente es mejor representarla como un atributo de otra clase durante la actividad de anlisis.

3.

4. Atributos comunes. Es posible definir un conjunto de atributos para la clase potencial, y estos atributos pueden aplicarse en todas las instancias de la clase. 5. Operaciones comunes. Es posible definir un conjunto de operaciones para la clase potencial, y estas operaciones pueden aplicarse en todas las instancias de la clase. Requisitos esenciales. Las entidades externas que aparecen en el espacio del problema, y que producen o consumen informacin esencial para la operacin de cualquier solucin para el sistema, se definirn casi siempre como clases en el modelo de requisitos.

6.

Especificacin de atributos Los atributos describen una clase que ha sido seleccionada para incluirla en el modelo de anlisis. En esencia, los atributos son los que definen la clase, lo cual clarifica que significa la clase en el contexto del espacio del problema. Se ha mencionado que el propietario puede configurar la funcin de seguridad para reflejar la informacin del sensor, de la respuesta de alarma, de la activacin / desactivacin, de la identificacin y as sucesivamente.

Definicin de operaciones Las operaciones definen el comportamiento de un objeto. Aunque existen muchos tipos de operaciones, estas se pueden dividir, por lo general, en tres categoras: 1. Operaciones que manipulan los datos de alguna manera 2. Operaciones que realizan un computo 3. Operaciones que preguntan acerca del estado de un objeto. 4. Operaciones que monitorean un objeto para la ocurrencia de un evento de control.

El modelo de comportamiento El modelo de comportamiento indica la forma en que el software responder a los eventos o estmulos externos. En la creacin del modelo el analista debe realizar los siguientes pasos: 1. Evaluar todos los casos de uso para entender por completo la secuencia de interaccin dentro del sistema. 2. Identificar los eventos que conducen la secuencia de interaccin y entender la forma en que estos eventos se relacionan con las clases especficas. 3. Crear una secuencia para cada caso de uso. 4. Construir un diagrama de estado para el sistema. 5. Revisar el modelo de comportamiento para verificar su exactitud y consistencia. Estados de una clase El estado de una clase implica caractersticas tanto pasivas como activas. Un estado pasivo es el estado actual de todos los atributos de un objeto, por ejemplo el estado de la clase Jugador en un juego que incluye los atributos como posicin y orientacin. El estado activo de un objeto indica el estado actual del objeto por ejemplo la clase Jugador puede tener estados activos como: en movimiento, en descanso, herido, etc.

CAPITULO 9 INGENIERIA DEL DISEO

La ingeniera del diseo abarca un conjunto de principios, conceptos y prcticas que conducen al desarrollo de un sistema o un producto de alta calidad. La ingeniera del diseo no es una frase comn dentro del contexto de la ingeniera de software. Sin embargo, debera serlo. El diseo es una actividad primordial de la ingeniera. A principios de la dcada de 1990, Mitch Kapor, el creador de Lotus 1-2-3, present un manifiesto sobre el diseo del software en Dr. Dobbs Journal. Ah afirma: Qu es el diseo? Es el lugar en donde una persona se puede parar con un pie en dos mundos el mundo de la tecnologa y el de la gente y los propsitos humanos e intenta unirlos. El crtico de arquitectura romana Vitruvius aport la nocin de que las construcciones bien diseadas eran aquellas que mostraban firmeza, comodidad y placer. Lo mismo debe decirse del buen software. Firmeza, el programa no debe tener ningn error que inhiba su funcin. Comodidad: un programa debe cumplir con los propsitos para los que fue creado. Placer: la experiencia de usar el programa debe ser agradable.

Diseo dentro del contexto de la ingeniera de software El diseo del software se encuentra en el ncleo tcnico de la respectiva ingeniera y se aplica de manera independiente al modelo de software que se utilice. Una vez que se analizan y especifican los requisitos, el diseo del software es la ltima accin de la ingeniera correspondiente dentro de la actividad del modelado, la cual establece una plataforma para la construccin (generacin de cdigo y pruebas). Richard Due El milagro ms comn de la ingeniera de software es la transicin del anlisis al diseo y del diseo al cdigo. En la figura se ilustra el flujo de informacin durante el diseo del software que muestran los elementos basados en escenarios, basados en clases, orientados al flujo y de comportamiento alimentan la tarea de diseo.

Proceso y calidad del diseo A travs del proceso del diseo, la calidad en evolucin de ste se evala con una serie de revisiones tcnicas formales o con revisiones de diseo, que sugiere tres caractersticas que sirven como gua en la evaluacin de un buen diseo. El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis, y debe ajustarse a todos los requisitos implcitos que desea el cliente. El diseo debe ser una gua legible y comprensible para quienes generan cdigo y quienes realizan pruebas y, en consecuencia, dan soporte a software. El diseo debe proporcionar una imagen completa del software dando direccin a los dominios de datos, funcionales y de comportamientodesde una perspectiva de implementacin.

Conceptos del diseo Abstraccin En los grados de menor abstraccin de una solucin se proporciona una descripcin ms detallada de la solucin. Abstraccin procedimental. Secuencia de instrucciones con funcin especfica y limitada. Ejemplo: Abrir una puerta implica una larga secuencia de pasos procedimentales. Abstraccin de datos. Coleccin nombrada de datos que describe un objeto de datos. Ejemplo: la abstraccin de datos para puerta abarcara una serie de atributos que la describan. Arquitectura La arquitectura es la estructura u organizacin de los componentes del programa, la manera en que estos componentes interactan, y la estructura de datos que utilizan los componentes. 1. Modelos estructurales, representan la arquitectura coleccin organizada de componentes del programa. como una

2. Modelos del marco de trabajo, identifica marcos de trabajo repetibles del diseo arquitectnico que se encuentran en tipos de aplicaciones similares. 3. Modelos dinmicos, indica cmo puede cambiar la estructura del sistema con funcin de los eventos externos. 4. Modelos del proceso, se centran en el diseo del proceso tcnico o de negocios. 5. Modelos funcionales, para representar la jerarqua funcional de un sistema.

Patrones Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, y despus describe la esencia de la solucin a dicho problema, de tal forma que puedas usar esta solucin un milln de veces ms, sin nunca hacerlos dos veces de la misma forma. Cristopher Alexander

Modularidad Es cuando se divide el software en componentes con nombres independientes y que es posible abordar en forma individual. Ocultacin de informacin Los mdulos deben especificarse y disearse de manera que la informacin que est dentro del mdulo sea inaccesible para otros mdulos que no necesiten esa informacin. De esta forma existe una probabilidad menor de introducir errores inadvertidos al realizar las modificaciones y propagarlos a otros lugares dentro del software. Independencia funcional Se desea disear el software de tal manera que cada mdulo aborde una subsuncin especfica de los requisitos y tenga una sola interfaz cuando se observe desde otras partes de la estructura del programa. Refinamiento El desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle procedimentales. El procedimiento se inicia con el enunciado de una funcin que se define con un alto grado de abstraccin. El refinamiento hace que el diseador trabaje sobre el enunciado original y que proporcione ms y ms detalles conforme se realiza cada refinamiento sucesivo. Refabricacin La refabricacin es el proceso de cambiar un sistema de software de tal forma que no se altere el comportamiento externo de su cdigo y an as se mejore su estructura interna. Cuando un software se refabrica el diseo existente se examina en busca de redundancias, elementos de diseo intiles, algoritmos innecesarios o insuficientes, estructuras de datos inapropiadas o construidas de manera incorrecta, o cualquier otra falla de diseo que se pueda corregir para lograr un mejor diseo. Clases de diseo Clases de interfaz con el usuario. Definen todas las abstracciones necesarias para la interaccin humano-computadora (IHC).

Clases de dominio de negocios. Identifican los atributos y servicios necesarios para implementar algn elemento del dominio de negocios. Clases de proceso. Implementan abstracciones del negocio en un nivel ms bajo, las cuales se requieren para manejar por completo las clases de dominio de negocios. Clases persistentes. Representan almacenamientos persistirn ms all de la ejecucin del software. de datos que

Clases de sistema. Implementan funciones de gestin y control del software que permiten que el sistema opere y se comunique dentro de su entorno de computacin y con el mundo exterior.

Resumen CAPITULO 8 MODELADO DEL ANALISIS CAPITULO 9 INGENIERIA DEL DISEO Ingeniera de Software Hora N5