Симулятор файлового менеджера

Введение

 

 

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

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

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

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

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

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

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

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

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

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

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

Приложение будет содержать текст программы.

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

 

1 Постановка задачи

 

1.1 Организационная сущность задачи

 

 

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

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

В файловой системе каталог файлов требуется организовать как бинарное дерево. Для каждого файла в каталоге будут содержаться следующие сведения:

    • имя файла;
    • дата создания;
    • количество обращений к файлу.

Общие задачи, которые требуется  разработать в программном средстве:

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

Разработать интерфейс пользователя и справочную систему приложения.

В наши дни существует множество  аналогов данного продукта, но ведь у каждого пользователя свои ожидания и критерии  к программному продукту, тем самым  разработчиками программных приложений всегда будет к чему стремится, создавая каждый раз все более и более универсальные приложения. Самый популярный аналог в данной тематике это – Total Commander.

 Total Commander (ранее WinCmd) — файловый менеджер для Windows, наподобие Проводника Windows. Однако Total Commander использует иной подход: у него две постоянных панели бок о бок, как в хорошо известной DOS-оболочке (NC).

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

 

 

1.2 Информационная модель

 

 

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

Первый шаг моделирования  – извлечение информации и выделение сущностей.

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

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

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

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

Связь (Relationship) – поименованная  ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

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

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

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

У сущности «Файл» можно выделить следующие атрибуты:

    • имя;
    • дата создания;
    • количество обращений.

У сущности «Каталог» можно выделить следующие атрибуты:

    • имя;
    • дата создания;
    • количество обращений.

Схема Баркера-Ченна представлена на рисунке 1.

 

 

 

 

 

 

 

 

 

Рисунок 1 – Схема Баркера-Ченна

 

В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций – диаграмм. В терминах языка UML определены следующие виды диаграмм: диаграмма вариантов использования, диаграмма классов, диаграммы поведения (диаграмма состояния, диаграмма деятельности), диаграммы взаимодействия (диаграмма последовательности, диаграмма кооперации), диаграммы реализации (диаграмма компонентов, диаграмма развертывания). [4]

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

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

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

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

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

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

В состав данной предметной области  будут включаться следующие бизнес-процессы:

– создания элемента;

– удаление элемента;

– удаление по определенным критериям;

– предоставление справочной информации;

– возможность поиска файлов.

Диаграмма вариантов использования  представлена в графической части на листе 1.

Математическую модель, проектируемая система не имеет.

 

 

1.3 Входные данные

 

 

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

 

 

1.4 Выходные данные

 

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

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

 

 

2 Вычислительная система

 

2.1 Используемые технические  средства

 

 

Конфигурация компьютера, на котором  будет разрабатываться программное приложение:

- процессор Phenom x4 2,3 Гц;

- оперативная память DDR II 800 2048 Mb;

- жёсткий диск HDD Hitachi 1024 Gb 16mb cache;

- видеокарта ATI Sapphire Radeon HD 4850 512mb\256bit;

- материнская плата Gigabyte-P45;

- клавиатура Logitech;

- мышь.

 

 

2.2 Инструменты разработки

 

 

Инструментами разработки будут являться:

    • операционная система Windows Vista Ultimate;
    • среда Visual Studio 2008;
    • язык программирования С#;
    • CASE-среда Rational Rose 2000.

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

Для разработки данного программного приложения была использована Windows Vista. Данная операционная система является иновационно новой решением для домашнего использования. Данная версия операционной системы Windows сочетает в себе преимущества всех предыдущих версий, а именно: средства безопасности, управляемость и надежность, новый приятный интерфейс (поддержка Plug&Play, простой пользовательский интерфейс и передовые службы поддержки). Все эти достоинства делают Windows Vista наиболее подходящей операционной системой для настольных компьютеров, применяемых в корпоративной среде. [5]

    В целом стратегия Visual Studio .NET, нацеленная на реализацию концепции .NET за счет достижения максимальной производительности, включает три направления:

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

                - Предоставление разработчикам набора модернизированных взаимодействующих языков .NET, соответствующих имеющимся у разработчиков навыкам;

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

   Язык C# появился на свет в июне 2000 г. в результате кропотливой работы большой группы разработчиков компании Microsoft, возглавляемой Андерсом Хейлсбергом (Anders Hejlsberg). Этот человек известен как автор одного из первых компилируемых языков программирования для персональных компьютеров IBM -- Turbo Pascal. Наверное, на территории бывшего Советского Союза многие разработчики со стажем, да и просто люди, обучавшиеся в той или иной форме программированию в вузах, испытали на себе очарование и удобство использования этого продукта. Кроме того, во время работы в корпорации Borland Андерс Хейлсберг прославился созданием интегрированной среды Delphi (он руководил этим проектом вплоть до выхода версии 4.0). 

