Unified Modeling Language (OMG, 2003b)

Conforme (Rumbaugh et al., 2004), a Unified Modeling Language (UML) é uma linguagem padrão para projetar, visualizar, especificar, construir e documentar um Produto de Software (PS).

O escopo da linguagem UML é muito abrangente e diversificado, cobrindo vários domínios em aplicações bem diferentes. Nem sempre toda esta capacidade de modelagem é utilizada para todos os domínios. Baseado neste contexto, a UML é dividida em diversos módulos que, podem ser selecionados de acordo com necessidade de utilização da linguagem. Sendo assim, a UML v2 possui duas especificações que são complementares:

• Infrastructure (OMG, 2007b), define os alicerces estruturais.

• Superstructure (OMG, 2007c), define as estruturas necessárias para interação em nível de usuário.

Na definição da UML existe um vocabulário e regras específicas que aumentam a facilidade de comunicação. Isto foi feito por que a utilização de uma linguagem de modelagem é feita

para aumentar o entendimento sobre o sistema. No entanto, apenas um único modelo não foi suficiente para representar todo um sistema, sendo necessária a existência de vários modelos que estejam interconectados. Portanto, a UML permite a utilização de diferentes visões de um mesmo sistema.

A UML dispõe de contêineres de abstrações visualizáveis na forma de diagramas. Os di- agramas servem para representar um mesmo sistema ou software sobre diversas perspectivas. Para que isto seja possível, a UML dispõe de treze diferentes tipos de diagramas: Diagrama de Classes; Diagrama de Objetos; Diagrama de Componentes; Diagrama de Casos de Uso; Diagrama de Seqüência; Diagrama de Colaboração; Diagrama de Estados; Diagrama de Ati- vidades; Diagrama de Implantação; Diagrama de Pacotes; Diagrama de Tempo; Diagrama de Interação; e Diagrama de Estrutura.

Como em qualquer linguagem, a UML possui uma série de regras para especificar como deve ser um modelo bem formado (well-formed). Estes tipos de modelos precisam ser seman- ticamente auto-contidos e estar em harmonia com modelos relacionados. Tais regras são tanto sintáticas quanto semânticas a fim de definir:

• nomes, como devem ser os nomes das abstrações, dos relacionamentos e dos diagramas;

• escopo, o contexto em que estão os nomes, garantido sentido;

• visibilidade, como os nomes podem ser vistos e utilizados por outros;

• integridade, como as abstrações devem ser relacionadas;

• execução, execução ou simulação de um modelo dinâmico.

Além disso, para uma melhor organização e padronização, a UML possui quatro mecanis- mos que a fazem consistente:

• Specification, provê um pano de fundo que garante valor semântico para as construções feitas graficamente;

• Adornments, cada elemento da UML possui uma notação gráfica única, provendo repre- sentação visual;

• Common divisions, na modelagem de sistemas orientados a objetos, o mundo sempre é dividido em diferentes caminhos para se chegar a um mesmo destino;

• Extensibility mechanisms, para que a UML pudesse ser utilizada, representando um nú- mero maior de domínios específicos, foram definidos mecanismos de extensão:

– stereotypes, estende o vocabulário da UML, permitindo a criação de novos blocos

– tagged values, estende as propriedades de um stereotype, permitindo criar novas

informações;

– constraints, estende o valor semântico dos blocos de construção da UML, permi-

tindo a criação de novas regras ou a modificação de uma já existente.

Diante da possibilidade de restringir a UML para determinado domínio, foram criadas duas estratégias de extensão (OMG, 2003b). A primeira, conhecida como lightweight built-in exten-

sion, utiliza um mecanismo de extensão chamado profiles mechanism, baseando-se em stere- otypes e tagged values. Conforme especificado pela MDA, elementos de um modelo indepen-

dente de plataforma (platform specific model - PSM) são marcados com estereótipos capazes de transformá-lo em um modelo específico de plataforma (platform specific model - PSM) (OMG, 2003a). A segunda estratégia é chamada de heavyweight extensibility mechanism, sendo o seu principal objetivo estender a UML adicionando novas metaclasses e outros metaconstruto- res (OMG, 2006). A seguir estão descritas a duas especificações da UML: UML Infrastructure e UML Superstructure.

UML Infrastructure (OMG, 2007b)

O metamodelo da UML é uma representação de linguagem dividida em diversos módulos, os quais constróem o pacote UML Core, também denominado por Infrastructure Library. O principal objetivo deste pacote é ser reutilizado por diversos outros metamodelos como base para metamodelagem. Como podemos ver na Figura 2.9, além de outras abordagens, o próprio MOF utiliza este pacote para definir sua família de metamodelos.

<metamodel> UML <metamodel> Outro <Infrastructure> CORE <metamodel> MOF <metamodel> Profiles <<import>> <<import>> <<import>> <<import>>

Figura 2.9: Reutilização do pacote UML Core

No entanto, o excesso de flexibilidade acaba por permitir a incompatibilidade entre duas ferramentas para modelagem UML distintas, que suportarem diferentes subconjuntos da lin- guagem. Conseqüentemente, há algumas regras que exigem um balanço entre os módulos e a facilidade de troca de dados. Entretanto, como a flexibilidade precisa ser mantida, UML provê o conceito de language units.

