MODELADO DE ANALISIS 1.

ANALISIS DE REQUISITOS o Genera la especificacin de caractersticas operacionales de software; indica la interfaz de software con otros elementos del sistema y establece las establece las restricciones que debe tener el software. o Permite al ingeniero de software construir elementos que representen escenarios del usuario, actividades funcionales, el comportamiento de las clases y, a medida que se transforma, el flujo de datos. o El modelado del anlisis y la especificacin de los requisitos proporcionan al desarrollador y al cliente un medio para evaluar la calidad una vez que el software est construido o El anlisis y modelado de requisitos debe tener un enfoque iterativo, pues se debe modelar lo que se conoce. 1.1. Filosofa y Objetivos generales El modelo de anlisis debe cumplir tres objetivos primarios: o Describir lo que requiere el cliente o Establecer una base para la creacin de un diseo de software o Definir un conjunto de requisitos que puedan validarse una vez construido el software. El modelo del anlisis llena un vaco entre la descripcin a nivel del sistema y el diseo de software. Se debe recordar que algunos elementos del modelo del anlisis estn presentes en la descripcin del sistema y que como parte del anlisis se realiza algn diseo y durante el diseo se realiza algn anlisis 1.2. Reglas Prcticas de Anlisis a. El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. b. Cada elemento del sistema debe agregarse a un acuerdo general de los requisitos de software y proporcionar una visin interna del dominio de informacin, funcin y comportamiento del sistema. c. Debe retrasarse la consideracin de la infraestructura y otros modelos no funcionales hasta el diseo d. Se debe minimizar el acoplamiento de todo el sistema e. Se debe tener la seguridad de que el modelo de anlisis proporciona valor a todos los interesados. f. El modelo debe mantenerse tan simple como sea posible. 1.3. Anlisis del Dominio El anlisis de dominio es la identificacin, el anlisis y la especificacin de requisitos comunes de un dominio de aplicacin especfico para reutilizarlo en mltiples proyectos dentro de ese dominio de aplicacin. El papel del analista de dominio es descubrir y definir patrones de anlisis reutilizables, clases de anlisis e informacin relacionada que pueda usar mucha gente en aplicaciones parecidas. 2. ENFOQUES DEL MODELADO DEL ANALISIS a. Anlisis Estructurado: Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Considera que los datos y procesos son entidades separadas. Los procesos que manipulan los objetos de los datos se modelan de tal manera que se muestran como transforma los datos, mientras los objetos de datos fluyen por el sistemas

b. Anlisis Orientado a Objetos: Se centra en la definicin de clases y en la manera en que stas colaboran entre ellas para efectuar los requisitos del cliente. El modelado del anlisis conduce a la derivacin de cada uno de los elementos del modelado mostrados en la siguiente figura. Sin embargo el contenido especfico de cada elemento puede variar de proyecto a proyecto

Fig. 1 Elementos del Modelado 3. CONCEPTOS DEL MODELADO DE DATOS 3.1. Objetos de Datos.- Es una representacin de casi cualquier informacin compuesta que se procesa con el software. Informacin compuesta se refiere a algo que tiene muchas propiedades o atributos diferentes Ejemplo: dimensiones (alto, ancho, profundidad). o Un objeto de datos puede ser una entidad externa, una cosa, un suceso, o un evento, una unidad organizacional, o una estructura. Ejemplo una persona, un auto. o Un objeto de datos encapsula solo los datos, no incorpora operaciones puedan actuar sobre datos, esto difiere de una clase que comprende atributos y operaciones (mtodos). 3.2. Atributos.- Los atributos definen las propiedades de un objeto de datos, describen sus caractersticas y en algunos casos hacen referencia a otro objeto de datos Se debe definir a uno o ms atributos del objeto como identificador, ste se convierte en una clave para identificar un registro. Ejemplo: cedula, nombre, edad, altura de una persona. 3.3. Relaciones.- La relaciones permiten establecer una conexin entre objetos de datos, indican la manera en que se conectan entre s.

Fig. 2 Relaciones

3.4. Cardinalidad y Modalidad La cardinalidad establece el nmero de objetos que pueden participar en una relacin. Las relaciones de cardinalidad pueden ser: De uno a uno: un Objeto X se relaciona slo con un Objeto Y. De uno a muchos: un Objeto X se relaciona con muchos Objetos Y. De muchos a muchos: muchos Objetos X se relacionan con muchos Objetos Y

