Типичные орфографические ошибки
1C + UML
Использование Rational Unified Process (RUP) с системой 1С:Предприятие 8.x
1. Введение 1
2. Данные о конторе 2
2.1 Данные полученные из опроса сотрудников: 2
3. Моделирование текущей деятельности 3
3.1 Модель бизнес-прецедентов 3
3.2 Модель бизнес-объектов. 7
4. Определение функциональных требований. 10
4.1 Модель системных прецедентов для бизнес-прецедента 10
4.2 Описание системного прецедента 11
4.3 Диаграммы последовательностей для системного прецедента. 12
5. Дополнительные требования 18
6. Приложение 1. Диаграммы 18
7. Приложение 2. Постановка ТЗ 18
8. Опомнились 18
1. Введение
В этой статье я попытаюсь автоматизировать государственное учреждение. Морг.
Почему морг? Потому что все уже запарились автоматизировать салоны видеопроката и аптеки. Работать в сей чудной организации, мне не приходилось, поэтому «данные полученные из изучения предметной области» и все остальные факты о работе организации это исключительно полёт фантазии. А посему прошу, сильно критично к этому не относиться. Ещё я очень многое упростил, чтобы не раздувать текст и диаграммы.
Чтобы тема морга не омрачала проектирование, резидентов холодильных ячеек заведения будем называть клиенты.
В ходе проектирования мы:
- соберем данные о процессах происходящих на объекте
- построим бизнес-модель происходящего на объекте
- сформируем требования к программной системе
- поставим ТЗ программистам
Таким шрифтом будет написана пометка о том, что часть статьи пока не готова и появится в будущем.
Свои мысли и информацию не первой важности я отметил таким шрифтом. Кому много буков можно не читать.
Если в ходе чтения возникнут вопросы, или что ещё лучше конструктивные возражения и предложения, всегда буду рад ответить на форуме.
Если статья окажется востребованной, я стану заниматься ей дальше. А нет - так нет.
Mort.
2. Данные о конторе
2.1 Данные полученные из изучения предметной области:
1. Приём:
Медслужба освидетельствовав факт смерти, направляет запрос в регистратуру морга на наличие свободных мест для хранения. При положительном результате производится перевозка и прием клиента(ов) в морг.
По приезду на каждого клиента составляется акт приема, где указывается его параметры, Ф.И.О если известны, общее описание и присваивается личный номер. По возможности указывается время захоронения клиента, либо указывается позже по телефону родственниками. Хранится клиент не больше 20 дней за исключительным случаем. И клиент сдается на хранение.
2. Хранение. Процедуры во время хранения:
Помещение морга состоит из 20 камер по 10 морозильных ячеек в каждой, каждая имеет свой номер.
2.1 Экспертиза
Временно клиентов может вывозить сотрудники МВД для проведения экспертизы (просто в самом морге недостаточно оборудования). Время возврата клиентов указывается сразу и никаких задержек и проблем в возврате не возникает. Во время отсутствия клиентов места остаются зарезервированными. Результаты экспертизы на записи регистратуры не влияют.
2.2 Опознание.
В морге может происходить опознание. Факт и результаты процедуры опознания заносятся в журнал.
3. Освобождение ячеек.
3.1 Похороны.
Каждый день клиентов забирает то или иное похоронное бюро. Время точного забора должно быть указано за день. Сотрудники МВД могут отложить срок реализации или захоронения клиента до какой-либо даты.
3.2 Реализация: Институт или кремация.
Если в течении 20 дней не было заявки на похороны или кремацию клиент подвергается утилизации. Его либо кремируют, либо отдают в институт на съедение медикам.
Институт периодически подаёт заявки на клиентов, типа на определенную дату им нужны клиенты определенного пола и разряда возраста, всего 6 разрядов: (1-4)(5-15)(16-30)(31-50)(51-70)(>70).
Каждый день в 3 часа регистратура составляет список «освободившихся» клиентов, просматривает список заявок из института, договаривается с институтом и вечером институт забирает клиента. Только после составления списка в институт, те счастливчики, что не попали в институт, сжигаются (список сжигаемых клиентов регистратура передает персоналу). Ещё кремация вместо похорон может быть произведена по желанию родственников в любой день (такой клиент в институт попасть не должен). Заявка от родственников должна прийти за день.
Необходимо автоматизировать всю бумажную работу регистратуры и иметь возможность по запросу указать положение дел в морге (состояние ячеек и клиентов) на любую дату.
Дальнейшие подробности уточнятся по ходу проектирования.
Только не надо кричать «лажа», и что структуру можно в конфигураторе накидать за 10 минут. Можно. Но не всегда.
3. Моделирование текущей деятельности
3.1 Модель бизнес-прецедентов.
Модель бизнес-прецедентов описывает, что творится в организации и кто с этими процессами взаимодействует извне.
Текущая деятельность нашего заведения, это обслуживание клиентов и обслуживание ячеек. Нарисуем эти процессы и всех, кто связан с ними:
Рис 1.1 Обобщенная модель бизнес-прецедентов
Мы получили Модель бизнес-прецедентов. Такие модели отображаются на Диаграмме вариантов использования (use case diagram).
На диаграмме указаны внешние исполнители или Бизнес-исполнители (Actor, на диаграмме человек) и Бизнес-прецеденты (Use Case, на диаграмме овал). Бизнес-прецедент это некий процесс, происходящий на предприятии. Указанные прецеденты слишком общие и требуют детализации. Рассмотрим бизнес-прецедент «обслуживание клиента». Мы разобьем его на несколько менее обобщенных процессов. Для этого выделим основные процессы предприятия, каким – либо образом связанные с обслуживанием клиента.
Рис 1.2 Модель бизнес-прецедентов «обслуживание клиента» на диаграмме вариантов использования.
«Реализация клиента» это объединение передачи в институт и передачи на кремацию. Я их решил объединить т.к. они являются одним неразрывным бизнес-процессом.
Для четкого выявления прецедентов нужно чтобы каждый из них соответствовал правилам описанными отцами RUP под аббревиатурой WAVE :
W(What) Прецедент должен описывать что нужно делать, а не как.
A (Actor) Прецедент должен быть описан с точки зрения исполнителя.
V (Value) Прецедент должен выдать исполнителю некий результат.
E (Entire) Последовательность событий должна представлять собой один неделимый бизнес-процесс.
Я пока писал первую часть статьи, перерисовал её раз десять. И ещё буду. Не надо стараться составить сразу идеальную модель и ступориться на начальном этапе. Следующие этапы проектирования выявят ошибки в модели, и её можно будет исправить.
Теперь опишем как выполняется каждый бизнес-прецедент. Методом опроса исполнителей и т.д.
Описание прецедента «Реализация» глазами исполнителя:
Регистратура смотрит записи о клиентах, которые были помещены в ячейки более 20-ти дней назад и не отложены заявкой МВД. Сравнивает их с заявками из института и составляет список кандидатов, который по мылу отправляет в институт. Те смотрят список, и если необходимость в некоторых кандидатах отпала, то их вычеркивают. Утвержденный список из института отсылается обратно в регистратуру морга. Регистратура составляет список всех, кого можно было сегодня сжечь, вычеркивает убывающих в институт и добавляет тех, кого сожгут по желанию родственников. И передает полученный список в крематорий. О том, что клиент был кремирован или отправлен в институт, ставится соответствующая пометка в записях о клиентах.
По этим данным мы строим диаграмму деятельности (activity diagram) бизнес-прецедента:
Ещё её называют диаграмма видов деятельности
Рис 1.3 Диаграмма деятельности бизнес-прецедента «Реализация клиента»
Немного похоже на схему бизнес-процеса, только «плавательные дорожки» указывают, кто производит действие. Прямоугольники с округлыми краями это Действия (Action) Точка – начало, точка в окружности – финал, горизонтальная черта разделяет процесс, что означает различные варианты прохождения процесса.
Как видно участие крематория в жизни записей довольно сомнительное – он просто получает список.
Уже на начальных этапах начинает вырисовываться те или иные Бизнес-сущности будущей системы. Бизнес-сущности это всё что используется внутренним исполнителем при выполнении прецедента. Для нашей регистратуры это различные записи. Например, сущности: «список кремации», «список переданных в институт», «записи о клиентах».
При построении системы одни сущности перейдут в прикладные объекты, хранящиеся в базе (справочники, документы и т.д.), а другие превратятся в результаты работы отчетов и т.д.
Также приведем диаграмму видов деятельности для прецедента «аренда клиента». По идее прецедент нужно было разделить на выдачу и возврат, но в условии оговорено, что возврат выполняется без задержек и проблем. Это условное упрощение для того, чтобы статья не превратилась в книгу.
Рис 1.4 Диаграмма видов деятельности бизнес-прецедента «Аренда клиента»
Описание: сотрудники МВД подваливают в морг и требуют выдачи такого-то клиента, причем сразу указывают, когда его вернут. Регистратура вносит пометку в записях о клиентах, что с того-то по такое-то был на экспертизе. Клиента увозят и привозят назад в указанную дату.
Диаграммы деятельности остальных прецедентов можно заценить в приложении 1.
Переходим к построению модели бизнес объектов.
3.2 Модель бизнес-объектов.
Модель бизнес-объектов описывает связь исполнителей с бизнес-сущностями присутствующими в организации. Нужна она для того, чтобы выделить какие сущности есть, и кто с ними имеет дело. Диаграмма называется кооперативной (collaboration diagram).
Модель бизнес-объектов для прецедента «Реализация клиента»:
Рис 2.1 Модель бизнес-объектов бизнес-прецедента «Реализация клиента»
На ней ясно видно, что при выполнении бизнес-прецедента «реализация клиента» регистратура использует записи о клиентах, заявки института, заявки на кремацию, списки клиентов в институт и списки клиентов к кремации.
Для более детального моделирования работы прецедента и взаимодействия исполнителей с сущностями строится диаграмма последовательности (sequence diagram) бизнес-прецедента:
Рис 2.2 Диаграмма последовательности бизнес-прецедента «Реализация клиента»
Диаграмма последовательности это более продвинутая версия диаграммы деятельности (Рис 1.3).
Вверху рисуются бизнес-исполнители и бизнес-сущности системы. От каждого вниз идет линия. Между линиями стрелками рисуется взаимодействия между ними. Читается в порядке сверху вниз.
Безусловно, процедуры формирования списков будут автоматизированы, но пока мы описываем модель «AS-IS».
Модель бизнес-объектов для прецедента Поступление клиента на хранение:
Рис 2.3 Модель бизнес-объектов бизнес-прецедента «Поступление клиента на хранение»
Рис 2.4 Диаграмма последовательности бизнес-прецедента «Поступление клиента на хранение»
И т.д по всем бизнес-прецедентам…
Из этих данных можно отдельно выделить список сущностей используемых в морге:
Рис 2.5 Бизнес сущности используемые в проекте.
Естественно это ещё не модель нашей БД. Вообще в нашем скромном примере эти данные можно свободно получить рассмотрев список документации в регистратуре, и с этого надо начинать, но так легко выходит не всегда.
После составления всей бизнес модели, у нас есть полная информация о том, что происходит с записями регистратуры в настоящий момент. Теперь пора узнать, что вообще от нас ожидают.
4. Определение функциональных требований.
Автоматизация никогда не меняет состав и цели бизнес процессов происходящих на объекте.
Конечно, в ходе моделирования могут быть выявлены неэффективные моменты в деятельности организации (называется просто: «хаос в конторе», например, непонятно что и зачем делает один перец, если то же самое делает чел за стенкой) и предложены пути их устранения, но это не автоматизация, а наведение порядка.
А это значит, что функциональные требования просто отражают нашу построенную бизнес модель. Мы просто тщательно рассмотрим каждый бизнес-прецедент с учетом использования будущей программной системы, и шаг за шагом будем превращать бизнес-модели в системные модели.
В процессе определения требований мы получим структуру конфигурации будущей ПС.
4.1 Модель системных прецедентов для бизнес-прецедента
Составляется для каждого бизнес-прецедента. Она описывает бизнес-прецедент как определенные действия пользователя с программой и очень похожа на модель бизнес-прецедентов. Для перехода от бизнес-моделей к системным используется таблица определенная правилами RUP:
Модель бизнес-прецедентов Модель системных прецедентов
Прецеденты Подсистемы
Внешние исполнители Исполнители
Внутренние исполнители Исполнители или прецеденты
Процессы, выполняемые внутренними исполнителями Прецеденты
Рис 3.1 Таблица конвертации из модели бизнес-прецедентов в модель системных прецедентов
«Подсистемы» в данном контексте и «подсистемы» в конфигурации 1С одинаковы не только в написании.
Создаем в конфигураторе подсистему «обслуживание клиента» и 8 подчиненных подсистем согласно каждому бизнес-прецеденту. В крупных системах бизнес прецеденты (Рис 1.2) могут несколько раз разбиваться мелкие прецеденты. В таком случае иерархия подсистем имеет больше уровней.
Построим модель системных прецедентов для бизнес-прецедента «Реализация клиента»:
Рис 3.2 Модель системных прецедентов
Модель получилась совсем простой. Но мы не ищем сложных путей.
Бизнес прецедент «Реализация клиента» я разбил на три системных прецедента по разным действиям, производимым пользователем с программой. Ниже о них рассказано подробней.
4.2 Описание системного прецедента
Когда пользователь долго мне потрошит мозг о том, как корабли бороздят космическое пространство, пытаясь объяснить мне, что хочет, я в большинстве случаев ничего не понимаю. А потом просто спрашиваю, что ты хочешь видеть на экране, как ты будешь данные вводить и в каком виде получать. Порядок действий. То, что я пишу на салфетке по его словам, есть основная последовательность действий бизнес-прецедента. А потом спрашиваю, а если там не так пошло? Ну, тогда…
Тогда получается альтернативная последовательность действий.
Вообще пользователь последний человек, который знает, как он хочет взаимодействовать с системой. Последовательности придумывает проектировщик. Но когда заставляешь пользователя пофантазировать на эту тему, он выдает много полезной информации. Плюс зачастую он сам начинает лучше соображать, чего хотелось бы от нововведения и чего стоит ожидать.
А если заморачиваться серьезно, то описание содержит:
- заголовок (название прецедента, ответственный за исполнение, дата создания шаблона/внесения изменений);
- краткое описание прецедента;
- предусловия (необходимое состояние системы или условия, при которых должен выполняться прецедент);
- постусловия (возможные состояния системы после выполнения прецедента);
- предположения;
- основная последовательность действий;
- альтернативные последовательности действий и условия, их инициирующие;
- точки расширения и включения прецедентов
Для ёмких прецедентов возможно и стоит отписать несколько листов, но я обычно ограничиваюсь (моё субъективное мнение) парой строчек на пункт плюс всякие особенности которые удалось выудить из юзера. Нужно записывать и конспектировать всё важное, что говорит юзер. Вы вот забудете о том, что он говорил, а он нет, и второй раз не скажет.
Опишем системные прецеденты «Сформировать XLS список в институт» и «внести данные по институту»:
Словом «ЮзерР» (это то что раньше было исполнителем «Регистратура») будем называть работника регистратуры - будущего пользователя системы. Поскольку он один, то и роль в конфигурации будет... две. Без администратора никуда :).
Прецедент: Сформировать XLS список в институт
Описание:
Процесс формирования файла формата EXCEL со списком клиентов, отправляемых в институт. Файл направляется в институт для корректировки.
Основная последовательность действий:
1. ЮзерР открывает форму обработки
2. ЮзерР указывает, куда сохранить будущий файл и нажимает кнопку создать файл.
3. ЮзерР оповещается о результате.
Прецедент: Внести данные по институту.
Описание:
Процесс ввода утвержденной информации о клиентах поступающих в институт. В результате пользователь получает готовый список кремации.
Основная последовательность действий:
Условие: ЮзерР получил отредактированный файл. Исключение1: Не получил.
1. ЮзерР выбирает в обработке путь к файлу.
2. ЮзерР нажимает «анализ».
3. ЮзерР получает на экран список к кремации, который может распечатать.
Альтернативные последовательности действий:
Исключение1 : ЮзерР не получил в ответ отредактированный файл.
Примечание: В этом случае считается, что институт на сегодня в клиентах не нуждается.
1. ЮзерР указывает обработке на отсутствие файла (возможно пункт меню обработки).
2. ЮзерР получает на экран список к кремации, который может распечатать.
4.3 Диаграммы последовательностей для системного прецедента.
В ходе детального определения требований и рассмотрения системных прецедентов, мы получим перечень объектов конфигурации.
Когда я выделял объекты по требованиям, мне в голову пришла мысль использовать такое явное видение использования прикладных объектов, для того чтобы заранее распределить их по подсистемам.
Создаем таблицу объектов-подсистем:
Объект/Прецедент Вывоз на захоронение Реализация клиента … и т.д.
Справочники
Спр1 Х
Спр2 Х Х
Документы
…
Обработки
Рис 3.3 Таблица соответствия объектов конфигурации бизнес-прецедентам (подсистемам конфигурации)
А потом оказалось это ещё и хорошая возможность распределить объекты по правам доступа на роли.
Создаем таблицу объектов-ролей, она также здорово поможет при построении меню:
Объект/Роль РаботникРегистратуры (ЮзерР)
Чтение Добавление Изменение … и т.д.
Справочники
Спр1 Х
Спр2 Х Х
Документы
…
Обработки
Рис 3.4 Таблица соответствия объектов конфигурации исполнителям (ролям конфигурации)
Диаграммы последовательностей(sequence diagram) такие же, как диаграммы последовательности для бизнес-прецедента, только описывают системный прецедент. В них описывается последовательность взаимодействия между пользователем и объектами системы и просто внутри между объектами системы.
Начинаем рисовать диаграмму последовательностей для системного прецедента «сформировать XLS список в институт»
Рис 3.5 Начало диаграммы последовательности для системного прецедента «сформировать XLS список в институт»
Новый объект:
Обработка.УправлениеРеализацией
Поздравляю, получили первый объект – Обработка Управление Реализацией. Обработки на схемах указываем кружком со стрелкой (“control”).
Ясно что общаться юзер будет не прямо с обработкой, а с формой обработки, но обрезаем присутствие форм (“boundary”) ради экономии времени и места.
Теперь начинаем думать куда полезет обработка за списком клиентов «претендентов в институт». В записи о клиентах и о заявках конечно, как нарисовано на рис 2.1. Просто нужно решить, как отобразить бизнес-сущности «Записи о клиентах» и «Заявки института» в реальной базе. Для клиентов я выбрал справочник.
Новый объект:
Справочник.Клиенты
Но это не всё.
Запись о клиенте вслед за самим клиентом, находится в разных состояниях. В помощь составляем диаграмму состояний клиента (statechart diagrams):
Рис 3.6 Состояния клиента
Новый объект:
Перечисление.СостоянияКлиента
Заблокирован – значит МВД запретило куда-нибудь распределять клиента.
То, что состояния превращаются в перечисление, думаю понятно. Не нужна история изменений состояний – пихаем реквизит в справочник, нужна – в периодический регистр сведений. Нам нужна.
Новый объект:
РегистрСведений.ИсторияСостоянийКлиента
Заявки из института сделаем регистром сведений с измерениями Дата, Пол, ГруппаВозраста[, другие характеристики] и ресурсом количество.
Новый объект:
РегистрСведений.ЗаявкиИнститута
Определяя объекты сразу определяем реквизиты необходимые для прецедента.
Новые объекты:
Перечисления.ГруппыВозраста
Перечисления.МужЖен
Для этого можно строить диаграммы вроде таких:
Рис 3.7 Примеры таблиц объектов
А можно обойтись деревом конфигурации.
Получили конечную диаграмму.
Отражения бизнес-сущностей (Регистры сведений, справочники, отчеты) рисуем кружком с подчеркиванием (entity):
Рис 3.8 Диаграмма последовательности для системного прецедента «сформировать XLS список в институт»
ИсторияСостоянийКлиентов подразумевает, что записи будут отражать различные действия. Эти различные действия будут описаны документами, которые будут регистраторами «ИсторииСостояний». Насчет того как будут заводится записи регистра «ЗаявкиИнститута» будет известно при рассмотрении прецедента «подача заявки на клиента»
Получили не только сами объекты, но и экспортную функцию обработки. «УправлениеРеализацией» содержит функцию СформироватьXLSвИнститут(Дата).
Запрос() – это условное обозначение запроса к таблице.
Можно было, конечно, указать объект 1с:Предприятия 8.0 «Запрос» и его метод выполнить(), а потом уже и регистр, но это лишняя трата времени.
После составления каждой диаграммы не забываем все новые объекты прописывать в таблице объектов-подсистем (Пометка в столбце «реализация клиента») и объектов-ролей (Обработка.УправлениеРеализацией – использование, РС.ИсторияСостоянияКлиентов – чтение, РС.ЗаявкиИнститута - чтение). Зачем это надо, если у нас только одна роль? Кто там влезет и что-то подсмотрит? Надо не забывать, что грамотная организация доступа дает хорошую защиту на тот случай если пользователь – мартышка с гранатой.
Составляем диаграмму последовательности системного прецедента «внести данные по институту»
Рис 3.9 Диаграмма последовательности для системного прецедента «Внести данные»
Новые объекты:
Документ.СписокВИнститут
Документ.СписокКремации
РегистрСведений.ЗаявкиНаКремацию
Оба документа регистраторы регистра ИсторияСостоянийКлиента.
Здесь в фигурных скобках указаны условия, при которых объект/исполнитель выполняет действие.
Также присутствует новый регистр сведений отражающий сущность «ЗаявкиНаКремацию» из рис 2.1 . Измерение – клиент, ресурс – Дата сжигания.
На диаграмме пользователь инициирует процесс вносящий изменения в регистр ИсторияСостоянийКлиентов, но сам их не вносит. Ставим у него в таблице объектов-ролей право на изменение истина, а на редактирование пропускаем.
Закончим разработку структуры подсистемы «РеализацияКлиента» составив диаграмму последовательности системного прецедента «Распечатать список кремации»
Рис 3.10 Диаграмма последовательности для системного прецедента «Распечатать список кремации»
На рисунке 2.4 указаны бизнес-сущности организации как «СпискиККремации» и «СпискиВИнститут». Они обе здорово уместились в регистре сведений СостоянияКлиентов, ведь список клиентов, которых надо кремировать на заданную дату, это список клиентов изменивших этой датой свой статус на «кремирован».
Итого в отборе по подсистеме «РеализацияКлиента» есть:
Рис 3.11 Конфигурация подсистемы «реализация пользователя»
Теперь берем ещё один бизнес-прецедент и действуем с ним подобным образом. Находим недостаток в первичной модели бизнес-прецедентов и исправляем.
5. Дополнительные требования
Будут приведены нефункциональные требования.
6. Приложение 1. Диаграммы
Здесь будет представлены все диаграммы проекта.
7. Приложение 2. Постановка ТЗ
Здесь будет техническое задание на групповую разработку проекта.
8. Опомнились
На самом интересном месте выясняем, что ячейки иногда ломаются, институтов два (да и список хочется автоматом высылать-получать), а холодильное помещение открывает филиал в Бобруйске. Легким движением руки..
|