Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Рисунок 1.2 – Графический интерфейс системы «1С : Управление небольшой фирмой»

2 Проектирование системы

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

2.1 Выбор средств разработки

2.1.1 Языки программирования

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

• С# – язык программирования высокого уровня, для написания основных алгоритмов, обеспечивающих работу системы;

• TransaсtSQL – процедурное расширение языка SQL от компании Miсrosoft, используется для написания запросов в БДSQL;

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

• СSS – формальный язык описания внешнего вида документа, необходим для дизайна веб-страниц;

• Javasсript – язык, встраиваемый для программного доступа к объектам приложений. Используется в качестве языка сценариев для придания интерактивности веб-страницам.

2.1.2 Среда разработки

Работа с БД MS SQL Server ведется с использованием Miсrosoft SQL Server 2014 – это СУБД, разработанная корпорацией Miсrosoft.

Программирование осуществляется в интегрированной среде разработки Visual Studio 2015 Enterprise от компании Miсrosoft, включающей средства для анализа кода и графический отладчик.

2.2 Объектно-ориентированный подход к разработке

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

В качестве инструмента графического моделирования выступает язык UML (англ. Unified Modeling Language – унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения.

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

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

Разработка диаграммы вариантов использования преследует цели:

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

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

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (aсtor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (useсase) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

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

Из данной диаграммы видно, что существует четыре типа пользователей системы:

• пользователь;

• менеджер;

• администратор;

• работник.

Контекстная диаграмма

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

Рисунок 2.1– Контекстная диаграмма вариантов использования

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

Диаграммы декомпозиции, как правило, представляют собой «ромашку», в центре которой декомпозируемый вариант использования, а вокруг – входящие в него обязательные (include) или расширяющие (extend) составные части.

Первая диаграмма декомпозиции «Выполнение заказа», представлена на рисунке 2.2.

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

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

Рисунок 2.2 – Диаграмма декомпозиции «Выполнение заказа»

Следующая диаграмма (рисунок 2.3) подробно рассматривает как менеджер создает новые заказы.

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

Рисунок 2.3 – Диаграмма декомпозиции «Оформление заказов»

2.2.2 Диаграмма классов

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

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

Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени.

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

На рисунке 2.4 представлена диаграмма классов, описывающая логическую структуру базы данных, и имеет следующие классы:

• Users (Пользователи) – содержит всю информацию о пользователе системы;

• Zakazi (Заказы) – содержит информацию о заказе пользователя;

• Otziv (Отзыв) – содержит информацию об отзывах о проведенных мероприятиях от клиентов;

• Oplata (Оплата) – содержит информацию о способах оплаты;

• Working (Работник) – содержит информацию о работниках шоу-центра «Небесный луч»;

• WorkingZakaz (РаботникЗаказ) – промежуточный класс между классом «Работник» и классом «Заказ»;

• Show (Шоу) – содержит информацию о шоу-программах шоу-центра «Небесный луч»;

• Skidki (Скидки) – содержит информацию о скидках и акциях проводимых шоу-центром «Небесный луч»;

• News (Новости) – содержит информацию обо всех новостях шоу-центра «Небесный луч».

Рисунок 2.4 – Диаграмма классов описывающие структуру БД – логическая

На рисунке 2.5 представлена диаграмма классов, описывающая физическую структуру базы данных, и имеет следующие классы:

• Users (Пользователи) – содержит всю информацию о пользователе системы;

• Zakazi (Заказы) – содержит информацию о заказе пользователя;

• Otziv (Отзыв) – содержит информацию об отзывах о проведенных мероприятиях от клиентов;

• Oplata (Оплата) – содержит информацию о способах оплаты;

• Working (Работник) – содержит информацию о работниках шоу-центра «Небесный луч»;

• WorkingZakaz (РаботникЗаказ) – промежуточный класс между классом «Работник» и классом «Заказ»;

• Show (Шоу) – содержит информацию о шоу-программах шоу-центра «Небесный луч»;

• Skidki (Скидки) – содержит информацию о скидках и акциях проводимых шоу-центром «Небесный луч»;

• News (Новости) – содержит информацию обо всех новостях шоу-центра «Небесный луч».

Рисунок 2.5 – Диаграмма классов описывающие структуру БД – физическая

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

Рисунок 2.6 – Диаграмма классов, описывающая структуру клиентского ПО – логическая

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

Рисунок 2.7 – Диаграмма классов, описывающая структуру клиентского ПО – физическая

2.2.3 Диаграмма состояний

После создания одной или нескольких диаграмм вариантов использования системный аналитик с заказчиком определяют приоритетность проработки вариантов использования и детализируют их. Главная цель данной процедуры – поиск ответа на вопрос: «В процессе какого поведения система обеспечит необходимую функциональность?».

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

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

Характеристики

Список файлов ВКР