OOAD - Design Orientado a Objetos
Após a fase de análise, o modelo conceitual é desenvolvido em um modelo orientado a objetos usando design orientado a objetos (OOD). No OOD, os conceitos independentes de tecnologia no modelo de análise são mapeados em classes de implementação, as restrições são identificadas e as interfaces são projetadas, resultando em um modelo para o domínio da solução. Em suma, uma descrição detalhada é construída especificando como o sistema deve ser construído em tecnologias concretas
Os estágios do design orientado a objetos podem ser identificados como -
- Definição do contexto do sistema
- Projetando a arquitetura do sistema
- Identificação dos objetos no sistema
- Construção de modelos de design
- Especificação de interfaces de objetos
Projeto de sistema
O projeto de sistema orientado a objetos envolve a definição do contexto de um sistema, seguido pelo projeto da arquitetura do sistema.
Context- O contexto de um sistema tem uma parte estática e outra dinâmica. O contexto estático do sistema é projetado usando um diagrama de blocos simples de todo o sistema, que é expandido em uma hierarquia de subsistemas. O modelo de subsistema é representado por pacotes UML. O contexto dinâmico descreve como o sistema interage com seu ambiente. É modelado usandouse case diagrams.
System Architecture- A arquitetura do sistema é projetada com base no contexto do sistema de acordo com os princípios do projeto de arquitetura, bem como do conhecimento do domínio. Normalmente, um sistema é particionado em camadas e cada camada é decomposta para formar os subsistemas.
Decomposição Orientada a Objetos
Decomposição significa dividir um grande sistema complexo em uma hierarquia de componentes menores com complexidades menores, com base nos princípios de dividir e conquistar. Cada componente principal do sistema é chamado de subsistema. A decomposição orientada a objetos identifica objetos autônomos individuais em um sistema e a comunicação entre esses objetos.
As vantagens da decomposição são -
Os componentes individuais são de menor complexidade e, portanto, mais compreensíveis e gerenciáveis.
Permite a divisão da força de trabalho com habilidades especializadas.
Ele permite que subsistemas sejam substituídos ou modificados sem afetar outros subsistemas.
Identificando Simultaneidade
A simultaneidade permite que mais de um objeto receba eventos ao mesmo tempo e mais de uma atividade seja executada simultaneamente. A simultaneidade é identificada e representada no modelo dinâmico.
Para habilitar a simultaneidade, cada elemento simultâneo é atribuído a um thread de controle separado. Se a simultaneidade estiver no nível do objeto, dois objetos simultâneos serão atribuídos a dois threads de controle diferentes. Se duas operações de um único objeto são simultâneas por natureza, esse objeto é dividido entre diferentes threads.
A simultaneidade está associada aos problemas de integridade de dados, conflito e privação. Portanto, uma estratégia clara precisa ser feita sempre que a simultaneidade for necessária. Além disso, a simultaneidade precisa ser identificada no próprio estágio de design e não pode ser deixada para o estágio de implementação.
Identificando Padrões
Ao projetar aplicativos, algumas soluções comumente aceitas são adotadas para algumas categorias de problemas. Esses são os padrões de design. Um padrão pode ser definido como um conjunto documentado de blocos de construção que podem ser usados em certos tipos de problemas de desenvolvimento de aplicativos.
Alguns padrões de design comumente usados são -
- Padrão de fachada
- Padrão de separação de visualização de modelo
- Padrão do observador
- Padrão de controlador de visualização de modelo
- Publicar padrão de assinatura
- Padrão proxy
Controle de eventos
Durante o projeto do sistema, os eventos que podem ocorrer nos objetos do sistema precisam ser identificados e adequadamente tratados.
Um evento é uma especificação de uma ocorrência significativa que tem uma localização no tempo e no espaço.
Existem quatro tipos de eventos que podem ser modelados, a saber -
Signal Event - Um objeto nomeado lançado por um objeto e pego por outro objeto.
Call Event - Um evento síncrono que representa o despacho de uma operação.
Time Event - Um evento que representa a passagem do tempo.
Change Event - Um evento que representa a mudança de estado.
Condições de limite de manuseio
A fase de design do sistema precisa abordar a inicialização e o encerramento do sistema como um todo, bem como de cada subsistema. Os diferentes aspectos documentados são os seguintes -
A inicialização do sistema, ou seja, a transição do sistema do estado não inicializado para o estado estacionário.
O encerramento do sistema, ou seja, o encerramento de todos os threads em execução, limpeza de recursos e as mensagens a serem enviadas.
A configuração inicial do sistema e a reconfiguração do sistema quando necessário.
Prevenção de falhas ou encerramento indesejado do sistema.
As condições de limite são modeladas usando casos de uso de limite.
Projeto de Objeto
Depois que a hierarquia dos subsistemas foi desenvolvida, os objetos no sistema são identificados e seus detalhes são projetados. Aqui, o designer detalha a estratégia escolhida durante o design do sistema. A ênfase muda de conceitos de domínio de aplicativo para conceitos de computador. Os objetos identificados durante a análise são gravados para implementação com o objetivo de minimizar o tempo de execução, o consumo de memória e o custo geral.
O design do objeto inclui as seguintes fases -
- Identificação de objeto
- Representação de objeto, ou seja, construção de modelos de design
- Classificação das operações
- Projeto de algoritmo
- Desenho de relacionamentos
- Implementação de controle para interações externas
- Classes de pacotes e associações em módulos
Identificação de Objeto
A primeira etapa do projeto do objeto é a identificação do objeto. Os objetos identificados nas fases de análise orientada a objetos são agrupados em classes e refinados de forma que sejam adequados para implementação real.
As funções deste estágio são -
Identificar e refinar as classes em cada subsistema ou pacote
Definindo os links e associações entre as classes
Desenhar as associações hierárquicas entre as classes, ou seja, a generalização / especialização e as heranças
Projetando agregações
Representação de Objeto
Uma vez que as classes são identificadas, elas precisam ser representadas usando técnicas de modelagem de objetos. Este estágio envolve essencialmente a construção de diagramas UML.
Existem dois tipos de modelos de design que precisam ser produzidos -
Static Models - Descrever a estrutura estática de um sistema usando diagramas de classes e diagramas de objetos.
Dynamic Models - Descrever a estrutura dinâmica de um sistema e mostrar a interação entre as classes usando diagramas de interação e diagramas de estado-gráfico.
Classificação de Operações
Nesta etapa, as operações a serem realizadas nos objetos são definidas pela combinação dos três modelos desenvolvidos na fase OOA, a saber, modelo de objeto, modelo dinâmico e modelo funcional. Uma operação especifica o que deve ser feito e não como deve ser feito.
As seguintes tarefas são realizadas em relação às operações -
O diagrama de transição de estado de cada objeto no sistema é desenvolvido.
As operações são definidas para os eventos recebidos pelos objetos.
Casos em que um evento aciona outros eventos no mesmo objeto ou em objetos diferentes são identificados.
As suboperações dentro das ações são identificadas.
As principais ações são expandidas para diagramas de fluxo de dados.
Projeto de Algoritmo
As operações nos objetos são definidas por meio de algoritmos. Um algoritmo é um procedimento passo a passo que resolve o problema estabelecido em uma operação. Os algoritmos se concentram em como isso deve ser feito.
Pode haver mais de um algoritmo correspondente a uma determinada operação. Uma vez que os algoritmos alternativos são identificados, o algoritmo ótimo é selecionado para o domínio de problema dado. As métricas para escolher o algoritmo ideal são -
Computational Complexity - A complexidade determina a eficiência de um algoritmo em termos de tempo de computação e requisitos de memória.
Flexibility - A flexibilidade determina se o algoritmo escolhido pode ser implementado adequadamente, sem perda de adequação em vários ambientes.
Understandability - Isso determina se o algoritmo escolhido é fácil de entender e implementar.
Desenho de Relacionamentos
A estratégia para implementar os relacionamentos precisa ser definida durante a fase de design do objeto. Os principais relacionamentos que são tratados incluem associações, agregações e heranças.
O designer deve fazer o seguinte em relação às associações -
Identifique se uma associação é unidirecional ou bidirecional.
Analise o caminho das associações e atualize-as se necessário.
Implemente as associações como um objeto distinto, no caso de relacionamentos muitos para muitos; ou como um link para outro objeto no caso de relacionamentos um-para-um ou um-para-muitos.
Em relação às heranças, o designer deve fazer o seguinte -
Ajuste as classes e suas associações.
Identifique classes abstratas.
Faça provisões para que os comportamentos sejam compartilhados quando necessário.
Implementação de Controle
O designer de objeto pode incorporar refinamentos na estratégia do modelo de gráfico de estado. No projeto do sistema, uma estratégia básica para realizar o modelo dinâmico é feita. Durante o projeto do objeto, esta estratégia é adequadamente embelezada para uma implementação apropriada.
As abordagens para implementação do modelo dinâmico são -
Represent State as a Location within a Program- Esta é a abordagem orientada por procedimento tradicional em que a localização de controle define o estado do programa. Uma máquina de estado finito pode ser implementada como um programa. Uma transição forma uma instrução de entrada, o caminho de controle principal forma a sequência de instruções, os ramos formam as condições e os caminhos anteriores formam os loops ou iterações.
State Machine Engine- Essa abordagem representa diretamente uma máquina de estado por meio de uma classe de mecanismo de máquina de estado. Essa classe executa a máquina de estado por meio de um conjunto de transições e ações fornecidas pelo aplicativo.
Control as Concurrent Tasks- Nesta abordagem, um objeto é implementado como uma tarefa na linguagem de programação ou no sistema operacional. Aqui, um evento é implementado como uma chamada entre tarefas. Ele preserva a simultaneidade inerente de objetos reais.
Aulas de embalagem
Em qualquer projeto grande, o particionamento meticuloso de uma implementação em módulos ou pacotes é importante. Durante o design do objeto, classes e objetos são agrupados em pacotes para permitir que vários grupos trabalhem cooperativamente em um projeto.
Os diferentes aspectos da embalagem são -
Hiding Internal Information from Outside View - Permite que uma classe seja vista como uma “caixa preta” e permite que a implementação da classe seja alterada sem exigir que nenhum cliente da classe modifique o código.
Coherence of Elements - Um elemento, como uma classe, uma operação ou um módulo, é coerente se for organizado em um plano consistente e todas as suas partes estiverem intrinsecamente relacionadas para servir a um objetivo comum.
Construction of Physical Modules - As diretrizes a seguir ajudam na construção de módulos físicos -
As classes em um módulo devem representar coisas ou componentes semelhantes no mesmo objeto composto.
As classes estreitamente conectadas devem estar no mesmo módulo.
Classes desconectadas ou fracamente conectadas devem ser colocadas em módulos separados.
Os módulos devem ter boa coesão, ou seja, alta cooperação entre seus componentes.
Um módulo deve ter baixo acoplamento com outros módulos, ou seja, a interação ou interdependência entre os módulos deve ser mínima.
Otimização de Design
O modelo de análise captura as informações lógicas sobre o sistema, enquanto o modelo de design adiciona detalhes para oferecer suporte ao acesso eficiente às informações. Antes de um design ser implementado, ele deve ser otimizado para tornar a implementação mais eficiente. O objetivo da otimização é minimizar o custo em termos de tempo, espaço e outras métricas.
No entanto, a otimização do design não deve ser excessiva, pois facilidade de implementação, facilidade de manutenção e extensibilidade também são preocupações importantes. É comum ver que um design perfeitamente otimizado é mais eficiente, mas menos legível e reutilizável. Portanto, o designer deve encontrar um equilíbrio entre os dois.
As várias coisas que podem ser feitas para a otimização do design são -
- Adicionar associações redundantes
- Omitir associações não utilizáveis
- Otimização de algoritmos
- Salve atributos derivados para evitar o recálculo de expressões complexas
Adição de Associações Redundantes
Durante a otimização do projeto, é verificado se a derivação de novas associações pode reduzir os custos de acesso. Embora essas associações redundantes não possam adicionar nenhuma informação, elas podem aumentar a eficiência do modelo geral.
Omissão de associações não utilizáveis
A presença de muitas associações pode tornar um sistema indecifrável e, portanto, reduzir a eficiência geral do sistema. Portanto, durante a otimização, todas as associações não utilizáveis são removidas.
Otimização de Algoritmos
Em sistemas orientados a objetos, a otimização da estrutura de dados e algoritmos é feita de forma colaborativa. Uma vez que o design da classe esteja estabelecido, as operações e os algoritmos precisam ser otimizados.
A otimização de algoritmos é obtida por -
- Reorganização da ordem das tarefas computacionais
- Reversão da ordem de execução de loops daquela estabelecida no modelo funcional
- Remoção de caminhos mortos dentro do algoritmo
Salvando e armazenando atributos derivados
Atributos derivados são aqueles atributos cujos valores são calculados em função de outros atributos (atributos básicos). O recálculo dos valores dos atributos derivados sempre que eles são necessários é um procedimento demorado. Para evitar isso, os valores podem ser calculados e armazenados em suas formas calculadas.
No entanto, isso pode representar anomalias de atualização, ou seja, uma alteração nos valores dos atributos básicos sem alteração correspondente nos valores dos atributos derivados. Para evitar isso, as seguintes etapas são executadas -
Com cada atualização do valor do atributo básico, o atributo derivado também é recalculado.
Todos os atributos derivados são recalculados e atualizados periodicamente em um grupo, em vez de após cada atualização.
Documentação de Design
A documentação é uma parte essencial de qualquer processo de desenvolvimento de software que registre o procedimento de fabricação do software. As decisões de design precisam ser documentadas para qualquer sistema de software não trivial para transmitir o design a outros.
Áreas de Uso
Embora seja um produto secundário, uma boa documentação é indispensável, principalmente nas seguintes áreas -
- No projeto de software que está sendo desenvolvido por vários desenvolvedores
- Em estratégias iterativas de desenvolvimento de software
- No desenvolvimento de versões subsequentes de um projeto de software
- Para avaliar um software
- Para encontrar condições e áreas de teste
- Para manutenção do software.
Conteúdo
Uma documentação benéfica deve incluir essencialmente os seguintes conteúdos -
High–level system architecture - Diagramas de processo e diagramas de módulo
Key abstractions and mechanisms - Diagramas de classes e diagramas de objetos.
Scenarios that illustrate the behavior of the main aspects - Diagramas comportamentais
Características
As características de uma boa documentação são -
Conciso e, ao mesmo tempo, inequívoco, consistente e completo
Rastreável de acordo com as especificações de requisitos do sistema
Well-structured
Esquemático em vez de descritivo