Artefatos > 
Conjunto de Artefatos de Análise e Design > 
Modelo de Design... > 
Subsistema de Design > 
Diretrizes
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 do usuário for relativamente independente das classes de entidade do sistema (ou seja, a interface e as classes podem e serão alteradas independentemente), crie subsistemas que sejam integrados horizontalmente: agrupe as classes de fronteira de interface do usuário relacionadas em um subsistema e agrupe classes de entidade relacionadas em outro subsistema. |
| Se a interface do usuário e as classes de entidade exibidas por ela estiverem intrinsecamente acopladas (ou seja, se uma mudança na interface acarretar uma mudança nas classes e vice-versa), crie subsistemas que sejam integrados verticalmente: inclua as classes de entidade e as classes de fronteira relacionadas em um subsistema comum. | |
| Observe os Atores | Separe a funcionalidade usada por dois atores diferentes, já que cada ator pode alterar independentemente seus requisitos no sistema. |
| Procure o acoplamento e a coesão entre as classes | As classes com um elevado grau de acoplamento ou coesão colaboram para fornecer um conjunto de serviços. Organize as classes fortemente acopladas em subsistemas, separando-as em linhas de menor grau de acoplamento. Em alguns casos, o menor grau de acoplamento pode ser eliminado inteiramente dividindo-se as classes em classes menores com responsabilidades mais coesas. |
| Examine a substituição | Se houver vários níveis de serviço especificados para um recurso específico (por 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 por diferentes nós. Nos casos em que o comportamento do subsistema deva ser dividido por diferentes 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 pertencer a 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 estarão contidos no subsistema original. |
Depois que as classes tiverem sido organizadas em subsistemas, atualize as realizações de casos de uso de acordo com essa organização.
Depois que o subsistema tiver sido criado:
Os componentes são itens de implementação; um subsistema pode ser usado como um proxy do componente para representá-lo no design.
Para esses fins, os Subsistemas de Design representam, de forma ideal, os componentes no Modelo de Design: eles são elementos de design que encapsulam o comportamento de diversas classes (assim como os componentes encapsulam o comportamento de diversas instâncias de classe) e seu comportamento só é acessado através das interfaces que realizam (como é o caso dos componentes).
Quando um produto existente for um produto que exporte interfaces, ou seja, operações (e talvez recepções), mas, em contrapartida, mantenha todos os detalhes de implementação ocultos, ele poderá ser modelado como um subsistema na visão lógica. Entre os exemplos de produtos usados pelo sistema que podem ser representados por um subsistema estão incluídos:
Alguns produtos existentes, como conjuntos 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, por exemplo, bibliotecas de matemática) poderão ser representados como subsistemas, caso simplesmente exportem interfaces, mas se isso será necessário ou fará sentido dependerá do julgamento do designer sobre a natureza do que é modelado. Os subsistemas são construções orientadas a objetos que são classificadores assim como pacotes: um subsistema pode ter instâncias (caso seja indicado pelo designer). A UML é outra forma de modelar grupos de procedimentos e variáveis globais no utilitário, que é um estereótipo de classe sem 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 diferem dos pacotes em seu aspecto semântico: um subsistema é um tipo de pacote que apresenta comportamento em uma ou mais interfaces que realiza. Os pacotes não apresentam nenhum comportamento; são simplesmente contêiners de elementos que apresentam comportamento.
A razão para se usar um subsistema em vez de um pacote é que o subsistema encapsula completamente seu conteúdo, apresentando comportamento somente através 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 não sofram mudanças. Os subsistemas também fornecem um elemento de "design substituível": dois subsistemas quaisquer (ou classes, no que diz respeito a isso) que realizem as mesmas interfaces 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
|
Rational Unified Process |
