ВУЗ: Пермская государственная сельскохозяйственная академия имени академика Д. Н. Прянишникова
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 18.10.2018
Просмотров: 2167
Скачиваний: 14
СОДЕРЖАНИЕ
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Шаг 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-продукты обеспечивают базовую обработку информации о продажах, но не решают все возникающие проблемы |
… |
… |
… |
… |