Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование (1158625), страница 67

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

Текст из файла (страница 67)

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

Причина этого в том, что классы анализа яв0..*«trace»Пакет анализа0..*ПроектнаяподсистемаПроектный класс0..*Класс анализа1«trace»0..*Реализация прецедента –аналитическая1«trace»1«interface»ИнтерфейсРеализация прецедента –проектнаяРис. 16.5. Отношения между ключевыми артефактами анализаи проектирования364Глава 16. Рабочий поток проектированияляются высокоуровневым концептуальным представлением классовсистемы. Когда дело доходит до физического моделирования (проектирования), для реализации этих концептуальных классов может понадобиться один или более физических проектных классов и/или интерфейсов.Между аналитическими и проектными реализациями прецедентов устанавливается простое одинкодному отношение «trace».

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

16.1.Сохраняйте аналитические модели для больших, сложных или стратегически важных систем.Таблица 16.1СтратегияРезультаты1 Берется аналитическая модель и до Имеется единственная проектная мополняется до проектной модели.дель, но утеряно аналитическое представление.2 Берется аналитическая модель, дополняется до проектной модели, ас помощью инструмента моделирования восстанавливается «аналитическое представление».Имеется единственная проектная модель, но восстановленное инструментом моделирования аналитическоепредставление может быть неприемлемым.3 Аналитическая модель заморажива Имеются две модели, но они не синется в некоторой точке фазы Уточне хронизированы.ние. До проектной модели дополняется копия аналитической модели.4 Поддерживаются две отдельные мо Имеются две модели – они синхронидели – аналитическая и проектная.

зованы, но их обслуживание оченьтрудоемко.Идеальной стратегии нет, все зависит от проекта. Однако необходимозадать себе фундаментальный вопрос: нужно ли сохранять аналитическое представление системы? Аналитические представления обеспечи16.4. Детализация рабочего потока проектирования365вают «общую картину» системы. В них может быть лишь от 1 до 10%классов подробного проектного представления, поэтому они более понятны. Их роль неоценима для следующих действий:•введения в проект новых людей;•понимания системы спустя месяцы или годы после ее поставки;•понимания того, как система выполняет требования пользователей;•обеспечения прослеживаемости требований;•планирования обслуживания и улучшения;•понимания логической архитектуры системы;•привлечения внешних ресурсов к разработке системы.Если необходимо чтото из перечисленного выше, несомненно, аналитическое представление должно быть сохранено.

Обычно аналитическое представление должно сохраняться для любой большой, сложной,стратегически важной системы или системы с предположительно большим ресурсом. Это означает, что необходимо выбирать между стратегиями 3 и 4. Возможность рассинхронизации аналитической и проектной моделей должна быть всегда очень тщательно продумана. Допустимо ли это для разрабатываемого проекта?Если система небольшая (скажем, меньше 200 проектных классов), тогда непосредственно проектная модель достаточно мала и понятна, поэтому в отдельной аналитической модели, возможно, и нет необходимости. Также, если система не имеет стратегического значения илинедолговечна, разделение аналитической и проектной моделей – излишнее требование.

В этом случае необходимо выбирать между стратегиями 1 и 2, и решающим фактором будут возможности используемогоинструментального средства UMLмоделирования. Некоторые инструменты моделирования сохраняют одну базовую модель и обеспечиваютвозможность применения фильтров и сокрытия информации для восстановления «аналитического» представления из проектной модели.Это разумный компромисс для многих систем среднего размера, но дляочень больших систем этого, скорее всего, недостаточно.И наконец, стоит помнить о том, что реальный срок службы многихсистем существенно превышает предполагаемый!16.4. Детализация рабочего потокапроектированияРабочий поток UP для проектирования представлен на рис. 16.6.

Основные его участники: архитектор, разработчик прецедентов и разработчик компонентов. В большинстве ОО проектов роль архитекторавыполняют один или несколько специалистов, но часто они же потомявляются разработчиками прецедентов и компонентов.366Глава 16. Рабочий поток проектированияПроектирование архитектурыАрхитекторПроектирование прецедентаРазработчик прецедентовРазработчик компонентовПроектирование классаПроектирование подсистемыРис. 16.6.

