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

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

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

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

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

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

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

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

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

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

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

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

Параллелизм

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

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

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

пример

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

Связь и сплоченность

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

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

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

Есть семь типов сплоченности, а именно -

Co-incidental cohesion -Это незапланированная и случайная сплоченность, которая может быть результатом разбивки программы на более мелкие модули ради модульности. Поскольку это не запланировано, это может сбить с толку программистов и обычно не принимается.
Logical cohesion - Когда логически категоризированные элементы объединяются в модуль, это называется логической связностью.
Temporal Cohesion - Когда элементы модуля организованы таким образом, что они обрабатываются в один и тот же момент времени, это называется временной связностью.
Procedural cohesion - Когда элементы модуля группируются вместе, которые выполняются последовательно для выполнения задачи, это называется процедурной связностью.
Communicational cohesion - Когда элементы модуля сгруппированы вместе, которые выполняются последовательно и работают с одними и теми же данными (информацией), это называется коммуникационной связностью.
Sequential cohesion - Когда элементы модуля группируются, потому что выход одного элемента служит входом для другого и так далее, это называется последовательной связью.
Functional cohesion - Это считается высшей степенью сплоченности, и это очень ожидаемо. Элементы модуля в функциональной сплоченности сгруппированы, потому что все они вносят вклад в одну четко определенную функцию. Его также можно использовать повторно.

Связь

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

Есть пять уровней сцепления, а именно -

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

В идеале лучшим вариантом считается отсутствие сцепления.

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

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

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

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

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