Разработка информационной системы интернет-магазина бытовой техники

3.2. Видение выполнения проекта и требования, предъявляемые к нему

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

      отдел доставки

      отдел продаж

      бухгалтерия

      склад

Не рассматривается в границах проекта автоматизация учета основных средств, расчета и начисления заработной платы, управления кадрами.

Требования к проекту

Требования к функциональным характеристикам

Система должна выполнять следующие функции:

         Формирование заказа;

         Подбор компьютеров в зависимости от требований клиента;

         Подсчёт стоимости выбранного товара;

         Доставка товара клиенту;

         Предоставление отчёта о сформированном заказе;

         Предоставление возможности просмотра состояния заказа.

Исходные данные:

                  Предлагаемый товар;

                  Адрес для доставки;

                  Метод оплаты.

Результаты:

                  Отчёт о сформированном заказе;

                  Состояние заказа;

                  Счёт-фактура;

                  Требование заказанной конфигурации;

                  Накладная;

                  Доставленный заказ.

Требования к надежности

Для обеспечения надежности информационной системы «Интернет

магазин» необходимо:

                  Проверка на заполнение всех полей формы заказа;

                  Проверка на корректность вводимых данных (адрес электронной

почты, наличие цифр в Фамилии и имени и т.д.)

Требования к техническим средствам

Система может работать как на IBM совместимых компьютерах, так и

на ноутбуках, нетбуках, сотовых телефонах с выходом в интернет.

Минимальная конфигурация:

Наличие выхода в интернет.

Требования к информационной и программной совместимости

Информационная система «Интернет-магазин компьютеров» может

работать под управлением любого семейства операционных систем.

Требования к программной документации

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

работе системы и подсказки пользователю.

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

                  Пояснительная записка;

                  Руководство пользователя.

3.3. Организационная диаграмма

Организационная диаграмма- это схематичное изображение сложных процессов и систем.

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

Графически связи обычно исходят из нижней грани верхнего прямоугольника (символизирует субъект управления), и входят в правую, левую, или верхнюю грань прямоугольника, символизирующего объект управления.

Организационная диаграмма делится на виды:

1) Дерево – специальный вид направленного графа;

2) Графы – структуры данных, состоящие из узлов связанных дугами;

3) Каждая дуга показывает однонаправленную связь между двумя узлами.

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

Ниже представлены правила непротиворечивости дерева целей:

      Правило непротиворечивости дерева целей 1: При чтении сверху вниз подцель должна отвечать на вопрос «что нужно сделать, чтобы реализовать цель предыдущего уровня?»;

      Правило непротиворечивости дерева целей 2: При чтении снизу вверх цель более высокого уровня должна отвечать на вопрос «для чего необходима цель непосредственно под ней?»;

      Правило непротиворечивости дерева целей 3: При чтении подцелей, необходимых для достижения одной цели, следует уточнить, все ли подцели действительно необходимы для ее достижения;

      Правило непротиворечивости дерева целей 4: При чтении подцелей, необходимых для достижения одной цели, следует уточнить, какие еще подцели этого уровня необходимы для ее достижения. [5]

          Предпочтительный формат дерева целей:

1) Глагол – действие;

2) Пояснение;

3) Объект.

Таким образом, любой объект с позиций системного подхода может быть структурирован на элементы (подсистемы). Выделение подсистем является творческой задачей автора. Инструменты создания диаграмм – помогут в визуализации творческой задачи.

3.4. Диаграмма прецедентов

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

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

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

Диаграммой прецедентов, или использования, называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения между ними.

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

Диаграммы прецедентов обычно включают в себя:

                   прецеденты;

                   актеры;

                   отношения зависимости, обобщения и ассоциации.

Как и все остальные диаграммы, они могут содержать примечания и ограничения. Иногда в диаграммы прецедентов помещают пакеты, применяемые для группирования элементов модели в более крупные блоки, а в ряде случаев и экземпляры прецедентов, особенно если надо визуализировать конкретную исполняемую систему.

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

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

                   для моделирования контекста системы. Моделирование контекста подразумевает, что мы обводим систему воображаемой линией и выявляем актеры, которые находятся за этой линией и взаимодействуют с системой. Диаграммы прецедентов нужны на этом этапе для идентификации актеров и семантики их ролей;

                   для моделирования требований к системе. Моделирование требований к системе предполагает указание на то, что система должна делать (с точки зрения внешнего наблюдателя), независимо от того, как она должна это делать. Диаграммы прецедентов Нужны здесь для специфицирования желаемого поведения системы. Они позволяют рассматривать всю систему как "черный ящик": вы видите все, что находится вне нее, наблюдаете за ее реакцией на события, но ничего не знаете о ее внутреннем устройстве. [21]

В приложении 2 приведена диаграмма прецедентов для

информационной системы «Интернет-магазин компьютеров». В данной системе можно выделить следующие субъекты и соответствующие им прецеденты:

             Web-страница – предоставляет пользователю список доступной

конфигурации (прецедент «Выбор товара»), подсчитывает стоимость выбранного товара («Подсчёт стоимости товара»), участвует в оформлении заказа («Оформление заказа»);

             Работник магазина – проверяет, оплачен ли заказ («Проверка

оплаты»);

             Склад – «Сбор товара»;

             Отдел доставки;

             Курьер – доставляет товара («Доставка»);

             Клиент – выбирает товар, оформляет заказ и оплачивает его.

Описание прецедентов представлено в приложении 3.

3.5. Формирование физической диаграммы и построение диаграмм действий

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

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

Физическая диаграмма представлена в приложении 4.

Формирование списка бизнес-процессов изображена в приложении 5..

          Бизнес-процесс «Оформление заказа».

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

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

Диаграммы действий описывают последовательность действий в системе с помощью действий. Диаграммы действий являются специальной формой диаграмм состояний, только в основном содержат действия.

Диаграммы действий подобны процедурным диаграммам потока, с той разницей, что все действия напрямую присоединены к объектам.

Диаграммы действий всегда ассоциируются с классами, методами или вариантами действий.

Диаграммы действий поддерживают как последовательные, так и параллельные действия. Параллельное выполнение представляется с помощью пиктограмм Fork/Wait. Для действий, выполняющихся параллельно, порядок, в котором они выполняются, не имеет значения (они могут выполняться одновременно или друг за другом).

Действие представляет собой один шаг процесса. Одно действие представляет одно состояние системы с внутренним действием и, как минимум, с одним результатом действия. Действия могут иметь более одного результата, если они происходят при разных условиях.

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

Существует несколько вспомогательных элементов в UML, которые не имеют реального семантического значения для модели, но помогают внести ясность в диаграмму. Перечислим их:

                   Текстовые строки

                   Текстовые заметки и якоря

                   Контейнеры

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

Текстовые заметки следует использовать для добавления более детальной информации об объекте или о специфической ситуации. Текстовые заметки могут быть прикреплены к элементам UML.

Контейнеры являются свободными прямоугольниками, которые могут быть использованы для группирования элементов диаграмм. Они не несут никакой смысловой нагрузки для модели. [3]

          Бизнес-процесс «Склад».

Функционирование склада предполагает оказание услуг клиентам. Клиент – тот объект, для которого, собственно, функционирует предприятие, а склад, в частности. После заказа товара, информация о товаре поступает на склад, и если данный товар имеется в наличии, то  курьер доставляет товар по назначенному адресу.