Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 46
Текст из файла (страница 46)
По мере того как разработчики прорабатывают и уточняют модель, она становится все более согласованной. Этап анализа делится на две стадии. Сначала осуществляется анализ предметной области, а затем — анализ приложения. Анализ предметной области применяется к объектам реального мира, семантику которых охватывает приложение. Например, рейс самолета — это объект реального мира, который должна отражать система бронирования билетов.
Объекты предметной области существуют независимо от приложений и имеют смысл для бизнес-экспертов. Эти объекты выявляются во время анализа предметной области или исходя из априорных соображений. Объекты предметной области в модели несут информацию об объектах реального мира и обычно являются пассивными. Анализ предметной области выделяет понятия и отношения, а функциональность при этом неявным образом содержится в модели классов. Конструирование модели предметной области сводится, главным образом, к принятию решений о том, какую информацию следует отразить в модели и как ее нужно представить. За анализом предметной области следует анализ приложения, который относится к компьютерным аспектам приложения, видимым пользователям.
Например, меню бронирования билета является частью системы бронирования авиабилетов. Объекты приложения существуют не в предметной области. Они имеют смысл только в контексте приложения. Однако эти объекты не являются чем-то внутренним по отношению к проекту, потому что их видят пользователи. Объекты приложения должны полностью удовлетворять пользователей. Модель приложения не предписывает конкретной реализации системы. Она описывает внешний вид приложения, которое воспринимается как черный ящик. Классы приложения нельзя определить на этапе анализа, но их часто можно взять из предыдущих приложений.
В противном случае объекты приложения приходится придумывать на этапе анализа, как часть интерфейса с другими системами и с пользователями. 10.1.3. Проектирование системы В процессе проекгпировапия системы (зузгеш дез1яп) разработчик принимает стратегические решения с наиболее широким спектром последствий. Он должен сформулировать архитектуру системы и выбрать глобальные стратегии и политики, определяющие последующие, более детализированные этапы проектирования. Архитектура — это высокоуровневый план, или стратегия решения задачи по созданию приложения. Выбор архитектуры определяется требованиями и предшест- 10.1.
Этапы разработки 205 вуюшим опытом разработчика. По возможности, архитектура должна включать исполняемый скелет, который можно было бы тестировать. Проектировщик должен представлять, каким образом новая система будет взаимодействовать с существующими системами. Архитектура также должна принимать во внимание возможность последующих изменений системы. В простых задачах подготовка архитектуры следует после анализа. Однако в крупномасштабных сложных проектах разработка архитектуры и анализ должны чередоваться. Архитектура помогает установить область применимости модели. Моделирование, в свою очередь, раскрывает важные стратегические вопросы, требующие решения. Конструкция модели и архитектура системы связаны друг с другом, а потому они должны строиться параллельно.
10.1.4. Проектирование классов На этапе проектирования классов разработчик расширяет и оптимизирует аналитические модели. Происходит смещение точки приложения усилий с концепций приложения к компьютерным концепциям. Разработчики выбирают алгоритмы реализации основных функций системы, однако они должны воздерживаться от выбора конкретных языков программирования.
10.1.5. Реализация Реализация (ппр)ешепгаг)оп) — это этап написания реального кода. Разработчики реализуют элементы проекта на языках программирования, создавая программный код и структуру базы данных. Достаточно часто код может частично генерироваться автоматически из проектной модели. 10.1.6. Тестирование После реализации система оказывается завершенной, но перед сдачей ее в эксплуатацию она должна пройти обязательный этап тестирования. Идеи, вложенные в исходный проект, претерпели изменения в процессе формирования моделей.
Тестеры возвращаются к исходным требованиям бизнес-экспертов и проверяют, что система обладает нужной функциональностью. Тестирование позволяет также раскрыть случайные ошибки (ябагик), которые появились в системе в процессе ее создания. Если приложение должно работать на разном оборудовании или под разными операционными системами (на разных платформах), оно должно быть проверено на всех этих платформах. Разработчики должны проверять программу на нескольких уровнях. Модульные тесты применяются к небольшим частям кода, например к методам или классам.
Модульное тестирование позволяет выявить локальные проблемы и часто требует встраивания в код дополнительных средств, применяемых только для тестирования. Системные тесты применяются к крупной подсистеме приложения. В отличие от модульных тестов системные позволяют выявить значительные несоответствия спецификации.
Оба вида тестов являются обязательными. Тестирование не следует откладывать до окончания полного кодирования 206 Глава 10 ° Обзор процесса разработки всего приложения. Его следует планировать с самого начала. Многие тесты могут выполняться в процессе реализации. 10.1.7.
Обучение Организация должна обучать пользователей, чтобы они могли полностью использовать все преимушества нового приложения. Обучение ускоряет усвоение пользователями новых навыков. Отдельная команда должна готовить пользовательскую документацию параллельно с разработкой программного обеспечения. Отдел контроля качества может сравнивать программное обеспечение с пользовательской документацией.
Это позволяет гарантировать, что программа соответствует исходным требованиям. 10.1.8. Развертывание Конечная система должна работать «в поле», на разных платформах в различных конфигурациях. При развертывании системы (г1ер!оушепс) на предприятии пользователя можно ожидать самых необычных эффектов от взаимодействия с другими системами. Разработчики должны оптимизировать систему под разные нагрузки и написать сценарии и процедуры установки. Некоторые клиенты потребуют настройки системы под себя. Персонал должен также выполнить локализацию продукта на разные языки с учетом пользовательской локали (1оса1е).
В результате получается пригодный к использованию выпуск продукта (ге1еазе). 10.1.9. Повдержка После завершения разработки и развертывания системы команда переходит к этапу поддержки. Поддержка подразумевает несколько видов деятельности. В процессе использования постепенно выявляются ошибки, содержавшиеся в программном обеспечении.
Эти ошибки необходимо исправлять. Успешное приложение вызывает запросы на усовершенствование, а долгоживушее приложение когда-нибудь придется реструктурировать. Модели облегчают поддержку и передачу дел при смене персонала, Модель отображает бизнес-требования к приложению, воплощенные в реальный код, пользовательский интерфейс и структуру базы данных. 10.2. Жизненный цикл разработки Объектно-ориентированный подход к разработке программного обеспечения поддерживает несколько вариантов жизненных циклов.
Вы можете использовать водопадный подход к этапам анализа, проектирования и реализации, чередуя их в строгой последовательности для всей системы. Однако мы рекомендуем в большинстве случаев использовать итерационную стратегию разработки. В этом разделе мы коротко расскажем об отличиях этих двух стратегий, а более подробные сведения приведем в главе 21. 10.3.
Резюме 202 10.2.1. Водопадная разработка Водопадный подход требует, чтобы разработчики выполняли этапы разработки в строгой линейной последовательности без всяких возвратов. Сначала описываются требования, затем конструируется аналитическая модель, затем выполняется проектирование системы и классов, после чего осушествляется реализация, тестирование и развертывание. Каждый этап должен полностью завершиться до начала следуюшего этапа. Водопадный подход пригоден для определенных приложений с предсказуемыми результатами этапов анализа и проектирования, но такие приложения на практике встречаются редко.
Слишком многие организации пытаются следовать водопадному подходу даже в том случае, когда требования к программе изменчивы. В результате получается знакомая многим ситуация: разработчики жалуются на изменение требований, а бизнес-эксперты жалуются на отсутствие гибкости при разработке программного обеспечения. Кроме того, водопадный подход не позволяет получить рабочую систему до того, как будут завершены все его этапы.
Это затрудняет оценку выполнения проекта и коррекцию проектов, отклонив- шихся от первоначальных планов. 10.2.2. Итерационная разработка Итерационный подход к разработке дает большую гибкость. Сначала разрабатывается ядро системы. Анализ, проектирование, реализация и развертывание дают рабочий код. Затем расширяется область применения системы, добавляются свойства и поведение к имеющимся объектам, создаются новые классы.
Система проходит несколько таких итераций до того, как получается готовый продукт. Каждая итерация подразумевает полное завершение этапов анализа, проектирования, реализации и тестирования. Однако в отличие от водопадного подхода, при итерационном подходе допускается перекрытие различных этапов и не требуется разработка системы целиком за один раз. Некоторые части системы могут быть закончены раньше, тогда как другие, не такие важные, доделываются потом. В конце каждой итерации получается исполняемая система, которая может быть интегрирована с другими системами и протестирована. Это дает возможность точно оценивать прогресс и корректировать планы с учетом информации, полученной на первых итерациях.
Если возникают проблемы, всегда можно вернуться к предыдущим этапам работы. Итерационная разработка хорошо подходит для большинства приложений, потому что она позволяет быстро реагировать на изменения и уменьшает риск провала. Менеджеры и клиенты почти сразу получают интересуюшие их сведения о прогрессе разработки. 10.3. Резюме Процесс разработки программного обеспечения является основой организованного производства программного обеспечения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
