Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Управление взаимоотношениями с клиентами» с помощью UML (Унифицированный язык моделирования UML)

Содержание:

Введение

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

Наиболее удобным способом хранения информации - создание базы данных на основе уже имеющейся информации.

Прежде чем приступить к реализации автоматизированной системы управления (АСУ), необходимо четко определить назначение каждого компонента и выбрать метод реализации каждой из его функций. Функциональные аспекты компонентов проектируемой ИС удобно представлять в виде диаграмм использования UML (унифицированный язык моделирования). При разработке данного проекта использовался UML и Rational Rose – мощное CASE - средство, помогающее строить модели систем.

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

Данная система решает следующие задачи:

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

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

Объект исследования – взаимоотношения клиентов и администраторов автомоечного комплекса.

Предмет исследования – процесс моделирования предметной области.

1. Методология проектирования информационных систем

1.1 Унифицированный язык моделирования UML

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

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

    • Возможностью создания приемлемой (соответствующей целям пользователей) структуры базы данных в определенные сроки и при определенных затратах.
    • Универсальностью, гибкостью и доступностью для разработчиков с различным опытом проектирования и использующих различные модели данных.
    • Воспроизводимостью, заключающейся в том, что если два независимых разработчика применяют одну методологию для решения одной и той же проблемы, то они должны получить одинаковые или почти одинаковые результаты. Чтобы методология проектирования обладала перечисленными свойствами, она должна включать следующие основные компоненты:
  • Процесс проектирования, который должен состоять из последовательности этапов, на каждом из которых необходим выбор из нескольких альтернативных решений.
  • Критерии качества альтернативных решений на каждом этапе и методики их расчетов.
  • Информационные требования в качестве исходных данных для проектирования, как в целом, так и на каждом этапе.
  • Средства описания исходных данных и результатов каждого этапа проектирования.

Проектирование информационных систем включает в себя следующие этапы[3]:

  • Определение предметной области.
  • Анализ и описание функций системы средствами UML.
  • Проработка требования к БД.
  • Проектирование БД.
  • Реализация автоматизированной системы управления.

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

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

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

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

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

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

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

Потребность в качестве процесса разработки обуславливает необходимость создания стандартных условных обозначений. Язык UML представляет собой именно такую систему обозначений.

Авторами UML являются Гради Буч (Grady Booch), Джеймс Румбах (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Известные как «три товарища», в 80-х – начале 90-х годов они работали в разных организациях и независимо друг от друга продумывали методологии объектно-ориентированного анализа и проектирования, которые имели явные преимущества перед всеми остальными известными методами. В середине 90-х годов они стали заимствовать идеи друг у друга и поэтому решили объединить свои усилия.

В 1994 году Румбаха пригласили в компанию Rational Software Corporation, где в это же время уже работал Буч. Через год к ним присоединился Якобсон.

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML полезен для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться.

1.2 Описание UML диаграмм в Rational Rose

Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования, которые появились в конце 80-х и начале 90-х годов, а с 1997 года является стандартом OMG в области визуального объектно-ориентированного моделирования и широко используется на практике, будучи реализован в рамках многих CASE-средств[4].

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

В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах[5]:

Use case diagram (диаграммы прецедентов);

Activity diagram (диаграммы активности);

Sequence diagram (диаграммы последовательностей действий);

Use case diagram (диаграммы прецедентов)

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).

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

Activity diagram (диаграммы активности)

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

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

Sequence diagram (диаграммы последовательностей действий)

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

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

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

2. Моделирование предметной области с использованием модели UML

2.1 Постановка задачи проектирования

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

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

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

Разработанная система должна:

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

2.2 Построение диаграмм

Целью данного этапа является проведение анализа бизнес-процессов заказчика и на основе данного анализа построение модели автоматизированной системы управления (АСУ). Для этого необходимо произвести анализ объектов капитального строительства, графика и объема их финансирования, условия заключаемых договоров и этапы их оплаты. Также необходимо провести анализ роли ответственных лиц (Actors) и т.д. Задача это не простая и требует значительных аналитических усилий и опыта. Результатом этой работы должен быть список ролей в компании заказчика, четкое понимание процесса и список объектов (сущностей), участвующих в этом процессе. Все это и должно найти отражение в диаграммах Rational Rose. Кроме того, необходимо вместе с заказчиком составить список требований к ИС.

Используем следующий подход: используем Use case diagram для отображения списка операций, которые должна выполнять наша система; иначе говоря, это требования к системе. Каждый Use case – это некоторый процесс (последовательность действий), поэтому мы должны использовать Sequence diagram для его детализации. На этой диаграмме мы отображаем объекты из предметной области (объекты, участвующие в бизнес-процессе); таким образом, мы получаем экземпляры некоторых классов и их взаимодействие. Sequence diagram отображает сам процесс, статическая картина взаимодействия объектов отображается с помощью Class diagram.

Начнем создавать диаграмму прецедентов – Use case diagram (диаграммы прецедентов). На Use case diagram отображаем взаимодействие между ролями (актерами) и прецедентами (т.е. это случаи использования ИС)[6].

