Atividade:  Incorporar Elementos de Design Existentes

Identificar Oportunidades de Reutilização

Procure subsistemas ou componentes existentes que oferecem interfaces semelhantes. Compare cada interface identificada com as interfaces fornecidas pelos subsistemas ou componentes existentes. Em geral, não há uma correspondência exata, mas é possível encontrar correspondências aproximadas. Procure comportamentos semelhantes e os valores retornados primeiro; depois, considere os parâmetros.

Modifique as interfaces que acabou de identificar para um ajuste mais preciso. Talvez você tenha oportunidade de efetuar pequenas mudanças em uma sugestão de interface que melhorarão a sua adequação à interface existente. Mudanças simples incluem a reorganização ou a adição de parâmetros à sugestão de interface e, em seguida, o ajuste dessa interface dividindo-a em diversas interfaces, das quais uma ou mais correspondem às interfaces do componente existente, com os "novos" comportamentos localizados em uma interface separada.

Substitua as sugestões de interface pelas interfaces existentes onde houver uma correspondência exata. Após a simplificação e o ajuste, se houver uma correspondência exata com uma interface existente, elimine a sugestão de interface e use apenas a existente.

Mapeie a sugestão de subsistema para componentes existentes. Observe os componentes existentes e o conjunto de sugestões de subsistema. Ajuste os subsistemas de modo que os componentes existentes sejam usados sempre que possível para satisfazer ao comportamento exigido do sistema. Nos casos em que uma sugestão de subsistema puder ser realizada por um componente existente, crie uma rastreabilidade entre o subsistema de design e o componente no modelo de implementação.

No mapeamento de subsistemas para componentes, considere os mecanismos de design associados ao subsistema; os requisitos de desempenho ou segurança podem excluir um componente da reutilização, apesar de uma correspondência perfeita entre as assinaturas da operação.

Fazer a Engenharia Reversa de Componentes e Bancos de Dados

Com base nos resultados da Atividade: Incorporar Elementos de Design Existentes, é possível 'revirar' definições de código e banco de dados existentes a fim de disponibilizar o trabalho realizado em projetos ou iterações anteriores para o projeto/iteração atual. Usando possíveis oportunidades de reutilização como um filtro, o trabalho onde foi realizada a engenharia reversa pode se concentrar apenas nos componentes que são reutilizáveis para a iteração atual.

Componentes de Engenharia Reversa

Nas organizações que criam sistemas semelhantes, há geralmente um conjunto de componentes comuns que fornece muitos dos mecanismos de arquitetura necessários a um novo sistema. Também podem existir componentes disponíveis no mercado que fornecem os mecanismos de arquitetura. É necessário examinar os componentes existentes para verificar a sua adequação à arquitetura de software e a sua compatibilidade com ela.

Os componentes existentes, desenvolvidos durante as iterações anteriores mas ainda não incluídos no Modelo de Design, ou os componentes adquiridos, deverão sofrer a engenharia reversa e ser incorporados ao Modelo de Design. Nesse Modelo, cada componente é representado como um Subsistema com uma ou mais Interfaces.

Bancos de Dados de Engenharia Reversa

Os bancos de dados, e os dados que neles residem, representam uma das fontes mais importantes de informações reutilizáveis. Para reutilizar as definições de classe implícitas incorporadas nos bancos de dados existentes, verifique quais informações usadas pelo aplicativo já residem nesses bancos de dados. Faça a engenharia reversa em um conjunto de classes para representar as estruturas de banco de dados que contêm essas informações (para obter informações sobre como fazer isso, consulte Diretrizes: Bancos de Dados Relacionais de Engenharia Reversa). Ao mesmo tempo, crie um mapeamento entre a representação de classe do aplicativo e as estruturas usadas no banco de dados. Para obter informações sobre o mapeamento entre classes e tabelas em um banco de dados relacional, consulte Diretrizes: Modelo de Dados.

Atualizar a Organização do Modelo de Design

Como novos elementos foram adicionados ao Modelo de Design, geralmente é necessário reempacotar os elementos desse Modelo. O reempacotamento atinge vários objetivos: reduz o acoplamento entre pacotes e aumenta a coesão nos pacotes do modelo de design. A meta final é permitir que diferentes pacotes (e subsistemas) sejam projetados e desenvolvidos de forma independente uns dos outros por indivíduos ou equipes distintas. Embora seja praticamente impossível estabelecer uma independência total, o acoplamento flexível entre pacotes costuma facilitar ainda mais o desenvolvimento de sistemas grandes ou complexos.

Uma estrutura de modelo 'plana' (em que todos os pacotes e subsistemas residem no mesmo nível conceitual no sistema) é adequada para um sistema pequeno; os sistemas maiores precisam de uma outra ferramenta de estruturação chamada 'divisão em camadas' (consulte Diretrizes: Divisão em Camadas e Conceitos: Divisão em Camadas). As regras de divisão em camadas definem restrições aos relacionamentos permitidos entre determinados tipos de pacotes. Essas regras reconhecem que certas dependências não devem existir: a funcionalidade do aplicativo não deve depender diretamente de um sistema operacional específico nem de serviços de sistema de janelas - é necessário existir uma camada intermediária com o sistema operacional lógico e os serviços de janelas que isole a funcionalidade do aplicativo de mudanças nos serviços de implementação de nível baixo. A divisão em camadas permite reduzir o impacto da mudança: com a imposição de regras que restringem as dependências entre pacotes e subsistemas, reduzindo o grau de acoplamento entre eles, o sistema fica mais potente. Ela tolera mudanças.

À medida que novos elementos do modelo são adicionados ao sistema, os pacotes existentes podem crescer muito para serem gerenciados por uma única equipe: é necessário dividir o pacote em diversas partes que sejam bem coesas dentro dele, mas acopladas com uma certa flexibilidade entre os pacotes. Essa tarefa pode ser complicada - talvez seja difícil colocar alguns elementos em um pacote específico porque são usados por elementos de outros pacotes. Existem duas soluções possíveis: divida o elemento em diversos objetos, um em cada pacote (isso funciona nos casos em que o elemento possui várias 'personalidades' ou conjuntos de responsabilidades distintas), ou mova o elemento para um pacote em uma camada inferior, na qual todos os elementos de níveis mais altos podem depender dele igualmente.

À medida que a complexidade do sistema aumenta, é necessário um número maior de camadas para obter uma estrutura que possa ser mantida e compreendida. No entanto, não é comum haver mais do que 7 a 10 camadas até nos maiores sistemas, já que a complexidade aumenta e a compreensão diminui com o número de camadas.

O exemplo a seguir mostra uma divisão em camadas, incluindo camadas de middleware e software do Sistema:

Exemplo de divisão em camadas de pacote para um aplicativo Java/baseado na Web. Observação: normalmente, as dependências no pacote TCP/IP não são modeladas explicitamente à medida que o uso dos serviços TCP/IP é encapsulado na Máquina Virtual Java, no java.rmi e no Navegador da Web. Elas são indicadas aqui apenas para fins de ilustração.

Atribua aos indivíduos ou equipes responsabilidades pelos subsistemas e camadas. Uma única pessoa (se o escopo for reduzido) ou uma equipe (se o escopo for amplo) poderá ficar responsável por cada pacote ou subsistema.

Atualizar a Visão Lógica

Quando classes, pacotes e subsistemas (elementos do modelo) forem importantes do ponto de vista da arquitetura, deverão ser incluídos na seção Visão Lógica do Artefato: Documento de Arquitetura de Software. Isso assegurará que os novos elementos significativos do ponto de vista da arquitetura sejam informados aos outros membros da equipe do projeto.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process