Файл: Лаб. занятие № 3+.doc

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Шаг 1. Определение рамок системы

Шаги 2 и 3. Определение основных исполнителей и задач

Основные и вспомогательные исполнители

Таблица 1.1 – Перечень исполнителей и их задач

Определение исполнителей и задач путем анализа событий

Таблица 1.2 – Перечень исполнителей и их задач на основе анализа внешних событий

Шаг 4. Определение прецедентов

Описание прецедентов, относящихся к интерфейсу пользователя

Базовый стиль описания

Конкретный стиль описания

Исполнители

Шаг 5. Построить диаграмму прецедентов

Система обозначений для диаграммы прецедентов

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

Даты внесения изменений

Введение

Функциональность (Имеющая отношение ко многим прецедентам)

Регистрация событий и обработка ошибок

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

Безопасность

Удобство использования

Надежность

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

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

Ограничения

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

Бесплатные компоненты на основе открытого кода

Интерфейсы

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

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

Введение

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

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

Обзор

Основные свойства системы

На рис. 1.3 показаны некоторые обозначения для диаграммы прецедентов. Следует обратить внимание на блок с надписью "исполнитель". Так в UML обознача­ется стереотип (stereotype) – механизм выделения категорий элементов. Имя стереотипа заключается в двойные угловые кавычки.


Рисунок 1.3 – Предлагаемые обозначения

Следует заметить, что возможно и иное выделение внешних исполнителей, как показано на рис. 1.4.

Рисунок 1.4 – Альтернативное обозначение исполнителей

Примечание:

В рамках RUP выделяют два вида прецедентов: системные и бизнес-прецеденты.

Системные прецеденты (system use-case) – это такие, которые рас­сматривались выше, например Оформление продажи. Они создаются в рамках дисциплины "Требования" и являются частью модели прецедентов.

Бизнес-прецеденты (business use-case) используются гораздо реже. При не­обходимости они создаются в рамках дисциплины "Бизнес-моделирование" как часть крупномасштабного бизнес-процесса или для облегчения понимания кон­текста новой системы. Они описывают последовательность действий в целом, выполняемых бизнес-исполнителем (business actor) (исполнителем в бизнес-среде, например, потребителем). В частности, для ресторана можно выделить бизнес-прецедент Приготовление блюда.



Вопрос 2. Дополнительная спецификация

Для определения требований одного описания прецедентов недостаточно. Необ­ходимо определить и другие виды требований, в частности, соглашения о лицен­зировании, возможностях поддержки системы и т.д. Все эти требования описы­ваются в дополнительной спецификации (supplementary specification).

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

Даты внесения изменений

Версия

Дата

Описание

Автор

Черновой начальный вариант

13 октября, 2003 г.

Первый черновой вариант. Будет уточнен на стадии развития

АБ


Введение

В этом документе описаны все требования к POS-системе "ТТ", не вошедшие в описание прецедентов.

Функциональность (Имеющая отношение ко многим прецедентам)

Регистрация событий и обработка ошибок

Все ошибки регистрируются на постоянном носителе.

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

Необходимо обеспечить возможность настройки функциональности системы в различных точках сценариев нескольких прецедентов (эти точки нужно определить) на основе заданных правил.

Безопасность

Необходимо выполнять аутентификацию всех пользователей.

Удобство использования

Человеческие факторы

Пользователь POS-системы будет работать с большим монитором, поэтому необходимо следующее:

  • Текст должен быть виден с расстояния 1м.

  • Нужно избегать мерцающих цветов.

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


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

Надежность

Возможность восстановления информации

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

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

Как указывалось выше, покупатель хочет сделать покупку как можно скорее. Задержка этого процесса мо­жет быть связана с внешней службой авторизации. Наша задача – выполнить авторизацию не более чем за 1 минуту в 90% случаев.

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

Адаптация системы

Различные пользователи POS-системы "ТТ" могут устанавливать свои бизнес-правила для обработки данных о продажах. Поэтому в нескольких заранее определенных точках сценария (например, при инициа­лизации новой продажи или при добавлении нового наименования товара) нужно обеспечить возможность подключения бизнес-правил.

Конфигурирование

Сетевые конфигурации различных, пользователей POS-системы могут отличаться. Могут использоваться архитектуры "тонкого" и "толстого" клиентов, двухуровневые и многоуровневые архитектуры и т.д. Кроме того, конфигурация ресурсов каждого клиента может изменяться со временем, отражая производственные потребности и потребности в производительности. Следовательно, система должна быть настраиваемой и отражать потребности пользователей. Этот вопрос требует тщательной дополнительной проработки, изу­чения степени гибкости и способов ее достижения.

Ограничения