Прецедент – это некоторый процесс, в котором обычно участвуют несколько объектов.

Диаграмма прецедентов

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

Актер – это роль, которую пользователь играет по отношению к системе.

Актерами являются: Клиент, Пользователь, Администратор.

Правильный 1ый прецендент

Рис. 1. Диаграмма прецедентов

Прецедент- "Запись клиента на мойку"

Краткое описание

Вариант использования " Запись клиента на мойку " позволяет клиенту заполнить форму для заявки на мойку своего автомобиля.

Основной поток

  1. Прецедент начинается, когда пользователь заходит на сайт.
  2. Пользователь заходит под своим зарегистрированным именем и паролем.
  3. На экран выводится сообщение об успешном входе на сайт.
  4. Далее клиент переходит по вкладке оформить заявку.
  5. На экран выводится форма для оформления заявки, предоставляется возможность заполнить такие поля как: Автомобиль, Услуга, Терминал и дата записи.
  6. На экран выводится сообщение об успешно добавленной записи “Запись добавлена”
  7. В базу данных добавляется новая запись.
  8. Прецедент завершается.

Альтернативный поток А1. Не все данные были введены.

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

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

3. Система определяет все ли запрашиваемые данные введены. Если не все, то выполняется альтернативный поток А1. Если во время отправки возникли ошибки, то выполняется поток ошибок Е1.

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

Поток ошибок Е1. Ошибка при отправке данных.

1. В браузере отображается сообщение о ошибке при отправке данных и приглашение ввести данные еще раз.

2. Пользователь вводит необходимые данные и нажимает кнопку "Отправить".

3. Система определяет все ли запрашиваемые данные введены. Если не все, то выполняется альтернативный поток А1. Если во время отправки возникли ошибки, то выполняется поток ошибок Е1.

4. Система выводит сообщение о том, что данные успешно отправлены.

5. Прецедент завершается.

Диаграммы взаимодействия (interaction diagrams)

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

Как правило, описывает поведение только одного варианта использования.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams)

Диаграммы последовательности (Sequence diagrams)

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

Струтктура 2Рис.2 Диаграмма последовательности для прецедента “Запись клиента на мойку”

Струетура3

Рис.3. Кооперативная диаграмма для прецедента «Запись клиента на мойку»

2.3 Проектирование базы данных

Процесс проектирования базы данных состоит из следующих отдельных шагов: концептуального проектирования, проектирования логической структуры базы данных, которая поддерживается СУБД и описывает представление пользователя о данных, и выбора физической структуры, которая включает представление данных, методы доступа и физическое группирование данных[7].

Построим ER-модель системы.

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

Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности (это требование в некотором роде аналогично требованию отсутствия кортежей-дубликатов в реляционных таблицах или требованию идентифицируемости объектов (object identity) в объектно-ориентированных системах).

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

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

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

Определим атрибуты сущностей:

  1. НКлиента-ключ
  2. Фамилия, Имя, Отчество, Телефон, Адрес
  3. НТипа – ключ
  4. Описание, Категории
  5. НАвто – ключ
  6. Тип авто, Владелец, Марка, Гос. Номер.
  7. Нуслуги - ключ
  8. Описание, Базовое время выполнения, Базовая стоимость, Наименование.
  9. НЗаказа – ключ
  10. Время, Подтверждение, Длительность
  11. НТерминала – ключ
  12. Категория, Описание
  13. НСотрудника – ключ
  14. Должность, Фамилия, Имя, Отчество, Телефон, Адрес, Дата приема на работу
  15. НЗаписи - ключ
  16. Тип записи, Логин, Пароль, Дата регистрации

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

Структ

Рис. 4 Схема данных

Заключение

Главной целью работы было моделирование взаимоотношений с клиентами автомоечного комплекса . Для разработки данной системы я использовал унифицированный язык моделирования UML и Rational Rose - case– средство, помогающее строить модели UML.

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

Разработанная ИС позволяет приложению:

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

Реализованная ИС в дальнейшем будет внедрена в автомоечный комплекс.

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

Список использованной литературы

  1. РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов.
  2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
  3. ГОСТ 34.602-89. Информационная технология.
  4. ГОСТ 19.701-90. Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
  5. РД IDEF0 2000. Методология функционального моделирования.
  6. Автоматизированные информационные технологии в экономике /Под ред. проф. ГА, Титоренко. - М.: ЮНИТИ, 2008.
  7. Введение в системы баз данных – СПб: Издательский дом «Вильямс», 2010. - 848с.
  8. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010
  9. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем – М.: ИНТУИТ.ру, 2005
  10. Данелян Т.Я. Организация и функционирование больших информационных систем. – М.: МЭСИ, 2011
  11. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.
  12. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
  13. Разработка программного обеспечения - СПб: Питер, 2010. - 592с.
  14. Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2005. – 400с.
  1. Автоматизированные информационные технологии в экономике /Под ред. проф. ГА, Титоренко. - М.: ЮНИТИ, 2008.

  2. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010

  3. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.

  4. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.

  5. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010

  6. ГОСТ 19.701-90. Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения

  7. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.