Появление языка C# и инициативы .NET отнюдь не случайно пришлось на начало лета 2000 г. Именно к этому моменту компания Microsoft подготовила промышленные версии новых компонентных технологий и решений в области обмена сообщениями и данными, а также создания Internet-приложений (COM+, ASP+, ADO+, SOAP, Biztalk Framework). Несомненно, лучшим способом продвижения этих новинок является создание инструментария для разработчиков с их полноценной поддержкой. В этом и заключается одна из главных задач нового языка C#. Кроме того, Microsoft не могла больше расширять все те же инструменты и языки разработки, делая их все более и более сложными для удовлетворения конфликтующих между собой требований поддержки современного оборудования и обеспечения обратной совместимости с теми продуктами, которые были созданы в начале 1990-х гг. во время первого появления Windows. Наступает момент, когда необходимо начать с чистого листа для того, чтобы создать простой, но имеющий сложную структуру набор языков, сред и средств разработки, которые позволят разработчику легко создавать современные программные продукты.[3] 
         С# и .NET являются той самой отправной точкой. Если говорить упрощенно, то .NET представляет собой новую платформу, новый API для программирования в Windows, а С# е новый язык, созданный с нуля, для работы с этой платформой, а также для извлечения всех выгод из прогресса сред разработки и нашего понимания принципов объектно-ориентированного программирования в течение последних 20 лет. [2] 
            Необходимо отметить, что обратная совместимость не потеряна. Существующие программы будут выполняться, а платформа .NET была спроектирована таким образом, чтобы она могла работать с имеющимся программным обеспечением. Связь между компонентами в Windows сейчас почти целиком осуществляется при помощи СОМ. С учетом этого .NET обладает способностью (а) создавать оболочки (wrappers) вокруг существующих компонентов СОМ, так что компоненты .NET могут общаться с ними, и (б) создавать оболочки вокруг компонентов .NET, что позволяет им выглядеть как обычные СОМ-компоненты.

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

 

 

3 Проектирование задачи

 

3.1 Объектно-ориентированный  анализ

 

 

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

  Основными свойствами ООП являются: инкапсуляция, наследование, полиморфизм.

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

            Сокрытие данных — неотделимая часть ООП, управляющая областями видимости. Является логическим продолжением инкапсуляции. Целью сокрытия является невозможность для пользователя узнать или испортить внутреннее состояние объекта.  

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

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

Центральное место в объектно-ориентированном анализе программы занимает разработка логической модели системы в виде диаграммы классов. Нотация классов в языке UML проста и понятна. Диаграмма классов позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов.

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

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

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

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

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

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

В проектируемой системе используются стандартные классы: Tlabel, Tbutton,            TMaskedTextBox, TTextBox, TtreeView, TmenuStrip, TsaveFileDialog, TcontextMenuStrip, TimageList. Также присутствует пользовательский класс ClassSaveTree и ClassTag, так же изображенный на диаграмме классов. Диаграмма классов для проектируемой системы представлена в графической части на листе 2.

Компоненты класса TLabel (метки) предназначены для размещения на форме различного рода текстовых надписей.

Компонент класса TTextBox представляет собой однострочный редактор текста. С его помощью можно вводить и (или) отображать достаточно длинные текстовые строки.

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

Компонент TtreeView  предназначен для отображения дерева с элементами.

Пользовательский класс ClassSaveTree предназначен для создания, сохранения дерева файлов и каталогов. Описание классов ClassSaveTree и ClassTag представлены ниже.

public class ClassTag

    {

        public string tag;

        public DateTime date;

        public int request;

        public string extencion;

    }

 

  public class ClassSaveTree

    {

        private string caption;

        public ClassTag tag;

        private int level;

        private int index;

 

        public ClassSaveTree() {…}

 

        public ClassSaveTree(string cap, ClassTag t, int lev, int ind)  {…}

       

        public string getCaption()

        {

            return caption;

        }

        public int getLevel()

        {

            return level;

        }

        public int getIndex()

        {

            return index;

        }

    }

Опишем назначение переменных и  методов класса.

Переменная типа string - caption отвечает за имя создаваемого элемента.

Переменная типа int request  - отвечает за количесвто обращений к элементу.

Переменная типа string extencion – отвечает за расширения элемента, при создании файла сразу заносится его расширение, что облегчает поиск.

Переменная типа string tag – отвечает за принадлежность создаваемого элемента к файлу или каталогу. Принимает значения: «FILE» или «DIR»

Переменная типа int level – отвечает за расположение в дереве. Родитель или наследник или «наследник наследника»

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

Метод ClassSaveTree() отвечает за получение имени и индекса сразу эти пораменты присваиваются по нулям.

Метод ClassSaveTree(string cap, ClassTag t, int lev, int ind) отвечает за характеристики элементв в дереве, а именно за: имя, файл или каталог, существует ли принадлежность к другим каталогам, и индекс в самом дереве.     

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

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

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

Диаграмма деятельности для проектируемой системы представлена в графической части на листе 3.

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