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
Top Related