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

Введение.

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

1.1 Жизненный цикл информационных систем.

1.2 Каскадная модель жизненного цикла.

1.3 Поэтапная модель с промежуточным контролем.

1.4 Спиральная модель жизненного цикла.

1.5 Унифицированный язык моделирования UML.

1.5.1 Виды диаграмм.

1.5.2 Диаграммы вариантов использования.

1.5.3 Диаграммы классов.

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

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

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

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

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

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

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

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

Заключение.

Список литературы.

Приложение А.

Введение

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

В 70−80-х гг. при разработке ПО достаточно широко применялись структурные методы, базирующиеся на строгих формализованных методах описания ПО и принимаемых технических решений (в настоящее время такое же распространение получают объектно-ориентированные методы). Эти методы основаны на использовании наглядных графических моделей: для описания архитектуры ПО в различных аспектах (как статической структуры, так и динамики поведения системы) используются схемы и диаграммы. Наглядность и строгость средств структурного и объектно-ориентированного анализа позволяют разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этих методов и следование их рекомендациям при разработке конкретных ИС сдерживалось отсутствием адекватных инструментальных средств, поскольку при ручной разработке все их преимущества практически сведены к нулю. Поэтому возникла потребность в программно-технологических средствах специального класса — CASE-средствах, реализующих CASE-технологию создания и сопровождения ПО ИС. CASE-технология представляет собой совокупность методов проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования.

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

Цель работы: систематизировать знания в области организации и проектирования информационных систем, получить навыки моделирования автоматизированных информационных систем и ознакомиться с основными частями унифицированного языка моделирования UML.

Задача курсовой работы: получить навыки при моделировании информационной системы «Ресторан», используя средства языка моделирования UML.

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

