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

Включение шаблона и/или механизма эффективно выполняет ряд последовательных действий в этой задаче (добавление новых классов, атрибутов и взаимосвязей), но в соответствии с правилами, определенными этим шаблоном или механизмом.

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

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

В зависимости от типа класса анализа (пограничный, сущностный или управляющий), существуют определенные стратегии создания начальных классов проекта.

Проектирование пограничных классов

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

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

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

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

Проектирование сущностных классов

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

Подробное обсуждение проблем проектирования постоянных классов представлено ниже под заголовком Определение постоянных классов.

Проектирование управляющих классов

Управляющие объекты ответственны за управление потоком вариантов использования, и, следовательно, они координируют большую часть их действий. Управляющие объекты инкапсулируют логику, которая не относится напрямую к пользовательскому интерфейсу (пограничным объектам) или проектированию данных (сущностным объектам). Эта логика является тем, что иногда называется логикой приложения или бизнес-логикой.

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

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

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

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

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

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

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

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

• Хранение в памяти
• Флэш-карта
• Двоичный файл
• Система управления базами данных (DBMS)

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

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

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

Для каждого класса определите его видимость в пакете, в котором он расположен. На класс public можно ссылаться снаружи содержащего его пакета. На класс private (или на класс, видимость которого - это implementation) может ссылаться только класс того же пакета.

• Определение операций
• Именование и описание операций
• Определение видимости операций
• Определение операций класса

Определение операций

Для определения операций в классах проекта:

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

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

Рисунок 1: Форма сообщений, основа определения операций

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

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

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

Именование и описание операций

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

Для каждой операции необходимо определить следующее:

• Имя операции - имя должно быть коротким и наглядно описывать результат операции.
  • Имена операций должны соответствовать синтаксису языка реализации. Пример: find_location применимо для C++ или Visual Basic, но не для Smalltalk (в котором не используются знаки подчеркивания). Имя, подходящее для всех - это findLocation.
  • Избегайте имен, выражающих способ выполнения операции. Например, Employee.wages() - это лучше, чем Employee.calculateWages(), так как второе говорит о выполняемом вычислении. Операция может просто возвращать значение в базу данных.
  • Имя операции должно ясно обозначать ее цель. Избегайте неопределенных имен, таких как getData, которые не описывают возвращаемый результат. Используйте имена, которые точно обозначают ожидаемый результат, например, getAddress. Еще лучше, если имя операции просто совпадает с именем свойства, которое оно получает или устанавливает. Если она имеет параметр, значит она устанавливает свойство. Если параметр отсутствует, значит она получает свойство. Пример: операция address возвращает адрес Customer, в то время как address(aString) устанавливает или изменяет адрес Customer. Сигнатура операции неявно предполагает, получает ли или устанавливает значение операция.
  • Концептуально эквивалентные операции должны иметь одинаковые имена, даже если их определяют разные классы, если они реализованы совершенно различными способами, или если они имеют разное число параметров. Например, операция, создающая объект, должна иметь одинаковое имя во всех классах.
  • Если операции в нескольких классах имеют одинаковую сигнатуру, они должны возвращать результаты одинакового вида, соответствующие получающему объекту. Это является примером полиморфизма, который означает, что разные объекты должны отвечать на одно сообщение одинаково. Пример: операция name должна возвращать имя объекта, независимо от того, как имя хранится или порождается. Следование этому принципу упрощает понимание модели.
• Тип возврата - Тип возврата должен быть классом объекта, возвращаемого операцией.
• Короткое описание - Имя операции часто неясно описывает, что она делает. Дайте операции короткое описание из пары предложений с точки зрения ее пользователя.
• Параметры - Для каждого параметра создайте короткое выразительное имя и его короткое описание. При создании параметров помните, что меньшее их количество означает более высокую возможность их повторного использования. Небольшое количество параметров облегчает понимание операции и, следовательно, увеличивает вероятность обнаружения подобных операций. Может понадобиться разделить операцию с большим количеством параметров на несколько операций. Операция должна быть понятна тем, кто ее будет использовать. Короткое описание должно включать в себя:
  • смысл параметров, который не ясен из их имен
  • передается ли параметр по значению или по ссылке
  • параметры, которые должны иметь значения
  • параметры, которые могут быть необязательны, и их значения по умолчанию
  • допустимые диапазоны значений параметров, если они применяются
  • что делает операция
  • какие параметры по ссылке изменяются операцией

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

