Diretrizes:
|
|
Detalhes |
---|---|
Procure possibilidade de opção | Se uma determinada colaboração (ou subcolaboração) representar um comportamento opcional, inclua-a em um subsistema. As funcionalidades que possam ser removidas, atualizadas ou substituídas por outras deverão ser consideradas independentes. |
Observe a interface do usuário do sistema | Se a interface com o usuário for relativamente independente das classes de entidade do sistema (ou seja, elas podem e serão alteradas independentemente), crie subsistemas que sejam integrados horizontalmente: agrupe as classes de limite da interface com o usuário relacionadas em um subsistema e agrupe as classes de entidade relacionadas em um outro subsistema. |
Se a interface com o usuário e as classes de entidade exibidas por ela estiverem intrinsecamente acopladas (ou seja, se uma alteração em uma disparar uma alteração na outra), crie subsistemas que sejam integrados verticalmente: inclua as classes de limite e de entidade relacionadas no subsistema comum. | |
Observe os Atores | Separe a funcionalidade usada por dois atores diferentes, já que cada ator pode alterar independentemente seus requisitos no sistema. |
Crie subsistemas para encapsular o acesso a um sistema ou subsistema externo. | |
Procure o acoplamento e a coesão entre os elementos de design | Classes/subsistemas com um elevado grau de acoplamento ou coesão colaboram para fornecer um conjunto de serviços. Organize os elementos altamente acoplados em subsistemas e separe-os em linhas de menor grau de acoplamento. Em alguns casos, o menor grau de acoplamento pode ser eliminado inteiramente, dividindo as classes em classes menores com responsabilidades mais coesas ou reparticionando os subsistemas apropriadamente. |
Examine a substituição | Se houver vários níveis de serviço especificados para um recurso específico (exemplo: disponibilidade alta, média e baixa), represente cada nível de serviço como um subsistema separado, cada qual realizando o mesmo conjunto de interfaces. Com isso, os subsistemas serão substituídos uns pelos outros. |
Examine a distribuição | Embora possa haver diversas instâncias de um subsistema específico, cada uma executada em diferentes nós, em muitas arquiteturas não é possível que uma única instância de um componente seja dividida em nós. Nos casos em que o comportamento do subsistema deva ser dividido em nós, é recomendável decompor o subsistema em subsistemas menores (cada qual representando um único componente) com uma funcionalidade mais restrita. Determine a funcionalidade que deve residir em cada nó e crie um novo subsistema para 'possuir' essa funcionalidade, distribuindo as responsabilidades e os elementos relacionados do subsistema original de modo apropriado. Os novos subsistemas são internos ao subsistema original. |
Depois que o design tiver sido organizado em subsistemas, atualize as realizações de casos de uso apropriadamente.
Os subsistemas de design são modelados utilizando componentes da UML. Essa construção fornece os recursos de modelagem a seguir:
Outras considerações são:
Nota: A UML 2.0 também define um estereótipo para o componente nomeado <<subsistema>>, indicando que ele pode ser utilizado, por exemplo, para representar estruturas em larga escala. Um Subsistema de Design RUP pode ou não ser uma estrutura em larga escala; ambos são Subsistemas de Design da perspectiva RUP. Esta é uma questão a ser decidida pelo arquiteto de software (se escolherá, por exemplo, etiquetar componentes que sejam compostos de componentes como <<subsistema>>).
Quando um produto existente é um produto que exporta interfaces, ou seja, operações
(e talvez recepções), mas, em
contrapartida, mantém todos os detalhes de implementação ocultos, ele pode ser modelado
como um subsistema na visualização lógica. Exemplos de produtos utilizados pelo sistema
que podem ser representados por um subsistema incluem:
Alguns produtos existentes, como coleções de tipos e estruturas de dados (por exemplo, pilhas, listas, filas), podem ser melhor representados como pacotes, já que revelam mais do que simplesmente um comportamento. Além disso, é o conteúdo específico do pacote que é importante e útil, e não o pacote propriamente dito, que é simplesmente um contêiner.
Utilitários comuns, como bibliotecas de matemática, podem ser representados como
subsistemas, caso simplesmente exportem interfaces, mas se isso é necessário ou
faz sentido depende do julgamento do designer sobre a natureza do que é modelado.
Os subsistemas são construções orientadas a objetos (uma vez que são componentes modelados):
um subsistema pode ter instâncias (se assim indicado pelo designer). A UML fornece
uma outra forma de modelar grupos de variáveis e procedimentos globais no utilitário,
que é um estereótipo de classe - o utilitário não possui instâncias.
Ao definir o subsistema para representar o produto, defina também uma ou mais interfaces para representar as interfaces do produto.
Os Subsistemas de Design (modelados como componentes da UML) diferem dos pacotes em relação à semântica: um subsistema fornece o comportamento por meio de uma ou mais interfaces que ele realiza. Os pacotes não apresentam nenhum comportamento; são simplesmente contêiners de elementos que apresentam comportamento.
A razão para utilizar um subsistema em vez de um pacote é que os subsistemas encapsulam seu conteúdo, fornecendo o comportamento somente por meio de suas interfaces. A vantagem disso é que, ao contrário do que ocorre no pacote, o conteúdo e os comportamentos internos de um subsistema podem ser alterados com total liberdade, contanto que as interfaces do subsistema permaneçam constantes. Os subsistemas também fornecem um elemento de 'design substituível': dois componentes <<realização>> que realizam as mesmas interfaces (ou componente <<especificação>>) são intercambiáveis.
Para assegurar que os subsistemas sejam elementos substituíveis no modelo, algumas regras precisam ser aplicadas:
Veja a seguir um exemplo das dependências de Subsistema e de Pacote:
Dependências de Subsistema e de Pacote no Modelo de Design
A UML ([UML04]) declara:
Existem vários estereótipos padrão da UML que aplicam-se ao componente, por exemplo, <<especificação>> e <<realização>> para modelar componentes com definições distintas de especificação e realização, em que uma especificação pode ter várias realizações.
Um Componente estereotipado por <<especificação>> especifica um domínio de objetos sem definir a implementação física desses objetos. Ele terá apenas interfaces fornecidas e requeridas e não deverá ter classes e subcomponentes de realização como parte de sua definição.
Um Componente estereotipado por <<realização>> especifica um domínio de objetos e também define a implementação física desses objetos. Por exemplo, um Componente estereotipado por <<realização>> terá apenas classes e subcomponentes de realização que implementam o comportamento especificado por um Componente <<especificação>> separado.
A separação da especificação e realização permite essencialmente duas descrições separadas do subsistema. A especificação serve como um contrato que define tudo que um cliente precisa saber para utilizar o subsistema. A realização é um design interno detalhado destinado a orientar o implementador. Se você desejar suportar várias realizações, crie subsistemas de "realização" separados e represente uma realização de cada subsistema de realização para o subsistema de especificação.
Se o estado e o comportamento internos do subsistema forem relativamente simples, poderá ser suficiente especificar o subsistema por suas interfaces expostas, diagramas de estado para descrever o comportamento e texto descritivo.
Para estado e comportamento internos mais complexos, é possível utilizar classes de análise para especificar o subsistema em um alto nível de abstração. Para sistemas em larga escala, a especificação de um subsistema também pode incluir casos de uso. Consulte Desenvolvendo Sistemas em Larga Escala com o Rational Unified Process.
O fornecimento de uma especificação detalhada separada da realização tende a ser mais útil nas situações a seguir:
No entanto, manter uma especificação separada exige esforço - uma vez que deve-se
assegurar que a realização do subsistema esteja em conformidade com a especificação.
Os critérios de quando, e se deve, criar classes e colaborações separadas de especificação
e realização devem ser definidos em Artefato:
Diretrizes Específicas do Projeto.
Uma especificação deverá definir suas dependências. Estas são as interfaces e os elementos visíveis de outros subsistemas e pacotes que devem estar disponíveis em todas as realizações de conformidade do subsistema.
Uma realização pode ter dependências adicionais, inseridas pelo designer ou implementador. Por exemplo, pode haver uma oportunidade para utilizar um componente de utilitário para simplificar a implementação - mas o uso desse componente de utilitário é um detalhe que não precisa ser exposto aos clientes. Essas dependências adicionais deverão ser capturadas em um diagrama separado como parte da realização.
Uma especificação totalmente detalhada define tudo o que um cliente precisa para utilizar um subsistema. Isso significa refinar as interfaces expostas e quaisquer elementos publicamente visíveis, de modo que fiquem um-a-um com o código. As classes de análise inseridas para especificar o comportamento do subsistema devem permanecer como abstrações de alto nível uma vez que elas devem ser independentes de quaisquer realizações de subsistemas.
Os elementos de realização de um subsistema devem ser alinhados juntamente com o código.
Consulte Conceitos: Mapeando de Design para Código para discussão adicional sobre este tópico.
Os subsistemas de design podem ser modelados como componentes da UML 2.0 ou subsistemas da UML 1.5. Essas construções fornecem recursos de modelagem quase equivalentes, como modularidade, encapsulamento e instâncias capazes de serem executados no tempo de execução.
Algumas considerações adicionais sobre essas opções de modelagem são:
No entanto, de um modo geral, essas notações podem ser utilizadas de modo intercambiável. A decisão
de representar os Subsistemas de Design como subsistemas da UML 1.5 ou componentes da UML 2.0
deverá ser documentada nas Diretrizes
Específicas do Projeto adaptadas ao processo/projeto.
Se a sua ferramenta de modelagem visual suportar pacotes da UML 1.5, mas não subsistemas da UML 1.5, um pacote estereotipado como <<subsistema>> poderá ser utilizado para indicar um subsistema.
As mesmas restrições e discussões de dependência mencionadas na seção intitulada Restrições de Dependência de Subsistema também se aplicam a subsistemas de design que estejam sendo modelados como subsistemas da UML 1.5.
Um exemplo de dependências de Subsistema e de Pacote na UML 1.5 é mostrado a seguir:
Dependências de Subsistema e de Pacote no Modelo de Design
O conteúdo de um subsistema é dividido em dois subconjuntos: 1) elementos de
especificação e 2) elementos de realização. Os elementos de especificação, juntamente com as
operações e recepções do sistema, são utilizados para fornecer uma especificação abstrata
do comportamento oferecido pelos elementos de realização. A coleção de elementos de realização
modelam o interior da unidade comportamental do sistema físico.
A separação de especificação e realização permite essencialmente duas descrições separadas do subsistema. A especificação serve como um contrato que define tudo que um cliente precisa saber para utilizar o subsistema. A realização é um design interno detalhado destinado a orientar o implementador.
Uma opção para modelar especificações e realizações, se não suportadas diretamente pelo ambiente de modelagem, é colocar dois pacotes, especificação e realização, dentro de cada subsistema.
Uma motivação para as especificações é suportar várias realizações. Isso não era diretamente suportado na UML 1.x. Se você desejar suportar várias realizações utilizando subsistemas da UML 1.5, crie subsistemas de "realização" separados e represente uma realização de cada subsistema de realização para o subsistema de especificação.
Basicamente, as mesmas considerações para Especificação e Realização que são aplicáveis à UML 2.0 também aplicam-se aqui (consulte Quando e Como Utilizar, Dependências e Relacionamento com Implementação para obter uma explicação).
Consulte Diferenças entre a UML
1.x e a UML 2.0 para obter informações adicionais.
Rational Unified Process
|