Modelado de Software



Descargar 48,88 Kb.
Fecha de conversión12.01.2017
Tamaño48,88 Kb.

Modelado de Software

  • Modelado de Software
  • Orientado a Objetos usando UML
  • Dr. Pedro Mejia Alvarez
  • Departamento de Computacion
  • CINVESTAV-IPN

Contenido

  • Fundamentos del Modelado OO
  • Requisitos del software
  • Interacción entre objetos
  • Clases y relaciones entre clases
  • Diagramas de UML

Diagramas de UML

  • Use Case
  • Diagrams
  • Use Case
  • Diagrams
  • Diagramas de
  • Casos de Uso
  • Scenario
  • Diagrams
  • Scenario
  • Diagrams
  • Diagramas de
  • Colaboración
  • State
  • Diagrams
  • State
  • Diagrams
  • Diagramas de
  • Componentes
  • Component
  • Diagrams
  • Component
  • Diagrams
  • Diagramas de
  • Distribución
  • State
  • Diagrams
  • State
  • Diagrams
  • Diagramas de
  • Objetos
  • Scenario
  • Diagrams
  • Scenario
  • Diagrams
  • Diagramas de
  • Estados
  • Use Case
  • Diagrams
  • Use Case
  • Diagrams
  • Diagramas de
  • Secuencia
  • State
  • Diagrams
  • State
  • Diagrams
  • Diagramas de
  • Clases
  • Diagramas de
  • Actividad
  • Modelos
  • Los diagramas expresan gráficamente partes de un modelo

Diagrama de Clases

  • El Diagrama de Clases es el diagrama principal para el análisis y diseño del sistema
  • Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia
  • La definición de clase incluye definiciones para atributos y operaciones
  • El modelo de casos de uso debería aportar información para establecer las clases, objetos, atributos y operaciones

Objetos

  • Objeto = unidad atómica que encapsula estado y comportamiento
  • La encapsulación en un objeto permite una alta cohesión y un bajo acoplamiento
  • La cohesion es la medida de la cercania de las relaciones entre sus componentes.
  • El acoplamiento es una medida de la fuerza de las interconecciones entre los componentes en el diseño.
  • Un objeto puede caracterizar una entidad física (coche) o abstracta (ecuación matemática)

Clases y Objetos

  • En UML, para distinguir una clase y una instancia de la clase (un objeto) se representa por un rectángulo con un nombre subrayado
  • Objeto = Identidad + Estado + Comportamiento
  • El estado está representado por los valores de los atributos los cuales tienen una visibilidad.
  • Un atributo toma un valor en un dominio concreto.

Clases y objetos

  • La clase define el ámbito de definición de un conjunto de objetos
  • Cada objeto pertenece a una clase
  • Los objetos se crean por instanciación de las clases
  • Para distinguir entre una clase (el tipo) y un objeto (una instancia del tipo), un objeto se muestra subrayado. Un objeto puede representarse como anObject, anotherObject:Class, o :Class.
  • Las clases y los objetos forman parte de varios diagramas UML.

Clases: Notación Gráfica

  • Cada clase se representa en un rectángulo con tres compartimientos:
    • nombre de la clase
    • atributos de la clase
    • operaciones de la clase

Clases: Encapsulación

  • La encapsulación permite la cohesion y presenta dos ventajas básicas:
    • Se protegen los datos de accesos indebidos
    • El acoplamiento entre las clases se disminuye
    • Favorece la modularidad y el mantenimiento
  • Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos

Clases: Encapsulación

  • Los niveles de encapsulación están heredados de los niveles
  • de C++, y explican si estos son visibles desde el exterior de
  • la clase:
    • (-) Privado : es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++)
    • (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original
    • (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)

Clases: Encapsulación

  • Ejemplo:
  • Reglas de visibilidad
  • + Atributo público : Integer
  • # Atributo protegido : Integer
  • - Atributo privado : Integer
  • + "Operación pública"()
  • # "Operación protegida"()
  • - "Operación privada"()

Diagramas de Clases

  • Un diagrama de clases describe los tipos de objetos
  • en el sistema y los distintos tipos de relaciones
  • estáticas que existen entre ellos. Existen cuatro
  • relaciones:
  • Asociación
  • Generalización/especialización
  • Agregación/composición
  • Dependencia

Asociación

  • Permite asociar objetos.
  • La asociacion se representa mediante una línea que une las cajas de los dos objetos.

Asociación

  • Una asociación se representa mediante una línea que une las cajas de las dos clases.
  • Esta asociacion tiene un nombre y opcionalmente una pequeña cabeza de flecha que indica la dirección en la cual se debe leer el nombre de la asociación.
  • En cada extremo de la línea se sitúa la multiplicidad o cuantas instancias de una clase se relacionan con una instancia de la otra.
  • Se puede usar una flecha de línea (“stick arrow”) para representar la dirección de la navegabilidad.

Asociación

  • Ejemplo:

Asociación

  • Especificación de multiplicidad (mínima...máxima)
    • 1 Uno y sólo uno
    • 0..1 Cero o uno
    • M..N Desde M hasta N (enteros naturales)
    • * Cero o muchos
    • 0..* Cero o muchos
    • 1..* Uno o muchos (al menos uno)
  • La multiplicidad mínima >= 1 establece una restricción de existencia

Generalización

  • Esta es una relación de tipo: es-un.
  • Una generalización se
  • representa como una flecha que une a las subclases
  • (hijos) a la superclase (padre), con la flecha tocando la caja de la superclase.

Generalización

  • Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases
  • Se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización
  • La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general

... Generalización

  • Nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada
  • Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre están disponibles en sus clases hijas

Relacion de Dependencia entre Clases

  • Se usa para mostrar relaciones entre paquetes (grupos de clases)
  • Proveedor
  • Cliente

Agregacion de Objetos

  • En este modelo se muestra como las clases pueden estar compuestas por otras clases.
  • Existe la relacion de agregacion y la de composicion.
  • Son similares a los modelos de entidad-relacion.

Agregacion de Objetos

  • Estas son relaciones todo/parte.
  • La relación de composición (representada con un diamante relleno) es la forma más fuerte de relación todo/parte que la relación de agregación (mostrada por un diamante vacío).
  • El diamante toca la caja de clase de la clase (todo) compuesta/agregada.

Ejemplos

  • Esta compuesta de
  • Son parte de

Diagrama de Casos de Uso

  • Es una técnica para capturar
  • información sobre los servicios que
  • un sistema proporciona a su
  • entorno, desde el punto de vista del
  • usuario. Es una técnica para captura
  • y especificación de requisitos

Casos de Uso

  • Los Casos de Uso describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario
  • Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno
  • Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación
  • Es posible identificarlos a partir de los puntos de vista (Metod VORD de Sommerville).

Casos de Uso

  • Ejemplo:

Casos de Uso

  • Actores:
    • Principales: personas que usan el sistema
    • Secundarios: personas que mantienen o administran el sistema
    • Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados
    • Otros sistemas: sistemas con los que el sistema interactúa
  • La misma persona física puede interpretar varios papeles como actores distintos
  • El nombre del actor describe el papel desempeñado

Casos de Uso

  • Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario (Metodo VORD).
  • Un escenario es una instancia de un caso de uso
  • Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso

Casos de Uso: Ejemplo

  • Passajero
  • Comprar boleto
  • Usado durante para la obtencion y analisis de los requerimientos para representar el comportamiento de sistema, visible desde el exterior.
  • Un caso de uso representa un tipo de funcionalidad del sistema

Ejemplo: Actores

  • Un actor es un modelo que permite representar una entidad externa que interactua (comunica) con el sistema:
    • Usuario
    • Sistema externo (otro sistema)
    • Ambiente fisico
  • Un actor tiene un nombre unico y una descripcion opcional.
  • Ejemplos:
    • Pasajero: Una persona en el tren
    • Satelite GPS: Sistema externo que provee coordenadas de ubicacion.
  • Pasajeros
  • Nombre
  • Descripcion
  • opcional

Caso de uso

  • • Los casos de uso pueden ser descritos textualmente, describiendo el flujo de eventos entre el actor y el sistema.
  • • La descripcion textual del caso de uso incluye 6 partes:
    • Nombre unico
    • Actores participantes
    • Condiciones de entrada
    • Condiciones de Salida
    • Flujo de eventos
    • Requisitos especiales
  • Compra boleto

Ejemplo de caso de uso textual

  • 1. Nombre: Compra boleto
  • 2. Actor: Pasajero
  • 3. Condicion de entrada:
  • El pasajero se dirige al la ventanilla de boletos
  • El pasajero cuenta con suficiente dinero para comprar el boleto
  • 4. Condicion de salida:
  • EL pasajero compro el boleto
  • 5. Flujo de eventos:
    • 1. El pasajero selecciona la zona de destino da donde quiere viajar
    • 2. El vendedor de boletos despliega el monto del boleto a ese destino
    • 3. El pasajero entrega al menos el monto de dinero requerido
    • 4. El vendedor regresa el cambio, en caso de que sea necesario
    • 5. El vendedor entrega el boleto
  • 6. Requerimientos especiales: Especificar el tipo de transporte: Tren o autobus.
  • Pasajero
  • Compra boleto

Casos de Uso: Relaciones

  • UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
    • Comunicación
    • Inclusion
    • Extension
    • Herencia

Casos de Uso: Relaciones

  • Comunicación: permite comunicar al actor con su caso de uso.
  • Pasajero
  • Compra un boleto
  • Compra multiples boletos
  • <>
  • Recoge el dinero
  • <>
  • No cambio
  • <>
  • Cambio de moneda
  • <>
  • Cancela
  • <>

… Casos de Uso: Relaciones

    • Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino.
    • La relación <> pretende evitar duplicación de interacciones en distintos casos de uso

Relacion <>

  • La relacion <> representa una funcionalidad comun necesaria en mas de un caso de uso
  • La funcionalidad de <> puede reutilizarse
  • La direcion de la relacion <> es hacia el caso de uso (de forma distinta que la relacion <>).
  • Pasajero
  • Compra un boleto
  • Compra multiples boletos
  • <>
  • Recoge el dinero
  • <>
  • No cambio
  • <>
  • Cambio de moneda
  • <>
  • Cancela
  • <>

… Casos de Uso: Relaciones

    • Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino
    • La relación <> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso.

Relacion <>

  • La relacion <> modela casos exceptional, o casos de uso auto invocados
  • EL flujo de eventos excepcionales pueden detallarse para claridad del caso de uso
  • La direccion de la relacion <> es hacia el caso de uso
  • Los casos de uso representando flujos excepcionales pueden extender mas de un caso de uso.
  • Pasajero
  • Compra boleto
  • Tiempo agotado
  • <>
  • No hay cambio
  • <>
  • Fuera de servicio
  • <>
  • Cancela
  • <>

… Casos de Uso: Relaciones

  • Otro ejemplo <> y <>:

… Casos de Uso: Relaciones

    • Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía

Casos de Uso: Construcción

  • Un caso de uso debe ser simple, inteligible, claro y conciso
  • Generalmente hay pocos actores asociados a cada Caso de Uso
  • Preguntas clave:
    • ¿cuáles son las tareas del actor?
    • ¿qué información crea, guarda, modifica, destruye o lee el actor?
    • ¿debe el actor notificar al sistema los cambios externos?
    • ¿debe el sistema informar al actor de los cambios internos?

… Casos de Uso: Construcción

  • La descripción del Caso de Uso comprende:
    • el inicio: cuándo y qué actor lo produce?
    • el fin: cuándo se produce y qué valor devuelve?
    • la interacción actor-caso de uso: qué mensajes intercambian ambos?
    • objetivo del caso de uso: ¿qué lleva a cabo o intenta?
    • cronología y origen de las interacciones
    • repeticiones de comportamiento: ¿qué operaciones son iteradas?
    • situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?
  • Identificador
  • CU-<id-requisito>
  • Nombre
  • <nombre del requisito funcional>
  • Descripción
  • El sistema deberá comportarse tal como se describe en el siguiente caso de uso { concreto cuando , abstracto durante la realización de los casos de uso }
  • Precondición

  • Secuencia
  • Normal
  • Paso
  • Acción
  • 1
  • 2
  • Si , {el , el sistema} >, se realiza el caso de uso < caso de uso CU-x>
  • Postcondición

  • Excepciones
  • Paso
  • Acción
  • 1
  • Si ,{el , el sistema} }>, se realiza el caso de uso
  • < caso de uso CU-x>, a continuación este caso de uso {continua, aborta}
  • Rendimiento
  • Paso
  • Cota de tiempo
  • 1
  • n segundos
  • Frecuencia esperada
  • veces /
  • Importancia
  • {sin importancia, importante, vital}
  • Urgencia
  • {puede esperar, hay presión, inmediatamente}
  • Comentarios