1.1 Жизненный цикл информационных систем Прежде чем приступать к разработке диаграмм будущей ИС, необходимо ввести понятие жизненного цикла информационной системы и рассмотреть модели жизненного цикла программного обеспечения. Жизненный цикл информационной системы (ЖЦ ИС) — это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12 207 (ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission — Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12 207 базируется на трех группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

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

1.2 Каскадная модель жизненного цикла Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ: каскадная модель, поэтапная модель с промежуточным контролем и спиральная модель.

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

Модель предполагает следующие свойства взаимодействия этапов:

— модель состоит из последовательно расположенных этапов;

— каждый этап полностью заканчивается до того, как начнется следующий;

— этапы не перекрываются во времени: следующий этап не начинается до тех пор, пока не завершится предыдущий;

— возврат к предыдущим этапам не предусмотрен либо всячески ограничен;

— исправление ошибок происходит лишь на стадии тестирования;

— результат появляется только в конце разработки.

Рисунок 1 — Каскадная модель жизненного цикла.

Критерием появления результата при каскадной модели ЖЦ является отсутствие ошибок и точное соответствие продукта первоначальной спецификации.

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

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

* этапы работ выполняются в логичной последовательности;

* возможно жестко планирование сроков завершения работ и соответствующих затрат.

Недостатки каскадной схемы:

1. Существенная задержка с получением конечного результата.

2. Несоответствие разработанной системы ожиданиям заказчика.

3. Превышение сроков и сметы разработки или искажение требований к системе.

4. Примитивная автоматизация существующих производственных процессов.

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

1.3 Поэтапная модель с промежуточным контролем Поэтапная модель с промежуточным контролем еще известна как итерационная модель или «водоворот».

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

Модель характеризуется следующими свойствами взаимодействия этапов:

— модель состоит из последовательно расположенных этапов (точно так же, как и «водопад»);

— каждый этап имеет обратную связь с предыдущими этапами;

— исправление ошибок происходит на каждом из этапов, сразу при выявлении проблемы — это промежуточный контроль;

— этапы перекрываются во времени по причине наличия обратной связи: следующий этап не начинается, пока не завершится предыдущий; при первом проходе по модели вниз, как только обнаружена ошибка, осуществляется возврат снизу вверх к предыдущим этапам, которые повлекли ошибку. Таким образом, фактически этапы оказываются растянутыми во времени;

— результат появляется только в конце разработки, как и в модели «водопад».

Рисунок 2 — Поэтапная модель с промежуточным контролем.

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

1.4 Спиральная модель жизненного цикла Спиральная модель делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия. На нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта. В результате выбирается обоснованный вариант, который доводится до реализации.

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

Модель предполагает также свойства взаимодействия этапов:

— модель состоит из последовательно расположенных этапов (как и «водопад») в пределах одного витка спирали;

— внутри витка спирали этапы не имеют обратной связи. Анализ результата осуществляется в конце витка и инициирует новый виток спирали;

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

— этапы могут перекрываться во времени в пределах одного витка спирали;

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

— при переходе от витка к витку происходит накопление и повторное использование программных средств, моделей и прототипов;

— процесс ориентирован на развитие и модификацию системы в процессе ее проектирования, на анализ рисков и издержек в процессе проектирования.

Рисунок 3 — Спиральная модель жизненного цикла.

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

Специалистами отмечаются следующие преимущества спиральной модели:

* накопление и повторное использование программных средств, моделей и прототипов;

* ориентация на развитие и модификацию системы в процессе ее проектирования;

* анализ риска и издержек в процессе проектирования.

Именно поэтому спиральная модель служит в настоящее время основой для создания методологий проектирования систем.

1.5 Унифицированный язык моделирования UML.

Мощный толчок к разработке унифицированного языка объектно-ориентированного моделирования Unified Modeling Language (UML) дало распространение объектно-ориентированных языков программирования в конце 1980;х — начале 1990;х годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE — Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, OMT-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.

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

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software Corporation Айвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.

В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

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

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

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

UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

UML включает внутренний набор средств моделирования («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности:

строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

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

1.5.1 Виды диаграмм В UML выделяют девять типов диаграмм:

диаграммы классов (Class Diagrams);

диаграммы объектов (Object Diagrams);

диаграммы прецедентов/ вариантов использования (Use Case Diagrams);

диаграммы последовательностей (Sequence Diagrams);

диаграммы кооперации/ сотрудничества (Collaboration Diagrams);

диаграммы состояний (Statechart Diagrams);

диаграммы деятельности (Activity Diagrams);

диаграммы компонентов (Component Diagrams);

диаграммы развертывания/ размещения (Deployment Diagrams).

Рассмотрим некоторые из них.

1.5.2 Диаграммы вариантов использования Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:

описывает видимую пользователем функцию,.

может представлять различные уровни детализации,.

обеспечивает достижение конкретной цели, важной для пользователя.

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

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

На рис. 4 показано, что при исполнении прецедента «формирование заказа» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие — рассчитать стоимость заказа.

Рисунок 4 — Связи на диаграммах прецедентов.

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

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

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

Атрибут — это свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов.

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

На рис. 5 приведено графическое изображение класса «Заказ» в нотации UML.

Рисунок 5 — Изображение класса в UML.

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

public (общий) — любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;

protected (защищенный) — только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;

private (закрытый) — только данный класс может пользоваться этими свойствами. Обозначаются символом «-» .

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

instance (экземпляр) — у каждого экземпляра класса есть собственное значение данного свойства;

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

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

не содержащие ни одного экземпляра — тогда класс становится служебным (Abstract);

содержащие ровно один экземпляр (Singleton);

содержащие заданное число экземпляров;

содержащие произвольное число экземпляров.

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

Между классами возможны различные отношения, представленные на рис. 6:

зависимости, которые описывают существующие между классами отношения использования;

обобщения, связывающие обобщенные классы со специализированными;

ассоциации, отражающие структурные отношения между объектами классов.

Рисунок 6 — Отображение связей между классами.

Зависимостью называется отношение использования, согласно которому изменение в спецификации одного элемента (например, класса «товар») может повлиять на использующий его элемент (класс «строка заказа»). Часто зависимости показывают, что один класс использует другой в качестве аргумента.

Обобщение — это отношение между общей сущностью (родителем — класс «клиент») и ее конкретным воплощением (потомком — классы «корпоративный клиент» или «частный клиент»). Объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это свойство называют полиморфизмом. Класс, у которого нет родителей, но есть потомки, называется корневым. Класс, у которого нет потомков, называется листовым.

Ассоциация — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме. Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи.

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

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

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

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

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

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

вводятся строки заказа;

по каждой строке проверяется наличие товара;

если запас достаточен — инициируется поставка;

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

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

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

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

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

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

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

возможности оформления заказа через глобальную сеть Интернет;

быстрой обработки заказа;

оформления заказа на доставку продуктов компаниямипосредниками;

оплаты заказа через банк.

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

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

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

Диаграмма прецедентов или вариантов использования (Use Case Diagram) — для представления системы с точки зрения прецедентов и выявления требований к ней.

Диаграмма классов (Class Diagram) — для моделирования статической структуры системы и взаимосвязи между классами.

Диаграмма последовательности (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 — Диаграмма последовательностей.

Заключение

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

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

При разработке модели использовался унифицированный язык моделирования UML. UML — это совокупность нескольких видов диаграмм. Для проектирования информационной системы «Ресторан» использовались три вида диаграмм:

диаграмма вариантов использования;

диаграмма классов;

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

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

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

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

Список литературы

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

Вендров А. М. Проектирование программного обеспечения экономических информационных систем. — М.:Финансы и статистика, 2000.-187с.

Калянов Г. Н. CASE-технологии. Консалтинг при автоматизации предприятий.-М.:СИНТЕГ, 1997.-276с.

Леонтьев А. В. Самоучитель UML — Учебное пособие — СПб.: БХВ-Петербург, 2001. — 304с.

Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования; Пер. с.англ. — М.:Мир, 1999.-236с.

Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. — Киев: Диалектика, 1993.-193с.

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

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

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

Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (рис. 13):

Рисунок 13 — Диаграмма состояний объекта «заказ».

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

Основными элементами диаграмм деятельности являются (рис. 14):

Рисунок 14 — Диаграмма деятельности — обработка заказа.

овалы, изображающие действия объекта;

линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия «И»);

ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия «ИЛИ»);

стрелки — отражают последовательность действий, могут иметь метки условий.

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

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

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

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

устройства — узлы системы, в которых данные не обрабатываются.

процессоры — узлы системы, осуществляющие обработку данных.

Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML.

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

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

На рис. 15 показана упрощенная схема элементов фрагмента корпоративной системы. «Коробки» представляют собой компоненты — приложения или внутренние подсистемы. Пунктирные линии отражают зависимости между компонентами.

Рисунок 15 — Диаграмма компонентов фрагмента ИС.

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