Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Язык моделирования UML).pdf

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

Рисунок 3.3 – Диаграмма состояний сущности «Заказ»

Как видно из диаграммы «Заказ» может находится в 5 состояниях:

‑ Потенциальный заказ

‑ Отмененный заказ

‑ Оформленный заказ

‑ Оплаченный заказ

‑ Выданный заказ(расходованный)

3.5 Диаграмма последовательности

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

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

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

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

В нашей модели построено две таких диаграмма: первая описывает глобальный процесс – «Оформление заказа», вторая ‑ детализирует внутренний процесс «Построение ведомости»

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

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

Рисунок 3.5 – Построение кассовой ведомости

3.6 Диаграмма кооперации

Эта диаграмма в некотором смысле дублирует диаграмму последовательности выполнения. Но ее основной целью есть показать задействованные компоненты в ходе выполнения той или иной операции в системе. Для иллюстрации этого момента выполним диаграмму «оформления заказа», но уже в виде кооперационной диаграммы(collaboration)

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

3.7 Диаграмма деятельностей

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

Диаграмма деятельности наиболее походит на классическую блок-схему алгоритма. Основным элементом является деятельность. Интерпретация этого термина зависит от той точки зрения, с которой строится данная диаграмма. На концептуальной диаграмме деятельность – это некоторая задача, которую необходимо выполнить вручную или автоматизированным способом.

Рисунок 3.7‑ Диаграмма деятельности

Наличие на диаграмме «дорожек» позволяет сразу понять – какая часть системы отвечает за выполнение действия. Диаграмма может иметь множество альтернативных окончаний. В нашем случае их два: «отмененный заказ», «полученный заказ».

3.8 Диаграмма компонентов

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

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

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

Рисунок 3.8 – Компонентная диаграмма системы

Как видим «Отчеты», «Работа с БД», «Ведомости» отображены в виде закладок (Package) этим можно подчеркнуть что эти компоненты имеют набор различных функций. Кроме модулей основных функций на диаграмме присутствуют внешние компоненты и наборы данных (без которых система тоже работать не будет): это сама БД, драйвер для обслуживания принтера, драйвер(технология) для доступа к БД. Последним компонентом есть пользовательский интерфейс, в нашей разработке планируется как оконный (WinForms) интерфейс, но может быть и другим, например – Web ориентированная система.

3.9 Диаграмма размещения

Рисунок 3.9 – Диаграмма размещения

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

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

В случае разрабатываемой системы эта диаграмма имеет наиболее простой вид. На диаграмме показаны основные компоненты системы с аппаратной точки зрения. Имеем сервер с размещенной БД, это не обязательно какой то отличный от других ПК, просто на нем установлена БД что не исключает ситуации – на том же ПК установлен и клиент для доступа к БД. Кроме сервера показаны 3 клиента (количество не критично). Клиенты должны иметь принтер ‑ печать накладных и чеков и средство удаленного соединения с БД (в этом случае должна использоваться сетевая технология).

ЗАКЛЮЧЕНИЕ

Сегодня практически ни один крупный проект в сфере программной разработки не обходится без использования case-средств.

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

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

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

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

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

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Бабич А.В. UML: Первое знакомство :БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2008
2. Вендров А.М., CASE-технологии. Современные методы и средства проектирования информационных систем - М.: Финансы и статистика, 2007 г, 456 стр.
3. Вигерс Карл, Разработка требований к программному обеспечению, Пер, с англ. - М.: Издательско-торговый дом "Русская Редакция", 2008. -576с.: ил
4. Вичугова А. А., Вичугов В. Н., Цапко Г. П. МЕТОДЫ И СРЕДСТВА UML КАК ИНСТРУМЕНТЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Вестник науки Сибири / Выпуск № 2 (8) / 2013 ВАК РФ: 05.13.00 ‑ 2013
5. Гвоздева Т. В., Б. А. Баллод, Проектирование информационных систем, М, Издательство: Феникс, 2009 г., 512 стр.
6. Д. Марка, К. МакГоуэн Методология структурного анализа и проектирования SADT (Structured Analysis & Design Technique), М.: ‑ "Мета Технология", 1993
7. Емельянова Н. З., Партыка Т. Л., И. И. Попов, Проектирование информационных систем, М, Издательство: Форум, 2009 г., 432 стр.
8. Игошина Л.В. Программирование на языке высокого уровня. - Пенза: ПГУ, 2014. - с.5
9. Кознов Д.В. Основы визуального моделирования :БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2012
10. Котляров В. П., Т. В. Коликова, Основы тестирования программного обеспечения, Издательства: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2009 г., 288 стр.
11. С. В. Маклаков “ERwin и BPwin. CASE-средства разработки информационных систем” Москва «Диалг-МИФИ» 2001.
12. Мирошниченко Е.А. Технологии программирования. 2-е изд., испр. и доп. – Томск: Изд-во ТПУ, 2014. – 128 с.
13. Онлайн руководство по разработке программ с использованием VisualStudio, Электронный ресурс [режим доступа: https://msdn.microsoft.com], время доступа 24.09.2019
14. Пальчунов М.Н, CASE-технологии. Практические работы в среде Rational Rose – М.:; Бином-Пресс, 2014
15. Рожкова Е. CASE-средства. Сравнительный анализ // ARIS – Rational Rose. URL: http://ocnova.ru/?p=334 10.12.2012
16. Сафьянова Е.Н. Основы алгоритмизации и программирование: Учебное пособие. - Томск: Томский межвузовский центр дистанционного образования, 2012. - 111 с.
17. Создание функциональных, событийных моделей и моделей потоков данных в среде моделирования BPWin 4.0 Методическое пособие, Рязань ГОУ ВПО «МГУ ЭКОНОМИКИ, СТАТИСТИКИ И ИНФОРМАТИКИ (РЯЗАНСКИЙ ФИЛИАЛ)» 2007.
18. Трофимов С.А. CASE-технологии. Modelling in Rational Rose, ‑ М.:БИНОМ. Лаборатория знаний 2012
19. Унифицированный процесс разработки программного обеспечения - А. Якобсон, Г. Буч, Дж. Рамбо; Исд: Питер, 2002г
20. Хайдаров К.А. Объектно-ориентированное программирование, [элетронный ресурс], режим доступа: http://bourabai.kz/alg/oop.htm, дата доступа ­- 05.10.2019
21. Язык UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-ое издание - Джим Арлоу, Айла Нейштадт; Исд: Символ-Плюс, 2007
22. Язык UML. Проектирование систем реального времени, распределенных и параллельных приложений, 4-е издание - Хассан Гома; Исд: ДМК Пресс, 2012
23. Язык UML. Руководство пользователя, 2-е издание-ради Буч, Джеймс Рамбо, Ивар Якобсон; Исд: ДМК Пресс, 2007
24. Язык UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-ое издание - Джим Арлоу, Айла Нейштадт; Исд: Символ-Плюс, 2007
25. B. Douglas “Doing Hard Time: Developing Real_time Systems with UML, Objects, Frameworks, and Patterns”, Addison Wesley 1999.
26. H. Gomma, Designing Concurrent, Distribute, and Real-Time Appli- cations with UML, Addison Wesley 2000.
27. K., Young, R. Piggin, P . Rachitrangsan, “An Object-Oriented Ap- proach to an Agile Manufacturing Control System Design”, Int. Journal of Advanced Manufacturing Technology, Vol. 17, Springer- verlag 2001.