ANLISIS DE SISTEMAS - UNIDAD VI

6.1 Anlisis de Sistemas: conceptos y aplicaciones. 6.2 Conceptos fundamentales de Orientacin a Objetos. 6.3 Anlisis de Sistemas orientados a Objetos: Ciclo de Vida de Sistemas usando metodologas orientadas a Objetos. Conceptos.

6.4 Modelo de Requerimientos. Realizacin de un Modelo de Anlisis. Trabajadores, Actividades. 6.5 Vistas de Anlisis orientado a Objetos. 6.6 Realizacin de Casos de Uso: Diagramas de Clases del Anlisis de la realizacin de los Casos de Uso. 6.7 Vista de Casos de Uso. Vista esttica y Vistas Dinmicas. Diagramas de Casos de Uso, de realizacin de Casos de Uso, Clases, Secuencia, Mquina de Estados y Diagrama de Actividades. Diagramas de Paquetes. 6.8 reas 6.9 Clasificaciones de Objetos. Roles. Objetos, mensajes, jerarqua de clases, herencia, polimorfismo. 6.10 El Modelo de Anlisis. Generalizacin y especificacin. Totalidad y partes. Balanceo. 6.11 Resumen de reas, Vistas y Diagramas del Lenguaje de Modelado Unificado (UML). 6.12 Patrones de Anlisis: Patrones de Arquitectura: Capas. Introduccin a Patrones GRASP
6.13 Sntesis Integradora de la Metodologa de Orientacin a Objetos.

6.14 Diccionario de Datos: Consideraciones especficas para la orientacin a objetos. ANLISIS ORIENTADO A OBJETOS: Permite alcanzar un entendimiento ms preciso de los requerimientos. El anlisis usa el lenguaje de los desarrolladores, introduce mayor formalismo que el expresado en la captura de requisitos. Es probable que todava permanezcan problemas no resueltos con respecto a los requerimientos del sistema. Se analizan los requerimientos en mayor profundidad. El anlisis puede ser visto como un primer corte al diseo. A fin de comunicar eficientemente las funciones del sistema al cliente: Los CU deben mantenerse tan independientes unos de otros como sea posible. Los CU deben describirse utilizando el lenguaje del cliente. Debe estructurarse cada CU para que forme una especificacin de funcionalidad completa e intuitiva. Modelo de Casos de Uso Modelo de Anlisis Descrito con el lenguaje del cliente. Descrito con el lenguaje del desarrollador. Vista externa del sistema. Vista interna del sistema. Estructurado por los CU. Estructurado por clases y paquetes Utilizado como contrato entre el cliente y los Utilizado por los desarrolladores para comprender como desarrolladores. se debera disear e implementar el sistema. Puede contener redundancias e inconsistencia entre No debera contener redundancias e inconsistencia entre requerimientos. requerimientos. Captura la funcionalidad del sistema, incluida la Esboza como llevar a cabo la funcionalidad dentro del funcionalidad significativa para la arquitectura. sistema, incluida la funcionalidad significativa para la arquitectura. Sirve como una 1 aproximacin al diseo. Define Casos de Uso que son analizados extensamente Define realizaciones de CU, y cada una de ellas en el modelo de anlisis. representa el anlisis de un CU del modelo de CU.

ARTEFACTOS DEL MODELO DE ANLISIS 1. Modelo de Anlisis: Provee una vista global del sistema. Muy valioso para nuevos desarrolladores o quienes deben mantenerlo. Es un modelo compartido para diferentes diseos o implementaciones (distintos lenguajes y plataformas). Resultado del anlisis orientado a objeto: modelo de anlisis. La estructura de los requisitos que proporciona el anlisis tambin sirve como entrada fundamental para dar forma al sistema en su totalidad (incluida su arquitectura). El anlisis nos proporciona una estructura centrada en el mantenimiento, en aspectos tales como la flexibilidad ante los cambios y la reutilizacin. Pero esta estructura no siempre se puede conservar, sino que se debe negociar y comprometer durante el diseo y la implementacin.

