Estratégias de Design
Estratégia de cima para baixo
A estratégia de cima para baixo usa a abordagem modular para desenvolver o design de um sistema. É assim chamado porque começa do módulo de nível superior ou superior e segue em direção aos módulos de nível inferior.
Nesta técnica, o módulo de nível mais alto ou módulo principal para desenvolver o software é identificado. O módulo principal é dividido em vários submódulos ou segmentos menores e mais simples com base na tarefa executada por cada módulo. Então, cada submódulo é subdividido em vários submódulos do próximo nível inferior. Este processo de divisão de cada módulo em vários submódulos continua até que os módulos de nível mais baixo, que não podem ser subdivididos, não sejam identificados.
Estratégia Bottom-Up
A Estratégia Bottom-Up segue a abordagem modular para desenvolver o design do sistema. É assim chamado porque começa a partir dos módulos de nível inferior ou mais básico e avança para os módulos de nível mais alto.
Nesta técnica,
Os módulos no nível mais básico ou mais baixo são identificados.
Esses módulos são agrupados com base na função executada por cada módulo para formar os próximos módulos de nível superior.
Em seguida, esses módulos são combinados para formar os próximos módulos de nível superior.
Este processo de agrupar vários módulos mais simples para formar módulos de nível superior continua até que o módulo principal do processo de desenvolvimento do sistema seja alcançado.
Design Estruturado
O projeto estruturado é uma metodologia baseada em fluxo de dados que ajuda a identificar a entrada e a saída do sistema em desenvolvimento. O principal objetivo do projeto estruturado é minimizar a complexidade e aumentar a modularidade de um programa. O projeto estruturado também ajuda a descrever os aspectos funcionais do sistema.
No projeto estruturado, as especificações do sistema atuam como uma base para representar graficamente o fluxo de dados e a sequência de processos envolvidos no desenvolvimento de um software com a ajuda de DFDs. Depois de desenvolver os DFDs para o sistema de software, a próxima etapa é desenvolver o gráfico de estrutura.
Modularização
O design estruturado divide o programa em módulos pequenos e independentes. Eles são organizados de cima para baixo com os detalhes mostrados na parte inferior.
Assim, o design estruturado usa uma abordagem chamada Modularização ou decomposição para minimizar a complexidade e gerenciar o problema subdividindo-o em segmentos menores.
Advantages
- As interfaces críticas são testadas primeiro.
- Ele fornece abstração.
- Ele permite que vários programadores trabalhem simultaneamente.
- Ele permite a reutilização de código.
- Ele fornece controle e melhora o moral.
- Facilita a identificação da estrutura.
Gráficos Estruturados
Os gráficos estruturados são uma ferramenta recomendada para projetar sistemas modulares de cima para baixo que definem os vários módulos de desenvolvimento do sistema e a relação entre cada módulo. Mostra o módulo do sistema e sua relação entre eles.
Consiste em um diagrama que consiste em caixas retangulares que representam os módulos, setas de conexão ou linhas.
Control Module - É um módulo de nível superior que direciona os módulos de nível inferior, chamados subordinate modules.
Library Module - É um módulo reutilizável e pode ser chamado a partir de mais de um ponto no gráfico.
Temos duas abordagens diferentes para projetar um gráfico estruturado -
Transform-Centered Structured Charts - Eles são usados quando todas as transações seguem o mesmo caminho.
Transaction–Centered Structured Charts - Eles são usados quando todas as transações não seguem o mesmo caminho.
Objetivos do uso de fluxogramas de estrutura
Para encorajar um design de cima para baixo.
Para apoiar o conceito de módulos e identificar os módulos apropriados.
Para mostrar o tamanho e a complexidade do sistema.
Para identificar o número de funções e módulos prontamente identificáveis em cada função.
Para descrever se cada função identificável é uma entidade gerenciável ou deve ser dividida em componentes menores.
Fatores que afetam a complexidade do sistema
Para desenvolver software de sistema de boa qualidade, é necessário desenvolver um bom design. Portanto, o foco principal durante o desenvolvimento do design do sistema é a qualidade do design do software. Um projeto de software de boa qualidade é aquele que minimiza a complexidade e os gastos de custo no desenvolvimento de software.
Os dois conceitos importantes relacionados ao desenvolvimento do sistema que ajudam a determinar a complexidade de um sistema são coupling e cohesion.
Acoplamento
O acoplamento é a medida da independência dos componentes. Ele define o grau de dependência de cada módulo de desenvolvimento do sistema em relação ao outro. Na prática, isso significa que quanto mais forte for o acoplamento entre os módulos em um sistema, mais difícil será implementar e manter o sistema.
Cada módulo deve ter uma interface simples e limpa com outros módulos, e que o número mínimo de elementos de dados deve ser compartilhado entre os módulos.
Alto acoplamento
Esses tipos de sistemas têm interconexões com unidades de programa dependentes umas das outras. Mudanças em um subsistema causam alto impacto no outro subsistema.
Baixo acoplamento
Esses tipos de sistemas são constituídos por componentes independentes ou quase independentes. Uma mudança em um subsistema não afeta nenhum outro subsistema.
Medidas de acoplamento
Content Coupling - Quando um componente realmente modifica outro, o componente modificado é completamente dependente da modificação de um.
Common Coupling - Quando a quantidade de acoplamento é reduzida de alguma forma, organizando o design do sistema de forma que os dados sejam acessíveis a partir de um armazenamento de dados comum.
Control Coupling - Quando um componente passa parâmetros para controlar a atividade de outro componente.
Stamp Coupling - Quando as estruturas de dados são usadas para passar informações de um componente para outro.
Data Coupling - Quando apenas os dados são passados, os componentes são conectados por este acoplamento.
Coesão
A coesão é a medida da proximidade da relação entre seus componentes. Ele define a quantidade de dependência dos componentes de um módulo entre si. Na prática, isso significa que o designer de sistemas deve garantir que -
Eles não dividem processos essenciais em módulos fragmentados.
Eles não reúnem processos não relacionados representados como processos no DFD em módulos sem sentido.
Os melhores módulos são aqueles funcionalmente coesos. Os piores módulos são aqueles que são coincidentemente coesos.
O pior grau de coesão
A coesão coincidente é encontrada em um componente cujas partes não estão relacionadas a outro.
Logical Cohesion - É onde várias funções ou elementos de dados relacionados logicamente são colocados no mesmo componente.
Temporal Cohesion - É quando um componente que é usado para inicializar um sistema ou definir variáveis executa várias funções em sequência, mas as funções estão relacionadas pelo tempo envolvido.
Procedurally Cohesion - É quando as funções são agrupadas em um componente apenas para garantir essa ordem.
Sequential Cohesion - É quando a saída de uma parte de um componente é a entrada para a próxima parte dele.