Analisis Orientado A Objetos Con UML

Ingeniería del Software I (4º I.I)

Tema 8: Análisis Orientado a Objetos con UML


Presentación de UML UML (Unified Modeling Language) Es un lenguaje estándar para construir planos software Modelo Conceptual de UML Tres elementos principales: Bloques Piezas básicas utilizadas en el modelado.

Reglas Dictan có mo combinar los bloques.

Mecanismos Aportan patrones que permiten construir modelos más consistentes.

1


Presentación de UML Modelo Conceptual de UML Bloques de construcción Reglas Elementos

Diagramas • Nombre

• Estructurales

• Clases

• Comportamiento

• Objetos

• Agrupación

• Casos de Uso

• Anotación

• Secuencia

Afectan

• Alcance • Visibilidad • Integridad

Afectan

• Colaboración • Estados • Actividad Colaboración

• Componentes • Despliegue Mecanismos

Relaciones • Especificaciones • Dependencia • Asociación • Generalización

Actúan

• Adornos • Divisiones comunes • Extensibilidad


Presentación de UML Bloques Tres tipos básicos: ? Elementos.- son las abstracciones de primer nivel. ? Relaciones.- unen a los elementos entre sí. ? Diagramas.- son agrupaciones de elementos que reflejan una vista del sistema .

2


Presentación de UML Elementos Dependiendo del uso: ? elementos estructurales.- describen los elementos básicos de la visión estática del sistema. ? elementos de comportamiento.- describen los elementos básicos de la visión dinámica del sistema. ? elementos de agrupación.- describe los elementos de agrupación o empaquetamiento de algunos elementos fuertemente relacionados. ? elementos de anotación.- describen los elementos que se utilizan para incluir notas descriptivas dentro de los modelos.


Presentación de UML Elementos estructurales Clase

Interfaz

Clase Activa

Caso de Uso

Componente

Colaboración

Nodo

3


Presentación de UML Elementos de comportamiento Interacción (mensaje)

Máquinas de Estados (estado)

Dibujar Esperando

Elementos de agrupamiento Paquete

Elementos de anotación Notas

Reglas del negocio

Devuelve una copia del objeto receptor


Presentación de UML Relaciones En función del tipo de interacción existente entre los elementos : ? relaciones de dependencia .- indica que un cambio en la especificación de un elemento puede afectar a otro que lo utiliza. ? relaciones de generalización.- expresa una relación entre un elemento general y una ocurrencia más específica de ese elemento (relación "es un tipo de") ? relaciones de asociación.- especifica que los objetos de un elemento están conectados con los objetos de otro. ? relaciones de realización.- define una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro garantiza que cumplirá.

Dependencia

Generalización

Asociación 0..1 patrón

* empleado

Realización

4


Presentación de UML Diagramas Representan gráficamente una vista de una parte del sistema, aportando diferentes perspectivas y diferentes niveles de detalle que facilitan la comprensión del sistema Diagrama de Casos de Uso

Diagrama de Clases Motor

Piloto

1..4

Diagrama de Secuencia Vendedor de billetes 1

1.2

: Socio

: Libro

: Encargado

: Ficha socio

: Ficha libro

: Préstamo

Coger libro

Venta Normal 1 Avión

* 1

*

Vuelo

* 1

*

Reserva Solicitar préstamo

*

{ disjunta, completa }

Verificar situación socio Situación socio ok

Venta en Rebajas Cliente

Vendedor

Aviónmilitar

1 Línea aérea

Avión comercial

Verificar situación libro Situación libro ok


Introducir préstamo Autorizarpréstamo

Avión de carga

Avión de pasajeros

Venta en Oferta

Diagrama de Colaboración 1:Cogerlibro

Diagrama de Estados

Diagrama de Actividad

: Libro

Prestar

Devolver[ Número préstamos = 1 ] :Socio

2: Solicitar préstamo

Con préstamos

: Ficha s ocio

Número préstamos > 1

3: Verificar situación socio 8: Autorizar préstamo 4: Situación socio ok

Prestar Devolver[ Número préstamos = 1 ] 6: Situación libro ok

:Encargado : Présta mo

7: Introducir préstamo

Sinpréstamos Alta

5: Verificar situación libro

Número préstamos = 0 Baja

: Ficha li bro

Diagrama de Objetos P1:

Diagrama de Componentes

Diagrama de Distribución

Control y Análisis

Profesor

Interfaz de Terminal DNI : 59.455.111 Nº Contrato:1000

Comment

S e r v i d o r A c c e s o

Comment

Nombre : José Pérez López

C e n t r Ca ol n t r o l a

B D

d e

Análisis

C o n e c c i o n

Asignatura A2:

Asignatura

-1 - 0 3 Código:4 Curso:

- 0 5

Gestión de Cuentas

Cuarto

Nombre : Ingeniería del Software I

Comment

Rutinas de Coneccion Comment

T e r m i n a l R u t i n a s

Acceso a BD Comment

P u n t o

d e

G e s t i ó n

T1:

y

C o m m e n t

C o m m e n t

R u t i n a s

A1:

Código:T1

Curso: Primero Nombre : Introducción a la Informática

Titulación

T2:

V e n t a R u t i n a s

d e

d e

d e d e

C o I n st u e lr t f a a z C o n e c c i o n

d e

T e r m i n a l

C o n e c c i o n

C u e n t a s I n t e r f a z

d e

T e r m i n a l

Titulación C o m m e n t

Código:

T1

Código:

Nombre : I. Técnica Informática Sistemas

T1

Nombre : Ing. Superior en Informática


Presentación de UML Diagramas • Diagrama de casos de uso.

Muestra un conjunto de casos de uso, actores y sus relaciones. Son especialmente importantes en la captura de los requisitos funcionales del sistema.

Diagrama de Casos de Uso Venta Normal

Venta en Rebajas

Cliente

Vendedor

Venta en Oferta

• Diagrama de clases. Muestra las clases, interfaces y colaboraciones, así como sus relaciones. Cubren la vista de diseño estática de un sistema.


1

1..2

1 Avión

Vendedor de billetes

Piloto

1..4

* 1

*

Vuelo

* 1

*

Reserva

*


1 Avión militar

Avión comercial

Línea aérea


Avión de carga

Avión de pasajeros

5


Presentación de UML Diagramas • Diagrama de actividad.

Muestra el flujo de actividades dentro del sistema. Son importante para modelar el funcionamiento de un sistema y resaltan el flujo de control entre objetos.

Diagrama de Actividad

• Diagrama de estados. Muestra una máquina de estados que consta de estados, transiciones, eventos y actividades.

Diagrama de Estados Prestar Devolver[ Número préstamos = 1 ] Con préstamos Número préstamos > 1

Prestar Devolver[ Número préstamos = 1 ]

Sin préstamos

Resaltan el comportamiento dirigido por eventos de un objeto.

Alta

Número préstamos = 0 Baja

.


Presentación de UML Diagramas • Diagrama de secuencia. Diagrama de Secuencia

Es un tipo de diagrama de interacción que resalta la ordenación temporal de los mensajes

: Libro : Socio

: Ficha socio

: Ficha libro

: Préstamo

: Encargado Cogerlibro

Solicitarpréstamo Verificar situación socio Situación socio ok Verificar situación libro Situación libro ok Introducirpréstamo Autorizar préstamo

• Diagrama de colaboración. Diagrama de Colaboración

Es el otro tipo de diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes.

1: Coger libro

:Socio

: Libro

2: Solicitar préstamo

: Ficha s ocio 3: Verificar situación socio

8: Autorizar préstamo 4: Situación socio ok

6: Situación libro ok

: Encargado 7: Introducir préstamo

: Présta mo

5: Verificar situación libro : Ficha li bro

6


Presentación de UML Diagramas • Diagrama de objetos.

Muestra un conjunto de objetos y sus relaciones. Representa instantáneas de las instancias de los elementos de un diagrama de clases.

Diagrama de Objetos P1: Profesor DNI : 59.455.111 Nº Contrato:1000 Nombre : José Pérez López

A1: Asignatura A2: Asignatura Código:T1- 1- 03 Curso: Primero Nombre : Introducción a la Informática

Código:4 - 05 Curso: Cuarto Nombre : Ingeniería del Software I

T1: Titulación

T2: Titulación

Código: T1 Nombre : I. Técnica Informática Sistemas

Código: T1 Nombre : Ing. Superior en Informática

• Diagrama de componentes. Muestra la organización y dependencias de un conjunto de componentes. Un componente se corresponde con clases, interfaces y colaboraciones.

Diagrama de Componentes Control y Análisis Interfaz de Terminal

Comment

Comment

Gestión de Cuentas

Rutinas de Coneccion

Comment

Acceso a BD

Comment

Comment


Presentación de UML Diagramas • Diagrama de distribución o despliegue.

Muestra la configuración de los nodos de procesamiento y los componentes que residen en cada uno de ellos.

Diagrama de Distribución Servidor Central Acceso a BD

Control y Análisis Comment

Comment


Terminal de Consulta Interfaz de Terminal Rutinas de Coneccion

Punto de Venta


Gestión de Cuentas

Interfaz de Terminal

7


Presentación de UML Reglas Establece restricciones a la hora de combinar los bloques de construcción. UML define reglas semánticas para: ? Nombres.- cómo llamar a los elementos, relaciones y diagramas. ? Alcance.- contexto que da un significado específico a un nombre. ? Visibilidad.- cómo se pueden ver y utilizar esos nombres por otros. ? Integridad.- cómo se relacionan apropiada y consistentemente unos elementos con otros. ? Ejecución.- qué significa ejecutar o simular un modelo dinámico.


Presentación de UML Mecanismos Aportan patrones que permiten construir modelos más consistentes . Podemos encontrar los siguientes: ? Especificaciones.- Asociada a cada elemento proporciona una explicación textual de la sintaxis y semántica del bloque de construcción. ? Adornos.- Se incluye para resaltar algunos detalles de un determinado elemento y pueden ser de tipo textual o gráfico. ? Divisiones comunes.- División entre clase y objeto; división entre interfaz e implementación. ? Mecanismos de extensibilidad.- permiten extender de manera controlada el lenguaje.

8


Presentación de UML Adornos Son complementos gr áficos o textuales que se añaden a la notación básica de un elemento para mostrar detalles de su especificación. ? Notas.- se utilizan para especificar características no recogidas en los elementos Nota del modelo (requisitos, observaciones, revisiones, restricciones, etc.). ? Otros adornos.- Asociada a cada elemento proporciona una explicación textual de la sintaxis Dar nombre a los adornos para evitar confusión.

Transacción AñadirAcción() QuitarAcción() Excepciones TransacciónVacia RecursoBloqueado


Presentación de UML Mecanismos de extensibilidad Permiten extender de manera controlada el lenguaje de modelado propuesto. ? Estereotipos.- extiende el vocabulario, permitiendo crear nuevos bloques derivados de los existentes. ? Valores etiquetados.- extiende las propiedades de un bloque permitiendo añadir nueva información a un elemento. ? Restricciones.- extiende la semántica de un bloque permitiendo añadir nuevas reglas o modificar las existentes.

9


Presentación de UML Estereotipos Es un metatipo ya que equivale a crear una nueva clase del metamodelo en el que se apoya UML Los nuevos bloque estereotipados tiene: • Sus atributos (su propio conjunto de valores etiquetados. • Su semántica (puede proporcionar restricciones propias). • Su notación (puede proporcionar su propio icono) Generalmente se presenta como un << nombre >> << metaclase>> ElementoMetamodelo

<> !

Overflow

Clase Interfaz


Presentación de UML Estereotipos Solo deben crearse cuando realmente son necesarios y no por un desarrollador aislado sino dentro de un proyecto o empresa. Cuatro tipos de estereotipos: • Decorativos .- aportan símbolos que hacen más comprensibles los modelos (p.e. símbolo de actor) • Descriptivos.- Utilizados para describir el contexto de aplicación del concepto (p.e. clase de negocio) • Restrictivos .- Aportan restricciones aplicables a ciertos elementos (p.e. interfaz)

Actor

Clase Entidad

Clase Interfaz

Clase Control

10


Presentación de UML Valores etiquetados Puede especificar nuevas propiedades a un elemento cualquiera. Por tanto, son una herramienta útil para definir detalles semánticos. Es un metadato porque su valor se aplica al propio elemento, no a sus instancias. Generalmente se presenta como una cadena de caracteres entre llaves que se coloca debajo del nombre de otro elemento. FiguraGeométrica {abstract Versión=1.3}

Servidor Central

Visible: Boolean{sololectura}

{procesadores=2}


Presentación de UML Restricciones Especifica condiciones que deben cumplirse para que el modelo esté bien formado. Estas se pueden escribir en texto libre o utilizando OCL (Object Constraint Language) si se desea una especificación más precisa. Empresa {segura} Cuenta Bancaria

{OR}

{self.esposa.sexo = mujer and self.marido.sexo = hombre}

0..1 Marido Persona

Sexo{Hombre, mujer} 0..1 Esposa

11


Presentación de UML Restricciones Pueden identificarse varios tipos de restricciones básicas: ? ? ? ? ? ? ?

Dependencia. Consistencia. Exclusión. Valores. Ordenación. Fórmulas. Enumeración.


Presentación de UML Restricciones Dependencia.- Expresan subordinación entre dos relaciones. Trabaja en Empleado

{subconjunto}

Proyecto

Responsable de Proyecto self.TrabajaEn->includes(self.ResponsableDe)

ConsistenciaCliente

1

Tiene

1 Recibe 0..* Factua self.Contrato.Cliente= self.cliente

0..* BasadoEn

Factura

Contrato

12


Presentación de UML Restricciones Exclusión.- Expresan relaciones de tipo OR o XOR. TrabajaEn Persona

Proyecto civil

{OR} TrabajaEn

Proyecto militar

Suele ser interesante sustituirla por una generalización/ especialización. Proyecto civil

TrabajaEn

Persona

Proyecto

Proyecto militar


Presentación de UML Restricciones Valores.- Las restricciones se aplican a los posibles valores de un atributo. Triángulo a {c-b
Ordenación.- Establece el criterio de ordenación de una relación que expresa una colección de elementos.

Departamento

1

Tiene

1..*

Empleado

{Ordenación:Apellido}

13


Presentación de UML Restricciones Fórmulas.- Definición de reglas de cálculo asociadas a atributos derivados. Persona fechaNacimiento /edad {edad=hoy-fechaNacimiento}

Enumeración.- Se utiliza para describir el conjunto de valores posibles de un atributo. Generalmente debe asociarsele una clase a dicho atributo. Color: {rojo, azul,verde)

Color


Modelos Dominio del Problema. ¿Qué es el Dominio del Problema? Es una parcela del mundo real que deseamos modelar. Características de los modelos asociados al Dominio del Problema. • Deben permitir describir los requisitos del sistema a modelar. • Deben tener un alto nivel de abstracción, deben contestar al QUÉ. • No deben responder a preguntas de implementación.

14


Modelos Dominio del Problema. Dentro de UML tenemos modelos que pueden ser utilizados en diferentes instantes del desarrollo para descubrir nueva información sobre el sistema Modelos que podemos utilizar para estudiar el Dominio del Problema. • • • •

Modelo o diagrama de casos de uso. Modelo o diagrama de clases abstractas. Modelo o diagrama de actividades Modelo o diagrama de secuencia básico.


Captura de requisitos. Requisitos Se recomienda utilizar los siguientes artefactos: • Descripción básica de los objetivos y metas del sistema. • Descripción de los clientes para los que se desarrolla el producto. • Funciones básicas, es decir, lo que el sistema deberá hacer. • Características no funcionales que debe tener el producto final.

15


Captura de requisitos. Características no funcionales Dentro de las características no funcionales podemos encontrar: • Facilidad de uso. • Tiempo de respuesta. • Plataforma de desarrollo e implementación. • Tolerancia a fallos. • Fiabilidad y precisión. • Mantenibilidad. • Prioridades de implementación. •...


Casos de Uso.

Caso de Uso Realizar Pedido

¿Qué es un caso de uso? Es una descripción de un conjunto de acciones que ejecuta un sistema para producir un resultado observable de valor para un actor. ?Captura y especifica el comportamiento de un sistema o de parte del mismo, sin tener que especificar cómo se implementa. ?Representa la interacción de los elementos externos al sistema.

16


Caso de Uso

Casos de Uso.

Realizar Pedido

?Puede tener variantes Se puede factorizar el comportamiento común y reutilizable de un conjunto de casos de uso según las relaciones siguientes: ? son versiones especializadas de otros más genéricos ? están incluidos como parte de otros ? extienden el comportamiento de otros más básicos


Casos de Uso.


? Se utilizan durante muchas fases del desarrollo del software. ? Captura y análisis de requisitos del sistema. ? Actúan como base del proceso de diseño y permiten validarlo. ? Se utilizan para probar el software y en el proceso de asegurar la calidad (Quality Assurance) del mismo. Las pruebas se realizan para validar la implementación correcta y completa de los casos de uso.

? Potencialmente puede ser el punto inicial para las ayudas en línea y el manual de usuario.

17


Caso de Uso

Casos de Uso.

Realizar Pedido

Actor ?Son entidades externas (personas o sistemas externos) que interaccionan con el sistema para conseguir una meta. ?Representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con éstos. ?Pueden definirse categorías de actores Cliente comercial


Casos de Uso.

Cliente


Actor ? Es frecuente que los actores coincidan con áreas de la empresa (vendedor, gestor de almacén, etc.) o distinto nivel en la jerarquía (empleado, supervisor, etc.) ?Se conectan a los casos de uso a través de asociaciones. Una asociación indica que el actor y el caso de uso se comunican entre sí y cada uno puede enviar o recibir mensajes

18


Casos de Uso.


Flujo de eventos El comportamiento de un caso de uso puede especificarse describiendo un flujo de eventos mediante texto. ? La especificación de un flujo de eventos debe incluir: ?Cómo y cuándo empieza y acaba. ?Cuándo interactúa con los actores. ?Qué objetos se intercambian. ?El flujo básico y los flujos alternativos.


Casos de Uso.


Escenarios Representa una instancia de un caso de uso y, por tanto, es una secuencia específica de acciones que ilustra un posible comportamiento dentro de un caso de uso. ? Escenario Básico.- se corresponde con la funcionalidad básica ? Escenarios Secundarios.- se corresponden con funcionalidades alternativas y tratamiento de casos de error. No tienen sentido fuera del contexto del caso de uso donde ocurren. Para su descripción se pueden utilizar texto, pseudocódigo o incluso diagramas de interacción.

19


Caso de Uso

Casos de Uso.

Realizar Pedido

Colaboraciones Es una sociedad de elementos (tanto estáticos como dinámicos) que colaboran para llevar a cabo el comportamiento de un caso de uso. Especifican la realización de un caso de uso, es decir describen cómo se implementa. Caso de uso Colaboración

Hacer pedido Gestión de pedidos Realización


Casos de Uso.


Relaciones entre casos de uso Podemos encontrar diferentes relaciones entre casos de uso: ?Inclusión o Uso.- Se utiliza para evitar describir el mismo flujo de eventos, poniendo el comportamiento común a varios casos en uno dado. ?Extensión.- Se utiliza cuando existe una secuencia opcional de eventos que se desea incluir en el caso de uso. ? Generalización.- Permite heredar el comportamiento y la semántica desde el caso de uso más general.

20


Caso de Uso

Casos de Uso.

Realizar Pedido

Relaciones entre casos de uso ?Inclusión o Uso.-

<>

Hacer pedido

Validar Usuario

?Extensión.? Obtenga primero el caso de uso normal. ? Pregúntate: ¿qué puede fallar?¿cómo podría funcionar esto de modo diferente? ?Dibuje las variaciones que encuentre como extensiones.

? Generalización

Hacer pedido <> Hacer pedido urgente

Comprobar clave Generalización Comprobar retina


Casos de Uso.

Validar Usuario


Descripción de un caso de uso ? Nombre: El nombre del caso de uso (verbo o frase verbal corta y significativa) . ? Meta: Resultado de valor que se pretende conseguir con su ejecución. ? Actores: actores que participan. ? Disparador : Evento o eventos externos que activan su comienzo. ? Precondición: cualquier condición previa necesaria antes de que comience el caso de uso. ? Condición de éxito: qué se considera un final con éxito (poscondición). ? Condición de fallo: qué se considera un final con fracaso (poscondición). ? Escenarios.- Descripción del escenario básico y de los escenarios secundarios relevantes. ? Notas: Otra información relevante: rendimiento, frecuencia de uso...

21


Casos de Uso.


Tipos de casos de uso En función del nivel de detalle de la descripción: ?Alto nivel.- Descripción muy breve que permita comprender la complejidad y la funcionalidad básica ?Expandido.- Describe el proceso más a fondo incluyendo la descripción del flujo de eventos y escenarios. Alto nivel (poco detalle)

Expandido (mayor detalle)

En función del nivel de abstracción: ? Esencial.- Permiten captar la esencia del proceso y sus procesos fundamentales sin incluir detalles de diseño. ? Real.- Describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías actuales. Esencial (muy abstracto)


Casos de Uso.

Real (muy concreto)


Tipos de casos de uso ?Alto nivel - Esencial.? Nombre: Comprar productos. ? Meta: Refleja el proceso de adquisición de productos por parte de los clientes en un supermercado. ? Actores: Cajero, cliente. ? Disparador : El cliente presenta un conjunto de productos al cajero.

22


Caso de Uso

Casos de Uso.

Realizar Pedido

Tipos de casos de uso ?Expandido- Real.? Nombre: Comprar productos. ? Meta: Refleja el proceso de adquisición de productos por parte de los clientes en un supermercado. ? Actores: Cajero, cliente. ? Disparador : El cliente presenta en la caja con un conjunto de productos. ? Precondición: La caja está abierta ? Condición de éxito: El cliente se lleva los productos adquiridos. ? Condición de fallo: El cliente no tiene dinero para pagar los productos.


Caso de Uso

Casos de Uso.

Realizar Pedido

Tipos de casos de uso (Expandido...) ? Escenario básico: (pago en efectivo) Curso normal 1.- El cliente llega a la caja con los productos que desea adquirir. 2.- El cajero registra el identificador de cada producto. Si hay varios productos de un mismo tipo el cajero también puede introducir la cantidad. 3.-Al terminar de introducir los producto el cajero indica su finalización al terminal de venta. 4.- El cajero indica al cliente la cantidad a pagar. 5.- El cliente paga los productos. 6.- El cajero le devuelve el cambio.

Curso alternativo

5.1.- el cliente no tiene dinero y no se lleva los productos

23


Caso de Uso

Casos de Uso.

Realizar Pedido

Tipos de casos de uso (Expandido...) ? Escenario secundario: (pago con tarjeta) Curso normal 1.- El cliente llega a la caja con los productos que desea adquirir. 2.- ... 3.- ... 4.- El cajero indica al cliente la cantidad a pagar. 5.- El cliente entrega la tarjeta. 6.- El cajero introduce la tarjeta para realizar el cobro 7.- El cliente firma el pago

Curso alternativo

5.1.- La tarjeta no es válida en ese establecimiento 6.1.-No existe comunicación con la central de tarjetas.


Casos de Uso.


Tipos de casos de uso (Expandido...) ? Notas: ? El tiempo de respuesta es básico, ya que es habitual que haya varios clientes esperando. ? Los productos deben ser fácilmente identificables por el sistema. ? Se debe ayudar al cajero en la devolución del cambio.

24


Casos de Uso.


Descripción de un caso de uso Use Case: 5 Buy Goods -------------------------------------------------CHARACTERISTIC INFORMATION Goal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed. Preconditions: We know Buyer, their address, etc. Success End Condition: Buyer has goods, we have money for the goods. Failed End Condition: We have not sent the goods, Buyer has not spent the money. Primary Actor: Buyer, any agent (or computer) acting for the customer Trigger: purchase request comes in. ---------------------------------------MAIN SUCCESS SCENARIO 1. Buyer calls in with a purchase request . 2. Company captures buyer’s name, address, requested goods, etc. 3. Company gives buyer information on goods, prices, delivery dates, etc. 4. Buyer signs for order. 5. Company creates order, ships order to buyer. 6. Company ships invoice to buyer. 7. Buyers pays invoice.


Casos de Uso.


Descripción de un caso de uso ---------------------EXTENSIONS 3a. Company is out of one of the ordered items : 3a1. Renegotiate order. 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods : 7a. Handle returned goods (use case 105) -------------------SUB-VARIATIONS 1. Buyer may use phone in, fax in, use web order form, electronic interchange 7. Buyer may pay by cash or money order check credit card

25


Casos de Uso.


Descripción de un caso de uso ---------------------RELATED INFORMATION Priority : top Performance Target: 5 minutes for order, 45 days until paid Frequency: 200/ day Superordinate Use Case: Manage customer relationship (use case 2) Subordinate Use Cases: Create order (use case 15) Take payment by credit card (use case 44) Handle returned goods (use case 105) Channel to primary actor: may be phone, file or interactice Secondary Actors: credit card company, bank, shipping service Channels to Secondary Actors : ---------------------------OPEN ISSUES What happens if we have part of the order? What happens if credit card is stolen? --------------------------SCHEDULE Due Date: release 1.0


Casos de Uso.


Casos de uso y proceso incremental ?Identificar todos los casos de uso solo a nivel de nombre. ?Expresarlos a alto nivel y de manera esencial ? Ignorar detalles sobre la forma de la interacción entre el actor y el sistema ? Incluir en la descripción sólo las alternativas relevantes, ignorando tratamientos de error y excepción. ? No entrar en los detalles sobre las acciones que realiza el usuario cuando interactúa con el sistema

?Establecer la planificación de la implementación de los diferentes casos de uso ?Expresar los casos de uso a nivel expandido ? Incluir una descripción del interfaz con el usuario. ? Incluir otras alternativas (errores y excepciones). ? Especificar con mas detalle el comportamiento interno del sistema.

26


Casos de Uso.


Casos de Uso & Procesos del Negocio Un proceso de negocio describe una actividad básica del negocio incluyendo actividades que no son soportadas por el software . Un caso de uso generalmente se asocia a aquellas actividades de un proceso del negocio que van a ser soportadas con un desarrollo software .


Casos de Uso.


Identificación de casos de uso Basados en la identificación de los actores: ?Identificar actores participantes en el sistema. ?Identificar para cada actor los procesos que inicia o en los que participa. Basados en la identificación de los eventos: ?Identificar los eventos externos a los que el sistema debe responder. ?Relacionar eventos con actores y casos de uso.

27


Caso de Uso

Casos de Uso.

Realizar Pedido

Identificación de casos de uso Cuestiones útiles para encontrar casos de uso. ? ¿Qué tareas o funciones principales realiza cada actor? ?¿Qué información del sistema debe adquirir, producir o cambiar el actor? ?¿Tendrá que informar el actor al sistema sobre cambios en el entorno externo? ?¿Qué información desea obtener el actor del sistema? ?¿Desea el actor ser informado acerca de cambios inesperados en el sistema?


Caso de Uso

Casos de Uso.

Realizar Pedido

Es muy importante que los casos de uso sean validados. Para ello se pueden realizar las siguientes preguntas: ? ¿Es completo el caso de uso? ¿Han sido recogidos los detalles necesarios? ? ¿Estas seguro que el resultado de valor (meta) para el actor se puede conseguir de manera correcta? ? ¿Hay nuevas metas de actores que deben tenerse en cuenta? ? ¿Hay nuevos actores que no se han representado (directa o indirectamente)? ? ¿ Hay cambios en los procesos o requisitos que puedan simplificar el caso de uso? ? ...

28


Caso de Uso

Casos de Uso.

Realizar Pedido

Caso de uso bien estructurado ? ¿Nombra un comportamiento simple, identificable y razonablemente atómico. ? Factoriza el comportamiento común, incorporando ese comportamiento desde otros casos de uso que incluye ? Factoriza variante, colocando ese comportamiento en otros casos de uso que lo extienden ? Describe el flujo de eventos de forma clara para que alguien externo al sistema lo entienda. ? Se describe por un conjunto mínimo de escenarios que especifican la semántica normal y de las variantes.


Diagrama de Casos de Uso

Diagramas de Casos de Uso.

Venta Normal

Cliente

VentaenRebajas Vendedor

Venta en Oferta

Se utiliza para modelar la vista estática de los casos de uso. Puede utilizarse para: ? Describir el contexto de un sistema. Implica dibujar una línea alrededor de todo el sistema y asegurar qué actores quedan fuera de los límites del sistema.

? Describir sus requisitos funcionales. Implica especificar qué debería hacer el sistema.

29




Cliente


Venta en Oferta

Describir el contexto de un sistema ? Identificar actores entorno al sistema, considerando grupos que: ? Requieren ayuda del sistema para llevar a cabo sus tareas. ? Son necesarios para ejecutar las funciones del sistema. ? Interactúan con el hardware externo o con otros sistemas.

? Organizar actores similares en jerarquías. ? Proporcionar un estereotipo para cada uno de esos actores. ? Introducir los actores en el diagrama y especificar las vías de comunicación de cada actor con los casos de uso.




Venta Normal

Cliente


Venta en Oferta

Describir los requisitos de un sistema ? Establecer el contexto del sistema, identificando los actores a su alrededor. ? Considerar el comportamiento que cada actor espera o requiere que el sistema proporcione. ? Nombrar esos comportamientos como casos de uso. ? Factorizar el comportamiento común (include) y las variantes (extend). ? Modelar los casos de uso, actores y relaciones en diagramas de casos de uso. ? Adornar los casos de uso con notas que enuncien los requisitos no funcionales.

30




Venta Normal

Cliente


Venta en Oferta

Ejemplo

Comprar productos efectivo Cajero

Cliente << extiende>> Comprar tarjeta




Cliente


Venta en Oferta

Ejemplo Se desea desarrollar un sistema para una empresa dedicada al transporte de pasajeros por avión. El sistema debe planificar los vuelos para el transporte de pasajeros. El sistema se encarga de transportan tanto pasajeros (nombre, origen, destino, tipo de asiento, etc), como carga (peso, tamaño, origen, destino, etc.), considerando a cada uno como elemento de embarque. Los clientes (tanto empresas como particulares) realizan sus reservas de embarque para el vuelo que desean al sistema, el cual debe responder con la confirmación de las mismas. Cada vuelo completo (misión) consta de un conjunto de saltos (segmentos de vuelo) que relacionan un aeropuerto de origen y otro de destino. El personal de control de tráfico debe realizar la asignación de un avión (número, estado, modelo, capacidad, situación, etc) a cada salto. Junto a ello se encargan de controlar y resolver las incidencias o fallos producidos en el transporte (fecha incidente, descripción, acción correctora, etc.) Para realizar la asignación de un avión el personal de control de tráfico necesita localizar al avión. Para ello necesita obtener información de un radar que envía posiciones en el espacio aéreo de un avión. Con dichas posiciones se genera una t rayectoria que permite predecir la nueva posición del avión en un instante posterior.

31




Venta Normal

Cliente


Venta en Oferta

Ejemplo Solicitar elemento de embarque

Cliente

Persona

Asignar avión a salto

Empresa

Control de tráfico

<< include>> Localizar avión Radar

Controlar y resolver incidencias


Clase

Clases. ¿Qué es una clase? Es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Nombre Atributos Operaciones

? Son una abstracción de las cosas que forman parte del vocabulario del dominio. ? Implementa una o más interfaces.

32


Clase

Clases. Nombre ? Es una cadena de texto que denomina y describe el concepto asociado a una clase. ? Es interesante que se asocie a un nombre genérico. ? Por ejemplo, en vez de Terminal de Registro de Ventana (TRV) es mejor poner registro, pues no se asocia con un dispositivo físico concreto como en el caso de TRV.

? Generalmente se utilizan nombre simples o expresiones nominales extraídos del dominio. ? Por lo general se suele poner la primera letra de cada palabra en mayúsculas (Cliente; SensorTemperatura)


Clase

Clases. Atributo ? Es una propiedad, cualidad o característica asociada a una clase, identificada por un nombre que describe un rango de valores que puede tomar la propiedad. ? Para identificarlos, cada clase debe preguntarse: ¿Qué conozca de mi? ? El nombre de un atributo es un nombre corto o expresión nominal extraída del dominio. ? Por lo general se suele poner la primera letra de cada palabra en mayúsculas, excepto de la primera (precio; tipoProducto)

? Junto al nombre se pueden incluir otras características (tipo, valor por defecto, etc.) que se verán en características avanzadas.

33


Clase

Clases. Operación ? Es una implementación de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento. ? Generalmente la invocación de una operación sobre un objeto produce un cambio en los datos o el estado de éste. ? El nombre de una operación es un verbo o expresión verbal extraído del dominio. ? Por lo general se suele poner la primera letra de cada palabra en mayúsculas, excepto de la primera (comprar; calcularImporte)


Clase

Clases. Operación ? Junto al nombre se puede especificar su signatura. ? Nombre, tipo y valores por defecto de los parámetros y en ciertos casos necesarios tipo de retorno.

SensorTemperatura reiniciar() ponerAlarma(t: Temperatura) valor() : Temperatura

34


Clase

Clases. Responsabilidad ? Es un contrato o una obligación de una clase. ? Las responsabilidades se llevan a cabo mediante los atributos y operaciones. ? Un buen comienzo en el modelado de las clases es especificar las responsabilidades de los conceptos manejados en el dominio del problema. ? Técnicas para definir responsabilidades: ? Tarjetas CRC (Clase-Responsabilidad-Colaborador). ? Análisis basado en casos de uso.

? Se especifican mediante texto libre utilizando una frase o un párrafo corto.


Clase

Clases. Especificación de una clase ? Para facilitar la comprensión no se suelen mostrar todos los atributos y operaciones de la clase, o incluso a veces sólo se muestra el nombre de la clase. ? Se puede indicar explícitamente que hay más atributos o propiedades mediante: ... ? Para organizar mejor las listas de atributos y operaciones es interesante utilizar estereotipos para anteponer a cada grupo una categoría descriptiva.

35


Clase

Clases. Identificación de clases El objetivo es identificar los conceptos significativos del dominio. Dos posibles estrategias: ?A partir de una lista de categorías. ?A partir de identificación de frases nominales.


Clase

Clases. Lista de categorías conceptos Categoría del concepto

Ejemplo

Objetos físicos tangibles

Camión

Especificaciones o descripciones de cosas Lugares

Descripción del producto

Transacciones

Venta, Pago, Reserva

Línea o elemento de una transacción

Línea de una Venta

Papeles de las personas

Vendedor, Camionero

Tienda, Almacén, Delegación

36


Clase


Ejemplo

Contenedores de cosas

Tienda, Almacén

Cosas dentro del contenedor

Producto

Otros sistemas software externos

Sistema de autorización de tarjeta de crédito

Conceptos abstractos

Hambre

Organizaciones

Depto de Ventas

Eventos

Pago, Anulación


Clase


Ejemplo

Procesos

Venta de un producto

Reglas y políticas

Política de reembolso por anulación

Catálogos

Catálogo de productos

Documentos, libros

Manual de Personal, Ticket de compra Existencias, Línea de crédito

Instrumentos y servicios financieros

37


Clase

Clases. Identificación de frases nominales Este método consiste en identificar en las descripciones textuales del dominio nombre o frases nominales y considerarlas como conceptos. En esta estructura los verbos representan asociaciones entre conceptos. Ejemplo.El cliente realiza los pedidos Cliente

Realiza

Pedido


Clase

Clases. Errores y problemas en la identificación de clases ?Incorporación de documentos como clases. ? Incorporarlos sólo si cumplen un papel especial respecto a las reglas del negocio (ejemplo.- un recibo de compra puede ser necesario para realizar una devolución).

?Distinción entre atributo y clase. ? Si el concepto identificado no se describe mediante un simple número o texto descriptivo, posiblemente sea una clase.

38


Clase

Clases. Errores y problemas en la identificación de clases ?Diferenciación entre elementos físicos y descripción de elementos. ? Incorpore una clase que hace referencia a una descripción de elementos si: ? La eliminación de las instancias de los elementos físicos da como resultado la pérdida de información. ? Reduce información redundante o duplicada. Producto identificación descripción precio númeroSerie

Desc. Producto identificación descripción precio

Producto físico númeroSerie


Clase

Clases. Tarjetas CRC ? Son tarjetas donde se describen las clases sus responsabilidades y otros colaboradores. ? Un colaborador son aquellas otras clases que deben existir para permitir que la clase original pueda asumir una responsabilidad. ? Es una herramienta particularmente útil en el análisis. ? Ayudan a obtener una visión más completa y compresible de los conceptos del dominio del problema. ? Su principal aplicación es estructurar y describir de manera detallada aunque abstracta los conceptos del dominio del problema.

39


Clase

Clases. Tarjetas CRC ? Se suele crear una CRC para cada concepto que aparece en un caso de uso. Dicho concepto se asocia con una clase. ? Mientras los casos de uso se encargan de definir el comportamiento, las CRC ayudan a clarificar su estructura. Responsabilidad

Pedido

Colaborador

Revisa si hay elementos en stock

LíneaPedido,Artículo

Determina el precio

LíneaPedido,Artículo

Revisa si el descuento es correcto

Cliente


Clase

Clases. Tarjetas CRC ? Las tarjetas CRC son una técnica muy válida para ser utilizada en sesiones en grupo. ? Son utilizadas con dos propósitos básicos: ? Es una técnica colectiva que permite definir los conceptos del dominio. ? Las discusiones de las diferentes perspectivas permite que las ideas aportadas por los diferentes participantes puedan ser comprobadas en cuanto a su validez.

? Tener en cuenta las siguientes características: ? Evitar tarjetas demasiado orientadas a los datos. ? Especificar el rol con que una clase participa en la colaboración. Evitar crear varias tarjetas para los diferentes roles de una clase.

40


Clase

Clases. Clase bien estructurada ?Proporciona una abstracción precisa de algo extraído del dominio del problema. ?Contiene un conjunto pequeño de responsabilidades. ?Proporciona una clara diferenciación entre la especificación y su implementación.

Especificación de una clase en Diagrama de Clases ?Mostrar sólo las clases relacionadas. ?Mostrar sólo aquellas propiedades de la clase que sean importantes para comprender la abstracción. ?Organizar las listas largas de atributos y operaciones agrupándolas según su categoría.


Clase

Clases. Clase de análisis ? Se centra en los requisitos funcionales ? Debe describir un concepto más conceptual. ? Raramente define u ofrece un interfaz en términos de operaciones con su signatura. ? Su comportamiento se define mediante responsabilidades a un alto nivel de descripción. ?Responsabilidad es una descripción textual de un conjunto cohesivo del comportamiento de una clase.

41


Clase

Clases. Clase de análisis ? Puede incluir atributos pero a alto nivel de abstracción y deben ser claramente reconocibles en el dominio del problema. ? Además los atributos identificados durante el análisis puede convertirse en clases durante le diseño.

? Participa en relaciones aunque dichas relaciones son conceptuales, despreciándose características como navegabilidad o estructuras de generalización especialización que permitan optimizar el software o mejorar la reutilización. ? Se pueden hacer corresponder con uno de los tres estereotipos básicos: interfaz, entidad o control .


Clase

Clases. Clase de interfaz ? Se utilizan para modelar la interacción entre el sistema y sus actores ? Modelan las partes del sistema que dependen de los actores y, por tanto, reúnen los requisitos en los límites del sistema. ? Por tanto, las interfaces de usuario y las interfaces de comunicación quedan aisladas en este tipo de clases. ? Cada clase interfaz debería estar asociada al menos a un actor.

42


Clase

Clases. Clase de interfaz ? Representan abstracciones de los elementos de la interfaz, pero deben mantenerse a un nivel de abstracción elevado. ?Pueden representar abstracciones de ventanas, formularios, interfaces de comunicación, sensores , etc., pero no deben detallarse en exceso. Por tanto, no se está pidiendo un prototipo final de la interfaz.


Clase

Clases. Clase de entidad ? Se utilizan para modelar la información que posee una vida más larga y que a menudo es persistente. ? Se corresponden con conceptos del dominio del problema. ? Se pueden derivar directamente de una clase de entidad del negocio, aunque pueden corresponder a un subconjunto de ellas. ? Puede tener un comportamiento relativo a la información que representa.

43


Clase

Clases. Clase de control ? Representa la coordinación, secuencia, transacciones y control de la lógica del negocio compleja que implica a varios objetos. ? Se utilizan para encapsular el control de un caso de uso concreto. ? Se pueden utilizar también para representar derivaciones o cálculos complejos que no pueden asociarse a ninguna información (clase entidad) concreta.


Clase

Clases. Diagrama de clases asociado a la realización de un caso de uso ? Una clase de análisis y sus objetos participan en varias realizaciones de casos de uso. ? Algunas responsabilidades, atributos y asociaciones suelen ser sólo relevantes para una única realización de caso de uso. ? Es importante, por tanto, durante el análisis coordinar todos los requisitos sobre una clase y sus objetos que puede estar asociados a diferentes casos de uso.

44


Clase

Clases. Ejemplo PedidosConfirmados GestorPedidos Factura

Pagos Comprador

IU SolicitudPago GestorPagos


Clase

Atributos. ¿Qué es un atributo? ? Es una propiedad, cualidad o característica asociada a una clase, identificada por un nombre que describe un rango de valores que puede tomar la propiedad. ? Para identificarlos, cada clase debe preguntarse: ¿Qué conozca de mi? ? Un atributo no debería ser un concepto complejo del dominio. ? Para establecer relaciones entre conceptos se deben utilizar relaciones, no atributos.

45


Clase

Atributos. ?Los atributos tienen un tipo que no tiene que corresponder obligatoriamente con un tipo primitivo (número, carácter, etc.) ?Represente como tipos no primitivos aquellos que pueden considerarse primitivos si: ? Se compone de secciones independientes (nº teléfono, nombre de una persona). ? Normalmente se le asocian operaciones de análisis o validación (DNI,ranking o importancia de un cliente, etc). ? Posee otros atributos asociados (el precio de rebajas está asociado a una fecha de inicio y otra de final). ? Es una cantidad con una unidad asociada (el importe del pago puede tener asociada una unidad monetaria).


Relaciones.

0..1 patrón

* empleado

¿Qué es una relación? Expresa una conexión entre las clases del dominio. Podemos encontrar tres tipos básicos de relaciones: ? Dependencias.- Representan relaciones de uso entre clases. ? Generalizaciones.- Conectan clases generales con sus especializaciones. ?Asociaciones.- Representan relaciones estructurales entre objetos.

46


Relaciones.

0..1 patrón

* empleado

Dependencia ? Declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza, pero no necesariamente a la inversa. ? Se representa mediante una flecha con trazo discontinuo que va dirigida hacia el elemento del cual se depende. ? La mayoría de las veces se utiliza para indicar que una clase utiliza otra como argumento en la signatura de una operación. PelículaVideo Canal reproducirEn (c:Canal)


Relaciones.

0..1 patrón

* empleado

Generalización ? Indica una relación entre un elemento más general (supertipo) y un caso más específico (subtipo) de ese elemento. ? A veces se le denomina relación “es-un-tipo-de”. ? Los objetos hijos se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la inversa. ? Las clases hijas heredan las características (atributos, operaciones y relaciones) de sus clases padres.

47


Relaciones.

0..1 patrón

* empleado

Generalización ? La generalización produce una estructura jerárquica en la que existen clases sin padres (clase base) y clases sin hijos (clases especializadas u hojas). Figura posición: Punto mover() dibujar()

Rectángulo esquina: Punto dibujar()

Polígono Círculo radio:Float

puntos: Lista dibujar()

dibujar() Cuadrado


Relaciones.

0..1 patrón

* empleado

Generalización ¿Cuando deberíamos definir un subtipo?. ? Debemos asegurarnos que esta partición es útil en el dominio del problema. ? Motivos para realizar la partición: ?El subtipo tiene otros atributos. ?El subtipo tiene otras asociaciones. ?Se pude especificar un comportamiento específico para el subtipo o se reacciona ante él de manera diferente a como se haría ante el supertipo.

48


Relaciones.

0..1 patrón

* empleado

Generalización ¿Cuando deberíamos definir un supertipo?. ? Motivos para realizar la generalización: ?Los conceptos asociados a subtipos potenciales representan variaciones de un concepto semejante. ?Los conceptos comparten entre si varios atributos o comportamientos semejantes. ?Existen relaciones compartidas por los conceptos candidatos a subtipos que pueden generalizarse y asociarse al supertipo.


Relaciones.

0..1 patrón

* empleado

Generalización Clases abstractas ? Representan clases que no contienen objetos.Sólo pueden aparecer dentro de jerarquías de generalización. ? Se pueden asociar a clases de una jerarquía en la que los objetos siempre deben pertenecer a uno de los subtipo definidos. Figuras

Rectángulos

Círculos

Polígonos

49


Relaciones.

0..1

*

patrón

empleado

Generalización Clases abstractas ? Se representan poniendo el nombre de la clase en cursiva o mediante el valor etiquetado {abstract} debajo del nombre de la clase. Figura {abstract}

Figura posición: Punto mover() dibujar()

Rectángulo

posición: Punto mover() dibujar()

Polígono

esquina: Punto

Círculo

dibujar()

radio:Float

puntos: Lista dibujar()

dibujar()


Relaciones.

0..1

*

patrón

empleado

Generalización Estructuras múltiples: ? La generalización puede ser: ? simple.- un subtipo solo tiene un supertipo (padre). ? múltiple.- un subtipo puede tener varios supertipos (padres). Persona Persona nombre dirección

Empleado fechaNacimiento identificacionUsuario password

Accionista númeroAcciones

nombre dirección

EmpleadoAccionista fechaNacimiento identificacionUsuario password númeroAcciones

Empleado fechaNacimiento identificacionUsuario password

Accionista númeroAcciones

EmpleadoAccionista

50


Relaciones. 0..1

Asociación

patrón

0..1 patrón

* empleado

* empleado

? Especifica que los objetos de una clase están conectados con objetos de otra clase. ? Puede verse como: ?“unión o conexión de ideas” ?“establece las relaciones entre los objetos necesarios para llevar a cabo un conjunto de requerimientos”

? Pueden incluirse cuatro adornos a la asociación. ?Nombre.- Se utiliza para describir la naturaleza de la asociación. ?Rol.- Es el papel específico que juega una clase en dicha relación. ?Multiplicidad.-Indica cuántos objetos pueden conectarse a través de una instancia de la asociación. ?Agregación.-Permite modelar relaciones especiales de tipo “todo/parte”.


Relaciones. Asociación

0..1 patrón

0..1 patrón

* empleado

* empleado

Nombre .- describe la relación existente entre las clases . Para aclarar su significado suele ser interesante indicar la dirección de lectura. Trabaja en Empresa

Persona

Puede no ser necesario su inclusión si se indican los nombre de los roles.

51


Relaciones. 0..1

Asociación

patrón

0..1 patrón

* empleado

* empleado

Rol.- es la cara que la clase de un extremo de la relación presenta a la clase del otro extremo. Una clase puede jugar el mismo o diferentes roles en otras asociaciones.

Empresa

Persona Patrón

Empleado



0..1 patrón

0..1 patrón

* empleado

* empleado

Multiplicidad.- indica el número de objetos que puede participar en una instancia de la relación. En una relación se indican tantas multiplicidades como clases participen en la asociación. En la multiplicidad se indican los límites inferior y superior de los objetos participantes. ? ? ? ? ? ? ?

1 -> exactamente 1 0,1 -> cero o uno 0..4 -> entre cero y cuatro 3,7 -> tres o siete 0..* -> mayor o igual de cero (por defecto) 1..* -> mayor o igual a uno 0..3, 7, 9..* -> cualquier número menos 4, 5, 6 y 8

52


Relaciones. 0..1

Asociación

patrón

0..1 patrón

* empleado

* empleado

Multiplicidad.Cuando se indica una multiplicidad en un extremo de la asociación, se está especificando que, para cada objeto de la clase en el extremo opuesto, debe haber tantos objetos en este extremo 1

1..*

Empresa

Persona

Persona 1

Empresa 1

Persona 2

Empresa 2

Persona 3



0..1 patrón

0..1 patrón

* empleado

* empleado

Agregación.- describe asociaciones en las que existe una jerarquía de composición en la que una clase representa el todo y otras las partes que lo constituyen. Empresa

Todo

1 * Departamento

Parte

La existencia de una agregación no liga la existencia del todo y sus partes.

53



0..1 patrón

0..1

*

patrón

empleado

* empleado

Avión

Agregaciones típicas.-

0,1

? Partes que componen un objeto de nivel superior

0..4

Motor Avión 0,1

? Elementos contenidos en otro nivel superior

0..n

Pasajeros

Vuelo

? Miembros de una colección o conjunto.

1..n 1..n

SegmentoVuelo



0..1 patrón

0..1 patrón

* empleado

* empleado

Composición.- es un tipo especial de agregación en la que la existencia de las partes está ligada a la del todo. El objeto parte puede pertenecer a un todo único, es más se espera que las parte vivan y mueran con el todo. Cliente

Todo

0..* CuentaBancaria

Parte

54


Relaciones.

0..1 patrón

* empleado

Otras características Las relaciones pueden tener asociados atributos.

Empresa 1..*

Empleo desde hasta

* Empleado


Clase

Relaciones. Lista de categorías asociaciones Categoría de asociación

Ejemplo

A es una parte física de B

Ala-Avión;

A es una parte lógica de B

TramoVuelo-RutaVuelo

A está físicamente contenido en B A está contenido lógicamente en B

Producto-Estante; Pasajero-Avión Producto-Catálogo

A es una descripción de B

DescripciónProducto-Producto

A es un elemento de una línea LíneaPedido-Pedido en una transacción B

55


Clase

Relaciones. Lista de categorías asociaciones Categoría de asociación A se conoce/introduce/ registra/presenta/captura en B A es miembro de B A es una subunidad organizacional de B

Ejemplo Reserva-ListaPasajeros; Venta-Caja Piloto-Avión; Vendedor-Tienda Departamento-Tienda; Mantenimiento-LíneaAérea

A usa o dirige a B

Piloto-Avión

A se comunica con B

Cliente-Vendedor; AgenteReserva-Pasajero Pago-Pedido; Pasajero-Billete

A se relaciona con una transacción B


Clase

Relaciones. Lista de categorías asociaciones

A es una transacción relacionada con otra transacción B

Categoría de asociación

Ejemplo Pago-Venta; Reserva-Cancelación

A está contiguo a B

Ciudad-Ciudad

A es propiedad de B

Avión-LineaAérea;

56



Piloto

1..4

Diagramas de Clases.

Vendedordebilletes 1

1..2

1

*

Avión 1

*

Vuelo 1

* *

Reserva

*


1 Avióncomercial

Avión militar

Líneaaérea


Avión de carga

Avión de pasajeros

Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. ? Colaboración.- Sociedad de roles (clases) y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos (especificación de cómo se realiza un elementos, tal como un caso de uso o una operación, por un conjunto de clasificadores y asociaciones). ?Interfaz.- Colección de operaciones que se utilizan para especificar un servicio de una clase o componente.



Piloto

1..4


1

* *

Vuelo 1

* *

Reserva

*


1 Avión militar

Avióncomercial

Líneaaérea


Avión de carga

Ejemplo

Vendedordebilletes

1..2

1 Avión 1

Avión de pasajeros

Empresa 1 1..*

*

1..*

Departamento nombre

Se ubica

0,1

*

Persona nombre dirección

*

Oficina dirección teléfono

{subconjunto}

miembro

director 1..*

1

Accionista

Empleado

númeroAcciones

fechaNacimiento identificacionUsuario password

RegistroPersonal historialEmpleos salario IinformaciónSegura

obtenerResgistrosPersonales

57



Piloto

1..4



1..2

1

*

Avión 1

*

*

Vuelo 1

*

Reserva

*


1 Avióncomercial

Avión militar

Líneaaérea


Avión de carga

Avión de pasajeros

Se utiliza para: ? Modelar el vocabulario de un sistema. ? Tomar decisiones sobre qué abstracciones son parte del sistema y cuáles caen fuera de sus límites. Se utilizan para especificar abstracciones y sus responsabilidades.

? Modelar colaboraciones simples. ? Prestar atención a la visualización especificación, construcción y documentación de la forma en que los conceptos abstractos del dominio colaboran entre sí.

? Modelar un esquema lógico de base de datos. ? Los diagramas de UML son un superconjunto de los diagramas Entidad-Relación.



Piloto

1..4



1..2

1

*

Avión 1

*

Vuelo 1

* *

Reserva

*


1 Avión militar

Avióncomercial

Líneaaérea


Avión de carga

Avión de pasajeros

Modelar colaboraciones simples ?Cada diagrama debe centrarse en una colaboración. ?Para modelar una colaboración: ? Identificar los mecanismos a modelar. Un mecanismo representa una función o comportamiento de la parte del sistema que se está modelando que resulta de la interacción de una sociedad de clases, interfaces y otros elementos. ?Para cada mecanismo identificar las clases, interfaces y otras colaboraciones que participan en esta colaboración, así como sus relaciones. ? Usar escenarios para recorrer la interacción entre los elementos. ? Completar la descripción de los elementos. Para las clases hay que comenzar con un reparto de responsabilidades. Después hay que convertir dichas responsabilidades en atributos y operaciones.

58



Piloto

1..4



1..2

1

*

Avión 1

*

*

Vuelo 1

*

Reserva

*


1 Avióncomercial

Avión militar

Líneaaérea


Avión de carga

Avión de pasajeros

Modelar un esquema lógico de base de datos ?Los modelos de clases no sólo permiten describir los datos sino el comportamiento. ? En una base de datos estas operaciones generalmente se convierten en disparadores o procedimientos almacenados.

?Para modelar un esquema: ?Identificar aquellas clases cuyo estado debe perdurar en el tiempo. ? Crear un diagrama. Las clases pueden completar su descripción con valores etiquetados que describan información de las base de datos. ? Especificar los atributos , las relaciones y las cardinalidades. ? Considerar el comportamiento de las clases, expandiendo las operaciones de acceso a la base de datos, o aquellas que permiten asegurar la integridad. En general las reglas del negocio deben modelarse en una capa por encima de las clases persistentes.



Piloto

1..4

Diagramas de Clases. destino

Avióncomercial

0..n

0..n

origen

ElementoEmbarque número situaciónActual

0..n

0,1

Avión número estado modelo capacidad

1

Cliente

Empresa razonSocial

Particular

1

Trayectoria fecha

tiene 1

0,1 1

2..n

adquiere 0..n

Avión de pasajeros

0..n

se asigna

1

destino

Líneaaérea

0..n

Aeropuerto nombre ciudad

Reserva

FallosAvión fecha hora descripción

SegmentoVuelo número descripción

destino origen

*

*


1..n

origen

*

Vuelo 1

1 Avión militar

1..n

Misión número descripción horario

1

* *


Avión de carga

Ejemplo

Vendedordebilletes

1..2

1 Avión 1

Persona nombreApellidos

Carga

Pasajeros

PuntoEspacioAéreo fecha hora posición

peso tamaño descripción

asiento

59

Ingeniería del Software I (4º I.I) Diagrama de Actividad

Diagramas de Actividades. ¿Qué es un diagrama de actividades? Es fundamentalmente un diagrama de flujo que muestra el flujo de control entre actividades. ?Un diagrama de interacción muestra objetos que se pasan mensajes, un diagrama de actividades muestra las operaciones que se pasan entre los objetos.

Actividad es un estado con una acción interna y uno o más transiciones de salida que automáticamente preceden a la terminación de la acción interna. ?Las actividades producen una acción, que está compuesta de computaciones atómicas ejecutables que producen un cambio en el estado del sistema o la devolución de un valor


Diagramas de Actividades. Ejemplo

Disponer de solar

Estado inicial

Contratar arquitecto

Estado acción

Obtener plano y presupuesto obra

Bifurcación

[no aceptado]

Guarda

[en otro caso]

División Construir casa ( )

Estado de actividad con submáquina

Vender casa

Flujo de objeto

:CertificadoVivienda Terminar promoción vivienda

[terminado]

Unión Estado final

60


Diagramas de Actividades. Normalmente los diagramas de actividades contienen: ?Estados de actividad y estados de acción. ?Estado de actividad.-Elemento compuesto cuyo flujo de control se compone de otros estados de actividad y de acción. ?Estado de acción.- Estado que representa la ejecución de una acción atómica, normalmente la invocación de una operación.

?Transiciones. ?Relación entre dos estados que indica que un objeto en el primer estado realizará ciertas acciones y pasará al segundo estado cuando ocurra un evento específico y satisfaga ciertas condiciones.

?Objetos. ? Manifestación concreta de una abstracción o instancia de una clase.


Diagramas de Actividades. Estados de actividad y de acción ?Estado de actividad.-Elemento compuesto, cuyo flujo de control se compone de otros estado de actividad y de acción. Procesar Pedido (f)

?Estado de acción.- Ejecución de una acción atómica. ?No pueden descomponerse y la aparición de eventos no puede interrumpir su ejecución. ?Generalmente se considera que su ejecución conlleva un tiempo insignificante. Preparar oferta

?Pueden definirse también otro tipo de estados: ? Inicial. ?Final.

61


Diagramas de Actividades. Transiciones ?Se representa mediante una línea dirigida del estado inicial al siguiente. Estado inicial

Estado final

?Podemos encontrar diferentes tipos de transacciones: ? Secuencial o sin disparadores.?Bifurcación.?División y unión.-


Diagramas de Actividades. Transiciones ?Secuencial o sin disparadores.Al completar la acción del estado origen se ejecuta la acción de salida y, sin ningún retraso, el control sigue por la transición y pasa al siguiente estado.

Estado acción 1

Transición sin disparador

Estado acción Estado acción 2

62


Diagramas de Actividades. Transiciones ?Bifurcación.Especifica caminos alternativos, elegidos según el valor de alguna expresión booleana. Guardas

[x>0]

Actividad

[x=0]

[x>0] [x=0]

Actividad

[x<0]

[x<0]

?Las condiciones de salida no deben solaparse y deben cubrir todas las posibilidades (puede utilizarse la palabra clave else). ?Pueden utilizarse para lograr el efecto de las iteraciones.


Diagramas de Actividades. Transiciones ?División y unión. Permiten expresar la sincronización o ejecución paralela de actividades.

Sincronización o unión

Ejecución paralela o división

? Conceptualmente las actividades invocadas después de una división son concurrentes. Aunque, en un sistema real en ejecución, estos flujos pueden ser realmente concurrentes o secuenciales y entrelazados, dando sensación de concurrencia real.

63


Diagramas de Actividades. Transiciones ?División y unión. Por definición, en la unión los flujos entrantes se sincronizan, es decir, cada uno espera hasta que todos los flujos de entrada han alcanzado la unión. ? Para expresar otro tipo de unión se pueden utilizar valores etiquetados.

{AND}

{OR}

{XOR}

? Para expresar que la actividad subsiguiente se realiza múltiple s veces se utiliza *. *


Diagramas de Actividades. Ejemplo Cuando recibimos un pedido, comprobamos cada artículo de la línea de pedido para ver si tenemos existencias de él. Si la respuesta es afirmativa, asignamos la mercancía al pedido. Si esta asignación hace bajar la cantidad de productos en almacén por debajo del nivel mínimo, se realiza un pedido a los proveedores. Mientras hacemos esto, revisamos el pago para ver si está correcto. Si el pago está bien y hay mercancías en existencia, servimos el pedido. Si el pago está correcto pero no tenemos existencias de ese producto, dejamos el pedido en espera. Si el pago no es correcto, se cancela la orden.

64


Diagramas de Actividades. Recibir orden

Disparador múltiple

*[por cada artículo de la línea de pedido] [fallo] Cancelar orden

Autorizar pago [éxito]

Comprobar existencia [en existencia]

Asignar a orden Condición de sincronización

[existencia asignada a todos los artículos de del pedido y pago autorizado] Servir pedido

[se necesita solicitar existencias] Realizar pedido a proveedores


Diagramas de Actividades. Ejemplo Cuando llega un reabastecimiento de los proveedores, vemos los pedidos pendientes y decidimos cuáles pueden servirse con el material recibido y, entonces, asignamos los productos correspondientes a dichos pedidos. Con esto se pueden servir las ordenes pendientes. La mercancía restante se guarda en el almacén.

65


Diagramas de Actividades. Recibir abastecimiento

Seleccionar artículos de pedidos pendientes *[por cada artículo de pedido seleccionado] Asignar artículo a pedido

[existencia asignada a todos los artículos de del pedido y pago autorizado]

[se han asignado todos los artículos necesarios a los pedidos pendientes]

Servir el pedido

Agregar resto de productos a existencias


Diagramas de Actividades. Recibir abastecimiento

Recibir orden

*[por cada artículo de la línea de pedido] Autorizar pago

Comprobar existencia [en existencia]

[fallo]

[éxito]

Seleccionar artículos de pedidos pendientes *[por cada artículo de pedido seleccionado] Asignar artículo a pedido

Asignar a orden Cancelar orden [se necesita solicitar existencias] Realizar pedido a proveedores [existencia asignada a todos los artículos de del pedido y pago autorizado]

Servir pedido

[se han asignado todos los artículos necesarios a los pedidos pendientes] Agregar resto de productos a existencias

66


Diagramas de Actividades. Calles (Swimlanes) ? Permiten ver QUIENES son los responsables de realizar las distintas actividades. ?Especificar qué parte de la organización es responsable de una actividad.

? Cada calle tiene un nombre único dentro del diagrama. ? Puede ser implementada por una o varias clases. ?Las actividades de cada calle se consideran independientes y se ejecutan concurrentemente a las de otras calles.


Diagramas de Actividades. Ventas

Almacén Recibir orden

Disparador múltiple

*[por cada artículo de la línea de pedido] [fallo] Cancelar orden

Autorizar pago

Comprobar existencia

[éxito]

[en existencia]

Asignar a orden Condición de sincronización [se necesita solicitar existencias]

[existencia asignada a todos los artículos de del pedido y pago autorizado] Servir pedido

Realizar pedido a proveedores

67


Diagramas de Actividades. Flujo de objetos ?Permiten mostrar los objetos que participan dentro del flujo de control asociado a un diagrama de actividades. ?Junto a ello se puede indicar cómo cambian los valores de sus atributos, su estado o sus roles. Objeto

o: Orden [en progreso]

Recibir orden

Estado Flujo de objeto

Servir pedido

o: Orden [finalizada]


Diagramas de Actividades. ¿Cuándo emplear los diagramas de actividades? ?En el modelado de los procesos del negocio. ?Permiten especificar y evaluar el flujo de trabajo de los procesos de negocio.

?En el análisis de un caso de uso. ?Permiten comprender qué acciones deben ocurrir y cuáles son las dependencias de comportamiento.

?En la comprensión del flujo de trabajo, a través de varios casos de uso. ?Permiten representar con claridad las relaciones de flujo de trabajo (workflow) entre varios casos de uso.

?Cuando se trata de expresar aplicaciones multihilos.

68


Diagramas de Actividades. ¿En qué situaciones no utilizarlos? ?Para tratar de ver cómo colaboran los objetos. ?En estos casos, es mejor utilizar los diagramas de interacción.

?Para tratar de ver cómo se comporta un objeto durante su ciclo de vida. ?En estos casos, es recomendable utilizar los diagramas de estados.


Diagramas de Actividades. Exposición del caso.-

Se desea estudiar el sistema de pedidos de libros, realizados po r los clientes, en una librería y su posterior envío y facturación. Se supone que la librería no mantiene stock de libros y por tanto debe pedir los libros solicitados a las editoriales correspondientes, con las cuales tiene concertado un sistema de descuentos en función de la cantidad de libros solicitados. Cada cliente tiene asociado un crédito permitido que debe ser controlado por el sistema para no aceptar pedidos si éste ha sido superado. Una vez validados los pedidos son agrupados por editorial para realizar un pedido de reaprovisionamiento asociado a los pedidos de los clie ntes.Estos pedidos se realizan dos días por semana. Cada editorial tiene establecido un tiempo estándar de respuesta. Una vez transcurrido este tiempo más una semana el pedido reaprovisionamiento puede ser anulado. Tras recibir y validar que lo enviado por la editorial se corresponde con lo solicitado, se deben asociar los pedidos de reaprovisionamiento y los de los clientes. Cuando el pedido del cliente est á completo debe añadirse la dirección de envío y generar una prefactura, la cual irá acompañando a los libros solicitados por el cliente. Una vez recibido el paquete con los libros y la prefactura, el cliente deberá realizar el pago asociado a dicha prefactura. Al ser recibido un pago del cliente, deberá asociarse a una prefactura pendiente y enviar una factura definitiva al cliente. Si el pago no se efectúa en un período de 30 días desde el env ío de la prefactura, el pedido llevará un recargo adicional. La dirección de ventas desea obtener mensualmente una estadística de compras por cliente, para de este modo poder clasificar a sus clientes en funci ón a su volumen de pedidos. Junto a este informe, la misma dirección desea enviar un cat álogo general anualmente y otro de novedades con carácter mensual , sobre aquellos temas de más interés para cada cliente, para lo cual desea disponer de una estad ística que indique los temas más frecuentemente solicitados. Una petición normal de los clientes, una vez solicitado un pedido, es saber en qué situación se encuentra.

69

Ingeniería del Software I (4º I.I) Diagrama de Secuencia : Socio

Diagramas de Secuencia.

: Encargado Coger

:Libro

: Ficha socio

: Ficha libro

:Préstamo

libro

Solicitar préstamo Verificarsituaciónsocio Situaciónsociook Verificarsituaciónlibro Situación libro ok Introducirpréstamo Autorizar

préstamo

¿Qué es un diagrama de secuencia? Es un tipo de diagrama de interacción. ? Muestra la interacción entre un conjunto de objeto y sus relaciones, incluyendo los mensajes que pueden enviarse entre ellos, en el que se destaca la ordenación temporal de los mensajes. ? Este tipo de diagramas se emplea básicamente en el diseño. ? En el análisis se utiliza para especificar el paso de mensajes entre los actores y el sistema (diagrama de secuencia del sistema).



: Encargado Coger

:Libro

: Ficha socio

: Ficha libro

:Préstamo

libro


préstamo

Diagrama de secuencia del sistema ? Es una representación que muestra los eventos generados por los actores externos y su orden . ? Permite expresar qué hace el sistema desde la perspectiva del usuario. ?Puede ser interesante crear uno de estos diagramas para cada escenario de los diferentes casos de uso.

70



: Encargado Coger

:Libro

: Ficha socio

: Ficha libro

:Préstamo

libro


préstamo

Diagrama de secuencia del sistema Ejemplo: :Sistema

Repetir mientras haya productos.

introducirProducto (identificador, cantidad)

terminarVenta()

pago(totalDinero)

Evento del sistema



: Encargado Coger

:Libro

: Ficha socio

: Ficha libro

:Préstamo

libro


préstamo

Diagrama de secuencia del sistema ¿Cómo se elabora?. ?Trazar una línea vertical que represente al sistema como un todo. ?Identifique los actores que operan directamente con el sistema para un escenario de un caso de uso. ?A partir de la descripción del escenario identifique los eventos que son generados por los actores. ?Ordene dichos eventos de arriba abajo según su orden de aparición o ejecución.

71

Ingeniería del Software I (4º I.I) Paquete

Paquete

Reglas del negocio

¿Qué es un paquete? Es un mecanismo que permite organizar los elementos de modelado en bloques mayores que se pueden manipular en grupo. ?Permiten controlar la visibilidad de los elementos de un grupo desde el exterior. ?Agrupan elementos cercanos semánticamente y que suelen cambiar juntos. ?Son cohesivos y poco acoplados. Reglas del negocio


Paquete

Reglas del negocio

?Un paquete puede contener otros elementos: clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros paquetes. ?Cada elemento pertenece exclusivamente a un único paquete ?Forma un espacio de nombres único ? Dentro de él no pueden existir dos elementos de la misma categoría con el mismo nombre.

?Permiten controlar la visibilidad de los elementos de un grupo desde el exterior. ?Pueden establecerse jerarquía de paquetes ? No más de tres niveles.

72


Paquete

Reglas del negocio

Importación ?Para poder acceder a los elementos contenidos de un paquete debe importarse dicho paquete. ? Importación: concede un permiso de un solo sentido para que los elementos de un paquete puedan acceder a los elementos de otro. ? Se utiliza el estereotipo import

?Las dependencias de importación y acceso no son transitivas ?Si un elemento es visible en un paquete lo es a todos los paquetes contenido en ese paquete


Paquete

Reglas del negocio

Visibilidad ?Normalmente los elementos contenidos en un paquete son públicos (+), es decir, son visibles por cualquier paquete que importe al paquete contenedor. ? El conjunto de partes públicas constituye su interfaz.

?Los elementos protegidos (#) sólo pueden ser vistos por los hijos dentro de una jerarquía de herencia. ?Los elementos privados (-) no son visibles fuera del paquete donde se declaran. ?Los paquete que son amigos (friend) de otro pueden ver todos los elementos de éste, sin importar cuál sea su visibilidad.

73


Paquete

Reglas del negocio

Generalización ?Pueden definirse jerarquías de generalización al igual que suceden con otros elementos como clases, casos de uso, etc. ?Los elementos más especializados heredan los elementos públicos y protegidos del paquete más general. ?Los paquetes más especializados pueden reemplazar a los elementos más generales y añadir otros. ?Un paquete generalizado puede utilizarse dondequiera que se use un paquete más general.


Paquete

Reglas del negocio

Modelado de grupos de elementos ?Examinar los elementos de una determinada vista arquitectónica en busca de grupos de elementos cercanos desde el punto de vista conceptual o semántico. ?Englobar cada uno de esos grupos en un paquete. ?Para cada paquete definir los elementos que pueden ser accedidos desde fuera. En caso de duda ocultar el elemento. ?Conectar explícitamente los paquetes que dependen de otros a través de dependencias de importación. ?En caso de encontrar familias de paquete utilizar la generalización.

74


Paquete

Reglas del negocio

Cliente + Formulario de pedidos - Pedido

Servicios de Usuario

<> <> GUI + Ventana + Formulario # GestorEventos

Servicios de Datos

<>

WindowsGUI Servicios de Negocio

MacGUI

+ GUI::Ventana + Formulario # GUI:: GestorEventos + VBForm


Paquete

Reglas del negocio

Modelado de paquetes de análisis ?Deberían crearse basándose en los requisitos funcionales y en el dominio del problema y, por tanto, deberían ser reconocibles por las personas con conocimiento del dominio. ?Contiene generalmente clases de análisis y realizaciones de casos de uso ?Una forma inicial de identificarlos es asignarle los casos de uso que : ? den soporte a un determinado proceso de negocio, ? den soporte a un determinado actor del sistema, ? están relacionados mediante relaciones de generalización y de extensión.

75


Paquete

Reglas del negocio

Modelado de paquetes de servicio ?Un servicio representa un conjunto coherente de acciones relacionadas funcionalmente que se utilizan en varios casos de uso y que son de valor para un determinado cliente. ?Tiene las siguientes características: ?Contiene un conjunto de clases relacionadas funcionalmente ?Es indivisible ?Cuando se realiza un caso de uso pueden ser necesaria la participación de varios paquetes de servicio. ?Suele ser relevante para un conjunto reducido de actores. ?Es un instrumento muy importante para la reutilización y la gestión de configuraciones o versiones en grandes proyectos software.


Paquete

Reglas del negocio

Modelado de paquetes de servicio ? Identificación de los paquetes de servicio: ?Por cada servicio opcional. El paquete de servicio será la unidad de compra. ?Para cada servicio que podría hacerse opcional, incluso aunque todos los clientes lo quieran.

?El paquete de servicio será la unidad de compra, desde la perspectiva del cliente. Corrector Ortográfico <>

Corrector Inglés

<>

Corrector Español

76


Glosario ? Actor.- Conjunto coherente de roles que juegan los usuarios de los casos de uso cuado interactúan con éstos. ? Adorno.- detalle de la especificación de un elemento que se añade a su notación gráfica básica. ? Arquitectura.- conjunto de decisiones acerca de la organización de un sistema software, la selección de los elementos estructurales de los que se compone el sistema, junto con su comportamiento tal y como se especifica en las colaboraciones entre esos elementos. En ella también se incluyen las restricciones y los compromisos entre uso, funcionalidad, rendimiento, flexibilidad, reutilización, comprensibilidad, economía y tecnología ? Artefacto.- pieza de información que es utilizada o producida por un proceso de desarrollo de software.


Glosario ... ?Asociación.- relación estructural que describe un conjunto de enlaces, donde un enlace es una conexión entre objetos (relación semántica entre dos o más clasificadores que implican la conexión entre sus instancias. ?Atributo.- propiedad con nombre de un clasificador que describe un rango de valores que pueden contener las instancias de la propiedad ?Caso de uso.- Descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable, de valor para un actor. ?Clase.- descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.

77


Glosario ... ?Clase activa.- clase cuyas instancias son objetos activos (descripción de un conjunto de objetos (objeto que tiene un proceso o hilo y puede iniciar actividad de control) ? Clase abstracta.- clase que no puede ser instanciada. ? Clasificación dinámica.- Variación semántica de la generalización en la que un objeto puede cambiar de tipo o de rol.(clasificación estática significa lo contrario). ? Clasificación múltiple.- Variación semántica de la generalización en la que un objeto puede pertenecer a más de una clase. ? Clasificador.- Mecanismo que describe características estructurales y de comportamiento (clases, interfaces, tipos de datos, señales, componentes, nodos, casos de uso y subsistemas).


Glosario ... ?Cardinalidad.- Número de elementos de un conjunto. ?Colaboración.- sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos (especificación de cómo se realiza un elementos, tal como un caso de uso o una operación, por un conjunto de clasificadores y asociaciones). ?Componente.- Parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la realización de dicho conjunto. ?Composición.- Forma de agregación con fuerte pertenencia y un tiempo de vida coincidentes entre la parte y el todo; las parte con una multiplicidad no fija pueden crearse después del todo, pero una vez creadas viven y mueren con él.

78


Glosario ... ?Concurrencia.- ocurrencia de dos o más actividades durante el mismo intervalo de tiempo. ? Contenedor.- Objeto que existe para contener otros objetos y que proporciona operaciones para acceder o iterar sobre los elementos que contiene. ? Delegación.- capacidad de un objeto de enviar un mensaje a otro objeto en respuesta a un mensaje. ? Dependencia.- relación semántica entre dos elementos en la cual un cambio a un elemento puede afectar a la semántica del otro. ? Diagrama.- Representación gráfica de un conjunto de elementos (generalmente grafo conexo de nodos y arcos). ?Diagrama de actividades .- Muestra el flujo de control entre actividades.


Glosario ... ?Diagrama de casos de uso .- Muestra un conjunto de casos de uso y actores y sus relaciones (cubren la vista de casos de uso estática del sistema). ? Diagrama de clases.- Muestra un conjunto de clases, interfaces y colaboraciones y sus relaciones (cubren la vista estática de un sistema). ?Diagrama de colaboración.- Diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben señales (muestra interacciones organizadas alrededor de instancias y los enlaces de unas a otras). ?Diagrama de componentes.- Muestra la organización y las dependencias entre un conjunto de componentes (cubren la vista de implementación estática de un sistema).

79


Glosario ... ?Diagrama de despliegue .- Muestra la configuración en tiempo de ejecución de los nodos de procesamiento y los componentes que residen en ellos(cubre la vista de despliegue estática). ?Diagrama de estados.- Muestra la máquina de estados (cubre la vista dinámica de un sistema). ?Diagrama de interacción.- Muestra una interacción que consta de un conjunto de objetos y sus relaciones; incluyendo los mensajes que pueden enviarse entre ellos (estos pueden ser de tres tipos: colaboración, secuencia y actividades). ?Diagrama de objetos.- Muestra un conjunto de objetos y sus relaciones en un momento dado(cubre la vista estática o de proceso estática)


Glosario ... ?Diagrama de secuencia .- resalta la interacción temporal de los mensajes. ?Dominio.- Área de conocimiento o actividad que se caracteriza por un conjunto de conceptos y una terminología que entienden los profesionales de ese área. ?Elemento.- constituyente atómico de un modelo. ?Enlace.- Conexión semántica entre objetos (instancia de una asociación). ?Escenario.- Secuencia específica de acciones que ilustra un comportamiento. ?Especificación.- Descripción textual de la sintaxis y la semántica de un bloque de construcción específico (descripción declarativa de los que algo es o hace).

80


Glosario ... ?Estado.- Condición o situación en la vida de un objeto durante la cual satisface una condición, realiza alguna actividad o espera algún evento. ?Estereotipo.- extensión del vocabulario de UML que permite crear nuevos bloques de construcción derivados a partir de los existentes pero específicos a un problema concreto. ?Evento.- Especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y en el espacio. ?Framework.- Patrón arquitectónico que proporciona una plantilla extensible para las aplicaciones dentro de un dominio. ?Generalización.- relación de especificación/generalización, en la cual los objetos del elemento especializado (hijo) pueden sustituir a los objetos del elemento general (padre).


Glosario ... ?Herencia.- Mecanismo por el cual los elementos más específicos incorporan la estructura y comportamiento de elementos más generales. ?Herencia múltiple.- Variación semántica de la generalización en la que un hijo puede tener más de un padre. ?Incompletitud.- Modelado de un elemento manteniendo ausentes algunas de sus partes. ?Inconsistencia.- Modelado de un elemento que no garantiza la integridad del modelo. ?Ingeniería directa.- proceso de transformar un modelo en código. ?Ingeniería inversa.- Proceso de transformar el código en un modelo.

81


Glosario ... ?Instancia.- Manifestación concreta de una abstracción; entidad a la que se pueden aplicar un conjunto de operaciones y que tiene un estado que almacena el efecto de las operaciones. ?Integridad.- relación concreta y consistente de unas cosas con otras. ?Interacción.- comportamiento que comprende un conjunto de mensajes que se intercambian entre un conjunto de objetos para lograr un objetivo. ?Interfaz.- Colección de operaciones que se utilizan para especificar un servicio de una clase o componente. ?Lenguaje de Restricción de Objetos (OCL) .- Lenguaje formal que se utiliza para expresar restricciones libres de efectos laterales.


Glosario ... ?Ligadura.- Creación de un elemento a partir de una plantilla cuando se proporcionan argumentos para los parámetros de la plantilla. ?Máquina de estados.- Comportamiento que especifica la secuencia de estados por los que pasa un objeto a lo largo de su vida en respuesta a eventos, junto con la respuesta a esos eventos. ?Mecanismo.- Patrón de diseño que se aplica a una sociedad de clases. Representa una función o comportamiento de la parte del sistema que se está modelando que resulta de la interacción de una sociedad de clases, interfaces y otros elementos. ?Mecanismo de extensibilidad.- Cada uno de los tres mecanismos (estereotipos, valores etiquetados y restricciones) que permiten extender UML de forma controlada.

82


Glosario ... ?Mensaje .- especificación de una comunicación entre objetos que transmite información con la expectativa de que se desencadene una actividad ?Metaclase.- Clase cuyas instancias son clases. ?Método.- implementación de una operación. ?Modelo.- Simplificación de la realidad, creada para comprender mejor el sistema que se está creando; abstracción semántica de un sistema. ?Multiplicidad.- Especificación del rango de cardinalidades. ?Nivel de abstracción.- Posición dentro de una jerarquía de abstracciones que abarca desde lo muy concreto a lo muy abstracto. ?Nodo.- elemento físico que existe en tiempo de ejecución y que representa un recurso computacional.


Glosario ... ?Nota.- Símbolo gráfico para representar restricciones o comentarios asociados a un elemento o a una colección de elementos. ?Objeto.- Manifestación concreta de una abstracción (instancia de una clase). ?Objeto activo.- Objeto que tiene un proceso o hilo y puede iniciar actividad de control. ?Objeto persistente.- Objeto que existe después de que el proceso que lo creó deja de existir. ?Operación.- Implementación de un servicio que puede ser requerido a cualquier objeto de la clase a la que pertenece. ?Paquete.- Mecanismo de propósito general para organizar elementos en grupos. ?Patrón.- Solución común a un problema común en un contexto determinado.

83


Glosario ... ?Plantilla.- Elemento parametrizado. ?Poscondición.- Restricción que debe ser cierta al finalizar una operación. ?Precondición.- Restricción que debe ser cierta cuando se invoca a una operación. ?Proceso.- Flujo de control pesado que puede ejecutarse concurrentemente con otros. ?Producto.- Artefacto del desarrollo como por ejemplo: modelos, código, documentación y planes de trabajo. ?Proveedor.- Tipo, clase o componente que proporciona servicios que pueden ser invocados por otros. ?Realización.- Relación semántica entre clasificadores, en la cual un clasificador especifica un contrato que otro clasificador se compromete a llevar a cabo.


Glosario ... ?Refinamiento.- Relaciones que representan una especificación más completa de algo que ya ha sido especificado a cierto nivel de detalle. ?Relación.- Conexión semántica entre elementos. ?Requisito.- Característica, propiedad o comportamiento deseado de un sistema. ?Responsabilidad.- Contrato u obligación de un tipo o una clase. ?Restricción.- Extensión de la semántica de un elemento de UML que permite añadir nuevas reglas o modificar las existentes. ?Rol.- Comportamiento de una entidad que participa en un contexto particular.

84


Glosario ... ?Señal.- Especificación de un estímulo asíncrono que es transmitido entre instancias. ?Subclase.- En una relación de generalización, la especialización de otra clase (el hijo). ?Subsistema.- agrupación de elementos, algunos de los cales constituyen una especificación del comportamiento ofrecido por los otros elementos. ?Superclase.- En una relación de generalización, la generalización de otra clase (el padre). ?Tarea.- flujo de ejecución único a través de un programa, un modelo dinámico o alguna otra representación de un flujo de control. ?Tipo.- estereotipo de clase que se utiliza para especificar un dominio de objetos, junto con operaciones de ese objeto.


Glosario ... ?Tipo de datos.- Tupo cuyos valores no tienen identidad. Los tipos de datos incluyen los tipos primitivos , así como tipos enumerados. ?Traza.- Dependencia que implica una relación de proceso o historia entre dos elementos que representan el miso concepto, sin reglas para derivar el uno del otro ?UML.- lenguaje de modelado para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. ?Unidad de distribución.- conjunto de objetos o componentes que se colocan en un nodo como un grupo. ?Uso.- Dependencia en la que un elemento (el cliente) requiere la presencia de otro elemento (el proveedor) para un funcionamiento o una implementación correcta.

85


Glosario ... ?Valor etiquetado.- Extensión de las propiedades de un elemento de UML, que permite crear nueva información en la especificación de ese elemento. ?Versión.-Conjunto relativamente completo y consistente de artefactos entregado a un usuario ?Visibilidad.- Cómo puede ser visto y utilizado un nombre por otros. ?Vista.- Proyección de un modelo que se ve desde una perspectiva o punto de vista dado y que omite entidades que no son relevante desde esa perspectiva.

86

Analisis Orientado A Objetos Con UML

Recommend Documents