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

Проектирование программного обеспечения — это процесс концептуализации того, как будет работать программная система , прежде чем она будет реализована или модифицирована. ^[1]Проектирование программного обеспечения также относится к прямому результату процесса проектирования – концепции того, как программное обеспечение будет работать, которое состоит как из проектной документации, так и из недокументированных концепций.

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

С точки зрения каскадного процесса разработки , проектирование программного обеспечения — это деятельность по соблюдению спецификации требований перед кодированием . ^[2]

Общий процесс [ править ]

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

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

Модель программного проектирования можно сравнить с архитектурным планом дома. Планы высокого уровня представляют собой весь дом (например, трехмерная визуализация дома). Планы нижнего уровня содержат рекомендации по построению каждой детали (например, прокладки водопровода). Аналогично, модель проектирования программного обеспечения обеспечивает различные представления предлагаемого программного решения.

Значение [ править ]

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

Анализ требований [ править ]

Одним из компонентов разработки программного обеспечения является анализ требований к программному обеспечению (SRA). SRA — это часть процесса разработки программного обеспечения , в которой перечислены спецификации, используемые при разработке программного обеспечения .

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

Артефакты [ править ]

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

Иногда результатом процесса проектирования является проектная документация .

Принципы проектирования [ править ]

Базовые принципы проектирования позволяют инженеру-программисту ориентироваться в процессе проектирования. Дэвис ^[4] предлагает набор принципов проектирования программного обеспечения, которые были адаптированы и расширены в следующем списке:

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

Концепции дизайна [ править ]

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

Абстракция . Абстракция — это процесс или результат обобщения путем уменьшения информационного содержания концепции или наблюдаемого явления, обычно для сохранения только информации, которая имеет отношение к определенной цели. Это акт представления существенных особенностей без включения дополнительных деталей или пояснений.
Уточнение – это процесс разработки. Иерархия разрабатывается путем поэтапного разложения макроскопического описания функции до тех пор, пока не будут получены операторы языка программирования. На каждом шаге одна или несколько инструкций данной программы декомпозируются на более подробные инструкции. Абстракция и уточнение — взаимодополняющие понятия.
Модульность . Архитектура программного обеспечения разделена на компоненты, называемые модулями.
Архитектура программного обеспечения . Это относится к общей структуре программного обеспечения и способам, которыми эта структура обеспечивает концептуальную целостность системы. Хорошая архитектура программного обеспечения обеспечит хорошую отдачу от инвестиций в отношении желаемого результата проекта, например, с точки зрения производительности, качества, графика и стоимости.
Иерархия управления — структура программы, которая представляет организацию программного компонента и подразумевает иерархию управления.
Структурное разделение . Структуру программы можно разделить по горизонтали и вертикали. Горизонтальные разделы определяют отдельные ветви модульной иерархии для каждой основной функции программы. Вертикальное секционирование предполагает, что управление и работа должны распределяться в структуре программы сверху вниз.
Структура данных . Это представление логических связей между отдельными элементами данных.
Программная процедура – ориентирована на обработку каждого модуля в отдельности.
Сокрытие информации . Модули должны быть определены и спроектированы таким образом, чтобы информация, содержащаяся в модуле, была недоступна для других модулей, которым такая информация не нужна.

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

Аспекты дизайна [ править ]

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

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

Язык моделирования [ править ]

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

