Post on 13-Aug-2015
Camacho Hernández Alberto
Actividades y Casos de Uso
La experiencia y práctica de quien hace los diagramas y su respectiva descripción
marca el punto de vista o tendencia, que genera una manera particular de poner
énfasis en determinados elementos. Por ejemplo si soy un desarrollador, veo en
todas partes menús, tablas, opciones, clics y demás elementos es decir no analizo
un problema y doy su solución sino que de una vez pienso en cómo debería correr la
aplicación.
El modelo de casos de uso, permite hacer una mejor toma de requerimientos y
clarificar la funcionalidad del sistema, es decir que espera el usuario que haga el
sistema, no tanto como lo haga o con qué. Por lo tanto una descripción de un caso
de uso específico se debe orientar hacia qué es lo que ese usuario haría allí en
interacción con un sistema.
Por lo tanto si tiene un caso de uso llamado “Registrar inventario”, en la descripción
no puede tener un paso que diga “el usuario registra el inventario” y listo, debido a
que eso es precisamente lo que le preguntan, como se registra, los datos que se
manipulan y que operaciones se hacen con ellos.
Para que posteriormente un desarrollador pueda crear las pantallas y menús.
Uno como ingeniero, entra a ser parte de un equipo, no lo hacemos todo nosotros y
además necesitamos especificaciones claras para poder realizar nuestro trabajo.
Una buena descripción de casos de uso, en relación con un buen modelo de clases
facilita inmediatamente los diagramas de secuencias y actividades y por lo tanto
favorecen un óptimo desarrollo de la aplicación.
Diagrama de actividades
En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
Camacho Hernández Alberto
Diagrama de casos de uso
Un Caso de Uso es un documento narrativo que describe la secuencia de eventos de un actor, el cual que es un agente externo y que usa un sistema para completar un proceso. Es una historia o una forma particular de usar un sistema. Los casos de uso no son exactamente requisitos ni especificaciones funcionales, pero ilustran e implican requisitos en las historias que cuentan.
A los casos de uso lo definen dos elementos: actores y casos de uso. Un actor modela una entidad externa que se comunica con el sistema:
Usuario Sistema externo Entorno físico
Camacho Hernández Alberto
Un actor tiene un nombre único y una descripción opcional. Ejemplos:
Pasajero: persona que viaja en un tren GPS satélite: provee al sistema con coordenadas GPS
Un caso de uso representa una clase de funcionalidad dada por el sistema como un flujo de eventos. Un caso de uso consiste:
Nombre único Actores que participan Condiciones de entrada Flujo de eventos Condiciones de salida Requerimientos especiales
Interfaces De Usuario
En el contexto del proceso de interacción persona-ordenador, la interfaz gráfica de
usuario, es el artefacto tecnológico de un sistema interactivo que posibilita, a través
Camacho Hernández Alberto
del uso y la representación del lenguaje visual, una interacción amigable con un
sistema informático.
La interfaz gráfica de usuario (en inglés Graphical User Interface, GUI) es un tipo de
interfaz de usuario que utiliza un conjunto de imágenes y objetos gráficos para
representar la información y acciones disponibles en la interfaz. Habitualmente las
acciones se realizan mediante manipulación directa para facilitar la interacción del
usuario con la computadora.
Surge como evolución de la línea de comandos de los primeros sistemas operativos
y es pieza fundamental en un entorno gráfico.
Como ejemplo de interfaz gráfica de usuario podemos citar el escritorio o desktop del
sistema operativo Windows y el entorno X-Window de Linux.
Diseño de la Lógica
El diseño lógico es el proceso de construir un esquema de la información que utiliza
la empresa, basándose en un modelo de base de datos específico, independiente del
SGBD concreto que se vaya a utilizar y de cualquier otra consideración física.
En esta etapa, se transforma el esquema conceptual en un esquema lógico que
utilizará las estructuras de datos del modelo de base de datos en el que se basa el
SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red,
el modelo jerárquico o el modelo orientado a objetos. Conforme se va desarrollando
el esquema lógico, éste se va probando y validando con los requisitos de usuario.
La normalización es una técnica que se utiliza para comprobar la validez de los
esquemas lógicos basados en el modelo relacional, ya que asegura que las
relaciones (tablas) obtenidas no tienen datos redundantes. Esta técnica se presenta
en el capítulo dedicado al diseño lógico de bases de datos.
El esquema lógico es una fuente de información para el diseño físico. Además, juega
un papel importante durante la etapa de mantenimiento del sistema, ya que permite
que los futuros cambios que se realicen sobre los programas de aplicación o sobre
los datos, se representen correctamente en la base de datos.
Camacho Hernández Alberto
Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un
punto de inicio y se van refinando continuamente. Ambos se deben ver como un
proceso de aprendizaje en el que el diseñador va comprendiendo el funcionamiento
de la empresa y el significado de los datos que maneja. El diseño conceptual y el
diseño lógico son etapas clave para conseguir un sistema que funcione
correctamente. Si el esquema no es una representación fiel de la empresa, será
difícil, sino imposible, definir todas las vistas de usuario (esquemas externos), o
mantener la integridad de la base de datos. También puede ser difícil definir la
implementación física o el mantener unas prestaciones aceptables del sistema.
Además, hay que tener en cuenta que la capacidad de ajustarse a futuros cambios
es un sello que identifica a los buenos diseños de bases de datos. Por todo esto, es
fundamental dedicar el tiempo y las energías necesarias para producir el mejor
esquema que sea posible.
Clases y Objetos
Un objeto es una cosa tangible, algo a que se puede aprehender intelectualmente o algo hacia lo que se puede dirigir una acción o pensamiento.
Un objeto representa un item individual e identificable, o una entidad real o abstracta, con un papel definido en el dominio del problema
Un objeto tiene: Estado, Comportamiento e Identidad. La estructura y el comportamiento de objetos similares se definen en sus clases comunes. El término objeto y ejemplo de una clase son intercambiables.
Estado de un objeto
El estado de un objeto abarca todas las propiedades del objeto, y los valores actuales de cada una de esas propiedades. Las propiedades de los objetos suelen ser estáticas, mientras los valores que toman estas propiedades cambian con el tiempo. El hecho de que los objetos tengan estado implica que ocupan un espacio, ya en el mundo físico, ya en la memoria del ordenador.
El estado de un objeto está influido por la historia del objeto. No deben confundirse los objetos, que existen en el tiempo, son mutables, tienen estado, pueden ser creados, destruidos y compartidos, con los valores (los asignados a una variable, por ejemplo) que son cantidades con las propiedades de ser atemporales, inmutables.
El estado de un objeto representa el efecto acumulado de su comportamiento.
Camacho Hernández Alberto
Identidad de un objeto
Identidad es la propiedad de un objeto que lo lleva a distinguirse de otros.
Comportamiento de un objeto
Comportamiento es como un objeto actúa y reacciona, en términos de sus cambios de estado y de los mensajes que intercambia. El comportamiento de un objeto representa su actividad externamente visible y estable. Son las operaciones que una clase realiza también llamadas mensajes y son las que dan cuenta de cómo se comporta la clase. Por operación se denota el servicio que una clase ofrece a sus clientes. Un objeto puede realizar cinco tipos de operaciones sobre otro, con el propósito de provocar una reacción:
Modificador: altera el estado de un objeto. Selector: accede al estado de un objeto, sin alterarlo. Iterador: permite a todas las partes de un objeto ser accedidas en un orden. Constructor: crea un objeto y/o inicializa su estado. Destructor: libera el estado de un objeto y/o destruye el objeto.
Relaciones entre objetos
Las relaciones entre objetos abarcan las operaciones, resultados y suposiciones que unos hacen sobre los otros.
Links Son conexiones físicas o conceptuales entre objetos. Denota la asociación específica por la que un objeto (cliente) usa o solicita el servicio de otro objeto (servidor). El paso de mensajes entre objetos los sincroniza. Agregaciones denota relaciones todo/parte, con capacidad para gobernar desde el todo las partes. Agregación es conveniente en las ocasiones en que el encapsulamiento de las partes es prioritario. Si se requiere que las relaciones entre objetos estén vagamente acopladas, se utilizan links.
Clases
Una clase es un conjunto de objetos que comparten una estructura y comportamiento comunes. Clase representa una abstracción, la esencia que comparten los objetos. Un objeto no es una clase, y una clase no es un objeto. Las clases actúan como intermediarias entre una abstracción y los clientes que pretenden utilizar la abstracción. De esta forma, la clase muestra:
Visión externa de comportamiento (interface), que enfatiza la abstracción escondiendo su estructura y secretos de comportamiento.
Camacho Hernández Alberto
Visión interna (implementación), que abarca el código que se ofrece en la interface de la clase.
Relaciones entre clases
Representan tipos de compartición entre clases, o relaciones semánticas. Asociación. Indica relaciones de mandato bidireccionales (Punteros ocultos en C++). Conlleva dependencia semántica y no establece una dirección de dependencia. Tienen cardinalidad.
Herencia. Por esta relación una clase (subclase) comparte la estructura y/o comportamiento definidos en una (herencia simple) o más (herencia múltiple) clases, llamadas superclases.
Una subclase aumenta o restringe el comportamiento o estructura de la superclase. Una clase de la que no existen ejemplos se denomina abstracta.
Agregación. Representa una relación del tipo "tener un" entre clases. Cuando la clase contenida no existe independientemente de la clase que la contiene se denomina agregación por valor y además implica contenido físico, mientras que si existe independientemente y se accede a ella indirectamente, es agregación por referencia.
Uso. Es un refinamiento de la asociación donde se especifica cual es el cliente y cual el servidor de ciertos servicios, permitiendo a los clientes acceder sólo a las interfaces públicas de los servidores, ofreciendo mayor encapsulación de la información.
Metaclases. Son clases cuyos ejemplos son a su vez clases. No se admiten en C++.
Relaciones entre clases y objetos.
Todo objeto es el ejemplo de una clase, y toda clase tiene 0 ó más objetos. Mientras las clases son estáticas, con semántica, relaciones y existencia fijas previamente a la ejecución de un programa, los objetos se crean y destruyen rápidamente durante la actividad de una aplicación.
El diseño de clases y objetos es un proceso incremental e iterativo. Debe asegurar la optimización en los parámetros:
Acoplamiento: Grado de acoplamiento entre módulos.
Cohesión: Mide el grado de conectividad entre elementos de un módulo, y entre objetos de una clase.
Camacho Hernández Alberto
Suficiencia: Indica que las clases capturan suficientes características de la abstracción para conseguir un comportamiento e interacción eficiente y con sentido.
Completitud: Indica que la interface de la clase captura todo el significado característico de una abstracción, escrito en el mínimo espacio.
Primitividad: Las operaciones deben implementarse si dan acceso a una representación fundamental de la abstracción. Cuales son operaciones primitivas y cuales no es un asunto subjetivo y afecta a la eficiencia en la implementación.