Более подробная информация содержится в разделе Рекомендации по рабочему продукту: Класс проекта.

Определение видимости операций

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

• Public - операция видима элементам модели, отличным от самого класса.
• Implementation - операция видима только внутри самого класса.
• Protected - операция видима только самому классу, его подклассам и друзьям класса (зависит от языка).
• Private - операция видима только самому классу и друзьям класса.

Выберите наиболее ограниченную видимость из тех, которые могут обеспечить выполнение целей операции. Для этого определите на диаграммах схем связей, приходит ли каждое сообщение из внешнего класса по отношению к пакету получателя (требует видимости public), из класса внутри пакета (требует видимости implementation), из подкласса (требует видимости protected), из самого класса или его друга (требует видимости private).

Определение операций класса

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

Строка операции, которая имеет область видимости класса, подчеркивается.

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

Метод должен описывать, как:

• операции будут реализованы
• атрибуты будут реализованы и использованы для реализации операций
• взаимосвязи будут реализованы и использованы для реализации операций

Требования меняются от случая к случаю, однако, спецификации метода класса всегда определяют:

• что будет сделано в соответствии с требованиями
• какие другие объекты и их операции будут использованы

Более специальные требования могут относится к:

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

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

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

Пример простого конечного автомата показан на Рисунке 2.

Рисунок 2: Простая диаграмма состояний для дозатора топлива

Каждое событие изменения состояния может быть связано с операцией. В зависимости от состояния объекта, операция может иметь разное поведение, и события перехода описывают, как это происходит.

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

Более подробная информация находится в разделе Прием: Диаграмма состояний.

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

• его имя, которое должно соответствовать соглашению об именах и языка реализации, и проекта
• его тип, являющийся элементарным типом данных, поддерживаемым языком реализации
• его начальное значение или значение по умолчанию, которое устанавливается при создании нового экземпляра класса
• его видимость, принимающую одно из следующих значений:
  • Public: атрибут видим и внутри, и снаружи пакета, который содержит класс
  • Protected : атрибут видим только самому классу, его подклассам и друзьям класса (зависит от языка)
  • Private : атрибут видим только самому классу и друзьям класса
  • Implementation : атрибут видим только самому классу
• для постоянных постоянных классов, является ли атрибут постоянным (по умолчанию) или временным. Даже если сам класс является постоянным, не все его атрибуты должны быть постоянными.

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

Более подробная информация об атрибутах находится в разделе, названном Атрибуты, в Рекомендации по рабочему продукту: Класс проекта.

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

• Должна ли ссылка на получателя передаваться в качестве параметра в операцию? Если да, то установите зависимость между классами отправителя и получателя на диаграмме классов, содержащей эти два класса. Также, если для взаимодействий используется формат диаграммы связи, то укажите видимость ссылки и установите для нее значение параметр.
• Является ли получатель глобальным? Если да, то установите зависимость между классами отправителя и получателя на диаграмме классов, содержащей эти два класса. Также, если для взаимодействий используется формат диаграммы связи, то укажите видимость ссылки и установите для нее значение глобальная.
• Является ли получатель временным объектом, создаваемым и уничтожаемым в самой операции? Если да, то установите зависимость между классами отправителя и получателя на диаграмме классов, содержащей эти два класса. Также, если для взаимодействий используется формат диаграммы связи, то укажите видимость ссылки и установите для нее значение локальная.

Заметьте, что моделируемые таким образом ссылки являются временными ссылками, которые существуют ограниченный период времени в определенном контексте кооперации. В этом смысле, они являются экземплярами роли связи в кооперации. Однако, взаимосвязь в модели класса (то есть, независимая от контекста) должна являться зависимостью, как это указано выше. Как указано в [RUM98] в определении временной связи: "Все такие ссылки возможно моделировать как связи, но тогда условия связи должны быть указаны явно, и они теряют в своей точности в ограничивающих комбинациях объектов". В такой ситуации, моделирование зависимости менее важно, чем моделирование взаимосвязи в кооперации, потому что зависимость не описывает взаимосвязь полностью, а только указывает на ее существование.

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

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

Рисунок 3: В диаграммы связи

Определение связей и объединений

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

• Установите свойство Инициатива для связей и объединений. Это можно сделать, принимая во внимание, что свойство Инициатива требуется для создания экземпляров их ссылок на диаграмме взаимодействий. Так как по умолчанию значение свойства Инициатива равно true, необходимо только найти связи (и объединения), для которых роли всех объектов класса на другом конце ссылки в этой связи не требуют этого свойства. В таких случаях, установите значение свойства Инициатива равным false для роли класса.
• Если в самой связи существуют атрибуты, создайте класс проекта для представления класса связи с соответствующими атрибутами. Поместите этот класс между двумя другими классами и установите связи с соответствующей множественностью между классом связи и двумя другими классами.
• Укажите, должны ли концы связи быть упорядоченными или нет. В этом случае связь объектов должна иметь упорядочение.
• Если на связанный (или объединенный) класс ссылается только текущий класс, решите, должен ли он быть вложенным. Преимущества вложения классов состоят в более быстром обмене сообщениями и простоте модели проекта. Недостатки включают в себя статическое выделение памяти для вложенного класса, независимо от того, существуют ли его экземпляры или нет, невозможность определения объекта отдельно от включающего класса, невозможность ссылки на экземпляры вложенного класса снаружи включающего класса.

Связи и объединения удобнее всего определять на диаграмме классов, на которой изображены связанные классы. Диаграмма классов должна принадлежать пакету, который содержит связанные классы. На Рисунке 4 показан пример диаграммы классов, изображающей связи и объединения.

Рисунок 4: Пример диаграммы классов, показывающей связи, объединения и обобщения между классами.

Управления связями-подписками между классами анализа

Связи-подписки между классами анализа используются для определения зависимостей событий между классами. В Модели проекта необходимо управлять этими зависимостями событий явно, или с помощью доступных структур описателей событий, или с помощью проектирования и построения своей собственной структуры описателей событий. В некоторых языках программирования, таких как Visual Basic, это можно сделать непосредственно: вы определяете соответствующие события и управляете ими. В других языках, можно использовать некоторую дополнительную библиотеку для многократно используемых функций, чтобы управлять подписками и событиями. Если требуемую функциональность невозможно приобрести, ее необходимо спроектировать и реализовать. См. также раздел Прием: Связь-подписка.

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

В UML 2.0 классы определяются как структурные классы, способные иметь внутреннюю структуру и порты. Таким образом, классы могут быть разложены на набор связанных компонентов, которые, в свою очередь, могут быть разложены. Класс может быть инкапсулирован принудительными связями снаружи для передачи через порты в соответствии с объявленными интерфейсами.

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

Более подробная информация и примеры составных структурных диаграмм находятся в разделе Концепция: Структурные классы.

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

Когда вы обнаружите обобщение, создайте общий суперкласс, содержащий общие атрибуты, связи, объединения и операции. Удалите общее поведение из классов, которые станут подклассами этого общего суперкласса. Определите отношение обобщения между подклассом и суперклассом.

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

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

Если используется синхронный обмен сообщениями, то выполнение операции заблокирует последующие вызовы объектов до ее завершения. Синхронный обмен сообщениями предполагает порядок обработки сообщений первый-пришел-первый-обслужен. Это может разрешить конфликт параллелизма, особенно в случаях, когда все сообщения имеют одинаковый приоритет, или когда все сообщения принадлежат одной нити выполнения. В случаях, когда к одному объекту имеют доступ разные нити управления (представленные активными классами), должны использоваться явные механизмы предотвращения или разрешения конфликтов параллелизма.

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

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

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

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

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

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

• использовать существующие продукты и компоненты
• адаптировать к языку программирования
• распределить объекты
• достигнуть приемлемой производительности
• достигнуть определенного уровня защиты
• управлять ошибками

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

• Модель проекта
• справочная таблица для классов проекта