Artefato: Cápsula

Opções de Representação

Representação UML: Classe, estereotipada como <<cápsula>>. Observe que essa representação é baseada na notação da UML 1.5. Muito disso pode ser representado em UML 2.0 utilizando o Conceito: Classe Estruturada. Consulte Diferenças entre a UML 1.x e a UML 2.0 para obter informações adicionais.

Uma cápsula é um elemento composto, como é representado na figura abaixo.

diagrama de elemento composto

Composição de Cápsulas

Uma cápsula pode ter portas e pode "conter" classes passivas e/ou sub-cápsulas. Ela também pode ter uma máquina de estado que descreva inteiramente o comportamento da cápsula. Uma taxonomia específica de cápsulas e as várias maneiras de utilizá-las são discutidas em Diretriz: Cápsula.

Propriedades

Uma cápsula encapsula um encadeamento de controle. Uma cápsula é uma abstração de um encadeamento independente de controle no sistema; é a unidade primária de simultaneidade no sistema. O isolamento adicional de threads de controle pode ser feito por meio de threads e processos do sistema operacional, mapeando cápsulas para threads e processos do sistema operacional. As mensagens para a cápsula chegam através de uma porta e são processadas seqüencialmente; caso a instância da cápsula esteja ocupada, as mensagens são postas na fila. As cápsulas forçam a semântica indivisível, de modo que, quando um evento for recebido, ele será totalmente processado, independentemente do número ou da prioridade de outros eventos que chegam.

Uma cápsula interage com seu ambiente através de portas. Uma porta é um objeto de limite baseado em sinal, que faz a mediação da interação da cápsula com o mundo externo. Uma porta implementa uma interface específica e pode ser dependente de uma interface específica. Uma cápsula não pode ter operações ou partes públicas que não sejam portas, que são seus meios exclusivos de interação com o mundo externo.

Cada porta desempenha uma função específica em uma colaboração. A colaboração descreve como a cápsula interage com outros objetos. Para capturar a semântica complexa dessas interações, as portas são associadas a um protocoloque define o fluxo válido de informações (sinais) entre as portas conectadas das cápsulas. O protocolo apreende as obrigações contratuais que existem entre as cápsulas. Ao forçar as cápsulas a se comunicarem apenas através de portas, é possível separar totalmente as implementações internas da cápsula do ambiente que cerca a cápsula. Isso torna as cápsulas altamente reutilizáveis.

A funcionalidade de uma cápsula simples é percebida diretamente pela máquina de estado da cápsula. Cápsulas mais complexas combinam a máquina de estado com uma rede interna de subcápsulas de colaboração unidas por conectores. Essas subcápsulas são cápsulas plenas e podem ser decompostas em subcápsulas. Esse tipo de composição pode ser feito em qualquer profundidade necessária, permitindo a modelagem de estruturas arbitrariamente complexas com apenas esse conjunto básico de construções de modelagem estrutural. A máquina de estado (que é opcional para cápsulas compostas), as subcápsulas e sua rede de conexões representam parte da implementação da cápsula e estão ocultas para observadores externos.

Uma cápsula pode ser um elemento composto. Cápsulas podem ser compostas por outras cápsulas e classes passivas. As cápsulas e as classes passivas são ligadas por conectores ou vínculos em uma colaboração; essa colaboração define a 'estrutura' da cápsula e, portanto, é chamada de uma 'colaboração de especificação'. Uma cápsula pode ter uma máquina de estado que pode enviar e receber sinais através de portas de extremidade da cápsula, e que tem controle sobre certos elementos da estrutura interna. Portanto, essa máquina de estado pode ser considerada como implementadora de comportamento reflexivo, isto é, comportamento que controla a operação da cápsula propriamente dita.

Portas

As portas são objetos cuja finalidade é agir como objetos de fronteira para uma instância de cápsula. São propriedade da instância da cápsula no sentido de que são criadas junto com suas respectivas cápsulas e são destruídas quando a cápsula é destruída. Cada porta tem uma identidade e um estado que são distintos da identidade e do estado da instância da cápsula a que pertencem (na mesma proporção em que qualquer parte é distinta de seu contêiner).

