00 (1158679), страница 11

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

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

Образец «Модель предметной области»

Аннотация: Обязанности по обработке запросов распределены по сети объектов-сущностей. В приложении создается слой объектов, описывающих структурные и поведенческие аспекты предметной области. Поведение сочетается с данными и реализуется в сущностях. Управляющие объекты довольствуются ролью посредников между граничными объектами и сущностями.

Э
скиз:

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

Отдельные этапы удаления расписания реализуются отдельными объектами. Объект студент обнуляет в себе ссылку на расписание и передает работу дальше объекту-расписанию. Объект-расписание отсылает запрос на удаление ссылки на себя из объекта-курса и освобождает занимаемую собой память.

Набор обязанностей классов, полученный в результате их распределения, должен быть проанализирован на предмет выявления и устранения следующих проблем:

• дублирования одинаковых обязанностей в различных классах;

• противоречивых обязанностей в рамках класса;

• классов с одной обязанностью или вообще без обязанностей;

• классов, взаимодействующих с большим количеством других классов.

Атрибуты классов анализа определяются, исходя из знаний о предметной области, требований к системе, глоссария и бизнес-модели. В процессе анализа атрибуты определяются только для классов-сущностей. Атрибуты должны быть простыми. Сложные атрибуты должны моделироваться как ассоциации между классами.

Связи между классами определяются в два этапа. Начальный набор связей определяется на основе анализа кооперативных диаграмм. Если два объекта обмениваются сообщениями, между ними должна быть ассоциация.

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

Квалификация механизмов анализа состоит в том, что:

• Составляется список всех механизмов анализа.

• Классы анализа ставятся в соответствие механизмам анализа.

• Определяются характеристики механизмов анализа.

Механизмы анализа играют следующие роли:

• Отражают нефункциональные требования к системе (надежность, безопасность и т.д.) и их реализацию в архитектуре системы.

• Представляют собой набор типовых решений, или образцов (patterns), принятых в качестве стандарта данного проекта.

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

Так, имея дело с устойчивыми классами, достаточно указать для них механизм «persistencу», не задумываясь как именно будет реализовано сохранение их экземпляров в базе данных. Пример:

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

• имя и описание каждого класса анализа должно отражать сущность его роли в системе;

• классы с одинаковым поведением, или представляющие одно и то же явление, должны объединяться;

• классы-сущности с одинаковыми атрибутами должны объединяться (даже если их поведение отличается).

По результатам унификации классов должны быть модифицированы описания вариантов использования.

По окончании модель анализа должна быть подвергнута проверке:

1. Все ли классы обоснованы надлежащим образом?

2. Отражает ли имя каждого класса его роль?

3. Представляет ли класс единственную, четко определенную абстракцию?

4. Являются ли все атрибуты и обязанности класса функционально связанными?

5. Отражают ли классы всю функциональность вариантов использованию, заключенную в основных, подчиненных и альтернативных потоках событий?

6. Однозначно ли распределено поведение по классам?

Лекция 8. Проектирование программного обеспечения

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

Этапы проектирования:

1. Проектирование архитектуры системы.

   1. Идентификация архитектурных решений и механизмов проектирования;

   2. Анализ взаимодействий между классами анализа, выявление проектных классов, подсистем и интерфейсов;

   3. Формирование архитектурных уровней;

   4. Проектирование структуры потоков управления;

   5. Проектирование конфигурации системы.

2. Проектирование элементов системы.

   1. Уточнение реализаций вариантов использования.

   2. Проектирование подсистем.

   3. Проектирование классов.

   4. Проектирование баз данных.

Проектирование архитектуры системы выполняется архитектором.

В процессе проектирования определяются детали реализации архитектурных механизмов, обозначенных в процессе анализа. Например, уточняется способ хранения данных, реализация дублирования для повышения надежности системы и т. п. Поскольку практически все механизмы – это некоторые типовые решения (образцы, шаблоны, каркасы), они документируются в проекте (модели) с помощью кооперации со стереотипом <<mechanism>>, при этом структурная часть механизма описывается с помощью диаграмм классов, а поведение – с помощью диаграмм взаимодействия.

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

Взаимодействие экземпляров классов, в рамках механизма описывается диаграммами взаимодействия

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

Первым действием архитектора при выявлении подсистем является преобразование классов анализа в проектные элементы.

По каждому классу анализа принимается одно из двух решений:

• класс анализа отображается в проектный класс, если он представляет единственную логическую абстракцию или достаточно прост для реализации;

