Преподаватель который помогает студентам и школьникам в учёбе.

Применение объектно-ориентированного подхода при проектировании информационной системы

Содержание:

Введение

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

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

Объект исследования: объектно-ориентированного подхода при проектировании ПО

Цель работы: Рассмотреть основные понятия объектно-ориентированного подхода при проектировании ПО

Задачи:

Рассмотреть ориентированного подхода при проектировании ПО;
Познакомится с унифицированным языком моделирования UML
Смоделировать информационную систему посредством использования программного обеспечения IBM Rational Rose

Структура данной работы: введение, глава 1 теоретическая часть, глава 2 практическая часть, заключение, список литературы.

Глава 1. Объектно-ориентированный подход

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

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

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

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

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

Основными механизмами объектной модели являются:

абстрагирование (abstraction);
инкапсуляция (encapsulation);
наследование (inheritance);
полиморфизм (polymorphism);
модульность (modularity);
иерархия (hierarchy).

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

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

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

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

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

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

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

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

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

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

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

1.2 UML - унифицированный язык объектно-ориентированного моделирования ИС

В 90-е годы появилось большое количество различных нотаций, поддерживающих объектно-ориентированную методологию проектирования. Самые популярные - ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсону). Каждая из них имела свои преимущества. Методика ОМТ отличалась хорошими средствами анализа и слабыми сторонами в проектировании, а методика Booch 1991, наоборот, более подходила для проектирования, чем для анализа. В методике OOSE основное внимание уделено развитым средствам поведенческого анализа, а в других областях отмечено много недостатков.

Спустя некоторое время Буч опубликовал второе издание, в котором собрал лучшие идеи и решения в области анализа, предлагавшиеся в том числе Рамбо и Джекобсоном. В свою очередь, Рамбо написал серию статей, известных как методика ОМТ-2, куда вошли предложения Буча в области проектирования. Перечисленные методики были достаточно похожи, но отличались разными нотациями - один и тот же символ имел в них различные значения. Например, закрашенный круг был индикатором множественности в методике ОМТ и символом агрегата в нотации Буча. Вы, наверное, слышали фразу «война методов», употреблявшуюся в период, когда класс обозначался либо в виде облака, либо в виде прямоугольника? Трудно понять, что же лучше.

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

Универсальный язык UML - это попытка стандартизировать инструменты анализа и проектирования семантических моделей, синтаксических нотаций и диаграмм. Первая общедоступная версия (0.8) появилась в октябре 1995 года. Джекобсон и другие разработчики предложили несколько вариантов, которые были реализованы в последующих двух версиях (0.9 - в июле и 0.91 - в октябре 1996 года). Версия 1.0 была представлена для стандартизации в ассоциацию Object Management Group (OMG) в июле 1997 года. Дополнительные улучшения сделаны в версии 1.1, которая вышла в сентябре того же года, а в ноябре UML был утвержден ассоциацией OMG в качестве стандартного языка моделирования

рис. №16 Составные части языка UML

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

