El modelo de anlisis: es una serie de modelos, que se apoyan de texto y diagramas para representar los requisitos de los datos,

las funciones y el comportamiento de una manera que es fcil de entender.

El modelo de anlisis debe cumplir tres objetivos primarios: 1.-Describe lo que quiere el cliente. 2.-Establecer una base para la creacin del diseo de software 3.- Definir un conjunto de requisitos que puedan validarse una vez construido el software

Enfoque del modelado de anlisis 1.-Anlisis estructurado: Los objetos de datos se modelan de una forma que define sus atributos y relaciones. 2.-Anlisis orientado a objetos: Se centra en la definicin de clases y en la manera en que stas colaboran entre elles para lograr los requisitos del sistema.

**Arquitectura de Clases** El modelo de anlisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseo posterior del sistema. diversas arquitecturas que se pueden utilizar, siendo de nuestro inters aquellas arquitecturas especialmente diseadas para el manejo de los sistemas de informacin. En trmino de las propias arquitecturas, stas se distinguen segn la organizacin de la funcionalidad que ofrecen los objetos dentro de ellas o la dimensin de los objetos.

****Modelo de anlisis*** Modelado basado en escenarios-- Representa el sistema desde el punto de vista del usuario.

Modelado orientado al flujo-- Indica la transformacin de los objetos a travs de las funciones de procesamiento. Modelado de comportamiento-- Presenta el estado del sistema y sus clases. Modelado basado en clases-- Define objetos, atributos y relaciones.

En le caso de los sistemas de informacin, uno de las tipos de arquitecturas mas importantes es la arquitectura MVC Modelo, Vista, Control (Model, View, Control). Esta arquitectura se basa en tres dimensiones principales: Modelo (informacin), Vista (presentacin) y Control (comportamiento)

***Identificacin de clases segn Estereotipos*** Clases con Estereotipos El tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de informacin la arquitectura del sistema segn nuestro modelo de anlisis se basa en tres estereotipos bsicos de objetos: El estereotipo entidad ( entity en ingls)para objetos que guarden informacin sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. El estereotipo interface o borde ( boundary en ingls) para objetos que implementen la presentacin o vista correspondiente a las bordes del sistema hacia el mundo externo. El estereotipo control ( control en ingls) para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos

Para llevar a cabo la transicin del modelo de requisitos al modelo de anlisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos como se discuti anteriormente. control. En general, se desea asignar la funcionalidad ms especializada correspondiente a la poltica de la aplicacin a los objetos control, la cual depende y afecta al resto de los objetos. El trabajo del analista consiste en distribuir lo mejor posible el comportamiento especificado en el modelo de requisitos en los diferentes tipos de objetos de la arquitectura de anlisis. En general, los cambios mas comunes a un sistema son los cambios en su funcionalidad Si la funcionalidad esta ligada a la informacin existente, tales cambios afectan al objeto entidad representado esa informacin, o puede involucrar mltiples objetos incluyendo objetos control. A continuacin describimos en ms detalles el proceso de identificacin de los tres tipos de objetos. -----Objetivos Describir lo que requiere el cliente. Establecer base para la creacin de un diseo de Software. Definir conjunto de requisitos que se puedan validar.

----Control o Comportamiento Diagrama transicin de estado (DTE): comportamiento del sistema ante sucesos externos. Especificacin del control (EC) -----Diccionario de datos: Almacn con definiciones de los objetivos de datos del sistema

*-----Atributos: Propiedades del objeto Atributo identificador Clave Entender contexto del problema - Atributos del objeto de datos

*---Relaciones: Conexin entre objetos --Cardinalidad, modalidad y generalizacin (Diagramas entidad-relacin) Cardinalidad Necesidad de representar el numero total de ocurrencias de un objeto relacionado con otro objeto Modalidad Obligatoria y opcional Generalizacin Descomposicin de entidades en subtipos

--Diagramas entidad - relacin Representacin grafica de parejas objeto/relacin

*****Modelado Funcional y flujo de informacin ***** -Transformacin de la informacin Entradas Transformacin (Hardware, Software, Usuario) Salidas

--Diagrama de flujo de datos (DFD) Tcnica de representacin del flujo de informacin y transformacin Permite representacin a diferentes niveles de jerarqua. Se determina como un Modelo funcional dada su optima aplicacin.

---Diagrama de transicin de estados Representa el comportamiento: estados y sucesos que hacen el cambio de estado

--Creacin del diagrama E-R: Forma grafica de mostrar interaccin entre quien realizara la funcin y la operacin a realizar en si. ---Creacin del modelo flujo datos: Una estructura ha seguir para canales de transmisin para informacin

--Definicin Listado organizado de todos los elementos de datos necesarios para el sistema, identificndolos y definindolos exhaustivamente, con la finalidad de

que tanto usuario como analista conozcan exactamente de lo que estn hablando. ---Objetivos Describir lo que requiere el cliente Establecer base para la creacin de un diseo Software Definir conjunto de requisitos que se puedan validar

Atributo codSocio nombre sexo direccion telefonos email

Tipo de dato Integer String Boolean String String string

****clases**** -Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

