Projeto OO: Etapas, Produtos e Padrões

Etapas do Projeto Orientado a Objetos

No projeto OO, duas grandes etapas são necessárias para iniciar a fase de projeto:

1. Organização por Domínio do Problema: Inicialmente, realiza-se uma organização por domínio do problema. Em seguida, os pacotes do domínio são subdivididos em estereótipos. Essa abordagem particiona o modelo de análise, definindo coleções coesas de classes, relacionamentos e comportamentos, que são empacotados em pacotes ou subsistemas.
2. Agrupamento por Estereótipo: Para cada subsistema, as classes são agrupadas de acordo com a função que exercem no sistema (seu estereótipo).

Características dos Subsistemas

• Um subsistema deve possuir uma interface bem definida, através da qual toda comunicação com o restante do sistema ocorre.
• Com exceção de um pequeno número de classes de comunicação, as classes dentro de um subsistema devem colaborar apenas com outras classes deste mesmo subsistema.
• O número de subsistemas deve ser mantido pequeno.

Produtos do Projeto Arquitetural

O projeto arquitetural aloca o modelo essencial de requisitos em uma tecnologia específica. Isso determina quais processos rodarão em quais processadores, onde os dados serão armazenados e quanta comunicação entre processadores será necessária. Alguns dos principais produtos incluem:

• A distribuição geográfica dos requisitos computacionais.
• Os componentes de hardware para as máquinas clientes.
• Os componentes de hardware para as máquinas servidoras.
• A configuração e o número de camadas de hardware cliente-servidor.
• A plataforma de software de implementação (linguagens de codificação e apresentação, sistemas operacionais, mecanismos e linguagens de comunicação em rede e SGBD).
• A localização dos processos.
• A localização dos dados físicos.
• As estratégias de sincronização para dados distribuídos geograficamente.

Critérios para o Projeto de Subsistemas

Ao projetar subsistemas, é crucial considerar os seguintes critérios:

• Projeto de Interfaces: Como os subsistemas interagem entre si.
• Acoplamento: O grau de dependência entre os subsistemas. Um baixo acoplamento é desejável.
• Estilo Arquitetural: O padrão arquitetural a ser seguido (ex: MVC).
• Manutenibilidade: A facilidade de modificar e corrigir o sistema.
• Reusabilidade: A capacidade de reutilizar componentes e padrões em outros projetos.

Padrão Arquitetural MVC

O padrão Model-View-Controller (MVC) visa separar os dados/lógica de negócios (Model) da interface do usuário (View) e do fluxo da aplicação (Controller). Isso permite que a mesma lógica de negócios seja acessada e visualizada através de várias interfaces. Na arquitetura MVC, o Modelo não tem conhecimento das interfaces que exibem seu estado.

Componentes do MVC:

• Modelo (Model): Representa a lógica de negócio e os dados da aplicação.
• Visão (View): É a camada de interface com o usuário. Exibe o estado do modelo e permite que o usuário interaja com a aplicação.
• Controlador (Controller): Recebe os eventos gerados pela interface (View) e os transforma em ações no Modelo, atualizando-o.

"A LÓGICA DE NEGÓCIO NÃO DEVE CONHECER NADA SOBRE AS TELAS QUE EXIBEM SEU ESTADO!"