Разработка регламента выполнения процесса «Управление документооборотом
Содержание:
Введение
Целью работы – разработка автотизированной системы документооборота, в конечном итоге позволяющей снизить издержки на данный процесс.
Задачи работы:
1 Описать предметную область
2 Разработать автоматизированную систему документооборота в виде диаграмм UML
2 Разработать автоматизированную систему документооборота в виде диаграмм IDEF
Предметом дипломной работы является разработка системы автоматизации документоооборота в виде диаграмм UML.
Объектом дипломной работы является система, средствами которой осуществляется разработка системы автоматизации документоооборота.
При решении поставленных задач в процессе работы использовались методы:
- аналитический метод;
- статистический метод;
- графические методы;
- сравнительный метод;
- методы сбора и обработки данных;
Практическая значимость проекта заключается в современности и актуальности используемых технологий, благодаря которым решались поставленные задачи, в оптимизации множества процессов и новизне приводимой информации. Основные положения данного дипломного проекта доведены до возможных рекомендаций администрациим пожелавшим вывести свой бизнес в интернет.
При доработке систем автоматизации документооборота на этапах кодирования и тестирования выявляется большое количество ошибок, исправление которых влечет за собой кардинальное изменение всей разрабатываемой системы. Учесть такие ошибки возможно только при моделировании и глубоком, детальном анализе создаваемых проектов. Моделирование позволяет «увидеть» проект в процессе разработки и создать предпосылки для анализа поведения системы в зависимости от начальных условий.
1 Проектирование UML
1.1 Выбор языка моделирования
Языком разработки модели системы был выбран унифицированный язык моделирования (Unified Modeling Language, UML). UML язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это – открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре. [1]
В UML используются следующие виды диаграмм:
Структурные диаграммы:
- Диаграмма классов;
- Диаграмма компонентов;
- Композитной/составной структуры;
- Диаграмма кооперации (UML2.0);
- Диаграмма развёртывания;
- Диаграмма объектов;
- Диаграмма пакетов;
- Диаграмма профилей (UML2.2);
Диаграммы поведения:
- Диаграмма деятельности;
- Диаграмма состояний;
- Диаграмма прецедентов;
Диаграммы взаимодействия:
- Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x);
- Диаграмма обзора взаимодействия (UML2.0);
- Диаграмма последовательности;
- Диаграмма синхронизации (UML2.0).
Диаграмма классов (Static Structure diagram) – статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
- концептуальная точка зрения – диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
- точка зрения спецификации – диаграмма классов применяется при проектировании информационных систем;
- точка зрения реализации – диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Диаграмма компонентов (Component diagram) – статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т.п.
Диаграмма композитной / составной структуры (Composite structure diagram) – статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.
Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.
Диаграмма развёртывания (Deployment diagram) – служит для моделирования работающих узлов (аппаратных средств, англ. node) иартефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.
Диаграмма объектов (Object diagram) – демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма пакетов (Package diagram) – структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма деятельности (Activity diagram) – диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов – вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.
Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.
Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701–90.
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) – диаграмма, на которой представлен конечный автомат с простымисостояниями, переходами и композитными состояниями.
Конечный автомат (англ. Statemachine) – спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.
Диаграмма вариантов использования (Use case diagram) – диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.
Основная задача – представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Диаграммы коммуникации и последовательности транзитивны, выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую.
Диаграмма коммуникации (Communication diagram, в UML 1.x – диаграмма кооперации, collaboration diagram) – диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).
Диаграмма последовательности (Sequence diagram) – диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
Диаграмма сотрудничества – Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Диаграмма обзора взаимодействия (Interaction overview diagram) – разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграмма синхронизации (Timing diagram) – альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.
Преимущества UML:
- UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современныхобъектно-ориентированных языках;
- UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
- Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
- UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
- UML получил широкое распространение и динамично развивается.
1.2 Выбор среды моделирования
При выборе программного обеспечения позволяющего построить легко, а главное правильно модели системы на языкtUML, я рассматривала несколько программ. Рассмотрим их основные характеристики:
- Yworks yED 3.8 – программа для создания различного рода диаграмм. С помощью yEd можно легко создать диаграмму сети, процесса, организационной структуры или uml диаграмму. yEd поддерживает разные виды диаграмм [7]:
Иерархические
Выделяет направление основного потока в схемах и сетей, а также определяет иерархию уровней и зависимостей. Поддержка ортогональных чертежей и сгруппированных диаграмм[7].
Органические
Выделяет данные присущие группам и симметрии и дает представление о взаимосвязанности больших и сложных структур. Поддержка сгруппированных диаграммы[7].
Ортогональные
Создает ясные диаграммы с ортогональными соединения только там, где соединения осуществляются с минимальным количеством пересечений и изгибов. Поддержка сгруппированных диаграмм и эксклюзивные маршрутизации соединений.
Древовидные
Оптимально организует древовидную структуру. Использует направленные и радиальные стили и поддерживает компактное расположение.
Кольцевые
Выделяет топологии типа кольцо и звезда в сетях. Группирует объекты в соответствии со структурой сети и организует их на круги или с помощью радиальной структуры дерева[7].
Microsoft Visio – независимая система построения диаграмм, предлагающая средства для наглядного представления идей, информации и систем. Visio позволяет определять и документировать любые сложные конструкции, с которыми вы сталкиваетесь в своей повседневной работе, и предлагает возможность эффективного обмена идеями и информацией. Кроме того, использование диаграмм Visio в документах Office позволяет представить информацию в более сжатом виде, сделать основную идею более запоминающейся и устранить многие технические и культурные барьеры[8].
Visio выполняет три ключевые задачи [8]:
1. Дополняет пакет Microsoft Office. Сотрудники компаний могут создавать информативные диаграммы, дополняя и расширяя материалы, с которыми они работают в приложениях Office.
2. Упрощает проектирование, развертывание и сопровождение систем. Технические специалисты могут документировать идеи, информацию и системы, а также представлять их в виде диаграмм. Эта возможность упрощает развертывание систем. Кроме того, Visio расширяет возможности средств разработки, позволяет создавать чертежи и планы зданий.
3. Обеспечивает возможность разработки специализированных решений. Visio позволяет создавать специальные фигуры и трафареты для поддержки корпоративных стандартов, а также разрабатывать собственные полномасштабные решения для работы с диаграммами.
Преимущества Visio[8]:
- Быстрое создание профессионально оформленных диаграмм. Visio предлагает средства, необходимые для быстрого создания профессионально оформленных диаграмм и обмена ими. Знакомая среда Microsoft Office упрощает освоение и использование продукта. Для создания качественных диаграмм с помощью Visio вам не требуется быть чертежником. Диаграммы можно создавать быстро и легко, перетаскивая готовые символы SmartShapes с трафаретов в рабочую область. Готовые рамки, фоновые изображения и цветовые схемы помогают в оформлении диаграмм. Диаграммы, скопированные в документы Office или сохраненные в виде подробных веб-страниц, могут быть легко переданы другим пользователям.
- Наглядное представление идей, информации и систем. Visio поддерживает множество типов диаграмм, в том числе схемы бизнес-процессов и организационные диаграммы, планы зданий и планы размещения офисного оборудования, сетевые диаграммы, карты веб-узлов, диаграммы баз данных и т.д. Во многих случаях диаграммы могут быть сгенерированы автоматически на основе данных из Microsoft Excel, Exchange Server, SQL Server и других источников. Visio позволяет хранить информацию в полях специальных свойств и создавать отчеты, а также экспортировать диаграммы в распространенные форматы обмена данными.
- Преимущества единого стандарта построения диаграмм. Visio представляет собой единую настраиваемую систему построения диаграмм, развертывание и сопровождение которой не составляет труда для предприятий. Поскольку в продуктах семейства Visio используется единый формат файлов, сотрудники организации могут легко обмениваться диаграммами – независимо о того, какой выпуск Visio использует каждый из них. Visio Standard и Visio Professional также позволяют создавать собственные системы построения диаграмм. Кроме того, организации могут с успехом выполнять широкомасштабное развертывание этого продукта, применяя средства, позволяющие устанавливать и сопровождать Visio на тысячах настольных компьютеров. [8]
Оценив все преимущества, в качестве среды моделирования выбрана среда Microsoft Visio.
1.3 Концептуальная модель системы
Концептуальная модель – это систематизированное содержательное описание моделируемой системы (или проблемной ситуации) на неформальном языке. Неформализованное описание разрабатываемой имитационной модели включает определение основных элементов моделируемой системы, их характеристики и взаимодействие между элементами на собственном языке. При этом могут использоваться таблицы, графики, диаграммы и т.д. Неформализованное описание модели необходимо как самим разработчикам (при проверке адекватности модели, ее модификации и т.д.), так и для взаимопонимания со специалистами других профилей.
Концептуальная модель содержит исходную информацию для системного аналитика, выполняющего формализацию системы и использующего для этого определенную методологию и технологию, т.е. на основе неформализованного описания осуществляется разработка более строгого и подробного формализованного описания.
Затем формализованное описание преобразуется в программу – имитатор в соответствии с некоторой методикой (технологией программирования).
Рассмотрим концептуальную модель автоматизации документооборота риэлтерской фирмы (рисунок 1.1):
Рисунок 1.1 – Общая концептуальная модель
Рассмотрим концептуальную модель более подробно по пакетам. Пакет 1 – Поступление недвижимости. Данная часть программы отвечает за учет приобретенных либо построенных объектов недвижимости, земельных участков (рисунок 2):
Рисунок 1.2 – Концептуальная модель пакета 1
Пакет 2 – Звонки и встречи. Данная часть программы отвечает за учет звонков и встреч с клиентами фирмы, для ведения отчетности по различным видам рекламы, городам обращения и прочей информации (рисунок 1.3):
Пакет 3 – Реализация недвижимости. В этой части программы регистрируется продажа объекта, фиксируется вся необходимая информация, а так же выводится на печать вся необходимая документация.
Пакет 4 – Зарплата менеджеров. Рассчитывается заработная плата по менеджерам, информационная база анализирует продажи за месяц и выводит информацию по продажам, суммам и процентной оплате менеджеру.
Пакет 5 – Финансовый результат. Составление финансового результата за период. Составляется из введенной информации в информационную базу.
Рисунок 1.3 – Концептуальная модель пакета 2
Рисунок 1.4 – Концептуальная модель пакета 3.
1.4 Диаграмма вариантов использования
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Разработка диаграммы вариантов использования преследует цели:
- Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;
- Сформулировать общие требования к функциональному поведению проектируемой системы;
- Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
- Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. Составим диаграмму вариантов использования для нашей разработки, будем рассматривать каждую роль отдельно.
Составим диаграмму вариантов использования для роли «Секретарь» (рисунок 1.5):
Рисунок 1.5 – Диаграмма вариантов использования для роли «Секретарь»
Рассмотрим каждую функцию роли «Секретарь» более подробно:
Фиксация вызова – фиксируется вызов от потенциального покупателя, по трем направлениям: квартиры, городские участки, лесные участки, при фиксации вызова по объектам, автоматически создается заявка в отдел продаж для дальнейшей работы с покупателем. При фиксации звонка, создается документ в информационной базе т.е. производится редактирование информационной базы и внесение новой информации по пунктам.
Консультация – консультации звонящих людей по интересующим вопросам.
Составление отчета о звонках – создается отчет по принятым звонкам в течении разных сроков (пользователь выбирает необходимый интервал времени, для составления отчета). Отчет создается по средствам обращения к информационной базе, в которой до этого была внесена информация по звонкам.
Составим диаграмму вариантов использования для роли «Менеджер» (рисунок 1.6):
Рисунок 1.6 – Диаграмма вариантов использования для роли «Менеджер»
Рассмотрим каждую функцию роли «Менеджер» более подробно:
Консультации – Консультации потенциальных покупателей по объектам. Консультации могут быть по телефону и при личной встречи. Менеджер подробно рассказывает всю необходимую информацию по каждому объекту. Так же можно информацию взять из информационной базы.
Составление отчета о звонках – создается отчет по звонкам в течении разных сроков (пользователь выбирает необходимый интервал времени, для составления отчета), а так же о встречах. Отчет создается по средствам обращения к информационной базе, в которую до этого была внесена информация по звонкам.
Составим диаграмму вариантов использования для роли «Бухгалтер» (рисунок 1.7):
Рисунок 1.7 – Диаграмма вариантов использования для роли «Бухгалтер»
Рассмотрим каждую функцию роли «Бухгалтер – аналитик» более подробно:
Редактирование информационной базы – при редактировании информационной базы, пользователь производит много различных действий, таких как:
- Регистрация поступления объектов – ввод информации по новым объектам, регистрация факта поступления и оплаты поставщику.
- Регистрация реализация объектов – ввод информации по проданному объекту (сумма, покупатель, менеджер и т.д.). Печать всей необходимой документации из базы (счет, договор и т.д.), фиксация факта поступления денег.
- Начисление заработной платы работникам – начисление заработной платы по сотрудникам, ввод отклонений, премий. Расчет зарплаты по сотрудникам находящимся на сдельной оплате труда (менеджеры). Расчет налогов и выплата заработной платы.
Составление финансового результата – Оценка работы менеджеров, рекламы. Рассмотрение лучшего вида рекламы и выявление проблемных участков организации за определенный период времени. Данные берутся из информационной базы и выводятся в виде отчета.
Составление отчета по различным сферам – создается отчет по интересующему направлению и периоду. Отчет создается по средствам обращения к информационной базе, в которую до этого была внесена информация.
1.5 Диаграмма классов риэлтерский моделирование
Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.
Диаграмма классов представляет собой граф, вершинами которого являются элементы типа «классификатор», связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи.
Построим диаграмму классов для нашей разработки. На данной диаграмме рассмотрены следующие классы (Рисунок 1.8):
- Поступление недвижимости;
- Реализация недвижимости;
- Звонки;
- Встречи и показы;
- Зарплата менеджеров;
- Финансовый результат.
Рисунок 1.8 – Диаграмма классов
Программный код для классов:
- Поступление недвижимости. Рассмотрим операцию «ПриЗаписи», на примере вида объекта «Квартиры»;
Процедура ПриЗаписью()
// Квартиры
Для каждого Строка Из ЭтотОбъект. Квартиры Цикл
Если Строка. Квартира=Справочники. Квартиры. ПустаяСсылка() тогда
НовыйЭлемент = Справочники. Квартиры. СоздатьЭлемент();
НовыйЭлемент. Владелец=Объект. Ссылка;
НовыйЭлемент. Дата = Дата;
НовыйЭлемент. СтоимостьКвадратногоМетра=ЦенаЗаКвадратныйМетр;
НовыйЭлемент. ПроектнаяПлощадь = Строка. ПроектнаяПлощадь;
НовыйЭлемент. КоличествоКомнат=Строка. КоличествоКомнат;
НовыйЭлемент. Наименование = «Кв № «+Строка (Строка. НомерКвартиры);
НовыйЭлемент. НомерКвартиры = Строка. НомерКвартиры;
НовыйЭлемент. Этаж = Строка. Этаж;
НовыйЭлемент. НомерСекции = Строка. НомерСекции;
НовыйЭлемент. ОбъектОписание = Объект;
НовыйЭлемент. НомерСекции = Строка. НомерСекции;
НовыйЭлемент. ОбщаяПлощадь = Строка. ОбщаяПлощадь;
НовыйЭлемент. Адрес = АдресОбъектаОбщий;
НовыйЭлемент. КадастровыйНомер=Строка. КадастровыйНомер;
НовыйЭлемент. Записать();
Строка. Квартира = НовыйЭлемент. Ссылка;
Иначе
Квартирка =Строка. Квартира.получитьОбъект();
Квартирка. Владелец=Объект. Ссылка;
Квартирка. Дата=Дата;
Квартирка. СтоимостьКвадратногоМетра=ЦенаЗаКвадратныйМетр;
Квартирка. ПроектнаяПлощадь = Строка. ПроектнаяПлощадь;
Квартирка. НомерСекции = Строка. НомерСекции;
Квартирка. КоличествоКомнат=Строка. КоличествоКомнат;
Квартирка. Наименование = «Кв № «+Строка (Строка. НомерКвартиры);
Квартирка. НомерКвартиры = Строка. НомерКвартиры;
Квартирка. НомерСекции = Строка. НомерСекции;
Квартирка. Этаж = Строка. Этаж;
Квартирка. ОбъектОписание = Объект;
Квартирка. ОбщаяПлощадь = Строка. ОбщаяПлощадь;
Квартирка. Адрес = АдресОбъектаОбщий;
Квартирка. КадастровыйНомер = Строка. КадастровыйНомер;
Квартирка. Записать();
Строка. Квартира = Квартирка. Ссылка;
КонецЕсли;
КонецЦикла;
КонецПроцедуры()
- Реализация недвижимости. Рассмотри две процедуры «ПриИзменении» и «ПодсчетСтоимостиОбъектаЦена»:
2.1 Процедура ПриИзменении(Элемент)
// Квартиры
Запрос = Новый Запрос ();
Запрос. Текст =«ВЫБРАТЬ
| КвартирыОстатки. СебестоимостьОстаток,
| КвартирыОстатки. Квартира,
| КвартирыОстатки. ПроектнаяПлощадьОстаток,
| КвартирыОстатки. КадастровыйНомер
|ИЗ
| РегистрНакопления. Квартиры. Остатки(,) КАК КвартирыОстатки
|ГДЕ
| КвартирыОстатки. Квартира. Ссылка = &ВыбКвартира»;
Запрос. УстановитьПараметр («ВыбКвартира», Квартира. Ссылка);
Выборка = Запрос. Выполнить().Выбрать();
Пока Выборка. Следующий() Цикл
ПлощадьОбъекта = Выборка. ПроектнаяПлощадьОстаток;
СтоимостьОбъекта = Выборка. СебестоимостьОстаток;
ЦенаЗаКвадратныйМетр = СтоимостьОбъекта/ПлощадьОбъекта;
КадастровыйНомер = Выборка. КадастровыйНомер;
КонецЦикла;
// Участки
Запрос = Новый Запрос ();
Запрос. Текст =«ВЫБРАТЬ
| ГорУчОстатки. СебестоимостьОстаток,
| ГорУчОстатки. Участки,
| ГорУчОстатки. ПлощадьОстаток,
| ГорУчОстатки. КадастровыйНомерГорУч // Ирина
|ИЗ
| РегистрНакопления. ГородскиеУчастки. Остатки(,) КАК ГорУчОстатки
|ГДЕ
| ГорУчОстатки. Участки. Ссылка = &ВыбГорУч»;
Запрос. УстановитьПараметр («ВыбГорУч», ГородскойУчасток. Ссылка);
Выборка = Запрос. Выполнить().Выбрать();
Пока Выборка. Следующий() Цикл
ПлощадьОбъекта = Выборка. ПлощадьОстаток;
СтоимостьОбъекта = Выборка. СебестоимостьОстаток;
ЦенаЗаКвадратныйМетр = СтоимостьОбъекта/ПлощадьОбъекта;
КонецЦикла;
КонецПроцедуры
2.2Процедура ПодсчетСтоимостиОбъектаЦена(Элемент)
Если ПлощадьОбъектаПродажа = 0 тогда
ПлощадьОбъектаПродажа = СтоимостьОбъектаПродажа/ЦенаЗаКвадратныйМетрПродажа;
Иначе
СтоимостьОбъектаПродажа = ПлощадьОбъектаПродажа * ЦенаЗаКвадратныйМетрПродажа;
КонецЕсли;
КонецПроцедуры
1.6 Диаграмма состояний
Диаграмма состояний – это, по существу, диаграмма состояний из теории автоматов cо стандартизированными условными обозначениями, которая может определять множество систем от компьютерных программ до бизнес-процессов. Используются следующие условные обозначения:
- Круг, обозначающий начальное состояние.
- Окружность с маленьким кругом внутри, обозначающая конечное состояния (если есть).
- Скругленный прямоугольник, обозначающий состояние. Верхушка прямоугольника содержит название состояния. В середине может быть горизонтальная линия, под которой записываются активности, происходящие в данном состоянии.
- Стрелка, обозначающая переход. Название события (если есть), вызывающего переход, отмечается рядом со стрелкой. Охраняющее выражение может быть добавлено перед «/» и заключено в квадратные скобки, что значит, что это выражение должно быть истинным, чтобы переход имел место. Если при переходе производится какое-то действие, то оно добавляется после «/»
- Толстая горизонтальная линия с либо множеством входящих линий и одной выходящей, либо одной входящей линией и множеством выходящих. Это обозначает объединение и разветвление соответственно.
Рассмотрим диаграмму состояний для каждой роли.
В схемах изображены функции работы касающиеся доработанной части программы (рисунок 1.9–1.11).
Рисунок 1.9 – Диаграмма состояний роли «Секретарь»
Рисунок 1.10 – Диаграмма состояний роли «Менеджер»
Рисунок 1.11 – Диаграмма состояний роли «Бухгалтер»
Отразим действующие процессы документооборота в организации с использованием средств BPwin. Для отражениея этих процессов используем модель AS-IS.
ПРОЦЕСС: Регистрация документа.
ВХОД: Входящий документ.
ВЫХОД: Зарегистрированный входящий документ.
АЛГОРИТМ: Зарегистрировать поступивший входящий документ, присвоив ему уникальный номер, в соответствии с Инструкцией по делопроизводству и внутренним Порядком документооборота.
ПРОЦЕСС: Обработка документа.
ВХОД: Зарегистрированный входящий документ.
ВЫХОД: Исполненный входящий документ, исходящий ответный документ.
АЛГОРИТМ: Исполнить поступивший документ и, если требуется, подготовить и отправить ответный исходящий документ.
ПОДПРОЦЕССЫ:
Вынесение резолюций.
Постановка на контроль.
Исполнение документа.
Снятие с контроля.
ПРОЦЕСС: Списание в дело.
ВХОД: Исполненный входящий документ.
ВЫХОД: Списанный документ.
АЛГОРИТМ: Подшить обработанный документ в дело с соответствующей номенклатурой.
ПРОЦЕСС: Формирование отчетов.
ВХОД: Списанный документ, исходящий ответный документ.
ВЫХОД: Реестр зарегистрированных входящих/ исходящих документов, Реестр документов, переданных на исполнение, Сводка об исполнении документов.
АЛГОРИТМ: Ручное формирование необходимых отчетов.
ПОДПРОЦЕССЫ:
Поиск форм отчетов.
Ручное заполнение форм отчетов.
Печать отчетов.
Эта модель показывает, как функционирует документооборот в организации, когда процессы не автоматизированы.
Рисунок 2.1 – Модель AS-IS процесса «Документооборот в организации»
Рисунок 2.2 – Декомпозиция процесса «Документооборот в организации» в нотации IDЕF0 модели AS-IS
Рисунок 2.2 – Декомпозиция процесса «Обработка документа» модели AS-IS
Рисунок 2.3 - Декомпозиция процесса «Формирование отчетов» модели AS-IS
Рисунок 2.4 - Декомпозиция процесса «Исполнение документа» в нотации IDEF3 модели AS-IS
После внедрения проектируемой информационной системы, организация документооборота будет представлена в виде модели TO-BE.
ПРОЦЕСС: Автоматизированное рабочее место «Делопроизводство».
ВХОД: Входящие документы.
ВЫХОД: Автоматизированные отчеты.
ПОДПРОЦЕССЫ:
АРМ «Делопроизводство: работа с документами».
АРМ «Делопроизводство: отчетность».
ПРОЦЕСС: АРМ «Делопроизводство: работа с документами».
ВХОД: Входящие документы.
ВЫХОД: Исполненные документы, исходящие ответные документы.
АЛГОРИТМ: Автоматизированный учет документов и контроль за их исполнением.
ПОДПРОЦЕССЫ:
Регистрация в АРМ «Делопроизводство».
Рассмотрение документа.
Исполнение документа.
ПРОЦЕСС: АРМ «Делопроизводство: отчетность».
ВХОД: Исполненные документы, исходящие ответные документы.
ВЫХОД: Автоматизированные отчеты.
АЛГОРИТМ: Автоматизирование формирование отчетов и вывод их на бумажные носители.
ПОДПРОЦЕССЫ:
Автоматическая загрузка данных в шаблоны отчетов.
Вывод отчетов.
Рисунок 2.5 - Модель TO-BE процесса «АРМ “Делопроизводство”»
Рисунок 2.6 - Декомпозиция процесса «АРМ “Делопроизводство”» в нотации IDEF0 модели TO-BE
Рисунок 2.7 - Декомпозиция процесса «АРМ “Делопроизводство: работа с документами”» модели TO-BE
Рисунок 2.8 - Декомпозиция процесса «АРМ “Делопроизводство: отчетность”» модели TO-BE
Рисунок 2.9 – Контекстная диаграмма потоков данных
Заключение
Целью данной работы была разработка модели системы автоматизации документооборота риэлтерской организации. Данная цель была достигнута, и в ходе разработки были реализованы следующие диаграммы и модели:
- Концептуальная модель системы
- Диаграмма вариантов использования;
- Диаграмма классов;
- Диаграмма состояний.
Все эти диаграммы очень важны при разработке программного кода дипломного проекта, они несомненно упрощают задачу разработки программного продукта.
Список литературы
- ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ. Информационная технология. Процессы жизненного цикла информационных систем. Издание официальное. - М., 1999
- Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. ГОСТ 19.701-90 (ИСО 5807-85) / Государственный комитет СССР по управлению качеством продукции и стандартам, 01.01.1992.
- Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие, М.: Гелиос АРВ, 2007. - 368 с., ил
- Астелс, Дэвид; Миллер Гранвилл; Новак, Мирослав, Практическое руководство по экстремальному программированию, Пер. с англ. - М.: Издательский дом "Вильямс", 2008. - 320 с.: ил. - Парал. тит. англ
- Вендров А.М., CASE-технологии. Современные методы и средства проектирования информационных систем - М.: Финансы и статистика, 2007 г, 456 стр.
- Вигерс Карл, Разработка требований к программному обеспечению, Пер, с англ. - М.:Издательско-торговый дом "Русская Редакция", 2008. -576с.: ил
- Гвоздева Т. В., Б. А. Баллод, Проектирование информационных систем, М, Издательство: Феникс, 2009 г., 512 стр.
- Голицына О. Л., И. И. Попов, Н. В. Максимов, Т. Л. Партыка, Информационные технологии, М, Издательство Инфра-М, 2009 г., 608 стр.
- Емельянова Н. З., Партыка Т. Л., И. И. Попов, Проектирование информационных систем, М, Издательство: Форум, 2009 г., 432 стр.
- Емельянова Н. З., Т. Л. Партыка, И. И. Попов, М, Издательство Форум, 2007 г., , 416 стр.
- Илюшечкин В. М. , Основы использования и проектирования баз данных, М, Издательство Юрайт, 2010 г., 224 стр.
- Котляров В. П., Т. В. Коликова, Основы тестирования программного обеспечения, Издательства: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2009 г., 288 стр.
- Кузин А. В., С. В. Левонисова, Базы данных, М, Издательство: Академия, 2008 г., 320 стр.
- Кузнецов С. Д., Основы баз данных, М, Издательства: Бином. Лаборатория знаний, Интернет-университет информационных технологий, 2007 г., 488 стр.
- Молчанов А. Ю., Системное программное обеспечение, М, Издательство: Питер, 2010 г., 400 стр.
- Незнанов А. А., Программирование и алгоритмизация, М, Издательство: Академия, 2010 г., 304 стр.
- Пирогов В. Ю., Информационные системы и базы данных. М, Организация и проектирование, Издательство: БХВ-Петербург, 2009 г.528 стр.
- Предметно-ориентированные экономические информационные системы, М, Издательство: Финансы и статистика, 2007 г., 224 стр.
- Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2009 – 400с.:ил;
- Языки гипертекстовой разметки
- Разработка регламента выполнения процесса «Складской учет»
- История развития средств вычислительной техники .
- Изучение особенностей трудового конфликта как разновидности конфликтов в организациях, для разработки соответствующих рекомендаций мер для профилактики деструктивных конфликтов .
- Метод экспертных оценок и область его применения решений .
- Понятие, сущность и этапы корпоративного проектирования
- Разработка клиентского и серверного приложения по организации чата с применением протокола TCP на платформе WIN 32
- Предпринимательское право
- Возмещения морального вреда
- Средства разработки клиентских программ
- Разработка регламента выполнения процесса «Управление документооборотом» (1 Построение бизнес-процессов «как есть»)
- Информация в материальном мире. Теоретические аспекты изучения информации