Основные понятия объектно - ориентированного подхода (ООП) к конструированию ПО.

Объектно-ориентированное проектирование ПО также декомпозирует программу на структурные единицы, которые называются объектами.

При этом объектно-ориентированное мышление семантически приближается к естественному человеческому мышлению.

Состояние объекта характеризуется перечнем и значением его свойств (атрибутов) в текущий момент времени.

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

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

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

Структурный и объектноориентированный методы проектирования разделяют ПО на все меньшие и меньшие подсистемы (модули), каждую из которых можно рассматривать и создавать независимо.

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

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

38. Мультиагентные технологии

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

1.До эпохи Windows - были линейные программы: много мелких утилит и консоль. Пользователь - программист, должен был знать API (параметры командной строки) + скриптовый язык (шелл-

скрипт). Это была эпоха обработки информации.

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

56

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

ников .

Поэтому можно назвать первые две отличительные особенности агентных технологий:

агенты отличаются самым главным - способом взаимодействия с пользователем;

агенты автономны - сами решают поставленные перед ними задачи.

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

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

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

При этом:

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

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

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

не существует единого правила в системе, которое описывало бы глобальное поведение.

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

тов могут вызывать сложное поведение и структуры».

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

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

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

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

39. Классы реального мира предметной области и искусственные объекты. Чрезмерно большие и неправильно названные классы

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

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

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

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

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

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

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

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

Одно из эвристических правил: избегайте создания классов, которые все знают и все могут. Если класс извлекает и задает данные других классов с использованием методов Get() и Set() (т. е. вмешивается в их де-

58

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

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

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

40. Эвристические приемы конструирования методов, предотвращение дублирования кода

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

Имя метода формирует абстракцию более высокого уровня, что облегчает чтение и понимание кода, а

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

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

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

[Введите текст]