Uml --components simple specification

Componentes con UMLUna forma simple de especificar software basado en

componentes

M.I. Capel

ETS Ingenierías Informática yTelecomunicación

Departamento de Lenguajes y Sistemas InformáticosUniversidad de Granada

Email: [email protected]

DSBCSMáster Universitario en Ingeniería Informática

21 de octubre de 2015

Especificación de componentesProceso de creación del Modelo de Información de Interfaz

Proceso de creación del MII de SistemaTécnicas de Factorización

Índice

1 Especificación de componentes

2 Proceso de creación del Modelo de Información de Interfaz

3 Proceso de creación del MII de Sistema

4 Técnicas de Factorización

M.I.Capel Desarrollo de Software Basado en Componentes y Servicios 2/ 40



Índice








Especificación de SBCs

Contratos en Sistemas Basados en ComponentesContrato de utilizaciónContrato de realización

Especificación de una interfazDeterminar qué partes la componen y describirlas sinambigüedad.

Especificación de un componenteSe trata fundamentalmente de agrupar las interfaces queimplementará e indicar las restricciones que afectan a larealización del propio componente.




Interfaces provistas

Una interfaz de este tipo cumple:Es implementada por el propio componente oEs implementada por uno de los objetos del componente oEs ofrecida por un puerto del componente

Figura: El componente Servicios Meteorológicos implementa la interfaz Pronóstico Tiempo




Interfaces requeridas

Una interfaz de este tipo cumple:Es una dependencia de uso del propio componenteEs una dependencia de uso de uno de los objetos delcomponenteEs necesitada por un puerto público del componente

Figura: El componente Servicios Usuario requiere la interfaz ServiciosIOrder




Proceso de Especificación de Interfaces

Figura: Especificación de un componente dentro del flujo de trabajos completo en esta etapa




Especificación de interfaces vs. operaciones

Especificación de operaciones de componentesCarecen de cualquier información estructural acerca de uncomponenteNivel de descripción inadecuado respecto de la gestión dedependencias

Especificación de interfaces de componentesAgrupación de operaciones relacionadasDicha agrupación es revisitada en la tarea de factorizaciónIntroducción de subtipado en las interfacesPueden incluir sólo 1 operación autocontenida y nodependiente




Especificación de operaciones

¿Qué tiene que incluir y qué no la especificación de unaoperación?

Descripción de la relación entre las entradas, salidas y elestado del objeto componenteEl efecto que tiene la llamada sobre la anterior relación

¿Qué tiene que garantizar?Transparencia de las relaciones del objeto componentecon otros




Especificación de operaciones IIElementos de la especificación:

Los parámetros de entrada y salidaLas restricciones que sean de aplicaciónCualquier cambio de estado resultante en el componente

Figura: Efecto de la operación IHotelMgt::makeReservation() en parte del estado del componente




Especificación de interfaces I

Características del modelo:Suficiente para permitir la especificación de lasoperaciones de la interfazAsí como restricciones y efectos sobre el estado delcomponenteDescripción de cambios del estado como resultado de lasoperacionesSe construirá incrementalmente conforme se elabora laespecificación de las operaciones especificaciones de lasoperaciones, añadiendo tipos, atributos, etc.




Especificación de interfaces II

Condiciones que respetará el modelo de especificación:Las interfaces sólo son asociadas a información tipadaSólo contendrán información del conjunto de estadospropios de ese componenteNunca pueden dar información sobre implementaciónestado del componenteTampoco sobre su persistencia




Modelo de Especificación de Interfaz

Representación del estado del objeto componente del quedepende la interfaz

Necesidad de un Modelo de Información de Interfaz (MII)

Figura: Diagrama previo al modelo de especificación de la interfaz ICustomerMgt




Modelo de Información de Interfaz (MII)

Discusión del ejemplo ICustomerMgt

Customer es una Información con TipoLos tipos de una interfaz no pueden mantenerasociaciones con nada fuera del modelo

Ubicación en el mismo paquete que la interfazSalvo subtipos heredados entre interfaces, los tipos no secomparten pero se pueden importar

Figura: Ejemplo de herencia de tipos después de una factorización de interfaces




Pre y postcondicionesCada operación posee una pre y poscondición asociada,que especifican con detalle qué hará la operaciónNo proporcionan información algorítmica o deimplementaciónActúan como la letra pequeña de un contrato con el clientePrecondición: la condición que garantiza que la ejecuciónde la operación hará cierta la poscondiciónLa llamada de la operación aludida es totalmenteindependiente del valor de certeza de su precondiciónCualquier suposición respecto de la ejecución de lasoperaciones es responsabilidad del clienteLas garantías contractuales (poscondición) sonresponsabilidad del proveedor de la operación




OCL

DefiniciónObject Constraint Language es un lenguaje declarativo quepermite construir expresiones lógicas y sirve, por ejemplo, paraespecificar condiciones contractuales en la especificación deinterfaces de componentes software

Expresiones OCL de pre y poscondiciones semánticamentecorrectas