Embora as portas sejam objetos de fronteira que agem como interfaces, elas não mapeiam diretamente para interfaces em UML. Uma interface UML é simplesmente algo comportamental - não possui estrutura de implementação. Uma porta, por outro lado, contém tanto a estrutura quanto o comportamento. Ela é uma parte composta da estrutura da cápsula e não, apenas uma restrição no seu comportamento. Ela percebe o padrão arquitetural que pode ser chamado de "interface manifesta".

Na UML, uma porta é modelada como uma classe com o estereótipo <<porta>>. Como foi observado anteriormente, o tipo de uma porta é definido pelo papel de protocolo assumido por aquela porta. Como as funções de protocolo são classes abstratas, a classe real correspondente a essa instância é uma que implementa a função de protocolo associada à porta. Na UML, a relação entre a porta e a função de protocolo é chamada de relação de realizações. A notação para isso é uma linha tracejada com uma seta sólida na extremidade de especificação. É uma forma de generalização pela qual o elemento de origem - a porta - herda apenas a especificação de comportamento do destino - a função de protocolo - mas não sua estrutura.

Uma cápsula está em um relacionamento de composição com suas portas. Se a multiplicidade da extremidade-alvo desse relacionamento for maior que um, isso significa que existem várias instâncias da porta no tempo de execução, cada uma participando de uma instância separada do protocolo. Se a multiplicidade for um intervalo de valores, isso significa que o número de portas pode variar no tempo de execução e que as portas podem ser dinamicamente criadas ou destruídas (possivelmente, sujeitas a restrições).

diagrama de cápsula mostrando portas

Portas, protocolos e papéis de protocolo

A figura acima mostra um exemplo de uma porta única chamada b pertencente à classe de cápsula CapsuleClassA. Essa porta apreende o papel-mestre do protocolo definido pela classe de protocolo ProtocolA. Observe que a classe de porta real, PortClassX, sendo uma classe de implementação que pode variar de uma implementação para outra, normalmente não é relevante para o modelador até o estágio de implementação. Em vez disso, as informações que são de interesse são a função de protocolo que essa porta implementa. Por esse motivo e também por razões de conveniência notacional, a notação mostrada na Figura 1 não é normalmente usada e é substituída pela forma mais compacta descrita na seção seguinte.

Notação

Nos diagramas de classes, as portas de uma cápsula são listadas em um compartimento especial de lista rotulado como aparece na ilustração. O compartimento de lista de portasnormalmente aparece depois dos compartimentos de lista de atributos e operadores. Essa notação se beneficia da característica da UML que permite a adição de compartimentos nomeados específicos.

diagrama de classe para portas

Notação de portas - representação de diagrama de classes

Todas as portas externas (portas de relé e portas de extremidade públicas) têm visibilidade pública, enquanto as portas internas têm visibilidade protegida (por exemplo, porta b2). O papel de protocolo (tipo) de uma porta, normalmente, é identificado por um nome de caminho, pois os nomes de papel de protocolo são exclusivos apenas dentro do escopo de um dado protocolo. Por exemplo, a porta b assume o papel-mestre definido na classe de protocolo chamada ProtocolA. No caso muito freqüente de protocolos binários, uma convenção notacional mais simples é utilizada: um símbolo de til ("~") é utilizado para identificar a função de protocolo conjugado (por exemplo, a porta b2), enquanto a função base está implícita sem anotação especial (por exemplo, porta b1). As portas com multiplicidade diferente de 1 têm o fator de multiplicidade incluído entre colchetes. Por exemplo, a porta b1[3] tem um fator de multiplicidade de exatamente 3, ao passo que uma porta designada por b5[0..2] tem um número variável de instâncias que não excede 2.

Conectores

