Arquitectura de un sistema de Bases de datos

Niveles generales del sistema:

● Nivel Externo: Formado por las vistas individuales de cada usuario. Interacciona con el nivel conceptual.

● Nivel Conceptual: Formado por la vista comunitaria de los usuarios, es decir toda la base de datos 

● Nivel interno: Como queremos que se almacene nuestra base de datos. 

Nivel Externo 

Nivel del usuario individual (diseñado por el administrador de la base de datos). Tiene que permitirle al programador de aplicaciones trabajar con un lenguaje de alto nivel o con lenguajes propios de la base de datos.

El usuario final se comunica a trabes de lenguajes de consultas o a trabes de aplicaciones. DSL: Sublenguaje estructurado de datos, incluido en el lenguaje anfitrión (Lenguaje de alto nivel). Este es fuertemente acoplado, no se distingue del lenguaje anfitrión. En caso de que sea claramente divisible, se puede separa con claridad del lenguaje anfitrión y se dice que es débilmente acoplado. 

El DSL esta formado por 2 sublenguajes de datos:

 ● DDL: Sublenguaje de definición de datos. Permite definir los objetivos de la Base de datos.

 ● DML: Sublenguaje de manejo de datos. Permite la transferencia de información entre la Base de Datos y aplicaciones. 

La vista externa es la vista individual que percibe cada usuario. Esta compuesto por el conjunto de ocurrencias de los distintos registros externos.

¿ Registro Externo≃Registro Lógico ? Si, el registro externo es lo que el usuario esta viendo y el lógico es lo que el usuario ve.

¿ Registroexterno≃Registroconceptual ? No tienen porqué.

Toda vista externa se define mediante un esquema externo, donde este esta formado por las definiciones de los diferentes tipos de registros externos en esa vista externa. ¿Cuantos esquemas externos hay? Tantos como vistas externas haya.

Nivel Conceptual 

La vista conceptual es toda la representación de toda la información contenida en la base de datos.

Se compone de las ocurrencias de los diferentes tipos de registros conceptuales. La vista conceptual se define por medio del esquema conceptual que es la definición de cada tipo de registro conceptual.

Se implementa mediante el DDL conceptual. ¿El DDL conceptual debe contemplar instrucciones para almacenar los registros? No, porque yo podría cambiar en cualquier momento el modo de almacenamiento, por lo que cambiarla la aplicación.

¿Donde se deben implementar las características de seguridad e integridad? En el nivel conceptual porque es donde esta la información de la base de datos.

Nivel Interno

El registrointerno≡registro almacenado porque es donde decido como almacenarlo. Se define vista interna como una representación de bajo nivel de toda base de datos. Se compone de las ocurrencias de los diferentes tipos de registros interno. En el nivel interno no se manejan direcciones físicas. La vista interna se define mediante el esquema interno, donde este, además de las definiciones de los diferentes tipos de registros internos, también contemplan información referente a:

● Los índices que hay.

● La representación de los campos almacenados.

● Las secuencias físicas de los registros almacenados. 

El esquema interno se implementa mediante el DDL interno.

El administrador de Bases de Datos (DBA)

Tiene las siguientes funciones:

1. Describir el contenido de la información de la base de datos (esquema conceptual), E/R sirve para describir el esquema conceptual (realizando el diseño lógico).

2. Decidir sobre la estructura de almacenamiento, define el esquema interno (analizando el diseño físico de la Base de Datos).

3. Conexión con los usuarios. 

   1. Al usuario final, el administrador de la Base de Datos debe captar la vista externa de cada uno de ellos, implementar el esquema externo asociado y la correspondencia externa conceptual y debe crear un entorno amigable. 

   2. Al programador de aplicaciones le aporta ayuda, para la implementación de vista externa y debe permitirle el desarrollo de la correspondencia externa conceptual. 

4. Tratar los problemas de seguridad e integridad.

5. Definir la estrategia de recuperación de fallos. 

6. Ocuparse de los problemas de rendimiento (afinamiento). Si la base de datos es dinámica (va evolucionando) debe mejorarse los tiempos de respuesta