Fig. 3 Cardinalidad La Modalidad puede ser 0 o 1: Es de 0 si se trata de una relacin opcional o no es necesario que ocurra la relacin; y, es de 1 cuando la ocurrencia de la relacin en obligatoria 4. ANALISIS ORIENTADO A OBJETOS El objetivo del anlisis orientado a objetos es definir todas las clases (adems de las relaciones y el comportamiento asociado con ellas) relevantes para el problema. Se debe llevar algunas tareas: 1. Deben comunicarse los requisitos bsicos del usuario entre el cliente y el ingeniero de software. 2. Deben identificarse las clases: definir los atributos y mtodos. 3. Se define una jerarqua de clases. 4. Deben representarse las relaciones de objeto a objeto. 5. Debe modelarse el comportamiento del objeto. 5. MODELADO BASADO EN ESCENARIOS El modelado de anlisis con UML comienza con la creacin de escenarios en la forma de casos de uso, diagramas de actividad y diagramas de carril. 5.1. Casos de Uso.- Un caso de uso especifica la manera en la que los actores interactan con el sistema en un conjunto especfico de circunstancias. o Las tareas de inicio y obtencin de la Ingeniera de Requisitos proporciona la informacin para comenzar a escribir los casos de uso. Se debe iniciar haciendo una lista de las funciones o actividades que realiza un actor especfico. o Los Casos de Uso Primarios no consideran los cursos alternativos pero para una comprensin completa de la funcin de deben examinar estos cursos alternativos, esto se logra contestando las siguientes interrogantes El actor puede ejecutar otra accin en este punto? Es posible que aparezca una condicin de error en este punto? De esto se obtiene escenarios secundarios que describen comportamientos alternativos y que son parte del caso de uso original.

Tabla 1: Plantilla para la descripcin de casos de uso

Nombre. Actores Descripcin Precondicin Referencia Curso Normal

Nombre del Caso de Uso Los actores que intervienen en el caso de uso Breve resumen de lo que realiza el caso de uso. Condiciones necesarias para que se produzca el caso de uso Cdigos que especifican que requisitos estn inmersos en el caso de uso

Se describe paso a paso la forma de interaccin del sistema con el usuario, tomando en cuenta el mejor de los casos
5.2. Desarrollo de un Diagrama de Actividad.- Complementa el caso de uso al proporcionar una representacin grfica del flujo de interaccin dentro de un escenario especfico. Un diagrama de actividad en UML representa las acciones y decisiones que ocurren mientras se realiza alguna funcin.

Fig. 4 Diagrama de Actividades 5.3. Diagrama de Carril.- Es una variacin del diagrama de actividad, ya que permite al modelador representar el flujo de actividades descrito por el caso de uso y al mismo tiempo indicar que actor o clases de anlisis tiene la responsabilidad de la accin descrita mediante un rectngulo de actividad. Las responsabilidades se representan como segmentos que dividen el diagrama en forma vertical como los carriles alberca.

Fig. 5 Diagrama de Carril

6. MODELADO ORIENTADO AL FLUJO 6.1. Modelo de Flujo de Datos.- El diagrama de flujo de datos (DFD) permite que el ingeniero de software desarrolle modelos del dominio de informacin y del dominio funcional al mismo tiempo. Tiene una visin del sistema del tipo entrada-proceso-salida. Los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento y los objetos de datos resultantes fluyen al exterior del software.

Fig. 6 Diagrama de Flujo de Datos

Directrices para la creacin de diagramas de flujo de datos: 1. El diagrama de flujo de datos 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 proceso a objetos de datos y almacenamientos 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 a una. 6.2. Modelo de Control del Flujo.- existen una clase muy grandes de aplicaciones que estn guiadas por eventos en lugar de datos, que producen informacin de control en lugar de reportes. Es aqu en donde es necesario aplicar el modelo de control del flujo 6.3. Especificacin de Control (EC).- Representa el comportamiento del sistema de dos maneras diferentes. La EC contiene un diagrama de estado que es una especificacin secuencial de comportamiento. Tambin puede contener un tabla de activacin del programa: una especificacin combinatoria del comportamiento 6.4. Especificacin de Proceso (EP).- 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.

7. MODELO BASADO EN CLASES Una clase orientada a objetos encapsula atributos de los datos pero tambin incorpora las operaciones que manipulan los datos implicados por dichos atributos.

