5.

3 MODELOS ESTRUCTURALES

Los modelos estructurales de software muestran la organizacin de un sistema. Modelos estructurales son estticos: que muestran la estructura del diseo del sistema, o

Modelos dinmicos: que revelan la organizacin del sistema cuando se ejecuta.

5.3.2 DIAGRAMAS DE CLASE

Pueden usarse cuando se desarrolla un modelo de sistema orientado a objetos para mostrar las clases y las asociaciones entre dichas clases.

Una clase de objeto se considera como una definicin general de un tipo de objeto del sistema. Asociacin es un vinculo entre clases.

Cuando se desarrollan: IS: Algo del mundo real. UML: Buscar en el mundo real, identificar los objetos esenciales y representarlos como clases

 Es un diagrama de clase simple que muestra 2 clases Asociacin es 1.

La figura 5.8 clases y asociaciones UML

Figura 5.9 clases y Asociaciones en

Es posible usar el el modelo semntico de datos: Piensa en entidades de con clases simplificadas. Atributos de clase objeto Relaciones En UML, los atributos se muestran al extender el rectngulo simple que representa una clase:

Fig 5.10 La clase consulta

1. Nombre de la clase. 2. Los atributos de la clase. 3. Las operaciones .

5.3.2GENERALIZACIN

La

generalizacin es una tcnica cotidiana que se usa para gestionar la complejidad. el modelado de sistema, con frecuencia es til examinar las clases de un sistema con la finalidad de ver si hay mbito para la generalizacin. Esto significa que la informacin comn se mantendr solamente en un lugar.

En

UML tiene un tipo especifico de asociacin para denotar la generalizacin. La generalizacin se muestra como una flecha que apunta hacia la clase mas general.
Mdic o
Mdico de hospital.

Mdico de cabecer a.
Mdico de equipo
Mdico calificado

Consulto r

Mdico
practicant e

Figura 5.11 Jerarqua de generalizacin.

En una generalizacin, los atributos y operaciones asociados con las clases de nivel superior tambin se asocian con las clases de nivel inferior. En esencia las clases de nivel inferior son subclases que heredan los atributos y las operaciones de sus superclases. Entonces dichas clases de nivel inferior agregan atributos y operaciones mas especficos. Mdico
Nombre # Telfono Correo electrnico Registro() Dar-baja()

Figura 5.12 Jerarqua de generalizacin con detalles agregados.

Mdico hospital # Personal # Localizador

Mdico general Especialidad Direccin

5.3.3 AGREGACIN

Los objetos en mundo real con frecuencia estn compuestos por diferentes partes. En ocasiones, en un modelo de sistema, se necesita ilustrar esto. UML proporciona un tipo especial de asociacin entre clases llamado agregacin, que significa que un objeto (el todo) se compone de otros objetos Paciente (las partes). registrado
1 1 Pacient e 1 1.. * Consult a

Figura 5.13 asociacin agregacin.

La

5.4 MODELOS DE COMPORTAMIENTO

Los modelos de comportamiento son modelos dinmicos del sistema conforme se ejecutan. En ellos se muestra lo que sucede o lo que se supone que pasa cuando un sistema responde ante un estimulo de su entorno. Tales estmulos son de dos tipos: Datos: Algunos datos que llegan se procesan por el sistema. Eventos: algunos eventos activan el procesamiento del sistema. Los eventos pueden tener datos asociados, pero esto no es siempre el caso.

5.4.1 MODELADO DIRIGIDO POR DATOS

16

Muestran la secuencia de acciones involucradas en el procesamiento de datos de entrada, as como la generacin de una salida asociada. Son tiles durante el anlisis de requerimientos. Pues sirve para mostrar procesamiento extremo a extremo en un sistema Los diagramas de flujos de datos son simples e intuitivos y por lo general son fciles de explicar a los usuarios potenciales del sistema, quienes pueden participar en la validacin del sistema.

 UML

Sensor de glucosa en la sangre

no soporta diagramas de flujo de datos. UML 2.0 introdujo diagramas de actividad que son similares a los diagramas de flujo de datos.
Obtener valor de sensor

Datos de sensor

