- •Стратегии «Руководство по основным действиям и компонентам».
- •Стратегии идентификации назначения и характерных свойств системы
- •Описание примера: Магазин (приложение для торгового терминала)
- •1.4.1. Идентификация назначения системы
- •1.4.2. Идентификация характерных свойств системы
- •Определение средств регистрации важной информации
- •Определение средств ведения бизнеса
- •Определение средств анализа результатов бизнеса
- •Определение средств взаимодействия с другими системами
- •Замечания по поводу назначения и характерных свойств системы
- •1.5. Выбор объектов
- •1.5.1. Использование компонентов модели для организации работы
- •1.5.2. Выбор объектов проблемной области
- •Выбор актеров и участников
- •1.6. Применение образцов: выбор и упорядочивание объектов проблемной области
- •1.6.1. Участник-транзакция
- •1.6.2. Место-транзакция
- •1.6.3. Транзакция - следующая транзакция
- •1.6.4. Контейнер-содержимое
- •1.6.5. Транзакция-экземпляр строки транзакции
- •1.6.6. Актер-участник
- •1.6.7. Общая схема на данный момент
- •1.7. Применение стратегий для определения обязанностей объектов проблемной области
- •1.7.1. Обязанности актеров и участников Актер: человек
- •Участник: кассир
- •Участник: покупатель.
- •1.7.2. Обязанности мест Магазин
- •1.7.3. Обязанности реальных вещей
- •Экземпляр товара
- •Универсальный код товара upc
- •Описание каждого атрибута
- •Регистрирующее устройство
- •Ящик кассового аппарата
- •Важное замечание по поводу состояния операции
- •Категория налога
- •1.7.4. Обязанности транзакций проблемной области
- •Продажа
- •Экземпляр строки продажи
- •Описание каждой службы
- •Новый вариант экземпляра строки продажи
- •Что совпадает, а что отличается Оплата и ее виды
- •1.8. Применение образцов: определение обязанностей в проблемной области
- •Множество-рабочий
- •Участник-транзакция
- •Транзакция-экземпляр строки транзакции
- •Экземпляр товара-экземпляр строки
- •Общая схема на данный момент
- •1.9. Разработка динамики проблемной области с помощью сценариев
- •1.9.1. Выбор ключевых сценариев
- •1.9.2. Сценарий: вычисление общей суммы при продаже
- •1.10. Выбор объектов взаимодействия с человеком
- •1.10.1. Выбор окон
- •1.10.2. Выбор отчетов
- •1.11. Определение обязанностей для взаимодействия с человеком
- •1.11.1. Обязанности для окон
- •Окно регистрации
- •Окно продажи
- •1.11.2. Обязанности отчетов Получение денег
- •1.12. Разработка динамики взаимодействия с человеком с помощью сценариев
- •1.12.1. Поиск имеющих смысл сценариев взаимодействия с человеком
- •Сценарий: регистрация в системе
- •Сценарий: провести продажу
- •1.13.2. Взаимодействие в данной системе
- •1.13.3. Определение обязанностей для взаимодействия систем
- •1.13.4. Множество систем авторизации
- •1.13.5. Разработка динамики взаимодействия систем с помощью сценариев
- •1.14. Выбор объектов управления данными и их обязанностей
- •1.14.1. Поиск
- •1.14.2. Сохранение
- •1.14.3. Разработка динамики управления данными с помощью сценариев
- •1.15. Общая схема на данный момент
Участник: кассир
А. Определение обязанностей: "что я знаю".
#50. Стратегия "Выбор атрибутов из актуальных атрибутов" |
• Это аспект возникающего объекта программного обеспечения: "Я знаю другие объекты, связанные с реальным объектом, абстракцией которого я являюсь". • Выберите атрибуты для объектов программного обеспечения из множества атрибутов, которые можно было бы применить для описания соответствующего актуального объекта (реального мира). • Сначала рассмотрите все атрибуты, а затем выберите нужные. Вначале исследуйте атрибуты данной области в общем, а затем строго с точки зрения обязанностей данной системы. |
О каждом cashier(кассире) нужно знать:
— номер;
— пароль;
— уровень авторизации; и атрибут, характеризующий конкретный сеанс:
текущий сеанс.
Модель cashierпоказана на рис.1.21.
Рис. 1.21. Кассир: «что я знаю»
Б. Определение обязанностей: "кого я знаю"
Объект cashierзнает сеанс, в котором он участвует (и любой сеанс также знает своего кассира), а также соответствующий объектperson(рис. 1.22).
Рис. 1.22. Кассир: "кого и знаю"
В. Определение обязанностей: "что я делаю".
Объект cashierимеет базовые службы:get,set,add,removeиdelete, и в качестве класса —create.
#86. Стратегия "Сделай сам" |
• Это аспект возникающего объекта программного обеспечения: "Я знаю другие объекты, связанные с реальным объектом, абстракцией которого я являюсь". • "Сделай сам" включает в себя атрибуты и службы, работающие с ними, что приводит к ослаблению соединения (coupling) и усилению связности (cohesion). • При построении моделирующей системы объект программного обеспечения будет имитировать действия реального объекта. В большинстве систем полная имитация не производится: объекты программного обеспечения делают то, что обязана делать система по отношению к конкретному объекту. |
Действия по отношению к реальному кассиру:
— проверка его авторизации (для выполнения конкретного действия):
— оценка его производительности за конкретное время.
Используя персонификациюи описывая объектcashier(являющийся абстракцией реального кассира) от первого лица, можно представить все следующим образом:
"Я кассир."
"Я знаю свой рабочий номер, имя, пароль, уровень авторизации и продажи, произведенные мной за конкретное время."
"Я определяю, могу я что-то делать, или нет."
"Я оцениваю собственную производительность."
Кто-то может возразить: "Но кассиры не авторизуют самих себя и, конечно же, нельзя допускать, чтобы они сами оценивали собственную производительность."
Рассмотрим разницу между реальными и абстрактными объектами. То, что они знают, часто совпадает, но их действия различны.
Реальный кассир — живой человек, работающий в магазине X. Объектcashierв объектной модели (а позже и в коде) — абстракция, плод вашего воображения, а не реальное лицо.
Объект cashier"знает" и "делает" то, что нужно делать системе по отношению к реальному кассиру. Этот объект и реальный кассир полностью соответствуют друг другу, равно как и их атрибуты.
#50. Стратегия "Выбор атрибутов из актуальных атрибутов" |
• Это аспект возникающего объекта программного обеспечения: "Я знаю другие объекты, связанные с реальным объектом, абстракцией которого я являюсь". • Выберите атрибуты для объектов программного обеспечения из множества атрибутов, которые можно было бы применить для описания соответствующего актуального объекта (реального мира). • Сначала рассмотрите все атрибуты, а затем выберите нужные. Вначале исследуйте атрибуты данной области в общем, а затем строго с точки зрения обязанностей данной системы. |
Службы объекта cashierи реального кассира тоже соответствуют друг другу, но лишь тогда, когда строится моделирующая система. В большинстве приложений эти службы кардинально различаются,
Это происходит потому, что службы объекта в объектной модели необходимо выполнять как часть общих обязанностей системы. Объекту в объектной модели наиболее подходят службы, позволяющие полностью и с максимальной выгодой использовать его знания. А затем объект начинает действовать.
Зададим вопрос: "Авторизован ли объект?" К какому автоматизированному объекту нужно при этом обратиться? А кто выполнит команду: "проверить производительность за конкретный период времени". Кто это сделает?
Работает, конечно, объект cashier. У него достаточно знаний для осуществления упомянутых служб. (В противном случае получилась бы модель с "объектами", храпящими данные и "объектами", хранящими функции.)
Позволяя объекту cashierвыполнять указанные задания, мы ослабляем соединение (coupling), укрепляем связность (cohesion), а также основанное на данной области разделение служб (а не атрибутов).
Заметим, что персонификация— жизненно важный аспект объектного мышления, один из наиболее важных принципов размещения служб. Он позволяет разработчикам моделей создавать распределенные атрибуты и службы на основе характерного для конкретной области разделения классов. Также он помогает применять "DFD-мышление" и "ERD-мышление".
(DFD — диаграммы потока данных и ERD -- диаграммы сущность-отношение являются двумя частями методов проектирования, в которых разделяются данные и функции.)
Более того, персонификация сама по себе очень эффективна. Используйте ее, особенно при разработке динамики системы с помощью сценариев.
Далее рассмотрим, какие службы нужны кассиру.
#90. Стратегия "Служба как вопрос" |
• Выясните, на какие вопросы может ответить объект. • Полезные исходные слова: has(имеет),how many,how much (сколько?),includes(включает в себя),is(есть). • Достигается более сильная инкапсуляция, лучшая разделяемость служб. Объекты при этом получаются более высокого качества, чем простые носители данных. |
Одна из полезных служб кассира отвечает на вопрос: "Авторизован ли он?" Запишите ее в следующем виде:
— авторизован.
#91. Стратегия "Служба как глагол" |
• Список полезных глагольных имен служб: активизировать (запустить, инициировать, открыть, начать) ответить (дать ответ) оценить (испытать, дать оценку, определить значение) вычислить (подсчитать, сосчитать, составить смету, определить цену или средний процент) дезактивиpировать (закрыть, закончить, выключить, прекратить) определить (решить, выяснить, наблюдать, разрешить) найти (получить, обнаружить, указать точное местонахождение) измерить (установить рамки, определить размер, ограничить) контролировать (проводить, направлять, управлять, наблюдать, оперировать, руководить, следить) квалифицировать (характеризовать, отличать, дискриминировать, различать, помечать) выбирать (отбирать, проводить селекцию, делать выбор, извлекать) • К службам, относящимся к разным интервалам времени, добавляйте слова "за интервал времени". |
Задачей другой полезной службы кассира является:
— оценить производительность.
Если служба применяется на различных временных интервалах, к ее имени добавляются слова "за интервал времени" (рис. 1.23).
Рис. 1.23. Кассир: «что я делаю»
Пересмотренные службы кассира:
— авторизован;
— оценить производительность за интервал времени.