диаграммы вариантов использования (use case diagrams) - для моделирования бизнес-процессов организации (требований к системе);
диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;
диаграммы поведения системы (behavior diagrams):
диаграммы взаимодействия (interaction diagrams):
диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;
диаграммы деятельностей (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
диаграммы реализации (implementation diagrams):
диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.

1.3 Диаграммы вариантов использования (модели прецедентов)

Поведение разрабатываемой системы (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (действующих лиц или актеров - actors) и связи между прецедентами и актерами (диаграммы прецедентов - use cases diagrams). В нотации UML их чаще называют диаграммами вариантов использования. Основная задача модели прецедентов или диаграмм вариантов использования - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

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

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

только снабжать информацией систему;
только получать информацию из системы;
снабжать информацией и получать информацию из системы.

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

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

В языке UML актер изображается в виде фигуры человечка —

рис. №17 Нотация языка UML для изображения актера

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

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

Чтобы выделить прецеденты для системы, можно использовать следующую серию вопросов:

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

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

Рис. №18 Нотация языка UML для прецедента

Между актером и прецедентом может существовать ассоциативное отношение. Такой тип связи часто называют коммуникативной ассоциацией (communicate association), потому что она отражает связь между актером и прецедентом.

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

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

Отношение дополняет (extend relationship) применяется для отражения:

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

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

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

Пример отношений прецедентов показан на рис. 3.8.

рис. №19 Отношения прецедентов

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

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

Пример такой диаграммы для банковского автомата (Automated Teller Machine, ATM)

рис. №20 Пример use cases диаграммы

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

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

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

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

Прежде чем определить диаграммы классов введем несколько понятий.

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

Состоянием (state) объекта называется одно из условий, в которых он может находиться. Состояние системы обычно меняется во времени и определяется набором свойств, называемых атрибутами (attribute), значений свойств и отношений между объектами. Например, объект учебный курс (CourseOffering) в системе регистрации учебных курсов может находиться в одном из двух состояний: открыт для записи или закрыт для записи. Если количество студентов, зарегистрировавшихся на курс, меньше десяти, запись на курс продолжается. После регистрации десятого студента она прекращается.

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

Индивидуальность (identity) означает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта. Например: Алгебра 101, секция 1 и Алгебра 101, секция 2 - два объекта в системе регистрации курсов. Хотя они оба являются учебными курсами, каждый из них уникален.

Класс (class) - это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.

Класс-сущность (entity class) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы. Такие классы обычно не зависят от окружения, то есть они нечувствительны к взаимодействию окружающей среды с системой. Следовательно, они не зависят от приложения и могут использоваться в различных приложениях.

Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы предоставляют интерфейс для пользователя или другой системы (то есть для актера). Они составляют внешне зависимую часть системы и используются для моделирования интерфейсов системы. Граничные классы также используются для обеспечения связи с другими системами.

Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, ревизующих заложенное в них поведение. Управляющие классы можно представить, как классы, «исполняющие» прецедент и определяющие его динамику. Они обычно зависят от приложения.

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

Диаграммы классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов. Например, счет Джо - это объект. Типом такого объекта можно считать счет вообще, то есть "Счет" (account) - это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Класс Account содержит идентификационный номер клиента и действия, проверяющие его. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или кооперативных диаграмм. Диаграмма классов для варианта использования "Снять деньги" показана на рис. 21.

рис. № 21 Диаграмма классов для варианта использования

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

Card Reader (устройство для чтения карточек). Account (счет), ATM Screen (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй - его атрибуты. Атрибут - это некоторая информация, характеризующая класс. Например, у класса Account (счет) имеется три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). У класса Account имеется четыре операции: Open (открыть). Withdraw Funds (снять деньги), Deduct Funds (вычесть сумму денег из счета) и Verify Funds (проверить наличие денег).

Связывающие классы линии отражают взаимодействие между классами. Так, класс Account связан с классом ATM Screen (экран ATM), потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не сообщаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыты (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance являются закрытыми атрибутами класса Account. Кроме того, операции Deduct Funds и Verify Funds также закрыты для этого класса.

Диаграммы взаимодействия

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

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

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

Информационное (informative) сообщение - сообщение, снабжающее объект-получатель некоторой информацией для обновления его состояния.

Сообщение-запрос (interrogative) - сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

Императивное (imperative) сообщение - сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams). Рассмотрим диаграммы последовательности.

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

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

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

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения, этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" (account) и инициализирует экран ATM. Экран, в свою очередь, запрашивает у Джо его регистрационный номер. Он вводит число 1234. Экран проверяет номер у объекта "Счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и он выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо выбирает 20 долларов. Затем экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "Счет Джо". Во-первых, осуществляется проверка, что на этом счету лежит, по крайней мере, 20 долларов. Во-вторых, из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию выдать 20 долларов наличными, а также чек. Наконец, все тот же объект "Счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку.

Итак, данная диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо 20 долларов. Глядя на эту диаграмму, пользователи могут увидеть специфику их работы. Аналитики увидят последовательность (поток) действий, разработчики - объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию, и, кроме того, можно показать само-делегирование (self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Диаграммы последовательности существенно помогают разобраться в процессе поведения системы. [2]

Глава № 2. Проектирования информационной системы

Рассмотрим пример проектирования информационной системы. В качестве задачи стоит разработка системы проката велосипедов. В качестве среды разработки будем использовать программное обеспечение от компании IBM Rational Rose.

Рассмотрим основные моменты:

Rational Rose представляет собой CASE средство проектирования и разработки информационных систем и программного обеспечения для управления предприятиями. Как и другие CASE средства (ARIS, BPwin, ERwin) его можно применять для анализа и моделирования бизнес процессов. Первая версия этого продукта была выпущена компанией Rational Software. В дальнейшем Rational Rose был куплен IBM.

Принципиальное отличие Rational Rose от других средств заключается в объектно-ориентированном подходе. Графические модели, создаваемые с помощью этого средства, основаны на объектно-ориентированных принципах и языке UML (Unified Modeling Language). Инструменты моделирования Rational Rose позволяют разработчикам создавать целостную архитектуру процессов предприятия, сохраняя все взаимосвязи и управляющие воздействия между различными уровнями иерархии. Моделирование бизнес процессов в Rational Rose выполняется за счет применения различных аспектов. Каждый из этих аспектов концентрирует внимание на определенных характеристиках и возможностях процессов.

К таким аспектам относятся:

2.1 Аспекты моделирования Rational Rose

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

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

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

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

За счет применения различных аспектов Rational Rose предоставляет пользователям (бизнес аналитикам, инженерам, техническим специалистам и руководителям) возможность создавать, анализировать, изменять и управлять моделями, используя единый объектно-ориентированный подход и единый язык моделирования. [3]

2.3 Характеристика предметной области

Общая характеристика

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

Актуальность разрабатываемой информационной системы

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

Процесс моделирования

Создание диаграммы прецедентов (use case)

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

Рис. №1 Диаграмма прецедентов

На рисунке №1 представлена диаграмма претендентов. Опишем состав диаграммы:

Основные действующие лица (актеры)

Клиент

Менеджер по аренде

Кассир

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

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

Создание диаграммы взаимодействия (последовательности).

Рис. №2 Диаграмма взаимодействия

На приведенной выше диаграмме выделены следующие объекты:

- Клиент и его взаимодействие с магазином велопроката:

Регистрация, заключение договора, выбор велосипеда, оплата услуг.

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

- Кассир взаимодействует с клиентом на этапе оплаты услуг.

Создание диаграммы классов

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

Рис. №3 Диаграмма классов

На приведенной выше диаграмме выделены следующие объекты(классы):

- Клиент, данный класс имеет следующие атрибуты: ID номер (индивидуальный номер клиента), ФИО, Адрес, Телефон и Почта.

- Менеджер по аренде данный класс имеет следующие атрибуты:

ID номер (индивидуальный номер клиента), ФИО, Телефон.

- Кассир данный класс имеет следующие атрибуты:

ID номер (индивидуальный номер клиента), ФИО, Телефон.

-БД Велопрокат данный класс имеет следующие атрибуты:

ID номер (индивидуальный номер клиента), Марка, Модель.

Заключение

При выполнении курсовой работы был изучен и рассмотрен объектно-ориентированный подход к проектированию информационной системе. Была рассмотрена история возникновения данного подхода и основные тезисы такие как: Объект, Класс, Абстрагирование, Инкапсуляция, Наследование и т.д. Так же был рассмотрен унифицированный язык объектно-ориентированного моделирования ИС UML, его история и основные моменты при работе с данным языком. Во время выполнения курсовой работы была изучена среда разработки информационных систем IBM Rational Rose. Во второй главе курсовой работы в качестве примера использования объектно-ориентированного подхода была разработана информационная система проката велосипедов. Были разработаны следующие диаграммы:

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

- Диаграмма взаимодействия

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

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

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

1 - Вендров А.М. Проектирование программного обеспечения экономических информационных систем. «Финансы и статистика» / 2006 - 163 с.,

2 - Ипатова Э.Р., Ипатов Ю.В. Методология и технологии системного проектирования информационных систем. «Флинта» 2008 г.- 79 c.,

3 – Rational Rose [Электронный ресурс]. – Режим доступа: http://www.kpms.ru/Automatization/Rational_Rose.htm Заглавие с экрана. – (Дата обращения: 15.05.2019).

4 - Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: М.: ДМК, / 2000.- 432 с., ил.

5 - Трофимов С. А. Case-технологии: практическая работа в Rational Rose / С. А. Трофимов. - М.: ЗАО «Издательский дом БИНОМ» / 2001. – 372 c.

6 - Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. – М.: Издательство «Лори», 2000.- 581 с., ил.