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

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

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

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

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

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

• Модули на самом базовом или низшем уровне определены.

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

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

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

Модули на самом базовом или низшем уровне определены.

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

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

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

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

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

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

Модульность

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

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

преимущества

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

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

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

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

• Модуль управления — это модуль более высокого уровня, который направляет модули более низкого уровня, называемые подчиненными модулями .

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

Модуль управления — это модуль более высокого уровня, который направляет модули более низкого уровня, называемые подчиненными модулями .

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

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

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

• Структурированные диаграммы, ориентированные на транзакции — они используются, когда все транзакции не следуют по одному и тому же пути.

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

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

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

• Для поощрения нисходящего дизайна.

• Для поддержки концепции модулей и определения соответствующих модулей.

• Чтобы показать размер и сложность системы.

• Для определения количества легко идентифицируемых функций и модулей внутри каждой функции.

• Чтобы показать, является ли каждая идентифицируемая функция управляемой или должна быть разбита на более мелкие компоненты.

Для поощрения нисходящего дизайна.

Для поддержки концепции модулей и определения соответствующих модулей.

Чтобы показать размер и сложность системы.

Для определения количества легко идентифицируемых функций и модулей внутри каждой функции.

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

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

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

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

Связь

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

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

Высокая связь

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

Низкая связь

Эти типы систем состоят из компонентов, которые являются независимыми или почти независимыми. Изменение в одной подсистеме не влияет ни на одну другую подсистему.

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

• Content Coupling — Когда один компонент фактически изменяет другой, тогда измененный компонент полностью зависит от его модификации.

• Common Coupling (Общая связь) — когда объем связи несколько уменьшается за счет организации дизайна системы, чтобы данные были доступны из общего хранилища данных.

• Control Coupling — когда один компонент передает параметры для управления активностью другого компонента.

• Штемпельная связь — когда структуры данных используются для передачи информации от одного компонента к другому.

• Связь данных — когда передаются только данные, компоненты соединяются этой связью.

Content Coupling — Когда один компонент фактически изменяет другой, тогда измененный компонент полностью зависит от его модификации.

Common Coupling (Общая связь) — когда объем связи несколько уменьшается за счет организации дизайна системы, чтобы данные были доступны из общего хранилища данных.

Control Coupling — когда один компонент передает параметры для управления активностью другого компонента.

Штемпельная связь — когда структуры данных используются для передачи информации от одного компонента к другому.

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

когезия

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

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

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

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

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

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

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

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

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

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

Процедурное единство — это когда функции сгруппированы в компонент только для обеспечения этого порядка.

Последовательная сплоченность — это когда выходные данные из одной части компонента являются входными данными для следующей его части.