jueves, 24 de marzo de 2011

Ejemplo de caso de uso

SISTEMA



Actor: puede sr una persona o un sistema
Elipse: representa los casos de uso
flechas : señala el rol de cada actor



jueves, 10 de marzo de 2011

consulta casos de usos

ACTOR: Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.


 
ROL: Los roles son agrupaciones de permisos. El rol más común es el de “miembro”. Podéis definir roles adicionales cuando necesitéis una unidad de permisos para formar un grupo.
Cuando se asigna un rol, a un usuario éste se mantiene en las carpetas inferiores (roles adquiridos).
Documentos / Archivos / Imagen / Carpetas

CUANTOS ROLES PUEDE TENER UN USUARIO
 Para un mejor control y administración de Roles en Los usuarios preferiblemente es mejor separar manejar dos roles es decir, roles que te permiten solo visualizar y roles que te permitan ejecutar (crear modificar y borrar) y al mismo tiempo separarlos por modulo o procesos eso depende de cada empresa y proyecto.

PARA QUIEN ESTAN DIRIGIDOS LOS DIAGRAMAS DE LOS CASOS DE USO

Para los clientes

CUANTOS NIVELES DE DIGRAMAS  DE CASOS DE USO EXISTEN: FALTA
QUE HACER CUANDO EL DIAGRAMA DE CASO DE USO ES MUY GRANDE Y NO CABE EN UNA HOJA
Organizarlos por modulos

CUANDO SE TIENE UN DIAGRAMA DE CASOS DE USO  MUY COMPLEJO QUE RECOMENDARIAS

CLASE: es la unidad básica que encapsula toda la información de un Objeto. A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones:

<Nombre Clase>
<Atributos>
<Operaciones o Métodos>


OBJETOS: Se puede decir que un objeto es todo aquello que pueda ser identificable dentro de una especificación de requerimientos o problema y tenga las siguientes características: Tenga estados definibles (abierto, cerrado).
 Posea comportamientos asociados (puede correr, saltar, volar, etc). Éstos son denominados métodos.
 Son capaces de interactuar/comunicarse con otros objetos por medio de sus métodos
Una característica propia de este paradigma, es la transparencia entre la implementación a nivel de código y la funcionalidad que provee un método (no me interesa cómo lo haga, sólo que lo haga).

INSTANCIA
Una clase es la estructura de un objeto, es decir, la definición de todos los elementos de que está hecho un objeto. Un objeto es, por lo tanto, el "resultado" de una clase. En realidad, un objeto es una instancia de una clase, por lo que se pueden intercambiar los términos objeto o instancia (o incluso evento).

Una clase es como la definición de un objeto, pero no es el objeto en sí, del modo como una idea no es una cosa física (el ejemplo de la silla). Así que para sentarnos necesitaremos convertir esa idea en algo, en un objeto real; a ese objeto lo llamamos instancia.
En un mismo proyecto puedo tener una o más instancias de una misma clase sin problemas.
Cada vez que creamos una nueva instancia, ésta adquiere las propiedades, métodos y eventos de la clase a la que pertenece (es lo que permite la relación es un), sin embargo, cada instancia es independiente de las otras; esto nos da dos ventajas:
  1. Si hago algún cambio en la clase, todas las instancias de esta clase se actualizarán automáticamente; esto nos permite hacer cambios sin tener que ir a cada una de las instancias (se aplica el mismo principio de herencia, aunque a un nivel diferente).
  2. Al ser independientes de las otras instancias, puedo darles valores diferentes sin que afecten a las demás (como tener una silla negra, una roja, una más alta, etc.). Aunque comparten la misma estructura, pueden programarse individualmente, dando versatilidad y flexibilidad al código.

UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo ¾ los símbolos utilizados en los modelos ¾ y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 1).



QUE ES ENCAPSULACIÒN: La encapsulación es un mecanismo que consiste en organizar datos y métodos de una estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el acceso a datos por cualquier otro medio distinto a los especificados. Por lo tanto, la encapsulación garantiza la integridad de los datos que contiene un objeto.
Existen tres niveles de acceso:

      Público: funciones de toda clase pueden acceder a los datos o métodos de una clase que se define con el nivel de acceso público. Este es el nivel de protección de datos más bajo
        · Protegido: el acceso a los datos está restringido a las funciones de clases heredadas, es decir, las funciones miembro de esa clase y todas las subclases
        · Privado: el acceso a los datos está restringido a los métodos de esa clase en particular. Este es nivel más alto de protección de datos (10)

HERENCIA: En términos simples la herencia en la P.O.O. es la capacidad que tiene los objetos para heredar todas o algunas de sus características (datos) y comportamiento (procedimientos) a sus descendientes o herederos, permitiendo así la reutilización de código lo que en la práctica se traduce en una herramienta muy potente de programación.
Esta herencia puede ser a nivel de estado (características) o protocolo (métodos y procedimientos) o ambas. La herencia en la P.O.O tiene sus raíces en el concepto de registros anidado

MENSAJES: Corresponde a la forma que tienen los objetos para comunicarse entre sí, de esta forma, el objeto que activa el mensaje se llama objeto emisor y el que lo recibe objeto receptor. Cabe señalar que un mensaje debe ser activado o generado desde un método hacia un objeto. En términos generales equivale a la llamada a un procedimiento o función.
Forma general de un mensaje:
receptor_mensaje.selector_mensaje [(parámetros)]
P/e ventana_editor.maximizar; documento1.imprimir (2);


POLIMORFISMO: Otra propiedad importante de la programación orientada a objetos es el polimorfismo. Esta propiedad, en su concepción básica, se encuentra en casi todos los lenguajes de programación. El polimorfismo, en su expresión más simple, es el uso de un nombre o un símbolo para representar o significar mas de una acción.
Esta propiedad permite que un mismo método se comporte de forma distinta dependiendo de que objeto lo esta ejecutando. Por ejemplo, todos los mamíferos tienen el método comer, pero este método se efectuara de forma distinta si este mamífero es un ciervo comiendo hierba, un león comiendo carne, una ballena comiendo plancton o un niño comiéndose un caramelo.
La gran ventaja ofrecida por el polimorfismo es permitir que los nuevos tipos de datos sean manipulados de forma similar que los tipos de datos predefinidos, logrando así ampliar el lenguaje de programación de una forma más ortogonal.


 ABSTRACCION: es uno de los medios más importantes mediante el cual nos enfrentamos con la complejidad inherente al software. La abstracción es la propiedad que permite representar las características esenciales de un objeto sin preocuparse de las restantes características ( no esenciales ). La abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementación.


