Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Омский государственный институт сервиса

Моделирование информационных систем с использованием языка UML

Методические указания к выполнению курсовой работы

И.В. Червенчук

• Введение
• 2 . Унифицированный язык моделирования UML
• 4. Разработка модели программной системы средствами UML
• 5. Вопросы реализации информационной системы
• 6. Темы курсовых работ
• Библиографический список

Введение

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

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

1. Общие требования к выполнению курсовой работы

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

Типовое название курсовой работы выглядит как "Разработка информационно-справочной системы _название _ "

Введение

1. Содержательный обзор предметной области. Основные требования к системе

2. Развернутая модель информационной системы

2.1 Вид с точки зрения прецедентов

2.2 Вид с точки зрения проектирования

2.3 Вид с точки зрения реализации

2.4 Вид с точки зрения процессов (при необходимости)

2.5 Вид с точки зрения развертывания (при необходимости)

3. Реализация информационной системы

Заключение

Приложение Листинг программы или головного модуля

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

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

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

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

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

моделирование информационная система язык

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

2. Унифицированный язык моделирования UML

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

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

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

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

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

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

UML - это язык конструирования. Хотя UML не является языком визуального программирования, модели, созданные с его помощью, могут быть непосредственно переведены на различные конкретные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

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

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

UML - это язык документирования

Компания, выпускающая программные средства, помимо исполняемого кода производит и другие документы, в том числе:

требования к системе;

архитектуру;

проект;

исходный код;

проектные планы;

тесты;

прототипы;

версии, и др.

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

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

Рассмотрим разработку модели информационной системы средствами языка UML на примере разработки автоматизированного рабочего места секретаря кафедры (далее АРМ секретаря кафедры).

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

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

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

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

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

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

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

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

Итак, ставится задача разработать систему "АРМ секретаря кафедры" которая позволяла бы вести автоматизированный учёт данных о сотрудниках и студентах кафедры ИВТ ОмГТУ, обеспечивала гибкие возможности при решении запланированных и незапланированных специфических задач обработки учетных данных.

В рамках решения задачи разработки АРМ секретаря кафедры выделим следующие сущности:

преподаватели - преподавателикафедры;

студенты - учащиеся вуза данной специальности;

студенты учатся в группах , группа является организующей (объединительной) сущностью для студентов;

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

дисциплина - преподаваемая дисциплина (предмет, курс).

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

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

С учетом введенных терминов разрабатываемая систем должна обеспечивать:

организацию полного и достоверного учета всех сотрудников и студентов кафедры;

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

сокращение трудозатрат на подготовку первичных документов и отчетов;

устранение дублирования при вводе информации и, возникающих при этом механических ошибок;

удобный интерфейс пользователю;

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

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

4. Разработка модели программной системы средствами UML

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

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

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

диаграммы объектов;

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

диаграммы последовательностей;

диаграммы кооперации;

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

диаграммы действий (деятельности);

диаграммы компонентов;

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

Концептуальная модель UML

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

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

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

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

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

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

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

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

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

4.1 Разработка вида с точки зрения прецедентов

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