Diagrama de Secuencia

    • Describe el comportamiento dinamico del los objetos en el sistema

Diagrama de Secuencia

  • Mensajes
  • :Time
  • :Watch
  • :WatchUser
  • Objeto
  • Activacion
  • Actor
  • pressButton1()
  • Lifeline
  • blinkHours()
  • pressButton2()
  • incrementMinutes()
  • :LCDDisplay
  • pressButton1and2()
  • commitNewTime()
  • stopBlinking()
  • refresh()
  • pressButton1()
  • blinkMinutes()
  • return

Diagrama de Secuencia

Diagrama de Secuencia

  • El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones
  • Muestra la secuencia de mensajes entre objetos durante un escenario concreto
  • Cada objeto viene dado por una barra vertical
  • El tiempo transcurre de arriba abajo
  • Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua

Diagrama de Secuencia

  • Usada durante el analisis
      • Refina la descripcion de casos de uso
      • Util para descubrir objetos
  • Usada durante el diseño
    • Para refinar interfaces de subsistemas
  • Las instancias se representan mediantes rectangulos.
  • Actores mediantes figuras
  • Los flujos de control mediante lineas punteadas
  • Los Mensajes mediante flechas
  • Las activaciones mediante rectangulos pequeños.
  • seleccionadestino()
  • retiracambio()
  • Retiraboleto()
  • insertamonedas()
  • Maquina de Boletos
  • Pasajero
  • zone2price
  • Selec-destino()
  • insertamoneda()
  • retiracambio()
  • retiraboleto()
  • Maquina de Boletos

