Содержание

Введение.. 3

1. Модели и методы описания систем.. 4

1.1. SADT- модель. 4

1.2. Метод структурного подхода. 5

1.3. Метод объектного подхода. 8

1.4. Математические модели. 11

2. Применение моделей описания систем.. 14

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

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

Введение

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

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

Целью данной работы является рассмотрение методов и моделей описания систем.

Для этого необходимо решить следующие задачи:

- Дать общее понимание понятия система;

- Охарактеризовать основные модели-методы описания систем;

- Рассмотреть особенности применения методов описания систем.

1. Модели и методы описания систем

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

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

1.1. SADT- модель

SADT (аббревиатура выражения Structured Analysis and Design Technique - методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности.[2] SADT была создана и опробована на практике в период с 1969 по 1973 г. Эта методология возникла под сильным влиянием PLEX, концепции клеточной модели человек-ориентированных функций Хори, общей теории систем технологии программирования и даже кибернетики. С 1973 г. сфера ее использования существенно расширяется для решения задач, связанных с большими системами, такими, как проектирование телефонных коммуникаций реального времени, автоматизация производства (САМ), создание программного обеспечения для командных и управляющих систем, поддержка боеготовности. Она с успехом применялась для описания большого количества сложных искусственных систем из широкого спектра областей (банковское дело, очистка нефти, планирование промышленного производства, системы наведения ракет, организация материально-технического снабжения, методология планирования, технология программирования). Причина такого успеха заключается в том, что SADT является полной методологией для создания описания систем, основанной на концепциях системного моделирования.

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

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

1.2. Метод структурного подхода

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

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

Диаграмма потоков данных/модель бизнес-процессов (Data Flow Diagram/Business Process Model)[4]

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

Диаграмма "сущность - связь" (Entity Relationship Diagram)

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

Диаграмма переходов состояний (State Transition Diagram)

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

Структурная карта (Structure Chart)

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

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

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

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

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

1.3. Метод объектного подхода

Объектный подход содержит набор моделей, связанных с понятием класса/объекта, объединяющего данные (состояние) и поведение[5]. В настоящее время наиболее естественным является применение набора моделей, входящих в UML (универсальный язык моделирования), так как этот язык стандартизирован, широко используется и постоянно развивается. Распространенность языка UML можно объяснить тем, что он создан авторами трех самых известных в мире объектных методов (OMT, OOSE и Booch method). Прекращение "войны методов" и объединение ведущих специалистов привело к открытости и стандартной интерпретации моделей. Стандарт UML открыт для обсуждения и развивается при участии ведущих технологических фирм: Rational Software, Microsoft, Hewlett-Packard, Oracle, IBM, Platinum Technology и других. Использование единого языка моделирования позволяет специалистам разных стран "говорить" на одном языке. На таком языке удобно составлять технические спецификации на коммерческие программные продукты. А стандартизация моделей облегчит интеграцию средств моделирования с другими инструментами.

Диаграмма вариантов использования (Use Case Diagram)

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

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

Диаграмма взаимодействия (Interaction Diagram)

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

Диаграмма классов (Class Diagram)

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

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

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

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

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

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

Широко распространено заблуждение, что при создании программного обеспечения одна модель классов может быть использована для генерации кода на любом объектном языке программирования. Это неверно. Создавая модель классов, следует знать средство реализации. И для каждого языка программирования должны выполняться соответствующие требования. Например, в языке C++ множественное наследование имеется, а в языке Java - нет. И построить одну модель для эффективной реализации на языках C++ и Java нельзя. Здесь, как и в модели "сущность - связь", нет полной независимости от средств реализации.

1.4. Математические модели

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

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

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

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

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

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

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

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

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

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

2. Применение моделей описания систем

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

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

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

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

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

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

Заключение

В ходе работы была раскрыта основная ее цель – рассмотрение моделей и методов описания систем.

Так же были решены задачи:

- Дано общее понимание понятия система;

- Охарактеризованы основные модели-методы описания систем;

- Рассмотрены особенности применения методов описания систем.

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

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

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

1. Государственное управление. Словарь-справочник (по материалам "International Encyclopedia of Public Politic and Administration"). – М.: ООО "Издательство "Петрополис"", 2002.

2. Кулаков Ю.В., Шамкин В.Н. Математическое моделирование технологических объектов и систем управления. – Тамбов: ЮНИКС, 2003

3. Моисеев Н. Н. Алгоритмы развития. – М.: Наука, 2002.

4. Хакен г. Синергетика. – М.: Мир, 2003.

5. Эйген М., Винклер Р. Игра жизни. – М.: Наука, 2004.

[1] Моисеев Н. Н. Алгоритмы развития. – М.: Наука, 2002. – с. 71.

[2] Государственное управление. Словарь-справочник (по материалам "International Encyclopedia of Public Politic and Administration"). – М.: ООО "Издательство "Петрополис"", 2002. – с. 98.

[3] Хакен г. Синергетика. – М.: Мир, 2003. – с. 54.

[4] Моисеев Н. Н. Алгоритмы развития. – М.: Наука, 2002. – с. 105.

[5] Хакен г. Синергетика. – М.: Мир, 2003. – с. 74.

[6] Кулаков Ю.В., Шамкин В.Н. Математическое моделирование технологических объектов и систем управления. – Тамбов: ЮНИКС, 2003 – с. 61.

[7] Кулаков Ю.В., Шамкин В.Н. Математическое моделирование технологических объектов и систем управления. – Тамбов: ЮНИКС, 2003 – с. 146.