Uma conexão representa um canal de comunicação que fornece os recursos de transmissão para dar suporte a um determinado protocolo baseado em sinal. Uma característica-chave dos conectores é que eles só podem interconectar portas que assumem papéis complementares no protocolo associado ao conector. Em princípio, os papéis de protocolo não precisam necessariamente pertencer ao mesmo protocolo, mas, naquele caso, eles devem ser compatíveis com o protocolo do conector.

Os conectores são visões abstratas de canais de comunicação baseada em sinal que interconectam duas ou mais portas. As portas vinculadas por uma conexão devem assumir papéis mutuamente complementares, mas compatíveis, em um protocolo. Em diagramas de colaboração, elas são representadas por funções de associação que interconectam as portas apropriadas. Se abstrairmos as portas dessa figura, os conectores realmente capturarão os relacionamentos-chave de comunicação entre as cápsulas. Esses relacionamentos são importantes para a arquitetura, pois eles identificam quais cápsulas podem afetar umas às outras através de comunicação direta. As portas são incluídas para permitir o encapsulamento de cápsulas sob o princípio de ocultamento de informações e separação de preocupações.

A semelhança entre conectores e protocolos poderia sugerir que os dois conceitos são equivalentes. No entanto, esse não é o caso, porque os protocolos são especificações abstratas de comportamento desejado enquanto os conectores são objetos físicos cuja função é meramente encaminhar sinais de uma porta para outra. Normalmente, os conectores são condutores passivos. (Na prática, os conectores físicos podem, às vezes, desviar do comportamento especificado. Por exemplo, como resultado de uma falta interna, um conector pode perder, reordenar ou duplicar mensagens. Esse tipo de falha é comum em canais de comunicação distribuída.)

Um conector é modelado por uma associação existente entre duas ou mais portas das classes de cápsulas correspondentes. (Para aplicativos avançados em que o conector possui propriedades físicas, uma classe de associação pode ser utilizada desde que o conector seja realmente um objeto com um estado e uma identidade. Já com as portas, a classe real que é usada para perceber um conector é um problema de implementação.) O relacionamento com o protocolo suportado é depreendido através das portas conectadas. Conseqüentemente, nenhuma extensão em UML é necessária para representar os conectores.

A Colaboração de Especificação

A estrutura interna completa de uma cápsula é representada por uma colaboração de especificação. Essa colaboração contém uma especificação de todas as suas portas, subcápsulas e conectores. Assim como as portas, as subcápsulas e os conectores pertencem totalmente à cápsula e não podem existir independentemente dela. Eles são criados quando a cápsula é criada ou destruídos quando ela é destruída.

Algumas subcápsulas da estrutura não podem ser criadas simultaneamente à cápsula que as contém. Em vez disso, elas podem ser criadas subseqüentemente, quando e se necessário, pela máquina de estado da cápsula. A máquina de estado também pode destruir essas cápsulas a qualquer momento. Isso está de acordo com as regras de UML de composição.

A estrutura de uma cápsula pode conter as conhecidas funções de plug-in. Eles são, na verdade, espaços reservados para subcápsulas que são preenchidos dinamicamente. Isso é necessário porque nem sempre são conhecidos com antecedência os objetos específicos que assumirão aqueles papéis no tempo de execução. Quando essas informações estiverem disponíveis, a instância de cápsula apropriada (que é propriedade de alguma outra cápsula composta) poderá ser encaixada nesse slot, e os conectores que ligam suas portas a outras subcápsulas na colaboração serão automaticamente estabelecidos. Quando o relacionamento dinâmico não for mais necessário, a cápsula será "removida" do slot de plug-in, e os conectores serão desativados.

As cápsulas e os encaixes criados de modo dinâmico permitem a modelagem de estruturas mutáveis dinamicamente enquanto asseguram que todos os relacionamentos válidos de comunicação e de confinamento entre as cápsulas sejam especificados explicitamente. Isso é importante para assegurar a integridade da arquitetura em um sistema complexo de tempo real.