Diagrama de secuencia

  • seleccionadestino()
  • retiracambio()
  • Retiraboleto()
  • insertamonedas()
  • Maquina de Boletos
  • Pasajero
  • Mensaje:Flujo
  • de control
  • Lifeline
  • Activacion

Lifeline y Especificacion de la ejecucion

  • El lifeline (linea de vida) representa una participacion de un objeto particular en la interaccion
  • Consiste de un rectangulo seguido de una linea vertical (que puede ser punteada) que representa el tiempo de vida del participante
  • La especificacion de la execucion especifica el comportamiento o la interaccion con la linea de vida.
  • Se representa mediante un rectangulo delgado vertical.

Mensajes

  • Define una comunicacion particular entre los “lifelines” de una interaccion.
  • Ejemplos de comunicacion
    • Enviar una señal
    • Invocar una operacion
    • Crear o destruir una instancia
  • Es necesario especificar quien envia y quien recibe (sender y receiver)
  • Se muestran como una linea que se enviar de enviador al receptor
  • Distintas formas de flechas reflejan las propiedades el mensaje

Tipos de mensajes

  • Asincronos
  • Sincronos
  • Llamada(Call) y creacion
  • de un objeto
  • Reply
  • Lost
  • Found
  • Asincrono

Etiquetas de las flechas

Tipos de flechas

Flujo de Datos

  • Los diagramas de secuencia tambien pueden modelar flujo de datos
  • El origen de una flecha indica la activacion que envia el mensaje
  • Las flechas horizontales punteadas indican flujo de datos.
  • Pasajero
  • Selecciona destino()
  • Botondestinoo
  • TarifasS
  • Diespiliegue
  • lookupPrice(selection)
  • Despliegaprecio(precio)
  • precio
  • Flujo de
  • Datos