sacado de:

http://uvirtual.ufps.edu.co/ufpsvirtual/pluginfile.php/5932/mod_resource/content/1/Arquitecura%20BD.pdf

Principios del Diseño de Software

• No debería ponerse “orejas” (considerar enfoques alternativos). † 
• Se debería poder seguir los pasos del diseño desde el modelo de análisis. 
• † No debe inventar nada que ya esté inventado. †
•  Debería “minimizar la distancia intelectual” entre el software y el problema tal y como existe en el mundo real. † 
• Debería presentar uniformidad e integración. 
• Debería estructurarse para admitir cambios.
• Debería estructurarse para degradarse poco a poco, incluso cuando se enfrenta a datos, sucesos o condiciones operativas aberrantes.
• No es escribir código y escribir código no es diseñar. 
• Se debería valorar la calidad del diseño mientras se crea no después de terminarlo. † 
• Se debería revisar el diseño para minimizar los errores conceptuales (semánticos).

ABSTRACCIÓN

La noción psicológica de abstracción permite concentrarse en un problema a un nivel de generalización independiente de los detalles de nivel inferior, la abstracción también permite trabajar con conceptos y términos que son familiares en el entorno del problema sin tener que transformarlos en una estructura poco familiar. † Cada fase del proceso de ingeniería del software es un refinamiento en el nivel de abstracción de la solución software. Finalmente se alcanza el nivel inferior de abstracción cuando se construye el código.

Abstracción procedimental: es una secuencia dada de instrucciones que tiene una función específica y limitada.

Abstracción de datos: es una colección determinada de datos que describen un objeto de datos. 

Abstracción de control: implica un mecanismo de control del programa sin especificar detalles internos

REFINAMIENTO PASO A PASO 

La arquitectura de un programa se desarrolla refinando sucesivamente niveles de detalle procedimental. † Se desarrolla una jerarquía descomponiendo un enunciado macroscópico de función (una abstracción procedimental) al estilo paso a paso hasta que se llega a los enunciados del lenguaje de programación. † La abstracción y el refinamiento son conceptos complementarios.

MODULARIDAD.

 Se divide el software en componentes identificables y tratables por separado, denominados módulos, que están integrados para satisfacer los requisitos del programa. † La modularidad es el atributo del software que permite a un programa ser manejable intelectualmente. La complejidad percibida de un problema que combina p’ y p’’; es mayor que la complejidad percibida cuando cada problema se considera por separado. † Hay un número m de módulos que resultarían en un costo de desarrollo mínimo, pero no tenemos la sofisticación necesaria para predecir m con seguridad.

Meyer define cinco criterios que permiten evaluar un método de diseño con respecto a su capacidad de definir un sistema modular eficaz:

Capacidad de descomposición funcional: mecanismo sistemático de descomposición del problema en sub-problemas. 

Capacidad de empleo de componentes modulares: ensamblar componentes de diseño existentes.

Capacidad de comprensión modular: entender un módulo como una unidad por sí sola. 

Continuidad modular: cambios en los módulos individuales, en vez de cambios generalizados en el sistema. „ 

Protección modular: los efectos se restringen dentro de ese módulo.

JERARQUIA DE CONTROL (estructura del programa). † 

Representa la organización (a menudo jerárquica) de componentes del programa (módulos) e implica una jerarquía de control

Profundidad y anchura: proporcionan una indicación del número de niveles de control y el ámbito global de control, respectivamente.

El grado de salida: es una medida del número de módulos que son controlados directamente por otro módulo.

Superior. † 

Subordinado. †

Visibilidad: indica el conjunto de componentes de programa que pueden invocarse o usarse sus datos por un componente dado, incluso cuando esto se realiza indirectamente.

Conectividad: indica el conjunto de componentes que son invocados directamente o usados sus datos por un componente determinado

PARTICIÓN ESTRUCTURAL. 

†Partición horizontal: define ramas separadas de la jerarquía modular para cada función principal del programa. El enfoque más simple de partición horizontal define tres particiones: entrada, procesamiento y salida. Es más fácil de probar y de mantener, propaga menos efectos secundarios, el software es más fácil de ampliar.

Partición vertical: o factoring (descomposición en factores), sugiere que el control (toma de decisiones) y el trabajo se distribuyan descendentemente en la arquitectura del programa.† Los módulos del nivel superior deberían realizar funciones de control y poco trabajo de procesamiento. † Los módulos que residen en la parte baja de la arquitectura deberían ser los trabajadores, realizando todos los trabajos de entrada, cálculo y salida.† Las arquitecturas de partición vertical tienen menos probabilidad de ser susceptibles a efectos secundarios cuando se hacen cambios y tendrán por tanto mejor capacidad de mantenimiento, un factor clave para la calidad.

sacado de:

http://uvirtual.ufps.edu.co/ufpsvirtual/pluginfile.php/5930/mod_resource/content/1/Dise%C3%B1o%20de%20software.pdf

Diseño de Software

Es una descripción de la estructura del software que se va a implementar, los datos que son parte del sistema, las interfaces entre los componentes del sistema, y algunas veces, los algoritmos utilizados. † Los diseñadores no obtienen inmediatamente un diseño detallado, sino que lo desarrollan de manera iterativa a través de diversas versiones. † El proceso de diseño incluye agregar formalidad y detalles durante el desarrollo del diseño, y regresar a los diseños anteriores y corregirlos.

El proceso de diseño incluye el desarrollo de varios modelos con diferentes niveles de abstracción

La retroalimentación entre estas actividades y la consecuente repetición del trabajo es inevitable en todo proceso de diseño

Diseño de datos: transforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarias para implementar el software.

Diseño arquitectónico: define la relación entre los principales elementos estructurales del programa.

Diseño de interfaz: describe cómo se comunica el software consigo mismo, con los sistemas que operan con él y con los operadores que lo emplean.

Diseño procedimental: transforma elementos estructurales de la arquitectura del programa en una descripción procedimental de los componentes de software.

RELACIÓN ENTRE LOS ELEMENTOS DE ANÁLISIS Y DISEÑO

Los sistemas grandes siempre se descomponen en subsistemas que suministran algún conjunto relacionado de servicios. † El proceso de diseño inicial para identificar estos subsistemas y establecer un marco de trabajo para el control y comunicación de los subsistemas se llama diseño arquitectónico y lo que produce este proceso de diseño es una descripción de la Arquitectura de Software. † La descomposición arquitectónica es necesaria para estructurar y organizar la especificación.

Resumiendo las razones expuestas por el Software Engineering Institute así como las propuestas por Bass et al. (SEI, 2000) (Bass et al.,2003), se puede contar con cuatro necesidades fundamentales para considerar importante la arquitectura del software las cuales justifican su análisis: „

 La comunicación entre los participantes: por representar una abstracción de alto nivel de un sistema que la mayoría, sino todos, los participantes pueden usar para crear un entendimiento común.

Decisiones de diseño tempranas: es también el punto más temprano en el cual el sistema a ser construido puede ser analizado. „

Abstracción transferible de un sistema: la arquitectura del software constituye un modelo pequeño e intelectualmente comprensible de cómo el sistema está estructurado y de cómo colaboran entre sí sus componentes. Este modelo es transferible a otros sistemas, especialmente a aquellos con requerimientos similares.

„ La arquitectura del software es el primer artefacto de diseño que direcciona al menos cuatro atributos de calidad relevantes: desempeño, confiabilidad, modificabilidad y seguridad.

Sacado de:

http://uvirtual.ufps.edu.co/ufpsvirtual/pluginfile.php/5930/mod_resource/content/1/Dise%C3%B1o%20de%20software.pdf

Bases de Datos Orientadas a Objetos (BDOO)

Es una base de datos inteligente. Soporta el paradigma orientado a objetos almacenando datos y métodos, y no sólo datos. Está diseñada para ser eficaz, desde el punto de vista físico, para almacenar objetos complejos. Evita el acceso a los datos; esto es mediante los métodos almacenados en ella. Es más segura ya que no permite tener acceso a los datos (objetos); esto debido a que para poder entrar se tiene que hacer por los métodos que haya utilizado el programador.

