Модель автоматизации документооборота
1. Постановка задачи
При доработке систем автоматизации
документооборота на этапах кодирования и тестирования выявляется большое
количество ошибок, исправление которых влечет за собой кардинальное изменение
всей разрабатываемой системы. Учесть такие ошибки возможно только при
моделировании и глубоком, детальном анализе создаваемых проектов. Моделирование
позволяет «увидеть» проект в процессе разработки и создать предпосылки для
анализа поведения системы в зависимости от начальных условий.
2. Выбор языка моделирования
Языком разработки модели системы был
выбран унифицированный язык моделирования (Unified Modeling Language, 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 получил широкое распространение и динамично развивается.
3. Выбор среды
моделирования
При выборе программного обеспечения
позволяющего построить легко, а главное правильно модели системы на языкtUML, я рассматривала
несколько программ. Рассмотрим их основные характеристики:
1. Yworks yED 3.8 - программа для создания различного рода диаграмм. С помощью
yEd можно легко создать диаграмму сети, процесса, организационной структуры или
uml диаграмму. yEd поддерживает разные виды диаграмм [7]:
Иерархические
Выделяет
направление основного потока в схемах и сетей, а также определяет иерархию
уровней и зависимостей. Поддержка ортогональных чертежей и сгруппированных
диаграмм[7].
Органические
Выделяет данные
присущие группам и симметрии и дает представление о взаимосвязанности больших и
сложных структур. Поддержка сгруппированных диаграммы[7].
Ортогональные
Создает ясные
диаграммы с ортогональными соединения только там, где соединения осуществляются
с минимальным количеством пересечений и изгибов. Поддержка сгруппированных
диаграмм и эксклюзивные маршрутизации соединений.
Древовидные
Оптимально
организует древовидную структуру. Использует направленные и радиальные стили и
поддерживает компактное расположение.
Кольцевые
Выделяет топологии
типа кольцо и звезда в сетях. Группирует объекты в соответствии со структурой
сети и организует их на круги или с помощью радиальной структуры дерева[7].
1. Дополняет пакет Microsoft Office.
Сотрудники компаний могут создавать информативные диаграммы, дополняя и
расширяя материалы, с которыми они работают в приложениях Office.
. Упрощает проектирование,
развертывание и сопровождение систем. Технические специалисты могут
документировать идеи, информацию и системы, а также представлять их в виде
диаграмм. Эта возможность упрощает развертывание систем. Кроме того, Visio
расширяет возможности средств разработки, позволяет создавать чертежи и планы
зданий.
. Обеспечивает возможность
разработки специализированных решений. Visio позволяет создавать специальные
фигуры и трафареты для поддержки корпоративных стандартов, а также
разрабатывать собственные полномасштабные решения для работы с диаграммами.
Преимущества Visio[8]:
1. Быстрое создание
профессионально оформленных диаграмм. Visio предлагает средства, необходимые
для быстрого создания профессионально оформленных диаграмм и обмена ими.
Знакомая среда Microsoft Office упрощает освоение и использование продукта. Для
создания качественных диаграмм с помощью Visio вам не требуется быть
чертежником. Диаграммы можно создавать быстро и легко, перетаскивая готовые
символы SmartShapes с трафаретов в рабочую область. Готовые рамки, фоновые
изображения и цветовые схемы помогают в оформлении диаграмм. Диаграммы,
скопированные в документы Office или сохраненные в виде подробных веб-страниц,
могут быть легко переданы другим пользователям.
2. Наглядное представление
идей, информации и систем. Visio поддерживает множество типов диаграмм, в том
числе схемы бизнес-процессов и организационные диаграммы, планы зданий и планы
размещения офисного оборудования, сетевые диаграммы, карты веб-узлов, диаграммы
баз данных и т.д. Во многих случаях диаграммы могут быть сгенерированы автоматически
на основе данных из Microsoft Excel, Exchange Server, SQL Server и других
источников. Visio позволяет хранить информацию в полях специальных свойств и
создавать отчеты, а также экспортировать диаграммы в распространенные форматы
обмена данными.
. Преимущества единого
стандарта построения диаграмм. Visio представляет собой единую настраиваемую
систему построения диаграмм, развертывание и сопровождение которой не
составляет труда для предприятий. Поскольку в продуктах семейства Visio
используется единый формат файлов, сотрудники организации могут легко
обмениваться диаграммами - независимо о того, какой выпуск Visio использует
каждый из них. Visio Standard и Visio Professional также позволяют создавать
собственные системы построения диаграмм. Кроме того, организации могут с
успехом выполнять широкомасштабное развертывание этого продукта, применяя
средства, позволяющие устанавливать и сопровождать Visio на тысячах настольных
компьютеров. [8]
Оценив все преимущества, в качестве
среды моделирования выбрана среда Microsoft Visio.
4. Концептуальная модель
системы
Концептуальная модель - это
систематизированное содержательное описание моделируемой системы (или
проблемной ситуации) на неформальном языке. Неформализованное описание
разрабатываемой имитационной модели включает определение основных элементов
моделируемой системы, их характеристики и взаимодействие между элементами на
собственном языке. При этом могут использоваться таблицы, графики, диаграммы и
т.д. Неформализованное описание модели необходимо как самим разработчикам (при
проверке адекватности модели, ее модификации и т.д.), так и для взаимопонимания
со специалистами других профилей.
Концептуальная
модель содержит исходную информацию для системного аналитика, выполняющего
формализацию системы и использующего для этого определенную методологию и
технологию, т.е. на основе неформализованного описания осуществляется
разработка более строгого и подробного формализованного описания.
Затем
формализованное описание преобразуется в программу - имитатор в соответствии с
некоторой методикой (технологией программирования).
Рассмотрим
концептуальную модель автоматизации документооборота риэлтерской фирмы (рисунок
1):
Рисунок 1 - Общая
концептуальная модель
Рассмотрим концептуальную
модель более подробно по пакетам. Пакет 1 - Поступление недвижимости. Данная
часть программы отвечает за учет приобретенных либо построенных объектов
недвижимости, земельных участков (рисунок 2):
Рисунок 2 -
Концептуальная модель пакета 1
Пакет 2 - Звонки и
встречи. Данная часть программы отвечает за учет звонков и встреч с клиентами
фирмы, для ведения отчетности по различным видам рекламы, городам обращения и
прочей информации (рисунок 3):
Пакет 3 - Реализация
недвижимости. В этой части программы регистрируется продажа объекта,
фиксируется вся необходимая информация, а так же выводится на печать вся
необходимая документация.
Пакет 4 - Зарплата
менеджеров. Рассчитывается заработная плата по менеджерам, информационная база
анализирует продажи за месяц и выводит информацию по продажам, суммам и
процентной оплате менеджеру.
Пакет 5 - Финансовый
результат. Составление финансового результата за период. Составляется из
введенной информации в информационную базу.
Рисунок 3 -
Концептуальная модель пакета 2
Рисунок 4 -
Концептуальная модель пакета 3.
5. Диаграмма вариантов
использования
Визуальное моделирование
в UML можно представить как некоторый процесс поуровневого спуска от наиболее
обшей и абстрактной концептуальной модели исходной системы к логической, а
затем и к физической модели соответствующей программной системы. Для достижения
этих целей вначале строится модель в форме так называемой диаграммы вариантов
использования (use case diagram), которая описывает функциональное назначение
системы или, другими словами, то, что система будет делать в процессе своего
функционирования. Разработка диаграммы вариантов использования преследует цели:
· Определить общие границы
и контекст моделируемой предметной области на начальных этапах проектирования
системы;
· Сформулировать
общие требования к функциональному поведению проектируемой системы;
· Разработать
исходную концептуальную модель системы для ее последующей детализации в форме
логических и физических моделей;
· Подготовить
исходную документацию для взаимодействия разработчиков системы с ее заказчиками
и пользователями.
Суть данной диаграммы состоит в
следующем: проектируемая система представляется в виде множества сущностей или
актеров, взаимодействующих с системой с помощью так называемых вариантов
использования. Составим диаграмму вариантов использования для нашей разработки,
будем рассматривать каждую роль отдельно.
Составим диаграмму вариантов
использования для роли «Секретарь» (рисунок 5):
Рисунок 5 - Диаграмма
вариантов использования для роли «Секретарь»
Рассмотрим каждую
функцию роли «Секретарь» более подробно:
Фиксация вызова -
фиксируется вызов от потенциального покупателя, по трем направлениям: квартиры,
городские участки, лесные участки, при фиксации вызова по объектам,
автоматически создается заявка в отдел продаж для дальнейшей работы с
покупателем. При фиксации звонка, создается документ в информационной базе т.е.
производится редактирование информационной базы и внесение новой информации по
пунктам.
Консультация -
консультации звонящих людей по интересующим вопросам.
Составление отчета о
звонках - создается отчет по принятым звонкам в течении разных сроков
(пользователь выбирает необходимый интервал времени, для составления отчета).
Отчет создается по средствам обращения к информационной базе, в которой до
этого была внесена информация по звонкам.
Составим диаграмму
вариантов использования для роли «Менеджер» (рисунок 6):
Рисунок 6 - Диаграмма
вариантов использования для роли «Менеджер»
Рассмотрим каждую
функцию роли «Менеджер» более подробно:
Консультации -
Консультации потенциальных покупателей по объектам. Консультации могут быть по
телефону и при личной встречи. Менеджер подробно рассказывает всю необходимую
информацию по каждому объекту. Так же можно информацию взять из информационной
базы.
Составление отчета о
звонках - создается отчет по звонкам в течении разных сроков (пользователь
выбирает необходимый интервал времени, для составления отчета), а так же о
встречах. Отчет создается по средствам обращения к информационной базе, в
которую до этого была внесена информация по звонкам.
Составим диаграмму вариантов
использования для роли «Бухгалтер» (рисунок 7):
Рисунок 7 - Диаграмма
вариантов использования для роли «Бухгалтер»
Рассмотрим каждую
функцию роли «Бухгалтер - аналитик» более подробно:
Редактирование информационной
базы - при редактировании информационной базы, пользователь производит много
различных действий, таких как:
1. Регистрация поступления
объектов - ввод информации по новым объектам, регистрация факта поступления и
оплаты поставщику.
2. Регистрация реализация
объектов - ввод информации по проданному объекту (сумма, покупатель, менеджер и
т.д.). Печать всей необходимой документации из базы (счет, договор и т.д.),
фиксация факта поступления денег.
. Начисление заработной платы
работникам - начисление заработной платы по сотрудникам, ввод отклонений,
премий. Расчет зарплаты по сотрудникам находящимся на сдельной оплате труда
(менеджеры). Расчет налогов и выплата заработной платы.
Составление финансового результата -
Оценка работы менеджеров, рекламы. Рассмотрение лучшего вида рекламы и
выявление проблемных участков организации за определенный период времени.
Данные берутся из информационной базы и выводятся в виде отчета.
Составление отчета по различным
сферам - создается отчет по интересующему направлению и периоду. Отчет
создается по средствам обращения к информационной базе, в которую до этого была
внесена информация.
6. Диаграмма классов
автоматизация документооборот
риэлтерский моделирование
Центральное место в
объектно-ориентированном программировании занимает разработка логической модели
системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для
представления статической структуры модели системы в терминологии классов
объектно-ориентированного программирования. Диаграмма классов может отражать, в
частности, различные взаимосвязи между отдельными сущностями предметной
области, такими как объекты и подсистемы, а также описывать их внутреннюю
структуру и типы отношений.
Диаграмма классов представляет собой
граф, вершинами которого являются элементы типа «классификатор», связанные
различными типами структурных отношений. Диаграмма классов может также
содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как
объекты и связи.
Построим диаграмму классов для нашей
разработки. На данной диаграмме рассмотрены следующие классы (Рисунок 8):
· Поступление
недвижимости;
· Реализация
недвижимости;
· Звонки;
· Встречи и показы;
· Зарплата
менеджеров;
· Финансовый
результат.
Рисунок 8 - Диаграмма
классов
Программный код для
классов:
Процедура ПриЗаписью()
// Квартиры
Для каждого Строка Из ЭтотОбъект.
Квартиры Цикл
Если Строка. Квартира=Справочники. Квартиры.
ПустаяСсылка() тогда
НовыйЭлемент = Справочники.
Квартиры. СоздатьЭлемент();
НовыйЭлемент. Владелец=Объект.
Ссылка;
НовыйЭлемент. Дата = Дата;
НовыйЭлемент.
СтоимостьКвадратногоМетра=ЦенаЗаКвадратныйМетр;
НовыйЭлемент. ПроектнаяПлощадь =
Строка. ПроектнаяПлощадь;
НовыйЭлемент.
КоличествоКомнат=Строка. КоличествоКомнат;
НовыйЭлемент. Наименование = «Кв №
«+Строка (Строка. НомерКвартиры);
НовыйЭлемент. НомерКвартиры =
Строка. НомерКвартиры;
НовыйЭлемент. Этаж = Строка. Этаж;
НовыйЭлемент. НомерСекции = Строка.
НомерСекции;
НовыйЭлемент. ОбъектОписание =
Объект;
НовыйЭлемент. НомерСекции = Строка.
НомерСекции;
НовыйЭлемент. ОбщаяПлощадь = Строка.
ОбщаяПлощадь;
НовыйЭлемент. Адрес =
АдресОбъектаОбщий;
НовыйЭлемент.
КадастровыйНомер=Строка. КадастровыйНомер;
НовыйЭлемент. Записать();
Строка. Квартира = НовыйЭлемент.
Ссылка;
Иначе
Квартирка =Строка.
Квартира.получитьОбъект();
Квартирка. Владелец=Объект. Ссылка;
Квартирка. Дата=Дата;
Квартирка.
СтоимостьКвадратногоМетра=ЦенаЗаКвадратныйМетр;
Квартирка. ПроектнаяПлощадь =
Строка. ПроектнаяПлощадь;
Квартирка. НомерСекции = Строка.
НомерСекции;
Квартирка. КоличествоКомнат=Строка.
КоличествоКомнат;
Квартирка. Наименование = «Кв №
«+Строка (Строка. НомерКвартиры);
Квартирка. НомерКвартиры = Строка.
НомерКвартиры;
Квартирка. НомерСекции = Строка.
НомерСекции;
Квартирка. Этаж = Строка. Этаж;
Квартирка. ОбъектОписание = Объект;
Квартирка. ОбщаяПлощадь = Строка.
ОбщаяПлощадь;
Квартирка. Адрес =
АдресОбъектаОбщий;
Квартирка. КадастровыйНомер =
Строка. КадастровыйНомер;
Квартирка. Записать();
Строка. Квартира = Квартирка.
Ссылка;
КонецЕсли;
КонецЦикла;
КонецПроцедуры()
. Реализация недвижимости.
Рассмотри две процедуры «ПриИзменении» и «ПодсчетСтоимостиОбъектаЦена»:
.1 Процедура ПриИзменении(Элемент)
// Квартиры
Запрос = Новый Запрос ();
Запрос. Текст =«ВЫБРАТЬ
| КвартирыОстатки.
СебестоимостьОстаток,
| КвартирыОстатки. Квартира,
| КвартирыОстатки.
ПроектнаяПлощадьОстаток,
| КвартирыОстатки.
КадастровыйНомер
|ИЗ
| РегистрНакопления.
Квартиры. Остатки(,) КАК КвартирыОстатки
|ГДЕ
| КвартирыОстатки. Квартира.
Ссылка = &ВыбКвартира»;
Запрос. УстановитьПараметр
(«ВыбКвартира», Квартира. Ссылка);
Выборка = Запрос.
Выполнить().Выбрать();
Пока Выборка. Следующий() Цикл
ПлощадьОбъекта = Выборка.
ПроектнаяПлощадьОстаток;
СтоимостьОбъекта = Выборка.
СебестоимостьОстаток;
ЦенаЗаКвадратныйМетр =
СтоимостьОбъекта/ПлощадьОбъекта;
КадастровыйНомер = Выборка.
КадастровыйНомер;
КонецЦикла;
// Участки
Запрос = Новый Запрос ();
Запрос. Текст =«ВЫБРАТЬ
| ГорУчОстатки.
СебестоимостьОстаток,
| ГорУчОстатки. Участки,
| ГорУчОстатки.
ПлощадьОстаток,
| ГорУчОстатки.
КадастровыйНомерГорУч // Ирина
| РегистрНакопления.
ГородскиеУчастки. Остатки(,) КАК ГорУчОстатки
|ГДЕ
| ГорУчОстатки. Участки.
Ссылка = &ВыбГорУч»;
Запрос. УстановитьПараметр («ВыбГорУч»,
ГородскойУчасток. Ссылка);
Выборка = Запрос.
Выполнить().Выбрать();
Пока Выборка. Следующий() Цикл
ПлощадьОбъекта = Выборка.
ПлощадьОстаток;
СтоимостьОбъекта = Выборка.
СебестоимостьОстаток;
ЦенаЗаКвадратныйМетр =
СтоимостьОбъекта/ПлощадьОбъекта;
КонецЦикла;
КонецПроцедуры
.2Процедура
ПодсчетСтоимостиОбъектаЦена(Элемент)
Если ПлощадьОбъектаПродажа = 0 тогда
ПлощадьОбъектаПродажа =
СтоимостьОбъектаПродажа/ЦенаЗаКвадратныйМетрПродажа;
Иначе
СтоимостьОбъектаПродажа =
ПлощадьОбъектаПродажа * ЦенаЗаКвадратныйМетрПродажа;
КонецЕсли;
КонецПроцедуры
7. Диаграмма состояний
Диаграмма состояний
- это, по существу, диаграмма состояний из теории автоматов cо
стандартизированными условными обозначениями, которая может определять
множество систем от компьютерных программ до бизнес-процессов. Используются
следующие условные обозначения:
· Круг,
обозначающий начальное состояние.
· Окружность с маленьким кругом внутри, обозначающая конечное
состояния (если есть).
· Скругленный прямоугольник, обозначающий состояние. Верхушка
прямоугольника содержит название состояния. В середине может быть
горизонтальная линия, под которой записываются активности, происходящие в
данном состоянии.
· Стрелка, обозначающая переход. Название события (если есть),
вызывающего переход, отмечается рядом со стрелкой. Охраняющее выражение может
быть добавлено перед «/» и заключено в квадратные скобки, что значит, что это
выражение должно быть истинным, чтобы переход имел место. Если при переходе
производится какое-то действие, то оно добавляется после «/»
· Толстая горизонтальная линия с либо множеством входящих линий и
одной выходящей, либо одной входящей линией и множеством выходящих. Это
обозначает объединение и разветвление соответственно.
Рассмотрим диаграмму состояний для
каждой роли.
В схемах изображены функции работы
касающиеся доработанной части программы (рисунок 9-11).
Рисунок 9 - Диаграмма
состояний роли «Секретарь»
Рисунок 10 - Диаграмма
состояний роли «Менеджер»
Рисунок 11 - Диаграмма
состояний роли «Бухгалтер»
Заключение
Целью данной курсовой работы была
разработка модели системы автоматизации документооборота риэлтерской
организации. Данная цель была достигнута, и в ходе разработки были реализованы
следующие диаграммы и модели:
· Концептуальная модель
системы
· Диаграмма вариантов
использования;
· Диаграмма классов;
· Диаграмма
состояний.
Все эти диаграммы очень важны при
разработке программного кода дипломного проекта, они несомненно упрощают задачу
разработки программного продукта.