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

Введение

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

На сегодняшний день особенно интенсивно в процессе разработки информационных систем применяется унифицированный язык моделирования 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 к любому количеству. Атрибутивная и ссылочная части классов оптимизированы для представления на основе реляционных СУБД.