OOAD - Object Oriented Design - Tutorialspoint

Design do sistema

Object-O projeto do sistema orientado envolve a definição do contexto de um sistema seguido pelo desenho da arquitetura do sistema.

Contexto – O contexto de um sistema tem uma parte estática e uma parte 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 do subsistema é representado por pacotes UML. O contexto dinâmico descreve como o sistema interage com seu ambiente. Ele é modelado usando diagramas de caso de uso.
Arquitetura do Sistema – A arquitetura do sistema é projetada com base no contexto do sistema de acordo com os princípios do projeto arquitetônico, bem como o conhecimento do domínio. Tipicamente, um sistema é dividido em camadas e cada camada é decomposta para formar os subsistemas.

Decomposição Orientada a Objetos

Decomposição significa dividir um sistema complexo de grande porte em uma hierarquia de componentes menores com menor complexidade, sobre os princípios de dividir-e-conquistar. Cada componente principal do sistema é chamado de subsistema. A decomposição orientada a objetos identifica objetos individuais autônomos 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.
Permite substituir ou modificar subsistemas sem afetar outros subsistemas.

Identificando a simultaneidade

Concorrência permite que mais de um objeto receba eventos ao mesmo tempo e que mais de uma atividade seja executada simultaneamente. A simultaneidade é identificada e representada no modelo dinâmico.

Para ativar a simultaneidade, a cada elemento concorrente é atribuído um fio de controle separado. Se a simultaneidade estiver em nível de objeto, são atribuídas duas roscas de controle diferentes a dois objetos simultâneos. Se duas operações de um único objeto são de natureza concorrente, então esse objeto é dividido entre diferentes threads.

Concorrência está associada aos problemas de integridade de dados, deadlock e inanição. Portanto, uma estratégia clara precisa ser feita sempre que for necessária a concomitância. Além disso, a concurrência requer ser identificada na própria fase de projeto, e não pode ser deixada para a fase de implementação.

Identificando Padrões

Ao projetar aplicações, algumas soluções comumente aceitas são adotadas para algumas categorias de problemas. Estes são os padrões de desenho. 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 aplicações.

Alguns padrões de desenho comumente usados são –

Padrão de fachada
Padrão de separação da vista do modelo
Padrão do servidor
Modelo de padrão do controlador de visualização
Publicar padrão de subscrição
Padrão de proxy

Controlar eventos

Desenho do sistema, os eventos que podem ocorrer nos objetos do sistema precisam ser identificados e tratados adequadamente.

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, nomeadamente –

Sinal Event – Um objecto nomeado lançado por um objecto e apanhado por outro objecto.
Call Event – Um evento sincrónico que representa o envio de uma operação.
Time Event – Um evento representando a passagem do tempo.
Change Event – Um evento representando a mudança de estado.

Handling Boundary Conditions

A fase de projeto do sistema precisa abordar a inicialização e a finalização do sistema como um todo, assim como cada subsistema. Os diferentes aspectos que estão documentados são os seguintes –

O arranque do sistema, ou seja, a transição do sistema do estado não inicializado para o estado estável.
>
A terminação do sistema, ou seja o fechamento de todos os fios em execução, a limpeza dos recursos e as mensagens a serem enviadas.
A configuração inicial do sistema e a reconfiguração do sistema quando necessário.
A previsão de falhas ou finalização indesejada do sistema.

Condições limite são modeladas usando casos de uso limite.

Desenho do objeto

Após a hierarquia dos subsistemas ter sido desenvolvida, os objetos no sistema são identificados e seus detalhes são desenhados. Aqui, o projetista detalha a estratégia escolhida durante o projeto do sistema. A ênfase passa dos conceitos do domínio da aplicação para os conceitos do computador. Os objetos identificados durante a análise são gravados para implementação com o objetivo de minimizar o tempo de execução, consumo de memória e custo total.

Objet design inclui as seguintes fases –

Object identification
Object representation, ou seja construção de modelos de design

Classificação de operações

Design de algoritmos

Design de relações

Implantação de controle para interações externas

Classes de pacotes e associações em módulos