Un SGBDOO es un SGBD que almacena objetos y por tanto posee todas las ventajas de la orientación a objetos

Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes de programación orientados a objetos como Java, C#, Visual Basic.NET y C++.



CARACTERISTICAS

 propone 13 características obligatorias para los SGBDOO, basado en dos criterios: debe ser un sistema orientado a objetos y debe ser un SGBD (Atkinson et al., 1989). Características:

1. Debe soportar objetos complejos: Debe ser posible construir objetos complejos aplicando constructores a objetos básicos.

2. Identidad del objeto: Todos los objetos deben tener un identificador que es independiente de los valores de sus atributos.

 3. Encapsulamiento: Los programadores solo tienen acceso a la especificación de interfaz de los métodos, y los datos e implementación de estos métodos están ocultos en los objetos.

 4. Tipos o clases : El esquema de una BBOO contiene un conjunto de clases o tipos.

5. Tipos o clases deben ser capaz de heredar de sus supertipos o superclases: los atributos y métodos.

6. Sobrecarga debe ser soportada: Los métodos deben poder aplicarse a diferentes tipos.

7. El LMD debe ser completo : El LMD en los SGBDOO debe ser un lenguaje de programación de propósito general.

8. El conjunto de tipos de datos debe ser extensible: No habrá distinción entre tipos definidos por el usuario y tipos definidos por el sistema.

9. Persistencia de datos: los datos deben mantenerse después de que la aplicación que los creó haya finalizado. El usuario no tiene que hacer copia explícitamente.

10. El SGBD debe ser capaz de manejar grandes BD 11. El SGBD debe soportar Concurrencia : Debe disponer de mecanismos para el control de concurrencia.

12. Recuperación: el SGBD debe proveer mecanismos de recuperación de la información en caso de fallo del sistema.

13. El SGBD debe proveer un manera fácil de hacer consultas.


BASES DE DATOS ORIENTADA A OBJETOS CON UML

