Концептуальное проектирование информационной системы

С.я73

М545

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное автономное образовательное учреждение высшего профессионального образования «Южный федеральный университет» ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ В Г. ТАГАНРОГЕ

 

 

№ 4786

Кафедра автоматизированных систем научных исследований и экспериментов

Методические указания   к выполнению курсового проекта по курсу Информационные ресурсы муниципальных систем Направление подготовки 120700 «Землеустройство и кадастры»

Таганрог 2011

 

УДК 681.324(07.07) + ББК 65с.я73

 

Составители: С.Л. Беляков, М.Л. Белякова, Л.В. Гордиенко

 

Методические указания к выполнению курсового проекта по курсу «Информационные ресурсы муниципальных систем». – Таганрог: Изд-во ТТИ ЮФУ, 2011. – 32 с.

 

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

 

Табл. 4.Илл. 18. Библиогр.: 15 назв.

 

Рецензент А.В. Боженюк, д.т.н., проф. каф. ПИ

 

 

Содержание

 

Введение. 4

1. Задание на курсовое проектирование. 4

2. Концептуальное проектирование информационной системы.. 5

2.1. Диаграммы прецедентов. 5

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

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

2.4. Диаграммы состояний. 13

2.5. Диаграммы действий. 13

2.6. Диаграммы развертывания. 14

3. Проектирование базы данных. 15

3.1. Реляционная модель данных. 15

3.1.1. Построение отношений. 15

3.1.2. Связи между отношениями. 16

3.1.3. Ограничения целостности. 17

3.2. Нормализация отношений базы данных. 17

3.2.1. Функциональные зависимости. 17

3.2.2. Нормальные формы.. 19

4. Использование СУБД Access для создания базы данных. 21

4.1. Основные характеристики и возможности СУБД Access. 21

4.2. Конструирование базы данных. 22

4.3. Основы создания форм.. 23

4.4. Обработка данных средствами СУБД Access. 25

4.4.1. Конструирование запросов. 25

4.4.2. Элементы языка SQL и запросы в форме SQL.. 25

5. Рекомендации по выполнению проекта. 26

Библиографический список. 30

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

 

Введение

В настоящих методических указаниях содержатся рекомендации для выполнения курсового проекта по курсу «Информационные ресурсы муниципальных систем» для подготовки студентов по направлению 120700 «Землеустройство и кадастры».

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

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

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

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

 

Задание на курсовое проектирование

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

1.На основе анализа предметной области в рамках среды MS Access нужно создать базу данных, разработать пользовательский интерфейс и реализовать не менее пяти разноплановых запросов.

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

3.При построении системы должны быть решены вопросы целостности информации.

4. Построенные отношения должны соответствовать 1, 2, 3 нормальным формам.

5.Запросы к базе данных должны быть реализованы на языке SQL.

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

· Введение.

· Анализ технического задания и предметной области.

· Разработка обобщенной структурной схемы системы.

· Разработка таблиц и схемы данных системы.

· Разработка дерева форм пользовательского интерфейса системы

· Создание запросов на языке SQL.

 

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

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

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

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

Рис. 1. Нотация для диаграмм прецедентов

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

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

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

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

В качестве примера рассмотрим диаграмму прецедентов для информационной картографической модели, которую предполагается использовать в системе управления городом (Рис.2).

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

Ввиду того, что система городского управления носит организационный характер, в её состав входят несколько классов пользователей. На диаграмме показаны 6 классов:

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

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

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

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

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

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

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

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

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

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

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

Аналогичным образом рассматривается прецедент «Картометрия». Функции измерения расстояний, периметров и других показателей рассматриваются единообразно для всех акторов. Заметим, что такой вариант использования не является единственным. Если картометрические функции носят узкоспециализированный характер, их следует связывать с соответствующими классами акторов. Например, измерение гидросопротивлений трубопроводов, интенсивности потока рабочей среды, расхода относится напрямую к актору Водоснабжение.

Возможность трёхмерного моделирования (прецедент «Управление 3D») доступна ограниченному набору классов пользователей. На диаграмме это акторы Архитектор, Строительство и Чрезвычайные ситуации. Явное выделение акторов позволит снизить избыточность строящихся объёмных моделей: в состав визуализируемых объектов, трёхмерных сцен будут включены элементы, необходимые перечисленнымакторам. Учитывая повышенные требования к вычислительным ресурсам для трёхмерной визуализации, снижение избыточности играет важную роль.Логически связан с прецедентом «Управление 3D» прецедент «Облёт». Данная возможность динамического анализа трёхмерных изображений становится всё более доступной благодаря росту вычислительной мощности персональных компьютеров. Возможно, на текущий момент подобная возможность не является строго необходимой акторам. Но её упоминание на диаграмме может рассматриваться как компонент перспективного развития модели.

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

 

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

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

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

В отношении наследования класс А является базовым, классы D,E,F – производными.

Ассоциация связывает объект-клиент класса В с объектом-сервером класса С.

Рис. 3. Нотация для диаграммы классов

Заметим, что для агрегирования и композиции на линиях указывают допустимое число включаемых экземпляров объектов. Например, класс А допускает включение не более 3 экземпляров класса С. При этом число агрегируемых объектов класса В не ограничивается.

На рис. 4 приведён пример диаграммы классов, описывающей модель электронной карты.

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

Обратим внимание, что абстракция фигуры включает набор свойств и методов, которые характерны для любых геометрических примитивов – точек, линий, дуг, и т.д. Значения свойств в конкретных классах устанавливаются в соответствии с определёнными соглашениями. Например, свойство Площадь и Периметр для точки устанавливаются равными 0, хотя с формальных позиций точка есть одномерный объект, для которого понятия площади и периметра смысла не имеют. Аналогично, требуется ввести соглашение о том, что считать площадью разомкнутой полилинии (ломаной линии из произвольного числа последовательно соединённых отрезков). Примером подобного соглашения может быть следующее: площадью полилинии считается площадь многоугольника, полученного замыканием начальной и конечной точки исходной полилинии. Рис. 5 иллюстрирует соглашение: исходная полилиния (рис.5 а) имеет площадь, равную площади вогнутого многоугольника (рис. 5.б).

Рис. 4. Пример диаграммы классов

В качестве примера методов, которые должен реализовать любой геометрический примитив, на рис. 4 указаны ОписывающийМ() и НайтиЦентр(). Метод ОписывающийМ() предназначен для построения описывающего многоугольника, что, в свою очередь, может использоваться для создания буферной зоны на карте. Универсальный алгоритм построения описывающего многоугольника достаточно громоздок, в то же время как частный случай для каждого класса примитивов реализация метода может быть несложной.

б)

а)

Метод НайтиЦентр() предназначается для нахождения центра фигуры, причём центр может не являться геометрическим понятием, а носить специальный характер в каждом классе.

Рис. 5 Интерпретация свойства Площадь полилинии

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

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

Класс «Ссылка» может быть абстрактным, если не определён метод Перейти(). Это может быть сделано тогда, когда предполагается использовать разные алгоритмы обращения к внешним источникам данных в зависимости от класса геометрического примитива. В том случае, когда это не так, т.е. будет использоваться единый алгоритм, он может быть реализован как метод Перейти() в базовом классе и наследоваться в производных. Таким образом, диаграмма неявно отражает два варианта объектной модели.

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

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

· объект «Точка» имеет свойство ВидТочки, определяющее визуальное представление точечного объекта – круг, ромб, растровое изображение. Методы ВСредину() или ВЦентр() позволяют точке размещаться в центре либо в средине выбранного объекта;

· всякий объект класса «Полилиния» содержит список всех своих сегментов в качестве свойства. Это отличает его от объектов классов «Точка» и «Дуга». Вызов метода Сгладить() позволит представить полилинию особым образом (см. рис. 6). На при ведённом рисунке исходнаяполилиния сглажена сплайнами;

· класс «Дуга» особым образом задаёт положение и вид своих экземпляров через свойства Центр и Радиус, что принципиально отличает его от других классов примитивов. Соответственно, специфику имеет метод определения длины дуги (метод ВычДлину()).

Рис. 6 Пример сглаживания полилинии

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

Рассмотрим примеры свойств картографического объекта. Свойство «ИдКод» используется для уникальной идентификации экземпляра картографического объекта. Обычно это уникальная цифро-буквенная комбинация, которая генерируется программным путём во время создания объекта. Свойство «Тип» используется для указания класса картографического объекта: всякая географическая карта предполагает использование классификации. Значение свойства – это строка символов, которая является наименованием класса картографического объекта.

Всякий картографический объект размещается на одном из слоёв карты. Класс объектов «Слой» агрегирует в себе картографические объекты. Как видно из диаграммы, объект «Слой» имеет наименование (свойство «Наименование»), которое позволяет обращаться к нему как на программном уровне, так и в диалоге с пользователем. Слои аккумулируют в себе разнообразную информацию, необходимую для визуального отображения картографических объектов. Именно через свойства слоя становится возможным один и тот же примитив отображать различным образом. Например, заданное значение свойства «Цвет» определяет цвет отображения всех объектов слоя. Способ отображения всех линий слоя задаёт свойство «ТипЛинии». Благодаря модели слоя, существенно облегчается задача манипулирования большим числом объектов карты.

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

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

Класс «Слой», как можно видеть на диаграмме, может не содержать ни одного картографического объекта. В то же время, картографические объекты не могут создаваться вне слоёв.

Класс «Слои» предназначен для предоставления сервисных функций управления отдельными слоями карты: создания, модификации, удаления и поиска слоёв. Свойство «СписокСлоёв» представляет собой объект, позволяющий манипулировать набором слоёв как списком – добавлять, удалять, перемещать, сортировать объекты класса «Слой». Подчеркнём, что объект списка является внутренним (инкапсулирован в объекте) и непосредственно не доступен для использования внешними объектами. Методы ДобавитьСлой() и УдалитьСлой() позволяют выполнять соответствующие операции извне, не нарушая инкапсуляции.

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

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

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

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

Объект класса «Карта» агрегирует в себя слои. Как видно из диаграммы, в карту включается строго один объект множества слоёв. Элементами поведения объекта класса «Карта» являются методы Создать() и Завершить(). Подобные методы называют конструктором и деструктором класса. Их назначение, соответственно, – зарезервировать ресурсы для создания объекта и организовать соответствующие информационные структуры, и освободить ресурсы после завершения работы объектом.

Свойства класса («Наименование», «Проекция» и «Источник») характеризуют качественные и количественные характеристики информационной модели географической карты.

Примером ассоциативной связи объектов на диаграмме является связь между классами «Карта» и «СерверПечати». Объект карты может вызывать метод Печать() сервера печати для вывода картографических изображений на внешние устройства. Заметим, что внешние устройства могут быть виртуальными, т.е. реализовать некую функцию вывода на абстрактное устройство. Такой приём часто используют для преобразования данных из одного формата в другой. Например, виртуальный плоттер для публикации картографических изображений в Интернет формирует растровый файл установленного размера и разрешения.

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

 

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

Рис. 8. Диаграмма состояний

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

Рис. 9 Диаграмма состояний

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

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

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

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

Рис.10 Нотация диаграмм действий

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

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

 

Диаграммы развертывания

Диаграммы развёртывания (deploymentdiagram) представляют информационную систему с точки зрения размещения её компонентов на серверах реальной компьютерной сети. Этот вид диаграмм наиболее важен для администрирования сложных компьютерных сетей. Если сеть состоит из более, чем нескольких десятков компьютеров, управление ею в рабочем режиме представляет собой нетривиальную задачу. Администрирование требует учёта используемых программных продуктов, распределения лицензий, установку обновлений, конфигурирование программ соответственно прикладным задачам, распределение прав доступа к ресурсам сети, настройку виртуальных подсетей, и многое другое. Выполнение перечисленных задач требует знаний о программных компонентах, их интерфейсах и связях, а также физическом размещении на компьютерах сети. На рис. 11 показан пример диаграммы развёртывания. Нотацию несложно понять из рисунка: объемными фигурами показаны устройства. Каналы связи между ними отображаются линиями с пометкой типа сетевого протокола. Обозначения программных компонентов и баз данных размещаются внутр