Проектирование информационной системы учета операций с недвижимостью

Министерство образования Республики Беларусь УО "Белорусский государственный экономический университет"

Бобруйский филиал

Кафедра информатики, статистики и высшей математики

Курсовая работа

Проектирование информационной системы учета операций с недвижимостью

Студентка

5 курса, ЭИ-091 Е.М. Прохоренко

Руководитель

Ст. преподаватель В.Л. Кулешова

Бобруйск 2013

Реферат

Курсовая работа: 23 с., 16 рис., 8 ист., 3 прил.

Информационная система, риэлтор, риэлтерская компания, недвижимость, аренда, продажа, таблица, SQL-запорос, форма, код, БД.

Объект исследования - процесс учета операций с недвижимости.

Предмет исследования - информационная система учета операций с недвижимостью.

Цель работы - проектирование информационной системы учета операций с недвижимостью с помощью программных средств Rational Rose, Microsoft Visio, Borland C++ Builder.

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

Методы исследования - функциональное моделирование, информационное моделирование.

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

недвижимость учет информационный программирование

Содержание

Введение

. Теоретические основы проектирования информационной системы учета операций с недвижимостью

.1 Теоретические основы учета операций с недвижимостью

.2 Концепция информационной системы учета операций с недвижимостью

. Разработка концептуальной модели информационной системы

.1 Диаграмма вариантов использования

.2 Диаграмма классов

.3 Диаграмма действий

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

.5 Диаграмма компонентов

. Разработка логической и физической моделей базы данных информационной системы

.1 Разработка логической модели ИС

.2 Разработка физической модели ИС

.3 Формирование таблицы описания документов и разработка форм входных и выходных документов в среде программирования C++ Builder

Заключение

Список использованных источников

Приложение А. Диаграмма действий

Приложение Б. Сгенерированный программный код на языке ANSI C++

Приложение В. Код главной формы

Введение

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

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

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

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

Объект исследования - процесс учета операций с недвижимости.

Предмет исследования - информационная система учета операций с недвижимостью.

Цель работы - создание - информационной системы учета операций с недвижимостью с помощью программных средств Rational Rose, Microsoft Visio, Borland C++ Builder.

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

Методы исследования - функциональное моделирование, информационное моделирование.

1. Теоретические основы проектирования информационной системы учета операций с недвижимостью

.1 Теоретические основы учета операций с недвижимостью

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

Риэлторские услуги - это услуги, которые оказываются при осуществлении риэлторской деятельности.

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

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

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

Вторая группа включает в себя услуги риэлтора по участию имущества "недвижимого и жилого" в гражданском обороте.

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

Существуют несколько основных видов деятельности риэлтора. Например, деятельность риэлтора в качестве:

-       агента или поверенного;

-       брокера;

-       дилера;

-       посредника при заключении сделок с недвижимым имуществом или правами на него между третьими лицами;

-       по организации торговли недвижимым имуществом;

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

-       по доверительному управлению недвижимым имуществом;

-       по предоставлению консультационных услуг, услуг по изучению конъюнктуры рынка, иных возмездных услуг, сопутствующих гражданскому обороту недвижимого имущества [1].

Рассмотрим такие виды риэлторских услуг, как покупка, продажа и аренда помещения.

Основной формой выражения таких взаимоотношений является договор.

Данные операции с недвижимостью подразделяются условно на 5 этапов:

1)    Получение заявки на предоставление риэлторской услуги.

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

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

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

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

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

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

Если риэлтор представляет интересы покупателя, его функции заключаются в следующем:

-      проведение маркетингового анализа рынка недвижимости;

-       организация просмотра выбранных вариантов;

-       сбор документов об объекте недвижимости;

-       организация переговоров;

-       предоставление отчета заказчику о проделанной работе и информирование о степени готовности всех субъектов к оформлению сделки.

Если риэлтор представляет интересы продавца, то его функции состоят в организации:

-      рекламы объекта;

-       показов объектов потенциальным покупателям;

-       переговоров между покупателями и продавцом.

4)    Юридическое сопровождение сделки, определение ее условий и порядка взаиморасчетов.

5)      Оформление сделки с недвижимостью и оплата услуг риэлтору.

Данный этап можно представить в следующем порядке:

. подписание договора и подача документов на государственную регистрацию сделки с недвижимостью;

2.      передача денег после получения свидетельства о регистрации;

.        приемка-передача объекта;

.        оплата услуг риэлтора за выполненную работу [2].

.2 Концепция информационной системы учета операций с недвижимостью

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

-       отсутствует электронный документооборот;

-       нет электронной формы договора аренды/покупки/продажи помещения, что приводит к риску потери информации о клиенте, так как данные клиента в базу не заносятся;

-       помещения на продажу/аренду/покупку хранятся в базе не отсортированные, что затрудняет поиск нужного помещения.

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

-       продаже помещения;

-       покупке помещения;

-       аренде помещения.

2. Разработка концептуальной модели информационной системы

.1 Диаграмма вариантов использования

Диаграмма вариантов использования описывает функциональное назначение системы или то, что система должна делать. Диаграмма вариантов использования проектируемой ИС представлена на рисунке 1.

Рисунок 1 - диаграмма вариантов использования

Примечание - Источник: собственная разработка.

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

-       "Клиент" и "Риэлтор" - бизнес-актёры (business actor) позволяют представить исполнителей бизнес-функций, связанного с работой системы.

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

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

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

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

Были использованы следующие виды связи:

-       ассоциации - направление стрелки позволяет понять, кто инициирует коммуникацию. Ассоциация направлена от актёров Клиент и Риелтор к вариантам использования покупка помещения, аренда помещения, продажа помещения.

-       отношение зависимости со стереотипом <<include>>. Применяется когда один из прецедентов использует другой. Направлено от вариантов использования покупка помещения и аренда помещения к варианту использования поиск помещения по базе данных и от варианта использования продажа помещения к прецеденту поиск клиента.

.2 Диаграмма классов

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

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

-       клиент;

-       договор;

-       риэлтор;

-       список условий;

-       условия;

-       помещение.

Рисунок 2 - диаграмма классов

Примечание - Источник: собственная разработка.

Отношения между классами выглядят следующим образом:

-       классы Клиент и Договор - отношение ассоциации. Один клиент может заключить один или несколько договоров, каждый договор оформляется только для одного клиента, поэтому кратность связи со стороны класса Клиент - 1, со стороны Договор - 1..n (1..много);

-       классы Договор и Риелтор - отношение ассоциации. Один риэлтор может оформить один или несколько договоров, каждый договор оформляется только одним риэлтором, поэтому кратность связи со стороны класса Риэлтор - 1, со стороны Договор - 1..n (1..много);

-       классы Услуга и Условия - отношение ассоциации. Но основе одной услуги формируется несколько условий, поэтому кратность связи со стороны класса Условие - n (много), со стороны Услуга - 1.

-       классы Договор и Условия - отношение ассоциации. Один договор формирует несколько условий, 1 условие относится к одному договору, связи со стороны класса Договор - 1, со стороны Условия - n (много);

-       классы Условия и Помещение - отношение ассоциации. Одному условию может соответствовать несколько помещений, связи со стороны класса Договор - 1, со стороны Условия - n (много).

.3 Диаграмма действий

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

Рассмотрим процесс риэлторской деятельности (Приложение А):

-       клиент обращается в риэлторскую компанию и подаёт заявку;

-       риэлтор регистрирует заявку в БД клиент.

-       риэлтор в базе данных ищет подходящее помещение, которое удовлетворяет условиям и требованиям клиента;

-       риэлтор показывает помещение клиенту;

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

-       риэлтор заключает необходимые договора с клиентом;