Uma language unit consiste em uma coleção de conceitos de modelagem bem definidos que provêm o poder de representar aspectos de um sistema de acordo com um paradigma ou forma- lismo pré-determinado e escolhido. Isto significa que um usuário somente precisa conhecer o subconjunto que julgar necessário de acordo com os modelos que irá utilizar. Contudo, os gru- pos providos pelos language units e os incrementos que se constituem, servem para simplificar a definição das regras de conformidade (compliance rules) da UML.

Isto é, o conjunto de conceitos do modelo da UML é particionado em camadas horizontais, chamadas de níveis de conformidade (compliance levels). Cada ponto em que seja necessária alguma conformidade será chamado de ponto de complacência ou conformidade (compliance

point). Para facilitar a troca de modelos existem apenas dois níveis de conformidade definidos

para a UML Infrastructure:

• Nível 0 (L0). Este nível contém apenas uma language unit que provê os tipos de es- truturas (todas class-based) necessárias para modelar as linguagens OO mais populares. Portanto, existe um primeiro nível (nível de entrada) que permite a modelagem. Contudo, esta camada serve como base para a existência de interoperabilidade entre diferentes ca- tegorias de ferramentas para modelagem.

• Metamodel Constructs (LM). Este nível adiciona alguns language unit extras para obter estruturas (também class-based) mais avançadas. Estas estruturas são utilizadas para a criação de metamodelos, assim como da própria UML (utilizando CMOF).

Para que os níveis de conformidade sejam suportados, existem mecanismos que são uti- lizados a partir da especificação da UML. Estes mecanismos permitem que os conceitos de modelagem definidos em um nível determinado possam ser estendidos sem que percam suas características. Para que os mecanismos funcionem, é necessário que os níveis de conformi- dade estejam em um mesmo namespace. Por esta razão, todos os níveis de conformidade estão definidos como extensões do pacote core da UML. Este pacote define um namespace comum para todos os níveis de conformidades. O nível 0 (L0) é definido pelo metamodelo da Figura 2.10. PrimitiveTypes Basic L0 «import» <<merge>> <<merge>>

No modelo da Figura 2.10, UML é, originalmente, um pacote vazio que simplesmente es- tende (utilizado merge) o conteúdo do pacote Basic do UML Infrastructure. Este pacote possui os conceitos mais elementares tais como Class, Package, DataType, Operation.

No nível LM, o conteúdo do pacote UML (que inclue os pacotes e seus conteúdos mesclados do L0), mesclam (utilizam package merge) o pacote Constructs, Figura 2.11. Como pode ser visto, o nível LM não se mescla (merge) explicitamente com o pacote Basic, pois essse já esta incorporado no pacote Constructs.

PrimitiveTypes Basic LM «import» <<merge>> <<merge>> Construts

Figura 2.11: Diagrama de pacotes do LM. Adaptado de (OMG, 2007b)

Arquitetura da UML

Toda a especificação da UML é definida utilizando o metamodelo desenvolvido pela OMG. Este metamodelo ajusta, ou melhor, acomoda as especificações formais e técnicas da UML. Embora esta o metamodelo não apresente todas as formalidades da especificação rigorosamente, ele oferece vantagens por ser mais intuitivo.

A arquitetura da UML foi desenvolvida baseada em alguns princípios e padrões, sendo eles:

• Modularity - O princípio básico de alta coesão e baixo acoplamento. Este padrão é apli- cado ao se determinar grupos e separá-los em pacotes, agrupando as características em

metaclasses;

• Layering - Layering é aplicado no metamodelo da UML de duas formas:

1. A estrutura de pacotes é dividida em camadas, separando as principais construções do metamodelo das construções que as utilizam.

2. É aplicado um padrão de quatro camadas arquiteturais do metamodelo a fim de separá-lo (especialmente no que se refere a instanciação) através de camadas de abstração.

• Partitioning - Utilizado para organizar os conceitos de uma mesma área, dentro da mesma camada. No caso da biblioteca da Infrastructure, é utilizado um particionamento com

granulação bastante fina, afim de provêr maior flexibilidade. No caso do metamodelo da UML, o particionamento é pouco granular, aumentando a coesão entre os elementos internos de um pacote e baixando o acoplamento entre eles.

• Extensibility - A UML pode ser extendida de duas formas diferentes:

1. uma pequena variação da linguagem UML (dialeto) pode ser definida utilizando

Profiles para customizá-la, tornando-a particular em algum domínio específico.

2. Uma nova linguagem relacionada com a UML pode ser especificada utilizando parte do pacote Infra-Struture Library, aumentando-a com as devidas metaclasses e me-

tarelationships.

No primeiro caso é definido um novo dialeto da UML, no segundo, é definido um novo membro da família de linguagens baseadas na UML.

• Reuse - Uma biblioteca de metamodelo flexível e com alta granularidade é fornecida desde que seja reutilizada para definir o metamodelo da UML, assim como outros meta- modelos relacionados (como o Meta Object Facility).

UML Superstructure (OMG, 2007c)

A UML Superstructure (OMG, 2007c) é a segunda parte de duas especificações comple- mentares. A primeira delas (Infrastructure) (OMG, 2007b) é o alicerce arquitetural para a

Superstructure. Essas duas especificações se constituem na especificação completa da UML 2.

A UML Superstructure não está dentro do escopo deste trabalho.

2.4 SPEM v2 (OMG, 2008b)

O Software and System Process Engineering Metamodel (SPEM v2) (OMG, 2008b) é um metamodelo para engenharia de PDSs assim como um arcabouço conceitual, provendo os con- ceitos necessários para modelar, documentar, apresentar, gerenciar, inter-mutabilidade e execu- ção de métodos e processos de software.