2012_cif6558 ingenieriasoftware unidad 0 uml

8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML

1/36

RESUMEN DE UML

1

Ingeniería de Software

Universidad de Playa AnchaFacultad de Ingeniería

Departamento de Informática y Computación

Ingeniería Informática


2/36

MODELO DE CASO DE USO

Un modelo de caso de uso describe la funcionalidad propuesta de un nuevo

sistema.

Un caso de uso representa una unidad discreta de interacción entre un usuario (humano o máquina) y el sistema.

Esta interacción es una sola unidad de trabajo significativo, por ejemplo, CrearCuenta o Ver los Detalles de la Cuenta.

Cada caso de uso describe la funcionalidad que se construirá en el sistemapropuesto, que puede incluir la funcionalidad de otro caso de uso o extender

otro caso de uso con su propio comportamiento.

2


3/36


3


4/36


Una descripción general de casos de uso incluye:

Comentarios generales y notas que describen el caso de uso.

Requisitos

Requisitos funcionales formales sobre las cosas que un caso de uso debeproporcionar al usuario final, tales como .

Estos corresponden a las especificaciones funcionales que se encuentranen las metodologías estructuradas, y constituyen un contrato queestablece que el caso de uso realiza alguna acción u ofrece algún valor alsistema.

4


5/36

MODELO DE CASO DE USO Restricciones reglas formales y limitaciones bajo las que un caso de uso

funciona definición de lo que puede y no puede hacer.

Estas incluyen:

Pre-Condiciones que debe haber ocurrido antes de que el caso de uso se

ejecute, por ejemplo, debe preceder a

Post-condiciones que deben darse una vez que el caso de uso escompletado, por ejemplo,

Invariantes que deben ser siempre ciertas durante el tiempo que el casode uso opera, por ejemplo: un pedido debe tener siempre un número decliente.

5


6/36

MODELO DE CASO DE USO Escenarios

Descripciones formales y secuenciales de los pasos tomados para llevar acabo el caso de uso, o el flujo de eventos que ocurre durante una instanciade caso de uso.

Estos pueden incluir escenarios múltiples, para atender circunstanciasexcepcionales y caminos alternativos de procesamiento. Estosgeneralmente se crean en forma de texto y corresponden a unarepresentación textual del diagrama de secuencia.

Diagramas de Escenario – Diagramas de secuencia, similares a los escenariospero descritos gráficamente.

Atributos adicionales, tales como la fase de implementación, número deversión, complejidad, estereotipo y estado.

6


7/36

ACTORES Los casos de uso habitualmente se relacionan a actores, que son entidades

humanas o máquinas que usan o interactúan con el sistema para ejecutaruna porción de trabajo significativo que lo ayuda a lograr un propósito.

El conjunto de casos de uso a los que un actor tiene acceso define su rol general en el sistema y el alcance de su acción.

7


8/36

RELACIONES INCLUDES/EXTENDS ENTRE CASOS DE USO

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su

procesamiento normal.

En general, se asume que el caso de uso incluido se llama cada vez que seejecuta el camino básico. Por ejemplo, cuando se listan una serie de pedidos deun cliente para seleccionarlos antes de modificar un pedido, el caso de uso

se debe incluir cada vez que el caso de uso es ejecutado.

Un Caso de Uso puede ser incluido por uno o más casos de uso, esto ayuda areducir la duplicación de funcionalidad al factorizar un comportamiento comúnen los casos de uso que son reutilizados muchas veces.

8


9/36

RELACIONES INCLUDES/EXTENDS ENTRE CASOS DE USO

Un Caso de Uso puede extender el comportamiento de otro, por lo general

cuando se encuentran circunstancias excepcionales.

Por ejemplo, si un usuario debe obtener la aprobación de alguna autoridadsuperior antes de modificar un tipo particular de pedido de cliente, entoncescaso de uso puede extender opcionalmente el caso de

uso normal .

9


10/36

DIAGRAMAS DE SECUENCIA

