Учебники

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

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

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

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

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

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

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

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

Сплоченность – группировка всех функционально связанных элементов.

Сцепление – связь между различными модулями.

Хорошая структурированная конструкция имеет высокую когезию и низкое сцепное устройство.

Функционально-ориентированный дизайн

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

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

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

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

Процесс проектирования

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

Объектно-ориентированный дизайн

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

Давайте посмотрим на важные концепции объектно-ориентированного дизайна:

  • Объекты – все объекты, участвующие в разработке решения, называются объектами. Например, человек, банки, компания и клиенты рассматриваются как объекты. У каждой сущности есть некоторые атрибуты, связанные с ней, и есть несколько методов для работы с атрибутами.
  • Классы . Класс – это обобщенное описание объекта. Объект является экземпляром класса. Класс определяет все атрибуты, которые может иметь объект, и методы, которые определяют функциональные возможности объекта.

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

  • Инкапсуляция. В OOD атрибуты (переменные данных) и методы (операции с данными) объединяются вместе и называются инкапсуляцией. Инкапсуляция не только объединяет важную информацию об объекте, но также ограничивает доступ к данным и методам из внешнего мира. Это называется сокрытием информации.
  • Наследование – OOD позволяет подобным классам складываться иерархически, где нижние или подклассы могут импортировать, реализовывать и повторно использовать разрешенные переменные и методы из своих непосредственных суперклассов. Это свойство OOD известно как наследование. Это облегчает определение определенного класса и создание обобщенных классов из определенных.
  • Полиморфизм – языки OOD предоставляют механизм, где методам, выполняющим аналогичные задачи, но различающимся по аргументам, можно присвоить одно и то же имя. Это называется полиморфизмом, который позволяет одному интерфейсу выполнять задачи для разных типов. В зависимости от того, как вызывается функция, выполняется соответствующая часть кода.

Классы . Класс – это обобщенное описание объекта. Объект является экземпляром класса. Класс определяет все атрибуты, которые может иметь объект, и методы, которые определяют функциональные возможности объекта.

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

Процесс проектирования

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

  • Проект решения создается из требования или ранее использованной системы и / или диаграммы последовательности системы.
  • Объекты идентифицируются и группируются в классы по признаку сходства характеристик атрибутов.
  • Классовая иерархия и отношения между ними определены.
  • Рамки приложения определены.

Подходы к разработке программного обеспечения

Вот два общих подхода к разработке программного обеспечения:

Дизайн сверху вниз

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

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

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

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

Дизайн снизу вверх

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

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

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