Identificação de objetos

O primeiro passo do design de objetos é a identificação de objetos. Os objetos identificados nas fases de análise orientada a objetos são agrupados em classes e refinados para que sejam adequados à implementação real.

As funções desta fase são –

>
Identificando e refinando as classes em cada subsistema ou pacote

>

Definindo as ligações e associações entre as classes

>

>
Desenhando as associações hierárquicas entre as classes, ou seja a generalização/especialização e heranças
Desenhar agregações

Representação abjeta

Quando as classes são identificadas, elas precisam ser representadas usando técnicas de modelagem de objetos. Esta etapa envolve essencialmente a construção de diagramas UML.

Existem dois tipos de modelos de desenho que precisam ser produzidos –

Static Models – Para descrever a estrutura estática de um sistema usando diagramas de classes e diagramas de objetos.
Modelos Dinâmicos – Para descrever a estrutura dinâmica de um sistema e mostrar a interação entre classes usando diagramas de interação e diagramas de estados.

Classificação de Operações

Neste passo, a operação a ser realizada nos objetos é definida 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 estados de cada objeto no sistema é desenvolvido.
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 ações principais são expandidas para diagramas de fluxo de dados.

Desenho de algoritmo

As operações nos objetos são definidas usando algoritmos. Um algoritmo é um procedimento por etapas que resolve o problema estabelecido em uma operação. Os algoritmos focam-se em como deve ser feito.

Pode haver mais do que um algoritmo correspondente a uma dada operação. Uma vez identificados os algoritmos alternativos, o algoritmo ótimo é selecionado para o domínio do problema em questão. As métricas para a escolha do algoritmo ótimo são –

Computational Complexity – Complexidade determina a eficiência de um algoritmo em termos de tempo de computação e requisitos de memória.
Flexibilidade – Flexibilidade determina se o algoritmo escolhido pode ser implementado adequadamente, sem perda de adequação em vários ambientes.
Understandability – Isto determina se o algoritmo escolhido é de fácil compreensão e implementação.

Desenho de Relacionamentos

A estratégia para implementar os relacionamentos precisa ser definida durante a fase de projeto do objeto. As principais relações que são abordadas compreendem associações, agregações e heranças.

O projetista deve fazer o seguinte em relação às associações –

Identificar se uma associação é unidirecional ou bidirecional.
Analizar o caminho das associações e actualizá-las se necessário.
>
Implementar as associações como um objecto distinto, no caso de muitas relações; ou como uma ligação a outro objecto, no caso de relações um-para-um ou um-para-muitos.

Regramentar heranças, o designer deve fazer o seguinte –

Ajustar as classes e suas associações.
>
Identificar classes abstratas.

>
Ajustar as classes e suas associações.

>

Implementação do controle

O designer de objetos pode incorporar refinamentos na estratégia do modelo de gráfico de estados. No design do sistema, é feita uma estratégia básica para a realização do modelo dinâmico. Durante o projeto do objeto, esta estratégia é apropriadamente embelezada para uma implementação apropriada.

As abordagens para implementação do modelo dinâmico são –

Representar o Estado como um Local dentro de um Programa – Esta é a abordagem tradicional guiada por procedimentos onde o local 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 seqüência de instruções, os ramos formam as condições e os caminhos para trás formam os loops ou iterações.
State Machine Engine – Esta abordagem representa diretamente uma máquina de estado através de uma classe de motor de máquina de estado. Esta classe executa a máquina de estado através de um conjunto de transições e ações fornecidas pela aplicação.
Controle como Tarefas Concorrentes – Nesta abordagem, um objeto é implementado como uma tarefa na linguagem de programação ou no sistema operacional. Aqui, um evento é implementado como uma chamada inter-tarefa. Ele preserva a concorrência inerente de objetos reais.

Packaging Classes

Em qualquer projeto grande, a partição meticulosa de uma implementação em módulos ou pacotes é importante. Durante o projeto de objetos, classes e objetos são agrupados em pacotes para permitir que múltiplos grupos trabalhem cooperativamente em um projeto.