• сложный класс анализа может быть разбит на несколько классов, преобразован в пакет или в подсистему.

Совокупности проектных классов объединяются в пакеты или подсистемы. При объединении классов в пакеты учитывается, что:

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

• Пакеты – средство распределения ресурсов между командами разработчиков.

• Разные пакеты могут соответствовать разным типам пользователей.

• Как пакет можно оформить повторно используемый код, встроенный в систему.

Например, если пользовательский интерфейс нестабилен, имеет смысл объединить все классы, его реализующие, в отдельный пакет. Если UI не будет подвергаться существенным изменениям, можно объединить в отдельные пакеты классы, взаимодействующие при реализации разных вариантов использования.

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

После выделения пакетов устанавливаются зависимости между ними и видимость членов пакета. К закрытым членам пакета доступ извне запрещен. Это позволяет скрыть внутреннее устройство пакета.

Несколько классов могут быть объединены в подсистему если:

• классы имеют функциональную связь (участвуют в реализации варианта использования и взаимодействуют только друг с другом);

• совокупность классов реализует функциональность, которая может быть удалена из системы или заменена на альтернативную;

• классы сильно связаны;

• классы размещены на одном узле вычислительной сети.

Заметим, что связь клиентского класса с подсистемой более гибкая, чем с пакетом, в том смысле, что изменения внутри подсистемы не затрагивают клиентский класс. Во втором случае изменения из пакета могут распространиться на клиента вдоль зависимости. Обратной стороной гибкости является такой неприятный факт – интерфейс должен быть стабильным. Любое изменение в интерфейсе затронет реализующую его подсистему (вдоль связи реализации), а также клиентский класс, которому требуется данный интерфейс (вдоль зависимости). Очень желательно сразу правильно описать интерфейсы!

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

При создании подсистем в модели выполняются следующие преобразования:

• объединяемые классы помещаются в специальный пакет с именем подсистемы и стереотипом <<subsystem>>;

• спецификации операций классов, образующих подсистему, выносятся в интерфейс подсистемы – класс со стереотипом <<interface>>;

• характер использования операций интерфейса и порядок их выполнения документируется с помощью диаграмм взаимодействия, которые вместе с диаграммой классов подсистемы объединяются в кооперацию с именем интерфейса и стереотипом <<interface realization>>;

• в подсистеме создается класс-посредник со стереотипом <<subsystem proxy>>, управляющий реализацией операций интерфейса.

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

• Имя интерфейса: короткое (одно-два слова), отражающее его роль в системе.

• Описание интерфейса: должно отражать его ответственности (размер – небольшой абзац).

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

• Документирование интерфейса: характер использования операций и порядок их выполнения (показывается с помощью диаграмм последовательности), тестовые планы и сценарии и т.д. Вся эта информация объединяется в специальный пакет.

Следующим этапом является формирование архитектурных уровней. В ходе анализа было принято предварительное решение о выделении архитектурных уровней. В ходе проектирования все проектные элементы системы должны быть распределены по данным уровням. С точки зрения модели это означает распределение проектных классов, пакетов и подсистем по пакетам со стереотипом «layer», соответствующим архитектурным уровням.

Следующий этап – проектирование структуры потоков управления. Оно выполняется при наличии в системе параллельных процессов (параллелизма). Цель проектирования – выявление существующих в системе процессов, характера их взаимодействия, создания, уничтожения и отображения в среду реализации. Требования параллелизма возникают в следующих случаях:

• необходимо распределение обработки между различными процессорами или узлами;

• система управляется потоком событий (event-driven system);

• вычисления в системе обладают высокой интенсивностью;

• в системе одновременно работает много пользователей.

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

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

Для моделирования структуры потоков управления используются так называемые активные классы – классы со стереотипами <<process>> и <<thread>>. Активный класс владеет собственным процессом или потоком и может инициировать управляющие воздействия. Связи между процессами моделируются как зависимости. Потоки могут существовать только внутри процессов, поэтому связи между процессами и потоками моделируются как композиции. Модель потоков управления помещается в пакет Process View (представление процессов – одно из архитектурных представлений в модели «4+1»). В качестве примера приведена диаграмма классов, описывающая структуру процесса регистрации студента на курсы. Обратите внимание, что все классы на ней являются активными (выделены жирными границами).

Создание потоков во время инициализации приложения моделируется с помощью диаграмм взаимодействия.

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

Список файлов лекций