Процесс планирования программных решений
Проектирование программного обеспечения — это процесс концептуализации того, как будет работать программная система , до ее внедрения или модификации. [1]
Проектирование программного обеспечения также относится к прямому результату процесса проектирования — концепциям того, как будет работать программное обеспечение, которые состоят как из проектной документации, так и из недокументированных концепций.
Проектирование программного обеспечения обычно направляется целями конечной системы и включает в себя решение проблем и планирование, включая как высокоуровневую архитектуру программного обеспечения , так и низкоуровневую разработку компонентов и алгоритмов .
С точки зрения каскадного процесса разработки , проектирование программного обеспечения представляет собой деятельность, следующую за спецификацией требований и предшествующую кодированию . [2]
Общий процесс
Процесс проектирования позволяет проектировщику моделировать различные аспекты программной системы еще до ее создания.
Творчество, прошлый опыт, понимание того, что делает "хорошее" программное обеспечение, и приверженность качеству являются факторами успеха для грамотного дизайна. Однако процесс дизайна не всегда является простой процедурой.
Модель проектирования программного обеспечения можно сравнить с архитектурным планом дома. Высокоуровневые планы представляют собой совокупность дома (например, трехмерная визуализация дома). Низкоуровневые планы предоставляют руководство по построению каждой детали (например, прокладка сантехники). Аналогично, модель проектирования программного обеспечения предоставляет различные представления предлагаемого программного решения.
Ценить
Документация по проектированию программного обеспечения может быть рассмотрена или представлена, чтобы позволить скорректировать ограничения, спецификации и даже требования до кодирования . Перепроектирование может произойти после обзора запрограммированной симуляции или прототипа . Возможно проектировать программное обеспечение в процессе кодирования, без плана или анализа требований, [3] но для более сложных проектов это менее осуществимо. Отдельный проект до кодирования позволяет многопрофильным дизайнерам и предметным экспертам (SMEs) сотрудничать с программистами для создания программного обеспечения, которое будет полезным и технически обоснованным.
Анализ требований
Одним из компонентов проектирования программного обеспечения является анализ требований к программному обеспечению (SRA). SRA — это часть процесса разработки программного обеспечения , которая перечисляет спецификации , используемые в программной инженерии .
Результатом анализа являются меньшие проблемы для решения. Напротив, дизайн фокусируется на возможностях, и, таким образом, может существовать несколько дизайнов для одной и той же проблемы. В зависимости от среды дизайн часто меняется, создается ли он из надежных фреймворков или реализуется с помощью подходящих шаблонов дизайна .
Артефакты
Процесс проектирования может включать создание артефактов, таких как блок-схема , вариант использования , псевдокод , модель унифицированного языка моделирования и другие фундаментальные концепции моделирования . Для программного обеспечения, ориентированного на пользователя , проектирование может включать проектирование пользовательского опыта, дающее раскадровку , помогающую определить эти спецификации.
Иногда результатом процесса проектирования является проектная документация .
Принципы проектирования
Базовые принципы проектирования позволяют инженеру-программисту ориентироваться в процессе проектирования. Дэвис [4] предлагает набор принципов для проектирования программного обеспечения, которые были адаптированы и расширены в следующем списке:
- Процесс проектирования не должен страдать от «туннельного зрения». Хороший дизайнер должен рассматривать альтернативные подходы, оценивая каждый из них на основе требований проблемы и ресурсов, доступных для выполнения работы.
- Проектирование должно прослеживаться до модели анализа. Поскольку один элемент модели проектирования часто можно проследить до нескольких требований, необходимо иметь средства для отслеживания того, как требования были удовлетворены моделью проектирования.
- Проектирование не должно изобретать велосипед. Системы строятся с использованием набора шаблонов проектирования, многие из которых, вероятно, встречались ранее. Эти шаблоны всегда следует выбирать в качестве альтернативы переизобретению. Времени мало, а ресурсы ограничены; время проектирования следует инвестировать в представление (действительно новых) идей путем интеграции шаблонов, которые уже существуют (когда применимы).
- Проект должен «минимизировать интеллектуальное расстояние» между программным обеспечением и проблемой, существующей в реальном мире. То есть структура программного обеспечения должна, по возможности, имитировать структуру проблемной области.
- Дизайн должен демонстрировать единообразие и целостность. Дизайн является единообразным, если он выглядит полностью связным. Чтобы достичь этого результата, правила стиля и формата должны быть определены для команды дизайнеров до начала работы над дизайном. Дизайн является интегрированным, если уделено внимание определению интерфейсов между компонентами дизайна.
- Дизайн должен быть структурирован для приспособления к изменениям. Концепции дизайна, обсуждаемые в следующем разделе, позволяют дизайну достичь этого принципа.
- Проект должен быть структурирован так, чтобы деградировать мягко, даже когда встречаются аномальные данные, события или условия эксплуатации. Хорошо спроектированное программное обеспечение никогда не должно «бомбиться»; оно должно быть спроектировано так, чтобы приспосабливаться к необычным обстоятельствам, и если оно должно прекратить обработку, оно должно сделать это изящно.
- Проектирование — это не кодирование, кодирование — это не проектирование. Даже когда для компонентов программы создаются подробные процедурные проекты, уровень абстракции модели проекта выше исходного кода. Единственные решения по проектированию, принимаемые на уровне кодирования, должны касаться небольших деталей реализации, которые позволяют кодировать процедурный проект.
- Качество дизайна следует оценивать в процессе его создания, а не после него. Разнообразные концепции дизайна и меры дизайна доступны для того, чтобы помочь дизайнеру оценить качество на протяжении всего процесса разработки.
- Проект должен быть пересмотрен, чтобы минимизировать концептуальные (семантические) ошибки. Иногда существует тенденция сосредотачиваться на мелочах при пересмотре проекта, упуская лес за деревьями. Команда дизайнеров должна убедиться, что основные концептуальные элементы проекта (пропуски, двусмысленность, непоследовательность) были рассмотрены, прежде чем беспокоиться о синтаксисе модели проекта.
Концепции дизайна
Концепции дизайна предоставляют дизайнеру основу, на которой могут применяться более сложные методы. Набор концепций дизайна развился, включая:
- Абстракция - Абстракция - это процесс или результат обобщения путем сокращения информационного содержания концепции или наблюдаемого явления, как правило, для сохранения только той информации, которая имеет отношение к определенной цели. Это акт представления существенных особенностей без включения фоновых деталей или объяснений.
- Уточнение - это процесс уточнения. Иерархия разрабатывается путем пошагового разложения макроскопического выражения функции до тех пор, пока не будут достигнуты выражения языка программирования. На каждом шаге одна или несколько инструкций данной программы разлагаются на более подробные инструкции. Абстракция и Уточнение являются взаимодополняющими концепциями.
- Модульность . Архитектура программного обеспечения делится на компоненты, называемые модулями.
- Архитектура программного обеспечения - относится к общей структуре программного обеспечения и способам, которыми эта структура обеспечивает концептуальную целостность системы. Хорошая архитектура программного обеспечения даст хорошую отдачу от инвестиций в отношении желаемого результата проекта, например, с точки зрения производительности, качества, графика и стоимости.
- Иерархия управления — структура программы, которая представляет организацию компонента программы и подразумевает иерархию управления.
- Структурное разбиение - Структура программы может быть разделена горизонтально и вертикально. Горизонтальные разбиения определяют отдельные ветви модульной иерархии для каждой основной функции программы. Вертикальное разбиение предполагает, что управление и работа должны быть распределены сверху вниз в структуре программы.
- Структура данных — это представление логической взаимосвязи между отдельными элементами данных.
- Программная процедура — фокусируется на обработке каждого модуля по отдельности.
- Сокрытие информации . Модули должны быть определены и спроектированы таким образом, чтобы информация, содержащаяся в модуле, была недоступна для других модулей, которым такая информация не нужна.
В своей объектной модели Грэди Буч упоминает Абстракцию , Инкапсуляцию , Модуляризацию и Иерархию как фундаментальные принципы проектирования программного обеспечения. [5] Аббревиатура PHAME (Принципы Иерархии, Абстракции, Модуляризации и Инкапсуляции) иногда используется для обозначения этих четырех фундаментальных принципов. [6]
Конструктивные соображения
При проектировании программного обеспечения необходимо учитывать множество аспектов. Важность каждого аспекта должна отражать цели и ожидания, которым должно соответствовать программное обеспечение. Вот некоторые из этих аспектов:
- Совместимость - программное обеспечение может работать с другими продуктами, которые разработаны для взаимодействия с другим продуктом. Например, часть программного обеспечения может быть обратно совместима с более старой версией самого себя.
- Расширяемость — в программное обеспечение можно добавлять новые возможности без внесения существенных изменений в базовую архитектуру.
- Модульность — полученное программное обеспечение состоит из четко определенных, независимых компонентов, что обеспечивает лучшую ремонтопригодность. Затем компоненты могут быть реализованы и протестированы по отдельности, прежде чем будут интегрированы для формирования желаемой программной системы. Это позволяет разделить работу в проекте разработки программного обеспечения.
- Отказоустойчивость — программное обеспечение устойчиво к отказам компонентов и способно восстанавливаться после них.
- Поддерживаемость - Мера того, насколько легко можно исправить ошибки или внести функциональные изменения. Высокая поддерживаемость может быть результатом модульности и расширяемости.
- Надежность ( долговечность программного обеспечения ) — программное обеспечение способно выполнять требуемую функцию в указанных условиях в течение определенного периода времени.
- Возможность повторного использования — возможность использовать некоторые или все аспекты уже существующего программного обеспечения в других проектах с небольшими изменениями или без них.
- Надежность - программное обеспечение способно работать в условиях стресса или выдерживать непредсказуемый или недопустимый ввод. Например, его можно разработать с устойчивостью к условиям нехватки памяти.
- Безопасность — программное обеспечение способно противостоять и противостоять враждебным действиям и воздействиям.
- Удобство использования - пользовательский интерфейс программного обеспечения должен быть удобен для своего целевого пользователя/аудитории. Значения по умолчанию для параметров должны быть выбраны так, чтобы они были хорошим выбором для большинства пользователей. [7]
- Производительность — программное обеспечение выполняет свои задачи в приемлемые для пользователя сроки и не требует слишком много памяти.
- Переносимость . Программное обеспечение должно быть пригодным для использования в различных условиях и средах.
- Масштабируемость — программное обеспечение хорошо адаптируется к увеличению объема данных или добавлению функций или числа пользователей. По словам Марка Брукера: «система масштабируется в диапазоне, где предельная стоимость дополнительной рабочей нагрузки почти постоянна». Бессерверные технологии соответствуют этому определению, но вам нужно учитывать общую стоимость владения, а не только стоимость инфраструктуры. [8]
Язык моделирования
Язык моделирования может использоваться для выражения информации, знаний или систем в структуре, которая определяется последовательным набором правил. Эти правила используются для интерпретации компонентов в структуре. Язык моделирования может быть графическим или текстовым. Примеры графических языков моделирования для проектирования программного обеспечения включают:
Шаблоны проектирования
Разработчик программного обеспечения может определить аспект дизайна, который был посещен и, возможно, даже решен другими в прошлом. Шаблон или шаблон, описывающий решение общей проблемы, известен как шаблон проектирования . Повторное использование таких шаблонов может увеличить скорость разработки программного обеспечения. [10]
Код как дизайн
Трудность использования термина «дизайн» в отношении программного обеспечения заключается в том, что в некотором смысле исходный код программы является дизайном для программы, которую он производит. В той степени, в которой это верно, «дизайн программного обеспечения» относится к дизайну дизайна. Эдсгер В. Дейкстра назвал это наслоение семантических уровней «радикальной новизной» компьютерного программирования [11] , а Дональд Кнут использовал свой опыт написания TeX , чтобы описать тщетность попыток спроектировать программу до ее реализации:
T E X был бы полным провалом, если бы я просто указал его и не участвовал в полной мере в его первоначальной реализации. Процесс реализации постоянно приводил меня к непредвиденным вопросам и новым идеям о том, как можно улучшить исходные спецификации. [12]
Смотрите также
На Викискладе есть медиафайлы по теме «Проектирование программного обеспечения» .
Ссылки
- ^ Ральф, П. и Ванд, И. (2009). Предложение по формальному определению концепции дизайна. В Lyytinen, K., Loucopoulos, P., Mylopoulos, J. и Robinson, W., редакторы, Design Requirements Workshop (LNBIP 14), стр. 103–136. Springer-Verlag, стр. 109 doi :10.1007/978-3-540-92966-6_6.
- ^ Фримен, Питер; Дэвид Харт (2004). «Наука проектирования систем с большим объемом программного обеспечения». Communications of the ACM . 47 (8): 19–21 [20]. doi :10.1145/1012037.1012054. S2CID 14331332.
- ^ Ральф, П. и Ванд, И. Предложение по формальному определению концепции дизайна. В Lyytinen, K., Loucopoulos, P., Mylopoulos, J. и Robinson, W., (ред.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, стр. 103-136
- ^ Дэвис, А.: «201 принцип разработки программного обеспечения», McGraw Hill, 1995.
- ^ Booch, Grady; et al. (2004). Объектно-ориентированный анализ и проектирование с приложениями (3-е изд.). MA, США: Addison Wesley. ISBN 0-201-89551-X. Получено 30 января 2015 г.
- ^ Suryanarayana, Girish (ноябрь 2014 г.). Рефакторинг для Software Design Smells . Морган Кауфманн. стр. 258. ISBN 978-0128013977.
- ^ Кэрролл, Джон, ред. (1995). Проектирование на основе сценариев: представление работы и технологий в разработке систем . Нью-Йорк: John Wiley & Sons. ISBN 0471076597.
- ^ Создание бессерверных приложений на Knative . O'Reilly Media. ISBN 9781098142049.
- ^ Белл, Майкл (2008). «Введение в сервисно-ориентированное моделирование». Сервисно-ориентированное моделирование: анализ услуг, проектирование и архитектура . Wiley & Sons. ISBN 978-0-470-14111-3.
- ^ Джудит Бишоп. "Шаблоны проектирования C# 3.0: используйте мощь C# 3.0 для решения реальных проблем". Книги по C# издательства O'Reilly Media . Получено 15.05.2012 .
Если вы хотите ускорить разработку приложений .NET, вы готовы к шаблонам проектирования C# — элегантным, общепринятым и проверенным способам решения распространенных проблем программирования.
- ^ Дейкстра, Э. В. (1988). «О жестокости реального преподавания компьютерной науки» . Получено 10 января 2014 г.
- ^ Кнут, Дональд Э. (1989). «Заметки об ошибках TeX» (PDF) .
^ Роджер С. Прессман (2001). Программная инженерия: подход практиков . McGraw-Hill. ISBN 0-07-365578-3.