Iteracion y Condicion

  • La iteracion se denota por un simbolo * seguido de un nombre de mensaje
  • La condicion se denota mediante una expresion booleana en [] antes del nombre del mensaje
  • Pasajero
  • Procesador de
  • Cambios
  • insertacambio(moneda)
  • Identif.demonedas
  • Diespliegue
  • Dispensa
  • Moneda
  • displiegaprecio(precio)
  • checamoneda(moneda)
  • precio
  • [Monto<0] returnCambio(-cambio)
  • Iteracion
  • Condicion
  • *

Creacion y destruccion

  • La creacion se denota mediante un mensaje sobre una flecha apuntando al objeto
  • La destruccion se denota mediante una X que marca el fin de la activacion
  • Pasajero
  • Proc.de Cambios
  • BoletoT
  • creaboletoT(seleccion)
  • free()
  • Creacion del boleto
  • Destruccion del boleto
  • print()

Propiedades del diagrama de secuencia

  • Representa comportamiento en terminos de interacciones
  • Util para identificar o encontrar objetos
  • Complemento al diagrama de flujo de datos y al diagrama de clases.

Diagrama de Secuencia(ejemplo)

Diagrama de Secuencia(ejemplo)

Diagrama de Colaboración

  • Modela la interacción entre los objetos de un Caso de Uso
  • Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección
  • Ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Diagrama de Colaboración

  • Muestran una vista dinamica del sistema.
  • El diagrama de secuencia muestra el ordenamiento en el tiempo de los mensajes mientras que el diagrama de colaboracion expone la estructura organizacional de los mensajes.
  • Los diagramas de colaboracion muestran el flujo de mensajes entre objetos en un sistema, y tambien exponen las relaciones (asociaciones) entre sus clases.
  • Los diagramas de colaboracion son tambien diagramas de interaccion. Manejan la misma informacion que los diagramas de secuencia pero se enfocan mas en los roles de los objetos que en los tiempos en que los mensajes son enviados.

Diagrama de Colaboración

Diagrama de Colaboración

Notacion del Diagrama de Colaboración

    • Representa una colaboracion o una interaccion.
    • Colaboracion: conjunto de objetos y su interaccion dentro de un contexto.
    • Interaccion: conjunto de mensajes intercambiados en una colaboracion para
    • producir un resultado deseado.
    • Objetos:
      • Rectangulos conteniendo una firma del objeto.
      • Firma del objeto: nombre del objeto : clase del objeto.
      • nombre de la clase (obligatoria): comienza con letra mayuscula.
      • Objetos conectados mediante lineas.
      • Puede existir uno o mas actores.
    • Mensajes:
      • Se etiquetan como las llamadas a funciones en Java.
      • Seguidas de brackets redondeados, pueden tener parametros y valores de retorno.
      • Incluyen una flecha que indica direccion.
      • Los mensajes se numeran, comenzando con el numero 1.

Notacion del Diagrama de Colaboración

    • Firma del mensaje
      • Guardia.
        • condicion aplicada al mensaje
        • en brackets redondos al principio del mensaje.
    • Numeros secuenciales.
      • numeros separados por puntos, con terminacion en coma.
    • Valor de retorno
      • nombre seguido de “:=“
    • Nombre de la operacion
    • Lista de argumentos.
      • nombres separados por comas, dentro de brackets redondeados.

Tipos de Mensajes

    • Simple
      • Indican flujo de control – el que envia espera hasta que el receptor procesa el mensaje.
        • default: mostrada mediante una flecha:
    • Sincrono.
      • indica flujo de control anidado.
      • usado para asegurar que el estado no pueda ser interrumpido por factores externos.
      • mostrado mediante una flecha llena.
    • Asincrono
      • muestra una señal de un objeto a otro.
      • se indica mediante una flecha a la mitad

Diagrama de Colaboración

    • 1. Trazado del diagrama: a nivel de instancia y especificacion.
    • 2. Mensajes.
    • 3. Conectores (Links)

