Обеспечение продаж автосалона

Она, в свою очередь, используется серверной подсистемой пользовательского интерфейса, основная задача которой — прием запросов пользователей с последующей передачей обертке базы данных и передача результатов обработки запросов пользователям. Подсистема пользовательского интерфейса также реализуется на выбранном языке программирования. Наконец, компоненты «интерфейс клиента», «интерфейс менеджера» и «интерфейс администратора» формируют запросы к подсистеме пользовательского интерфейса и принимают от нее результаты обработки запросов. Эти компоненты реализуются с помощью гипертекстовых технологий: HTML, JavaScript и других. Разработка программного продукта сводится к разработке перечисленных выше компонентов и к их интеграции в цельную систему. Построим диаграмму потоков данных верхнего уровня (Приложение 3), соответствующую этой модели, показанной на рисунке 4. Представленная диаграмма отображает полный цикл передачи обработки данных на верхнем уровне: от запроса пользователя до SQL-запросов к базе данных. Из рисунка видно, что в системе реализуется двойная проверка входных данных: во-первых, интерфейсом оператора, во-вторых, подсистемой пользовательского интерфейса. Такой подход обусловлен несколькими причинами. Кроме того, ряд проверок может потребовать обращения к базе данных системы, детальной описание этих процессов показаны с помощью диаграмм деятельности в Приложении 4. Моделирование реализации — архитектура серверной части системы

В соответствии с представленной в приложении 3 диаграмме потоков данных системы, серверная часть системы состоит из подсистемы пользовательского интерфейса и программной обертки БД, которые производят контроль входных данных, преобразование их в программные объекты, формирование запросов к базе данных, обработку и передачу результатов клиентской части системы. Рассмотрим более подробно, уточним и дополним архитектуру серверной части системы, алгоритмы ее работы, потоки данных. Диаграмма потоков данных серверной части системы показана в Приложении 5. В соответствии с этой диаграммой можно выделить четыре архитектурных компонента серверной части системы:

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

5.Диаграмма компонентов серверной части системы

Рассмотрим более подробно компоненты системы. При рассмотрении, акцентируем внимание на наиболее сложном и важном для компании и клиентов прецеденте — «Оформить заказ». Прецедентоформления заказа (случай, при котором клиент подтверждает заказ)

имеет следующую форму деятельности, рисунок 6. А структурное описание этого прецедента показано на рисунке 7. Покупатель выбирает опцию «Оформить заказ» (place order), при этом вызывается некоторый объект PlaceOrderОткрывается форма ввода личных данных покупателя и его кредитной карты (EnterPersonalInformation), на ней покупатель вводит свое имя, адрес, телефон, адрес электронной почты и кредитные данные. Рис. 6. Диаграмма деятельности — «Оформление заказа"Рис.

7. Диаграмма классов — «Оформление заказа"Информация принимается и открывается форма подтверждения заказа (ConfirmOrder), покупатель подтверждает, что согласен с реквизитами заказа (confirm order), детали заказа сохраняются для дальнейшего использования (save the details). Управления передается некоторому управляющему объекту (PlaceOrderManager), который обращается к внешней кредитной системе (Credit System) для проведения платежа. PlaceOrderManager посылает сообщение (create order) создать объект Заказ (Order)Вызывается форма подтверждения заказа (OrderConfirmation). Объект Заказ (Order) обращается к объектам Товар (Item) для того, чтобы получить информацию о товарах и создает заказ. После этого процесс завершается. Для отражения взаимодействия объектов в процессе реализации прецедента строим диаграмму последовательности процесса успешного оформления заказа, рисунок 8.Рис. 8. Диаграмма последовательности — «Оформление заказа"Задача оформления заказа является тривиальной, поэтому подробное ее рассмотрение опускается; отметим лишь, что она организована в виде мастера оформления заказа с пятью шагами:

шаг 1: выбор автомобиля;

шаг 2: ввод данных;

шаг 3: подтверждение данных заказа;

шаг 4: оформление заказа;

шаг 5: активация заказа. Для демонстрации динамики функционирования системы заказов мы использовали диаграмму автоматов, изображенную на рисунке 9. Рис.

9. Диаграмма автоматов — «Оформление заказа"Заключение

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

Количество уровней зависит от сложности системы и выбранного способа её декомпозиции на подсистемы. Объектно-ориентированный метод уменьшает размер программных систем за счет повторного использования общих механизмов. Системы построенные с помощью этого метода более гибкие и проще эволюционируют. И конечно же несомненным достоинством можно считать то, что объектно-ориентированный подход отражает топологию новейших языков высокого уровня, таких как Smalltalk, Object Pascal, C++, CLOS и Ada. В ходе выполнения курсового проекта был проведен анализ предметной области и сформирована функциональная спецификация информационной системы «Обеспечение продаж автосалона». На основе определенной спецификации был реализован комплекс ULMдиаграмм: диаграмма прецедентов функционирования системы с точки зрения внешних агентов второго уровня детализации для информационной системы «Обеспечение продаж автосалона»; диаграммы деятельности: процесс заказа автомобиля; работа клиентского приложения с базой данныхдиаграмма потоков данных системы и диаграмма потоков данных серверной части системы

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

диаграмм классов, реализующих прецедент «Оформление заказа"диаграммы последовательности и деятельности, отражающих взаимодействиеобъектов в процессе реализации прецедента;

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

Список литературы

Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е издание/ Пер. с англ.; Под общей редакцией проф.

С. Орлова — СПб.: Питер, 2006. — 736 с.: ил. Богсс У., Богсс М. 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Диаграмма деятельности: процесс заказа автомобиля

Приложение 2Диаграмма UseCase: функционирование системы с точки зрения внешних агентов второго уровня детализации

Приложение 3Диаграмма потоков данных системы

Приложение 4Диаграммы деятельности: работа клиентского приложения с базой данныха) Ввод нового документаб) Поиск документав) Удаление документа

Приложение 5Диаграмма потоков данных серверной части системы