Наименование ролей и ассоциаций даны в таком объёме, чтобы избегать повторений и переполнения пространства диаграммы.
Далее один из прецедентов представлен в табличной форме. Описание прецедента отражают фактический порядок осуществления заказов на получение публикации в библиотеке. В частности, пользователь имеет самостоятельный доступ к каталогу для поиска публикаций. Каталог не содержит информации о выдаче публикаций, и читатель может её получить только в ходе заказа.
Диаграмма концептуальных классов проекта поддержки библиотеки
Диаграмма прецедентов проекта поддержки библиотеки
Прецедент из проекта поддержки библиотеки
Имя прецедента | Выполнение заказа |
Исполнители | Читатель и библиотекарь |
Описание | Осн. Читатель передает библиотекарю информацию, идентифицирующую себя и публикацию, которую читатель хотел бы получить. Библиотекарь убеждается по реестру, что читатель зарегистрирован в библиотеке и экземпляр требуемой публикации может быть выдан. Библиотекарь передает экземпляр требуемой публикации и фиксирует факт выдачи. A1. Читатель не зарегистрирован в библиотеке. Заказ отклоняется. A2. Читатель зарегистрирован, но заказанная публикация выдана. Заказ отклоняется |
Предусловия | Читатель реализовал прецедент «Справка о наличии» и узнал, что искомая публикация входит в библиотечный фонд. |
Постусловия | Если читатель получил заказанную публикацию, то в карточке читателя отмечается факт выдачи. |
В данном случае, Осн. – основная последовательность действий (основной сценарий).
A1-A2. Альтернативные сценарии.
УПРАЖНЕНИЯ.
1. Описать остальные прецеденты проекта
6.2.2.Первые проектные решения
В рамках следующей фазы проектирования принимается решение о границах проектируемой компьютерной поддержки и её месте в библиотеке. Оно состоит в том, что картотечные каталог и реестр заменяются компьютерной системой, которая обеспечивает ведение двух баз данных – по фонду публикаций и контингенту читателей. Читатель имеет прямой доступ к фонду публикаций для поиска и чтения. Все функции оперативного изменения содержимого баз данных осуществляет библиотекарь. Это решение фиксируется в уточненных описаниях прецедентов (в табличной и графической формах) и диаграммах проектных классов и системных взаимодействий.
Далее представлены первичная версия диаграммы проектных классов, диаграммы системных последовательностей основного сценария прецедента «Выполнение заказа» и соответствующей диаграммы кооперации.
Эти диаграммы представляют интерфейс между пользователем – библиотекарем и проектируемой компьютерной системой и оставляют открытыми многие детали этого интерфейса равно, как и вопросы его реализации внутри системы.
Первичная диаграмма проектных классов
Диаграмма системных последовательностей для прецедента «Выполнение заказа»
Диаграмма кооперации (системная) для сценария «Выполнение заказа»
6.2.3. Ключевые элементы реализации
В ходе реализации принятых решений складывается вполне типовая ситуация, когда информационная система (ИС) должна обеспечивать учёт действий пользователя с некоторым множеством (фондом) однотипных объектов (элементов фонда), например, менеджера с проектами, в рассматриваемом случае - библиотекаря с экземплярами печатных изданий и читателями. Обобщённая концептуальная диаграмма классов в этой ситуации показана на Рис.1.
Рисунок 1. Концептуальная диаграмма классов для типового фрагмента проекта
Единственный атрибут элемента – состояние – обобщает всевозможные состояния моделируемого объекта, например, книга может быть выдана, проект – приостановлен, читатель - зарегистрирован. Ассоциация “действует” обобщает всевозможные действия пользователя, изменяющие состояния объекта, а также “Включение объекта в фонд” и “Изъятие объекта из фонда”.
Диаграмма последовательностей для системных операций представлена на Рис.2, а соответствующая диаграмма кооперации – на Рис.3.
Рисунок 2. Диаграмма последовательностей системных операций для типового фрагмента проекта
Рисунок 3. Диаграмма кооперации системных операций для типового фрагмента проекта
Диаграмма классов проекта строится на основе концептуальной диаграммы классов и диаграмм взаимодействия. При этом определяется набор классов, которые исполняют системные операции, показанные в диаграммах взаимодействия, и служат прототипами классов исходного языка программирования, на котором записывается проект. Первичными кандидатами в классы проекта являются классы концептуальной диаграммы.
Простейшее и вполне удовлетворительное решение этой задачи состоит в назначении всех системных операций классу “Фонд” и реализации их в виде методов соответствующего класса в программе. Выбор в языке программирования способа представления “Элементов”, входящих в “Фонд” определяется следующими требованиями, вытекающими из определения системных операций:
· в “Фонд” может входить любое (в частности, пустое) конечное множество однотипных “Элементов”,
· необходимы элементарные операции для добавления, удаления и выборки “Элемента” по некоторому признаку.
В языке C# этим требованиям удовлетворяют классы List(T) и ArrayList. Функциональность этих классов можно передать классу “Фонд”, реализовав его как их наследника или введя в “Фонд” атрибут типа ArrayList или List(T). Для реализации концептуального класса “Элемент” можно выбрать типы Struct или Class.
На Рис.4 показана диаграмма классов для первого варианта проекта (Варианта А), в котором “Фонд” реализуется как наследник класса List(T).
Рисунок 4. Диаграмма классов для первого варианта фрагмента проекта Соответствующие диаграмма последовательностей и диаграмма кооперации показаны на Рис.5 и 6.
Рисунок 5. Диаграмма последовательностей для первого варианта типового фрагмента проекта
Рисунок 6. Диаграмма кооперации для первого варианта типового фрагмента проекта
В этом варианте проекта установлено, что элементы фона идентифицируются строкой и сам пользователь заботится об уникальности элементов. Хотя на диаграммах показаны только те операции типа List(T), которые необходимы для реализации выбранных системных операций, и не показаны базовые операции, необходимые для реализации пользовательского интерфейса, класс “Фонд” оказался функционально перегружен. Поэтому предложен второй вариант (Вариант Б), в котором введен класс “Список элементов”, и “Фонд” связан с экземпляром этого класса как с элементом своей конструкции. Кроме того, введен класс “Фасад”, который реализует связь с пользователем на базе формы
Соответствующие диаграмма классов и диаграмма последовательностей показаны на Рис.7 и 8.
Рисунок 7. Диаграмма классов для второго варианта проекта
Рисунок 8.Диаграмма последовательностей для второго варианта проекта (операции «Включить» и «Показать»).
Рисунок 9.Диаграмма последовательностей для второго варианта проекта (операции “Ввести” и “Исключить”).
6.2.4. Программная реализация на языке C++
Приведённые выше диаграммы могут быть конкретизированы на языке C++ в среде Microsoft Visual Studio в виде версии CLR следующим образом (проект CppLab02).
Класс Fasade, отвечающий за взаимодействие с оператором, определён в модуле (файле) Fasade.h – наследнике класса Form. Экземпляр класса Fasade как главная форма приложения обеспечивает визуальный интерфейс с оператором, когда приложение запущено. Далее показан вид этой формы.
Пункты главного меню представляют собой операции, которые пользователь активирует, когда работает с фондом. «Включить» создает элемент фонда со свойствами, значения которых пользователь должен перед операцией установить в окнах «Идентификатор» и «Состояние». «Показать» обеспечивает поиск элемента фонда по значению, установленному в окне «Идентификатор», и вывод в свойства State этого элемента в окно «Состояние» на форме. «Ввести» ищет элемент по «Идентификатору» и присваивает свойству State найденного элемента значение из окна «Состояние». «Исключить» находит элемент фонда по значению, установленному в окне «Идентификатор», и удаляет его из фонда. Если поиск в этих операциях не приводит к успеху, то в окне «Состояние» устанавливается значение
-3. Значение окна «Идентификатор» должно быть десятичным числом.
Операции реализуются обработчиками событий Click соответствующих пунктов меню. Их тексты нетрудно найти в листинге файла Fasade.h, приведённом далее.