ИС дилерской фирмы

Введение

              В данной курсовой работе рассмотрен вопрос разработки объектно-ориентированной модели информационной системы дилерской фирмы. Многие современные информационные системы представляют собой сложные комплексы взаимодействующего ПО, таким образом, одним из основных требований к современным ИС является соответствующим образом выполненная проектная документация. В свою очередь объектно-ориентированный подход позволяет во многом упростить понимание сложных систем и процесс их проектирования. Целью курсовой работы является освоение методики объектно-ориентированного проектирования на практике.

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

              1 Краткая характеристика предметной области

1.1 Общая характеристика дилерской фирмы как объекта  хозяйственной деятельности

Дилерская фирма представляет собой хозяйствующий субъект, предоставляющий услуги посреднического характера, а именно, принимающий заказы клиентов на поставку товаров, и выполняющий их доставку. Численность штата работников: директор, бухгалтер, секретарь, четверо водителей-грузчиков. Дилерская фирма арендует помещения и инвентарь по необходимости. Основная профильная область - торговля бытовыми товарами. Общий документооборот ведется с использованием IBM-совместимых ПК под управлением ОС Windows, MS Office, 1С, с последующей печатью на бумажные носители.

1.2 Обоснование актуальности разработки объектно-ориентрованной модели информационной  подсистемы  дилерской фирмы

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

1.3 Формулировка задач проектирования

              Основной задачей проектирования является разъяснение протекающих процессов средствами разработки объектно-ориентированной модели информационной системы дилерской фирмы, включающей в себя следующие подзадачи:

- cоздание диаграммы прецедентов

- cоздание диаграммы последовательности

- cоздание диаграммы классов

- добавление деталей к описаниям операций и определение атрибутов классов, добавление связей между классами

- создание диаграммы состояний для классов

- создание диаграммы компонентов

Выводы: 1) Дилерская фирма представляет собой небольшую и достаточно оптимальную организацию. 2) Общий документооборот ведется с использованием наиболее распространенных в настоящее время технологий. 3) Администрация предприятия осознает возможность улучшения качественно-количественных показателей работы, и предполагает выполнить эту задачу используя современные подходы в области информационных технологий.

              2 Создание диаграммы прецедентов

              Диаграмма прецедентов (вариантов использования) приведена на рисунке 1.

Рисунок 1 - Диаграмма прецедентов (вариантов использования)

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

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

              3 Создание диаграммы последовательности

              Диаграмма последовательности приведена на рисунке 2.

Рисунок 2 - Диаграмма последовательности

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

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

              Выводы: Работа с договорами осуществляется секретарем. Представленная диаграмма не учитывает необходимость проверки существования договора. Секретарь может создавать как типовые, так и детализированные договоры. Типовые данные договора доступны в объекте "Выбор варианта договора". Объект Детализация договора представляет форму со всеми необходимыми элементами управления (ввода и редактирования) для детализации типового договора. Объект "Договор" представляет собой хранилище всех атрибутов конечного клиентского договора.

              4 Создание диаграммы классов

              Диаграмма классов используемых при оформлении заказа приведена на рисунке 3.

Рисунок 3 - Диаграмма классов

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

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

