Типичные черты исследовательского проекта




Скачать 381.19 Kb.
НазваниеТипичные черты исследовательского проекта
страница6/7
Дата публикации14.05.2014
Размер381.19 Kb.
ТипЛитература
literature-edu.ru > Лекции > Литература
1   2   3   4   5   6   7

ОО Проектирование


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

Процесс ОО проектирования производится по тем же принципам, что и ОО Анализ.

Исходные данные для проектирования


  • ОО Модель предметной области, построенная на этапе анализа.

  • ОО Модель доменов/ классов, построенная на предыдущем этапе проектирования.

  • Набор внешних тестов системы/ домена/ класса реализующих случаи использования.

  • Стандартные проектные решения (шаблоны проектирования).

Шаблоны проектирования – стандартные роли и ролевые модели взаимодействия для объектов системы. Например, упоминавшийся выше шаблон Фабрика.

Фабрика – объект, предоставляющий сервисы создания новых объектов. Примером фабрики является объект Класс, имеющий открытый конструктор.

Результат проектирования


  • ОО Модель системы/ домена/ класса, полностью идентифицирующая объекты, классы, структуры, атрибуты и сервисы входящих в нее объектов.

Аспекты системы


На этапе анализа рассматривается платформонезависимый аспект системы.

  • Аспект Предметной области (Problem Domain)

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

  • Аспект Пользовательского интерфейса (Human Interface)

  • Аспект Управления выполнением (Task Management)

  • Аспект Управления данными (Data Management)

Для каждого из этих аспектов выполняются те же виды деятельности, что и при анализе.

  1. Идентификация Объектов и Классов

  2. Идентификация Структур

  3. Идентификация Доменов

  4. Определение Атрибутов

  5. Определение Сервисов

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

Аспект предметной области


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

Аспект пользовательского интерфейса


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

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

Примеры низкоуровневых средств: Win32, Xlib. Прямой доступ к окнам и низкоуровневым компонентам. Библиотеки не содержат готовых к использованию классов для взаимодействия с пользователем. Инфраструктура ПИ должна содержаться в системе.

Примеры средств среднего уровня: Gnome, Motif, AWT, Swing, MFC. Библиотеки содержат набор готовых блоков, из которых можно построить визуальные компоненты системы. Система должна содержать небольшую прослойку, обеспечивающую взаимодействие стандартных визуальных элементов с данными.

Примеры средств высокого уровня: Chrome. Пользовательский интерфейс автоматически строится по модели данных.

Шаблон Модель-Наблюдатель




Модель – как правило, объект аспекта предметной области инкапсулирует данные и методы их изменения.

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

Аспект управления выполнением


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

Взаимодействие между объектами


Может быть синхронным и асинхронным.
Синхронное взаимодействие

Метод не возвращает управление, пока не будет достигнут конечный результат выполнения, то есть неопределенно долго. Пример: InputStream.read() не вернет управление пока не считает байт из потока.
Асинхронное взаимодействие

Метод является запросом на исполнение действия и возвращается немедленно. О результате действия сообщается другим способом.
Опрос (Polling)

После запроса на исполнение происходит периодический опрос объектов исполнителей о готовности результата. Чтение происходит по готовности результата. Например, InputStream.available() возвращает количество байтов, готовых для считывания, затем InputStream.read() может считать готовые байты без блокировки. Опрос является наименее эффективным способом асинхронного взаимодействия, поскольку интервал опроса выбирается произвольно и не зависит от момента готовности результата. Если интервал слишком маленький то возрастают накладные расходы на опрос, если слишком большой, то задержка с момента возникновения события до реакции системы. Метод опроса используется, только если нет возможности использовать другие методы.
Извещение (Notification)

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

По готовности результата он заворачивается в сообщение, и сообщение помещается в очередь объекта заказчика. Чтение результата происходит при обработке сообщения заказчиком без дополнительного взаимодействия с исполнителем. Эта техника является наиболее эффективной, но и наиболее сложной для реализации, поскольку требует реализации механизма асинхронного обмена сообщениями (Messaging) и очередей сообщений (Message Queue).

Параллелизм


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

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

Замечание: все механизмы синхронизации реализованы на базе считающего семафора (counting semaphore).

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

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

Внимание: если вы не используете синхронизацию, стандартные классы ввода-вывода и явно не отдаете время другим нитям (yield, sleep), то параллельные потоки команд не будут выполняться. Эта ситуация называется голоданием (starvation).

Сколько нитей обязательно необходимо системе? Одна нить для каждого синхронного взаимодействия плюс одна для асинхронных взаимодействий. Пример: система синхронно читает из 10 потоков ввода вывода и поддерживает асинхронный пользовательский интерфейс. Системе необходимо минимум 11 нитей.
Монитор (Monitor)

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

  • Monitor.enter() захватывает монитор, нить может вызывать enter любое количество раз при каждом последующем вызове счетчик захватов увеличивается на 1.

  • Monitor.exit() уменьшает счетчик захватов на 1, освобождает монитор, когда счетчик равен 0.

  • Monitor.wait() освобождает монитор и ожидает извещения, может быть выполнен только когда нить владеет монитором.

  • Monitor.notify() извещает нить, ожидающую извещения, может быть выполнен только когда нить владеет монитором.

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


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

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

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

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

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

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

