Стратегии дизайна

Стратегия сверху вниз

Стратегия «сверху вниз» использует модульный подход для разработки дизайна системы. Он называется так потому, что начинается с модуля верхнего или самого высокого уровня и движется к модулям самого низкого уровня.

В этом методе определяется модуль самого высокого уровня или основной модуль для разработки программного обеспечения. Главный модуль делится на несколько более мелких и простых подмодулей или сегментов в зависимости от задачи, выполняемой каждым модулем. Затем каждый субмодуль подразделяется на несколько субмодулей следующего более низкого уровня. Этот процесс разделения каждого модуля на несколько подмодулей продолжается до тех пор, пока не будут идентифицированы модули самого низкого уровня, которые не могут быть далее подразделены.

Стратегия снизу вверх

Стратегия «снизу-вверх» следует модульному подходу к разработке системы. Он называется так, потому что начинается с модулей самого нижнего или самого базового уровня и движется к модулям самого высокого уровня.

В этой технике

Идентифицируются модули на самом базовом или самом низком уровне.
Эти модули затем группируются вместе на основе функции, выполняемой каждым модулем, для формирования следующих модулей более высокого уровня.
Затем эти модули объединяются в следующие модули более высокого уровня.
Этот процесс группировки нескольких более простых модулей для формирования модулей более высокого уровня продолжается до тех пор, пока не будет достигнут основной модуль процесса разработки системы.

Структурированный дизайн

Структурированный дизайн - это методология, основанная на потоках данных, которая помогает идентифицировать входные и выходные данные разрабатываемой системы. Основная цель структурированного дизайна - минимизировать сложность и повысить модульность программы. Структурированный дизайн также помогает описать функциональные аспекты системы.

При структурированном проектировании системные спецификации служат основой для графического представления потока данных и последовательности процессов, задействованных в разработке программного обеспечения с помощью DFD. После разработки DFD для системы программного обеспечения следующим шагом является разработка структурной схемы.

Модуляризация

Структурированный дизайн разбивает программу на небольшие и независимые модули. Они организованы сверху вниз, а детали показаны внизу.

Таким образом, в структурированном дизайне используется подход, называемый модуляризацией или декомпозицией, для минимизации сложности и решения проблемы путем разделения ее на более мелкие сегменты.

Advantages

В первую очередь тестируются критически важные интерфейсы.
Это обеспечивает абстракцию.
Это позволяет нескольким программистам работать одновременно.
Это позволяет повторно использовать код.
Это обеспечивает контроль и улучшает моральный дух.
Это упрощает идентификацию структуры.

Структурированные диаграммы

Структурированные диаграммы - это рекомендуемый инструмент для проектирования модульных систем сверху вниз, которые определяют различные модули разработки системы и отношения между каждым модулем. Он показывает системный модуль и их отношения между ними.

Он состоит из диаграммы, состоящей из прямоугольных блоков, представляющих модули, соединяющих стрелок или линий.

Control Module - Это модуль более высокого уровня, который управляет модулями более низкого уровня, называемыми subordinate modules.
Library Module - Это многоразовый модуль, который может быть вызван более чем из одной точки диаграммы.

У нас есть два разных подхода к созданию структурированной диаграммы:

Transform-Centered Structured Charts - Они используются, когда все транзакции проходят по одному и тому же пути.
Transaction–Centered Structured Charts - Они используются, когда все транзакции идут по разному.

Цели использования структурных блок-схем

Поощрять нисходящий дизайн.
Поддерживать концепцию модулей и определять соответствующие модули.
Чтобы показать размер и сложность системы.
Для определения количества легко идентифицируемых функций и модулей в каждой функции.
Чтобы показать, является ли каждая идентифицируемая функция управляемым объектом или должна быть разбита на более мелкие компоненты.

Факторы, влияющие на сложность системы

Для разработки системного программного обеспечения хорошего качества необходимо разработать хороший дизайн. Поэтому при разработке дизайна системы основное внимание уделяется качеству проектирования программного обеспечения. Качественный дизайн программного обеспечения - это такой дизайн, который сводит к минимуму сложность и затраты на разработку программного обеспечения.

Двумя важными концепциями, связанными с разработкой системы, которые помогают определить сложность системы, являются: coupling и cohesion.

Связь

Связь - это мера независимости компонентов. Он определяет степень зависимости каждого модуля развития системы от другого. На практике это означает, что чем сильнее связь между модулями в системе, тем сложнее внедрить и поддерживать систему.

Каждый модуль должен иметь простой и понятный интерфейс с другими модулями, а минимальное количество элементов данных должно совместно использоваться модулями.

Высокое сцепление

Системы этого типа имеют взаимосвязи с программными модулями, зависящими друг от друга. Изменения в одной подсистеме сильно влияют на другую подсистему.

Низкое сцепление

Системы этого типа состоят из независимых или почти независимых компонентов. Изменение одной подсистемы не влияет на другие подсистемы.

Меры сцепления

Content Coupling - Когда один компонент фактически изменяет другой, тогда измененный компонент полностью зависит от изменения одного.
Common Coupling - Когда степень связи несколько снижается за счет организации системного дизайна так, чтобы данные были доступны из общего хранилища данных.
Control Coupling - Когда один компонент передает параметры для управления активностью другого компонента.
Stamp Coupling - Когда структуры данных используются для передачи информации от одного компонента к другому.
Data Coupling - Когда передаются только данные, компоненты соединяются этой связью.

Сплоченность

Сплоченность - это мера близости отношений между ее составляющими. Он определяет степень зависимости компонентов модуля друг от друга. На практике это означает, что разработчик системы должен гарантировать, что:

Они не разделяют важные процессы на фрагментированные модули.
Они не собирают воедино несвязанные процессы, представленные как процессы на DFD, в бессмысленные модули.

Лучшие модули - это те, которые функционально связаны. Худшие модули - это те, которые по совпадению связаны.

Худшая степень сплоченности

Случайное сцепление обнаруживается в компоненте, части которого не связаны друг с другом.

Logical Cohesion - Здесь несколько логически связанных функций или элементов данных помещаются в один и тот же компонент.
Temporal Cohesion - Это когда компонент, который используется для инициализации системы или установки переменных, выполняет несколько функций последовательно, но функции связаны по времени.
Procedurally Cohesion - Это когда функции группируются в компонент, чтобы обеспечить этот порядок.
Sequential Cohesion - Это когда выход из одной части компонента является входом для следующей его части.