Estratégias de Design de Software
O design de software é um processo para conceituar os requisitos de software na implementação de software. O design de software considera os requisitos do usuário como desafios e tenta encontrar a solução ideal. Enquanto o software está sendo conceituado, um plano é traçado para encontrar o melhor design possível para implementar a solução pretendida.
Existem várias variantes de design de software. Vamos estudá-los brevemente:
Design Estruturado
O projeto estruturado é uma conceituação do problema em vários elementos bem organizados de solução. Ele está basicamente relacionado ao design da solução. A vantagem do design estruturado é que ele dá uma melhor compreensão de como o problema está sendo resolvido. O projeto estruturado também torna mais simples para o projetista se concentrar no problema com mais precisão.
O projeto estruturado é baseado principalmente na estratégia de 'dividir para conquistar', onde um problema é dividido em vários pequenos problemas e cada pequeno problema é resolvido individualmente até que todo o problema seja resolvido.
As pequenas partes do problema são resolvidas por meio de módulos de solução. Ênfase no projeto estruturado de que esses módulos sejam bem organizados para obter uma solução precisa.
Esses módulos são organizados em hierarquia. Eles se comunicam entre si. Um bom design estruturado sempre segue algumas regras de comunicação entre vários módulos, a saber -
Cohesion - agrupamento de todos os elementos funcionalmente relacionados.
Coupling - comunicação entre diferentes módulos.
Um bom projeto estruturado tem alta coesão e arranjos de baixo acoplamento.
Design Orientado a Função
No projeto orientado a função, o sistema é composto de muitos subsistemas menores conhecidos como funções. Essas funções são capazes de realizar tarefas significativas no sistema. O sistema é considerado uma visão superior de todas as funções.
O design orientado a funções herda algumas propriedades do design estruturado onde a metodologia de dividir para conquistar é usada.
Este mecanismo de design divide todo o sistema em funções menores, o que proporciona meios de abstração ao ocultar a informação e seu funcionamento. Esses módulos funcionais podem compartilhar informações entre si por meio da passagem e utilização de informações disponíveis globalmente.
Outra característica das funções é que quando um programa chama uma função, a função muda o estado do programa, o que às vezes não é aceitável por outros módulos. O design orientado a função funciona bem onde o estado do sistema não importa e o programa / funções funcionam na entrada em vez de em um estado.
Processo de design
- Todo o sistema é visto como os dados fluem no sistema por meio do diagrama de fluxo de dados.
- DFD descreve como as funções alteram os dados e o estado de todo o sistema.
- Todo o sistema é logicamente dividido em unidades menores conhecidas como funções com base em sua operação no sistema.
- Cada função é então descrita de forma ampla.
Design Orientado a Objetos
O design orientado a objetos trabalha em torno das entidades e suas características, em vez de funções envolvidas no sistema de software. Essas estratégias de design se concentram nas entidades e em suas características. Todo o conceito de solução de software gira em torno das entidades envolvidas.
Vejamos os conceitos importantes do Design Orientado a Objetos:
- Objects - Todas as entidades envolvidas no design da solução são conhecidas como objetos. Por exemplo, pessoa, bancos, empresa e clientes são tratados como objetos. Cada entidade possui alguns atributos associados a ela e alguns métodos para executar nos atributos.
Classes - Uma classe é uma descrição generalizada de um objeto. Um objeto é uma instância de uma classe. A classe define todos os atributos que um objeto pode ter e métodos que definem a funcionalidade do objeto.
No desenho da solução, os atributos são armazenados como variáveis e as funcionalidades são definidas por meio de métodos ou procedimentos.
- Encapsulation - No OOD, os atributos (variáveis de dados) e métodos (operação nos dados) são agrupados é chamado de encapsulamento. O encapsulamento não apenas agrupa informações importantes de um objeto, mas também restringe o acesso aos dados e métodos do mundo externo. Isso é chamado de ocultação de informações.
- Inheritance - OOD permite que classes semelhantes sejam empilhadas de maneira hierárquica, onde as classes inferiores ou subclasses podem importar, implementar e reutilizar variáveis e métodos permitidos de suas superclasses imediatas. Esta propriedade do OOD é conhecida como herança. Isso torna mais fácil definir classes específicas e criar classes generalizadas a partir de classes específicas.
- Polymorphism - As linguagens OOD fornecem um mecanismo onde métodos que executam tarefas semelhantes, mas variam em argumentos, podem receber o mesmo nome. Isso é chamado de polimorfismo, que permite que uma única interface execute tarefas para diferentes tipos. Dependendo de como a função é chamada, a respectiva parte do código é executada.
Processo de design
O processo de design de software pode ser percebido como uma série de etapas bem definidas. Embora varie de acordo com a abordagem do projeto (orientado a funções ou orientado a objetos, ainda assim pode ter as seguintes etapas envolvidas:
- Um projeto de solução é criado a partir de requisitos ou sistema usado anteriormente e / ou diagrama de sequência do sistema.
- Os objetos são identificados e agrupados em classes em nome da similaridade nas características dos atributos.
- A hierarquia de classes e a relação entre elas são definidas.
- A estrutura do aplicativo é definida.
Abordagens de design de software
Aqui estão duas abordagens genéricas para o projeto de software:
Design de cima para baixo
Sabemos que um sistema é composto por mais de um subsistema e contém vários componentes. Além disso, esses subsistemas e componentes podem ter seu próprio conjunto de subsistemas e componentes e criar uma estrutura hierárquica no sistema.
O design de cima para baixo pega todo o sistema de software como uma entidade e o decompõe para obter mais de um subsistema ou componente com base em algumas características. Cada subsistema ou componente é então tratado como um sistema e decomposto posteriormente. Esse processo continua em execução até que o nível mais baixo do sistema na hierarquia de cima para baixo seja alcançado.
O design de cima para baixo começa com um modelo generalizado de sistema e continua definindo a parte mais específica dele. Quando todos os componentes são compostos, todo o sistema passa a existir.
O design de cima para baixo é mais adequado quando a solução de software precisa ser projetada do zero e os detalhes específicos são desconhecidos.
Design de baixo para cima
O modelo de design de baixo para cima começa com os componentes mais específicos e básicos. Ele prossegue com a composição de um nível superior de componentes usando componentes de nível básico ou inferior. Ele continua criando componentes de nível superior até que o sistema desejado não seja desenvolvido como um único componente. A cada nível mais alto, a quantidade de abstração é aumentada.
A estratégia bottom-up é mais adequada quando um sistema precisa ser criado a partir de algum sistema existente, onde as primitivas básicas podem ser usadas no sistema mais novo.
Ambas as abordagens de cima para baixo e de baixo para cima não são práticas individualmente. Em vez disso, uma boa combinação de ambos é usada.