Разработка программного обеспечения - Software design

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

Разработка программного обеспечения это процесс, посредством которого агент создает спецификацию программный артефакт предназначен для выполнения цели, используя набор примитивных компонентов и при условии ограничения.[1] Проектирование программного обеспечения может относиться либо к «всей деятельности, связанной с концептуализацией, построением, внедрением, вводом в эксплуатацию и, в конечном итоге, изменением сложных систем», либо к «деятельности, следующей за требования спецификация и до программирование, как ... [в] стилизованном процессе разработки программного обеспечения ".[2]

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

Обзор

Дизайн программного обеспечения - это процесс представления и определения программных решений для одного или нескольких наборов проблем. Одним из основных компонентов разработки программного обеспечения является анализ требований к программному обеспечению (SRA). SRA является частью процесс разработки программного обеспечения это перечисляет технические характеристики используется в программная инженерия. Если программное обеспечение «полуавтоматическое» или ориентированный на пользователя, разработка программного обеспечения может включать дизайн пользовательского опыта давая раскадровка чтобы помочь определить эти характеристики. Если ПО полностью автоматизированный (имеется в виду нет Пользователь или же пользовательский интерфейс ), дизайн программного обеспечения может быть таким же простым, как блок-схема или текст, описывающий запланированную последовательность событий. Также существуют полустандартные методы, например Единый язык моделирования и Основные концепции моделирования. В любом случае некоторые документация плана обычно является продуктом дизайна. Кроме того, дизайн программного обеспечения может быть независимая платформа или же платформенно-зависимый, в зависимости от наличия технологии, используемой для проектирования.

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

Дизайн программного обеспечения - это одновременно и процесс, и модель. Процесс проектирования - это последовательность шагов, которая позволяет разработчику описать все аспекты программного обеспечения для построения. Творческие навыки, прошлый опыт, понимание того, что делает программное обеспечение «хорошим», и общая приверженность качеству - вот примеры решающих факторов успеха для грамотного проектирования. Однако важно отметить, что процесс проектирования не всегда является простой процедурой; модель проекта можно сравнить с архитектурными планами дома. Он начинается с представления всего объекта, который должен быть построен (например, трехмерное изображение дома); медленно, вещь уточняется, чтобы обеспечить руководство для построения каждой детали (например, прокладки сантехники). Точно так же модель проектирования, созданная для программного обеспечения, обеспечивает множество различных представлений о компьютерном программном обеспечении. Основные принципы проектирования позволяют инженеру-программисту ориентироваться в процессе проектирования. Дэвис[3] предлагает набор принципов разработки программного обеспечения, которые были адаптированы и расширены в следующем списке:

  • Процесс проектирования не должен страдать от «туннельного зрения». Хороший дизайнер должен рассмотреть альтернативные подходы, оценивая каждый исходя из требований задачи и имеющихся ресурсов для выполнения работы.
  • Дизайн должен быть прослеживаемым до аналитической модели. Поскольку один элемент модели проекта часто можно проследить до нескольких требований, необходимо иметь средства для отслеживания того, как требования были удовлетворены моделью проекта.
  • В дизайне не стоит изобретать велосипед. Системы конструируются с использованием набора шаблонов проектирования, многие из которых, вероятно, встречались раньше. Эти шаблоны всегда следует выбирать как альтернативу переизобретению. Времени мало, а ресурсы ограничены; время разработки следует вкладывать в представление (действительно новых) идей путем интеграции уже существующих шаблонов (если применимо).
  • Дизайн должен «минимизировать интеллектуальное расстояние» между программным обеспечением и проблемой, как она существует в реальном мире. То есть структура проекта программного обеспечения должна, по возможности, имитировать структуру проблемной области.
  • Дизайн должен быть единообразным и интегрированным. Дизайн является единообразным, если кажется полностью связным. Чтобы достичь этого результата, до начала проектной работы необходимо определить правила стиля и формата для команды дизайнеров. Проект является интегрированным, если при определении интерфейсов между компонентами проекта уделяется внимание.
  • Дизайн должен быть структурирован с учетом изменений. Концепции дизайна, обсуждаемые в следующем разделе, позволяют проекту реализовать этот принцип.
  • Дизайн должен быть структурирован так, чтобы его можно было аккуратно деградировать, даже если встречаются аномальные данные, события или рабочие условия. Хорошо разработанное программное обеспечение никогда не должно «бомбить»; он должен быть разработан с учетом необычных обстоятельств, и если он должен прекратить обработку, он должен сделать это изящным образом.
  • Дизайн - это не кодирование, кодирование - это не дизайн. Даже когда для компонентов программы создаются подробные процедурные проекты, уровень абстракции модели проекта выше, чем у исходного кода. Единственные проектные решения, принимаемые на уровне кодирования, должны касаться мелких деталей реализации, которые позволяют кодировать процедурный дизайн.
  • Качество дизайна следует оценивать в процессе его создания, а не постфактум. Для помощи проектировщику в оценке качества на протяжении всего процесса разработки доступны различные концепции дизайна и меры проектирования.
  • Дизайн следует пересмотреть, чтобы минимизировать концептуальные (семантические) ошибки. Иногда при пересмотре дизайна наблюдается тенденция сосредотачиваться на мелочах, упуская за деревьями лес. Группа разработчиков должна убедиться, что основные концептуальные элементы дизайна (упущения, двусмысленность, несогласованность) были учтены, прежде чем беспокоиться о синтаксисе модели проекта.

