ИЗУЧЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ

Расчетно-пояснительная записка к курсовой работе

по дисциплине “Объектное моделирование информационных систем”

ЯГТУ 230201.65-029 КР

Отчет выполнил

студент гр. ЭИС-34

(               )Юдин А.Н.

__________

2012

Реферат

34 с., 8 рис., 14 табл., 6 источников.

{ИНФОРМАЦИОННАЯ СИСТМЕА, ОБЪЕКТНОЕ МОДЕЛИРОВАНИЕ, ЯЗЫК UML,  МОДЕЛЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, CASE-СРЕДСТВА, RATIONAL ROSE}

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

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

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

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

Содержание

Введение                                                                                                      4

1 Изучение особенностей объектно-ориентированного подхода к   

проектированию ИС                                                                                         5

1.1 Методологии разработки и проектирования ИС                                 5

1.2 Особенности объектно-ориентированного подхода к

проектированию и разработке ИС                                              7

   1.3 Основы языка UML                                                                                9

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

   1.3.2 Диаграмма классов                                                              12

   1.3.3 Диаграммы кооперации и последовательности                 13

   1.3.4 Диаграммы состояний и деятельности                      15

   1.3.5 Диаграммы компонентов и развертывания                       17

2 Анализ и построение модели информационной системы,

предназначенной для управления турникетом метро                    19

   2.1 Глоссарий                                                                                    20

   2.2 Концептуальная модель системы                                                    21

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

             2.2.2 Диаграмма классов                                                         24

   2.3 Анализ поведения системы                                                     27

             2.3.1 Диаграммы кооперации и последовательности                27

             2.3.2 Диаграммы состояний и деятельности                     29

   2.4 Физическая модель                                                                 31

Заключение                                                                                           33

Список использованных источников                                                   34

Введение

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

За последнее десятилетие сформировалось новое направление в программотехнике – CASE (Computer-Aided Software/System Engineering). CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE – это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.

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

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

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

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

     1 Изучение особенностей объектно-ориентированного подхода к проектированию ИС

1.1 Методологии разработки и проектирования ИС

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

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

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

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

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

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

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

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

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

1.2 Особенности объектно-ориентированного подхода к проектированию и разработке информационных систем

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

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

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

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

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

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

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

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

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

1.3 Основы языка UML

Для описания, визуализации и документирования объектно-ориентированных систем в процессе их анализа и проектирования был предложен унифицированный язык моделирования UML (Unified Modeling Language).

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

Назначение языка UML:

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

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

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

- описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП;

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

- интегрировать в себя новейшие и наилучшие достижения практики ООАП;

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

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

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

- вариантов использования (use case diagram);

- классов (class diagram);

- кооперации (collaboration diagram);

- последовательности (sequence diagram);

- состояний (statechart diagram);

- деятельности (activity diagram);

- компонентов (component diagram);

- развертывания (deployment diagram).

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

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

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

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

Вариант использования (use case) — внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с актерами.

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

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

Отношение (relationship) — семантическая связь между отдельными элементами модели. В языке UML имеется несколько стандартных видов отношений:

- ассоциации (association relationship) - специфицирует семантические особенности взаимодействия актеров и вариантов использования;

- включения (include relationship) - указывает на то, что заданное поведение для одного варианта использования включается последовательность поведения другого варианта использования;

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

- обобщения (generalization relationship) - указывает на родительский вариант использования.

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

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

Класс (class) — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов. Конкретный класс (concrete class) — класс, на основе которого могут быть непосредственно созданы экземпляры или объекты. Абстрактный класс (abstract class) — класс, который не имеет экземпляров или объектов.

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

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

Стереотип – это механизм, позволяющий категоризовать классы. Некоторые из стереотипов используются во время анализа, другие после спецификации используемого языка программирования. Управляющие классы (Control class) отвечают за координацию действий других классов. Пограничными классами (boundary class) называются классы, расположенные на границе системы со всем остальным миром. Классы-сущности (entity) содержат информацию, хранимую постоянно. Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели.

1.3.3 Диаграммы кооперации и последовательности

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

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

Объект(object) — сущность с хорошо определенными границами и индивидуальностью, которая инкапсулирует состояние и поведение. Активный объект (active object) имеет собственный процесс управления и может инициировать деятельность по управлению другими объектами. Мультиобъект(multiobject) представляет собой множество анонимных объектов, которые могут быть образованы на основе одного класса.

