Учебники

Основы проектирования программного обеспечения

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

Для оценки требований пользователя создается документ SRS (Спецификация требований к программному обеспечению), тогда как для кодирования и реализации необходимы более конкретные и подробные требования с точки зрения программного обеспечения. Вывод этого процесса может быть непосредственно использован для реализации на языках программирования.

Разработка программного обеспечения — это первый шаг в SDLC (жизненный цикл разработки программного обеспечения), который переносит концентрацию с проблемной области на область решения. Он пытается указать, как выполнить требования, указанные в SRS.

Уровни разработки программного обеспечения

Разработка программного обеспечения дает три уровня результатов:

  • Архитектурное проектирование — архитектурное проектирование является высшей абстрактной версией системы. Он идентифицирует программное обеспечение как систему со многими компонентами, взаимодействующими друг с другом. На этом уровне дизайнеры получают представление о предлагаемой области решения.
  • Проектирование высокого уровня. Проектирование высокого уровня разбивает концепцию архитектурного дизайна «один объект-несколько компонентов» на менее абстрагированное представление подсистем и модулей и отображает их взаимодействие друг с другом. Проектирование высокого уровня фокусируется на том, как система вместе со всеми ее компонентами может быть реализована в виде модулей. Он распознает модульную структуру каждой подсистемы и их взаимосвязь и взаимодействие друг с другом.
  • Детальный дизайн — Детальный дизайн имеет дело с частью реализации того, что рассматривается как система и ее подсистемы в предыдущих двух проектах. Более подробно о модулях и их реализациях. Он определяет логическую структуру каждого модуля и их интерфейсы для связи с другими модулями.

Модульность

Модуляризация — это метод разделения программной системы на несколько отдельных и независимых модулей, которые, как ожидается, будут способны выполнять задачу (и) независимо. Эти модули могут работать как базовые конструкции для всего программного обеспечения. Проектировщики, как правило, проектируют модули так, чтобы их можно было выполнять и / или компилировать отдельно и независимо.

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

Преимущество модульности:

  • Меньшие компоненты легче поддерживать
  • Программа может быть разделена на основе функциональных аспектов
  • Желаемый уровень абстракции можно внести в программу
  • Компоненты с высокой когезией могут быть снова использованы повторно
  • Возможно одновременное выполнение
  • Желаемый с точки зрения безопасности

совпадение

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

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

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

пример

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

Сцепление и сцепление

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

когезия

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

Существует семь типов сплоченности, а именно —

  • Случайное сплочение — это незапланированное и случайное сплочение, которое может быть результатом разбиения программы на более мелкие модули для модульности. Поскольку это незапланировано, это может ввести в заблуждение программистов и обычно не принимается.
  • Логическая сплоченность — когда логически категоризированные элементы объединяются в модуль, это называется логической сплоченностью.
  • Временная сплоченность — когда элементы модуля организованы так, что они обрабатываются в один и тот же момент времени, это называется временной сплоченностью.
  • Процедурное единство — когда элементы модуля группируются вместе, которые выполняются последовательно для выполнения задачи, это называется процедурным единством.
  • Коммуникационная сплоченность — когда элементы модуля группируются вместе, которые выполняются последовательно и работают с одними и теми же данными (информацией), это называется коммуникационной сплоченностью.
  • Последовательное сцепление — когда элементы модуля сгруппированы, потому что выход одного элемента служит входом для другого и т. Д., Это называется последовательным сцеплением.
  • Функциональная сплоченность — считается высшей степенью сплоченности, и это очень ожидаемо. Элементы модуля в функциональной связности сгруппированы, потому что все они вносят вклад в одну четко определенную функцию. Это также может быть использовано повторно.

Связь

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

Существует пять уровней сцепления, а именно —

  • Связывание контента. Когда модуль может напрямую обращаться к контенту другого модуля, изменять его или ссылаться на него, это называется связыванием контента.
  • Общая связь — когда несколько модулей имеют доступ для чтения и записи к некоторым глобальным данным, это называется общей или глобальной связью.
  • Управляющая связь. Два модуля называются управляющими, если один из них решает функцию другого модуля или изменяет ход выполнения.
  • Штемпельная связь — когда несколько модулей имеют общую структуру данных и работают с другой ее частью, это называется штемпельной связью.
  • Соединение данных. Соединение данных — это когда два модуля взаимодействуют друг с другом посредством передачи данных (в качестве параметра). Если модуль передает структуру данных в качестве параметра, то принимающему модулю следует использовать все его компоненты.

В идеале ни одна муфта не считается лучшей.

Проверка дизайна

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

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

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

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