Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Базовые понятия объектно-ориентированного программирования).pdf

Варианты использования «Вернуть товар» позволяет клиенту вернуть не устраивающий его товар, если он, например, с производственным браком.

Вариант использования «Оформить заказ» позволяет клиентам сделать заказ по каталогу или в Интернете. Составными частями данного варианта использования является указание списка заказываемых товаров, информации об оплате заказа, адреса, по которому товар должен быть доставлен.

2.2 Моделирование системы с использованием диаграммы классов

Диаграммой классов (Class Diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Класс – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой.

В рамках данной системы будут присутствовать 3 класса: Клиент, Транспортная компания и Заказ.

Клиент приобретает товары, предварительно оплачивая заказ. Клиенту необходимо сообщить компании-посреднику свои данные, в частности адрес для доставки. Эти сведения необходимо отразить на разрабатываемой диаграмме, создав класс «Клиент», который будет иметь соответствующие атрибуты, и выполнять определенные операции.

Чтобы заказ был получен клиентом, необходимо его доставить по определенному адресу и в определенные сроки. Следовательно, на диаграмме необходимо указать класс «Транспортная компания», который будет также иметь соответствующие атрибуты, и выполнять определенные операции.

Каждый заказ заключает в себе определенное количество заказанных товаров. Кроме того каждый товар имеет свое наименование, цену и т.д. Поэтому на диаграмме необходимо отразить класс «Заказ» с присущими ему атрибутами. Классы «Клиент» и «Транспортная компания» будут связаны с ним отношением ассоциации.

Атрибут – это именованное свойство класса, включающее описание множества значений, которые могут принимать его отдельные экземпляры. Имя атрибута – это строка текста, однозначно его идентифицирующая. Оно является обязательным и выражается, как правило, в форме имени существительного. Важным аспектом при описании атрибута является его тип. Он представляет собой выражение, семантика которого определяется языком описания соответствующей модели. Общепринятые типы атрибутов – текстовый, целочисленный, логический (String, Integer, Boolean).

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

Таким образом, класс «Клиент» будет иметь следующие атрибуты:

• № Заказа: Integer
• ФИО: String
• Дата_рождения: Integer
• Телефон: Integer
• Адрес: Integer

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

• public (общий). Атрибут с таким квантором доступен из любого другого класса пакета, в котором определена данная диаграмма.
• protected (защищенный). Такой атрибут недоступен для всех классов за исключением подклассов данного класса.
• private (закрытый). Данный атрибут недоступен для всех без исключения классификаторов.

Класс «Клиент» на фрагменте диаграммы классов будет представлен следующим образом (рис. 2):

Клиент

+ № Заказа: Integer

+ ФИО: String

+ Дата_рождения: Integer

+ Телефон: Integer

+ Адрес: Integer

+ Оформлять_заказ()

+ Получать_заказ()

+ Возвращать_заказ()

Рисунок 2 – Класс «Клиент»

При логическом моделировании статической структуры информационной системы обработки заказов, диаграмма классов будет выглядеть следующим образом (рис.3):

Клиент

+ № Заказа: Integer

+ ФИО: String

+ Дата_рождения: Integer

+ Телефон: Integer

+ Адрес: Integer

+ Оформлять_заказ()

+ Получать_заказ()

+ Возвращать_заказ()

Транспортная компания

+ Название_фирмы: String

+ Телефон: Integer

+ Адрес: Integer

+ Срок доставки: Integer

+ Дата отправки: Integer

+ Доставлять_заказ()

+ Информировать_о_доставке()

оформляет доставляет

Заказ

+ № Заказа: Integer

+ Список_товаров: String

+ Стоимость_заказа: Integer

+ Оплата_заказа: String

+ Дата_оплаты: Integer

+ Дата_доставки: Integer

+ Информация_о_возвращенных_товарах: String

+ Выполняться()

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

3 Проектирование информационной системы обработки заказов

3.1 Диаграмма последовательности

Диаграммы последовательности относятся к числу пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов системы.

Диаграммой последовательностей (Sequence Diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений.

Для создания такой диаграммы надо, прежде всего, расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные – правее. Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже.

Под каждым из взаимодействующих объектов изображается линия жизни, отражающая существование объекта во времени. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create .

Большая часть объектов существует на протяжении всего взаимодействия, но они могут уничтожаться и во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy. В данном случае этот тип сообщения не используется.

На данной диаграмме последовательности будет отображаться вариант использования «Информировать о доставке». Тем самым объектами взаимодействия будут являться Транспортная компания, Форма информационной системы, БД заказов. Эти объекты выполняют определенные действия (инициированные сообщениями) в хронологическом порядке. Таким образом, при логическом моделировании поведения информационной системы бронирования туров, диаграмма последовательности будет выглядеть следующим образом (рис.4):

БД заказов

Форма

Тр. компания

открыть

указать № заказа

найти заказ по номеру

предоставить информацию о заказе

вписать новую информацию

создать новую запись

подтвердить создание

указать месяц доставки

указать день доставки

указать время доставки

завершить ввод

сохранить запись

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

3.2 Разработка физической модели проектируемой системы

Представление системы с точки зрения компонентов

Диаграммы компонентов (Component Diagram) применяются при моделировании статического вида системы с точки зрения реализации. Сюда относится моделирование физических сущностей, развернутых в узле, например, исполняемых программ, библиотек, таблиц, файлов и документов.

В UML определены 5 стандартных стереотипов, применимых к компонентам:

• executable (исполняемый) – определяет компонент, который может исполняться в узле;
• library (библиотека) – определяет статическую или динамическую объектную библиотеку;
• table (таблица) – определяет компонент, представляющий таблицу базы данных;
• file (файл) – определяет компонент, представляющий документ, который содержит исходный текст или данные;
• document (документ) – определяет компонент, представляющий документ.

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

• • • • Client.exe;
      • Posrednik.exe;
      • Catalog.htm;
      • Zakaz.mdb;
      • Address.mdb;
      • Money.mdb;
      • Dostavka.mdb.

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

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

Catalog.exe

Client.exe

Posrednic.exe

Money.mdb

Dostavka.mdb

Address.mdb

Zakaz.mdb

БД компании-посредника

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

Таким образом, рассмотрев диаграмму можно понять, что сотрудник компании-посредника Posrednic.exe использует базу данных, содержащую информацию о заказах Zakaz.mdb, сделанных клиентами, адресах клиентов Address.mdb, по которым нужно доставить товар. А также с базой данных банка Money.mdb, чтобы узнать достоверность информации об оплате заказа клиентом, и базой данных транспортных компаний Dostavka.mdb, услугами которых используется при доставке заказов клиентам.

Клиенты Klient.exe, могут зайти на сайт компании посредника, просмотреть перечень предлагаемых товаров и сделать заказ. Информация о заказе отправляется в базу данных посредника.

Представление системы с точки зрения размещения

На диаграмме развертывания или размещения (Deployment Diagram) показана конфигурация обрабатывающих узлов, на которых выполняется система, и компонентов, размещенных в этих узлах. Диаграммы размещения используются для моделирования статического вида системы с точки зрения развертывания.

Узел (Node) – это физический элемент, который существует во время выполнения и представляет вычислительный ракурс, обычно обладающий как минимум некоторым объемом памяти, а зачастую также и процессором. На них бывают представлены компоненты, каждый из которых должен быть размещен на каком-то узле.

В данном случае узлы представлены сервером компании-посредника, компьютером клиента и компьютером менеджера компании, а также сервер, на котором находится сайт компании. На данном сервере будет размещен компонент Catalog.htm.

На сервере компании-посредника будут размещены следующие компоненты: Zakaz.mdb, Address.mdb, Money.mdb, Dostavka.mdb. Каждый из вышеперечисленных компонентов выполняет определенную функцию: компонент Zakaz.mdb, который представляет собой базу данных с информацией о заказах и их конфигурации; компонент Money.mdb – база данных, в которой содержится информация об оплате заказов; компонент Address.mdb – база данных, в которой содержится информация об адресах клиентов; Dostavka.mdb – база данных, содержащая информацию о доставке заказов клиентам.

На узлах ПК Клиента и ПК Менеджера будет размещаться исполняемый модуль Client.exe и Posrednic.exe. ПК Клиента и сервер, на котором расположен сайт компании подключены к Интернет. А ПК менеджера компании и сервер объединены в локальную сеть, через которую можно получать информацию, выходить в Internet и вносить изменения в базы данных. При физическом моделировании информационной системы обработки заказов, диаграмма развертывания (размещения) будет выглядеть следующим образом (рис. 6):

Сервер Host

Internet

ПК Клиента

Сервер компании-посредника

ПК Менеджера

Локальная сеть компании

Address.mdb

Money.mdb

Dostavka.mdb

Zakaz.mdb

Klient.exe

Catalog.htm

Posrednik.exe

Рисунок 6 – Диаграмма размещения

4 Выбор модели жизненного цикла разработки информационной системы

4.1 Модели и стандарты жизненного цикл информационных систем

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

Существует несколько моделей и стандартов, в той или иной степени регламентирующих жизненный цикл, большинство из них относятся к заказному ПО и кроме непосредственно ЖЦ регламентируют также и процессы разработки:

• ГОСТ 34.601-90 распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий, этапов.
• Custom Development Method (и методика Oracle) по разработке прикладных информационных систем под заказ - конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle.
• Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования.