Актуальные проблемы современной науки: тезисы докладов VІI Международной научно-практической конференции (Санкт-Петербург – Астана – Киев – Вена, 28 апреля 2016)
Саликов Валентин Александрович
доцент кафедры автоматизированных систем обработки информации
Днепропетровского национального университета имени Олеся Гончара,
Гриценко Анна Сергеевна
бакалавр, студент кафедры автоматизированных систем обработки информации Днепропетровского национального университета
РАЗРАБОТКА МОДЕЛИ СОСТАВА ДАННЫХ ПО ТРЕБОВАНИЯМ ЗАКАЗЧИКА НА ОСНОВЕ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ
Наличие в организации информационной системы с систематическим обновлением данных позволяет руководящему персоналу держать на контроле все рабочие процессы организации – расходы материальных и энергетических ресурсов, операции сбыта готовой продукции и услуги, транспортные издержки, денежные потоки, выполнение производственных заданий персоналом и т.д. В разработке информационных систем участвуют две команды – заказчики и исполнители. Заказчик (директор организации, его заместители, руководители структурных подразделений) формулируют требования к содержанию и форме представления информации, необходимой для контроля и управления выполняемой деятельностью. В команду исполнителей обычно входят системные аналитики, владеющие методологией бизнес-моделирования, и программисты для создания баз данных и приложений клиентов [1]. В задачу системного аналитика входит выяснение сущности рабочих процессов, протекающих в организации Заказчика, и их документирование. Покажем, как путем функционального моделирования IDEF0 в среде Allfusion Process Modeler (ранее BPwin) можно эффективно, с достаточной полнотой отобразить все основные рабочие процессы организации Заказчика и на основе разработанных диаграмм IDEF0 получить модель состава данных [1-3].
Предположим, что организация условного Заказчика – это агентство недвижимости, выполняющее операции купли, продажи и аренды объектов недвижимости в качестве посредника. Заметим, что в аренде недвижимости есть два участника – владелец недвижимости и лицо, принимающее в аренду объект. Ограничимся рассмотрением только объектов жилищного назначения, а объекты недвижимости промышленного, торгового, спортивного и т.п. назначения принимать во внимание не будем.
При проведении функционального моделирования руководствуются следующими соображениями. Имена входных и выходных стрелок работ должны отображать интересы Заказчика в части регистрации информации о выполняемых работах. Стрелки контроля должны содержать сведения о нормативно-правовой базе сделок. Стрелки механизма работ должны отображать информацию об участниках деятельности и ресурсах, требуемых для осуществления деятельности (программы, оборудование, транспорт и др.). Для именования стрелок будем использовать сцепки сокращений слов, содержащих смысловую подсказку.
Рис.1. Контекстная диаграмма организации Заказчика
Диаграмма, определяющая контекст моделирования, приведена на рис. 1. По инициативе Заказчика учтены услуги автотранспорта и персонал для обслуживания сделок купли/продажи и аренды недвижимости. Деятельность агентства выполняется в соответствии с законами Украины – эту информацию должен предоставить Заказчик. Организация Заказчика обслуживает 4 типа различных заявок (см. рис. 1). После проведения декомпозиции контекстной работы диаграмма IDEF0 принимает вид на рис. 2. Как видим, выполняемые работы детализированы и появилась новая работа – “Оценка недвижимости”, осуществляемая в сделках купли/продажи. По требованию Заказчика необходима проверка прав собственности клиентов в сделках продажи недвижимости и регистрация гражданских документов всех клиентов.
Рис.2. Верхний уровень декомпозиции контекстной диаграммы
Это учтено при выполнении декомпозиции работы “Покупка недвижимости” на рис. 3. Для осуществления сделки клиенту-покупателю предлагается некоторое подмножество вариантов для осмотра и выбора. Выбранный объект регистрируется агентством как “Вариант_покупки” и для него оформляется с
Рис. 3. Диаграмма декомпозиции работы “Покупка недвижимости”
местными органами власти “Разрешение_покупки”. Сделка завершается заключением договора купли с участием нотариуса, а приобретенный в собственность клиента объект регистрируется в информационной системе агентства в списке “Купленные_объекты”. В сделке “Продажа недвижимости” агентство помогает клиентам продавать объекты жилья после проверки прав собственности владельца, осмотра и регистрации состояния объекта продажи (см. рис. 4).
Рис. 4. Диаграмма декомпозиции работы “Продажа недвижимости”
Получение разрешения органов местной власти обязательно. Атрибуты договора и сведения о проданном объекте сохраняются в базе данных агентства.
При оформлении договора продажи должна быть выполнена оценка стоимости объекта по действующим нормативам с участием опытного эксперта. Оценивание стоимости объекта может проводиться и по заявке клиента-покупателя при участии агентства (см. рис. 5). Состояние объекта по итогам его осмотра (в частном доме от фундамента до крыши) регистрируется
Рис. 5. Диаграмма декомпозиции работы “Оценка недвижимости”
в системе. По инициативе агентства или клиента могут быть выполнены ремонтные работы на объекте. Сведения о содержании ремонта и стоимости работ (“Смета_ремонта”), учитываемых в договоре купли/продажи, а также информация о выполненном оценивании недвижимости (“Оцененные объекты”) сохраняются в базе данных.
Для сдачи по заявке клиента объекта в аренду на определенный период агентство проводит проверку документов и осмотр объекта жилья и дает заключение (“Состоян_аренд”) о его пригодности для аренды (см. рис. 6).
Рис. 6. Диаграмма декомпозиции работы “Сдача в аренду недвижимости ”
Если объект принят в аренду, то агентство периодически его инспектирует, отмечая в документе “Журнал_контроля” замечания и претензии. Оплата
Рис. 7. Диаграмма декомпозиции работы “Взятие в аренду недвижимости ”
аренды владельцу объекта, как это предусмотрено договором, регулярно регистрируется в базе.
Клиент, принявший объект в аренду, обязан согласно договору оплачивать стоимость услуги на расчетный счет клиента-владельца (см. рис. 7). Информация об этих платежах (“Плата_за_аренду”) отслеживается агентством в базе данных. Замечания клиента к состоянию объекта недвижимости (“Замеч_гражд”), принятого в аренду, согласованы с агентством и клиентом-владельцем и сохранены как документ.
Результаты функционального моделирования не могут быть совершенными даже после многих итераций. С течением времени “всплывают” ранее не учтенные детали, требующие учета в модели. Поэтому моделирование завершают, когда, по мнению Заказчика, в модели достигнута полнота отображения его бизнес-деятельности. В этом случае можно выполнить операцию экспорта стрелок IDEF0 в среду моделирования данных Allfusion Data Modeler (ранее ERwin ) [1]. При настройке фильтра экспорта необходимо заблокировать те имена стрелок, которые нельзя применить для создания сущностей – объектов базы данных. В нашем случае необходимо блокировать
Рис.8. Модель состава данных для агентства недвижимости
все стрелки контроля, т.к. они соответствуют единичным записям законов и нормативных документов, а в числе стрелок механизма оставить для экспорта лишь стрелки “Персонал” и “Транспорт_услуг”. После проведения экспорта отфильтрованных стрелок на рабочем столе ERwin получим модель состава данных, которую можно принять за основу при создании логической модели данных (см. рис.8). Эту работу продолжают в среде ERwin программисты – создатели баз данных.
Литература