5 Добавление деталей к описаниям операций и определение атрибутов классов. Добавление связей между классами

              Рассматриваемые в данном разделе классы представлены на диаграмме классов приведенной на рисунке 3. Каждый из 3 классов (Заказчик, Договор, Заказ), в соответствии с парадигмой ООП обладает уникальным набором свойств (атрибутов) и методов - процедур обработки (управления). Ввиду достаточно простой объектной структуры и соответственно нецелесообразности использования дополнительных подходов к структуризации, все методы проектируются как публичные. Событийная составляющая модели в данном случае не рассматривается. Все классы не жестко взаимосвязаны на основе ссылок. Атрибутивная и ссылочная части оптимизированы для представления на основе реляционных СУБД.

              Класс Заказчик представляет собой описание соответствующего типа объектов, которые в свою очередь предназначены для определения реальных заказчиков с которыми работает фирма. Данный класс имеет следующие атрибуты: id, name, address, tel - идентификатор заказчика, имя, адрес и телефон соответственно. Идентификатор заказчика представляет собой уникальное в рамках коллекции заказчиков целочисленное определение. На основе данного определения на уровне приложения идентифицируются (различаются) отдельные экземпляры объектов типа Заказчик. Атрибут name (наименование заказчика) представляет собой свойство строкового типа и определяет официальное наименование заказчика - наименование юридического либо физического (фамилия, имя, отчество) лица (клиента). Атрибут address (адрес заказчика), подобно атрибуту name, является свойством строкового типа, но в свою очередь определяет официальный адрес заказчика. Атрибут tel (телефон) также подобен атрибутам name и address (представляет собой свойство строкового типа), однако определяет телефонный номер заказчика. Класс Заказчик также определяет 2 метода: new() и edit(). Метод new() представляет собой конструктор объектов, а метод edit() - процедуру редактирования свойств заказчика.

              Класс Договор предназначен для порождения одноименных объектов с целью определения и работы с реальными договорами о поставке. Каждый объект типа Договор обладает следующими атрибутами: id, name, content, zak. Атрибут id представляет собой целочисленный уникальный идентификатор договора. Атрибут name - наименование договора (свойство строкового типа). Атрибут content - содержание договора (свойство типа текст). Атрибут zak - целочисленный идентификатор заказчика (ссылка на соответствующий объект Заказчик). Класс Договор также определяет 2 метода: new() и edit(). Метод new() представляет собой конструктор объектов, а метод edit() - процедуру редактирования свойств (атрибутов) договора.

              Класс Заказ представляет собой шаблон одноименных объектов предназначенных для работы с реальными заказами клиентов. Каждый объект этого типа обладает следующим набором атрибутов: id, tovar, kolvo, dog. Атрибут id представляет собой идентификатор заказа - уникальное в рамках коллекции заказов целочисленное определение. Атрибут tovar также представляет собой идентификатор, однако в данном случае - товара. Этот атрибут имеет целочисленный тип. Атрибут kolvo представляет собой свойство заказа указывающее на количество единиц заказываемого товара. Атрибут dog является ссылкой на соответствующий договор, т.е. имеет тип идентификатора договора и определяется его значением. Класс Заказ также определяет 3 метода: new(), edit() и delete(). Метод new() представляет собой конструктор объектов, метод edit() - процедуру редактирования свойств (атрибутов) заказа, а метод delete() предназначен для его (заказа) удаления.

              Между классами установлены следующие связи: между Заказчик и Договор - 1 к любому количеству, между Договор и Заказ - 1 к любому количеству. Такое положение обусловлено следующим: отправной точкой в работе секретаря с клиентом является оформление клиента (заказчика). Далее с заказчиком может быть заключено несколько договоров на поставку, по каждому из договоров может быть оформлено произвольное количество заказов.

              Выводы: Все атрибуты классов имеют либо целочисленный, либо строковый тип, т.е. определяются базовыми, и являются окончательными в иерархии типов. Все методы классов объявлены как публичные ввиду достаточно простой объектной структуры. Каждый класс имеет в своем составе методы new() и edit() - конструктор объекта и процедура его модификации соответственно. Класс Заказ также определяет метод delete() предназначенный для удаления объектов. Связи между классами выполнены в виде ссылок, тип связей следующий: между Заказчик и Договор - 1 к любому количеству, между Договор и Заказ - 1 к любому количеству. Атрибутивная и ссылочная части классов оптимизированы для представления на основе реляционных СУБД.

6 Создание диаграммы состояний для классов

Диаграмма состояний для классов представлена на рисунке 4.