Diagrama de Colaboración

  • Diagramas a nivel de instancia: usuados para explorar las caracteristicas del diseño de los objetos. Estos diagramas muestran interacciones entre objetos (instancias).

Diagrama de Colaboración

  • Diagramas a nivel de especificacion: se usan para analizar y explorar los roles de las clases en el sistema.

Mensajes en el Diagrama de Colaboración

  • sequenceNumber loopIndicator: returnValue := methodName(parameters)

Ligas (links) en el Diagrama de Colaboración

  • Las lineas o ligas entre las clases representan instancias de las
  • Relaciones, que pueden incluir, asociaciones, agregaciones,
  • composiciones y dependencias.
  •  

Diagrama de Estados

  • Modela el comportamiento de una parte del sistema

Diagrama de UML: Statechart

  • Estado
  • Estado inicial
  • Estado final
  • Transicion
  • Evento
  • button1&2Pressed
  • button1Pressed
  • button2Pressed
  • button2Pressed
  • button2Pressed
  • button1Pressed
  • button1&2Pressed
  • Increment
  • Minutes
  • Increment
  • Hours
  • Blink
  • Hours
  • Blink
  • Seconds
  • Blink
  • Minutes
  • Increment
  • Seconds
  • Stop
  • Blinking

Diagrama de Actividades

  • Es un caso especial de un diagrama de state-chart en donde los estados son actividades (“funciones”).
  • Es util para dibujar los flujos de trabajo (workflows) en un sistema
  • Puede especificar:
  • (1)El comportamiento de los objetos de una clase
  • (2) Las actividades del sistema
  • (3) La lógica de una operación (método)
  • (4) Parte o toda la descripción de un Caso de uso
  • (5) La descripción de un Flujo de Trabajo

Nodos de actividades y flechas

  • Un diagrama de actividad consiste de nodos y flechas (edges)
  • Hay 3 tipos de nodos de actividades
      • Nodos de control
      • Nodos executables: acciones
      • Nodos de objetos
  • Una flecha (edge) es una coneccion directa entre nodos
    • Control de flujo
    • Flujo de objetos

Notacion del Diagrama

  • Initial node
  • Merge node
  • Final node
  • Action
  • Object node
  • Fork node
  • Join node
  • Object flow
  • Control flow

Permite modelar desiciones

  • Decision

Modelacion de concurrencia

  • Sincronizacion de multiples actividades
  • Separacion de el flujo de control en multiples threads
  • Synchronization
  • Splitting

Agrupamiento de actividades

  • Las actividades pueden agruparse para denotar el objeto o el subsistema que implementa las actividades
  • Open
  • Incident
  • Allocate
  • Resources
  • Coordinate
  • Resources
  • Document
  • Incident
  • Archive
  • Incident
  • Dispatcher
  • FieldOfficer

Diagrama de Componentes

  • Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones
  • Permite modelar la estructura del software y la dependencia entre componentes, en donde un componente es un grupo de clases que trabajan estrechamente. Los componentes pueden corresponder código fuente, binario o ejecutable.
  • Una relación de dependencia indica que un componente utiliza otro, por lo cual depende de él

Diagrama de Componentes

  • Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc.
  • Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente

Diagrama de Componentes

Diagrama de Despliegue

  • Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos

Diagrama de Despliegue

  • Modela la distribución en tiempo de ejecución de los elementos de procesamiento y componentes de software, junto a los procesos y objetos asociados
  • Se modelan los nodos y la comunicación entre ellos
  • Cada nodo puede contiene instancias de componentes

Diagrama de Despliegue

  • Los estereotipos permiten precisar la naturaleza del equipo:
    • Dispositivos
    • Procesadores
    • Memoria
  • Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse

Diagrama de Despliegue

  • Ejemplo de conexión entre nodos:
  • Terminal Punto
  • de Venta
  • <>
  • Base de
  • Datos
  • <>
  • Control
  • <>
  • <>
  • Podemos distinguir tipos de nodos y conexiones por estereotipado
  • <>

Diagramas de Despliegue

  • Ejemplo:

… Diagramas de Despliegue

  • Ejemplo:
  • Component Diagram: videoStoreServer
  • Client
  • videoStoreApplication
  • DBServer

