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

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

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

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

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

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

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

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

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

Coupling - связь между разными модулями.

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

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

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

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

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

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

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

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

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

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

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

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

В проекте решения атрибуты хранятся как переменные, а функциональные возможности определяются с помощью методов или процедур.
Encapsulation - В OOD атрибуты (переменные данных) и методы (операции с данными) объединяются вместе, это называется инкапсуляцией. Инкапсуляция не только связывает вместе важную информацию об объекте, но также ограничивает доступ к данным и методам из внешнего мира. Это называется сокрытием информации.
Inheritance - OOD позволяет подобным классам складываться иерархически, где более низкие или подклассы могут импортировать, реализовывать и повторно использовать разрешенные переменные и методы из своих непосредственных суперклассов. Это свойство OOD известно как наследование. Это упрощает определение конкретного класса и создание обобщенных классов из конкретных.
Polymorphism - Языки OOD предоставляют механизм, в котором методы, выполняющие аналогичные задачи, но различающиеся по аргументам, могут иметь одно и то же имя. Это называется полиморфизмом, который позволяет одному интерфейсу выполнять задачи для разных типов. В зависимости от того, как вызывается функция, выполняется соответствующая часть кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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