-       на заключительном этапе клиент подписывает договор и в дальнейшем ему передаётся выбранное помещение.

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

Диаграмма последовательности - диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления (рис. 4).

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

-  клиент;

-       риэлтор;

-       условия;

-       список условий;

-       помещение;

-       договор.

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

Рисунок 3 - диаграмма последовательности

Примечание - Источник: собственная разработка.

.5 Диаграмма компонентов

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

Рисунок 4 - диаграмма компонентов

Примечание - Источник: собственная разработка.

Для диаграммы компонентов были реализованы следующие классы:

-       для компоненты Учёт клиентов - класс Клиент;

-       для компоненты Учёт помещений - класс Помещение;

-       для компоненты Учёт договоров - класс Договор;

-       для компоненты Учёт персонала - класс Риэлтор.

Так же была сделана кодогенерация на основе исполняемого компонента "MAIN.exe" с расширением ".EXE" на диаграмме компонентов . Кодогенерация представлениа в приложениях Б.

3. Разработка логической и физической моделей базы данных информационной системы

3.1 Разработка логической модели ИС

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

На основе ситуации описания проекта проектируем модель базы данных и составляем для нее схему логической модели типа Database Model Diagram в Microsoft Visio. Исходными данными для построения логической модели информационной системы являются знания, содержащиеся в разделе Диаграмма классов. Она будет включать такие же самые сущности (рис. 2). Логическая модель изображена на рисунке 6.

Рисунок 5 - логическая модель информационной системы

Примечание - Источник: собственная разработка.

-       классы Клиент и Договор - отношение композиции. Один клиент может заключить один или несколько договоров, каждый договор оформляется только для одного клиента, поэтому кратность связи со стороны класса Клиент - 1, со стороны Договор - 1..n (1..много);

-       классы Договор и Риелтор - отношение композиции. Один риэлтор может оформить один или несколько договоров, каждый договор оформляется только одним риэлтором, поэтому кратность связи со стороны класса Риэлтор - 1, со стороны Договор - 1..n (1..много);

-       классы Услуга и Условия - отношение композиции. Но основе одной услуги формируется несколько условий, поэтому кратность связи со стороны класса Условие - n (много), со стороны Услуга - 1;

-       классы Договор и Условия - отношение композиции. Один договор формируется на основе нескольких условий, связи со стороны класса Договор - 1, со стороны Условия - n (много);

-       классы Условия и Помещение - отношение композиции. Одному условию может соответствовать несколько помещений, связи со стороны класса Договор - 1, со стороны Условия - n (много).

Зададим индексирование поля Номер договора в сущности Договор (рис. 6).

Рисунок 6 - логическая модель информационной системы

Примечание - Источник: собственная разработка.

3.2 Разработка физической модели ИС

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

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога.

После преобразования логической модели в физическую имеем следующую модель

Физическая модель изображена на рисунке 7.

Рисунок 7 - физическая модель информационной системы

Примечание - Источник: собственная разработка.

На основании разработанной в программном продукте Microsoft Visio физической модели информационной системы была сгенерирована база данных в Microsoft Access.

Схема БД изображена на рисунке 8.

Рисунок 8 - схема БД

Примечание - Источник: собственная разработка

3.3 Формирование таблицы описания документов и разработка форм входных и выходных документов в среде программирования C++ Builder

Рисунок 9 - главная форма БД в пользовательском режиме

Примечание - Источник: собственная разработка

На форме использовались следующие элементы:

-       элемент Label (название форм);

-       элемент Button (кнопка выхода);

-       компонент ADOConnection (обеспечивал связь с БД);

-       компонент ADOQuery (SQL запрос);

-       компонент DataSource (для связи приложения с таблицей);

-       компонент DBGrid (окно для вывода информации из БД);

-       компонент DBNavigator (компонент для перемещения по БД).

Рисунок 10 - Форма документа в пользовательском режиме

Примечание - Источник: собственная разработка

Поиск информации осуществляется по SQL-запросу:* from Klient

Рисунок 11 - Форма документа в пользовательском режиме

Примечание - Источник: собственная разработка

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

Поиск информации осуществляется по SQL-запросу:* from Dogovor

Рисунок 12 - Форма документа в пользовательском режиме

Примечание - Источник: собственная разработка

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

Поиск информации осуществляется по SQL-запросу:* from Pomeschenie

Рисунок 13 - Запрос в пользовательском режиме

Примечание - Источник: собственная разработка

По запросу выдаётся информация о помещениях, которые сдаются в аренду.

Поиск информации осуществляется по SQL-запросу:* from Pomeschenietip='аренда'

Рисунок 14 - Запрос в пользовательском режиме

Примечание - Источник: собственная разработка

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

Поиск информации осуществляется по SQL-запросу:* from Pomeschenietip='продажа'

Рисунок 15 - Запрос в пользовательском режиме

Примечание - Источник: собственная разработка

По запросу выдаётся информация о помещениях на покупку.

Поиск информации осуществляется по SQL-запросу:* from Pomeschenietip='покупка'

Рисунок 16 - Форма документа в пользовательском режиме

Примечание - Источник: собственная разработка

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

Поиск информации осуществляется по SQL-запросу:* from Sotrudniki

Заключение

В ходе работы был рассмотрен общий процесс деятельности риэлторской компании.

Основой для создания информационной системы послужили проблемы предметной области. Для разработки проекта программных приложений использовались CASE-средства IBM Rational Rose 2003, Microsoft Visio, в результате чего была построена концептуальная, логическая и физическая модели информационной системы.

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

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

С помощью C++ Builder 6 разработана форма для работы с базой данных Access проекта. Разработанная база данных позволит не только отображать сведения о клиентах, договорах и сотрудника, но и позволит отразить помещения только по аренде/продаже/покупке помещения, добавить нового клиента, договор, помещение и сотрудника.

Список использованных источников

1.      Курс лекций - Основы риэлторской деятельности [Электронный ресурс] - Режим доступа: <#"787453.files/image017.gif">

Рисунок А - диаграмма действий

Примечание - Источник: собственная разработка.

Приложение Б. Сгенерированный программный код на языке ANSI C++

Таблица 1 - Сгенерированный программный код на языке ANSI C++

Приложение В. Код главной формы

#include <vcl.h>

#pragma hdrstop

#include "glavnaya.h"

#include "Unit2.h"

#include "Unit3.h"

#include "Unit4.h"

#include "Unit5.h"

#include "Unit6.h"

#include "Unit7.h"

#include "sotrudn.h"

//---------------------------------------------------------------------------

#pragma package(smart_init)

#pragma resource "*.dfm"*Form1;

//---------------------------------------------------------------------------

__fastcall TForm1::TForm1(TComponent* Owner)

: TForm(Owner)

{

}

//---------------------------------------------------------------------------__fastcall TForm1::KnVyhodClick(TObject *Sender)

{();

}

{>ShowModal();

}

//---------------------------------------------------------------------------__fastcall TForm1::KnDogovoraClick(TObject *Sender)

{>ShowModal();

}

//---------------------------------------------------------------------------__fastcall TForm1::KnPomesceniyaClick(TObject *Sender)

{>ShowModal();

}

//---------------------------------------------------------------------------__fastcall TForm1::Button1Click(TObject *Sender)

{->ShowModal();

}

//---------------------------------------------------------------------------__fastcall TForm1::Button2Click(TObject *Sender)

{->ShowModal();

}

//---------------------------------------------------------------------------__fastcall TForm1::Button3Click

(TObject *Sender)

{->ShowModal();

}

//---------------------------------------------------------------------------__fastcall TForm1::Button6Click(TObject *Sender)

{->ShowModal();

}

//---------------------------------------------------------------------------