Calcular el nivel de azcar

Nivel de azcar en la sangre

Calcular la liberacin de insulina Comandos de control de bomba Calcular comandos de bomba

Bomba de insulina

Control de bomba

Requerimiento de insulina

FIG. 5.14 Modelo de actividad de la operacin de la bomba de insulina

FIG. 5.15 Orden de procesamiento Agente de compras :Pedido Presupuesto

Proveedor

Almacn datos Pedidos

Llenar () Validar ()

[Validacin ok ] Actualizar (importe)

Guardar () Enviar ()

5.4.2 MODELADO DIRIGIDO POR UN EVENTO

20

Muestra

como responde un sistema a eventos externos e internos. Se basa en la suposicin de que un sistema tiene un nmero finito de estados y que los eventos pueden causar una transicin de un estado a otro. UML soporta modelado basado en eventos usando diagramas de estado, que muestran estados y eventos del sistema que causan transacciones de un estado a otro.

En

los diagramas de estado UML los rectngulos redondeados representan estados del sistema. Las flechas representan estmulos que fuerzan una transaccin Se pueden indicar los estados inicial y final usando circulo rellenos. El problema con el modelado basado en el estado es que el nmero de posibles estados se incrementa rpidamente.

Potencia Completa

Potencia completa DO: Establecer potencia = 600 Temporizado r

Numero
Operacin DO: Operar horno

Espera DO: Desplegar tiempo Potencia media

Potenci a complet a

Establecer tiempo DO: Conseguir numero Exit: Establecer tiempo Puerta cerrada

Temporizado r

Iniciar
Cancelar

Potencia media

Potencia media DO: Establecer potencia = 300 Puerta abierta

En operacin DO: Mostrar Listo

Puerta abierta

Espera DO: Mostrar tiempo

Figura 5.15 Diagrama de estado de un horno de microondas

Puerta cerrada
Deshabilitado DO: Mostrar Espere

Para modelos se sistemas grandes, necesita ocultar detalles de los modelos, esto se puede hacer mediante la nocin de un superestado que encapsule algunos estados separados. Operacin Tiempo
Comprobacin DO: Comprobar status

OK

Cocinar DO: Correr generador

Falla tornamesa
Alarma DO: Mostrar evento

Falla emisor

Pausa
Hecho DO: Timbre 5 segundos

Figura 5.18 Operacin del horno de microondas

Puerta abierta
Deshabilitado Espera

Cancelar

Ingeniera dirigida por modelo

Arquitectura dirigida por modelo

Ingeniera dirigida por modelo

Es un enfoque al desarrollo de software donde los modelos, y no los programas son las salidas principales del proceso de desarrollo. Los programas se ejecutan en una plataforma hardware/software se generan en tal caso automticamente a partir de los modelos. Se argumenta que se eleva el nivel de abstraccin en la Ing. Software, porque los ingenieros no tienen que preocuparse por el lenguaje de programacin o de las especificaciones de las plataformas de ejecucin.

Las races de la Ing. Dirigida por modelo estn en la arquitectura dirigida por modelo, que fue propuesta en como nuevo paradigma de software. La arquitectura dirigida por modelo se enfoca en las etapas de diseo e implementacin del desarrollo de software. La ingeniera dirigida por modelo se interesa por todos los aspectos del proceso de la ingeniera de software. La ingeniera basada en modelo aun esta en etapa de desarrollo y no es claro saber si tendr o no un efecto significativo sobre la practica de ingeniera de software.

Los principales argumentos a favor y en contra de la ingeniera dirigida por modelo son:

EN FAVOR:
Permite a los ingenieros pensar sobre sistemas en un nivel de abstraccin elevado, sin ocuparse por los detalles de su implementacin Esto reduce la probabilidad de errores, acelera el diseo y el proceso de implementacin y permite la creacin de modelos de aplicacin reutilizables, e independientes de la plataforma de aplicacin. Con solo escribir el traductor el sistema se puede adaptar a alguna nueva plataforma tecnolgica a partir del mismo modelo.

EN CONTRA:

Aunque los modelos son una buena forma hacer el diseo de software el problema esta que no siempre se siguen las abstracciones correctas que soporta el modelo para la implementacin, creando modelos de diseo informal. Los argumentos para independencia de plataforma solo son validos para sistemas grandes de larga duracin, donde las plataformas se vuelven obsoletas durante el tiempo. Pero la implementacin no es el principal problema, el problema es la seguridad, la confiabilidad, la integracin con sistemas heredados y las pruebas.

Arquitectura dirigida por modelo

Es un enfoque orientado a modelos para el diseo y la implementacin de software, que usa un subconjunto de modelos UML para describir un sistema. Se crean modelos a diferentes niveles de abstraccin. A partir de un modelo independiente de plataforma de alto nivel, es posible, en principio, generar un programa funcional sin intervencin manual.

El mtodo MDA recomienda la produccin de tres tipos de modelos de sistema abstracto:

1. CIM (Modelo independiente de computacin) Modela las importantes abstracciones de dominio usadas en el sistema.

2. PIM (Modelo independiente de plataforma) Modela la operacin del sistema sin referencia a su implementacin. 3. PSM (Modelos especficos de plataforma) Son transformaciones del modelo independiente de plataforma con un PSM separado para cada plataforma de aplicacin.

33

Los CIM se relacionan, y parte del proceso de traduccin puede involucrar conceptos de vinculacin en diferentes CIM. La traduccin de PIM a PSM es mas madura y se dispone de varias herramientas comerciales que proporcionan traductores de PIM a plataformas comunes como Java y J2EE. Estas se apoyan en una extensa librera de reglas y patrones especficos de plataforma para convertir el PIM al PSM. Puede haber muchos PSM para cada PIM en el sistema.

34

Si se tiene la intencin de que un sistema de software funcione en diferentes plataformas (por ejemplo J2EE y .NET) entonces solo es necesario mantener el PIM. Los PSM para cada plataforma se generan automticamente.
Traductor J2EE

35

Modelo especifico J2EE

Generado r de cdigo

Programa Java

Modelo independien te de plataforma

Traductor .NET

Modelo especifico .NET

Generado r cdigo #C

Programa #C

Figura 5.20 Mltiples modelos especficos de plataforma

Aunque las herramientas de soporte MDA incluyen traductores especficos de plataforma, es frecuente el caso de que solo ofrezcan soporte parcial para la traduccin PIM a PSM.

Tambin incluye otros sistemas de aplicacin, libreras de aplicacin que son especificas a una compaa y libreras de interfaz de usuario. Como estas varan significativamente de una compaa a otra, no esta disponible un soporte estndar para herramientas.

36

En algunos casos (por ejemplo, para generacin de interfaz del usuario), la traduccin de PIM a PSM completamente automatizada es imposible.

Si las transformaciones pueden automatizarse completamente y a partir de un PIM se genera un programa completo, entonces, en principio, MDA podra usarse en un proceso de desarrollo gil, ya que no se requerira codificacin separada.

37

38

 UML

Ejecutable

La nocin fundamental detrs de la ingeniera dirigida por modelo es que debe ser posible la transformacin completamente automatizada de modelos a cdigo. Para lograr esto se tiene que ser capaz de construir modelos grficos, cuya semntica este bien definida. Tambin se necesita una forma de agregar a los modelos grficos, informacin sobre la forma en que se implementan las operaciones definidas en el modelo. Esto es posible usando un subconjunto de UML 2 llamado UML ejecutable o xUML. El UML se desarrollo como un lenguaje para soportar y documentar diseo de software, no como un lenguaje de programacin.
39

 Por

ende, para crear un subconjunto ejecutable de UML, el numero de tipos de modelo se redujo drsticamente a tres tipos de modelo clave: 1. Modelos de dominio que identifican las principales preocupaciones en el sistema. Se definen usando diagramas de clase UML que incluyen objetos, atributos y asociaciones.

2.

Modelos de clase, en los que se definen clases, junto con sus atributos y sus operaciones. Modelos de estado, en los que un diagrama de estado se asocia con cada clase y se usa para describir el ciclo de vida de la clase.
40

3.

Fuente de informacin:

Ingeniera del Software 9na edicin. Ian Sommerville. Pearson.

41