2. Clase del Anlisis: Representa una abstraccin de una o varias clases y/o subsistemas. Se focalizan sobre la manipulacin de los requerimientos funcionales, y pospone los no funcionales. Rara vez provee alguna interfaz en trminos de operaciones y signaturas. Su comportamiento es definido por responsabilidades a alto nivel de abstraccin (descripcin textual de un subcito cohesivo del comportamiento). Estereotipos: 2.1 Clase Interfaz: Modela la interaccin entre el sistema y el actor. Tienen mayormente mtodos y no atributos (solo puede tener uno y para identificarlo). (Capa presentacin). Responsable de interactuar con el usuario y con las otras capas. 2.2 Clase Entidad: Modela informacin que posee una vida larga y que es persistente. Tiene atributos y mtodos. (Capa de acceso a recursos/datos). Responsable de gestionar la informacin. 2.3 Clase Control: Representa coordinacin, secuencia, transaccin y control de otros objetos. Tienen mayormente mtodos y no atributos (Solo puede tener uno y para identificarlo). Se usan para implementar las reglas de negocio. (Capa lgica de aplicacin). Responsable de implementar las operaciones requeridas por el usuario. 2.3.1 Experto: es aquel elemento que realiza toda la lgica del programa. 3. Realizacin de CU-Anlisis: Es una colaboracin dentro del modelo de anlisis que describe como se lleva a cabo y se ejecuta un CU determinado en trminos de las clases del anlisis y de los objetos del anlisis en interaccin. Una realizacin de CU proporciona una traza directa hacia un CU concreto del modelo de CU. Se centra de manera natural en los requisitos funcionales, ya que se basa en las clases del anlisis, por lo tanto pospone el tratamiento de los no funcionales. Cuando hablo de una realizacin es la imaginacin de una ejecucin de un CU en funcin de las clases del anlisis. Colaboracin: es una descripcin de una coleccin de objetos que interactan para implementar un cierto comportamiento dentro de un contexto. 3.1 Diagrama de clases de la realizacin: Se hace con clases de anlisis. 3.2 Diagramas de interaccin: Cuidado se hace con clases de anlisis. 3.3 Flujos de sucesos-anlisis: Descripcin textual. 3.4 Requisitos Especiales: Descripcin textual que recoge los requisitos no funcionales. 4. Paquetes Del Anlisis: Los paquetes de anlisis proporcionan un medio para organizar los artefactos del modelo de anlisis en piezas manejables. Puede constar de clases de anlisis, realizaciones de CU es incluso otros paquetes. Los paquetes de anlisis deberan ser cohesivos y dbilmente acoplados. Paquetes: 4.1 Paquetes Funcionales: (ver si son uno o dos) 4.1 Paquetes de servicios: Contienen un conjunto de clases relacionadas funcionalmente, estos paquetes son indivisibles, reutilizables y son fundamentales para el diseo y la implementacin. (Ej.: validacin y mantenimiento de usuario) 5. Descripcin de la Arquitectura (Vista del modelo de anlisis): Podemos ver la descomposicin del modelo de anlisis en paquetes de anlisis y sus dependencias; las clases fundamentales del anlisis y las realizaciones de CU. Trabajadores: 1. Arquitectos: Es el responsable de la integridad y la arquitectura del modelo de anlisis, garantizando que ste sea correcto, consistente y legible como un todo. El modelo de anlisis es correcto si cumple con el modelo de CU. 2. Ingeniero de CU: Es responsable de la integridad de una o ms realizaciones de CU, garantizando que cumplen los requisitos que recaen sobre ellos. 3. Ingeniero de Componentes: Se encarga de definir y mantener las responsabilidades, atributos, relaciones y requisitos especiales de una o varias clases y paquetes de anlisis, asegurndose de que cada clase de anlisis cumple con los requisitos que se esperan de ella de acuerdo a las realizaciones de CU en las que participa.