Los diagramas de secuencia proporcionan una representación gráfica de la

interacción de objetos en el tiempo.

Estos generalmente muestran un usuario o actor, y los objetos y componentesque interactúan en la ejecución de un caso de uso. Un diagrama de secuenciageneralmente representa un “escenario” único de un caso de uso o el flujo de

eventos.

Los diagramas de secuencia son una excelente forma de documentar escenariosde uso y capturar los objetos que se requieren tempranamente en el análisis yla verificación de uso de esos objetos más tarde en el diseño. Los diagramas

muestran el flujo de mensajes de un objeto a otro, y, como tal, corresponde alos métodos y eventos soportados por una clase / objeto.

10


11/36

DIAGRAMAS DE SECUENCIA

El siguiente ejemplo de un diagrama de secuencia muestra el usuario o el

agente de la izquierda iniciando un flujo de eventos y mensajes quecorresponde al escenario de un caso de uso. Los mensajes que pasan entreobjetos se convierten en operaciones de clase en el modelo final.

11


12/36

DIAGRAMAS DE IMPLEMENTACIÓN

Un caso de uso es una descripción formal de la funcionalidad que el sistema

tendrá cuando se construya.

Un diagrama de implementación se asocia generalmente con un caso de usopara documentar qué elementos de diseño (por ejemplo, componentes yclases) implementarán la funcionalidad del caso de uso en el nuevo sistema.

Esto proporciona un alto nivel de trazabilidad para el diseñador del sistema, elcliente y el equipo que realmente va a construir el sistema. La lista de casos deuso de un componente o clase está vinculada a los documentos de lafuncionalidad mínima que debe ser implementada por el componente.

12


13/36

DIAGRAMAS DE IMPLEMENTACIÓN

El ejemplo muestra que el caso de uso “Login” implementa el requisito formal“1 .01 Iniciar sesión en el sitio web”. También muestra que el componente

"lógica empresarial" y "páginas ASP" implementa alguna o toda lafuncionalidad de “Login” .

Un refinamiento adicional muestra la pantalla “Login” (una página web) comola implementación del caso de uso “Login” . Esta implementación o link“realize” define la trazabilidad desde el requerimiento formal a través del caso

de uso sobre componentes y pantallas.

13


14/36

MODELO DINÁMICO

El modelo dinámico se utiliza para expresar y modelar el comportamiento del

sistema en el tiempo.

Incluye soporte para diagramas de actividad, diagramas de estado, diagramasde secuencia y extensiones incluyendo modelado de procesos de negocio.

14


15/36

DIAGRAMA DE SECUENCIA Los diagramas de secuencia se utilizan para mostrar la interacción entre los usuarios,

pantallas, objetos y entidades del sistema.

Proporciona un mapa secuencial de paso de mensajes entre objetos en el tiempo.

Frecuentemente, estos diagramas se colocan debajo de los Casos de Uso en el modelopara ilustrar el escenario de caso de uso - cómo un usuario interactúa con el sistema y loque sucede internamente para hacer el trabajo.

A menudo, los objetos se representan usando iconos especiales estereotipados, como enel ejemplo a continuación.

El objeto etiquetado pantalla de Login se muestra mediante el ícono de interfaz deusuario.

El objeto etiquetado SecurityManager se indica mediante el ícono de controlador.

El objeto que lleva la etiqueta de users se muestra con el ícono de Entidad.

15


16/36

ESTEREOTIPOS

Entity Class: clase del dominio del problema

Control Class: clase que media entre clases boundary y clases entity actuando comoconmutador o central entre la capa de presentación y la de dominio

Boundary or View Class: clase que existe en una frontera de automatización, como una

ventana de entrada

16


17/36

DIAGRAMA DE SECUENCIA - EJEMPLO

17

ÍconoBoundary Ícono control Ícono Entity


18/36

DIAGRAMA DE ACTIVIDAD Los diagramas de actividad se utilizan para mostrar cómo se construyen diferentes flujos de trabajo

