Tópicos

ExplicaçãoPara o início da página

Uma forma básica de reduzir a complexidade de um modelo de implementação com centenas de elementos é utilizar subsistemas de implementação.

Normalmente, os subsistemas assumem a forma de diretórios, com informações adicionais sobre estrutura ou gerenciamento. Por exemplo, um subsistema pode ser criado como um diretório ou uma pasta em um sistema de arquivos, como um subsistema no Rational Apex para C++ ou Ada, ou como pacotes que usem Java. Em desenvolvimentos do Rational XDE, um Subsistema é um "projeto" conforme definido pelo IDE (Integrated Development Environment).

O subsistema de implementação é o análogo da implementação de ../glossary.htm#design_package -- This hyperlink in not present in this generated websitepacote de design (ou subsistema de design de granularidade maior). O modelo de implementação e os subsistemas de implementação são o destino da ../glossary.htm#implementation_view -- This hyperlink in not present in this generated websitevisualização de implementação e, portanto, de primordiais no tempo de desenvolvimento.

Exportando Elementos

Um subsistema de implementação controla a visibilidade externa do conteúdo nele presente. Um elemento pode ser referenciado por elementos fora do subsistema, caso ele se torne visível ("exportado") pelo respectivo subsistema declarante.

Por padrão, todos os elementos (e os subsistemas contidos) em um subsistema são geralmente visíveis fora dele. Isso significa que qualquer elemento fora desse subsistema pode referenciar todos os elementos. Por exemplo, em C++, isso significa que os elementos externos podem incluir (#include) todos os elementos no subsistema.

UsoPara o início da página

O modelo de implementação pode ser mais ou menos parecido com o modelo de design, de acordo com a forma como os pacotes de design são mapeados para os subsistemas de implementação no modelo de implementação.

É recomendável manter o mapeamento com uma equivalência de um para um, ou seja, um pacote de design mapeado para um subsistema de implementação. O principal motivo disso é obter uma rastreabilidade uniforme do design para o código.

Existem situações em que os subsistemas na implementação precisam ser diferentes dos pacotes e subsistemas no design. Para obter informações adicionais, consulte a Atividade: Estruturar o Modelo de Implementação. A decisão e a forma de representar esse mapeamento será abrangido pelo ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websiteArtefato: Diretrizes Específicas do Projeto.

Muitos são os motivos para particionar um sistema em subsistemas. Os mesmos critérios usados no design se aplicam à implementação. Para obter informações adicionais, consulte Diretrizes: Pacote de Design.



Rational Unified Process   2003.06.15