Flujo De Trabajo: 1. Anlisis de la Arquitectura 1.1. Identificacin de paquetes del anlisis. 1.1.1. Gestin de los aspectos comunes entre paquetes del anlisis. 1.1.2. Identificacin de paquetes de servicio. 1.1.3. Definicin de dependencias entre paquetes de anlisis. 1.2. Identificacin de clases de entidad obvias. 1.3. Identificacin de requisitos especiales comunes: Como gestin de transacciones, persistencia, distribucin, concurrencia, seguridad, tolerancia a fallos. 2. Analizar un Caso de Uso 2.1. Identificacin de clases de anlisis 2.2. Descripcin de interacciones entre objetos del anlisis. 2.3. Captura de requisitos especiales. 3. Analizar una clase 3.1. Identificar responsabilidades 3.2. Identificar atributos. 3.3. Identificar asociaciones y agregaciones. 3.4. Identificar generalizaciones. 3.5. Captura de requisitos especiales. 4. Analizar un paquete: Se debe tener en cuenta: Garantizar que el paquete sea lo ms independiente posible de otros paquetes, Garantizar que el paquete cumple con sus objetivos, Describir las dependencias para poder estimar el efecto de cambios futuros. Buscar Dibujo Anlisis de la arquitectura (arquitecto) Analizar un CU (Ing. De CU) Analizar una clase (Ing. De componentes) Analizar un paquete (Ing. De componentes) OBJETOS Y CLASES Objeto: Es una entidad de la vida real, puede ser tangible o no, de existencia real (una persona) o de existencia ideal (una cuenta bancaria). Tipo de objeto: Objeto de la realidad acerca de la cual queremos guardar informacin. Objeto = Estado + Comportamiento + Identidad. Est definido por la identidad, el estado y el comportamiento. Estado: Atributos con valores ciertos. Atributos: Caracterstica que describe (color, marca, nombre, especialidad) o identifica (lo hace nico, DNI, nmero de motor, legajo de alumno) un objeto en particular. Permiten definir el estado de un objeto o caracterizarlo. Identidad (ID): Atributo/s que identifican a cada objeto especfico, lo hace nico. Comportamiento: Acciones que puede realizar un objeto. Conjunto de operaciones. Representa lo que el objeto puede hacer. Una implementacin del comportamiento se denomina mtodo. Abstraccin: Proceso mental por el cual se puede extraer lo esencial de lo que se est estudiando. El concepto de abstraer es general a todos los modelos, ya que permite simplificar la realidad que se estudia. En esta metodologa, la abstraccin requerida consiste en buscar propiedades comunes a los elementos que forman el dominio (objetos), olvidando de momento las propiedades que los diferencian, agrupando dichos objetos en CLASES Clase: es una descripcin de un conjunto de objetos casi idnticos. Una clase determina la estructura de todos los objetos de esa clase. Todos los objetos tienen el mismo conjunto de operaciones, los mismos atributos y el mismo conjunto de relaciones, pero tienen distintos valores de atributos.

Visibilidad: Adorno + # Palito de la

Nombre Visibilidad Pblica Privada Protegida De Paquete

Semntica Cualquier elemento que puede acceder a la clase puede acceder a cualquiera de sus caractersticas. Solamente las operaciones dentro de la clase pueden acceder a las caractersticas. Solo las operaciones dentro de la clase o dentro de los hijos de la clase pueden acceder. Cualquier elemento que est en el mismo paquete que la clase o en un subpaquete anidado puede acceder.

Encapsulamiento: Se ocultan todos los detalles de un objeto que no son necesarios conocer desde el exterior por otros objetos. Es la ocultacin de todos los detalles de un objeto que no es necesario conocer desde el exterior por otros objetos. Toda clase debe tener dos secciones: Interfaz (parte visible) e Implementacin (Representacin de la abstraccin). Ejemplo: El volante, el cuentakilmetros, los pedales y la palanca de cambios representan una interfaz pblica hacia los mecanismos de funcionamiento del automvil. Para conducir no es necesario conocer la mecnica del automvil (su implementacin). Encapsulacin: Es un trmino formal que permite describir un conjunto de mtodos y caractersticas de un objeto de tal forma que slo los mtodos del propio objeto puedan acceder a sus caractersticas. Tipos de visibilidad: Pblica, Privada y Protegida. Mensajes: Los objetos se comunican o interaccionan entre s por medio de mensajes. Si un objeto desea que otro objeto ejecute un mtodo, le enva un mensaje que puede tener informacin adicional en forma de parmetros. Componentes de un mensaje: Objeto destinatario del mensaje (miCoche), Mtodo que se debe ejecutar como respuesta (CambiarMarcha), Parmetros necesarios del mtodo (Segunda). Tipos de Mensajes: Constructores, Destructores, Selectores (permite mostrar datos <valores de atributos>), Modificadores e Iteradores. Aspecto Dinmico: de un sistema orientado a objetos se observa a travs del intercambio de mensajes entre objetos. Aspecto Esttico: se observa a travs de las relaciones estructurales entre clases. Generalizacin de Clases: Se organizan las clases en una jerarqua de generalizacin, en donde las subclases heredan todas las caractersticas de sus superclases. Herencia de Clases: Permite definir una clase especializando otra ya existente. Se extiende un tipo de datos, heredando las caractersticas comunes y especificando las diferentes. Permite la reutilizacin de cdigo. Implementa la relacin es un o es una clase de. Define una jerarqua de clases. Herencia Simple: Una clase hereda caractersticas de una sola clase padre. Herencia Mltiple: una subclase dada hereda caractersticas de ms de una superclase (ms de un padre). Herencia de Clases: Los mtodos y atributos de la superclase son heredados por las subclases, pero en la especializacin: Se pueden aadir nuevos mtodos y atributos (la clase taxi tiene taxmetro y las operaciones poner en marcha taxmetro y parar taxmetro). Se pueden redefinir los mtodos (la clase taxi redefine el mtodo arrancar: si es recin subido un nuevo cliente, poner en marcha taxmetro). Se pueden ocultar mtodos (La subclase coche automtico oculta el mtodo cambiar marcha) Polimorfismo: Los objetos actan en respuesta a mensajes que reciben. Un mismo mensaje puede producir acciones completamente diferentes cuando es recibida por diferentes objetos. El polimorfismo es posible gracias al mecanismo de la herencia.