Fig. 7 Representacin de una Clase 7.1. Identificacin de Clases de Anlisis.- Se puede iniciar la identificacin de clases al examinar el enunciado del problema. Las clases se determinan al subrayar los sustantivos e introducirlos en un tabla. Las clases se manifiestas en una de las siguientes formas: entidades externas, cosas, papeles o roles, unidades organizacionales, sitios y estructuras. Un analista debe tomar en cuenta seis caractersticas de seleccin para incluirlas en el modelo de anlisis Informacin requerida Servicios requeridos Atributos mltiples Atributos comunes. Operaciones comunes Requisitos esenciales 7.2. Especificacin de Atributos.- Los atributos definen la clase dentro del contexto del problema. Para especificar los atributos, se debe realizar la siguiente pregunta Cules elementos definen esta clase en el contexto del problema? 7.3. Definicin de Operaciones.- Las operaciones definen el comportamiento de un objeto. Aunque existen muchos tipos distintos de operaciones estas pueden dividir, por lo general, en tres grandes categoras. Operaciones que manipulan los datos de alguna manera. Operaciones que realizan un cmputo. Operaciones que preguntan acerca del estado de un objeto Operaciones que monitorean un objeto para la ocurrencia de un evento de control.

7.4. Modelado de Clase-Responsabilidad-Colaborador (CRC) Proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto. Un modelo CRC es una coleccin de tarjetas ndices estndar que representan clases. El objeto es desarrollar una representacin organizada de las clases.

Fig. 8 Modelo CRC Categoras de Clases: Clases de entidad: llamadas clases de modelo o negocios, se extraen de manera directa del enunciado del problema. Clases de frontera: se utilizan para crear la interfaz que el usuario ve y con la cual interacta cuando se utiliza el software. Clases de controlador: manejan una unidad de trabajo desde el inicio hasta el final. Responsabilidades: son los atributos y las operaciones relevantes para la clase. o La inteligencia del sistema se debe construir entre las clases para abordar de mejor manera las necesidades del problema. o Cada responsabilidad debe establecerse tan general como sea posible. o La informacin y el comportamiento relacionado con ella deben estar dentro de la misma clase o La informacin relativa a una cosa debe localizarse con una sola clase, o distribuirse entre muchas de ellas. o Las responsabilidades pueden compartirse entre las clases relacionadas cuando es apropiado. Colaboradores: son aquellas clases que se requieren para que otra clase reciba la informacin necesaria para completar una responsabilidad, adems identifican las relaciones entre clases. Las colaboraciones se identifican al determinar si una clase puede cumplir cada responsabilidad por s misma. Si no es as, entonces se requiere de la interaccin con otra clase y ende una colaboracin. 7.5. Asociaciones y Dependencias o Asociaciones: define una relacin de entre clases

Fig. 9 Asociacin: Cliente utiliza Cajero Automtico o Dependencia: en el contexto de las clases va ligada a las operaciones, indicando que una clase utiliza otra como argumento en la signatura de una operacin. Las dependencias se definen mediante un estereotipo.

Fig. 10 Dependencia: Para acceder a la cmara necesita contrasea en la Ventana despliegue 7.6. Paquetes de Anlisis.- Los elementos del modelo de anlisis se clasifican (categorizacin) de tal forma que se empaquetan como una agrupacin llamada un paquete de anlisis. Un paquete se utiliza para agrupar una coleccin de clases relacionadas. 8. CREACION DE UN MODELO DE COMPORTAMIENTO Los diagramas de clase, las tarjetas ndice CRC y otros modelos orientados a las clases, representan elementos estticos del modelo de anlisis. 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: o o o o o Evaluar todos los casos de uso para entender por completo la secuencia de interaccin dentro del sistema. Identificar los eventos que conducen la secuencia de interaccin y entender la forma en que estos eventos se relacionan con las clases especficas. Crear una secuencia para cada caso de uso. Construir un diagrama de estado para el sistema. Revisar el modelo de comportamiento para verificar su exactitud y consistencia.

8.1. Diagrama de estado: representa el comportamiento de las clases cuando el sistema realiza sus funciones.

Fig. 11 Diagrama de Estado

8.2. Diagrama de Secuencia: representa el comportamiento al describir la forma en que las clases se mueven de estado a estado

Fig. 12 Diagrama de Secuencia

BIBLIGRAFIA PRESSMAN, Roger. Ingeniera de Software, Capitulo 8. Sexta Edicin, enlace [www.intercambiosvirtuales.org]. pgs. 192-242