Объектно-ориентированное проектирование информационных систем

Глава 4. Динамика предметной области.

4.1. Сценарии.

Для отображения динамики предметной области используется сценарий.

Наиболее удобно сценарий записывать в виде диаграммы последовательностей. Именно на основе сценариев реализуется конкретный программный код.
Сценарий применяется для:

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

Стратегия №127. "Выбор ключевых сценариев".

Разработка динамики системы.

Спланируйте динамику поведения системы (продумайте логическую и временную последовательность событий и процессов);
рассмотрите наиболее важные для системы операции и процессы;
используйте разбиение больших сценариев на "подсценарии" для более наглядного представления;
отдельно рассмотрите сложно реализуемые сценарии;
очевидные лёгкие сценарии можно не раскрывать (можно описать словесно).

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

Рассмотрим динамику взаимодействия на примере: Продажа (по оси X - объекты; по оси Y - время).

4.2. Объекты взаимодействия с человеком.

4.2.1. Выбор окон.

Стратегия №27. "Выбор окон".

Выбор объектов HI.

создайте окна для каждого объекта PD;
если объект имеет экземпляры строк, разместите их в единственном окне.

1 действие: речь идёт о классах (которые в диаграмме);

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

В случае если таких списков много, то вместо них легче помечать ссылки на окна с соответствующими списками.

Стратегия №28. "Выбор окна регистрации".

Выбор объектов HI.

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

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

Стратегия №30. "Выбор главных окон ".

Выбор объектов HI.

рассмотрите, кто и в чём испытывает потребность и почему;
создайте окна ведения бизнеса для каждой категории пользователей;
рассмотрите окна комбинаций, когда экземпляры содержания тесно связаны во времени (например, кассир зарегистрировался, на терминал и должен быть сразу сеанс);
создайте окна анализа результатов (желательно отображать результаты действительности; например, для кассира надо знать: всю ли оплату внёс покупатель).

Окна для нашей системы:

окно: регистрация - сеанс работы. Внутри окна будут вводиться их атрибуты.
окно: магазин (из него открываются окна: "товары", "кассиры", "терминалы", "продажи", "сеансы").
окно: кассир (редактирует атрибут кассира).
окно: товар (редактирование товара).
окно: товар - текущая цена - старые цены (по стратегии №27: отдельное окно старых цен).
окно: продажа - строки продажи, оплаты.

4.2.2. Выбор отчетов.

Стратегия №31. "Выбор отчётов".

Выбор объектов HI.

Рассмотрите, кто и в чём испытывает потребности и почему;
Включайте в систему только 2 вида отчётов: официально требуемые отчеты и необходимые для бизнеса. По возможности соединяйте их;
Не включайте в модель специальные вопросы, которые кто - то случайно может задать, а также устаревшие отчёты.

Отчёты для нашей системы:

касса;
отчёты за интервал времени магазина, кассира, товара.

4.2.3. Определение обязанностей объектов HI.

Стратегия № 57. "Определение атрибутов окна и отчётов".

Определение обязанностей "Что я знаю?".

для окон и отчетов включите в модель: ключевые поля, поля вводимых и выводимых данных, поля поиска и т. п.

Для окна регистрации понадобится; N терминала (как его ключ), N кассира, пароль кассира.

Стратегия № 79. "Определение связей между объектами для окна и отчета".

Определение обязанностей: "Кого я знаю?".

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

В частности для окна регистрации нужно определить объект магазин. Связь с объектом кассир будет нужна в окне регистрации.

"Что я делаю?": для окна обязанностей "Что я делаю?" - это те операции, которые оно должно выполнять в соответствии с меню, соответствующего окну объекта, а также создание объектов, (меню - набор команд, например, Action List). Для окна регистрации следует определить операцию: НачатьСеанс.

Окно магазина:
"Что я знаю?": имя.
"Кого я знаю?": магазин, все остальные окна (кроме окна регистрации).
"Что я делаю?": (все операции объекта магазин) ЗакончитьСеанс.

Окно кассира:
"Что я знаю?": N, имя, пароль.
"Кого я знаю?": кассир.
"Что я делаю?": ВСеансе, ВыручкаЗаИнт.

Окно терминал - ящик.
"Что я знаю?": N, СуммаВЯщике.
"Кого я знаю?": кассир, ящик, терминал.
"Что я делаю?": ПродажаЗаИнт, РаботаюВСеансе.

Окно товар - цена - старые цены:
"Что я знаю?": N товара, имя, код, количество на складе, цена (в рублях), дата цены.
"Кого я знаю?": товар, цена, старые цены.
"Что я делаю?": ЦенаПоДате.

Окно продажи, строки продажи, строки оплаты:
"Что я знаю?": дата/время, N кассира, N терминала.
"Кого я знаю?": продажа, сроки продажи (список), список оплат.
"Что я делаю?": ВычислитьСумму, ОсталосьОплатить, Завершить, Отменить, Принять Наличными, ДобавитьСтрокуПродажи, ДобавитьСтрокуОплаты, ПоискТовараПоКоду.

Обязанности отчётов:

отчёт касса:
"Что я знаю?": СуммаДенегВЯщике. "Что я делаю"?: Генерировать
отчёт за интервал времени: "Кого я знаю?": соответствующий объект (магазин, кассир, вид товара), может ссылаться только на магазин.
"Что я знаю?": интервал времени.
"Что я делаю?": Генерировать.

4.2.4. Разработка динамики с использованием объектов HI.

Стратегия №128. "Где начинать сценарий".

Разработка динамики.

сценарий начинайте со службы объекта PD, HI или SI.

Сценарий: Регистрация в системе.

*-если указатель Кассир пустой, то сценарий прерывается.
**-если Ложь, то сценарий прерывается.

1-3 - образуют сценарий: НачатьПродажу;
4-8 - образуют отдельный сценарий: ДобавитьСтрокуПродажи (Возврата);
9-11 - образуют сценарий: Оплата;
12-14 - образуют сценарий: ЗакончитьПродажу.

4.3. Объекты управления данными(DM).

4.3.1. Выбор объектов DM.

Стратегия № 32. "Выбор объектов управления данными".

Выбор объектов.

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

У нас появляются следующие объекты:

DM Товара;
DM Цены;
DM ЦеныСОконч;
DM Магазина;
DM Кассира;
DM Терминала;
DM Ящика;
DM Сеанса;
DM Продаж;
DM СтрокиПродажи;
DM СтрокиВозврата;
DM Оплаты;
DM ОплатыНаличными;
DM ОплатыПоКарте.

4.3.2. Определение служб и связей DM.

Стратегия № 100. "Определение служб управления данными".

Определение обязанностей: "Что я делаю".

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

У каждого объекта DM имеются операции: Найти, Сохранить, Загрузить.

Стратегия № 80. "Определение связей для объектов DM".

Определение обязанностей: "Кого я знаю".

для объекта управления данными определите его связь со всеми объектами соответствующего класса предметной области. Обычно это реализуется добавлением ссылки на объект DM в класс PD.

Важность объектов DM:

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

Для объектов SI нет необходимости создавать соответствующие объекты DM по следующим причинам:

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

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

Объектно-ориентированные базы данных:
- их недостаток в строгой привязке к языку программирования.

Реляционные базы данных: - на сегодняшний день выделяют два способа хранения:

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

Объектно-ориентированные реляционные базы данных:
- сочетают объектно-ориентированные базы данных и реляционные базы данных. Например, Oracle.