Рисунок 4 - Диаграмма состояний

              Описание: На данной диаграмме приведены состояния для классов Заказчик, Договор - вверху, Заказ - внизу. Классы Заказчик и Договор имеют одинаковые диаграммы состояний, а именно, они могут быть либо определены, либо не существовать вовсе. Каждый из объектов этого класса в процессе своего существования может изменяться, что отражено состоянием Изменение. Диаграмма состояний для класса Заказ похожа на диаграмму для Заказчик и Договор, однако несколько сложнее за счет дополнительного состояния - Удаление. Это состояние введено для отражения процесса корректного удаления Заказа. Корректное удаление заказа включает в свой состав все действия необходимые для соблюдения целостности структуры данных информационной системы, после чего происходит уничтожение самого объекта (высвобождение занимаемой памяти).

              Выводы: Диаграммы состояний для классов достаточно просты. Классы Заказчик и Договор имеют одинаковые диаграммы состояний, для них определены два состояния: Определен и Изменение - это соответственно статическое состояние, и состояние изменения атрибутов. Класс Заказ обладает третьим состоянием - Удаление. Это состояние введено для отражения процесса корректного удаления Заказа по необходимости соблюдения целостности структуры данных информационной системы в целом.

7 Создание диаграммы компонентов

Диаграмма компонентов приведена на рисунке 5.

Рисунок 5 - Диаграмма компонентов

              Описание: На диаграмме компонентов представлена организация приложения Diler.exe. Это приложение является классическим объектно-ориентированным приложением C++. Каждый используемый класс имеет свою непосредственную реализацию в виде файла *.cpp (исходного кода классов) и соответствующего заголовочного файла, которые подключены к основному приложению. В файлах исходного кода классов реализована их полная структура и функциональность. В заголовочных файлах также описаны глобальные определения, константы и др. служебная информация.

              Выводы: Для управления классами Заказчик и Договор может быть использована единая динамическая схема в основном приложении. Процедура "Корректное удаление" может быть оформлена в виде деструктора соответствующих классов. Структура компонентов Diler.exe представляет собой классическое объектно-ориентированное приложение C++. Глобальные определения, константы и другая служебная информация описаны в заголовочных файлах. Структура приложения Diler.exe достаточно проста.

              Заключение

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

Список использованных источников информации

1               Соммервилл И. Инженерия программного обеспечения. - М.: Издательский дом «Вильямс», 2002. – 624 с.

2               Мацяшек Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. - М.: Издательский дом «Вильямс», 2002. – 432 с.

3               Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. – М.: ДМК, 2000.- 432 с.

4               Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. – М.: Издательство «Лори», 2000.- 581 с.

5               Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. – СПб.: Питер, 2002.- 432 с.

6               Калянов Г.Н. CASE-технологии. Консалтинг при автоматизации бизнес-процессов. - М.: Горячая линия - Телеком, 2000.- 412 с.

7               Петров В.Н. Информационные системы. - СПб.: Питер, 2002. – 688 с.

8               Смирнова Г. Н. и др. Проектирование экономических информационных систем. - М.: Финансы и статистика, 2001. – 512 с.

9               Трофимов С.А. CASE-технологии: практическая работа в Rational Rose – М.: ЗАО «Издательство БИНОМ», 2001. – 272 с.

10          Ларман К. применение UML и шаблонов проектирования: Пер. с англ. – М.:  Издательский дом «Вильямс», 2001. – 496 с.

11          ГОСТ  2.105-95  ЕСКД. Общие требования к текстовым документам.

12          ГОСТ  2.004-88  ЕСКД. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах ввода  ЭВМ.

13          ГОСТ 2.104-68 ЕСКД. Основные надписи.

14          ГОСТ 2.106-68 ЕСКД. Текстовые документы.

15          ГОСТ 2.301-68 ЕСКД. Форматы.

16          ГОСТ 2.316-68 ЕСКД. Правила нанесения на чертежах надписей, технических требований и таблиц.

17          ГОСТ 2.321-84 ЕСКД. Обозначения буквенные.

18          ГОСТ 2.38-90 УСД. Система организационно-распорядительной документации. Требования к оформлению документов.

19          ГОСТ 7.32-91 Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления.

20          ГОСТ 21.1101-92 СПДС. Основные требования к рабочей документации.

Приложение А

Условные графические обозначения

Таблица 1 - Обозначения объектов

Таблица 2 - Виды отношений вариантов использования

Таблица 3 - Значения множественности