As portas também podem ser representadas em diagramas de colaboração. Nesses diagramas, os objetos são representados pelas funções classificadoras adequadas, isto é, subcápsulas por funções de cápsula e portas por funções de porta. Para reduzir a confusão visual, os papéis de porta geralmente são mostrados na forma de ícones, representados por quadrados pretos ou brancos pequenos. As portas públicas são representadas por ícones de papel de porta que abrem a fronteira dos papéis de cápsula correspondentes como é mostrado na figura anterior. Essa notação abreviada permite que elas sejam conectadas tanto de dentro quanto de fora da cápsula sem atravessamento desnecessário das linhas, e também as identifica claramente como objetos de fronteira.

diagrama de portas públicas e funções de cápsula

Notação de porta - diagrama de colaboração de especificação

Observe que os rótulos são adornos nos papéis de porta e não devem ser confundidos com nomes de extremidades de associações do conector. Além disso, como as portas têm identificação exclusiva através de seus nomes, é possível, como uma conveniência gráfica, organizar os papéis de portas públicas em torno do perímetro de uma caixa de subcápsulas em qualquer ordem. Isso pode ser usado para minimizar os desvios entre linhas de conectores.

Para o caso de protocolos binários, um ícone de estereótipo adicional pode ser utilizado: a porta que desempenha a função conjugada é indicada por um quadrado preenchido de branco (em contraste com o preenchido de preto). Nesse caso, o nome do protocolo e o sufixo de til são suficientes para identificar o papel de protocolo como o papel conjugado; o nome do papel de protocolo é redundante e deve ser omitido. Da mesma forma, o uso apenas do nome do protocolo em um quadrado preto indica o papel de base do protocolo. Por exemplo, se a função "master" no protocolo ProtQ for declarada como a base, o diagrama na figura a seguir e o diagrama na figura anterior serão equivalentes. Essa convenção facilita ver quando papéis de protocolo complementares estão conectados.

diagrama de funções de protocolo

Convenções notacionais para protocolos binários

As portas com um fator de multiplicidade maior do que um também podem ser indicadas graficamente usando-se a notação padrão de vários objetos da UML, como é mostrado na próxima figura. Isso não é obrigatório (a seqüência de caracteres de multiplicidade é suficiente), mas enfatiza a possibilidade de várias instâncias da porta.

diagrama UML para vários objetos

Portas com fator de multiplicidade maior do que 1

A Máquina de Estado

A máquina de estado opcional associada a uma cápsula é apenas outra parte da implementação de uma cápsula. Contudo, ela possui certas propriedades especiais que a distingue de outros constituintes de uma cápsula:

Ela não pode ser decomposta em subcápsulas. Ela especifica o comportamento de modo direto. As máquinas de estado, no entanto, podem ser decompostas em hierarquias de máquinas de estado mais simples usando-se as capacidades padrão da UML.
Pode haver, no máximo, uma dessas máquinas de estado por cápsula (embora as subcápsulas possam ter suas próprias máquinas de estado). As cápsulas que não possuem máquinas de estado são meros contêineres para subcápsulas.
Ela trata de sinais que chegam em qualquer porta de extremidade de uma cápsula e pode enviar sinais através dessas portas.
Ela é a única entidade que pode acessar as partes protegidas internas na sua cápsula. Isso significa que ela age como o controlador de todas as outras subcápsulas. Como tal, ela pode criar e destruir aquelas subcápsulas identificadas como dinâmicas, e pode encaixar e remover subcápsulas externas conforme a necessidade.

As subcápsulas criadas de forma dinâmica são indicadas simplesmente por um fator de multiplicidade variável. Como os slots de encaixe, elas também podem ser especificadas por um simples tipo de interface. Isso significa que, no momento de criar instâncias, qualquer classe de implementação que suporte aquela interface pode ser instanciada. Isso permite generalidade nas especificações estruturais.

Apesar de suas restrições adicionais, a máquina de estado associada a uma cápsula é modelada pelo vínculo padrão entre um Classificador de UML e uma Máquina de Estado. A implementação/decomposição de uma cápsula é modelada por um elemento padrão de colaboração de UML que pode ser associado a um classificador.