С каждым объектом связывается монитор. Захват объекта транзакцией отображается в Monitor.enter(). Транзакция завершается, когда нить освободит все захваченные монитор. Механизм мониторов не гарантирует свойств транзакций и вложенных транзакций. Во многих случаях достаточно сохранить свойства атомарности непротиворечивости и устойчивости, пожертвовав независимостью для упрощения системы. Однако такой подход часто является причиной непредсказуемого поведения системы в некоторых ситуациях.
Неизменяемые объекты (Immutable objects)

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

Для реализации механизма наблюдаемости используется механизм раздельной блокировки чтения и записи (Read/Write Lock). Когда транзакция собирается только читать состояние объекта, она захватывает его на чтение. Любое количество транзакций могут одновременно захватить объект на чтение, если он не захвачен на запись. Если объект захвачен на запись, то транзакция ожидает его освобождения. Если транзакция собирается изменять объект, она захватывает его на запись и чтение. Только одна транзакция может захватить объект на запись и чтение одновременно, и только если объект свободен на чтение и запись. Если объект захвачен на чтение или запись, то нить блокируется до освобождения объекта.

Усиление захвата (Upgrade Lock). Можно ли сначала захватив объект на чтение захватить его и на запись? Нельзя. Прежде чем захватить объект на запись, транзакция должна дождаться освобождения его на чтение. Если две транзакции одновременно захотят усилить захват, то произойдет взаимная блокировка. Таким образом, перед захватом объекта на запись и чтение, нить должна сначала отпустить его на чтение.
Кеширование (Caching)

Можно ли сохранить свойство наблюдаемости во время исполнения транзакции, изменяющей состояние объекта? Да можно. Для этого пред началом транзакции надо сделать временную копию состояния объекта. Все транзакции, не изменяющие состояние объекта, могут читать временную копию состояния объекта. Этот подход является частичной реализацией оптимистической модели транзакций. Поскольку в каждый момент времени выполняется только одна изменяющая состояние транзакция, нет проблемы с разрешением конфликтов. Для сохранения состояния объекта используется клонирование (clone) (шаблон Прототип (Prototype)) или выделение состояния объекта в отдельный класс (шаблон Состояние (State)). Так же этот подход связан с неизменяемыми объектами, сохраненное состояние является неизменяемым объектом.

Аспект управления данными


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

Часто можно использовать простую эффективную технику сериализации.

Сериализация – сохранение объекта и связанных с ним объектов в потоке ввода/вывода.

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

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

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

Проблемы стандартных механизмов сериализации


    1. Производительность. Универсальные механизмы сериализации являются не слишком эффективными с точки зрения производительности.

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

    3. Совместимость различных версий классов. В течение разработки системы классы могут меняться. В зависимости от реализации сериализации, при чтении старой версии класса могут возникнуть проблемы.
1   2   3   4   5   6   7

Похожие:

Типичные черты исследовательского проекта iconКонспект внеклассного мероприятия «Подготовка к созданию учебного...
Конспект внеклассного мероприятия Подготовка к созданию учебного исследовательского проекта

Типичные черты исследовательского проекта iconСценарий проекта Полное название проекта «Солнце Русской поэзии»
Участники проекта – воспитанники, воспитатель, музыкальный родители

Типичные черты исследовательского проекта iconОтче т
Южного филиала федерального государственного бюджетного научно-исследовательского учреждения

Типичные черты исследовательского проекта iconОтче т
Южного филиала федерального государственного бюджетного научно-исследовательского учреждения

Типичные черты исследовательского проекта iconВладимир Исаевич Круковер 300 практических советов владельцам собак. Типичные ошибки

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

Типичные черты исследовательского проекта iconЧерты развития русской литературы XVIII века. Классицизм в русском и мировом искусстве
Цель – общий обзор «Черты развития русской литературы XVIII века», введение понятия «классицизм»

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

Типичные черты исследовательского проекта iconПлан мероприятий в рамках проекта «Этот загадочный Шерлок Холмс»
Составление учителями визитки проекта, методических и дидактических материалов к проекту и размещение их на школьном сайте

Типичные черты исследовательского проекта iconОтдела образования Администрации Макушинского района о реализации...
Од, о реализации проекта «Интеллектуал Зауралья» в образовательных учреждениях района. Был заслушан отчёт директора Макушинской сош...

Литература


При копировании материала укажите ссылку © 2015
контакты
literature-edu.ru
Поиск на сайте

Главная страница  Литература  Доклады  Рефераты  Курсовая работа  Лекции