Методология организации проектирования информационных систем

Рисунок 7  иллюстрирует модель формирования заказа.

Рисунок 7 – Свойства ассоциации.

Каждый заказ может быть создан единственным клиентом (множественность роли 1..1). Каждый клиент может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть «привязан» к определенному клиенту.

Такого рода ассоциация является простой и отражает отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Если приходится моделировать отношение типа «часть-целое», то используется специальный тип ассоциации — агрегирование. В такой ассоциации один из классов имеет более высокий ранг (целое — класс «заказ») и состоит из нескольких меньших по рангу классов (частей — класс «строка заказа»). В UML используется и более сильная разновидность агрегации — композиция, в которой объект-часть может принадлежать только единственному целому. В композиции жизненный цикл частей и целого совпадают, любое удаление целого обязательно захватывает и его части.

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

 

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

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

• вводятся строки заказа;
• по каждой строке проверяется наличие товара;
• если запас достаточен — инициируется поставка;
• если запас недостаточен — инициируется дозаказ (повторный заказ).

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

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

 

 

 

2. Практическая часть. Моделирование информационной системы «Ресторан» в сфере общественного питания

2.1. Описание деятельности ресторана с целью выявления автоматизируемых процессов

 

Ресторан, для которого создается ИС – необычный ресторан, специализирующийся на моментальном обслуживании клиентов. Он специализируется на обслуживании праздников, банкетов, свадеб, семейных праздников и другое.  Каждый месяц ресторан публикует каталог (меню), который рассылается клиентам и другим заинтересованным лицам. Клиенты делают заказ, направляя в компанию перечень блюд с информацией об оплате. Заказ можно оплатить как в ресторане, так и в банке. Клиенты могут отказываться от заказов, оплачивая, возможно, при этом некоторые издержки. Часть клиентов заказывает товары через Интернет. Компания пользуется услугами различных компаний-посредников для доставки требуемых продуктов. Система должна отслеживать заказ от момента его получения до выполнения.

 

2.2. Постановка задачи для моделирования информационной системы «Ресторан»

 

Реализовать модель информационной системы «Ресторан», выполняющей функции:

• возможности оформления заказа через глобальную сеть Интернет;
• быстрой обработки заказа;
• оформления заказа на доставку продуктов компаниями- посредниками;
• оплаты заказа через банк.

 

2.3. Разработка диаграмм информационной системы «Ресторан»

2.3.1. Диаграмма вариантов использования для информационной системы «Ресторан»

 

При моделировании информационной системы «ресторан», будут использоваться следующие виды диаграмм:

1. Диаграмма прецедентов или вариантов использования (Use Case Diagram) – для представления системы с точки зрения прецедентов и выявления требований к ней.
2. Диаграмма классов (Class Diagram) – для моделирования статической структуры системы и взаимосвязи между классами.
3. Диаграмма последовательности (Sequence Diagram) – для моделирования процессов сообщения между объектами.

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

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

В данном случае роль Актера (Actor) будут играть Клиент, Банк, Сайт. Каждый вариант использования показывает, как конкретный актер использует систему. Необходимо рассмотреть и виды отношений, которыми они связаны.

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

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

Компания-посредник – компания, которая доставляет исходные продукты.

Банк – организация, которая предоставляет услуги оплаты заказа.

Сайт – рекламное агентство в Интернете, где опубликован каталог (меню) ресторана.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 9 - Диаграмма вариантов использования.

 

Краткое описание вариантов использования, изображенных на рисунке.

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

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

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

Вариант использования «Доставить заказ» и «Информировать о доставке» позволяет компании-посреднику доставить товары и проинформировать об этом ресторан.

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

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

 

2.3.2. Диаграмма классов для информационной системы «Ресторан»

 

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

Рисунок 10 - Класс «Клиент».

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

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

2.3.3. Диаграмма последовательности для информационной системы «Ресторан»

 

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

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

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

Центром моделируемой информационной системы является заказ ресторану на обслуживание мероприятий, поэтому все операции будут направлены на выполнение этого заказа. На основании этого можно построить диаграмму классов, оказанную на рис. 12.

 

 

 

 

 

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

 

Заключение

 

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

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