Процесс планирования программных решений
Проектирование программного обеспечения — это процесс концептуализации того, как будет работать программная система , прежде чем она будет реализована или модифицирована. [1]
Проектирование программного обеспечения также относится к прямому результату процесса проектирования – концепции того, как программное обеспечение будет работать, которая состоит как из проектной документации, так и из недокументированных концепций.
Проектирование программного обеспечения обычно определяется целями конечной системы и включает в себя решение проблем и планирование, включая как архитектуру программного обеспечения высокого уровня, так и проектирование компонентов и алгоритмов низкого уровня .
С точки зрения каскадного процесса разработки , проектирование программного обеспечения — это деятельность по соблюдению спецификации требований перед кодированием . [2]
Общий процесс
Процесс проектирования позволяет разработчику моделировать различные аспекты программной системы еще до ее создания.
Креативность, прошлый опыт, понимание того, что делает программное обеспечение «хорошим», и приверженность качеству — вот факторы успеха компетентного проектирования. Однако процесс проектирования не всегда является простой процедурой.
Модель программного проектирования можно сравнить с архитектурным планом дома. Планы высокого уровня представляют собой весь дом (например, трехмерная визуализация дома). Планы нижнего уровня содержат рекомендации по построению каждой детали (например, прокладки водопровода). Аналогично, модель проектирования программного обеспечения обеспечивает различные представления предлагаемого программного решения.
Ценить
Документация по проектированию программного обеспечения может быть просмотрена или представлена, чтобы обеспечить возможность корректировки ограничений, спецификаций и даже требований перед кодированием . Редизайн может произойти после проверки запрограммированного моделирования или прототипа . Можно разрабатывать программное обеспечение в процессе кодирования, без анализа плана или требований [3] , но для более сложных проектов это менее осуществимо. Отдельное проектирование перед кодированием позволяет многопрофильным дизайнерам и профильным экспертам (SME) сотрудничать с программистами для создания полезного и технически надежного программного обеспечения.
Анализ требований
Одним из компонентов разработки программного обеспечения является анализ требований к программному обеспечению (SRA). SRA — это часть процесса разработки программного обеспечения , в которой перечислены спецификации, используемые при разработке программного обеспечения .
Результатом анализа являются более мелкие проблемы, которые необходимо решить. Напротив, при проектировании основное внимание уделяется возможностям, поэтому для одной и той же проблемы может существовать несколько проектов. В зависимости от среды дизайн часто меняется, создается ли он на основе надежных фреймворков или реализуется с помощью подходящих шаблонов проектирования .
Артефакты
Процесс проектирования может включать в себя создание таких артефактов, как блок-схема , вариант использования , псевдокод , модель единого языка моделирования и другие фундаментальные концепции моделирования . Для программного обеспечения , ориентированного на пользователя , дизайн может включать в себя проектирование пользовательского опыта с созданием раскадровки , помогающей определить эти спецификации.
Иногда результатом процесса проектирования является проектная документация .
Принципы дизайна
Базовые принципы проектирования позволяют инженеру-программисту ориентироваться в процессе проектирования. Дэвис [4] предлагает набор принципов проектирования программного обеспечения, которые были адаптированы и расширены в следующем списке:
- Процесс проектирования не должен страдать от «туннельного видения». Хороший дизайнер должен рассматривать альтернативные подходы, оценивая каждый на основе требований проблемы и ресурсов, доступных для выполнения работы.
- Проект должен быть прослежен до модели анализа. Поскольку один элемент модели проектирования часто можно связать с несколькими требованиями, необходимо иметь средства для отслеживания того, насколько требования удовлетворяются моделью проектирования.
- Дизайн не должен изобретать велосипед. Системы создаются с использованием набора шаблонов проектирования, многие из которых, вероятно, уже встречались ранее. Эти шаблоны всегда следует выбирать в качестве альтернативы переосмыслению. Времени мало, а ресурсы ограничены; время проектирования следует инвестировать в представление (действительно новых) идей путем интеграции уже существующих шаблонов (когда это применимо).
- Дизайн должен «минимизировать интеллектуальную дистанцию» между программным обеспечением и проблемой, существующей в реальном мире. То есть структура проекта программного обеспечения должна, насколько это возможно, имитировать структуру предметной области.
- Дизайн должен демонстрировать единообразие и интеграцию. Дизайн является единообразным, если он выглядит полностью последовательным. Чтобы достичь этого результата, правила стиля и формата должны быть определены для команды дизайнеров до начала проектной работы. Проект считается интегрированным, если внимательно определить интерфейсы между компонентами проекта.
- Проект должен быть структурирован с учетом изменений. Концепции проектирования, обсуждаемые в следующем разделе, позволяют реализовать этот принцип.
- Конструкция должна быть структурирована таким образом, чтобы постепенное ухудшение характеристик происходило даже при обнаружении аномальных данных, событий или условий эксплуатации. Хорошо спроектированное программное обеспечение никогда не должно «бомбить»; он должен быть разработан с учетом необычных обстоятельств, и если ему необходимо прекратить обработку, он должен сделать это изящным образом.
- Дизайн — это не кодирование, кодирование — это не дизайн. Даже когда для программных компонентов создаются детальные процедурные проекты, уровень абстракции модели проектирования выше, чем исходного кода. Единственные проектные решения, принимаемые на уровне кодирования, должны учитывать мелкие детали реализации, которые позволяют кодировать процедурный дизайн.
- Качество дизайна следует оценивать по мере его создания, а не постфактум. Доступны различные концепции проектирования и меры проектирования, которые помогают дизайнеру оценивать качество на протяжении всего процесса разработки.
- Проект следует пересмотреть, чтобы свести к минимуму концептуальные (семантические) ошибки. Иногда при рассмотрении проекта наблюдается тенденция сосредотачиваться на мелочах, упуская из виду лес за деревьями. Команда дизайнеров должна убедиться, что основные концептуальные элементы проекта (упущения, двусмысленность, несогласованность) учтены, прежде чем беспокоиться о синтаксисе модели проекта.
Концепции дизайна
Концепции дизайна предоставляют дизайнеру основу, на которой можно применять более сложные методы. Был разработан ряд концепций дизайна, в том числе:
- Абстракция . Абстракция — это процесс или результат обобщения путем уменьшения информационного содержания концепции или наблюдаемого явления, обычно для сохранения только информации, которая имеет отношение к определенной цели. Это акт представления существенных особенностей без включения дополнительных деталей или пояснений.
- Уточнение – это процесс разработки. Иерархия разрабатывается путем поэтапного разложения макроскопического описания функции до тех пор, пока не будут получены операторы языка программирования. На каждом шаге одна или несколько инструкций данной программы декомпозируются на более подробные инструкции. Абстракция и уточнение — взаимодополняющие понятия.
- Модульность . Архитектура программного обеспечения разделена на компоненты, называемые модулями.
- Архитектура программного обеспечения . Это относится к общей структуре программного обеспечения и способам, которыми эта структура обеспечивает концептуальную целостность системы. Хорошая архитектура программного обеспечения обеспечит хорошую отдачу от инвестиций в отношении желаемого результата проекта, например, с точки зрения производительности, качества, графика и стоимости.
- Иерархия управления — структура программы, которая представляет организацию программного компонента и подразумевает иерархию управления.
- Структурное разделение. Структуру программы можно разделить по горизонтали и вертикали. Горизонтальные разделы определяют отдельные ветви модульной иерархии для каждой основной функции программы. Вертикальное секционирование предполагает, что управление и работа должны распределяться в структуре программы сверху вниз.
- Структура данных . Это представление логических связей между отдельными элементами данных.
- Программная процедура – ориентирована на обработку каждого модуля в отдельности.
- Сокрытие информации . Модули должны быть определены и спроектированы таким образом, чтобы информация, содержащаяся в модуле, была недоступна для других модулей, которым такая информация не нужна.
В своей объектной модели Грейди Буч упоминает абстракцию , инкапсуляцию , модульность и иерархию как фундаментальные принципы проектирования программного обеспечения. [5] Аббревиатура PHAME (принципы иерархии, абстракции, модульности и инкапсуляции) иногда используется для обозначения этих четырех фундаментальных принципов. [6]
Рекомендации по проектированию
При разработке программного обеспечения необходимо учитывать множество аспектов. Важность каждого фактора должна отражать цели и ожидания, ради удовлетворения которых создается программное обеспечение. Некоторые из этих аспектов:
- Совместимость. Программное обеспечение может работать с другими продуктами, предназначенными для взаимодействия с другим продуктом. Например, часть программного обеспечения может быть обратно совместима со своей более старой версией.
- Расширяемость . В программное обеспечение можно добавлять новые возможности без серьезных изменений базовой архитектуры.
- Модульность — полученное программное обеспечение состоит из четко определенных независимых компонентов, что обеспечивает лучшую удобство обслуживания. Затем компоненты можно было бы реализовать и протестировать по отдельности, прежде чем интегрировать в желаемую программную систему. Это позволяет разделить работу в проекте разработки программного обеспечения.
- Отказоустойчивость . Программное обеспечение устойчиво к сбоям компонентов и способно восстанавливаться после них.
- Ремонтопригодность — показатель того, насколько легко можно выполнить исправление ошибок или функциональные модификации. Высокая ремонтопригодность может быть результатом модульности и расширяемости.
- Надежность ( долговечность программного обеспечения ). Программное обеспечение способно выполнять требуемую функцию при заданных условиях в течение определенного периода времени.
- Возможность повторного использования — возможность использовать некоторые или все аспекты существующего программного обеспечения в других проектах практически без изменений.
- Надежность . Программное обеспечение способно работать в условиях стресса или выдерживать непредсказуемые или неверные входные данные. Например, его можно спроектировать с учетом устойчивости к условиям нехватки памяти.
- Безопасность . Программное обеспечение способно противостоять враждебным действиям и воздействиям.
- Удобство использования . Пользовательский интерфейс программного обеспечения должен быть удобен для использования целевым пользователем/аудиторией. Значения параметров по умолчанию должны быть выбраны так, чтобы они подходили большинству пользователей. [7]
- Производительность . Программное обеспечение выполняет свои задачи в приемлемые для пользователя сроки и не требует слишком много памяти.
- Портативность . Программное обеспечение должно быть пригодным для использования в различных условиях и средах.
- Масштабируемость . Программное обеспечение хорошо адаптируется к увеличению объема данных, добавлению функций или количеству пользователей.
Язык моделирования
Язык моделирования может использоваться для выражения информации, знаний или систем в структуре, которая определяется последовательным набором правил. Эти правила используются для интерпретации компонентов внутри структуры. Язык моделирования может быть графическим или текстовым. Примеры языков графического моделирования для разработки программного обеспечения включают:
Шаблоны проектирования
Разработчик программного обеспечения может определить аспект дизайна, который уже посещался и, возможно, даже решался другими в прошлом. Шаблон или шаблон, описывающий решение общей проблемы, известен как шаблон проектирования . Повторное использование таких шаблонов может увеличить скорость разработки программного обеспечения. [9]
Код как дизайн
Трудность использования термина «проектирование» по отношению к программному обеспечению заключается в том, что в некотором смысле исходный код программы является дизайном программы, которую она создает. В той степени, в которой это верно, «проектирование программного обеспечения» относится к проектированию проекта. Эдсгер В. Дейкстра назвал это наслоение семантических уровней «радикальной новинкой» компьютерного программирования [10] , а Дональд Кнут использовал свой опыт написания TeX , чтобы описать тщетность попыток разработать программу до ее реализации:
T E X был бы полным провалом, если бы я просто уточнил его и не участвовал в полной мере в его первоначальной реализации. Процесс реализации постоянно приводил меня к неожиданным вопросам и новым идеям о том, как можно улучшить исходные спецификации. [11]
Смотрите также
Викискладе есть медиафайлы, связанные с дизайном программного обеспечения .
Рекомендации
- ^ Ральф П. и Ванд Ю. (2009). Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж. и Робинсон В., редакторы, Семинар по требованиям к проектированию (LNBIP 14), стр. 103–136. Шпрингер-Верлаг, с. 109 дои : 10.1007/978-3-540-92966-6_6.
- ^ Фриман, Питер; Дэвид Харт (2004). «Наука проектирования программно-емких систем». Коммуникации АКМ . 47 (8): 19–21 [20]. дои : 10.1145/1012037.1012054. S2CID 14331332.
- ^ Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. Люйтинен К., Лукопулос П., Милопулос Дж. и Робинсон В. (ред.), Разработка требований к проектированию: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103–136.
- ^ Дэвис, А.: «201 принцип разработки программного обеспечения», McGraw Hill, 1995.
- ^ Буч, Грейди; и другие. (2004). Объектно-ориентированный анализ и проектирование с приложениями (3-е изд.). Массачусетс, США: Эддисон Уэсли. ISBN 0-201-89551-Х. Проверено 30 января 2015 г.
- ^ Сурьянараяна, Гириш (ноябрь 2014 г.). Рефакторинг для запахов проектирования программного обеспечения . Морган Кауфманн. п. 258. ИСБН 978-0128013977.
- ^ Кэрролл, Джон, изд. (1995). Проектирование на основе сценариев: представление работы и технологий при разработке системы . Нью-Йорк: Джон Уайли и сыновья. ISBN 0471076597.
- ^ Белл, Майкл (2008). «Введение в сервис-ориентированное моделирование». Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов . Уайли и сыновья. ISBN 978-0-470-14111-3.
- ^ Джудит Бишоп. «Шаблоны проектирования C# 3.0: используйте возможности C# 3.0 для решения реальных проблем». Книги по C# от O'Reilly Media . Проверено 15 мая 2012 г.
Если вы хотите ускорить разработку своих .NET-приложений, вы готовы к использованию шаблонов проектирования C# — элегантных, общепринятых и проверенных способов решения распространенных проблем программирования.
- ^ Дейкстра, EW (1988). «О жестокости реального преподавания информатики» . Проверено 10 января 2014 г.
- ^ Кнут, Дональд Э. (1989). «Заметки об ошибках TeX» (PDF) .
^ Роджер С. Прессман (2001). Программная инженерия: подход практикующего специалиста . МакГроу-Хилл. ISBN 0-07-365578-3.