-En UML, una clase es representada por un rectngulo que posee tres divisiones: -En donde: -Superior: Contiene el nombre de la Clase

 -Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). -Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno (dependiendo de la visibilidad: private, protected o public). *Atributos y Mtodos* -Atributos: Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son: public (+, ): Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-, ): Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar). protected (#, ): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de las subclases que se deriven .

-Mtodos: Los mtodos u operaciones de una clase son la forma en como sta interacta con su entorno, stos pueden tener las caractersticas: public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden accesar). protected (#, ): Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de mtodos de las subclases que se deriven.

3.4Diagramas de secuencias *Diagramas de clases -Los diagramas de clases se utilizan para modelar la vista de diseo esttica de un sistema -Los diagramas de clases contienen los siguientes elementos: -Clases -Interfaces -Colaboraciones -Relaciones de dependencia, generalizacin y asociacin

 -Estos diagramas son los ms importantes del diseo orientado a objetos, son la piedra angular de nuestro diseo. -Contienen toda la informacin de todas las clases y sus relaciones con otras clases. -En el momento de hacer el primer diagrama de clases ya se tiene una lista de clases con algunos de sus atributos y operaciones. Sin embargo es necesario reflexionar y abstraer sobre la organizacin de esas clases estudiando las relaciones de herencia, agregacin, etc. **Diagramas de interaccin** *Son de dos tipos: Diagramas de Secuencia Diagramas de Colaboracin

*Modelan aspectos dinmicos del sistema *Un diagrama de interacciones se usa para realizar una traza de la ejecucin de un escenario *Permiten en las fases inciales de diseo razonar ms en detalle como es el comportamiento de un escenario. *Obtener nuevas clases y objetos en el escenario. *Detectar cuales son los mtodos de las clases, al observar como se relacionan los objetos entre s para llevar a cabo la tarea encomendada en el escenario. *Un diagrama de interaccin muestra una interaccin, que consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos *Un diagrama de secuencia es un diagrama de interaccin que destaca la ordenacin temporal de los mensajes *Un diagrama de colaboracin es un diagrama de interaccin que destaca la organizacin estructural de los objetos que envan y reciben mensajes

Diagramas de Secuencia -Los diagramas de secuencia ilustran la interaccin entre objetos y el orden secuencial en el que ocurren dichas interacciones, es decir como se comunican los objetos entre s. -Los objetos se comunican mediante interfaces, para poder invocar a un operacin.

 -En los Casos de Uso se modelan las caractersticas del sistema y se desarrollan escenarios. -El diagrama de secuencias proporciona un camino a partir de los escenarios para describir las operaciones en una forma ms detallada

****3.5 Diccionario de clases segn mdulos**** Diccionario de Clases Como ltima etapa del modelo de anlisis, se actualiza el diccionario de datos originalmente descrito para el dominio del problema para incluir todas las clases identificadas durante el modelo de anlisis. Aunque no es obligatorio, aprovechamos para separar estas clases en diferentes mdulos para lograr una mejor organizacin y correspondencia entre clases y casos de uso. ***Herramientas CASE para el Anlisis***

-Las herramientas de anlisis y diseo capacitan al ingeniero del software para crear modelos del sistema. Los modelos contienen una representacin de los datos, as como caracterizaciones del diseo de datos, arquitectura, procedimientos e interfaz. -Al efectuar una comprobacin de la consistencia y validez del modelo, las herramientas de anlisis y diseo proporcionan al ingeniero del software un cierto grado de visin en lo tocante a la representacin del anlisis, y le ayudan a eliminar errores antes de que se propaguen al diseo. ***HERRAMIENTAS DE ANLISIS ESTTICO.** SE UTILIZAN TRES TIPOS DISTINTOS DE HERRAMIENTAS ESTTICAS DE COMPROBACIN EN LA INDUSTRIA: -HERRAMIENTAS DE COMPROBACIN BASADAS EN CDIGO: -Cdigo fuente (o PDL) -LENGUAJES DE COMPROBACIN ESPECIALIZADOS: -Capacita al ingeniero del software para escribir detalladas especificaciones de comprobacin que describirn todos los casos de prueba y la logstica de su ejecucin. -HERRAMIENTAS DE COMPROBACIN BASADAS EN REQUISITOS: -Aslan requisitos especficos del usuario y sugieren casos de prueba

*HERRAMIENTAS DE ANLISIS DINMICO.* -Las herramientas de anlisis dinmico interactan con un programa que se est ejecutando, comprueban la cobertura de rutas, comprueban las afirmaciones acerca del valor de variables especificas y en general instrumentan el flujo de ejecucin del programa. Las herramientas dinmicas pueden ser bien intrusivas, bien no intrusivas. *HERRAMIENTAS DE ANLISIS DE RIESGOS* -Las herramientas de anlisis de riesgos capacitan al administrador el proyecto para construir una tabla de riesgos proporcionando una gua detallada en la identificacin y anlisis de riesgos. *EJEMPLOS DE HERRAMIENTAS CASE PARA EL ANALISIS:* -Integrated CASE: Engloban todo el proceso de desarrollo software, desde anlisis hasta implementacin. -Upper CASE: herramientas que ayudan en las fases de planificacin, anlisis de requisitos y estrategia del desarrollo, -Middle CASE: herramientas para automatizar tareas en el anlisis y diseo de la aplicacin. -existen otras no muy conocidas como por ejemplo Visible Analyst, Easy Case, SDesignor ProcessAnalysis