Рабочий поток проектирования. Воспроизведено с рис. 9.16 [Jacobson 1]с разрешения издательства Addison+WesleyОдна из целей UP состоит в том, чтобы определенные члены командыотвечали за отдельные части системы, начиная с анализа и заканчиваяреализацией. Таким образом, специалист или команда, ответственныеза создание конкретной части ОО аналитической модели, будут дополнять ее до проектной модели и, возможно с помощью программистов,превращать ее в код. При таком подходе (в этом его основное преимущество) нет «перекладывания ответственности» друг на друга междуаналитиками, проектировщиками и программистами, что распространено в ОО проектах.16.5. Деятельность UP: проектированиеархитектурыВ UP начало всему процессу проектирования дает деятельность подназванием Проектирование архитектуры (architectural design).

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

Самое главное, необходимо понять, чтопроектирование архитектуры заключается в предварительном описании артефактов, важных с архитектурной точки зрения, с целью создания общего плана архитектуры системы. Обозначенные в общихчертах артефакты являются входными данными для более детальногопроектирования, в процессе которого происходит их конкретизация.36716.6. Что мы узнали«subsystem»Подсистема[в общих чертах]МодельпрецедентовАрхитекторИнтерфейс[в общих чертах]МодельтребованийПроектированиеархитектурыПроектный класс[в общих чертах]АналитическаямодельМодель развертывания[в общих чертах]ОписаниеархитектурыОписание архитектурыРис.

16.7. Деятельность UP Проектирование архитектуры. Адаптированос рис. 9.17 [Jacobson 1] с разрешения издательства Addison+WesleyОбычно Проектирование архитектуры не выделяется в отдельный шаг. Неследует забывать, что UP – итеративный процесс. Таким образом, проработка деталей архитектуры системы ведется на всем протяжениизавершающих этапов Уточнения и в начале Построения.16.6. Что мы узналиВ рабочем потоке проектирования определяется, как будет реализовываться функциональность, описанная в аналитической модели. Мы узнали следующее:• Проектирование – основная деятельность при моделировании в последней части фазы Уточнение и первой части фазы Построение.• Анализ и проектирование в некоторой степени могут происходить параллельно.• Одна команда должна провести артефакт от анализа до проектирования.• ОО проектировщики основное внимание должны уделять главнейшим вопросам проектирования, таким как арихитектурыраспределенных компонентов – политики и стандарты должны368Глава 16.

Рабочий поток проектирования••••вводиться для решения тактически важных вопросов проектирования.Проектная модель включает:• проектные подсистемы;• проектные классы;• интерфейсы;• реализации прецедентов – проектные;• диаграмму развертывания (в первом приближении).Отношения отображения существуют между:• проектной и аналитической моделями;• одной или более проектными подсистемами и пакетом анализа.Следует поддерживать две отдельные модели, аналитическую и проектную, если система:• большая;• сложная;• стратегически важная;• подвержена частым изменениям;• предположительно с большим сроком службы;• для ее разработки привлекаются внешние ресурсы.Деятельность UP Проектирование архитектуры – это итеративный процесс, имеющий место в конце фазы Уточнение и в начале фазы Построение:• в ходе процесса создаются и описываются в общих чертах артефакты, которые в дальнейшем конкретизируются.17Проектные классы17.1.

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

Деятельность UP: Проектирование классаВ детализации рабочего потока проектирования в UP (рис. 16.6) послеПроектирования архитектуры (Architectural design) следуют деятельностиПроектирование класса (Design a class) и Проектирование прецедента (Designa use case) (раздел 20.2). Они являются параллельными и итеративными.В этом разделе рассматривается деятельность UP Проектирование класса,представленная на рис. 17.2. Мы расширили ее и показали Интерфейс[полный] как явный результат Проектирования класса.

Характеристики

Список файлов книги