Modelado de Sistemas Software

56
Modelado de sistemas software: Introducción Fuentes: Bran Selic, ICSE’03 UML2.0 Tutorial y número especial sobre MDD, IEEE Software, September 2003, pag. 19-25

description

un poco de uml

Transcript of Modelado de Sistemas Software

  • Modelado de sistemas software: IntroduccinFuentes: Bran Selic, ICSE03 UML2.0 Tutorial y nmero especial sobre MDD, IEEE Software, September 2003, pag. 19-25

  • Modelado de ...Sistemas...Sistemas webSistemas de control/tiempo realFamilias de sistemasVariabilidadPatrones de alto nivelRestriccionesRequisitosProcesos...Modelos ejecutables?

  • La importancia de los modelos

  • Modelos de ingenieraModelo de ingeniera:Representacin reducida de un sistema Propsito: Ayudar a comprender un problema complejo (o solucin) Comunicar ideas acerca de un problema o solucin Guiar la implementacin

  • Caractersticas de los modelosAbstractoEnfatiza los elementos importantes y oculta los irrelevantes ComprensibleFcil de comprender por los observadoresPrecisoRepresenta de forma fiel el sistema que modelaPredictivoSe pueden usar para deducir conclusiones sobre el sistema que modelaBaratoMucho ms barato y sencillo de construir que el sistema que modelaLos modelos de ingeniera eficaces deben satisfacer todas estas caractersticas

  • Cmo se usanPara detectar errores u omisiones en el diseo antes de comprometer recursos para la implementacinAnalizar y experimentar Investigar y comparar soluciones alternativas Minimizar riesgosPara comunicarse con los stakeholdersClientes, usuarios, implementadores, encargados de pruebas, documentadores, etc.Para guiar la implementacin

  • Desarrollo guiado por modelos (Model-Driven development o MDD)Una aproximacin al desarrollo de software en el que el enfoque y los artefactos fundamentales son modelos (y no programas) Implica la generacin automtica de programas a partir de modelosUtilizando lenguajes de modelado directamente como herramientas de implementacin

    El modelo es la implementacin

  • Lo esencial en MDDEn MDD el enfoque y los artefactos fundamentales son modelos (y no programas) La mayor ventaja es que los conceptos de modelado estn mucho menos ligados a la tecnologa de implementacin y ms cerca del dominio del problema Los modelos son ms fciles de especificar, comprender y mantener

  • Tecnologa Se generan automticamente programas completos a partir de modelos (y no slo esqueletos o fragmentos de cdigo )Se verifican automticamente modelos en una computadora(por ejemplo, ejecutndolos)

  • Estndares: Model-Driven ArchitectureIniciativa MDA de OMGEs un marco para definir estndares:MOFUMLXMLSOAPSPEMRAS....

  • La prctica Modelos ObservablesEs necesario que las herramientas nos den informacin sobre errores, al igual que lo hacen los compiladores (o los depuradores)

  • ...La prctica Modelos ejecutablesEl hola_mundo Debe ser posible trabajar con modelos incompletos (pero bien formados)Eficiencia del sistema generado15 % de diferencia con las herramientas actuales

  • ...La prcticaEscalabilidadGrandes sistemas:Tiempo de generacin/compilacin del sistemaTiempo de generacin/compilacin de cada incrementoEn realidad el tiempo de generacin representa un 10 %Integracin con sistemas legados

  • Modelado y lenguajes

  • Lenguajes para MDA/MDD

  • Evolucin de UMLUML 1.3Abril 1999:septiembre de 2001 UML 1.4UML 1.5

  • Crticas a UML 1.Xexcesivo tamao,complejidad gratuita, semntica imprecisa, personalizacin limitada, Soporte inadecuado para desarrollos basados en componentes, implementaciones no estndarfalta de soporte para intercambio de diagramas.

  • Qu ha ido mal en UML 1.XDoes not fully exploit MDD potential of models, E.g., C++ in picturesInadequate modeling capabilitiesBusiness and similar processes modelingLarge-scale systemsNon-functional aspects (quality of service specifications)Too complexToo many conceptsOverlapping conceptsInadequate semantics definitionVague or missing (e.g., inheritance, dynamic semantics)Informal definition (not suitable for code generation or executable models)No diagram interchange capabilityNot fully aligned with MOFLeads to model interchange problems (XMI)

  • Requisitos para UML 2.0Requisitos de la infraestructura: se refieren a la arquitectura, reestructuracin y mecanismos de extensin. Indican cmo UML 2.0 es definido y estructurado como un metamodelo.Requisitos de la superestructura: se refieren al refinamiento y extensin de la notacin y la semntica de UML 1.x.Requisitos generales: afectan tanto a los cambios en la infraestructura como a los de la superestructura.

  • Qu se le pide a UML 2.0Se ha dividido la peticin en varios RPF (peticiones de propuestas)

  • UML 2.0 RPF "UML 2.0 Infrastructure RFP". Documento OMG ad/2000-09-01.UML internobase conceptual precisa para soporte de MDA

    "UML 2.0 Superstructure RFP". Documento OMG ad/2000-09-02.Caractersticas para el usuarioCapacidades nuevas para sistemas grandesConsolidacin

  • ...UML 2.0 RPF "UML 2.0 OCL RPF". Documento OMG ad/2000-09-03.Lenguaje de restricciones Alineamiento con UML

    "UML 2.0 Diagram Interchange RFP". Documento OMG ad/2001-02-39.Estndar de intercambio de diagramasIncluye informacin grfica

  • UML 2.0 Infrastructure RFPSolicitaba propuestas que mejorasen las bases arquitectnicas de UML, incluyendo su ncleo y sus mecanismos de extensin:- Mejorar la alineacin arquitectnica con otros estndares de modelado del OMG, como MOF (Meta Object Facility) y XMI (XML Metadata Interchange).- Reestructurar la arquitectura del lenguaje, para que fuera ms sencillo de entender, implementar y extender, manteniendo la semntica que ya haba sido contrastada.- Proporcionar perfiles y mecanismos de extensin de primera clase (metaclases) que fueran consistentes con la arquitectura del metamodelo.

  • UML 2.0 Superstructure RFPSolicitaba propuestas que actualizasen y mejorasen el soporte que UML proporciona al desarrollo del software, en reas tales como desarrollo basado en componentes, modelado de procesos de negocios, modelado arquitectnico modelos ejecutables Requera la revisin de ciertos aspectos estructurales y de comportamiento.

  • Componentes y arquitecturaMejorar el soporte para desarrollos basados en componentes. Era necesario demostrar que se podan especificar contenedores de ejecucin y perfiles para las principales arquitecturas de componentes, como EJB y COM+Aumentar el soporte para arquitecturas de tiempo de ejecucin (comparar modelos ejecutables) incluyendo la especificacin de estructuras jerrquicas y comportamientos dinmicos.

  • Revisin de ciertos aspectos...Refinar la semntica de las relaciones, incluyendo generalizacin, asociacin y dependencia.Mejorar el encapsulamiento y la escalabilidad en los modelos de comportamiento, especialmente en los diagramas de estado y en los diagramas de interaccin.Refinar la semntica grfica de las actividades, centrndose en la gestin de eventos y el flujo de control y de objetos.

  • UML 2.0 OCL RFPSolicitaba propuestas que definiesen un metamodelo de Lenguaje de Restricciones de Objetos (OCL) acorde al metamodelo de UML. Esto incrementara la precisin y consistencia de las implementaciones OCL y facilitara el intercambio de constructores OCL entre distintas herramientas. Aunque se la Infraestructura como la Superestructura utilizan OCL para especificar sus reglas, ninguno de sus respectivos RFP dependen de ste.

  • UML 2.0 Diagram Interchange RFPSolicitaba propuestas que definieran un metamodelo para el intercambio de elementos de diagramas entre herramientas UML. Este metamodelo necesitara soportar el intercambio de caractersticas tales como la posicin de los elementos, el agrupamiento de elementos, la alineacin de elementos, las configuraciones de las fuentes, los caracteres y los colores.

  • Facilidad Meta-Objetos (MOF)MOF, Meta-Object Facility es un lenguaje para definir lenguajes de modeladoPermite a los usuarios definir totalmente nuevos lenguajes a partir de metamodelosFue tambin definido por el OMG y actualmente se encuentra en su versin 2.0La alineacin del metamodelo UML 2.0 con el metamodelo MOF simplificar el intercambio de modelos va XMI y la interoperabilidad cruzada entre herramientas. La especificacin del ncleo unificado MOF 2.0 debe estar arquitectnicamente alineada con la Infraestructura de UML

  • Arquitectura de Lenguajes de ModeladoMOF define una Arquitectura de Lenguajes de Modelado en la que existen 4 capas o niveles: Nivel M3: MOF. Nivel M2: UML. Nivel M1: Modelo del usuario. Nivel M0: Instancias en tiempo de ejecucin.

  • Arquitectura de UML/MOF

  • Situacin actual: finalizacinUML 2.0 Infrastructure RFP: adoptado en agosto de 2003 la especificacin final UML 2.0 Superstructure RFP: adoptada en agosto de 2003 la especificacin finalUML 2.0 OCL RFP: adoptado en agosto de 2003 el borrador de la especificacin, UML 2.0 Diagram Interchange RFP: adoptado en julio de 2003 el borrador de la especificacin, Se aprob en agosto de 2005

  • Infraestructuraa) Alineacin arquitectnica y reestructuracinb) Extensibilidad

  • a) Alineacin arquitectnica y reestructuracinAunque el metamodelo UML 1.x era compatible con el metamodelo MOF, no se cea estrictamente al patrn de metamodelo de 4 niveles, en el que cada metamodelo es una instancia de slo un meta-metamodeloEn UML 2.0 el metamodelo UML est perfectamente alineado con el metamodelo MOFAdems, el ncleo de UML y el ncleo de MOF deben compartir los mismos elementos de metamodelo,

  • UML 2.0 y MOF 2.0

  • b) ExtensibilidadLos perfiles UML incorporan mecanismos de extensin (estereotipos, valores etiquetados y restricciones) que permiten personalizarlo para distintas aplicaciones y tecnologas. En el OMG se est trabajando con ellos, algunos ya han sido adoptados y otros estn en proceso de adopcin. Por ejemplo existen perfiles para: CORBA IDL, Modelo de Componentes CORBA (CCM), Computacin de Empresa de Objetos Distribuidos (EDOC).Se ha incluido un mecanismo de extensibilidad de primera clase, que permite a los desarrolladores definir y aadir sus propias metaclases (que sern instancias de las meta-metaclases MOF), dando as soporte a la "familia de lenguajes basada en UML.

  • SuperestructuraPensada para el modelado arquitectnicoObjetos con estructura externa e interna (objetos arquitectnicos)Modelado de sistemas complejosLa estructura deseada es declarada (asserted) ms que construidaConstructor de clase crea la estructura deseada automticamenteEl destructor de la clase hace la limpieza automticamenteExpresividad, fiabilidad y productividadBasado en lenguajes de descripcin arquitectnica (ADLs) UML-RT profile: Selic and Rumbaugh (1998) ACME: Garlan et al. SDL (ITU-T standard Z.100)

  • Nuevos elementosClases estructuradasPuertosProtocolosComponentes...

  • Clases estructuradas

  • Puertos

  • Protocolos

  • Componentes

  • Sumario de UML 2.0First major revision of UMLOriginal standard had to be adjusted to deal with MDD requirements (precision, code generation, executability)UML 2.0:Small number of new features + consolidation of existing onesScaleable to large software systems (architectural modelingModular structure for easier adoption (core + optional)Increased semantic precision and conceptual claritySuitable foundation for MDA (executable models, full code generation)

  • Arquitectura de UML/MOF

  • Descripcin de los objetos en trminos de sus propiedades y de sus relacionesIdea bsica: describir un grupo de objetos similares en trminos de clases, que son instanciadas para crear objetos individualesLos objetos se relacionan con las clases de las que son creados por la relacin SerInstanciaDe (IsInstanceOf)Modelado de objetos

  • Una situacin parecida ocurre con las relaciones. Una clase define los tipos de relaciones que sus instancias pueden tener con instancias de otras clases...Modelado de objetos

  • Metamodelado...Se basa en la idea de reificar las entidades que forman un cierto tipo de modelo y describir las propiedades comunes del tipo de modelo en forma de un modelo de objetosCuando se ve la clase como un objeto, la clase es una instancia de otra clase

  • Metamodelado...Las clases pueden participar en relaciones con otros objetos

  • ...MetamodeladoLa idea fundamental en el metamodelado es que las entidades del modelo (clases) juegan dos papeles: el papel de plantilla (cuando se ve como una clase) y el papel de instancia (cuando se ve como objeto

  • La idea de ver las clases como objetos puede ser aplicada repetidamente para crear una jerarqua de instanciacin del clases y objetos

    En principio est jerarqua podra continuar hasta cualquier profundidad arbitraria, pero en la prctica no se extiende ms all de cuatro niveles de profundidadTerminologa de metamodelado...

  • Si la jerarqua tiene una profundidad fijada, se puede utilizar un esquema de nombres para describir el nivel en que reside una entidad dada en la jerarqua de instanciacinTerminologa de metamodelado...

  • ...Terminologa de metamodelado

    *******************************Figura de [Rivas et al., 1997]

    Los conceptos utilizandos durante el modelado son varios, que potencialmente pueden provenir de diferentes disciplinas, pero cuando se modela, se quiere crear un modelo de un sistema, en lugar de muchas piezas que no est muy claro como relacionarlas. Para conseguir integrar modelos, el metamodelo subyacente debe estar integrado a travs de las disciplinas tambin.Un ejemplo simple: considrese el concepto de un requisito. Independientemente de que se est haciendo un diseo estructurado, OO o hardware, es el mismo concepto. Un metamodelo integrado permitir representar los mismo conceptos a travs de dominios diferentes utiilizando los mismos metaobjetos, una coleccin de fragmentos de metamodelos no integrados requerirn un esfuerzo adicional del vendedor de herramientas para integrar lo que el metamodelo no hace [Metamodel, 1997]*****************Figura de [Rivas et al., 1997]

    Los conceptos utilizandos durante el modelado son varios, que potencialmente pueden provenir de diferentes disciplinas, pero cuando se modela, se quiere crear un modelo de un sistema, en lugar de muchas piezas que no est muy claro como relacionarlas. Para conseguir integrar modelos, el metamodelo subyacente debe estar integrado a travs de las disciplinas tambin.Un ejemplo simple: considrese el concepto de un requisito. Independientemente de que se est haciendo un diseo estructurado, OO o hardware, es el mismo concepto. Un metamodelo integrado permitir representar los mismo conceptos a travs de dominios diferentes utiilizando los mismos metaobjetos, una coleccin de fragmentos de metamodelos no integrados requerirn un esfuerzo adicional del vendedor de herramientas para integrar lo que el metamodelo no hace [Metamodel, 1997]*(1b) El conjunto de objetos instanciados de las clases tienen todos las mismas propiedades y las relaciones definidas en la clase

    En este ejemplo, City es una clase y Houston es un objeto generado de City. En otras palabras, Houston es una instancia de City. Ntese que City, en su papel como plantillas de objetos, define los tipos de atributos que sus instancias pueden tener. Houston, como objeto generado de City, tiene valores especficos para estos atributos.

    *A similar situation occurs with relationships. A class defines the kinds of relationships which its instance may enter into with instances of other classes. Thus, extending the above example, a given city my have an IsIn relationship with a country. For example, Houston IsIn the USA.In its role as a template, the class City defines the kinds of relationships which its instances can enter into with instances of other classes. Thus in the above example, IsIn between City and Country is a template for IsIn relationships between instances of City and County (such as Houston and the USA). Relationships are often shown diagramatically as lines connecting classes, as illustrated above.However, it is also possible to represent them textually. To do so it is necessary to give the names of the related entities as well as the relationship name. Thus Houston.IsIn.USA is the full name of the relationship depicted on the right hand side of the above drawing, and City.IsIn.Country is the name of the relationship template shown on the left hand side. To reiterate, a class represents a template from which multiple object may be instantiated. These objects are related to the class by the IsInstanceOf relationship. A class also defines attribute templates and relationships templates which its instances may have instances of. These attributes and relationships may also be viewed as defining a membership test for belonging to the set of instances of the class. One common source of confusion in object modeling is that the term attribute is often used to refer both to attribute templates at the class level (eg. Pop) and attribute instances at the object level (e.g. Pop = 2M) . Thus, it would not be uncommon to use a phrase of the kind City has attributes Pop and Area and also Houston has attributes Pop and Area. A similar situation applies to the term relationship. This is frequently used loosely to mean both relationships templates and relationship instances. In other words, in current modeling methods relationships and attributes are rarely distinguished explicitly from relationship templates and attribute templates. This can be a major source of confusion when extending object modeling to meta-modeling.

    *(1a) Ver las entidades de ese nivel como si fueran objetos

    When viewed as an object, a class itself becomes an instance of another class. Thus, in the diagram fragment below, class City is an instance of the class, Class, which defines an attribute (template), NoOfInstances. Since it is an instance of the class, Class, City has a value for its instance of the attribute NoOfInstances, in this case 1.

    *As with regular objects, City can participate in relationships with other objects. The example below indicates that City is stored in a file, called CityFile, which has a size attribute with a value of 4 Kb. Naturally, the kind of attributes and relationships which City can have are defined by its class, Class.Notice that the attributes and relationships of City (when viewed as objects), are not passed on to (i.e. have no effect on) its instances (when it plays the role of a class). Thus, Houston, an instance of City, does not have (instances of) the attribute NoOfInstances or the relationship Stores. This is impossible, since NoOfInstances and Store are not templates, but actual attribute and relationship instances.*Por lo tanto, una descripcin completa de tales entidades deberan tener dos dimensiones como se ilustra en la figura.

    A full description of a class such as City, therefore involves four elements attribute values (eg. NoOfInstances = 1) relationship values (eg. CityFile.Stores.City) attribute templates (eg. Pop, Area) relationship templates (eg. City.IsIn.Country)

    **This is the approach adopted in this submission. As illustrated below, the label meta is used to describe entities defined at the third level in the instantiation hierarchy, and the label meta-meta to describe entities defined at the fourth level. All data entities at the bottom level are instances of artifacts at the model level, which in turn are instances of entitities at the meta model level and so on up the IsInstanceOf (or meta) hierarchy.This use of terminology differs from the situation with inheritance hierarchies in which relative terminology is used. Thus, when the term superclass is used, it means the immediate parent of a given class. It is rarely, if ever, used in an absolute sense to mean classes at the second level (from the bottom) of the inheritance hierarchy. Unfortunately, the term meta is sometimes also used to represent a relative IsInstanceOf relationship between two classes, but this submission uses the term meta exclusively in an absolute sense.*Notice that that the entities at the extremes of the hierarchy can only be viewed from one perspective. Objects, at the bottom of the hierarchy do not have a template perspective (since they cannot be instantiated), while meta-meta-classes at the top of the hierarchy do not have an object perspective (since they have not been instantiated). Only those class in the middle can be viewed from both perspectives. However, this submission borrows a neat trick from CDIF [EIA/IS-107] to side step this problem at the top end. The tick is to make the entities at the top of the meta hierachy instances of other entities at the same level, possibly even themselves.Although this has the flavor of creating something from thin air (like particles in the soup of quantum mechanics) it does neatly terminate the meta hiearchy.Note also that because of the absolute naming scheme an entity is said to have values for attributes from the next meta-level. Thus, a class has value for meta-attributes (eg. NoIfInstances = 1), and a meta-class has value for meta-meta-attributes (eg. Shape = rectangle).