Руководство проекта "ТТ" настаивает на применении технологии Java, поскольку это улучшит возможности по поддержке системы и ее переходу на различные платформы, а также обеспечит простоту разработки.

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

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

Бесплатные компоненты на основе открытого кода

В целом, рекомендуется максимальное использование в этом проекте компонентов на основе открытого кода в рамках Java-технологии. Несмотря на то, что пока преждевременно определять проектные решения, предлагаются следующие варианты.

  • Контур регистрации Jlog...

Интерфейсы

Важные интерфейсы и аппаратные средства

  • Сенсорный монитор (воспринимаемый операционной системой как обычный монитор; прикоснове­ния обрабатываются как события мыши).

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

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

  • Устройство считывания данных с кредитной/дебитной карточки.

  • Устройство считывания подписи (не в первой версии системы).


Программные интерфейсы

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

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

Имя

Правило

Возможность изменения

Источник

ПРАВ 1

Для платежей по кредитной кар­точке требуется подпись

Подпись покупателя будет нужна, но через 2 года большинство пользователей захотят применять цифровое устройство для ввода подписи, а через пять лет может понадобиться поддержка уникаль­ной цифровой закодированной подписи, введенной в настоящее время в США

Политика практически всех служб авториза­ции платежей

ПРАВ 2

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


Высокая вероятность изменения. Законы налогообложения изменяются ежегодно на прави­тельственном уровне


Закон


ПРАВ З


При возврате товара, купленного по кредитной карточке, возврат денег осуществляется не налич­ными, а путем перевода на кре­дитную карточку


Низкая вероятность изменения -


Политика компаний авторизации платежей


ПРАВ 4


Правила вычисления скидок (примеры). Работник компании – скидка 20%. Привилегированный покупатель – 10 %

Высокая вероятность измене­ния. Каждая торговая организа­ция устанавливает свои скидки


Политика торговых организаций


ПРАВ 5


Правила вычисления торговых скидок (на уровне транзак­ций). Применяются к общей стоимости покупки, (без вычета налога). Примеры: 10% общей стоимости покупки, если стоимость превышает 100%. 5% по понедельникам. 10% для всех продаж с 10 до 15 часов ежедневно. 50% для всех продаж с 9 до 10 часов сегодня


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


Политика торговых организаций


ПРАВ 6


Правила вычисления торговых скидок на товары (на уровне на­именований товаров). Примеры: 10% на все тракторы на этой неделе. При покупке двух единиц това­ра – третья бесплатно


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


Политика торговых организаций



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

Рекомендуется использование бесплатных компонентов на основе открытого кода, если их разрешено ис­пользовать в коммерческих программных продуктах.

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

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


Ценовая политика

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

Обработка платежей по кредитной и дебитной карточке

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

Вычисление налогов

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

Идентификаторы товаров (UPC, EAN, SKU, штрих-коды и сканеры)

Система ТТ должна поддерживать различные типы идентификаторов товаров. Наиболее популярными системами идентификации товаров являются UPC (Universal Product Codes), EAN (European Article Numbering) и SKU (Stock Keeping Units). Японская система JAN (Japanese Article Number) является вариантом европейской версии EAN,

В системе SKU идентификаторы товаров назначаются произвольным образом торговыми организациями. Системы UPC и EAN имеют свои стандарты и регулируемые компоненты. Хорошее описание этих систем можно найти по адресам www.adamsl.com/pub/rus-sadam/upccode.html, www.uc-council.org и www.ean-int.org.



Вопрос 3. Видение

Документ "Видение" определяет видение проекта. В нем кратко описывают­ся основные цели проекта, проблемы, указывается круг заинтересованных лиц, их потребности, а также основные идеи предложенного решения.

Приведем цитату: "Документ "Видение" определяет точку зрения заинтересованных лиц на разрабатываемый продукт в терминах их основных потребностей и свойств продукта. Этот документ содержит описание неочевидных ос­новных требовании и составляет основу для более детального описания технических требований".


Видение

Даты внесения изменений

Версия

Дата

Описание

Авторы

Черновой начальный вариант


13 октября, 2003


Первый черновой вариант. Будет уточнен на стадии развития


АБ



Введение

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


Анализ в этом примере носит иллюстративный характер

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

Экономические предпосылки

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

Формулировка проблемы

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

Место системы

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

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

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

Демографические особенности рынка...

Заинтересованные лица, не являющиеся пользователями системы...

Пользователи системы...

Основные задачи высокого уровня и проблемы заинтересованных лиц

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


Цель высокого уровня

Приоритет

Проблемы и замечания

Текущие решения

Быстрая, робастная и интегриро­ванная обработка информации о продажах


Высокий


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


Существующие POS-продукты обеспе­чивают базовую обра­ботку информации о продажах, но не ре­шают все возникаю­щие проблемы