Разработка программного обеспечения — это процесс концептуализации требований к программному обеспечению при реализации программного обеспечения. Разработка программного обеспечения принимает пользовательские требования как проблемы и пытается найти оптимальное решение. В то время как программное обеспечение концептуализируется, составляется план, чтобы найти наилучший возможный дизайн для реализации предполагаемого решения.
Существует несколько вариантов дизайна программного обеспечения. Давайте кратко изучим их:
Структурированный дизайн
Структурированный дизайн — это концептуализация проблемы на несколько хорошо организованных элементов решения. Это в основном связано с дизайном решения. Преимущество структурированного дизайна заключается в том, что оно дает лучшее понимание того, как решается проблема. Структурированный дизайн также позволяет дизайнеру более точно сосредоточиться на проблеме.
Структурированный дизайн в основном основан на стратегии «разделяй и властвуй», где проблема разбита на несколько небольших проблем, и каждая небольшая проблема решается индивидуально до тех пор, пока не будет решена вся проблема.
Небольшие кусочки проблемы решаются с помощью модулей решения. Структурированный дизайн подчеркивает, что эти модули хорошо организованы для достижения точного решения.
Эти модули расположены в иерархии. Они общаются друг с другом. Хороший структурированный дизайн всегда следует некоторым правилам общения между несколькими модулями, а именно:
Сплоченность — группировка всех функционально связанных элементов.
Сцепление — связь между различными модулями.
Хорошая структурированная конструкция имеет высокую когезию и низкое сцепное устройство.
Функционально-ориентированный дизайн
При функционально-ориентированном проектировании система состоит из множества небольших подсистем, известных как функции. Эти функции способны выполнять значительные задачи в системе. Система рассматривается как вид сверху всех функций.
Функционально ориентированный дизайн наследует некоторые свойства структурированного дизайна, где используется методология «разделяй и властвуй».
Этот механизм проектирования разделяет всю систему на более мелкие функции, которые обеспечивают средства абстрагирования путем сокрытия информации и их работы. Эти функциональные модули могут обмениваться информацией между собой посредством передачи информации и использования информации, доступной в глобальном масштабе.
Другой характеристикой функций является то, что когда программа вызывает функцию, она изменяет состояние программы, что иногда не приемлемо для других модулей. Функционально-ориентированное проектирование хорошо работает, когда состояние системы не имеет значения, а программа / функции работают на входе, а не на состоянии.
Процесс проектирования
- Вся система рассматривается как поток данных в системе с помощью диаграммы потока данных.
- DFD показывает, как функции изменяют данные и состояние всей системы.
- Вся система логически разбита на более мелкие блоки, известные как функции, в зависимости от их работы в системе.
- Каждая функция затем описывается в целом.
Объектно-ориентированный дизайн
Объектно-ориентированный дизайн работает вокруг сущностей и их характеристик, а не функций, задействованных в программной системе. Эта стратегия проектирования ориентирована на сущности и ее характеристики. Вся концепция программного решения вращается вокруг заинтересованных лиц.
Давайте посмотрим на важные концепции объектно-ориентированного дизайна:
- Объекты — все объекты, участвующие в разработке решения, называются объектами. Например, человек, банки, компания и клиенты рассматриваются как объекты. У каждой сущности есть некоторые атрибуты, связанные с ней, и есть несколько методов для работы с атрибутами.
-
Классы . Класс — это обобщенное описание объекта. Объект является экземпляром класса. Класс определяет все атрибуты, которые может иметь объект, и методы, которые определяют функциональные возможности объекта.
В проекте решения атрибуты хранятся как переменные, а функциональные возможности определяются с помощью методов или процедур.
- Инкапсуляция. В OOD атрибуты (переменные данных) и методы (операции с данными) объединяются вместе и называются инкапсуляцией. Инкапсуляция не только объединяет важную информацию об объекте, но также ограничивает доступ к данным и методам из внешнего мира. Это называется сокрытием информации.
- Наследование — OOD позволяет подобным классам складываться иерархически, где нижние или подклассы могут импортировать, реализовывать и повторно использовать разрешенные переменные и методы из своих непосредственных суперклассов. Это свойство OOD известно как наследование. Это облегчает определение определенного класса и создание обобщенных классов из определенных.
- Полиморфизм — языки OOD предоставляют механизм, где методам, выполняющим аналогичные задачи, но различающимся по аргументам, можно присвоить одно и то же имя. Это называется полиморфизмом, который позволяет одному интерфейсу выполнять задачи для разных типов. В зависимости от того, как вызывается функция, выполняется соответствующая часть кода.
Классы . Класс — это обобщенное описание объекта. Объект является экземпляром класса. Класс определяет все атрибуты, которые может иметь объект, и методы, которые определяют функциональные возможности объекта.
В проекте решения атрибуты хранятся как переменные, а функциональные возможности определяются с помощью методов или процедур.
Процесс проектирования
Процесс разработки программного обеспечения можно воспринимать как последовательность четко определенных шагов. Хотя он варьируется в зависимости от подхода к проектированию (функционально-ориентированного или объектно-ориентированного, тем не менее он может включать следующие этапы:
- Проект решения создается из требования или ранее использованной системы и / или диаграммы последовательности системы.
- Объекты идентифицируются и группируются в классы по признаку сходства характеристик атрибутов.
- Классовая иерархия и отношения между ними определены.
- Рамки приложения определены.
Подходы к разработке программного обеспечения
Вот два общих подхода к разработке программного обеспечения:
Дизайн сверху вниз
Мы знаем, что система состоит из более чем одной подсистемы и содержит ряд компонентов. Кроме того, эти подсистемы и компоненты могут иметь свой набор подсистем и компонентов и создают иерархическую структуру в системе.
При проектировании сверху вниз вся программная система объединяется в единое целое, а затем разбивается на части, чтобы получить более одной подсистемы или компонента на основе некоторых характеристик. Каждая подсистема или компонент затем рассматривается как система и далее разлагается. Этот процесс продолжается до тех пор, пока не будет достигнут самый низкий уровень системы в иерархии сверху вниз.
Нисходящий проект начинается с обобщенной модели системы и продолжает определять более конкретную ее часть. Когда все компоненты составлены, вся система появляется.
Нисходящий дизайн больше подходит, когда программное решение должно быть разработано с нуля, а конкретные детали неизвестны.
Дизайн снизу вверх
Модель проектирования «снизу вверх» начинается с самых специфических и базовых компонентов. Это происходит с составлением компонентов более высокого уровня с использованием компонентов базового или более низкого уровня. Он продолжает создавать компоненты более высокого уровня, пока желаемая система не развивается как единый компонент. С каждым более высоким уровнем количество абстракций увеличивается.
Восходящая стратегия больше подходит, когда необходимо создать систему из какой-либо существующей системы, где базовые примитивы могут использоваться в более новой системе.
Как нисходящий, так и восходящий подходы не являются практичными по отдельности. Вместо этого используется хорошая комбинация обоих.