en el sistema, cómo se inician y los muchos caminos de decisión posibles que se pueden tomardesde el principio hasta el final.

También pueden ilustrar donde el procesamiento en paralelo puede ocurrir en la ejecución dealgunas actividades.

18


19/36

DIAGRAMA DE ESTADO Los diagramas de estado son usados para detallar la transición o cambios de estado por

los cuales un objeto puede pasar en el sistema. Ellos muestran como un objeto pasa desde un estado a otro y las reglas que gobiernan

estos cambios.

Los diagramas de estado habitualmente tienen una condición de inicio y de fin.

19


20/36

MODELO LÓGICO

Un modelo lógico es una visión estática de los objetos y las clases que

componen el espacio de análisis/diseño.

Por lo general, un modelo de dominio es una vista más pobre, una vista de altonivel de los objetos de negocio y entidades, mientras que el modelo de claseses más riguroso y centrado en el modelo de diseño.

20


21/36

MODELO DE CLASES

Una clase es un constructo estándar UML usado para especificar el patrón

desde el cual los objetos debe ser creados en tiempo de ejecución.

Una clase es una especificación - un objeto es una instancia de una clase.

Las clases pueden heredar de otras clases (es decir, heredan todo elcomportamiento y el estado de su padre y agregan nuevas funcionalidades desu propiedad), pueden tener otras clases como atributos, y pueden delegarresponsabilidades a otras clases e implementar interfaces abstractas.

21


22/36

MODELO DE CLASES

El modelo de clases es el “core” del desarrollo orientado a objetos y del diseño

– este expresa el estado persistente del sistema y el comportamiento delsistema.

Una clase encapsula el estado (atributos) y ofrece servicios para manipular eseestado (comportamiento).

Un buen diseño orientado a objetos limita el acceso directo a los atributos de laclase y ofrece servicios que los manipulan en representación del “llamador”.

Este ocultamiento de datos y exposición de servicios asegura que laactualización de los datos se realiza en un sólo en un lugar y de acuerdo conreglas específicas - para sistemas grandes la carga de mantención del códigoque tiene acceso directo a los elementos de datos en muchos lugares esextremadamente alta.

22


23/36

MODELO DE CLASES

Note que la clase tiene tres áreas diferenciadas:

1. El nombre de la clase (y estereotipo si se aplica)

2. El área de atributos de la clase (elementos de dato internos)

3. El comportamiento - tanto público como privado

Los atributos y métodos pueden ser:

Private: indicando que no son visibles para llamadas fuera de la clase

Protected: solo son visibles para los hijos de la clase

Public : son visibles para todos

23


24/36

HERENCIA

A continuación se muestra la herencia de clases : una clase abstracta en este

caso, es la clase padre de dos clases hijas, cada una de las cuales hereda lascaracterísticas de la clase base y la extiende con su propio comportamiento.

24


25/36

MODELO DE CLASES

El modelo de clase puede ser agrupado en paquetes de comportamiento y

estados relacionados.

25


26/36

MODELO DE COMPONENTES

El modelo de componentes ilustra los componentes de software que se usarán

para construir el sistema.

Estos pueden ser construido a partir del modelo de clases y escrito desde ceropara el nuevo sistema, o pueden ser traídos desde otros proyectos yproveedores de 3° Parte.

Los componentes son agregaciones de alto nivel de piezas de software máspequeñas y proporcionan un enfoque de construcción de bloques de “blackbox“ (caja negra) para la construcción del software.

26


27/36

NOTACION DE COMPONENTES

Un componente puede ser algo así como un ActiveX control - ya sea un control

de interfaz de usuario o un servidor de reglas de negocio.

Los componentes se representan como muestra el siguiente diagrama:

27


28/36

DIAGRAMA DE COMPONENTES

El diagrama de componentes muestra la relación entre los componentes de

software, sus dependencias, comunicación, ubicación y otras condiciones.

Interfaces