Сообщение (message) — спецификация передачи информации от одного элемента модели к другому с ожиданием выполнения определенных действий со стороны принимающего элемента. В языке UML определены следующие стереотипы сообщений:

- <<call>>(вызвать) – сообщение, требующее вызова операции или процедуры объекта-получателя.

- <<return>>(возвратить) – сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту.

- <<create>>(создать) – сообщение, требующее создания другого объекта для выполнения определенных действий.

- <<destroy>>(уничтожить) – сообщение с явным требованием уничтожить соответствующий объект.

- <<send>>(послать) – обозначает посылку другому объекту сигнала, который асинхронно инициируется одним объектом и принимается (перехватывается) другим.

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

Линия жизни объекта (object lifeline) - вертикальная линия на диаграмме последовательности, которая представляет существование объекта в течение определенного периода времени.

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

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

1.3.4 Диаграммы состояний и деятельности

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

Диаграмма состояний (statechart diagram) - диаграмма, которая представляет конечный автомат. Главное назначение - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение моделируемой системы в течение всего ее жизненного цикла.

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

Действие (action) - спецификация выполнимого утверждения, которая образует абстракцию вычислительной процедуры.  Входное действие (entry action) - действие, которое выполняется в момент перехода в данное состояние. Действие выхода (exit action) - действие, производимое при выходе из данного состояния. Внутренняя деятельность (do activity) - выполнение объектом операций или процедур, которые требуют определенного времени.

Переход (transition) - отношение между двумя состояниями, которое указывает на то, что объект в первом состоянии должен выполнить определенные действия и перейти во второе состояние. Если параллельный переход имеет две или более исходящих из него дуг, то его называют разделением (fork). Если же он имеет две или более входящие дуги , то его называют слиянием (join).

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

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

Сторожевое условие (guard condition) - логическое условие, записанное в прямых скобках и представляющее собой булевское выражение.

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

Состояние деятельности (activity state) - состояние в графе деятельности, которое служит для представления процедурной последовательности действий, требующих определенного времени.

Состояние действия (action state) - специальный случай состояния. Состояние действия не может иметь внутренних переходов, поскольку оно является элементарным. Состояние под-деятельности (subactivity state) - состояние в графе деятельности, которое служит для представления неатомарной последовательности шагов процесса.

Графически ветвление на диаграмме деятельности обозначается символом решения (decision), изображаемого в форме небольшого ромба, внутри которого нет никакого текста.

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

1.3.5 Диаграммы компонентов и развертывания

Физическая система (physical system) — реально существующий прототип модели системы.

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

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

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

В языке UML для компонентов определены следующие стереотипы:

- <<file>> (файл) – определяет наиболее общую разновидность компонента, который представляется в виде произвольного физического файла.

- <<executable>> (исполнимый) – определяет разновидность компонента-файла, который является исполнимым файлом.

- <<document>> (документ) – определяет разновидность компонента-файла, который представляется в форме документа произвольного содержания, не являющегося исполнимым файлом или файлом с исходным текстом программы.

- <<library>> (библиотека) – определяет разновидность компонента-файла, который представляется в форме динамической или статической библиотеки.

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

- <<table>> (таблица) – определяет разновидность компонента, который представляется в форме таблицы базы данных.

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

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

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

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

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

2  Анализ и построение модели информационной системы, предназначенной для управления турникетом метро

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

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

2.1  Глоссарий

В процессе анализа нашей предметной области мы выделили несколько терминов и составили неформальный словарь данных системы (Таблица 1).

Таблица 1 - Глоссарий проекта

2.2  Концептуальная модель системы

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

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

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

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

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

 Добавим к диаграмме вариантов использования текстовый сценарий, описывающий типичный ход событий выполнения варианта использования «Проход через турникет» (Таблицы 2-4).

Таблица  2 - Главный раздел сценария выполнения варианта использования "Проход через турникет "

Таблица 3 - Типичный ход событий сценария выполнения варианта использования  "Проход через турникет"

Таблица  4 - Раздел Исключения сценария  выполнения варианта использования "Снятие наличных по кредитной карточке"

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

 В случае недействительности карточки (карта просрочена, недостаточно "единиц") турникет блокирует пассажиру доступ в метрополитен. Поэтому следует описать еще один вариант использования – «Блокирование доступа в метро».

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

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

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

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

За координацию действий других классов системы управления турникетом отвечает управляющий класс «Контроллер турникета».