VISTAS DE UML UML es un lenguaje que proporciona un vocabulario y reglas para permitir una comunicacin. Una vista es simplemente un subconjunto de UML que modela construcciones que representan un aspecto del sistema. En el nivel superior las vistas se pueden dividir en 3 reas: Clasificacin Estructural: Describe los elementos del sistema y sus relaciones con otros elementos. Comportamiento Dinmico: Describe el comportamiento de un sistema en el tiempo. Gestin de Modelo: Describe la organizacin de los propios modelos en unidades jerrquicas.

Patrones Para la construccin de SW: Patrones Arquitectnicos: Aspectos fundamentales de la estructura de un sistema SW. Especifican un conjunto predefinido de subsistemas con responsabilidades y una serie de recomendaciones para organizar distintos componentes. (Patrones arquitectnicos = patrones de anlisis. Los patrones son como modelos de hacer determinadas cosas y se utilizan ms en diseo). Patrones De Diseo: Sobre aspectos relacionados con el diseo de software. Por lo tanto se centran en aspectos ms especficos. Patrones De Bajo Nivel: Para un lenguaje especfico. Patrn Arquitectnico: Modelo en Capas (Slo son conceptuales: no tienen porque corresponderse con la estructura de implementacin, tambin se conocen como la vista lgica de la arquitectura) Cliente <-> Capa de presentacin = Interfaz (Responsable de presentar informacin e interactuar con la capa inferior externas. Se asocia con el estereotipo de clases del anlisis conocido como interfaz) <-> Capa lgica de aplicacin= motor (Responsable de implementar las operaciones solicitadas por los clientes a travs de la capa de presentacin. Ej.: el componente encargado de ver un cliente est o no logado. Se asocia con el estereotipo de clases del anlisis conocido como control) <-> Capa de acceso a datos/recursos= parte de cdigo que busca datos, no es la base de datos (Responsable de gestionar todos los elementos de informacin del SID; ficheros, planos, XML, SGBD, etc.. Se la conoce tambin como capa de gestin de recursos. Se asocia con el estereotipo de clases del anlisis conocido como entidad).

1. rea Estructural: 1.1 Vista Esttica: La vista Esttica modela los conceptos del dominio de la aplicacin, as como los conceptos internos inventados como parte de la implementacin de la aplicacin. Los componentes principales de la vista esttica son las clases y sus relaciones. Las clases son el centro alrededor del cual se organiza la vista de clases: otros elementos pertenecen o se unen a las clases. Las clases se dibujan como rectngulos. Las listas de atributos y de operaciones se muestran en compartimientos separados, que pueden ser suprimidos cuando no es necesario el detalle completo. Las relaciones entre clases se dibujan como las lneas que conectan rectngulos de clases. Las diversas clases de relaciones se diferencian por la textura de la lnea y por los adornes en las lneas o en sus extremos. 1.2 Vista De Casos De Uso: La vista de los casos de uso modela la funcionalidad del sistema segn lo perciben los usuarios externos, llamados actores. Un caso de uso es una unidad coherente de funcionalidad, expresada como transicin entre los actores y el sistema. El propsito de la vista de casos de uso es enumerar a los actores y los casos de uso, y demostrar qu actores participan en cada caso de uso. Los casos de uso se pueden describir en varios niveles de detalle. Se pueden sacar partes como factor comn y ser descritos en trminos de otros casos de uso ms simples. Un caso de uso se implementa como una colaboracin en la vista de interaccin. 1.3 Vistas Fsicas: Las vistas fsicas modelan la estructura de la implementacin de la aplicacin por s misma, se organizacin en componentes, y su despliegue en nodos de ejecucin. Estas vistas proporcionan una oportunidad de establecer correspondencias entre las clases y los componentes de implementacin y nodos. Hay 2 vistas fsicas: 1.3.1 Vista De Implementacin: La vista de implementacin modela los componentes de un sistema, as como las dependencias entre los componentes, para poder determinar el impacto de un cambio propuesto. Tambin modela la asignacin de clases y de otros elementos del modelo a los componentes. Esta vista se representa en diagramas de componentes. Un crculo pequeo con un nombre es una interfaz. Una lnea slida que va desde un componen a una interfaz, indica que el componente proporciona los servicios de la interfaz. Una flecha de guiones de un componente a una interfaz indica que el componente requiere los servicios proporcionados por la interfaz. 1.3.2 Vista de Despliegue: La vista de despliegue representa la disposicin de las instancias de componentes de ejecucin en instancias de nodos. Un nodo es un recurso de ejecucin, tal como una PC, un dispositivo o memoria. Esta vista permite determinar las consecuencias de la distribucin y de la asignacin de recursos. La vista de despliegue se representa en diagramas de despliegue. Este diagrama muestra los tipos de nodos del sistema y los tipos de componentes que contienen. Un nodo se representa como un cubo. 2. rea Dinmica: 2.1 Vista de Mquinas de Estados: Describe el comportamiento dinmico de los objetos, en un cierto plazo. Modela las posibles historias de vida de un objeto de una clase. Cada objeto detecta eventos y responde a ellos. Modela las posibles historias de vida de un objeto de una clase. Diagrama De Transicin de Estados (DTE): Modela el comportamiento del sistema en el tiempo. Describe un periodo de tiempo durante la vida de un objeto de una clase. Puede ser caracterizado como: un conjunto de valores de objeto cualificativamente similares en cierta forma, El periodo de tiempo durante el cual un objeto espera que ocurra algn evento, El periodo de tiempo durante el cual un objeto realiza cierta actividad. Eventos (todo lo que cambia el valor del atributo que est en seguimiento) representan las clases de cambios que un objeto puede detectar. Transicin es la respuesta de un objeto a un evento dejando un estado para pasar a otro. 2.2 Vista de Actividad: Un diagrama de actividades muestra el flujo de actividades software implicadas en la ejecucin de un proceso. Permite entender el comportamiento de la ejecucin de un sistema. Diagrama De Actividades: Actividad es un conjunto de acciones en ejecucin. Cuando una actividad termina procede a ejecutar la siguiente, mostrando as el flujo de trabajo. Las acciones incluyen llamadas a otras operaciones, envo de seales, creacin o destruccin de objetos o simples clculos como la evaluacin de una expresin. Flujo de Objetos: Se puede mostrar este flujo, relacionando los estados de los objetos con la actividad donde se produce. Calles: Para organizar el diagrama se puede utilizar calles que representan una unidad organizativa que realiza las tareas. Un escenario es un caso de uso y un diagrama de actividad se hace de un caso de uso con sus extensiones e inclusiones.

Elementos: Actividad (rectngulo con puntas redondas), transicin (flecha), bifurcacin (rombo), barra de divisin y barra de unin. Contiene bifurcaciones y divisiones de control concurrente. 2.3 Vista de Interaccin: Describe el intercambio de mensajes entre objetos para implementar el comportamiento de un sistema. Se muestra a travs de dos diagramas centrados en diferentes aspectos: Diagrama de Secuencia: Centrado en la secuencia temporal de los mensajes. Diagrama de Colaboracin: Centrado en las relaciones entre objetos. Diagrama de Paquetes: Los paquetes son una forma natural de agrupamiento del UML. Pueden contener clases y casos de uso y se pueden anidar. Cada elemento pertenece a un nico paquete. Su utilizacin por otro paquete se hace por medio de la relacin de dependencia entre paquetes o por anidamiento. Una clase no puede pertenecer a ms de un paquete.