Менеджер автосалона делает запрос на наличие авто на складе автосалона, и при его отсутствии посылает запрос на комплектацию поставки менеджеру завода изготовителя. После подтверждения, менеджер автосалона посылает заявку на поставку авто менеджеру транспортно-экспедиционной компании.
Управления передается управляющему облачная БД, который формирует поставку авто (createPutevList) и посылает сообщение (SendMsg) о том что создана поставка. Вызывается форма подтверждения заказа (OrderConfirmation).Менеджер автосалона делает отметки в объекте поставка (Delivery) облачной БД о датах прохождения (ListPoint). Объект (Delivery) обращается к объектам Car (getCar) для того, чтобы получить информацию об автомобилях входящих в поставку. Также объект поставка (Delivery) расширен объектом путевой лист (ListPoint), который содержит информацию о точках и датах прохождения поставки. Пользователь может просматривать эту информацию (ShowList). После проверки платежа процесс поставки завершается и заказ закрывается (CloseOrder). Компонентное представление ИИСПри проектировании больших систем может оказаться, что система должна быть декомпозирована на несколько сотен или даже тысяч компонентов, диаграмма компонентов (Component diagram) позволяет не потеряться в обилии модулей и их связей. Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей. Обзор существующих методов решения поставленной задачи и их сравнительный анализ был проведен в разделе 1.2 настоящего документа.
В результате анализа для реализации была выбрана модель, основанная на облачных технологиях, как наилучшим образом отвечающая целям разработки и позволяющая реализовать бизнес требования с наибольшей эффективностью. Диаграмма потоков данных облачной части системы представлена на рисунке 5.Рис.. Диаграмма потоков данных проверки доступных действий пользователей ИИСВ соответствии с этой диаграммой можно выделить четыре архитектурных компонента облачной части системы:
Компонент инициализации приложения. Данный компонент принимает HTTP-данные от веб-сервера и выделяет из них данные программного окружения, в котором осуществлен запуск приложения, и управляющие данные. Вместе с данными пользователя они образуют среду функционирования приложения. Компонент управления действием. Данный компонент отвечает за проверку управляющих данных и за запуск нужного действия. Компонент-действие. Данный компонент отвечает за непосредственную обработку запроса, а также за проверку входных пользовательских данных. Он может обращаться к базе данных и выполнять другие действия, связанные с обработкой запроса. В этом компоненте сосредоточены все вычислительные алгоритмы. Компонент представления результатов. Данный компонент отвечает за представление результатов пользователю системы. Ниже приводится более формализованное представление этой модели в виде UML-диаграммы компонентов:
Рис.. Диаграмма компонентов: модель организации работы модуля облачного хранения данных с клиентскими частями системы.
В состав ИИС входит: модуль обеспечения соединений, который обеспечивает связь между клиентскими частями системы и модулем обеспечения облачного хранения данных и расшифровывает команды, полученные от клиентских частей. Модуль доступа, который обеспечивает аутентификацию пользователей и разделение прав пользователей. Модуль доступа получает данные из баз данных прав. База данных прав, хранит в себеданные аутентификации пользователей и права на доступ к данным облака. Модуль выдачи информации обеспечивает выдачу информации о доступныхданных и возможностях добавления, изменения или удаления информации. Эти данные храниться в БД поставок. Допускается создание изменение и удаление путевых листов поставок автомобилей, в соответствии с правами пользователя. Сетевая организация системы:
Система выполнена в формате клиентского веб-приложения с возможностью сохранять данные о процессе поставки в облако. Пользователь работает с локальной копией поставки, с возможностью обновления/выгрузки данных. Пользователи, подключенные к облаку имеют 2 группы прав «с возможностью создавать и редактировать новую поставку» и «с возможностью просматривать созданные поставки».Файловая организация системы:
Система выполнена в виде отдельных модулей взаимосвязанных между собой. Все модули выполнены в виде отдельных dll библиотеках с документированным функционалом. Расчетное ядро выполнено в виде «связок» библиотека dll и файла БД, где одна связка — один справочник, БД реализована с использованием SQLite. Для реализации команд разработан протокол обмена данных, в котором команды представлены в формате: {код команды} - {текст команды}, в коде команды мы храним числовые номера команд. При этом данные команды записываются в формате JSON. Разработка программного продукта сводится к разработке перечисленных выше компонентов и к их интеграции в цельную систему. Для демонстрации динамики функционирования системы отображения изменения состояния поставки мы использовали диаграмму автоматов, изображенную на рисунке 6. Рис. .Диаграмма автоматов — отслеживание поставки.
Пользователь посылает HTTPPOST запрос (шаг 1). Запрос проходит обработку в модуле контроля данных, создается окружение и контекст. Подключается контроллер модуля, в контроллере модуля определяется, какую информацию может получить пользователь. На шаге 2 осуществляется передача данных в метод, в методе осуществляется проверка правильности (валидности) данных, и если они удовлетворяют условиям, то выполняются шаги 3 и 4 по сохранению данных в облачной БД. Шаг 5 отвечает за возвращение управления от Модели к Контроллеру, который должен решить, куда перенаправить пользователя и собственно осуществить это на шаге 6. Шестой шаг можно считать конечным в работе системы, 7-ой шаг является концептуальным, он позволяет показать, что после перенаправления система продолжит работать.
Заключение
.
В современных условиях руководителям предприятий, организаций приходиться иметь дело с таким большим количеством информации, она так быстро меняется, что её часто становится просто невозможно обрабатывать «вручную». Кроме того, на больших предприятиях с большими оборотами продукции существует необходимость учёта и контроля большого объёма финансовой, производственной, закупочно-сбытовой, маркетинговой информации. Для этого создаются автоматизированные системы для сбора, обработки и хранения информации. Такие информационные системы должны облегчить процесс работы с информацией, циркулирующей на предприятии. В результате выполненной работы можно сделать следующие выводы: при проектировании и разработке приложения был выполнен полный цикл проектирования приложения от постановки задачи до введения выходного результата на исполнение и эксплуатацию. Разработанноеприложение упрощает процедуру формирования поставки и делает процесс поставки прозрачным для покупателя, то есть покупатель в любой момент времени может узнать место нахождения партии поставки автомобиля и дату прибытия в автосалон. В ходе выполнения курсового проекта был проведен анализ предметной области и сформирована функциональная спецификация интегрированной информационной системы, базирующейся на облачной технологии. На основе определенной спецификации был реализован комплекс ULMдиаграмм: диаграмма прецедентов функционирования системы с точки зрения внешних актеров;
диаграммы деятельности процесса поставки автомобиля;
Выполнена реализация вариантов использования в терминахвзаимодействующих объектов и представляющую собойнабор диаграмм:
диаграмма классов, реализующих прецедент «поставкаавто"диаграмма кооперации объектов процесса поставки автодиаграммы последовательности и деятельности, отражающих взаимодействиеобъектов в процессе реализации прецедента;
Разделены классы по пакетам и построена диаграмму компонентов серверной части системы. Построена диаграмма состояний для отслеживания состояния поставки. По сравнению с ранее реализованными проектами в данной области задач разработанный комплекс моделей в большей степени учитывает реально существующие потребности пользователей, в первую очередь, клиентов, планирующих покупку автомобиля, что является его оригинальной чертой и выгодно отличает его от аналогов.
Список литературы
Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е издание/ Пер. с англ.; Под общей редакцией проф. С.
Орлова — СПб.: Питер, 2006. — 736 с.: ил. Колесников, А. Модель SaaS — в мире и в России. / А. Колесников.
// BYTE Россия: Журнал для ИТ-профессионалов. — 2008. — №.
10. Риз Д. Облачные вычисления. СПб: БХВ-Петербург, 2011. 288 с. Богсс У., Богсс М. UML и R ational Rose.
— М.: Изд-во ЛОРИ, 2008. — 600с. Буч Г., Максимчук Р., Энгл М., Янг Б., Коналлен Д., Хьюстон К. Объектно-ориентированный анализ и проектирование с примерами приложений.
— М.: «Вильямс», 2010. — 720 с. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя, — М.: ДМК Пpecc, 2007.
— 496 с. Ларман К. Применение UML и шаблонов проектирования. — М.: Издательский дом «Вильямс», 2008.
— 736с. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектноориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2007. -.
366 с. Леоненков А. В. Самоучитель UML. — СПб.: БХВ-11етербург, 2001. — 304 с. Арлоу Д., Нейштадт A. UML 2 и унифицированный процесс.
Практический объектно-ориентированный анализ и проектирование. — М.: Символ-Плюс, 2007. — 624 с. Петрова С. Ю. Проектирование, эксплуатация и модернизация информационных систем. — Великий Новгород: Нов.
ГУ им. Ярослава Мудрого, 2005. — 31 с. Леоненков А. В. Самоучитель UML 2. Санкт-Петербург: БХВ-Петербург, 2007. — 554 с. Приложение 1Диаграмма UseCase: функционирование системы с точки зрения внешних актеров.
Приложение 2Диаграмма деятельности: процесс поставки автомобиля.