Язык описания архитектуры (ADL) — это язык, используемый для описания и представления архитектуры программного обеспечения программной системы .
Нотация моделирования бизнес-процессов (BPMN) является примером языка моделирования процессов .
EXPRESS общего назначения и EXPRESS-G (ISO 10303-11) — это международный стандартный язык моделирования данных .
Расширенный язык моделирования предприятия (EEML) обычно используется для моделирования бизнес-процессов на нескольких уровнях.
Блок-схемы представляют собой схематические изображения алгоритмов или других пошаговых процессов.
Фундаментальные концепции моделирования (FMC) — это язык моделирования для систем с интенсивным использованием программного обеспечения.
IDEF — это семейство языков моделирования, наиболее известные из которых включают IDEF0 для функционального моделирования, IDEF1X для информационного моделирования и IDEF5 для моделирования онтологий .
Структурное программирование Джексона (JSP) — это метод структурного программирования, основанный на соответствии между структурой потока данных и структурой программы.
LePUS3 — это объектно-ориентированный визуальный язык описания дизайна и язык формальных спецификаций , который подходит в первую очередь для моделирования больших объектно-ориентированных ( Java , C++ , C# ) программ и шаблонов проектирования .
Унифицированный язык моделирования (UML) — это общий язык моделирования, предназначенный для описания программного обеспечения как структурно, так и поведенчески. Он имеет графическое обозначение и допускает расширение с помощью профиля (UML) .
Alloy (язык спецификации) — это язык спецификации общего назначения для выражения сложных структурных ограничений и поведения в программной системе. Он обеспечивает краткую языковую основу на реляционной логике первого порядка.
Язык моделирования систем (SysML) — это новый язык моделирования общего назначения для системной инженерии.
Структура сервис-ориентированного моделирования (SOMF) ^[8]

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

Разработчик программного обеспечения может определить аспект дизайна, который уже посещался и, возможно, даже решался другими в прошлом. Шаблон или шаблон, описывающий решение общей проблемы, известен как шаблон проектирования . Повторное использование таких шаблонов может увеличить скорость разработки программного обеспечения. ^[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 .

[1] Ральф П. и Ванд Ю. (2009). Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж . и Робинсон В., редакторы, Семинар по требованиям к проектированию (LNBIP 14), стр. 103–136. Шпрингер-Верлаг, с. 109 дои : 10.1007/978-3-540-92966-6_6 .

[2] Фриман, Питер; Дэвид Харт (2004). «Наука проектирования программно-емких систем». Коммуникации АКМ . 47 (8): 19–21 [20]. дои : 10.1145/1012037.1012054 . S2CID 14331332 .

[3] Ральф П. и Ванд Ю. Предложение по формальному определению концепции дизайна. Лютинен К., Лукопулос П., Милопулос Дж. и Робинсон В. (ред.), Разработка требований к проектированию: десятилетняя перспектива: Springer-Verlag, 2009, стр. 103–136.

[4] Дэвис, А.: «201 принцип разработки программного обеспечения», McGraw Hill, 1995.

[5] Буч, Грейди; и др. (2004). Объектно-ориентированный анализ и проектирование с приложениями (3-е изд.). Массачусетс, США: Эддисон Уэсли. ISBN 0-201-89551-Х . Проверено 30 января 2015 г.

[6] Сурьянараяна, Гириш (ноябрь 2014 г.). Рефакторинг для запахов проектирования программного обеспечения . Морган Кауфманн. п. 258. ИСБН 978-0128013977 .

[7] Кэрролл, Джон, изд. (1995). Проектирование на основе сценариев: представление работы и технологий при разработке системы . Нью-Йорк: Джон Уайли и сыновья. ISBN 0471076597 .

[Bell-8] Белл, Майкл (2008). «Введение в сервис-ориентированное моделирование». Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов . Уайли и сыновья. ISBN 978-0-470-14111-3 .

[9] Джудит Бишоп. «Шаблоны проектирования C# 3.0: используйте возможности C# 3.0 для решения реальных проблем» . Книги по C# от O'Reilly Media . Проверено 15 мая 2012 г. Если вы хотите ускорить разработку своих .NET-приложений, вы готовы к использованию шаблонов проектирования C# — элегантных, общепринятых и проверенных способов решения распространенных проблем программирования.

[10] Дейкстра, EW (1988). «О жестокости реального преподавания информатики» . Проверено 10 января 2014 г.

[11] Кнут, Дональд Э. (1989). «Заметки об ошибках TeX» (PDF) .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

v т и Информатика
Note: This template roughly follows the 2012 ACM Computing Classification System.
Hardware	Printed circuit board Peripheral Integrated circuit Very Large Scale Integration Systems on Chip (SoCs) Energy consumption (Green computing) Electronic design automation Hardware acceleration
Computer systems organization	Computer architecture Computational complexity Dependability Embedded system Real-time computing
Networks	Network architecture Network protocol Network components Network scheduler Network performance evaluation Network service
Software organization	Interpreter Middleware Virtual machine Operating system Software quality
Software notations and tools	Programming paradigm Programming language Compiler Domain-specific language Modeling language Software framework Integrated development environment Software configuration management Software library Software repository
Software development	Control variable Software development process Requirements analysis Software design Software construction Software deployment Software engineering Software maintenance Programming team Open-source model
Theory of computation	Model of computation Formal language Automata theory Computability theory Computational complexity theory Logic Semantics
Algorithms	Algorithm design Analysis of algorithms Algorithmic efficiency Randomized algorithm Computational geometry
Mathematics of computing	Discrete mathematics Probability Statistics Mathematical software Information theory Mathematical analysis Numerical analysis Theoretical computer science
Information systems	Database management system Information storage systems Enterprise information system Social information systems Geographic information system Decision support system Process control system Multimedia information system Data mining Digital library Computing platform Digital marketing World Wide Web Information retrieval
Security	Cryptography Formal methods Security hacker Security services Intrusion detection system Hardware security Network security Information security Application security
Human–computer interaction	Interaction design Social computing Ubiquitous computing Visualization Accessibility
Concurrency	Concurrent computing Parallel computing Distributed computing Multithreading Multiprocessing
Artificial intelligence	Natural language processing Knowledge representation and reasoning Computer vision Automated planning and scheduling Search methodology Control method Philosophy of artificial intelligence Distributed artificial intelligence
Machine learning	Supervised learning Unsupervised learning Reinforcement learning Multi-task learning Cross-validation
Graphics	Animation Rendering Photograph manipulation Graphics processing unit Mixed reality Virtual reality Image compression Solid modeling
Applied computing	Quantum Computing E-commerce Enterprise software Computational mathematics Computational physics Computational chemistry Computational biology Computational social science Computational engineering Differentiable computing Computational healthcare Digital art Electronic publishing Cyberwarfare Electronic voting Video games Word processing Operations research Educational technology Document management
Category Outline WikiProject Commons