Los componentes también pueden exponer interfaces. Estos son los puntos deentrada visibles o servicios que un componente está ofreciendo y poniendo adisposición de otras clases y componentes de software.

Generalmente, un componente esta compuesto de muchas clases internas y

paquetes de clases. Incluso puede ser ensamblado a partir de una colección decomponentes más pequeños.

28


29/36

COMPONENTES Y NODOS

Un diagrama de despliegue muestra la implementación física del sistema

dentro de un entorno de producción (o de prueba). Muestra dónde los componentes serán ubicados, en qué servidores, máquinas

o hardware. Puede representar enlaces de red, ancho de banda de la LAN, etc.

29


30/36

COMPONENTES Y NODOS

Requisitos

Los componentes pueden tener requisitos adjuntos para indicar sus obligacionescontractuales - es decir, que servicio proporcionarán en el modelo. Requisitos ayudan adocumentar el comportamiento funcional de los elementos de software.

Restricciones

Los componentes pueden tener restricciones asignadas que indican el entorno en elque operan.

Pre-condiciones especifican que se debe cumplir antes de que un componente

puede ejecutar alguna función. Post-condiciones indican lo que va a ser cierto después de un componente ha hecho

algún trabajo

Invariantes especifican lo que debe seguir siendo válido para la duración de la vidaútil de los componentes.

30


31/36

COMPONENTES Y NODOS

Escenarios

Los escenarios son descripciones procedurales/textuales de las acciones de un objetoen el tiempo y describen la forma en que un componente funciona. Escenariosmúltiples puede ser creado para describir la ruta básica (ejecución perfecta), así comoexcepciones, errores y otras condiciones.

Trazabilidad

La trazabilidad se puede indicar a través de link de realización.

Un componente puede implementar otro elemento del modelo (por ejemplo, un caso

de uso) o un componente puede ser implementado por otro elemento (ej: un paquetede clases).

A través de los link de realización desde y hacia los componentes se pueden mapear lasdependencias entre los elementos del modelo y la trazabilidad de los requisitosiniciales hasta la implementación final.

31


32/36

EJEMPLO

32

El ejemplo muestra cómo los componentespueden estar relacionados paraproporcionar una vista lógico/ conceptual

de la construcción de un sistema.

Este ejemplo tiene que ver con el servidor ylos elementos de seguridad de una tiendade libros en línea.

Este incluye elementos tales como, servidor

web, firewall y páginas ASP, etc.

Este diagrama muestra la disposición de loscomponentes del lado del servidor principalque se requieren para la construcción deuna tienda de libros en línea.

Estos componentes son una mezcla deelementos construidos personalizados yadquiridos, que se ensamblaron paraproporcionar la funcionalidad requerida.


33/36

COMPONENTES DE SEGURIDAD

33

El diagrama de componentes de seguridad muestra como SW de

seguridad, tales como la Autoridad Certificadora, el Navegador, elServidor Web y otros elementos del modelo trabajan juntos para asegurarnormas de seguridad en el sistema propuesto.


34/36

MODELO FISICO

34

El Modelo Físico/Implementación ofrece un modelo detallado de la forma en

que los componentes serán implementados a través de la infraestructura delsistema.

En él se detallan las capacidades de la red, las especificaciones del servidor, losrequisitos de hardware y otra información relacionada con la implementacióndel sistema propuesto.

Deployment View


35/36

MODELO FISICO

35

El modelo físico muestra dónde y cómo los componentes del sistema se

implementarán. Es un mapa específico de la disposición física del sistema. Un diagrama

despliegue muestra la implementación físico del sistema en un entorno deproducción (o prueba).

Muestra dónde se ubican los componentes, en qué servidores, máquinas o

hardware. Puede representar los enlaces de red, ancho de banda LAN, etc.


36/36

REVISAR MÁS DETALLE EN:

36

http://www.sparxsystems.com/resources/uml2_tutorial/

2012_cif6558 ingenieriasoftware unidad 0 uml

Documents