Основной успешный сценарий (или основной процесс)

1. Покупатель подходит к кассовому аппарату POS-системы с выбранными товарами.
2. Кассир открывает новую продажу.
3. Кассир вводит идентификатор товара.
4. С истема записывает наименование товара и выдает его описание, цену и общую стоимость. Цена вычисляется на основе набора правил. Кассир повторяет действия, описанные в пп. 3-4 для каждого наименования товара.
5. Система вычисляет общую стоимость покупки с налогом.
6. Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку.
7. Покупатель оплачивает покупку, система обрабатывает платеж.
8. Система регистрирует продажу и отправляет информацию о ней внешней бухгалтерской системе (для обновления бухгалтерских документов и начисления комиссионных) и системе складского учета (для обновления данных).
9. Система выдает товарный чек.
10. Покупатель покидает магазин с чеком и товарами (если он что-то купил).

 

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

 

 

Рис. 1. Диаграмма концептуальных классов

 

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

• Чек – это своеобразный отчет о покупке. В модель предметной области не следует включать объекты отчета
• Чек выполняет конкретную роль в реализации бизнес-правил – обеспечивает право на возврат товара. Поэтому чек следует включать на следующей итерации, когда рассматривается возврат товара

 

Рекомендации:

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

 

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

 

Совет: если некоторый объект Х в реальном мире не является числом или текстом, значит, это, скорее всего концептуальный класс. Пример: магазин – это не текст и не число, значит, концептуальный класс

 

 

Использование классов описаний

 

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

 

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

 

Ассоциации

 

Ассоциации – это отношения между классами, отражающими некоторые значимые и полезные связи между ними

 

 

Рис. 2. Пример ассоциации

 

Целесообразно в модель предметной области включать:

• Ассоциации, знания о которых необходимо сохранять в течение некоторого периода (важные ассоциации). Чтобы избежать «визуального шума»
• Ассоциации, производные от списка стандартных ассоциаций

 

Обозначение ассоциаций в UML

Рис. 3. Обозначение ассоциации в UML

 

Линии ассоциаций в модели предметной области не описывают потоки данных, ключи баз данных, имена переменных или связи объектов в программной реализации. Многие из этих связей будут реализованы в ПО.

 

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

 

Кратность

 

Кратность определяет сколько экземпляров класса А может быть ассоциировано с одним экземпляром класса Б.

 

Рис. 4. Примеры кратных ассоциаций

 

*Замечание: значение кратности определяет, сколько экземпляров одного класса может быть корректно связано с экземпляром другого класса в некоторый конкретный момент, но не на всем промежутке времени.

 

Атрибуты

 

Атрибут – логическое значение данных объекта.

 

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

 

Например,

Рис. 5. Два способа представления типа свойства объектов

В модели предметной области атрибуты должны быть типами данных. К стандартным типам атрибутов относятся: Boolean, string, integer, real. Другими часто используемыми типами являются: address, color, phone number, social security number, universal product number, post code.

 

Список стандартных ассоциаций

 

А, B – классы из модели предметной области

 

№	Категории	Примеры
	Транзакция А связана с другой транзакцией B	Платеж наличными – продажа
	А является элементом транзакции	Элемент продажи – продажа
	А является товаром или услугой для транзакции В	Элемент – элемент продажи
	А является ролью, связанной с транзакцией В	Покупатель – платеж
	А является физической или логической частью В	Устройство для печати торговых чеков – реестр
	А – физически или логически содержится в В	Реестр – магазин
	А является описанием В	Описание товара – товар
	А известнее/зарегистрирован/записан/включен в В	Продажа – реестр
	А является членом В	Кассир – магазин
	А является организационной единицей В	Отдел – магазин
	А использует, управляет или владеет В	Кассир – реестр
	А следует за В	Продажа – следующая продажа. Чек – следующий чек

 

Рис. 6. Фрагмент модели предметной области

 

Rational Software Modeler – визуальный инструмент моделирования и проектирования (фирма IBM).

 

Создан на основе технологии Eclipce

 

 

29.03.10

Диаграммы взаимодействия

 

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

 

CRC cards— Class-Responsibility-Collaborator cards

CRC-карты – это индексные карты, по одной на каждый класс, на которых кратко описаны обязанности класса и перечислены объекты, которые взаимодействуют с данным классом при выполнении этих обязанностей.

 

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

 

Диаграммы взаимодействия включают два типа:

• Диаграммы последовательностей (sequence diagram)
• Диаграммы коммуникации (communication diagram)

 

Диаграммы последовательностей иллюстрируют взаимодействие

 

Рис. 1. Диаграмма последовательности

 

(диаграмму следует рассматривать слева направо, сверху вниз)

Класс А содержит метод doOne и атрибут типа B (класса B).

Класс В, в свою очередь, содержит методы doTwo и doThree.

 

Диаграмма коммуникации

 

Рис. 2. Диаграмма коммуникации

 

Взаимодействие А и В представлено в форме графа.

 

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

 

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

 

ОСНОВНЫЕ ОБОЗНАЧЕНИЯ ДЛЯ ДИАГРАММ ПОСЛЕДОВАТЕЛЬНОСТИ

 

Прямоугольники – участники взаимодействия (реестр, продажа):

• объекты,
• классы,
• экземпляры классов

 

Между ними существуют передаваемые сообщения. Стандартный синтаксис для обозначения сообщений:

получатель = сообщение (параметр: типПараметра): типПолучателя

 

Типичными примерами участников взаимодействия являются:

 

Рис. 3. Примеры участников взаимодействия

 

1 – неименованный экземпляр класса Sale

2 – именованный экземпляр класса Sale

3 – экземпляр метакласса (Font – описание шрифтов)

 

Каждый прямоугольник участника взаимодействия имеет линию жизни – пунктирная линия

 

СООБЩЕНИЯ

 

Рис. 4. Сообщения и фокус управления с блоком выполнения

 

Сообщения изображаются в виде соединяющих вертикальные линии жизни – линии с заштрихованными стрелками (черненькая).

 

Линия сообщений с открытыми стрелками – это асинхронное сообщение.

 

Возврат сообщения может быть показан с использованием возвратной линии сообщения, исходящей из блока выполнения (блока активации).

 

Рис. 5. Два способа отображения возврата значения

 

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

Рис. 6. Сообщения, передаваемые самому объекту

 

 

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

Рис. 7. Уничтожение объекта

 

Фреймы на диаграммах последовательностей

 

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

 

Рис. 8. Пример фрейма

 

Основные операторы, изображаемые с помощью фреймов

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

 

 

Рис. 12. Условное сообщение

 

Взаимоисключающее условное сообщение имеет вид:

Рис. 9. Взаимоисключающие условные сообщения.

 

Фреймы могут быть вложенными

 

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

 

ДИАГРАММЫ КОММУНИКАЦИИ

 

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

Рис. 10. Сообщения

 

Сообщение может передаваться объектом самому себе. Начальное сообщение может не нумероваться.

Рис. 11. Нумерация последовательности сообщений

 

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

 

Рис. 12. Условное сообщение

 

В квадратных скобках указывается условное сообщение.

Сообщение передается только в случае, когда его значение истина.

 

Взаимоисключающие условные маршруты

 

Рис. 13. Взаимоисключающие сообщения

 

 

Итерационный процесс или цикл.

 

Рис. 14. Итерационный процесс или цикл

 

Цифра 1 – номер сообщения

Символ * – цикл

В скобках параметр – цикл изменяется от 1 до N

 

 

 

 

 

12.04.10

Требования и бизнес-правила

 

Для описания требований диаграммы прецедентов недостаточно. Существуют и другие артефакты требований:

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

· Словарь терминов (Включает термины и определения и может служить словарем данных)

· Документ-видение (Определяет видение проекта, описывает важнейшие идеи, положенные в основу разработки системы)

· Бизнес-правила (Устойчивые правила или политики, применяемые в предметной области – правила налогообложения, торговая политика и т.д.)

 

Ценность документов Видение и Дополнительная спецификация состоит в формировании первого приближения требований к системе и определение главных идей проекта.

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

 

Пример Дополнительной спецификации (фрагмент)

1. Введение

· Описание всех требований, не вошедших в описание прецедентов.

2. Функциональность.

· Описание, относящееся к большинству прецедентов.

· Кроме того, описывается, каким образом регистрируются события и обрабатываются ошибки.

· Подключение бизнес-правил

3. Безопасность – аутентификация всех пользователей

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

4. Надежность

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

5. Производительность

· Время взаимодействия с внешними системами

6. Возможности поддержки

· Адаптация системы. Для различных пользователей заранее определяются точки сценария, в которые можно подключать специфические бизнес-правила

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

7. Ограничения

· Команда разработчиков (команда проекта) может рекомендовать определенную среду разработки

8. Приобретаемые компоненты

· Система вычисления налоговых платежей

· Бухгалтерская система

9. Интерфейсы

· Выбор монитора (например, сенсорный)

· Лазерный сканер (для считывания штрих-кода)

· Устройство для печати чека

· Устройство для считывания данных с кредитной или дебетовой карты

10. Бизнес-правила

· Правило №1: Правило вычисления скидок. (Например, работникам компании – 15%, привилегированный покупатель – 10%). Высокая вероятность возможных изменений – каждая торговая организация устанавливает свои скидки. Источником этого правила является политика торговой организации.

· Правило №2: Правило вычисления торговых скидок на уровне транзакций. Применяется к общей стоимости покупки (Например, при сумме покупки более, чем на 500 рублей – скидка 3%). Высокая вероятность изменений. Источник – политика торговой организации.

11. Вопросы законодательства

· Необходимо учитывать все необходимые налоги

· Правила налогообложения могут изменяться довольно часто

12. Информация из предметной области

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

· Обработка платежа по кредитной и дебетовой карточке. Ответственность за обработку платежей по карточкам несет служба авторизации

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

· Идентификаторы товаров. Система должна поддерживать разные типы идентификаторов товаров: универсальный код товаров, европейская система кодирования товаров, японская система кодирования товаров

 

Фрагмент документа Видение

1. Введение

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

2. Позиционирование

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

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

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

3. Заинтересованные лица.

· Указать, для кого предназначена система, и каковы проблемы заинтересованных лиц

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

· Указать основные задачи высокого уровня

4. Перспективы продукта.

· Система может устанавливаться в магазинах, мобильных терминалах (вблизи сети магазинов), будет обслуживать пользователей и взаимодействовать с другими системами

· ПРЕИМУЩЕСТВА СИСТЕМЫ:

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

o автоматически выявлять сбои, переходя в автономный режим, давая возможность продолжения торговли

 

*Примечание* к документу Видение:

• Функции системы можно выразить через ее системные свойства
• Свойства – это то, что может делать система. Пример: Система будет выполнять авторизацию платежей
• Выделение функциональных свойств можно проводить в лингвистической форме: Система будет выполнять…*авторизации платежей, обработку продажи по кредитной карте, обработку продажи по дебетовой карте* (нужное подчекрнутьJ)
• В документ Видение желательно включать не более 10 свойств. Если этих свойств больше, то желательно их сгруппировать

Словарь терминов

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

 

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

 

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