Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ АГЕНТСТВО МОРСКОГО И РЕЧНОГО ТРАНСПОРТА

ФЕДЕРАЛЬНОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ВОДНЫХ КОММУНИКАЦИЙ

Кафедра прикладной информатики в экономике

Курсовой проект

По дисциплине «Проектирование информационных систем»

На тему: «Моделирование деятельности работы интернет-магазина»

Выполнила:

Романова Е.С.

Санкт-Петербург 2014 год

Введение

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

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE).

Объектно-ориентированная методология (ООМ) создания автоматизированных систем состоит из следующих частей:

· объектно-ориентированный анализ (OOA),

· объектно-ориентированное проектирование (OOD),

· объектно-ориентированное программирование (OOР).

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

OOР - совокупность идей и понятий, определяющая стиль написания программ, в которой основными концепциями являются понятия объектов и классов.

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

Основные понятия объектно-ориентированного проектирования: объект, класс, атрибут, операция, полиморфизм, наследование, компонент, связь.

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

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

Атрибут - поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный).

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

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

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

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

Между элементами объектной модели существуют различные виды связей:

· ассоциация - это семантическая связь между классами;

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

· зависимость - связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе;

· обобщение - связь «тип - подтип».

Метод объектно-ориентированного проектирования основывается на:

· модели построения системы как совокупности объектов абстрактного типа данных;

· модульной структуре программ;

· нисходящем проектировании, используемом при выделении объектов.

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

Инкапсуляция.

Концепция сокрытия в как бы "капсуле" всей информации об объекте, то есть объединение в некое целое данных и процедур (методов) их обработки. Единицей инкапсуляции в OOD является объект, в котором содержатся и данные состояния объекта и сообщения, которые объект может обрабатывать. Т.е. инкапсуляция означает сочетание структур данных с методами их обработки в абстрактных типах данных - классах объектов.

Наследование.

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

Полиморфизм.

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

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

· объект описывается как модель некоторой сущности реального мира;

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

Выделено четыре этапа объектно-ориентированного проектирования:

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

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

· разработка диаграмм объектов, показывающих взаимосвязи с другими объектами;

· разработка внутренней структуры программного продукта.

Развитие методик и языков ООАП. Назначение языка UML, причины его возникновения.

Отдельные языки объектно-ориентированного моделирования стали появляться в период между серединой 1970-х и концом 1980-х годов, когда различные исследователи и программисты предлагали свои подходы к ООАП. В период между 1989-1994 гг. общее число наиболее известных языков моделирования возросло с 10 до более чем 50. Многие пользователи испытывали серьезные затруднения при выборе языка ООАП, поскольку ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем.

К середине 1990-х некоторые из методов были существенно улучшены и приобрели самостоятельное значение при решении различных задач ООАП.

Наиболее известными в этот период становятся:

· Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch Lite (позже - Booch'93).

· Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling Technique - ОМТ (позже - ОМТ-2).

· Метод Айвара Джекобсона (Ivar Jacobson), получивший название Object-Oriented Software Engineering - OOSE.

Каждый из этих методов был ориентирован на поддержку отдельных этапов ООАП. Например, метод OOSE содержал средства представления вариантов использования, которые имеют существенное значение на этапе анализа требований в процессе проектирования бизнес-приложений. Метод ОМТ-2 наиболее подходил для анализа процессов обработки данных в информационных системах. Метод Booch'93 нашел наибольшее применение на этапах проектирования и разработки различных программных систем.

Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML(Unified Modeling Language) , эти документы послужили своеобразным катализатором для широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.

В это же время стало ясно, что некоторые компании и организации видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP (Real-time Transport Protocol). Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.

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

В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG (Object Management Group). Соответствующая группа специалистов обеспечивает публикацию материалов, содержащих описание последующих версий языка UML и запросов предложений RFP (Request for Proposal) по его стандартизации. Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3.

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

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

Подводя итог анализу методологии ООАП и исторических предпосылок появления UML, можно утверждать следующее. Имеются все основания предполагать, что в ближайшие годы язык UML в его современном виде станет основой для разработки и реализации во многих перспективных инструментальных средствах: в RAD (Rapid Application Development)-средствах визуального и имитационного моделирования, а также в CASE-средствах самого различного целевого назначения. Более того, заложенные в языке UML потенциальные возможности могут быть использованы не только для объектно-ориентированного моделирования систем, но и для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические комплексы.

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

· информационные системы масштаба предприятия;

· банковские и финансовые услуги;

· телекоммуникации;

· транспорт;

· оборонная промышленность, авиация и космонавтика;

· розничная торговля;

· медицинская электроника;

· наука;

· распределенные Web-системы.

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

Унифицированный язык моделирования UML стал основой для целого спектра различных средств поддержки разработки программного обеспечения - CASE-средств (Computer-Aided Software Engineering).

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

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

К появлению CASE-технологии способствовали и такие факторы, как:

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

· широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

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

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Помимо этого, CASE-средства можно классифицировать по категориям, применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

К основным достоинствам CASE-средств можно отнести:

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

· широкое разнообразие в практике внедрения различных организаций;

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

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

Но все же грамотное, продуманное и обоснованное использование CASE-технологии способно принести следующие выгоды:

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

· приемлемый уровень отдачи от инвестиций в CASE-средства.

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

IBM Rational Rose - популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Инструментальное средство IBM Rational Rose расширяет возможности моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

Являясь простым и мощным решением для визуальной разработки информационных систем любого класса, Rational Rose позволяет создавать, изменять и проверять корректность модели. Rational Rose объединяет команду разработчиков на базе универсального языка моделирования UML, который определяет стандартную графическую символику для описания архитектуры ПО. Любые участники проекта - аналитики, специалисты по моделированию, разработчики и другие - могут использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта.

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

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

Rational Rose является ведущим инструментом визуального моделирования в программной индустрии, благодаря полноценной поддержке UML и многоязыковой поддержке командной разработки. Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС.

Достоинства продукта Rational Rose

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

· удобная навигация между элементами модели при помощи "инспектора проекта";

· хранение результатов проектирования в виде единой модели;

· поддержка работы над проектом группы разработчиков;

· данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а также на языке Java;

· на всех этапах разработки применяется язык UML, и проект программного средства представляет собой единую модель;

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

· в наибольшей степени подходит для разработки крупных информационных систем, так как реализует большую часть функций ARIS и ERwin/BPwin. И т.д.

Недостатки продукта Rational Rose

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

· сложность самого языка UML также накладывает определенные ограничения на привлечение к работам над проектами непрофессионалов,

· нельзя показать и удалить неиспользуемые объекты в отличие от BPWin;

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

· не поддерживает функционально-стоимостной анализ;

· нет возможности отобразить потоки данных между объектами или процессами.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

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

· диаграммы состояний;

· диаграммы сценариев;

· диаграммы модулей;

· диаграммы процессов;

· спецификации классов, объектов, атрибутов и операций

· заготовки текстов программ.

1. Описание предметной области

В данном курсовом проекте была описана деятельность интернет-магазина.

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

Интернет-магазин позволяет пользователям онлайн, в своём браузере, сформировать заказ на покупку, выбрать способ оплаты и доставки заказа, оплатить заказ, а также осуществляет доставку товара. Управление интернет-магазином -- это процесс планирования, координации и контроля бизнес-процессов в интернет-магазине. Суть данного процесса состоит в оптимальном использовании как интернет ресурсов, так и трудовых ресурсов.

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

программный rational rose архитектурный

2. Моделирование проектируемой системы

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества так называемых вариантов использования, предоставляемых системой множеству актеров или сущностей, взаимодействующих с системой. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.

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

На рисунке, представленном ниже, изображена диаграмма вариантов использования для интернет-магазина. Клиент - все люди, желающие воспользоваться услугами интернет-магазина; интернет-магазин - предоставляет онлайн услуги по продаже товара. Работники склада - проверяют наличие товара на складе и передают заказ курьеру. Курьер - доставляет заказ клиенту. Электронная система - проводит платежи.

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

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

Тем временем работник склада передаёт заказ курьеру, а курьер доставляет товар клиенту.

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

2.2 Диаграмма классов

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

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

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

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

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

Работники - включает в себя всех работников магазина: администратор, электронная система, работники склада, курьер. Главным атрибутом класса является должность.

Администратор (Case worker) - является ключевой фигурой, так как взаимодействует с актерами в бизнес системе. Главным атрибутом является ФИО.

Электронная система - принимает платежи клиентов и информирует администратора о результате.

Работники склада - проверяют наличие товара и передают заказ в службу доставки. Главным атрибутом является: ФИО.

Курьер - принимает заказ от работников склада и доставляет заказ клиенту. Главным атрибутом является: ФИО.

Каталог (Business Entity) - перечень всего товара, представленного в интернет-магазине, и его цена. Главным атрибутом класса является: наименование товара.

Заказ - в заказе указывается только номер заказа, дата заказа и номер клиента. Главный атрибут: номер заказа.

Состав заказа- номер заказа, код товара и его количество. Главный атрибут: код товара.

Диаграмма классов представлена на рисунке 2.

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

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

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

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

На рисунке 3 представлена диаграмма последовательности. Клиент зашёл на сайт интернет-магазина. Просмотрев каталог, он формирует заказ. Далее он заказывает товар, и электронная система предъявляет ему счёт. Клиент оплачивает счёт с помощью электронных денег. Через электронную систему курьер узнаёт о заказе и доставляет товар клиенту.

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

2.4 Диаграмма кооперации

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

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

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

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

2.5 Диаграмма состояний

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

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

Рисунок 4 - Диаграмма коопераций

На рисунке представлена диаграмма состояний, которая отображает деятельность администратора видео-проката. Заметим, что любая деятельность администратора начинается из состояния « Ожидание».

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

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



Рисунок 5 - Диаграмма состояний

2.6 Диаграмма деятельности

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

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

На рисунке 6 представлена диаграмма деятельности для клиента видео-проката в процессе выдачи фильма.

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

Рисунок 6 - Диаграмма деятельности

Заключение

Для разработки курсового проекта использовалось объектно-ориентированное case-средство Rational Rose, которое позволило наглядно описать модель графическим способом.

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

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

1. Конспект лекций по дисциплине “Проектирование информационных систем”.

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

3. Интернет Университет Информационных Технологий http://tver.mesi.ru/e-lib/res/652/index.html.

Размещено на Allbest.ru

...