Diagrama de Despliegue en Rational

  • Servidor Central
  • Punto de Venta
  • Terminal de Consulta

Paquetes en UML

  • Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado
  • Se representan gráficamente como:

… Paquetes en UML

  • Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema)
  • Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está definido en) sólo un paquete
  • Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes

… Paquetes en UML

  • Todos los elementos no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa
  • El operador “::” permite designar una clase definida en un contexto distinto del actual

...Paquetes en Rational Rose

  • Customers
  • Banking

… Paquetes en UML

Los modelos se usan para describir al sistema de software

  • Modelo del sistema: Modelo de objetos + modelo funcional + modelo dinamico
  • Modelo de objetos: Cual es la estructura del sistema? Cuales son los objetos y cual es su relacion?
    • Notacion UML: Diagramas de clases
  • Modelo funcional: Cuales son las funciones del sistema? Como fluyen los datos en el sistema?
    • Notacion UML: Diagramas de casos de uso
  • Modelo dinamico: Como reaccciona el sistema a eventos externos (e internos) y cual es el flujo de eventos?
    • Notacion UML: Diagramas de secuencia, state charts y de actividad.

Modos de utilizacion de UML

  • Ingenieria hacia adelante(Forward Engineering)
    • Se comienza con un modelo antes de producir codigo
  • Ingenieria en reversa (Reverse Engineering)
    • Se crea un modelo a partir de algun codigo
    • Proyectos de interfaces o re-ingenieria
  • Ingenieria ciclica (Roundtrip Engineering)
    • Se mueve constantemente entre ingenieria hacia adelante y en reversa.
    • Util en proyectos que utilizan el modelo de procesos evolutivo, o cuando los requerimientos cambian frecuentemente.
  • Se asume que a partir de UML se puede producir codigo, pero en donde se ubica UML dentro del proceso de Diseño ?.

Proceso de Desarrollo Unificado basado en UML

  • Propuesta de Rational Unified Process (RUP)
    • M. de Casos de Uso del Negocio (Business Use-Case Model)
    • M. de Objetos del Negocio (Business Object Model)
    • M. de Casos de Uso (Use-Case Model)
    • M. de Análisis (Analysis Model)
    • M. de Diseño (Design Model)
    • M. de Despliegue (Deployment Model)
    • M. de Datos (Data Model)
    • M. de Implementación (Implementation Model)
    • M. de Pruebas (Test Model)

Resumen

  • UML define una notación que se expresa como diagramas sirven para representar modelos/subsistemas o partes de ellos
  • El modelo de proceso RUP utiliza UML para el modelado.

Tendencias

  • Nuevas versiones de UML, uff!
  • Extensiones de UML (SysML, www.sysml.org)
  • Generación automática de código a partir de modelos
    • Model-Driven Development (MDD), Model-Driven Architecture (MDA), Compiladores de Modelos
    • Round-trip engineering. Convergencia entre herramientas CASE e IDEs
  • Extendiendo UML mediante Profiles (www.objecteering.com/products_uml_profile_builder.php)
  • Modelado y generación de código en dominios específicos (más allá de UML)
    • Eclipse Modeling Framework (EMF, download.eclipse.org/tools/emf/scripts/home.php)
    • Microsoft Tools for Domain Specific Languagues
    • Domain-Specific Modeling (DSM, www.dsmforum.org)
    • Meta CASE Tools (www.metacase.com)

Diagramas en UML 2.0

Bibliografía Adicional

  • UML
    • www.omg.org/uml/
    • Meta-links www.cetus-links.org/oo_uml.html
    • Martin Fowler, autor de “UML Destilled” (“UML Gota a Gota”) http://www.martinfowler.com/
  • Herramientas CASE
    • Herramientas basadas en UML www.objectsbydesign.com/tools/umltools_byPrice.html
    • International Council in SE (INCOSE) www.incose.org/tools/
  • Otras
    • Revista IEEE Software, Conferencias: OOPSLA, ECOOP
    • Patrones http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html,
    • Foro UML en yahoo: http://groups.yahoo.com/group/uml-forum/  


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal