Разработка ПО ИС покупки билетов в железнодорожной кассе

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

    Декомпозиция продолжается, создавая многоуровневую иерархию диаграмм до тех пор, пока не будет достигнут уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее не имеет смысла. На рис. 4.4. достаточно четко детализирован второй процесс  под  названием  «Администрирование клиентов». Он разбился на 3 подпроцесса, название которых должно начинаться с глагола: 2.1 определить пункт назначения; 2.2 ответить на запрос о наличии билета; 2.3 определить цену и наличие билета. 

 

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

      Далее происходит детализация процесса 3 (рис. 4.5.). Процесс «Администрирование билетов» разбивается на подпроцессы: 3.1 оформить покупку билета; 3.2 вернуть билет. 

    

    Рис. 4.5. диаграмма потоков данных первого  уровня для процесса 3 

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

    Построение  диаграммы системных  процессов и диаграммы  последовательностей экранных форм

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

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

    Рис. 4.6.Диаграмма системных процессов  первого уровня 

 

Рис. 4.7. Диаграмма последовательности экранных форм

5. Объектно-ориентированный подход к проектированию ПО ИС

    Концептуальной  основой объектно-ориентированного анализа и проектирования ПО (ООАП) является объектная модель. Ее основные принципы:

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

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

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

    Унифицированный язык моделирования UML (Unified Modeling Language) является преемником объектно-ориентированного анализа и проектирования (OOA&D), которые появились в конце 80-х и начале 90-х годов. Он непосредственно унифицирует методы Буча, Рамбо (ОМТ) и Джекобсона, однако обладает большими возможностями. Язык UML прошел процесс стандартизации в рамках консорциума OMG (Object Management Group) и в настоящее время является стандартом OMG.

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

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

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

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

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

    Достоинства модели вариантов использования  заключаются в том, что она:

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

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

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

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

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

      Построим  диаграмму последовательности для варианта использования Запрос на наличие билетов в выбранный пункт назначения (рис. 5.2.).   

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

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

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

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

 

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

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

    Выделение архитектурных уровней:

    Application Layer - содержит элементы прикладного уровня (пользовательский интерфейс);

    Business Services Layer - содержит элементы, реализующие бизнес-логику приложений (наиболее устойчивая часть системы);

    Middleware Layer - обеспечивает сервисы, не зависимые от платформы.

      

    Рис. 5.4. Диаграмма пакетов 

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

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

      

    Рис. 5.5. Сетевая конфигурация системы продажи билетов 
 
 

6. Заключение

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

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