Альфапедия

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

редактировать

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

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

Содержание
  • 1 Обзор
  • 2 Концепции проектирования
  • 3 Рекомендации по проектированию
  • 4 Язык моделирования
  • 5 Шаблоны проектирования
  • 6 Техника
  • 7 Использование
  • 8 См. Также
  • 9 Ссылки
Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

Методика

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

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

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

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

См. Также
На Викискладе есть материалы, связанные с Дизайн программного обеспечения.
Ссылки

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

Последняя правка сделана 2021-06-08 08:27:04
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте