DIAGRAMAS DE CLASES

DEFINICIÓN:

En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.
Son los diagramas más comunes en el modelado de sistemas orientados a objetos.

Un diagrama de clase muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre ellos.

Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son también la base para un par de diagramas relacionados: Diagramas de Componente y Diagramas de Instalación(Deployment).

Los diagramas de clase son importantes no solo para la visualización, especificación y documentación del modelo estructural, pero también para la construcción de sistemas ejecutables. Ingeniería hacia adelante e ingeniería inversa.

La construcción de software tiene muchas características similares, excepto, que la calidad(Fluidez) de software, uno tiene la habilidad de definir la construcción de bloques básicos para ir detallando(scratch).


ELEMENTOS:

CLASE:Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.)

ATRIBUTOS:son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Ejemplo: el objeto es una puerta, sus propiedades o atributos serían: la marca, tamaño, color y peso.

OPERACIONES:son aquellas actividades o verbos que se pueden realizar con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, confirmar, cargar. El nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrir Puerta, cerrar Puerta, buscar Puerta, etc.

VISIBILIDAD:Para especificar la visibilidad de un miembro de la clase (es decir, cualquier atributo o método), se coloca uno de los siguientes signos delante de ese miembro:

TIPOS DE DATOS:En el diagrama de clases debemos especificar el conjunto de posibles valores que puede tomar cada atributo. Estos valores pueden ser valores numéricos, cadenas de caracteres, booleanos, o incluso otras clases de nuestro diagrama (aunque esto no es muy común ni recomendable).

Representaremos los tipos de datos de los atributos de la siguiente manera: 

RESUMEN:

Un diagrama de clase muestra un conjunto de clases, interfaces, y colaboraciones y sus relaciones entre ellos.
Los diagramas de clase se usan en el diseño del modelo estático para ver un sistema. Para las demás partes, este modelado involucra el vocabulario del sistema, el modelado de colaboraciones, o modelado de esquemas. Los diagramas de clase son también la base para un par de diagramas relacionados: Diagramas de Componente y Diagramas de Instalación(Deployment).

SUMMARY:

A class diagram shows a set of classes , interfaces, and collaborations and their relationships with each other.

Class diagrams are used in designing the static model for a system . For the other parties, this involves modeling the vocabulary of the system, modeling collaborations, or modeling schemes . Class diagrams are also the basis for a couple of related diagrams : component diagrams and diagrams Installation ( Deployment) .

RECOMENDACIONES:

Para un buen diseño es importante  tener un buen análisis y saber utilizar las herramientas en los diagramas de clases.

CONCLUSIONES:

Los diagramas de clases nos ayudan a comprender de una mejor manera ,  la aplicación  .

APRECIACIÓN DE EQUIPO:

los diagramas de clases  es una vista de la forma que va a tomar el sistemas a desarrollar.

LINKOGRAFIA:

https://es.wikipedia.org/wiki/Diagrama_de_clases
http://www.mcc.unam.mx/~cursos/Objetos/Cap8/cap8.html

Presentacion en Diapositiva: SlideShare

Juan Julca Landacay

DIAGRAMAS DE CASO DE USO

DEFINICIÓN:

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar más de un caso de uso para poder identificar qué es lo que hace un caso de uso.

• La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.
• La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

Casos de uso UML para un modelo simple de restaurante.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.

La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.

ELEMENTOS:

Actores

Un actor es alguien o algo que interactúa con el sistema; es quien utiliza el sistema. Por la frase "interactúa con el sistema" se debe entender que el actor envía a o recibe del sistema unos mensajes o intercambia información con el sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el sistema a modelar.

Un actor es un tipo (o sea, una clase), no es una instancia y representa a un rol. Gráficamente se representa con la figura de "stickman".

Encontrando a los actores de un diagrama de casos de uso.

Es posible obtener a los actores de un diagrama de casos de uso a través de las siguientes preguntas:

¿Quién utilizará la funcionalidad principal del sistema (actores primarios)?

¿Quién necesitará soporte del sistema para realizar sus actividades diarias?

¿Quién necesitará mantener, administrar y trabajar el sistema (actores secundarios)?

¿Qué dispositivos de hardware necesitará manejar el sistema?

¿Con qué otros sistemas necesitará interactuar el sistema a desarrollar?

