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

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Поиск источников:  «Разработка программного обеспечения»  -  новости  · газеты  · книги  · ученый  · JSTOR ( январь 2013 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

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

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

Обзор [ править ]

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

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

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

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

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

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

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

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

Соображения по дизайну [ править ]

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

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

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

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

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

Паттерны дизайна [ править ]

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

Техника [ править ]

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

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

Использование [ править ]

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

См. Также [ править ]

Викискладе есть медиафайлы по теме разработки программного обеспечения .

• Аспектно-ориентированная разработка программного обеспечения
• Бакалавр наук в области информационных технологий
• Дизайн
• Обоснование дизайна
• Графический дизайн
• Интерактивный дизайн
• Дизайн иконок
• Краткое описание программного обеспечения
• План разработки программного обеспечения
• Краткое описание программной инженерии
• Разработка программного обеспечения на основе поиска
• Описание разработки программного обеспечения (IEEE 1016)
• Разработка программного обеспечения
• Пользовательский опыт
• Дизайн пользовательского интерфейса
• веб-дизайн
• Zero One Infinity

Ссылки [ править ]

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