Выделим так называемые пограничные классы – устройства турникета, которые непосредственно взаимодействуют с пассажиром: «Устройство чтения карточки», «Устройство индикации прохода», «Устройство подачи звуковых сигналов», «Датчики движения», «Устройство перекрывания доступа», «Таймер». Перечислим их атрибуты и опреации (Таблицы 5-14).

Таблица 5 - Операции класса «Устройство чтения карточки»

Таблица 6 - Операции класса «Устройство индикации прохода»

Таблица 7 - Операции класса «Устройство подачи звуковых сигналов»

Таблица 8 - Операции класса «Датчики движения»

Таблица 9 - Операции класса «Устройство перекрывания доступа»

Таблица 10 - Операции класса «Таймер»

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

Таблица 11 - Атрибуты класса «Транзакция банкомата»

Таблица 12 - Операции класса «Транзакция банкомата»

       Так как каждый турникет связан с главной программой управления метро, добавим два класса типа интерфейс: «Контроллер метрополитена» и «АСУ метрополитена».

Таблица 13 - Операции класса «Контроллер метрополитена»

Таблица 14 - Операции класса «АСУ метрополитена»

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

Рисунок 2 - Диаграмма классов для модели управления турникетом
     2.3  Анализ поведения системы

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

2.3.1  Диаграммы  кооперации и последовательности

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

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

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

1. прочитать идентификатор карточки (пассажир, вставляя карточку в приемник отправляет сообщение на устройство чтения);

2. проверить идентификатор карточки (контроллер турникета передает сообщение на контроллер метро для проверки действительности карты);

3. создать новую транзакцию;

4. проверить количество единиц (контроллер турникета передает сообщение на контроллер метро для проверки баланса пассажира);

5. проверить срок годности (контроллер турникета передает сообщение на контроллер метро для проверки срока годности карты);

6. списать единицу со счета пассажира (контроллер турникета передает сообщение на контроллер метро для списания единицы с баланса);

7. вернуть карточку (контроллер турникета передает сообщение на устройство чтения карточки для возврата ее владельцу);

8. отсчитывать 5 секунд (контроллер турникета посылает сообщение на таймер для отсчета времени);

9. зажечь индикатор «Проход» (контроллер турникета посылает сообщение на устройство индикации);

10.  подать звуковой сигнал (контроллер турникета посылает сообщение на устройство подачи звуковых сигналов);

11.  открыть доступ (контроллер турникета посылает сообщение на устройство перекрывания доступа);

12.  пройти через турникет (пассажир, пройдя через турникет, посылает сообщение о проходе на датчики движения);

13.  определить проход пассажира (контроллер турникета посылает сообщение на датчики для регистрации прохода пассажира);

14. фиксировать время прохода (контроллер турникета посылает сообщение на таймер для фиксации времени прохода);

15.  зажечь индикатор «Стоп» (контроллер турникета посылает сообщение на устройство индикации);

16.  перекрыть доступ (контроллер турникета посылает сообщение на устройство перекрывания доступа);

17.  закрыть транзакцию.

Конечный вид диаграмм кооперации и последовательности представлены на рисунках 3 и 4.

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

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

2.3.2  Диаграммы состояний и деятельности

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

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

Представим описанный принцип действия в виде диаграммы состояний (Рисунок 5).

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

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

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

     Представим описанный принцип действия в виде диаграммы деятельности (Рисунок 6).

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

2.4  Физическая модель

Опишем  особенности физического представления  модели управления банкоматом при помощи диаграмм компонентов и размещения.

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

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

Построим диаграмму компонентов (Рисунок 7).

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

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

Система состоит из сервера метрополитена и некоторого количества турникетов, связанных с сервером при помощи сети.

      Изобразим это на диаграмме (Рисунок 8).

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

Заключение

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

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

1. В.П.Романов, Н.З.Емельянова, Т.Л.Партыка Проектирование экономических информационных систем. Методологии и современные технологии. – М: Экзамен, 2005.- 256 с.

2. Дж.Рамбо, М.Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. – СПб.: Питер, 2007.

3. Г.Буч, ДЖ.Рамбо, А.Якобсон. Язык UML: руководство пользователя . – СПб. : Питер, 2003.

4. Леоненков А.В. Самоучитель UML. 2-е издание - СПб.: "БХВ-Петербург", 2004. - 432 с.

5. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения - СПб: "Питер", 2002. - 496 с.

6. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов - М.: "ДМК Пресс", 2002. - 160 с.