CASOS DE USO:

Un caso de uso representa la funcionalidad completa tal y como la percibe un actor. Un caso de uso en UML es definido como un conjunto de secuencias de acciones que un sistema ejecuta y que permite un resultado observable de valores para un actor en particular. Gráficamente se representan con una elipse y tiene las siguientes características:

Un caso de uso siempre es iniciado por un actor.

Un caso de uso provee valores a un actor.

Un caso de uso es completo.

Encontrando casos de uso

El proceso para encontrar casos de uso inicia encontrando al actor o actores previamente definidos. Por cada actor identificado, hay que realizar las siguientes preguntas:

¿Qué funciones del sistema requiere el actor? ¿Qué necesita hacer el actor?

¿El actor necesita leer, crear, destruir, modificar o almacenar algún tipo de información en el sistema?

¿El actor debe ser notificado de eventos en el sistema o viceversa? ¿Qué representan esos eventos en términos de funcionalidad?

¿El trabajo diario del actor podría ser simplificado o hecho más eficientemente a través de nuevas funciones en el sistema? (Comúnmente, acciones actuales del actor que no estén automatizadas)

Otras preguntas que nos ayudan a encontrar casos de uso pero que no involucran actores son:

¿Qué entradas/salidas necesita el sistema? ¿De dónde vienen esas entradas o hacia dónde van las salidas?

¿Cuáles son los mayores problemas de la implementación actual del sistema?

RELACIONES:

Inclusión (include )

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual(si el actor realiza el caso de uso base tendrá que realizar también el caso de uso incluido), desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones esto no sirve.

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. El caso de uso extensión puede ser insertado 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."

documentan el comportamiento de un sistema desde el punto de vista de un usuario

En otras palabras será utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones, un ejemplo claro es que se necesite comprar azúcar y podemos seleccionar de entre azúcar rubia, blanca o su unidad de medida bolsa , kilo, etc.

Generalización

"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."

En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Asociación 

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

Dependencia o Instanciación 

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

Generalización 

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Asociación 

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

Dependencia o Instanciación 

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

EJEMPLO:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el número de ítemes ingresados.

Imprimir un recibo cuando el usuario lo solicita:

Describe lo depositado

El valor de cada item

Total

El usuario/cliente presiona el botón de comienzo

Existe un operador que desea saber lo siguiente:

• Cuantos ítemes han sido retornados en el día.
• Al final de cada día el operador solicita un resumen de todo lo depositado en el día.

El operador debe además poder cambiar:

• Información asociada a ítemes.

Dar una alarma en el caso de que:

• Item se atora.
• No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

RESUMEN: 

UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar más de un caso de uso para poder identificar qué es lo que hace un caso de uso.

Un actor es alguien o algo que interactúa con el sistema; es quien utiliza el sistema. Por la frase "interactúa con el sistema" se debe entender que el actor envía a o recibe del sistema unos mensajes o intercambia información con el sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el sistema a modelar.

SUMMARY:

UML does not define standards for the written format describes the use cases, and so many people do not understand that this graphical notation defines the nature of a use case; however a graphical notation can only give a simple overview of a use case or set of use cases. The use case diagrams are often confused with the use cases. As the two concepts are related, the use cases are much more detailed than the use case diagrams. In the concepts shLos ould detail more than one use case to identify what makes a use case.

An actor is someone or something that interacts with the system; who is using the system. By the phrase "interacts with the system" should be understood that the actor sends to or receives a message or system interfaces with the system. In short, the actor performs the use case. An actor can be a person or another system that communicates with the system modeling.

RECOMENDACIONES:

• Utilizar correctamente las elementos del Diagrama de casos de uso, debido a que cada uno cumple una función especifica.

CONCLUSIONES:

• Los casos de uso hacen ver el cuerpo completo del  sistema, define el objetivo del sistema, entre otros. 

APRECIACIÓN DE EQUIPO:

• Los Diagramas de Caso de Uso , es una herramienta vital para el diseño que tomará el desarrollo de un sistema.

LINKOGRAFÍA:

http://profesores.fi-b.unam.mx/carlos/aydoo/usecase.html

https://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso

http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html

->>Juan Julca Landacay

Presentación >>>>>> SlideShare