Прецедент (Use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенногоакт е ра (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Прецедент только декларирует описание какого-либо действия системы, отвечая на вопрос "что делать?", но не указывает какими средствами. Конкретная реализация специфицируемого прецедентом поведения обеспечивается классом, кооперацией классов или компонентом.

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

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

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

Возвращаясь к моделированию АРМ секретаря кафедры, выделим прецеденты:

Редактирование данных ,

Поиск студента ,

Поиск преподавателя ,

Выдача списка преподаваемых дисциплин ,

Авторизация .

Элементы диаграммы прецедентов (прецеденты и актеры) должны быть связаны отношениями.

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

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

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

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

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

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

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

В нашем случае, прецедент редактирование данных включает в себя прецеденты: ввод данных , удаление данных , изменение данных .

Диаграмма прецедентов АРМ секретаря кафедры показана на рис.1.

Рис. 1. Диаграмма прецедентов АРМ секретаря кафедры

Прецедент поиск студента предполагает поиск по фамилии и поиск по итогам успеваемости.

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

Потоки событий могут быть описаны посредством неструктурированного текста, структурированного текста (содержащего служебные слова: ЕСЛИ ,ДО ТЕХ ПОР ПОКА и т.п.), специализированного формального языка (псевдокода).

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

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

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

Исключительный поток событий . Клиент может прекратить транзакцию в любой момент, нажав клавишу Cancel . Это действие начинает прецедент заново. Ввод в систему не производится.

Исключительный поток событий . Клиент может в любой момент до нажатия клавиши Enter стереть свои Login и пароль.

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

Очевидно, что описание прецедента потоком событий предполагает некоторый алгоритм, который можно представить на диаграмме деятельности (рис. 2).

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

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

Рис. 2. Авторизация пользователя. Диаграмма деятельности.

4.2 Разработка вида с точки зрения проектирования

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

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

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

является четко очерченной абстракцией некоторого понятия из словаря проблемной области или области решения;

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

поддерживает четкое разделение спецификаций абстракции и ее реализации;

понятен и прост, но в то же время допускает расширение и адаптацию к новым задачам.

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

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

При моделировании класса T _ ADR атрибутиндекс зададим посредством примитивного типа T _ POSTIDX , определяемого как шестизначное десятичное число. Примитивные типы моделируются стереотипом "type " , диапазон значений указывается через ограничения, заключенные в фигурные скобки.

В классе преподаватель выделим специфические атрибуты, относящиеся только к преподавателю: должность , уч . степень (ученая степень), уч . звание (ученое звание), разряд (разряд единой тарифной сетки). Атрибуты уч . степень иуч . звание лучше определить специализированными типами через перечисление. Перечисления моделируются классом со стереотипом "enum " (enumeration - перечисление), допустимые значения записываются как атрибуты, метки, определяющие видимость атрибутов при этом подавляются. В рассматриваемом примере через перечисление введем специализированные классы T _Должн , Т_УчСт , Т_УчЗв , определяющие соответственно возможные должности, ученые степени, ученые звания через перечисления. В данном случае, как и везде в подобных случаях при создании классов, специфицирующих атрибуты основного класса, устанавливаются отношения зависимости.

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

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

Класс дисциплина имеет атрибуты: номер , название , цикл . Атрибут цикл посредством введенного через перечисление специализированного типа Т_Циклы определяет к какому циклу относится дисциплина: к циклу гуманитарных и социально-экономических дисциплин, математических и естественнонаучных дисциплин, общепрофессиональных дисциплин, специальных дисциплин.

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

Рис. 3. Диаграмма классов АРМ секретаря кафедры (вариант 1)

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

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

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

В данном случае, как и в большинстве других, направление ассоциаций двухстороннее, поэтому навигацию лучше подавлять (снять галочку в поле Navigable опции Detail Role)

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

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

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

Рис. 4. Диаграмма классов АРМ секретаря кафедры (вариант 2)

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

Аспиранты также могут вести занятии по определенной дисциплине у определенных групп: ассоциации "многие ко многим" аспиранты-группы , аспиранты-дисциплины . Некоторые аспиранты могут не вести занятия, поэтому тип множественности на концах ассоциации будет 0. n.

Итоговая диаграмма классов приводится на рис. 3.

Рис. 5. Упрощенная диаграмма классов

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

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

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

Перейдем к определению интерфейсов. Классы взаимодействуют с внешним миром через интерфейсы.

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

Поместим на диаграмму класс электронная таблица , в котором инкапсулированы все свойства и операции электронной таблицы, позволяющей редактировать данные. Структуру данного класса раскрывать ввиду большой сложности не будем. Так в современных средствах разработки приложений пользователь пользуется готовыми классами и шаблонами, наследуя их возможности, например библиотека VCL (Delphi) содержит класс TTable, инкапсулирующий возможности электронной таблицы. Потомки класса электронная таблица являются конкретными электронными таблицами, содержащие конкретные данные по преподавателям, аспирантам, студентам, группам, дисциплинам и специальностям. Делая соответствующие классы потомками класса электронная таблица , мы декларируем для этих классов все свойства и операции, присущие электронным таблицам (регистрацию в системе, вставку, удаление, редактирование данных, сортировку и т.д.).

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

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

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

Интерфейс поиск студента отобразим с указанием списка операций через стереотипный класс, при этом отношение реализации отображается пунктирной стрелкой с закрытым наконечником.

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

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

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

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

Рис. 6. Итоговая диаграмма классов АРМ секретаря кафедры

Итоговая диаграмма приводится на рис. 6.

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

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

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

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

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

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

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

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

Менеджер транзакций - объект, обеспечивающий выполнение законченной операции над базой данных, в данном случае создание новой записи о студенте Петрове. На данный объект возлагается выполнение также ряда системных функций, сопровождающих трансакцию. Примером менеджеров трансакций являются, например, BDE (используются для доступа из приложений Delphi к базам данных Paradox, Dbase и др.), ADO (используется для доступа к базам MS Access из различных приложений).

Диаграмма последовательности ввода новой записи о студенте в АРМ секретаря кафедры представлена на рис. 7.

Рис. 7. Ввод данных о студенте. Диаграмма последовательности.

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

При желании можно данное взаимодействие представить диаграммой кооперации, иллюстрирующей прежде всего структурный аспект взаимодействия (рис.8). Данную диаграмму можно построить из предыдущей в автоматическом режиме (в Rational Rose нажатием клавиши F5).

Рис. 8. Ввод данных о студенте. Диаграмма кооперации.

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

4.3 Разработка профиля реляционной базы данных

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

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

Таблица (Table) - набор записей в базе данных по определенному объекту, состоит из столбцов.

Столбец (Column) - компонент таблицы, содержащий один из атрибутов таблицы (поле таблицы).

Первичный ключ (Primary key) - возможный ключ, выбранный для идентификации строк таблицы.

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

Представление (View) - виртуальная таблица, которая ведет себя с точки зрения пользователя точно также, как обычная таблица, но не существует самостоятельно.

Хранимая процедура (Stored procedure) - независимая процедурная функция, выполняемая на сервере.

Домены (Domains) - допустимый набор значений для атрибута или столбца.

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

Подобные документы

Методологии разработки информационных систем в отечественной и зарубежной литературе. Государственные и международные стандарты в области разработки программного обеспечения. Разработка фрагмента информационной системы "Учебно-методический ресурс".

курсовая работа , добавлен 28.05.2009


Определение понятия "система". История развития и особенности современных информационных систем. Основные этапы развития автоматизированной информационной системы. Использование отечественных и международных стандартов в области информационных систем.

презентация , добавлен 14.10.2013


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

презентация , добавлен 02.04.2013


Роль структуры управления в информационной системе. Примеры информационных систем. Структура и классификация информационных систем. Информационные технологии. Этапы развития информационных технологий. Виды информационных технологий.

курсовая работа , добавлен 17.06.2003


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

презентация , добавлен 07.04.2013


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

дипломная работа , добавлен 17.02.2015


Развитие информационных систем. Современный рынок финансово-экономического прикладного программного обеспечения. Преимущества и недостатки внедрения автоматизированных информационных систем. Методы проектирования автоматизированных информационных систем.

дипломная работа , добавлен 22.11.2015


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

дипломная работа , добавлен 23.06.2015


Решение по информационной безопасности. Системы для датацентров. Что такое оборудование центра обработки данных. Основные понятия и принципы моделирования. Выбор метода решения задач. Метод допустимых направлений Зойтендейка, алгоритм Франка–Вульфа.

курсовая работа , добавлен 18.05.2017


Понятие информационной системы. Этапы развития информационных систем. Процессы в информационной системе. Информационная система по отысканию рыночных ниш, по снижению издержек производства. Структура информационной системы. Техническое обеспечение.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ УЛЬЯНОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ В.С.ЩЕКЛЕИН МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ Конспект лекций для студентов направления 652100 «Авиастроение» Ульяновск 2002 2 УДК 621.9.06-229(035) ББК Щ Рецензент: Одобрены секцией методических пособий научно-методического сове- та университета Щеклеин В.С. Щ Моделирование информационных систем: конспект лекций/ В.С.ЩЕКЛЕИН. - Ульяновск: УлГТУ, 2002. - с. Конспект лекций представляет собой подборку материала, использо- ванного в 1999/2000 учебном году при проведении занятий по дисциплине "Моделирование информационных систем". Предназначен для студентов специализаций: 130107 «Программная обработка конструкционных мате- риалов» и 130111 «Проектный менеджмент авиационного производства». Это пособие не является завершенным, в него планируется включать новый разработанный материал, подборка и оформление которого осуществляется в соответствии с утвержденной программой дисциплины. 3 СОДЕРЖАНИЕ ВВЕДЕНИЕ ……………………………………………………………... 4 1. ОСНОВНЫЕ ПОНЯТИЯ ТЕОРИИ МОДЕЛИРОВАНИЯ ………... 4 2. СУЩНОСТЬ МЕТОДА СТАТИСТИЧЕСКИХ ИСПЫТАНИЙ И ЕГО РЕАЛИЗАЦИИ С ПОМОЩЬЮ КОМПЬЮТЕРА …………… 7 3. ОБОБЩЕННЫЕ АЛГОРИТМЫ СТАТИСТИЧЕСКОГО МОДЕЛИ- РОВАНИЯ ………………………………………………………… 9 4. МОДЕЛИРОВАНИЕ СЛУЧАЙНЫХ ВЕЛИЧИН С ЗАДАННЫМ ЗАКОНОМ РАСПРЕДЕЛЕНИЯ. МОДЕЛИРОВАНИЕ СЛУЧАЙ- НЫХ СОБЫТИЙ …………………………………………………….. 5. ПОДХОД К МОДЕЛИРОВАНИЮ СИСТЕМ ……………………... 15 6. ЗАДАНИЕ СЛУЧАЙНЫХ ВЕЛИЧИН И СЛУЧАЙНЫХ СОБЫТИЙ В EXCEL ………………………………………………………... 21 7. МОДЕЛИРОВАНИЕ МАРКОВСКИХ ЦЕПЕЙ ……………………. 23 8. МОДЕЛИРОВАНИЕ СИСТЕМ МАССОВОГО ОБСЛУЖИВАНИЯ. 25 9. СТРУКТУРА ИНФОРМАЦИОННО–ВЫЧИСЛИТЕЛЬНЫХ СИС- ТЕМ ……………………………………………………………………… 26 9.1. Понятие процесса ……………………….………………………….. 28 9.2. Рабочая нагрузка …………………………………………………… 29 10. ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ ……………………………………………………………….. 30 11. ОЦЕНКА ПРОИЗВОДИТЕЛЬНОСТИ КОМПОНЕНТОВ СИСТЕ- МЫ …………………………………………………………….…. 31 12. ОЦЕНКА ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ В ЦЕЛОМ ……. 32 13. ВЛИЯНИЕ РЕЖИМА ОБРАБОТКИ ДАННЫХ …………………….. 35 14. ХАРАКТЕРИСТИКИ НАДЕЖНОСТИ ……………………………… 36 15. ПОСТРОЕНИЕ МАТЕМАТИЧЕСКОЙ МОДЕЛИ ИНФОРМАЦИОННОЙ СИСТЕМЫ …………………………………. 40 БИБЛИОГРАФИЧЕСКИЙ СПИСОК ……………………………………. 46 4 ВВЕДЕНИЕ Полезность математического моделирования для решения практиче- ских задач вообще не вызывает сомнений. Может возникнуть вопрос, а для чего необходимо осваивать моделирование информационных систем (а сей- час эти системы невозможно представить без вычислительной техники) авиа- строителям, ориентированным на технологию производства самолетов? Со- временная технология становится все более и более автоматизированной. Современный авиастроитель, будь он конструктор или технолог должен ис- пользовать компьютеры в своей работе. Существует опасность неадекватной оценки возможностей компьютера при решении инженерных задач. Это мо- жет привести или к отказу от автоматизации того или иного фрагмента тех- нологического процесса, или к неоправданным расходам на средства вычис- лительной техники, возможности которых сильно завышены по сравнению с необходимыми. При этом так называемый здравый смысл может приводить к серьезным ошибкам в оценке. Целью дисциплины является вооружение мо- лодого специалиста аппаратом оценки информационно - вычислительных систем для того, чтобы он мог грамотно вписывать средства автоматизации в контуры производства или управления. Кроме того, моделируя те или иные системы, студенты получают опосредованный опыт оптимизации систем и закрепляют навыки использования компьютера при решении профессио- нальных задач. 1. ОСНОВНЫЕ ПОНЯТИЯ ТЕОРИИ МОДЕЛИРОВАНИЯ Моделированием называется замещение одного объекта другим с це- лью получения информации о важнейших свойствах объекта – оригинала с помощью объекта – модели. Модель (франц. modele от лат. modulas – мера, образец) : 1) образец для массового изготовления изделия; марка изделия; 2) изделие, с которого снимается форма (шаблоны, лекала, плазы); 3) изображаемый художником человек или предмет; 4) устройство, воспроизводящее строение или действие какого-либо другого устройства; 5) любой образ объекта, процесса или явления, используемый в качестве представителя оригинала (изображение, схема, чертеж, карта); 6) математический аппарат, описывающий объект, процесс или явление; 7) приспособление для получения отпечатка в литейной форме. В дальнейшем, если это не будет оговорено особо, под моделью будем понимать математический аппарат. Всем моделям присуще наличие некоторой структуры (статической или динамической, материальной или идеальной), которая подобна структуре объекта – оригинала. В процессе работы модель выступает в роли относи- тельно самостоятельного квазиобъекта, позволяющего получить при иссле- довании некоторые знания о самом объекте. Если результаты такого иссле- 5 дования (моделирования) подтверждаются и могут служить основой для про- гнозирования в исследуемых объектах, то говорят, что модель адекватна объ- екту. При этом адекватность модели зависит от цели моделирования и при- нятых критериев. Процесс моделирования предполагает наличие: - объекта исследования; - исследователя, имеющего конкретную задачу; - модели, создаваемой для получения информации об объекте, необходимой для решения задачи. По отношению к модели исследователь является экспериментатором. Надо иметь в виду, что любой эксперимент может иметь существенное зна- чение в конкретной области науки и техники только при специальной обра- ботке его результатов. Одним из наиболее важных аспектов моделирования систем является проблема цели. Любую модель строят в зависимости от це- ли, которую ставит перед ней исследователь, поэтому одна из основных про- блем при моделировании – это проблема целевого назначения. Подобие про- цесса, протекающего в модели, реальному процессу, является не самоцелью, а условием правильного функционирования модели. В качестве цели должна быть поставлена задача изучения какой-либо стороны функционирования объекта. Если цели моделирования ясны, то возникает следующая проблема, проблема построения модели. Это построение оказывается возможным, если имеется информация или выдвинуты гипотезы относительно структуры, ал- горитмов и параметров исследуемого объекта. Следует подчеркнуть роль ис- следователя в процессе построения модели, этот процесс является творче- ским, базирующимся на знаниях, опыте, эвристике. Формальные методы, по- зволяющие достаточно точно описать систему или процесс являются непол- ными или просто отсутствуют. Поэтому выбор той или иной аналогии полно- стью основывается на имеющемся опыте исследователя, и ошибки исследо- вателя могут привести к ошибочным результатам моделирования. Когда модель построена, то следующей проблемой можно считать про- блему работы с ней, реализацию модели. Здесь основные задачи – минимиза- ция времени получения конечных результатов и обеспечение их достоверно- сти. Для правильно построенной модели характерным является то, что она выявляет лишь те закономерности, которые нужны исследователю, и не рас- сматривает свойства системы – оригинала, несущественные в данный мо- мент. Классификация видов моделирования систем приведена на рис. 1.1. Математическое моделирование – это построение и использование матема- тических моделей для исследования поведения систем (объектов) в различ- ных условиях, для получения (расчета) тех или иных характеристик оригина- ла без проведения измерений или с небольшим их количеством. В рамках ма- тематического моделирования сложились два подхода: - аналитический; - имитационный. 6 Моделирование систем Детермини- Стохастическое рованное Статическое Динамическое Дискретное Дискретно- Непрерывное непрерывное Абстрактное Материальное Наглядное Символическое Математическое Натурное Физическое Аналитическое Комбинирован. Имитационное Рис. 1.1. Аналитический подход основывается на построении формульных зави- симостей, связывающих параметры и элементы системы. Такой подход дол- гое время и был собственно математическим подходом. Однако при рассмот- рении сложных систем строгие математические зависимости весьма сложны, требуется большое количество измерений для получения требуемых значе- ний параметров. Анализ характеристик процессов функционирования сложных систем с помощью только аналитических методов исследования наталкивается на зна- чительные трудности, приводящие к необходимости существенного упроще- ния моделей либо на этапе их построения, либо в процессе работы с моде- лью, что снижает достоверность результатов. Имитационный (статистический) подход в моделировании базируется на использовании предельной теоремы Чебышева при вероятностном пред- ставлении параметров системы. На основе предварительного изучения моде- лируемой системы достаточно просто определяются виды и значения законов распределения случайных величин параметров. В рамках имитационного подхода используются аналитические зависимости между параметрами эле- ментов системы, однако эти зависимости имеют более обобщенный, упро- щенный характер. Они значительно проще, нежели зависимости в рамках аналитического подхода. 7 Математическое моделирование систем, в том числе и информацион- ных, имеет целью оптимизацию структуры систем, выбор наиболее опти- мальных режимов функционирования систем, определение требуемых харак- теристик аппаратурного оборудования и программного обеспечения. Математическое моделирование технологических процессов, в том числе и информационных, имеет основными целями нахождение оптималь- ных или приемлемых характеристик самого объекта, нахождение оптималь- ных режимов обработки, обучение персонала, обеспечение определенных функций управления. В любом случае моделирование должно отвечать следующим требова- ниям: - модели должны быть адекватны соответствующим системам или техноло- гическим задачам; - должна обеспечиваться необходимая точность; - должно обеспечиваться удобство работы пользователя – специалиста по технологии или по обработке информации (управлению): - понятный интерфейс управления моделированием; - достаточная скорость работы; - наглядность результатов; - приемлемая стоимость разработки и использования средств моделиро- вания. 2. СУЩНОСТЬ МЕТОДА СТАТИСТИЧЕСКИХ ИСПЫТАНИЙ И ЕГО РЕАЛИЗАЦИИ С ПОМОЩЬЮ КОМПЬЮТЕРА Метод статистического моделирования заключается в воспроизведении исследуемого процесса при помощи вероятностной математической модели и вычислении характеристик этого процесса. Основан метод на многократном проведении испытаний построенной модели с последующей статистической обработкой полученных данных с целью определения характеристик рас- сматриваемого процесса в виде статистических оценок его параметров. Рассмотрим уравнение: у = f (x, t , ξ) , (2.1) где y - параметр системы, требующий определения, x - фазовая переменная, t - время, ξ - случайный параметр, закон распределения которого нам известен. Если функция f существенно нелинейна, то для решения данной зада- чи нет универсальных методов решения, и достаточно полно отработанные регулярные методы поиска оптимальных решений можно применить только поставив во главу угла видимость использования математики, упрощения приведут к серьезной потери точности. Математическая модель станет не- 8 адекватной исследуемой системе, и моделирование будет только формой за- блуждения. Однако, если удается построить функцию y = ϕ (ξ) и датчик случайных чисел ξ 1 , ξ 2 , ... , ξ N с заданным законом распределения, то значение y может быть вычислено как y = ∑ ϕ (ξ i) N , (2.2) где ϕ (ξ 1) - значение i -ой реализации. Если f (x, t , ξ) является аналитической моделью процесса преобразова- ния информации или технологического процесса обработки детали, то ϕ (ξ) будет статистической моделью. Некоторые принципы и приемы построения статистических моделей будут рассмотрены позднее. Важно то, что при по- строении функции y = ϕ (ξ) и датчика случайных чисел ξ 1 , ξ 2 , ... , ξ N на бумаге в подавляющем большинстве случаев достаточно легко реализовать их на ЭВМ в рамках соответствующего программного обеспечения. При этом ре- зультаты будут содержать ошибку, но эта ошибка меньше, нежели ошибки из-за допущений в аналитической модели. Кроме того, ошибка из-за приме- нения статистической модели может быть количественно оценена. Этот прием распространяется и на более сложные случаи, когда урав- нение (2.1) содержит не только случайные параметры, но и случайные функ- ции. После получения на ЭВМ N реализаций следует этап обработки стати- стики, позволяющий рассчитать, наряду с математическим ожиданием (2.2) и другие параметры ϕ (ξ) , например дисперсию D = 1 N * ∑ x.i − 1 N 2* (∑ x.i) . В методе статистических испытаний для получения достаточно на- дежных результатов необходимо обеспечивать большое число реализаций N , кроме того, с изменением хотя бы одного исходного параметра задачи необ- ходимо производить серию из N испытаний заново. При сложных моделях неоправданно большая величина N может стать фактором, задерживающим получение результата. Поэтому важно правильно оценить необходимое чис- ло результатов. Доверительный интервал ε , доверительная вероятность α , дисперсия D и число реализаций N связаны соотношением ε = D NФ −1 (α) , где Ф −1 (α) - функция, обратная функции Лапласа. На практике можно воспользоваться соотношением N ≤ D ε 2 * 6,76 для α ≥ 0,99 принимая, с целью надежности, наибольшее значение N из соот- ношения (). Оценка дисперсии D может быть получена предварительно с помощью той же статистической модели при числе реализаций n , n << N . 9 При построении статистических моделей информационных систем ис- пользуется общий и прикладной математический аппарат. В качестве приме- ра можно привести аппарат систем массового обслуживания. Система массо- вого обслуживания (СМО) - система, предназначенная для выполнения пото- ка однотипных требований случайного характера. Статистическое моделиро- вание СМО заключается в многократном воспроизведении исследуемого процесса (технического, социального и т.д.) при помощи вероятностной ма- тематической модели и соответствующей обработке получаемой при этом статистики. Существуют пакеты программ статистического моделирования СМО, однако они требуют определенных усилий для их освоения и не всегда доступны. Поэтому в рамках дисциплины предлагается достаточно простой подход, позволяющий с наименьшими затратами моделировать простые СМО. При этом предполагается, что пользователь ознакомлен с теорией мас- сового обслуживания и имеет навыки работы на компьютере. Следует пом- нить, что массовое обслуживание - важный, но далеко не единственный предмет статистического моделирования. На основе этого метода решаются, например, задачи физики (ядерной, твердого тела, термодинамики), задачи оптимизации маршрутов, моделирования игр и т.п. 3. ОБОБЩЕННЫЕ АЛГОРИТМЫ СТАТИСТИЧЕСКОГО МОДЕЛИРОВАНИЯ Существуют две схемы статистического моделирования: - моделирование по принципу особых состояний; - моделирование по принципу ∧ t . Порядок моделирования по принципу особых состояний заключается в выполнении следующих действий: 1) случайным образом определяется событие с минимальным временем - бо- лее раннее событие; 2) модельному времени присваивается значение времени наступления наибо- лее раннего события; 3) определяется тип наступившего события; 4) в зависимости от типа наступившего события осуществляется выполнение тех или иных блоков математической модели; 5) перечисленные действия повторяются до истечения времени моделирова- ния. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования хо- рошо подходит для систем массового обслуживания в традиционном их опи- сании. Обобщенный алгоритм моделирования по принципу особых состоя- ний представлен схемой на рис. 3.1. 10 н Определение времени наступления очередного события Корректировка текущего модельного времени Опр.типа соб Блок реакции 1 Блок реакции К нет Конец модел Да Рис. к Моделирование по принципу ∧ t осуществляется следующим образом: 1) устанавливаются начальные состояния, в т. ч. t = 0 ; 2) модельному времени дается приращение t = t + ∧t ; 3) на основе вектора текущих состояний элементов модели и нового значения времени рассчитываются новые значения этих состояний; за ∧ t может на- ступить одно событие, несколько событий или же может вообще не проис- ходить событий; пересчет состояния всех элементов системы – более тру- доемкая процедура, нежели любой из блоков реакции модели, построенной по принципу особых состояний; 4) если не превышено граничное время моделирования, предыдущие пункты повторяются. В процессе моделирования производится измерение и статистическая обработка значений выходных характеристик. Эта схема моделирования применима для более широкого круга систем, нежели моделирование по принципу особых событий, однако есть проблемы с определением ∧ t . Если задать его слишком большим - теряется точность, слишком малым - возрас- тает время моделирования. На основе базовых схем моделирования можно строить комбинирован- ные и диалоговые схемы, в которых моделирование идет под контролем опе-

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

Задачи и функции информационной системы.

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

Задачи второй группы - задачи информатизации

общества "вглубь".

Для решения поставленных задач ИС должна выполнять следующие функции:

 отбор сообщений из внутренней и внешней среды, необходимых для реализации основной деятельности;

 ввод информации в ИС;

 хранение информации в памяти ИС, ее актуализация и поддержание целостности;

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

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

Функциональная структура информационной системы.

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

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

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

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

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

Выполнение указанных функций требует наличия аппарата описания и анализа информационных потребностей и их выражения на языке ИС (в том числе ЯОД, ИПЯ, языке индексирования и т. д.), а также аппарата непосредственно информационного обеспечения (процедуры поиска и выдачи информации, языки манипулирования данными и т. д.). Многие функции подсистем ИС дублируются или пересекаются, что является предметом оптимизации при проектировании ИС. Автоматизация ИС в связи с этим сопровождается перераспределением элементов ИС.

Автоматизация предполагает формализованное представление (структуризацию) как функций ИС, так и самой обрабатываемой в ИС информации, которое и позволяет осуществлять ввод, обработку/переработку, хранение и поиск информации с использованием ЭВМ. Любая формализация характеризуется тем или иным уровнем адекватности создаваемого образа реальной действительности (модели) самой действительности. Причем, адекватность модели реальной действительности определяется как свойствами самой действительности, так и возможностями используемого аппарата ее формализованного представления.

С этой точки зрения "уровень автоматизации" ИС тесно связан со "степенью структурируемости" информации. Различают три уровня структурируемости информации: Жесткоструктурируемая информация (данные)- информация, формализованное представление которой современными средствами ее структурирования (в частности, языками описания данных) не приводит к потере адекватности модели информации самой исходной

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

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

Методологии построения информационных систем.

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

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

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

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

Согласно статистическим данным, собранным Standish Group (СШЛ), из 8380 проектов, обследованных в СШЛ в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

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

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

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

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

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

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

К моделям предметных областей предъявляются следующие требования:

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

Понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

Реализуемость, подразумевающая наличие средств физической реализации модели предметной области и ИС;

Обеспечение опенки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей.

Функциональное моделирование IDEF0: основные определения и положения.

Программа интегрированной компьютеризации производства ICAM (ICAM - Integrated Computer Aided Manufacturing) направлена на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий. В США это обстоятельство было осознано еще в конце 70-ых годов, когда ВВС США предложили и реализовали

Методология IDEF (ICAM Definition), позволяет исследовать структуру, параметры и характеристики производственно-технических и организационно- экономических систем (в дальнейшем, там, где это не вызывает недоразумений – систем). Общая методология IDEF состоит из трех частных методологий моделирования, основанных на графическом представлении систем:

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

IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы;

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

К настоящему времени наибольшее распространение и применение имеют методологии IDEF0 и IDEF1 (IDEF1X), получившие в США статус федеральных стандартов. Методология IDEF0, особенности и приемы применения которой описываются в настоящем Руководящем документе (РД), основана на подходе, разработанном Дугласом Т. Россом в начале 70–ых годов и получившем название SADT (Structured Analysis & Design Technique - метод структурного анализа и проектирования). Основу подхода и, как следствие, методологии IDEF0, составляет графический язык описания (моделирования) систем, обладающий следующими свойствами.

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

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

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

Определим ключевые понятия структурного анализа деятельности предприятия (организации).

Операция - элементарное (неделимое) действие, выполняемое на одном рабочем месте.

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

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

открытие, идея), представляющая ценность для потребителя.

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

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

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

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

Инструментальная среда BPwin.

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case- средства BPwin.

BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес- процессов (IDEF3); диаграммы потоков данных (DFD). BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer).

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

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

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

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

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

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

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

Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Деятельность компании", "Прием заказа" и т.д.). Работа"Деятельность компании" может иметь, например, следующее определение: "Это учебная модель, описывающая деятельность компании". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом.

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

Учебное пособие для вузов

2-е изд., перераб. и доп.

2014 г.

Тираж 1000 экз.

Формат 60х90/16 (145x215 мм)

Исполнение: в мягкой обложке

ISBN 978-5-9912-0193-3

ББК 32.882

УДК 621.395

Гриф УМО
Рекомендовано УМО по образованию в области телекоммуникаций в качестве учебного пособия для студентов высших учебных заведений, обучающихся по специальностям «Сети и системы коммутации», «Многоканальные телекоммуникационные системы»

Аннотация

Рассмотрены алгоритмы моделирования дискретных и непрерывных случайных величин и процессов. Изложены принципы и алгоритмы моделирования информационных сигналов, описываемых Марковскими процессами с дискретным и непрерывным времени Рассмотрены принципы моделирования систем массового обслуживания. Описаны особенности описания и использования фрактальных и мультифрактальных процессов для моделирования телекоммуникационного трафика. Анализируются методы и примеры моделирования информационных систем с использованием специализированных пакетов прикладных программ Matlab, Opnet, Network simulator.

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

Введение

1 Общие принципы моделирования систем
1.1. Общие понятия модели и моделирования
1.2. Классификация моделей
1.3. Структура моделей
1.4. Методологические основы формализации функционирования сложной системы
1.5. Моделирование компонентов
1.6. Этапы формирования математической модели
1.7. Имитационное моделирование
Контрольные вопросы

2 Общие принципы построения систем и сетей связи
2.1. Концепция построения систем и сетей связи
2.2. Многоуровневые модели сети
2.2.1. Трехуровневая модель
2.2.2. Архитектура протоколов ТСР/IР
2.2.3. Эталонная модель OSI
2.3. Структура сетей связи
2.3.1. Глобальные сети
2.3.2. Локальные вычислительные сети
2.3.3. Топологии вычислительной сети
2.3.4. Локальные сети Ethernet
2.4. Сети Frame Relay
2.5. IP-телефония
Контрольные вопросы

3 Моделирование случайных чисел
3.1. Общие сведения о случайных числах
3.2. Программные методы генерирования равномерно распределенных случайных чисел
3.3. Формирование случайных величин с заданным законом распределения
3.3.1. Метод обратных функций
3.3.2. Приближенные методы преобразования случайных чисел
3.3.3. Метод отсеивания (метод генерации Неймана)
3.4. Методы, основанные на центральной предельной теореме
3.5. Алгоритмы моделирования часто употребляемых случайных величин
3.6. Алгоритмы моделирования коррелированных случайных величин
3.7. Формирование реализаций случайных векторов и функций
3.7.1. Моделирование n-мерной случайной точки с независимыми координатами
3.7.2. Формирование случайного вектора (в рамках корреляционной теории)
3.7.3. Формирование реализаций случайных функций

4 Моделирование дискретных распределений
4.1. Распределение Бернулли
4.2. Биномиальное распределение
4.3. Распределение Пуассона
4.4. Моделирование испытаний в схеме случайных событий
4.4.1. Моделирование случайных событий
4.4.2. Моделирование противоположных событий
4.4.3. Моделирование дискретной случайной величины
4.4.4. Моделирование полной группы событий
4.5. Потоки событий
4.6. Обработка результатов моделирования
4.6.1. Точность и количество реализаций
4.6.2. Первичная статистическая обработка данных
Контрольные вопросы

5 Алгоритмы моделирования стохастических сигналов и помех в системах связи
5.1. Алгоритм моделирования нестационарных случайных процессов
5.2. Алгоритмы моделирования стационарных случайных процессов
5.3. Методы моделирования сигналов и помех в виде стохастических дифференциальных уравнений
5.4. Примеры моделей случайных процессов в системах связи
5.4.1. Модели информационных процессов
5.4.2. Модели помех
5.4.3. Характеристика основных видов помех
Контрольные вопросы

6 Марковские случайные процессы и их моделирование
6.1. Основные понятия марковского случайного процесса
6.2. Основные свойства дискретных цепей Маркова
6.3. Непрерывные марковские цепи
6.3.1. Основные понятия
6.3.2. Полумарковские процессы
6.3.3. Процессы гибели и размножения
6.4. Модели непрерывнозначных марковских случайных процессов на основе стохастических дифференциальных уравнений
6.5. Моделирование марковских случайных процессов
6.5.1. Моделирование дискретных процессов
6.5.2. Моделирование скалярных непрерывнозначных процессов
6.5.3. Моделирование непрерывнозначных векторных процессов
6.5.4. Моделирование гаусcовского процесса с дробно-рациональной спектральной плотностью
6.5.5. Моделирование многосвязных последовательностей
6.5.6. Моделирование марковских процессов с помощью формирующих фильтров
6.5.7. Алгоритм статистического моделирования марковских цепей
Контрольные вопросы

7 Примеры марковских моделей
7.1. Марковские модели речевого диалога абонентов
7.1.1. Состояния речевого сигнала
7.1.2. Модели диалога
7.2. Марковские модели речевого монолога
7.3. Пуассоновский процесс, управляемый марковским в моделях речи
7.4. Марковские модели цифровых последовательностей на выходе кодека G.728
7.5. Статистическое уплотнение источника речевых пакетов с учетом марковской модели телефонного диалога
7.6. Марковская модель беспроводного канала с механизмом ARQ/FEC
7.7. Пакетирование ошибок
7.8. Расчёт характеристик потока ошибок по параметрам модели
7.8.1. Оценка параметров потока ошибок
7.8.2. Оценка адекватности модели потока ошибок
7.9. Марковские модели оценки QoS мультимедийных сервисов реального времени в Интернете
7.9.1. Понятие мультимедийных сервисов реального времени
7.9.2. Анализ и моделирование задержек и потерь
7.10. Модели потоков мультимедийного трафика
Контрольные вопросы

8 Системы массового обслуживания и их моделирование
8.1. Общая характеристика систем массового обслуживания
8.2. Структура системы массового обслуживания
8.3. Системы массового обслуживания с ожиданием
8.3.1. Система обслуживания M/M/1
8.3.2. Система обслуживания M/G/1
8.3.3. Сети с большим числом узлов, соединенных каналами связи
8.3.4. Приоритетное обслуживание
8.3.5. Система обслуживания M/M/N/m
8.4. Системы массового обслуживания с отказами
8.5. Общие принципы моделирования систем массового обслуживания
8.5.1. Метод статистических испытаний
8.5.2. Блочные модели процессов функционирования систем
8.5.3. Особенности моделирования с использованием Q-схем
Контрольные вопросы

9 Моделирование информационных систем с использованием типовых технических средств
9.1. Моделирование систем и языки программирования
9.2. Основные сведения о языке GPSS
9.2.1. Динамические объекты GPSS. Транзактно-ориентированные блоки (операторы)
9.2.2. Аппаратно-ориентированные блоки (операторы)
9.2.3. Многоканальное обслуживание
9.2.4. Статистические блоки GPSS
9.2.5. Операционные блоки GPSS
9.2.6. Другие блоки GPSS
9.3. Имитационное моделирование сети ETHERNET в среде GPSS
Контрольные вопросы

10 Моделирование систем передачи информации
10.1. Типовая система передачи данных
10.2. Помехоустойчивость передачи дискретных сигналов. Оптимальный прием
10.3. Оценка вероятности ошибочного приема дискретных сигналов с полностью известными параметрами
10.4. Помехоустойчивость дискретных сигналов со случайными параметрами
10.5. Помехоустойчивость дискретных сигналов при некогерентном приеме
10.6. Помехоустойчивость дискретных сигналов со случайными существенными параметрами
10.7. Алгоритмы формирования дискретных сигналов
10.8. Алгоритм формирования помехи
10.9. Алгоритм демодуляции дискретных сигналов
10.10. Структура имитационного комплекса и его подпрограмм
10.11. Программная среда Mathworks Matlab и пакет визуального моделирования Simulink
10.11.1. Техническое описание и интерфейс
10.11.2. Пакет визуального моделирования Simulink
10.11.3. Создание и маскирование подсистем
10.11.4. Пакет расширений Communications Toolbox
10.12. Моделирование блоков системы передачи данных стандарта WiMAX
10.12.1. Моделирование передатчика
10.12.2. Моделирование канала передачи
10.12.3. Моделирование приемника
10.12.4. Реализация модели в системе Mathlab
10.13. Результаты имитационного моделирования системы WiMAX
Контрольные вопросы

11 Самоподобные процессы и их применение в теле- коммуникациях
11.1. Основы теории фрактальных процессов
11.2. Мультифрактальные процессы
11.3. Оценка показателя Херста
11.4. Мультифрактальный анализ с использованием программного обеспечения
11.4.1. Описание программного обеспечения
11.4.2. Примеры оценки степени самоподобия
11.5. Алгоритмы и программное обеспечение для мультифрактального анализа
11.6. Влияние самоподобия трафика на характеристики системы обслуживания
11.7. Методы моделирования самоподобных процессов в теле-трафике
11.8. Исследование самоподобной структуры трафика Ethernet
11.9. Перегрузочное управление самоподобным трафиком
11.10. Фрактальное броуновское движение
11.10.1. RMD-алгоритм генерации ФБД
11.10.2. SRA-алгоритм генерации ФБД
11.12. Фрактальный гауссовский шум
11.12.1. БПФ-алгоритм синтеза ФГШ
11.12.2. Оценка результатов моделирования
Контрольные вопросы

12 Моделирование узла телекоммуникационной сети
12.1. Основные положения протокола Frame Relay
12.2. Проектирование узла сети Frame Relay
12.3. Результаты имитационного моделирования маршрутизатора FR с кодеками G.728 на входе
12.4. Влияние самоподобия трафика на QoS
Контрольные вопросы

13 Специализированные системы имитационного моделирования вычислительных сетей
13.1. Общая характеристика специализированных пакетов прикладных программ сетевого моделирования
13.2. Общие принципы моделирования в среде OPNET Modeler
13.3. Примеры применения OPNET
13.3.1. Модель для оценки качества обслуживания
13.3.2. Реализация модели локальной сети
Контрольные вопросы

14 Имитационное моделирование с помощью сетевого имитатора Network simulator 2
14.1. История создания и архитектура пакета NS2
14.2. Создание объекта имитатора
14.3. Создание топологии сети
14.4. Задание параметров генераторов
14.4.1. Exponential On/Off
14.4.2. Pareto On/Off
14.5. Два основных алгоритма организации очереди
14.6. Адаптивная маршрутизация в NS2
14.6.1. Интерфейс прикладного программирования на пользовательском уровне
14.6.2. Внутренняя архитектура
14.6.3. Расширения на другие классы
14.6.4. Недостатки
14.6.5. Список команд, используемых для имитации динамических сценариев в NS2
14.6.6. Пример динамической маршрутизация в NS2
14.7. Запуск программы сценария в NS2
14.8. Процедура обработки результатов моделирования
14.9. Пример моделирования беспроводной сети
14.10. Пример имитационного моделирования качества передачи потокового видео с использованием пакета NS 2
14.10.1. Структура программно-аппаратного комплекса для оценки качества потокового видео
14.10.2. Функциональные модули ПАК
14.10.3. Оценка качества видео