CAPITULO 8 MODELADO DEL ANALISIS

Modelo de Anlisis

En el mbito tcnico, la ingeniera de software comienza con una serie

de tareas 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.

3. 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.

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.

6. 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.

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 comportamiento-

desde 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 como una coleccin organizada de componentes del programa.

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 de datos que persistirn ms all de la ejecucin del software.

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