Файл: Моделирование предметной области «Управление взаимоотношениями с клиентами» с помощью UML (АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ).pdf

В совокупности все эти недостатки можно было бы решить путем установления нового программного обеспечения, но так как данное предприятие небольшое, и покупка готового программного решения будет дорогостоящей, то было принято решение о разработке автоматизированной системы учета клиентов для данного предприятия [13, c.47].

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

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

Система должна обеспечивать надежную защиту информации, для чего необходимы парольное разграничении доступа, многоуровневая система защиты данных и т.д. [2, c.94]

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

В силу влияния внешних и внутренних факторов (изменений направления бизнеса, изменения в законодательстве и т.п.), система должна быть адаптивной. Применимо к России, это качество системы должно рассматриваться более серьезно, так как у нас в стране изменения законодательства и правил учета происходят в несколько раз чаще, чем в странах со стабильной экономикой [5, c.94].

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

Эти требования являются основными, но далеко не единственными критериями выбора корпоративной информационной системы для предприятия.

Проведем бизнес-анализ и определим требования к разрабатываемой системе.

Вначале определим требования к разрабатываемой информационной системе:

---

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

- пользовательский интерфейс должен быть Windows ХР и выше, Windows Vista, программный интерфейс должен быть простым легко освоенным и понятным для пользователя;

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

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

- система должна обеспечивать возможность исправления созданных ошибок [14, c.96].

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

Необходимо спроектировать и разработать систему по учету предоставления услуг клиентам, которая будет позволять автоматизировать учёт договоров на приобретение услуг и определять сумму по каждому договору [21, c.94].

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

Требования к системе: разрабатываемая информационная система должна автоматизировать процесс учета предоставления услуг клиентом в ООО «ГорЭнергоСервис». В основе системы будет лежать база данных, которая должен содержать сведения о сотрудниках, заключающих договора; информация о договорах; данные о заказчиках и сведения об услугах компании.

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

Информационные базы данных имеют и более узкое определение. Под ними понимают хранилище сведений, структурированных оптимальным для машинной обработки образом. Это наиболее распространенное определение, его лучше и принять за основу [24, c.79].

Создание базы данных, обработка и поиск всей необходимой информации в ней осуществляется с помощью системы управления базами данных (СУБД). СУБД – это набор определенных программных средств, которые предоставляют возможность пользователю быстро и эффективно взаимодействовать с БД [22, c.84].

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

---

2.МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ РЕШАЕМОЙ ЗАДАЧИ

2.1 Выбор средства для моделирования предметной области решаемой задачи

Нотация IDEF0 используется непосредственно для создания специальной функциональной модели, которая отображает структуру и функции исследуемой системы, а также и разные потоки информации, материальных объектов.

Методология IDEF0 совсем немного отличается от классического инструментария описания БП DFD.

При этом, основным отличием считается классификация входов при описании БП.

Стандарт IDEF0 предлагает следующую категоризацию входов в нотации:[11, c.85]

Вход – входит в блок слева и показывает все материальные и информационные потоки, что преобразуются в БП.

Управление – входит в работу в верхнее поле блока и показывает информационные и материальные потоки, что не преобразуются при описании БП, но нужны при выполнении.

Механизм – реализуется входом в блок снизу и показывает персонал, людей, технические средства, а также информационные системы, которые предназначены для использовании функции БП, при помощи которого бизнес-процесс выполняется [8, c.97].

Результаты (выходы) выходят из правой части блока.

Рисунок 4 – Схема IDEF0 [7, c.97]

Рассмотрим основные составные части диаграммы.

Основу графического моделирования IDEF0, а также его синтаксис и семантику, составляют блоки, соединяющие стрелки, которые дают возможность сформировать иерархию детализируемых диаграмм при описании БП [15, с.69].

Функциональный блок может быть изображен в виде прямоугольника.

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

Каждый блок:

– должен использовать для описания уникальный идентификационный номер, который должен быть указан в нижнем правом углу;

– название должно представляться только в отглагольном наклонении.

Под интерфейсной дугой понимается стрелка для соединения блоков, она изображается в качестве однонаправленной стрелки [7]

---

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

Особенности моделирования:

– дуга должна иметь только уникальное наименование;

– наименование дуги должно быть только оборотом от существительного;

– дуга должна начинаться и заканчиваться определенным функциональным блоком;

– источником может также быть выходная сторона блока, при чем, приемником – любая из оставшихся сторон.

Правила моделирования БП в нотации BPMN такими уж сложными не являются, а также, базируются на простоте восприятия и логике [2, c.78]

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

Рассмотрим главные правила нотации.

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

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

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

Начальное событие в подпроцессе конкретного типа не должно иметь.

В нотации BPMN такие понятия, как:

– процесс;

– диаграмма;

– модель;

– файл – не являются полностью эквивалентными [12, c.114].

Модель BPMN может в себе содержать сразу несколько процессов.

Модель BPMN, кроме указанных свойств, может изображаться с применением нескольких диаграмм, которые разделены специальным коннектором [22, c.98]

При создании диаграмма BPMN нельзя ее указывать, как диаграмму потоков данных.

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

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

Под диаграммой использования понимается наиболее общее представление назначения предметной области.

Диаграмма использования отвечает на главный вопрос процесса моделирования: какие действия выполняет система?

На диаграмме использования используются 2 главных типа сущностей:

---

– лица;

– варианты использования.

Стоит отметить, что между ними устанавливаются такие основные типы соотношений:

– ассоциация между лицом и вариантами использования;

– выполнение обобщения между разными действующими лицами;

– обобщение для вариантов использования;

– определение зависимостей (различных типов) для вариантов использования [9, c.158]

На диаграмме использования, аналогично, как и на других, могут присутствовать комментарии.

Кроме этого, это настоятельно рекомендуется выполнять для улучшения уровня читаемости диаграммы.

Стоит отметить, что применение данного типа диаграммы является обоснованным, так как UML – объектно-ориентированный язык, а классы являются его главными компонентами.

На диаграмме классов может быть применен один главный тип сущностей – классы (включая примитивные типы, интерфейсы, классы-ассоциации, а также многие другие), между ними устанавливаются следующие варианты отношений:

– ассоциация для классов;

– обобщения для классов;

– зависимости между классами [3, c.96].

В результате выполненного анализа будет выбрана нотация UML для моделирования процесса управления персоналом.

В настоящее время в РФ для анализа, а также выполнения моделирования БП широко могут применяться средства моделирования:

– Rational Rose;

– АllFusion Modeler;

– Oracle Designer;

– Process Modeler;

– ARIS [18, c.94].

Кроме этого, в заграничном опыте используются помимо уже упомянутых, средства Ithink Analys, System Architect.

АllFusion Data Modeler, а также продукт AllFusion Process Modeler (еще несколько лет тому назад они имели наименование ERWin, BPWin) компании Соmputer Associates давно входят в пятерку качественных производителей ПО, предлагая инструменты для резервного копирования, выполнения моделирования, управления разного рода инфраструктурой предприятия, уровнями информационной безопасности [15, c.85].

Заметим, что пакет BPWin базирован на методологии моделирования IDEF, а также он предназначается для реализации процесса функционального моделирования.

Методология IDEF, что входит в совокупность официальных стандартов США, представляется совокупностью инструментария, правил или процедур, что в свою очередь предназначены для реализации функциональной системы объекта исследуемой предметной области [6, c.94].

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

Основными характеристиками такого типа моделирования являются:

---