2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 88
Текст из файла (страница 88)
Обычно все перечисленные задачи решает небольшая группа людей.В конце начальной фазы еще раз внимательно анализируетсявесь жизненный цикл проекта и принимается решение о том, стоитли приступать к полномасштабной разработке.Разработкаитер. итер.итер. итер. итер.итер. итер.Рис.
П2.1. Жизненный цикл процесса разработкипрограммного обеспеченияЦели этой фазы – анализ предметной области, выработка прочной архитектурной основы, уточнение плана проекта и исключение наиболее серьезных рисков. Архитектурные решения должныприниматься тогда, когда уже понятна вся система, то есть сформулирована большая часть требований. Для подтверждения правильности выбора архитектуры создается система, демонстрирующаяRational Unified Process464выбранные принципы в действии и реализующая некоторые наиболее важные варианты использования.Основные действующие лица на данном этапе – архитекторсистемы и менеджер проекта, а также аналитики, разработчики,тестировщики и др. Обычно вторая фаза требует участия большегоколичества специалистов, чем первая.В конце фазы разработки изучаются максимально конкретизированные цели проекта, его рамки, выбор архитектуры и методыразрешения основных рисков, а затем принимается решение о переходе к конструированию.КонструированиеНа стадии конструирования производится итерационная и пошаговая разработка продукта, готового к внедрению.
Под этим подразумевается описание ранее не учтенных требований и критериевприемки, материализация дизайна, завершение реализации и тестирования программного обеспечения.В такую работу вовлечены архитектор системы, менеджер проекта и лидеры групп разработчиков, а кроме того, весь персонал, занятый разработкой и тестированием.В конечном счете принимаются решения о готовности программ, среды эксплуатационных площадок и пользователей к установке и эксплуатации первой рабочей версии системы.ВнедрениеНа фазе внедрения программное обеспечение поставляетсясообществу пользователей. Следует заметить, что они участвуютв демонстрации, обсуждении и испытании альфаF и бетаFрелизовпроекта.
Как только система попадает в руки конечного пользователя, часто возникают новые требования, предполагающие корректировку системы, решение ранее незамеченных проблем либо окончательную доработку функций, реализация которых была отложена.Обычно данная фаза начинается с выпуска бетаFверсии, впоследствии заменяемой рабочей версией системы.Среди основных членов группы, выполняющих вышеизложенные задачи, – менеджер проекта, тестировщики, специалисты по выпуску версий, маркетологи и персонал, занятый в сфере продаж. Отметим, что работа по подготовке окончательнойверсии, маркетингу и продажам должна начинаться как можнораньше.В конце фазы внедрения делается вывод о том, достигнуты лицели проекта и стоит ли начинать следующий цикл разработки.Дисциплины465Подводятся итоги работы и извлекаются уроки, которые помогутсовершенствовать процесс разработки новых проектов.ИтерацииКаждая фаза RUP может быть разбита на итерации.
Итерацияпредставляет собой полный цикл разработки, по завершении которого выпускается промежуточная или итоговая версия работающего продукта, где реализована часть запланированных функций.От одной итерации к другой эта версия наращивается до получения готовой системы. Во время каждой итерации выполняются вседисциплины (см. ниже), хотя на разных фазах основной акцент делается на различных моментах. На начальной фазе главная задачазаключается в сборе требований, на фазе разработки это анализ, проектирование и реализация архитектуры, на фазе конструирования –детальное проектирование, реализация и тестирование, а на фазевнедрения – размещение. Тестирование важно на всех стадиях.Циклы разработкиПрохождение системы через четыре основные фазы называется циклом разработки. Каждый цикл завершается генерациейпрограммного обеспечения.
Первый проход через все фазы – этоначальный цикл разработки. Если после него работа над проектомне прекращается, полученный продукт продолжает развиватьсяи снова минует те же фазы: начальный этап, разработку, конструирование и внедрение. Таким образом система эволюционирует,поэтому все циклы, следующие за начальным, называются эволюционными.ДисциплиныRUP состоит из девяти дисциплин:1.
Бизнес9моделирование (business modeling) – описывает структуру и динамику организацииFзаказчика;2. Управление требованиями (requirements) – выявляет требования на основе множества подходов;3. Анализ и проектирование (analysis & design) – описываетмножество архитектурных представлений системы;4. Реализация (implementation) – собственно, разработка программного обеспечения, модульное тестирование и интеграция;5.
Тестирование (test) – описывает тестовые сценарии, процедуры и метрики для оценки дефектов;Rational Unified Process4666. Размещение (deployment) – включает спецификацию материалов, описание версии, обучение и другие аспекты, связанные с поставкой системы;7. Управление конфигурацией и изменениями (configurationmanagement) – сфокусировано на изменениях, поддержкецелостности рабочих продуктов проекта и управленческойдеятельности;8. Управление проектом (project management) – описывает различные стратегии работы в условиях итерационного процесса;9.
Создание рабочей среды (environment) – рассматривает необходимую инфраструктуру для разработки системы.Каждая дисциплина охватывает свой набор связанных рабочихпродуктов и видов деятельности. Рабочий продукт1 – это некоторый документ, отчет или исполнимая программа, которые послеих создания преобразуются или потребляются.
Вид деятельностиописывает комплекс задач – этапы продумывания, выполнения,анализа, – выполняемых сотрудниками с целью создания или модификации рабочих продуктов, а также способы выполнения этихзадач и соответствующие рекомендации. В число таких способовможет входить применение инструментальных средств, позволяющих автоматизировать ряд процессов.В некоторых из этих дисциплин уставновлены важные связимежду рабочими продуктами.
Например, модель вариантов использования, созданная в ходе сбора требований, реализуется в видепроектной модели, выработанной в ходе анализа и проектирования,воплощается в модели дисциплины реализации и верифицируетсямоделью дисциплины тестирования.Рабочие продуктыС каждым видом деятельности в рамках RUP ассоциированырабочие продукты (входные или выходные). Некоторые рабочиепродукты используются как входные для последующих видов деятельности, содержат справочные сведения о проекте или придаютему окончательную форму для поставки по контракту.МоделиМоделироМодели – наиболее важная разновидность рабочих продуктоввание обсуж- в RUP. Модель представляет собой упрощенное представлениедаетсяреальности, созданное для лучшего понимания разрабатываемойв главе 1.системы. В RUP существует множество моделей, которые в своей1В отличие от языка UML, в контексте процесса разработки RUP термин «artifact»по смыслу целесообразнее переводить как «рабочий продукт», а не «артефакт».
–Прим. ред.Рабочие продукты467совокупности охватывают все важнейшие решения, направленныена визуализацию, специфицирование, конструирование и документирование программных систем:1. Модель бизнес9процессов (business use case model) описываетдеятельность организации;2. Модель бизнес9анализа (business analysis model) определяетконтекст системы;3. Модель вариантов использования (use case model) выражаетфункциональные требования к системе;4. Модель анализа (analysis model) – необязательная.
Определяет проектные решения на концептуальном уровне;5. Проектная модель (design model) охватывает словарь предметной области и области решения;6. Модель данных (data model) – необязательная. Определяетпредставление данных в базах данных и других репозиториях;7. Модель размещения (deployment model) специфицирует топологию аппаратных средств, на которых работает система,вместе с механизмами параллелизма и синхронизации;8. Модель реализации (implementation model) определяет, какие части используются для сборки и реализации физической системы.Архитектура обсуждаетсяв главе 2.Представление (view) – это проекция модели.
В RUP архитектура системы включает пять тесно связанных друг с другом представлений: проектирования, взаимодействия, размещения, реализации и вариантов использования.Другие рабочие продуктыРабочие продукты RUP подразделяются на две группы: продукты управления и технические продукты. Последние, в свою очередь,делятся на пять основных подгрупп:1.
Группа требований (requirements set) описывает, что должна делать система. В составе этих рабочих продуктов могутбыть модель вариантов использования, нефункциональныетребования, модель предметной области, модель анализаи другие формы выражения потребностей пользователей,включая макеты, прототипы интерфейсов, юридические ограничения и т.д.;2. Группа анализа и проектирования (analysis & design set) описывает, как система должна быть построена с учетом всехограничений по времени, бюджету, унаследованным системам, повторному использованию, требованиям к качеству468Rational Unified Processи т.п. Сюда могут входить проектная модель, модель тестирования и другие формы выражения природы системы,включая прототипы и исполняемые архитектуры, но не ограничиваясь ими;3. Группа тестирования (test set) описывает подход, посредством которого система верифицируется и аттестуется. С этойцелью используются скрипты, сценарии тестирования, способы измерения дефектов и критерии приемки;4.
Группа реализации (implementation set) дает информациюоб элементах программного обеспечения, включая исходный код на разных языках программирования, файлы конфигурации, файлы данных и т.д., а также о сборке системына основе разработанных программных компонентов;5. Группа размещения (deployment set) представляет все данные, необходимые для конфигурирования поставляемой системы, – в частности, включает всю информацию о способахпакетирования, поставки, установки и запуска программного обеспечения на целевой платформе заказчика.ГлоссарийObject Constraint Language (OCL) – формальный язык длявыражения ограничений без побочных эффектовUnified Modeling Language (UML) – унифицированный языкмоделирования, предназначенный для визуализации, специфицирования, конструирования и документирования артефактов программных системАбстрактный класс (abstract class) – класс, для которого нельзясоздать прямые экземпляры объектовАбстракция (abstraction) – важная характеристика сущности,отличающая ее от всех прочих видов сущностей.
Абстракция определяет границы сущности с определенной точки зренияАвтомат (state machine) – поведение, которое специфицируетпоследовательность состояний объекта, через которые он проходит на протяжении своего жизненного цикла, реагируя на события(в числе прочего дает описание реакций на эти события)Агрегат (aggregate) – класс, представляющий целое в агрегацииАгрегация (aggregation) – разновидность ассоциации, описывающая связь между агрегатом (целым) и компонентом (частью)Активный класс (active class) – класс, экземпляры которого являются активными объектамиАктивный объект (active object) – объект, который владеет процессом или потоком и может инициировать управляющее воздействиеАргумент (argument) – конкретное значение, соответствующеепараметруАрхитектура (architecture) – совокупность существенных решений относительно организации программной системы:– выбор структурных элементов и интерфейсов, из которыхона состоит, вместе с их поведением, описываемым в терминах кооперации этих элементов;– объединение данных структурных и поведенческих элементов в крупные подсистемы;– архитектурный стиль, которому подчинена организация элементов, интерфейсов, коопераций и их композиция.К архитектуре программного обеспечения относятся не толькоструктура и поведение, но также используемость, функциональность,470Глоссарийпроизводительность, гибкость, повторное использование, понятность,экономические и технологические ограничения и компромиссы,а также эстетические аспектыАсинхронное действие (asynchronous action) – запрос, при котором посылающий объект не приостанавливается для ожиданияответаАссоциация (association) – структурная связь, описывающаянабор ссылок, где некая ссылка представляет собой соединениемежду объектами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