Концепции дизайна

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

  1. Абстракция - Абстракция - это процесс или результат обобщения за счет уменьшения информационного содержания концепции или наблюдаемого явления, как правило, для того, чтобы сохранить только ту информацию, которая актуальна для конкретной цели. Это акт представления основных характеристик без включения фоновых деталей или объяснений.
  2. Уточнение - Это процесс разработки. Иерархия разрабатывается путем поэтапной декомпозиции макроскопического описания функции до тех пор, пока не будут достигнуты операторы языка программирования. На каждом шаге одна или несколько инструкций данной программы разбиваются на более подробные инструкции. Абстракция и Уточнение - взаимодополняющие концепции.
  3. Модульность - Архитектура программного обеспечения разделена на компоненты, называемые модулями.
  4. Архитектура программного обеспечения - Это относится к общей структуре программного обеспечения и способам, которыми эта структура обеспечивает концептуальную целостность системы. Хорошая программная архитектура обеспечит хорошую окупаемость инвестиций в отношении желаемого результата проекта, например по производительности, качеству, графику и стоимости.
  5. Иерархия управления - Структура программы, которая представляет организацию программного компонента и подразумевает иерархию управления.
  6. Структурное разделение - Структура программы может быть разделена как по горизонтали, так и по вертикали. Горизонтальные разделы определяют отдельные ветви модульной иерархии для каждой основной функции программы. Вертикальное разбиение предполагает, что управление и работа должны быть распределены сверху вниз в структуре программы.
  7. Структура данных - Это представление логической взаимосвязи между отдельными элементами данных.
  8. Программное обеспечение Процедура - Он ориентирован на обработку каждого модуля в отдельности.
  9. Скрытие информации - Модули должны быть определены и спроектированы таким образом, чтобы информация, содержащаяся в модуле, была недоступна для других модулей, которые не нуждаются в такой информации.

В своей объектной модели Грейди Буч упоминает абстракцию, инкапсуляцию, модуляризацию и иерархию как фундаментальные принципы проектирования программного обеспечения.[4] Аббревиатура PHAME (Принципы иерархии, абстракции, модуляризации и инкапсуляции) иногда используется для обозначения этих четырех фундаментальных принципов.[5]

Соображения по дизайну

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

  • Совместимость - Программное обеспечение может работать с другими продуктами, которые предназначены для взаимодействия с другими продуктами. Например, часть программного обеспечения может быть обратно совместима с более старой версией самого себя.
  • Расширяемость - Новые возможности могут быть добавлены к программному обеспечению без серьезных изменений базовой архитектуры.
  • Модульность - итоговое программное обеспечение включает четко определенные независимые компоненты, что улучшает ремонтопригодность. Затем компоненты могут быть реализованы и протестированы изолированно перед интеграцией для формирования желаемой программной системы. Это позволяет разделить работу в проекте разработки программного обеспечения.
  • Отказоустойчивость - Программное обеспечение устойчиво к отказу компонентов и способно восстанавливаться после них.
  • Ремонтопригодность - Мера того, насколько легко могут быть выполнены исправления ошибок или функциональные модификации. Высокая ремонтопригодность может быть результатом модульности и расширяемости.
  • Надежность (Долговечность программного обеспечения ) - Программное обеспечение способно выполнять требуемую функцию в указанных условиях в течение определенного периода времени.
  • Возможность повторного использования - Возможность использовать некоторые или все аспекты уже существующего программного обеспечения в других проектах практически без изменений.
  • Надежность - Программное обеспечение способно работать в условиях стресса или допускать непредсказуемые или неверные данные. Например, он может быть разработан с учетом условий нехватки памяти.
  • Безопасность - Программное обеспечение способно противостоять враждебным действиям и влияниям.
  • Удобство использования - Программное обеспечение пользовательский интерфейс должен быть пригоден для использования для своего целевого пользователя / аудитории. Значения по умолчанию для параметров должны быть выбраны так, чтобы они были хорошим выбором для большинства пользователей.[6]
  • Спектакль - Программное обеспечение выполняет свои задачи в приемлемые для пользователя сроки и не требует слишком много памяти.
  • Портативность - Программное обеспечение должно использоваться в различных условиях и средах.
  • Масштабируемость - Программное обеспечение хорошо адаптируется к увеличению объема данных, добавленным функциям или количеству пользователей.

Язык моделирования

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

Шаблоны проектирования

Разработчик или архитектор программного обеспечения может определить проблему дизайна, которую уже посещали и, возможно, даже решали другие в прошлом. Шаблон или шаблон, описывающий решение общей проблемы, известен как шаблон дизайна. Повторное использование таких шаблонов может помочь ускорить процесс разработки программного обеспечения.[8]

Техника

Сложность использования термина «дизайн» по отношению к программному обеспечению заключается в том, что в некотором смысле исходный код программы является дизайн программы, которую он производит. В той степени, в которой это правда, «дизайн программного обеспечения» относится к дизайну дизайна. Эдсгер В. Дейкстра назвал это наслоение семантических уровней "радикальной новизной" компьютерного программирования,[9] и Дональд Кнут использовал свой опыт написания TeX чтобы описать тщетность попытки разработать программу до ее реализации:

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

использование

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

Смотрите также

Рекомендации

  1. ^ Ральф П. и Ванд Ю. (2009). Предложение по формальному определению концепции дизайна. В Lyytinen, K., Loucopoulos, P., Милопулос, Дж., и Робинсон, У., редакторы, Design Requirements Workshop (LNBIP 14), стр. 103–136. Springer-Verlag, p. 109 Дои:10.1007/978-3-540-92966-6_6.
  2. ^ Фриман, Питер; Дэвид Харт (2004). «Наука о проектировании программно-интенсивных систем». Коммуникации ACM. 47 (8): 19–21 [20]. Дои:10.1145/1012037.1012054. S2CID  14331332.
  3. ^ Дэвис, А: «201 Принцип разработки программного обеспечения», МакГроу Хилл, 1995.
  4. ^ Буч, Гради; и другие. (2004). Объектно-ориентированный анализ и дизайн с приложениями (3-е изд.). Массачусетс, США: Аддисон Уэсли. ISBN  0-201-89551-X. Получено 30 января 2015.
  5. ^ Сурьянараяна, Гириш (ноябрь 2014 г.). Рефакторинг для разработки программного обеспечения. Морган Кауфманн. п. 258. ISBN  978-0128013977.
  6. ^ Кэрролл, Джон, изд. (1995). Сценарно-ориентированное проектирование: видение работы и технологий в разработке системы. Нью-Йорк: Джон Вили и сыновья. ISBN  0471076597.
  7. ^ Белл, Майкл (2008). «Введение в сервис-ориентированное моделирование». Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов. Wiley & Sons. ISBN  978-0-470-14111-3.
  8. ^ Джудит Бишоп. «Шаблоны проектирования C # 3.0: используйте возможности C # 3.0 для решения реальных проблем». Книги по C # от O'Reilly Media. Получено 2012-05-15. Если вы хотите ускорить разработку своих .NET-приложений, вы готовы к шаблонам проектирования C # - элегантным, общепринятым и проверенным способам решения общих проблем программирования.
  9. ^ Дейкстра, Э. В. (1988). «О жестокости преподавания информатики». Получено 2014-01-10.
  10. ^ Кнут, Дональд Э. (1989). «Замечания об ошибках TeX» (PDF).
  11. ^ Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A 10-Year Perspective: Springer-Verlag, 2009, pp. 103-136

^Роджер С. Прессман (2001). Программная инженерия: подход практикующего специалиста. Макгроу-Хилл. ISBN  0-07-365578-3.