2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
Transcript of 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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
3/36
MODELO DE CASO DE USO
3
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
4/36
MODELO DE CASO DE USO
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
17/36
DIAGRAMA DE SECUENCIA - EJEMPLO
17
ÍconoBoundary Ícono control Ícono Entity
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
25/36
MODELO DE CLASES
El modelo de clase puede ser agrupado en paquetes de comportamiento y
estados relacionados.
25
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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.
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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.
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
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.
-
8/17/2019 2012_CIF6558 IngenieriaSoftware UNIDAD 0 UML
36/36
REVISAR MÁS DETALLE EN:
36
http://www.sparxsystems.com/resources/uml2_tutorial/