Lenguaje Unificado de Modelado (LUM) o (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir.

UML combina notaciones provenientes desde:

• Modelado Orientado a Objetos
• Modelado de Datos • Modelado de Componentes
• Modelado de Flujos de Trabajo (Workflows) DI

Análisis y diseño orientados a objetos con UML

 Metodología de diseño de BD:

1. Generar diagramas de casos de uso a partir de la especificación de requisitos para representar las principales funciones requeridas por el sistema.

2. Generar un diagrama de clases (E/R).

3. Generar un diagrama de secuencias para cada caso de uso o para cada grupo de casos de uso (interacción entre clases).

4. Actualizar el diagrama de clases para mostrar los métodos requeridos en cada una. 5. Crear un diagrama de estados para cada clase que muestre como cambia de estado.

VENTAJAS 

• Se desarrolla un único modelo al que acceden directamente las aplicaciones.

• Simplifica la conceptualización La utilización de objetos permite representar de una forma más natural los datos que se necesitan guardar.

• Mejora la comunicación entre los usuarios, los diseñadores y los analistas.

• Extensibilidad: Los SGBDOO permiten construir nuevos tipos de datos a partir de tipos existentes.

• Existe una única interfaz entre el LMD y el lenguaje de programación lo que elimina lo que elimina el problema de tener incrustar un lenguaje declarativo como SQL en un lenguaje imperativo como C.

• Lenguaje de consultas más expresivo : El acceso navegacional es más adecuado para manipular despliegue de partes, consultas recursivas, etc. • Soporte a esquema evolutivo : el estrecho acoplamiento entre datos y aplicaciones en un SGBDOO hace más abordable el esquema evolutivo


DESVENTAJAS

 • La optimización de consultas compromete la encapsulación: optimizar consultas requiere conocer la implementación para acceder a la BD eficientemente.

• Los bloqueos a nivel de objeto, utilizados en protocolos de control de concurrencia pueden afectar al rendimiento.

• Complejidad: el incremento de funcionalidad provisto por un SGBDOO, como un único nivel de modelo de almacenamiento o soporte a transacciones largas. La complejidad con lleva productos más caros y difíciles de usar.

• Falta de soporte a las vistas: la mayoría de SGBDOO no proveen mecanismos de vistas.

• Falta de soporte a la seguridad: Actualmente los SGBDOO no proveen un mecanismo adecuado de seguridad. La mayoría de mecanismos están basados en un nivel de granularidad alto y los usuarios no pueden conceder derechos de acceso a objetos o clases individuales.

CONCLUSIONES

En Conclusión sabemos que las BDOO representan el siguiente paso en la evolución de las bases de datos, para soportar el Análisis, Diseño y Programación OO. Las BDOO permiten el desarrollo y mantenimiento de aplicaciones complejas con un costo Significativamente menor. Permiten que el mismo modelo conceptual se aplique al Análisis, diseño, programación, definición y acceso a la base de datos.

Esto reduce el problema del operador de traducción entre los diferentes modelos a través de todo el ciclo de vida. El modelo conceptual debe ser la base de las herramientas CASE OO totalmente integradas, las cuales ayudan a generar la estructura de datos y los métodos. Las BDOO ofrecen un mucho mejor rendimiento de la máquina que las bases de datos por relación, para aplicaciones o clases con estructuras complejas de datos. Sin embargo, Las BDOO coexistirán con las bases de datos por relación durante los próximos años, puesto que a menudo se utilizará un modelo por relación como una forma de estructura de datos dentro de una BDOO.

Sacado de:

http://uvirtual.ufps.edu.co/ufpsvirtual/pluginfile.php/5361/mod_resource/content/1/Bases%20de%20Datos%20OO.pdf

DIAGRAMA DE DESPLIEGUE

Los diagramas de despliegue son los complementos de los diagramas de componentes que, unidos, proveen la vista de implementación del sistema. Describen la topología del sistema la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos. Los diagramas de despliegue representan a los nodos y sus relaciones. Los nodos son conectados por asociaciones de comunicación tales como enlaces de red, conexionesTCP/IP.

Los diagramas de despliegue muestran la configuración en funcionamiento del sistema incluyendo su software y su hardware. Para cada componente de un diagrama es necesario que se deba documentar las características técnicas requeridas, el tráfico de la red, el tiempo de respuesta.

Usos

·         Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.

·         Sistemas cliente-servidor: Los sistemas Cliente-Servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.

·         Sistemas completamente distribuidos: En el otro extremo se encuentra aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores.

Ventajas

·         Muestra un conjunto de nodos y sus relaciones.

·         Se utilizan para describir la vista de despliegue estática de un sistema.

·         Se relacionan con los diagramas de componentes, ya que un nodo normalmente incluye uno o más componentes.

Desventajas

·         La posible falla en la modelación de un hardware.

·         Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro.El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.

Componentes

Nodo

Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento.Un Nodo es un elemento de hardware o software.

Instancia de nodo

Una instancia se puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de los dos puntos.

Estereotipo de nodo

Estereotipo, son cosas u objetos q se repiten sin variación.El estereotipo de un nodo es la manera de poder verificar que tipo de nodo es el que se esta observando.

Artefactos

Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (modelos de Caso de uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario etc. Donde un artefacto es un conjunto de componentes.

Asociación

Una asociación representa una ruta de comunicación entre los nodos. Donde esta asociación va incluida con misma dependencia del diagrama de componentes.

Tomado de

http://www.ecured.cu/Diagrama_de_despliegue

MODELADO DE CASOS DE USO

En el modelado de casos de uso, el sistema se observa como una caja negra que proporciona casos de uso. Cómo lo haga el sistema, cómo se implementen los casos de uso y cómo trabajen internamente no importa.

• Las clases e interacciones implementan los casos de uso del sistema.

 – Las interacciones se expresan en diagramas de secuencia, colaboración y actividad, así, hay un enlace entre las vistas funcional y dinámica del sistema.

– Las clases en la implementación de los casos de uso se modelan y se describen en diagramas de clases y de estados.

• Los propósitos primarios de los casos de uso son:

– Decidir y describir los requerimientos funcionales del sistema, dando lugar a un acuerdo entre el cliente (y/o usuario final) y los programadores que desarrollan el sistema.

– Dar una descripción clara y consistente de lo que debería hacer el sistema, de modo que el modelo se use a lo largo del proceso de desarrollo. – Proporcionar una base para realizar verificaciones (tests) del sistema que comprueben su funcionamiento.

– Proporcionar la capacidad para rastrear requerimientos funcionales en clases y operaciones reales del sistema, verificando los casos de uso afectados por cambios y extensiones al sistema.

• El modelado de casos de uso también se utiliza cuando se desarrolla una nueva versión del sistema.

– Se añade la nueva funcionalidad al modelo de casos de uso existente insertando nuevos actores y casos de uso, o modificando la especificación de los casos de uso actuales

Diagrama de Casos de Uso

•  Un modelo de casos de uso se describe en UML mediante un diagrama de casos de uso (use-case diagram) y puede dividirse en varios diagramas de casos de uso.

• Un diagrama de casos de uso contiene elementos del modelo para el sistema, los actores y los casos de uso, y muestra las diferentes relaciones entre estos elementos.

– Estos diagramas dan una visión del modelo, pero las descripciones reales de los casos de uso suelen ser textuales, usando el lenguaje y terminología del cliente/usuario.

• Un sistema en un diagrama de casos de uso se describe mediante un rectángulo que contiene el nombre del sistema y los símbolos de los casos de uso en el sistema.

Actor

•Un actor es alguien o algo que interactúa con el sistema, pero que es externo al sistema.

– El actor envía o recibe mensajes a y desde el sistema, o intercambia información con el sistema.

 – Un caso de uso siempre es iniciado por un actor que le envía un mensaje o estímulo (stimulus). Los actores llevan a cabo casos de uso.

  – Cuando un caso de uso se realiza, el caso de uso podría enviar mensajes a uno o más actores. Estos mensajes también pueden ir a otros actores además del que inició el caso de uso.

•Un actor es una clase, no una instancia. El actor representa un papel, no a un usuario individual del sistema.

– Por ejemplo, una persona puede ser diferentes actores en el sistema, dependiendo de su papel en éste.

– Los papeles que una persona puede tener en un sistema pueden estar restringidos. Por ejemplo, puede estar prohibido que la misma persona registre una factura y la apruebe.

– Un actor tiene un nombre que debería reflejar el papel del actor.

• Para identificar los actores, se establecen las entidades interesadas en usar e interactuar con el sistema:

– Los usuarios de la funcionalidad principal del sistema (actores primarios). Por ejemplo, en un sistema de seguros, un actor primario podría ser uno que maneja el registro y administración de los seguros.

– Los que mantienen, administran y tienen el sistema en funcionamiento (actores secundarios). Un ejemplo de actor secundario podría ser una tarjeta que usa las funciones del sistema para recuperar estadísticas sobre los negocios o la compañía. – Los dispositivos hardware que necesita manejar el sistema.

– Los otros sistemas con que necesita interactuar, que incluyen otros sistemas computadores, así como otras aplicaciones en el computador en que operará este sistema.

– Los que tienen interés en los resultados que produce el sistema.

• Un actor debe tener alguna asociación con uno o más casos de uso.

– Aunque un actor podría no iniciar un caso de uso, ese actor se comunicará con uno en algún punto.

– Un actor activo inicia un caso de uso, mientras que un actor pasivo nunca inicia un caso de uso, sino que sólo participa en uno o más casos de uso.

Relaciones entre actores

• Los actores en UML son clases con el estereotipo <<actor>> y tienen un estereotipo icono estándar. El nombre de la clase es el nombre del actor.

 – Una clase actor puede tener atributos y comportamiento.

 – Los actores pueden tener las mismas relaciones que las clases.

• Cuando varios actores, como parte de sus papeles, también representan un papel más generalizado, se describe mediante una relación de generalización.

– El comportamiento del papel general se describe en una superclase actor. Los actores especializados heredan el comportamiento de la superclase y extienden ese comportamiento de algún modo.

Representación de un Caso de Uso 

•Un caso de uso se representa en UML mediante una elipse que contiene el nombre del caso de uso, o con el nombre del caso de uso debajo.

• Los casos de uso se conectan a los actores mediante asociaciones, denominadas líneas de comunicación (communication lines).

– Las asociaciones muestran con qué actores se comunica el caso de uso, incluyendo el actor que inicia la ejecución del caso de uso.

– La asociación normalmente es una relación uno a uno sin dirección. Esto significa que una instancia de actor se comunica con una instancia de caso de uso y que pueden comunicarse en ambas direcciones.

Relaciones entre casos de Uso

• Relación de extensión (extend): un caso de uso añade acciones, que pueden ser opcionales, al comportamiento de un caso de uso general.

– El caso de uso extendido puede incluir comportamiento del caso de uso que se extiende, aunque no tiene que incluir todo el comportamiento.

• Relación de inclusión (include): un caso de uso incluye el comportamiento completo de un caso de uso general.

– Permite la composición jerárquica de casos de uso, así como la reutilización entre casos de uso.

• Relación de generalización: en el caso de uso especializado se especifican los pasos extra que es necesario añadir al caso de uso general, para representar una funcionalidad diferente a la original.

Tomado de:

http://www.ctr.unican.es/asignaturas/mc_oo/doc/casos_de_uso.pdf

ANÁLISIS ORIENTADO A OBJETOS(AOO)

El análisis orientado a objetos es el proceso que modela el dominio del problema identificando y especificando un conjunto de objetos semánticos que interaccionan y se comportan de acuerdo a los requisitos del sistema. [Monarchi y Puhr, 1992]

• Permite describir el sistema en los mismos términos que el mundo real

• Se centra en la comprensión del espacio (dominio) del problema

• Contiene elementos de síntesis

• La abstracción de requisitos de usuario y la identificación de los objetos clave del dominio es seguida del ensamblaje de estos objetos en estructuras de forma que soporten el diseño en fases posteriores

• Difícil determinar dónde acaba el análisis orientado a objetos y donde comienza el diseño orientado a objetos

• El objetivo es modelar la semántica del problema en términos de objetos distintos pero relacionados

 • El análisis casa con el dominio del problema

• Los objetos del dominio del problema representan cosas o conceptos utilizados para describir el problema (objetos semánticos)

• Los objetos del dominio del problema tienen una equivalencia directa en el entorno de la aplicación

• Se centra en la representación del problema

 • Identificar abstracciones que contengan el significado de las especificaciones y de los requisitos

• El modelo de casos de uso identifica secuencias de eventos e interacciones entre actores y el sistema

• El modelo de análisis especifica las clases de objetos que se encuentran o existen en el sistema

• No existen reglas fijas para esta transformación

• Se centra en la elaboración de un modelo del sistema, el modelo de análisis

• Modelo funcional: Representado por los casos de uso

• Modelo objeto análisis: Representado por los diagramas de clase y objetos

• Modelo dinámico: Representado por los diagramas de secuencia y los diagramas de transición de estados.

Actividades del AOO

• La identificación de las clases semánticas, los atributos, el comportamiento y las relaciones (generalizaciones, agregaciones y asociaciones)

• El emplazamiento de las clases, atributos y comportamiento

• La especificación del comportamiento dinámico mediante paso de mensajes

Existen diferentes enfoques de proceso en el análisis

 • Centran en la información (datos) del sistema

• Centran en la funcionalidad (comportamiento) del sistema

• Síntesis de los dos procesos anteriores

• El Proceso Unificado [Jacobson et al., 1999] sigue el enfoque de síntesis

• Inicio por la funcionalidad (Casos de uso)

• Refinamiento por la información (Diagramas de Clases) • Consolidación por la funcionalidad (Diagramas de secuencia /colaboración)

Tomado de:

http://uvirtual.ufps.edu.co/ufpsvirtual/pluginfile.php/5305/mod_resource/content/1/Analisis%20OO.pdf