Построение объектной модели информационной системы «Поставка автосалону автомобиля, выбранного покупателем»

Менеджер автосалона делает запрос на наличие авто на складе автосалона, и при его отсутствии посылает запрос на комплектацию поставки менеджеру завода изготовителя. После подтверждения, менеджер автосалона посылает заявку на поставку авто менеджеру транспортно-экспедиционной компанииУправления передается управляющему облачная БД, который формирует поставку авто (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 и Rational 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Диаграмма деятельности: процесс поставки автомобиля