Se pueden referir a los parámetros, resultado de lasoperaciones y al estado del objeto componenteNo se pueden referir a elementos de otras interfacesLa especificación de interfaces sólo afectan localmente




Expresiones con OCL

Especificación OCL de operación de cambio de nombre

1 contex t ICustomerMgt : : changeCustomerName ( i n cus : CustId , i nnewName: S t r i n g )

2

3 pre :4 −−cus es un i d e n t i f i c a d o r v a l i d o de c l i e n t e5 customer−>e x i s t s ( c | c . i d = cus )6 post :7 −−e l nombre de l c l i e n t e cuyo i d e n t i f i c a d o r es ’ cus ’ se

conv ie r te en ’newName ’8 customer−>e x i s t s ( c | c . i d = cus and c . name = newName)

’customer’ se refiere al conjunto de clientes asociados a unobjeto-componente de soporte: ICustomerMgt




Expresiones con OCL (II)Especificación de operación para obtener detalles de un cliente

1 contex t ICustomerMgt : : getCustomerDetai ls ( i n cus : CustId ) :CustomerDetai ls

2 pre : −−cus es un i d e n t i f i c a d o r v a l i d o de c l i e n t e3 customer−>e x i s t s ( c | c . i d = cus )4 post : −−l os d e t a l l e s devuel tos t r a s l a e jecuc ion co inc iden con

del c l i e n t e cuyo i d e n t i f i c a d o r es ’ cus ’5 −−encont rar a l c l i e n t e6 Let e l C l i e n t e = customer−>s e l e c t ( c | c . i d = cus ) i n7 −−e s p e c i f i c a r e l resu l tado8 r e s u l t . nombre= e l C l i e n t e . nombre and9 r e s u l t . cod igoPosta l = e l C l i e n t e . cod igoPosta l and

10 r e s u l t . emai l = e l C l i e n t e . emai l11 −−l a devoluc ion es i m p l i c i t a con l a as ignac ion de l a v a r i a b l e

’ r e s u l t ’ ; no hay cambio de estado de l componente

Esta operación no cambia el estado del objeto que la realiza: laposcondición sólo especifica el resultado a devolver.




OCL (II)

Condiciones en poscondicionesLas expresiones de poscondición pueden referirse tanto alestado antes de la ejecución de la operación (@pre deOCL ) como a su estado posteriorPermiten escribir expresiones que especifican cómocambian los atributos o las asociaciones en el MII comoresultado de la ejecución de una operación




Creación del Modelo de Información de una Interfaz

Generalidades del MII de reservas en hotelesLa interfaz IHotelMgt se preocupa de organizar reservasen hoteles asignando habitacionesICustomerMgt se preocupa de gestionar los clientesTipos que son responsabilidad de IHotelMgt:

HotelRoomTypeRoomReservation

Tipos que son responsabilidad de ICustomerMgt:Customer




Creación del Modelo de Información de una Interfaz II

Figura: Diagrama de Responsabilidades de la Interfaz IHotelMgt




Creación del Modelo de Información de una Interfaz III

Adaptaciones en el DRI para obtener el MIILos tipos: Hotel, RoomType y Reservation han deincluirse en el MII de IHotelMgt

La asociación entre reservas y clientes no tiene por quéintegrarse en el MIIPueden transformarse las asociaciones en el DRI:

Inclusión de asociación directa: IHotelMgt ->ReservationDe asociación derivada a directa: Hotel->Reservation

Se pueden eliminar asociaciones del DRI:Asociación derivada Hotel -> RoomType

Se pueden añadir atributos: atributo claimed aReservation




Creación del Modelo de Información de una Interfaz IV

Figura: Diagrama de Especificación de Interfaz de IHotelMgt




Creación del Modelo de Información de una Interfaz VInvariantes

Invariante: restricción asociada a un tipo que debemantenerse cierta para todas las instancias del mismoLos invariantes pueden expresarse gráficamente con UMLLos invariantes se pueden escribir con expresiones OCL:

1 contex t r : Reservat ion inv :2 −−una reserva esta conf irmada ( claimed ) s i t i ene ya una

hab i tac ion asignada3 r . c laimed = r . a l l o c a t i o n −>noEmpty

A partir de la definición anterior se podría utilizar “claimed”como forma abreviada de la relaciónUn invariante conecta diferentes partes de la informacióncontenida en una especificación




Especificación de operaciones con OCL

Ejercicio propuestoEspecificar completamente la operaciónIHotelMgt::makeReservation (...) con OCL;utilizando los operadores: exists, select yasSequence->first




Especificación de Interfaces del Sistema

Interfaces del SistemaEl Modelo de Información de una Interfaz de Sistema(MIIS) es un subconjunto del modelo del tipo de negocioEste modelo de interfaz pretende agrupar las funcionesque realiza el sistema sin asistencia, automáticamenteDiferencias respecto de la elaboración de los MII denegocio:

MIIS no tiene porqué contener todos los tipos del modelode negocioLa elaboración de diagramas de especificación deresponsabilidades no proporciona tanta información comolo hacen en el caso de la elaboración del MIINo se tenga claro todos tipos del modelo de negocio quehay que incluir hasta la programación de las operaciones




Modelos de Información de Interfaces del Sistema

Figura: Diagrama de Especificación de Interfaz de Sistema IMakeReservation

Este modelo no necesita el atributo number de la clase Roomdel MII de negocio




Modelos de Información Interfaces Sistema II

Figura: Diagrama de Especificación de Interfaz de Sistema ITakeUpReservation

Necesita ahora el atributo number de la clase Room

No necesita ni el atributo name de Hotel ni available(during) de RoomType




Especificación de componentes

Diferencias con la especificación de otras interfacesLas interfaces MII de negocio y MIIS se refieren al contratode utilizaciónAhora nos preocuparemos más por el contrato derealizaciónLos más importante es describir las dependencias entreun componente y otras interfacesIncluye las restricciones de realización y combinación decomponentes




Especificación de componentes II

Figura: Diagrama de Especificación de Componente de HotelMgr

El componente debe ofrecer la interfaz IHotelMgt y no se leimpide utilizar otras interfaces




Especificación de componentes III

Figura: Diagrama de Especificación de Componente de HotelMgr

El componente debe ofrecer 2 interfaces de sistema y hade utilizar 3 interfaces de negocio adicionalesNo dice cómo van a utilizarse estas interfaces en lasimplementaciones del componente




Especificación de componentes IV

Figura: Diagrama de Especificación de Componente de ReservationSystem

Todas las implementaciones del componente debe utilizarlos mismos objetos que ofrecen cada una de las interfacesRestricción frozen: siempre los mismos objetos a lo largode todo el tiempo de vida del objeto-componente




Restriciones entre interfaces

Completar las especificaciones de los componentes¿Cómo se relacionan entre sí las interfaces provistas porun componente?¿Cómo se relacionan con las interfaces requeridas en elcomponente?




Interfaces provistas

Restricciones que aplican sobre estas interfacesSe pretende dejar claro que los tipos del mismo nombreofrecidos en 2 ó más interfaces se refieren al mismo concepto

1 contex t ReservationSystem2 −−r e s t r i c c i o n e s ent re i n t e r f a c e s p r o v i s t a s3 IMakeReservation : : ho te l = ITakeUpReservation : : ho te l4 IMakeReservation : : r ese rva t i on = ITakeUpReservation : : r ese rva t i on5 IMakeReservation : : customer = ITakeUpReservation : : customer

Las instancias del tipo del MII IMakeReservation sonlógicamente las mismas (= ) que las instancias del MIIITakeUpReservation




Interfaces provistas y requeridas

Relaciones entre todas las interfacesLas implementaciones de las interfaces provistas obtienenla información que necesitan de los componentes denegocio: no reimplementan tipos comunesTampoco hay que especificar los protocolos de mensajesque se establecen entre una interfaz provista y lasinterfaces requeridasDescribir sólo las restricciones en OCL que hacen que losmodelos de información de todas las interfaces casen

1 contex t ReservationSystem2 −−r e s t r i c c i o n e s ent re i n t e r f a c e s p r o v i s t a s y requer idas3 IMakeReservation : : ho te l = IHote lMgt : : ho te l4 IMakeReservation : : r ese rva t i on = IHote lMgt : : r ese rva t i on5 IMakeReservation : : customer = ICustomerMgt : : customer




Factorización de interfaces

MotivaciónCada interfaz ha de tener un modelo de información diferente,pero a veces sólo difieren en pequeños cambios; porconsiguiente, se produce mucha redundancia.

PasosIntroducir interfaces abstractas nuevas que actúen comosuper tipos de otras interfaces que compartan informaciónLa interfaz abstracta mantiene los elementos coincidentesde varios MIIs y también operaciones comunesPuede ser indicado cuando los modelos de casos de usode los que proceden las interfaces comparten actores




Factorización de interfaces II

Ejercicio propuesto1) Factorizar los elementos comunes de los modelos deinformación de las interfaces IMakeReservation yITakeUpReservation y ubicarlos en una nueva interfazIReservationSystem de las que las 2 interfaces aludidasheredan.2) Elaborar los diagramas de clases de las interfacesIReservationSystem y rehacer el de IMakeReservation




Bibliografía Fundamental

Cheesman, J. and Daniels, J. (2001).UML Components: A Simple Process for SpecifyingComponent–based Software.Component Software Serirs. Addison-Wesley, first edition.

Eden, A., Hirshfeld, Y., and Kazman, R. (2006).Abstraction classes in software design.IEE Software, 153(4):163–182.

Exposito, D. and Saltarello, A. (2009).Architecting Microsoft .NET solutions for the enterprise.Microsoft Press, Redmond, Washington.

Szyperski, C. (1998).Component Software. Beyond Object-Oriented Programming.Addison–Wesley, Básica.


Uml --components simple specification

Engineering

Transcript of Uml --components simple specification