Os diferentes aspectos do empacotamento são –

Oculta de Informações Internas da Vista Externa – Permite que uma classe seja vista como uma “caixa preta” e permite que a implementação de uma 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 estiver organizado em um plano consistente e todas as suas partes estiverem intrinsecamente relacionadas para que sirvam a um objetivo comum.
Construção de Módulos Físicos – As seguintes diretrizes ajudam na construção de módulos físicos –
- Classes em um módulo devem representar coisas ou componentes semelhantes no mesmo objeto composto.
  
  >
- As classes ligadas entre si devem estar no mesmo módulo.
  
  >
- >
  As classes não ligadas ou ligadas fracamente devem ser colocadas em módulos separados.
  
  >
- Os módulos devem ter uma 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 módulos deve ser mínima.

Otimização do design

O modelo de análise captura as informações lógicas sobre o sistema, enquanto o modelo de design adiciona detalhes para suportar o acesso eficiente às informações. Antes de um design ser implementado, ele deve ser otimizado de forma a 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 projeto não deve ser excessiva, pois a facilidade de implementação, a manutenção e a extensibilidade também são preocupações importantes. É frequentemente visto que um projeto perfeitamente otimizado é mais eficiente, mas menos legível e reutilizável. Portanto, o projetista deve encontrar um equilíbrio entre os dois.

As várias coisas que podem ser feitas para otimização de design são –

Adicionar associações redundantes
Omitir associações não utilizáveis
Optimização de algoritmos
Guardar atributos derivados para evitar a re-computação de expressões complexas

Adicionar associações redundantes

Optimização de design, é verificado se a derivação de novas associações pode reduzir os custos de acesso. Embora essas associações redundantes possam não acrescentar nenhuma informação, elas podem aumentar a eficiência do modelo geral.

Omissões de associações não utilizáveis

A presença de demasiadas associações pode tornar um sistema indecifrável e, portanto, reduzir a eficiência geral do sistema. Assim, durante a otimização, todas as associações não utilizáveis são removidas.

Optimização de Algoritmos

Em sistemas orientados a objetos, a otimização da estrutura de dados e algoritmos são feitos de forma colaborativa. Uma vez que o desenho da classe está no lugar, as operações e os algoritmos precisam ser otimizados.

Optimização dos algoritmos é obtida por –

Rearranjo da ordem das tarefas computacionais
Reversão da ordem de execução dos loops em relação à estabelecida no modelo funcional
Remoção de caminhos mortos dentro do algoritmo

Saving and Storing of Derived Attributes

Derived attributes are those attributes whose values are computed as a function of other attributes (base attributes). A nova computação dos valores de 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 computadas.

No entanto, isso pode representar anomalias de atualização, ou seja, uma alteração nos valores dos atributos base sem alteração correspondente nos valores dos atributos derivados. Para evitar isso, os seguintes passos são tomados –

A cada atualização do valor do atributo base, o atributo derivado também é recalculado.
Todos os atributos derivados são recalculados e atualizados periodicamente em um grupo, ao invés de após cada atualização.

Documentação de projeto

Documentação é uma parte essencial de qualquer processo de desenvolvimento de software que registra o procedimento de criação do software. As decisões de projeto precisam ser documentadas para qualquer sistema de software não trivial para transmitir o projeto para outros.

Áreas de utilização

Pois um produto secundário, uma boa documentação é indispensável, particularmente nas seguintes áreas –

No desenho 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 testes
Para manutenção do software.

Conteúdo

Uma documentação benéfica deve incluir essencialmente os seguintes conteúdos –

Arquitectura de sistema de alto nível – Diagramas de processo e diagramas de módulos
Retiradas e mecanismos de chaves – Diagramas de classes e diagramas de objectos.
Cenários que ilustram o comportamento dos principais aspectos – Diagramas de comportamento

Características

As características de uma boa documentação são –

Concisar e ao mesmo tempo, sem ambigüidade, consistente, e completo
Rastreável às especificações dos requisitos do sistema
>
Bem estruturado
>
Diagramático em vez de descritivo

OOAD – Object Oriented Design