RELACIONES ENTRE CLASES
Las relaciones entre clases juegan un papel muy importante en el modelo de objetos. Las clases, al igual que los objetos, no existen de modo aislado. Por esta razón existirán relaciones entre clases y entre objetos.
Las relaciones entre clases, se deben a dos razones: 1) una relación de clases puede indicar algún tipo de compartición 2) una relación entre clases puede indicar algún tipo de conexión semántica.
Los tres grandes tipos de relaciones entre clases son:
·         Generalización / especialización (es-un)
·         Agregación (todo-parte//tiene-un)
·         Asociación.


MODULARIDAD: Descomponer un programa en un número pequeño de abstracciones coherentes que pertenecen al dominio del problema y enmascaran la complejidad interna.
 Modularizar es dividir un programa en módulos que pueden ser compilados separadamente pero existiendo conexiones entre los módulos.
Parnas dice además que deben (las conexiones) seguir el criterio de ocultación.
Booch piensa que la modularización deber ser propiedad de un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados.


SOBRECARGA: En programación orientada a objetos la sobrecarga se refiere a la posibilidad de tener dos o más funciones con el mismo nombre pero funcionalidad diferente. Es decir, dos o más funciones con el mismo nombre realizan acciones diferentes. El compilador usará una u otra dependiendo de los parámetros usados. A esto se llama también sobrecarga de funciones.
También existe la sobrecarga de operadores que al igual que con la sobrecarga de funciones se le da más de una implementación a un operador.
Sobrecarga es la capacidad de un lenguaje de programación, que permite nombrar con el mismo identificador diferentes variables u operaciones
El mismo método dentro de una clase permite hacer cosas distintas en función de los parámetros
Java no permite al programador implementar sus propios operadores sobrecargados, pero sí utilizar los predefinidos como el +. • C++, por el contrario si permite hacerlo.

Ej: Tenemos un método que soporta varios tipos de parámetros, entonces cuando hacemos uso de este, lo que hace el compilador es buscar el que posee ese tipo de parámetros.

Color (int r, int g, int b)
Color (float a, float b, float c)
//--------------------------------------------
//r,g,b (son valores enteros entre 0 y 255)
//a,b,c (son valores flotantes entre 0.0 y 1.0)
Entonces cuando hacemos un llamado a este método (en este caso seria un constructor), el compilador hace referencia al tipo de parámetros. La sobrecarga seria redefinir cualquiera de estos métodos utilizando los mismos parámetros pero para un proceso distinto.

ESTRUCTURA DE UN OBJETO Y COMO SE REPRESENTA EN UML

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
1 - RELACIONES
2 - PROPIEDADES
3 - METODOS
Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propieda de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.
Los métodos son las operacione sque pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.

QUE ES EXTENSION: Extensión (Extend)
Es otra forma de interacción, un caso de uso dado, (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. uso extensión puede ser insertada en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."


QUE ES AGREGACION: cuando una clase se compone de otras







miércoles, 9 de marzo de 2011

CONSULTA POO

 POO: pensar en términos de objetos es muy parecido a cómo lo haríamos en la vida real. Por ejemplo vamos a pensar en un coche para tratar de modelizarlo en un esquema de POO. Diríamos que el coche es el elemento principal que tiene una serie de características, como podrían ser el color, el modelo o la marca. Además tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o aparcar.
Pues en un esquema POO el coche sería el objeto, las propiedades serían las características como el color o el modelo y los métodos serían las funcionalidades asociadas como ponerse en marcha o parar.

CLASES: son plantillas que agrupan comportamiento (métodos) y estados (atributos) de los futuros objetos.
Los objetos son instancias de una clase. Usando el símil “variable – tipo” de la programación estructurada, se entiendo que un objeto es una variable que tiene el comportamiento y estados del tipo (objeto)
Las clases son declaraciones de objetos, también se podrían definir como abstracciones de objetos. Esto quiere decir que la definición de un objeto es la clase. Cuando programamos un objeto y definimos sus características y funcionalidades en realidad lo que estamos haciendo es programar una clase.

OBJETOS: Se puede decir que un objeto es todo aquello que pueda ser identificable dentro de una especificación de requerimientos o problema y tenga las siguiente características: Tenga estados definibles (abierto, cerrado).
 Posea comportamientos asociados (puede correr, saltar, volar, etc). Éstos son denominados métodos.
 Son capaces de interactuar/comunicarse con otros objetos por medio de sus métodos
Una característica propia de este paradigma, es la transparencia entre la implementación a nivel de código y la funcionalidad que provee un método (no me interesa cómo lo haga, sólo que lo haga).

 

INSTANCIA:   Bien, decíamos que una clase es como la definición de un objeto, pero no es el objeto en sí, del modo como una idea no es una cosa física (el ejemplo de la silla). Así que para sentarnos necesitaremos convertir esa idea en algo, en un objeto real; a ese objeto lo llamamos instancia.
En un mismo proyecto puedo tener una o más instancias de una misma clase sin problemas
Cada vez que creamos una nueva instancia, ésta adquiere las propiedades, métodos y eventos de la clase a la que pertenece (es lo que permite la relación es un), sin embargo, cada instancia es independiente de las otras; esto nos da dos ventajas:
  1. Si hago algún cambio en la clase, todas las instancias de esta clase se actualizarán automáticamente; esto nos permite hacer cambios sin tener que ir a cada una de las instancias (se aplica el mismo principio de herencia, aunque a un nivel diferente).
  2. Al ser independientes de las otras instancias, puedo darles valores diferentes sin que afecten a las demás (como tener una silla negra, una roja, una más alta, etc.). Aunque comparten la misma estructura, pueden programarse individualmente, dando versatilidad y flexibilidad al código.

HERENCIA: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.
POLIMORFISMO: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

ATRIBUTO:: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

METODO: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema

MENSAJE: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó
Encapsulamiento
Se dice que es el empaquetado de métodos y atributos dentro de un objeto, mediante una interfaz grafica. La clave está precisamente en el envoltorio del objeto.
Como se puede observar de los diagramas, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la protección de sus métodos se le llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa.
El encapsulamiento de variables y métodos en un componente de software ordenado es, todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software: El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto en una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el ocultamiento que veremos a continuación. La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque lo que nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.
La encapsulación da lugar a que las clases se dividan en dos partes:
  1. Interface: captura la visión externa de una clase, abarcando la abstracción del comportamiento común a los ejemplos de esa clase.
  2. Implementación: comprende la representación de la abstracción, así como los mecanismos que conducen al comportamiento deseado.
Formas de encapsular
  1. Estándar (Predeterminado)
  2. Abierto: Hace que el miembro de la clase pueda ser accedido desde el exterior de la Clase y cualquier parte del programa.
  3. Protegido: Solo es accesible desde la Clase y las clases que heredan (a cualquier nivel).
  4. Semi cerrado : Solo es accesible desde la clase heredada
  5. Cerrado: Solo es accesible desde la Clase.
En el encapsulamiento hay analizadores que pueden ser semánticos y sintácticos.

Estado : es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.

Estado
El estado de un objeto se refiere al conjunto de los valores de sus atributos en un instante de tiempo dado. El comportamiento de un objeto puede modificar el estado de este. Cuando una operación de un objeto modifica su estado se dice que esta tiene "efecto colateral".
Esto tiene especial importancia en aplicaciones que crean varios hilos de ejecución. Si un objeto es compartido por varios hilos y en el transcurso de sus operaciones estas modifican el estado del objeto, es posible que se deriven errores del hecho de que alguno de los hilos asuma que el estado del objeto no cambiará ..
.
TIPOS DE METODOS
-cientifico -mental -psicotecnico y de maicon -Como ya se mencionó, los métodos de instancia están relacionados con un objeto en particular, mientras que los métodos estáticos o de clase (también denominados métodos compartidos) están asociados a una clase en particular. En una implementación típica, a los métodos de instancia se les pasa una referencia oculta al objeto al que pertenecen, comúnmente denominada this o self (referencias a sí mismo por sus significados en inglés), para que puedan acceder a los datos asociados con el mismo. Un ejemplo típico de un método de clase sería uno que mantuviera la cuenta de la cantidad de objetos creados dentro de esa clase.
Los llamados métodos obtener y métodos establecer (en inglés get y set) proveen un mecanismo para leer y modificar (respectivamente) los datos privados que se encuentran almacenados en un objeto o clase.

martes, 8 de marzo de 2011

CASO DE USO, ACTORES Y ROLES

CASO DE USO
En ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.
En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Pasos para la Definición de un Caso de Uso:
  • ID
  • NOMBRE
  • REFERENCIAS CRUZADAS
  • CREADO POR
  • ULTIMA ACTUALIZACION POR
  • FECHA DE CREACION
  • FECHA DE ULTIMA ACTUALIZACION
  • ACTORES
  • DESCRIPCION
  • TRIGGER
  • PRE-CONDICION
  • POST-CONDICION
  • FLUJO NORMAL
  • FLUJOS ALTERNATIVOS
  • INCLUDES
  • FRECUENCIA DE USO
  • REGLAS DE NEGOCIO
  • REQUERIMIENTOS ESPECIALES
  • NOTAS Y ASUNTO

ACTORES
Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.

Tipos de relaciones
  • ``comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso.
  • ``usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.
  • ``extiende (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura
Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra, utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.
En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido.
En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.
Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.
Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases.
Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a descartarla, si es el caso.






ROLES
Los roles son agrupaciones de permisos. El rol más común es el de “miembro”. Podéis definir roles adicionales cuando necesitéis una unidad de permisos para formar un grupo.
Cuando se asigna un rol, a un usuario éste se mantiene en las carpetas inferiores (roles adquiridos).
Documentos / Archivos / Imagen / Carpetas
Rol de propietario
Tener éste rol sobre una carpeta implica poder visualizar y editar (siempre hablando del mismo nivel e inferiores) el contenido de la misma, tanto si son carpetas o archivos, sea cual sea su estado: Visible, Privado, Publicado.
También se puede acceder a las pestañas de contenidos, visualiza. Edita y comparte.
Si el estado de la carpeta, sobre la que se tiene el rol de Propietario es además privada (es decir su estado es privado), únicamente será visible para aquellos grupos que tengan el rol de Propietario.
Rol de Empleado
Tener el Rol de Empleado sobre una carpeta  implica poder visualizar todo su contenido en los estados Visible o Publicado, tanto si son carpetas o archivos. No se pueden visualizar en los elementos que se encuentren en estado Privado.
El estado en el que debería estar esta carpeta para asignarle un rol de empleado, y poder así visualizar dicho contenido, podria ser el de Visible o Publicado (en este caso no tiene mucho sentido asignar un rol a la carpeta), nunca Privado. 
Rol de Revisor
Tener el Rol de Revisor sobre una carpeta implica poder visualizar todo  su contenido, únicamente si el estado de esta carpeta en cuestión es Visible (o Publicado), si fuese Privada no la vería.
Rol de Gestor
 Tener el Rol de Gestor sobre una carpeta implica poder visualizar todo
 su contenido, tanto si el estado de esta carpeta en cuestión es Visible
 ó Privado, y tanto si el contenido de la misma: carpetas o archivos, es 
 Visible ó Privado.

Y al igual que con el rol de Propietario, se tiene también acceso a las pestañas de contenidos, visualiza. Edita y comparte, a las cuales no se puede acceder con el resto de Roles.

Rol de miembro

Tener el Rol de Miembro sobre una carpeta implica poder visualizar todo su contenido, siempre y cuando este contenido no sea Privado, y podré visualizar esta carpeta en cuestión siempre que el estado de la misma no sea Privado.
Rol de Responsable
Tener el Rol de Responsable sobre una carpeta implica poder visualizar todo su contenido, tanto si el estado de esta carpeta en cuestión es Visible ó Privado, y tanto si el contenido de carpetas o archivos es Visible ó Privado.