Procure subsistemas ou componentes existentes que ofereçam 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 recém-identificadas para aprimorar o ajuste. 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 inclusão de parâmetros na sugestão de interface e, em seguida, fatorar essa 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 a distribuição em fatores, se houver uma correspondência exata com uma interface existente, elimine a interface sugerida e utilize apenas a existente.

Mapeie a sugestão de subsistema para os componentes existentes. Examine os componentes existentes e o conjunto de sugestões de subsistemas. 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 reutilizáveis, considere os mecanismos de design associados ao subsistema; os requisitos de desempenho ou segurança podem desqualificar um componente para reutilização, apesar de uma correspondência perfeita entre as assinaturas da operação.

As definições de códigos e bancos de dados existentes podem ser 'reviradas' para disponibilizar o trabalho efetuado em iterações ou projetos 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, tais componentes costumam ser representados 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 engenharia reversa em um conjunto de classes para representar as estruturas de banco de dados que contêm essas informações. 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 adicionais sobre engenharia reversa de bancos de dados, consulte Diretriz de Produto de Trabalho: Fazer Engenharia Reversa em Bancos de Dados Relacionais. Para saber mais sobre o mapeamento entre classes e tabelas em um banco de dados relacional, consulte Diretriz de Produto de Trabalho: Modelo de Dados.

Como novos elementos foram adicionados ao Modelo de Design, geralmente é necessário reempacotar os elementos desse Modelo. O reempacotamento alcança vários objetivos: ele reduz o acoplamento entre pacotes e aprimora a coesão do conteúdo dos pacotes no 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 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 ferramenta adicional de estruturação chamada 'divisão em camadas' (consulte Diretriz de Produto de Trabalho: 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 determinadas 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 das mudanças nos serviços de implementação de nível inferior. O sistema de camadas fornece uma maneira de 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 se torna mais robusto. Ela tolera mudanças.

À medida que novos elementos de modelo são incluídos no sistema, os pacotes existentes podem crescer muito para serem gerenciados por uma única equipe: o pacote deve ser dividido em vários pacotes que fiquem altamente coesos dentro do pacote mas acoplados livremente entre eles. 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. Há 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 um tanto quanto distintas) ou mova o elemento para um pacote em uma camada inferior, na qual todos os elementos da camada mais alta possam 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. Nota: as dependências no pacote TCP/IP não seriam modeladas explicitamente, visto que o uso dos serviços TCP/IP é encapsulado na Java VM, 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.

Quando classes, pacotes e subsistemas (elementos de modelo) de design forem importantes do ponto de vista arquitetural, deverão ser incluídos na seção Visualização Lógica do Produto de Trabalho: 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.

Além disso, a função de arquiteto de software colabora com a função de engenheiro de processo para fornecer orientação detalhada aos designers e implementadores sobre como utilizar os elementos de design recém-incorporados.