Практические исследования. Предпосылки практических исследований. Постановка задачи. Обоснование и допущения, страница 6

Некоторые типичные диаграммы последовательностей, разработанные на этой итерации, показаны на рис. 16.6 - 16.9.



 


Диаграмма пакетов

На рис. 16.13 показана первоначальная диаграмма пакетов для нашего примера.

Диаграмма зависимостей компонентов

На рис. 16.14 показана диаграмма компонентов для компонента-сущности Account, изображающего счет в примере HomeDirect.

Итерация развития 2

В данном разделе приведены ключевые пункты второй итерации развития.

Изменение требований

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

Кроме того, были выработаны требования к функциям администрирования.

Подробности реализации

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

Вкратце изменения, необходимые для перехода с EJB 1.1 на EJB 2.0, состоят в следующем.

·  Все персистентные поля с управлением от контейнера (СМР) в компонентах-сущностях заменены на аналогичные поля версии СМР 2.0. Это означает, что были удалены все прямые ссылки на эти поля в исходном коде EJB и все методы доступа заменены на абстрактные (удален код).

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

·  Требуется сборка всех компонентов приложения заново, так как средства развертывания претерпели значительное изменение.

·  Запросы в методах поиска теперь указываются с помощью EJB QL, а не обычного языка SQL.

·  Методы findByPrimaryKey теперь генерируются автоматически средствами развертывания. Чтобы обеспечить совместимость с ними, все имена таблиц и столбцов должны быть изменены в соответствии с правилами именования, используемыми этими средствами.

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

Итерация развития 3

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

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

Изменение требований

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

Предложения для итерации

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

·  Обновить список факторов риска и при необходимости скорректировать план итерации.

·  Добавить в модель прецедентов новые прецеденты.

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

·  При необходимости пересмотреть архитектуру, если она не удовлетворяет новым требованиям.

·  Разработать для каждого прецедента диаграмму представления участвующих классов (View Of Participating Classes — VOPC).

·  Обновить реализацию.

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

·  Изменить прецедент "Список операций" в соответствии с требованиями, указанными в предыдущем разделе.

·  Дополнить компонент EJB профиля пользователя возможностями сохранять и выдавать такие сведения о пользователе, как адрес электронной почты, номер телефона и почтовый адрес.

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