Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Что такое функционирование в «Реальном масштабе времени»↑ Стр 1 из 9Следующая ⇒ Содержание книги
Поиск на нашем сайте
Что такое функционирование в «Реальном масштабе времени» Каноническое определение системы реального времени дано Дональдом Гиллиесом и выглядит так: «Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в которое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы». Другие добавляют: «Поэтому необходимо, чтобы было гарантировано выполнение требований по времени. Гарантия выполнения требований по времени необходима, чтобы поведение системы было предсказуемо. Также желательно, чтобы система обеспечивала высокую степень использования ресурсов, чтобы удовлетворять требованиям по времени». ОС РВ характеризуется прежде всего малым временем реакции на внешние события. Последние версии ОС имеют прерываемое микроядро, что гарантирует быструю реакцию на внешнее событие при любом состоянии системы. Особенность большинства ОС – возможность стопроцентного размещения в памяти ядра, сетевого и графического обеспечения, драйверов и прикладных программ. Для встроенных бездисковых систем это чрезвычайно важно. Традиционно ОС РВ делятся на "жесткие" и "мягкие". Система "жесткого" РВ должна без сбоев отвечать на внешние события в рамках заранее определенного интервала времени. Время ответа должно быть предсказуемым и не зависеть от текущего состояния системы. "Мягкая" ОС РВ тоже должна отвечать очень быстро, но гарантированное время ответа в ней не обеспечивается. Здесь нужно отметить, что временные характеристики последних версий промышленных ОС практически стерли ранее существовавшую грань между двумя этими разновидностями. Сейчас OS-9, ранее считавшаяся "мягкой" ОС, практически не уступает классическим "жестким" ОС - pSOS+ и VxWorks. Ядра и операционные системы реального времени Примем как очевидные следующие моменты. 1. Когда-то операционных систем совсем не было. 2. Через некоторое время после их появления возникло направление ОС РВ. 3. Все ОС РВ являются многозадачными операционными системами. Задачи делят между собой ресурсы вычислительной системы, в том числе и процессорное время. Четкой границы между ядром (Kernel) и операционной системой нет. Различают их, как правило, по набору функциональных возможностей. Ядра предоставляют пользователю такие базовые функции, как планирование и синхронизация задач, межзадачная коммуникация, управление памятью и т.п. Операционные системы в дополнение к этому имеют файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого уровня. По своей внутренней архитектуре ОС РВ можно условно разделить на монолитные ОС, ОС на основе микроядра и объектно-ориентированные ОС. Задачи, процессы, потоки Принято различать две разновидности задач: процессы и потоки. Процесс представляет собой отдельно загружаемый программный модуль (файл), который, как правило, во время исполнения имеет в памяти свои независимые области для кода и данных. В отличие от этого потоки могут пользоваться общими участками кода и данных в рамках единого программного модуля. Преимущества потоков. 1. Так как множество потоков способно размещаться внутри одного EXE-модуля, это позволяет экономить ресурсы как внешней, так и внутренней памяти. 2. Использование потоками общей области памяти позволяет эффективно организовать межзадачный обмен сообщениями (достаточно передать указатель на сообщение). Процессы не имеют общей области памяти. 3. Как правило, контекст потоков меньше, чем контекст процессов, а значит, время переключения между задачами-потоками меньше, чем между задачами-процессами. 4. Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕ-модуле, значительно упрощается использование программ-отладчиков Недостатки потоков. 1. Как правило, потоки не могут быть подгружены динамически. Процессы, в отличие от потоков, подгружаемы, что позволяет динамически изменять функции системы в процессе ее работы. 2. То, что потоки имеют доступ к областям данных друг друга, может привести к ситуации, когда некорректно работающий поток способен испортить данные другого потока. В отличие от этого процессы защищены от взаимного влияния, а попытка записи в «не свою» память приводит, как правило, к возникновению специального прерывания по обработке «исключительных ситуаций». Реализация механизмов управления процессами и потоками, возможность их взаимного сосуществования и взаимодействия определяются конкретным ПО РВ. Основные свойства задач Приоритет – это некое целое число, присваиваемое задаче и характеризующее ее важность по сравнению с другими задачами, выполняемыми в системе. Приоритет используется в основном планировщиком задач для определения того, какая из готовых к работе задач должна получить управление. Различают системы с динамической и статической приоритетностью. Контекст задачи – это набор данных, содержащий всю необходимую информацию для возобновления выполнения задачи с того места, где она была ранее прервана. Планировщик задач в случае необходимости сохраняет контекст текущей активной задачи и восстанавливает контекст задачи, назначенной к исполнению. Такое переключение контекстов и является, по сути, основным механизмом ОС РВ при переходе от выполнения одной задачи к выполнению другой. Состояние (статус) задачи. С точки зрения операционной системы, задача может находиться в нескольких состояниях. Тем не менее, практически в любой ОС РВ загруженная на выполнение задача может находиться, по крайней мере, в трех состояниях. 1. Активная задача – это задача, выполняемая системой в текущий момент времени. 2. Готовая задача – это задача, готовая к выполнению и ожидающая у планировщика своей «очереди». 3. Блокированная задача – это задача, выполнение которой приостановлено до наступления определенных событий. Пустая задача – это задача, запускаемая самой операционной системой в момент инициализации и выполняемая только тогда, когда в системе нег других готовых для выполнения задач. Пустая задача запускается с самым низким приоритетом и, как правило, представляет собой бесконечный цикл «ничего не делать». Многократный запуск задач. Как правило, многозадачные ОС позволяют запускать несколько копий одной и той же задачи. В целях экономии памяти может быть предусмотрено совместное использование одного и того же исполняемого кода для всех запущенных копий. В этом случае программа должна обеспечивать повторную входимость (реентерабельность). Реентерабельность (повторная входимость) означает возможность без негативных последствий временно прервать выполнение какой-либо функции или подпрограммы, а затем вызвать эту функцию или подпрограмму снова. Планирование задач Важной частью любой ОС РВ является планировщик задач. Его функции остаются теми же: определить, какая из задач должна выполняться в системе в каждый конкретный момент времени. Самым простым методом планирования, не требующим никакого специального ПО и планировщика как такового, является использование циклического алгоритма стиле round robin: Каждая «задача», представляющая собой отдельную подпрограмму, выполняется циклически. При этом надо придерживаться следующих правил: 1. Подпрограммы не должны содержать циклов ожидания 2. Подпрограммы должны выполнять свою работу как можно быстрее 3. При необходимости подпрограмма может сохранять свое окружение и текущие результаты, чтобы в следующем цикле возобновить работу с того же места. Можно отметить следующие преимущества циклического алгоритма. 1. Простота использования и прозрачность для понимания. 2. Минимальные размеры кода и данных. Кроме того, в отличие от алгоритмов с вытеснением, для всех задач необходим только один стек. К недостаткам циклического алгоритма можно отнести отсутствие приоритетности и очередей. К тому же задачи вызываются независимо от того, должны ли они в данный момент что-либо делать или нет, а на прикладного программиста ложится максимальная ответственность за работоспособность системы. Кооперативная многозадачность – это еще один алгоритм переключения задач. Задача, получившая управление, выполняется до тех пор, пока она сама по своей инициативе не передаст управление другой задаче. Приоритетная многозадачность с вытеснением – это, по-видимому, наиболее часто используемый в ОС РВ принцип планирования. Основная идея состоит в том, что высокоприоритетная задача как только для нее появляется работа, немедленно прерывает низкоприоритетную. Необходимо отметить, что в одной вычислительной системе могут одновременно сосуществовать задачи и «жесткого», и «мягкого» реального времени, и что только одна из этих задач, обладающая наивысшим приоритетом, может быть по-настоящему детерминированной. Как правило, разработчики стараются свести свою систему реального времени к наиболее простым конфигурациям, характерным для систем «жесткого» реального времени, иногда даже в ущерб эффективности использования вычислительных ресурсов. Часто в системе реализуется несколько «режимов» работы, каждый из которых имеет свой набор выполняемых задач с заранее заданными приоритетами. Значительная часть особо ответственных систем по-прежнему реализуется без применения коммерческих ОС РВ вообще. Синхронизация задач Хотя каждая задача в системе как правило, выполняет какую-либо отдельную функцию, часто возникает необходимость в согласованности (синхронизации) действий, выполняемых различными задачами. Такая синхронизация необходима, в основном, в следующих случаях. 1. Функции, выполняемые различными задачами, связаны друг с другом. Одна из вариаций в этом случае – это когда задача при определенных условиях порождает одну или несколько новых задач. 2. Необходимо упорядочить доступ нескольких задач к разделяемому ресурсу. 3. Необходима синхронизация задачи с внешними событиями. Как правило, для этого используется механизм прерываний. 4. Необходима синхронизация задачи по времени. Для решения этих вопросов в конечном счете используются специальные аппаратные средства, называемые таймером. Тестирование Прежде чем устанавливать вашу систему реального времени, рекомендуется проверить ее работоспособность с помощью интенсивных тестов. Это особенно важно для сложных динамических систем. Во время такого тестирования желательно смоделировать наиболее неприятные и «тяжелые» режимы работы, аварийные ситуации и т.п. При умозрительном анализе простых систем следует осторожно относиться к рекламной информации разработчиков ОС РВ, которые из коммерческих соображений показывают, как правило, параметры для «лучшего случая». Linux реального времени У Linux много достоинств: открытость кода; большое количество сопутствующего программного обеспечения, пока в основном ориентированного на серверные применения; наличие неплохой документации на API-интерфейс и ядро операционной системы; работа на процессорах различных классов. В данный момент эта ОС готова к стабильной работе, а открытость ее исходных текстов и архитектуры наряду с растущей популярностью заставляет программистов переносить свои наработки на многие аппаратные платформы. Для задач реального времени сообщество разработчиков Linux активно применяет специальные расширения – RTLinux, KURT и UTIME, позволяющие получить устойчивую среду реального времени. RTLinux представляет собой систему "жесткого" реального времени, а KURT (KU Real Time Linux) относится к системам "мягкого" реального времени. Linux-расширение UTIME, входящее в состав KURT, позволяет добиться увеличения частоты системных часов, что приводит к более быстрому переключению контекста задач. Операционная система QNX QNX – это первая коммерческая ОС, построенная на принципах микроядра и обмена сообщениями. Система реализована в виде совокупности независимых (но взаимодействующих через обмен сообщениями) процессов различного уровня, каждый из которых реализует определенный вид сервиса. Предсказуемость, означающую ее применимость к задачам жесткого реального времени. Ни одна версия Unix не может достичь подобного качества, поскольку нереентрабельный код ядра слишком велик. Любой системный вызов в Unix может привести к непредсказуемой задержке. То же самое относится к Windows NT, где реальное время заканчивается между ISR (первичный обработчик прерывания) и DPC (вызов отложенной процедуры). Масштабируемость и эффективность, достигаемую оптимальным использованием ресурсов и означающую ее применимость для встроенных систем. Можно иметь только тот сервис или те модули, которые реально нужны, причем это не требует серьезных усилий и не порождает проблемы. Расширяемость и надежность одновременно, поскольку написанный вами драйвер не нужно компилировать в ядро, рискуя вызвать нестабильность системы. Быстрый сетевой протокол FLEET, прозрачный для обмена сообщениями, автоматически обеспечивающий отказоустойчивость, балансирование нагрузки и маршрутизацию между альтернативными путями доступа. Он не так универсален, как TCP/IP, но гораздо проще в использовании и эффективнее. Богатый выбор графических подсистем, включающий QNX Windows, X11R5 и Photon, что позволяет разработчикам выбирать ту, которая лучше подходит для их целей. Существуют также некоторые ограничения, связанные с ориентацией системы на рынок встроенных систем реального времени. Вот важнейшие из них: – нет поддержки SMP; – нет своппинга виртуальной памяти на диск; – неэффективная и нестандартная поддержка нитей (threads); – нет поддержки Java (как следствие предыдущего пункта); – нет поддержки отображения файлов в память; – многочисленные ограничения файловой системы; – нет поддержки Unix-domain sockets; – слабые средства разграничения и контроля доступа пользователей; – отсутствие средств безопасности в рамках собственного сетевого протокола. Проект Neutrino Еще до появления Windows 95, стартовал проект создания совершенно новой ОС, которая могла бы воплотить в себе лучшие идеи, разработанные в теории операционных систем. Этот проект получил кодовое название "Neutrino", довольно удачно отражающее его суть – очень маленькая и неуловимо быстрая ОС. глобальная цель проекта Neutrino – создание POSIX-совместимой масштабируемой ОС, пригодной для построения систем реального времени на самом широком спектре оборудования. термин "Neutrino", если говорить конкретно, применяется на данном этапе не ко всей ОС, а лишь к ее микроядру. Neutrino представляет собой значительно более совершенную модель, выполняющую гораздо больше функций, чем микроядро QNX, имея при этом лучшую производительность и временные характеристики. Улучшенное микроядро позволило также вчетверо уменьшить размер менеджера процессов (с 80 до 20 Кбайт). Функции, включенные в микроядро, были выбраны по принципу минимального количества операций, необходимых для их исполнения. Все относительно сложные функции были вынесены во внешние модули. По этой причине Neutrino остается достаточно маленьким и простым и по-прежнему оправдывает название "микроядра". управление процессами и памятью не является, строго говоря, функцией Neutrino – это функция менеджера процессов ProcNto, который, кроме этого, занимается поддержкой пространства имен ввода/вывода Сетевой сервис в Neutrino представлен только протоколом TCP/IP. Разработчики создали специальную версию стека для встроенных систем – Micro TCP/IP, который занимает всего около 40 Кбайт кода за счет ряда ограничений. Для тех же, кому нужны все возможности TCP/IP, например динамическая маршрутизация, будет предоставлен другой вариант, совместимый на 100% с BSD-sockets. Файловая система в Neutrino реализована иначе, чем в QNX. Главное функциональное отличие – улучшенная приспособленность к сменным носителям. Теперь приложение обращается к драйверу, который определяет тип файловой системы (по сигнатурам) и динамически загружает соответствующую файловую систему, реализованную в виде разделяемой библиотеки. Аппаратная архитектура Для разработчиков систем автоматизации стандарты – это возможность создавать открытые модульные комплексы из готовых программных и аппаратных блоков разных производителей. Выигрывают и поставщики – во-первых, они могут действовать на всем рынке, а не только на своей частной делянке. Во-вторых, они получают доступ к профессионально разработанным спецификациям открытых стандартов, для которых не требуется приобретение патентов и которые не защищены авторским правом. Успех стандарта не определяется постановлением правительства. Он будет продуктивен при условии, что его поддерживают поставщики, разработчики и потребители. И уж во всяком случае стандарт должен развиваться, отражая постоянно растущий потенциал базовых технологий. В этом плане в области систем управления жизнь кипит: при изобилии стандартов разного уровня идет жесткая конкурентная борьба альтернативных подходов. Технологии VME и PCI По отмеченным причинам одним из основных архитектурных решений для систем промышленной автоматизации является магистрально-модульная архитектура, в которой различные внешние блоки – модули связываются между собой через общую магистраль. Первым из получивших широкое признание международных стандартов на магистрально-модульные системы стал принятый в 1968 году стандарт CAMAC. Сегодня уже очевидно, что большинство разработчиков систем промышленной автоматизации практически отказались от применения нестандартных технических решений (их доля снизилась до 12%), возможно даже в ущерб техническим характеристикам, ориентируясь на стандарты де-факто и де-юре. Мезонинные технологии Мезонинные технологии применяются достаточно давно: в середине 80-х не было способа запаивать на основной плате кристаллы памяти емкостью более 64 Кбайт, и для увеличения ее объема использовались мезонинные модули. Сейчас, когда степень интеграции микросхем гораздо выше, на одной плате размещается простой компьютер со всеми соответствующими электронными атрибутами, и еще остается место. Мезонинные технологии приобрели новый смысл – сегодня это средство модульного наращивания функциональных возможностей. Взяв за основу типовую плату, разработчик может добавить к ней специальные пользовательские функции, реализованные в готовом мезонинном модуле. Таким образом, мезонинные платы представляют еще один, более низкий по сравнению, например, с модулями VMEbus уровень модульности. Типичный размер мезонинных плат 50×80 мм. Они являются функционально законченными изделиями и устанавливаются на плату-носитель Полевые системы Для связи с удаленными цифровыми устройствами промышленного назначения принято использовать бит-последовательные промышленные или полевые шины. PROFIBUS-FMS представляет собой решение для задач взаимодействия на цеховом и полевом (field) уровне иерархии промышленных связей: с его помощью организуется обмен между интеллектуальными field-устройствами и контроллерами, а также между контроллерами. Как правило, на этом уровне обмен информацией осуществляется по запросу прикладного процесса и не является циклическим. Поэтому время реакции здесь не очень существенно, гораздо важнее функциональные возможности. Модель PROFIBUS позволяет определить коммуникационные связи, объединяющие распределенные прикладные процессы в один общий. Та часть прикладного процесса field-устройства, которая отвечает за взаимодействие, называется виртуальным field-устройством (VFD). Все объекты реального устройства, с которыми можно взаимодействовать (переменные, программы, диапазоны данных), называются объектами коммуникации. Отображение функций VFD на реальное устройство обеспечивается в коммуникационной модели PROFIBUS интерфейсом прикладного уровня. Для этого объекты коммуникации PROFIBUS-станции вводятся в ее локальный словарь объектов – OD. Конфигурация OD может определяться и загружаться в устройство либо его производителем, либо разработчиком или может формироваться динамически. OD содержит структуру и типы всех объектов, а также их внутренние адреса в устройстве и представление на шине (индекс/имя). Доступ к объектам при функционировании происходит через сервисные функции протокола PROFIBUS-FMS, которые позволяют, например, опросить/установить значения переменных и массивов, запустить/остановить программу. Управление производством Верхний уровень в комплексе FactorySuite занимает пакет InTrack – инструментарий для разработки систем управления производством. Продолжая линию, заложенную в пакете InTouch, он поддерживает объектно-ориентированный стиль разработки и имеет архитектуру клиент/сервер. Назначение InTrack – создание интерактивных приложений, способных контролировать и управлять всеми стадиями производственных процессов – от загрузки сырья до выпуска готовой продукции. Основные принципы в InTrack такие же, как и в InTouch, – работа с переменными, графическими образами и обработка предупредительных сообщений. Добавлено понятие схемы производственных процессов как некоторой последовательности операций. Схемы создаются в специальном графическом редакторе из графических образов, поставляемых в библиотеке InTrack. Среди них производственные цепочки и операции, материальные ресурсы, продукты. В результате приложение, разработанное в InTrack, способно автоматизировать сбор данных и выдавать управляющие воздействия на производственные процессы в масштабах целого предприятия. Метод и нотация Метод проектирования и нотация проектирования – это разные вещи. Нотация проектирования ПО предназначена для описания самого проекта. Хотя она и предполагает наличие определенного подхода к проектированию, сам подход остается за ее рамками. Метод проектирования ПО представляет собой систематическое описание этапов создания проекта. Нотация проектирования ПО описывает.проект программы в графическом или текстовом виде. В частности, диаграммы классов – это графическая нотация, а псевдокод – текстовая. Концепция проектирования ПО – это фундаментальная идея, применимая к проектированию всей системы, например сокрытие информации. Стратегия проектирования ПО – общий план и методика выполнения проекта. Одной из стратегий является объектно-ориентированная декомпозиция. Критерии структурирования ПО – это эвристические или формальные правила, помогающие проектировщику разбить систему на отдельные компоненты. Так, критерии разбиения на объекты - это правила декомпозиции системы на объекты. Метод проектирования ПО описывает последовательность шагов, выполняемых при работе над проектом при условии, что требования к системе уже сформулированы. Он помогает выявить, какие решения предстоит принять, в каком порядке это следует делать и на основе каких критериев. Метод проектирования базируется на наборе соответствующих концепций, использует одну или несколько стратегий, а также ту или иную нотацию для документирования результатов. При выполнении определенных шагов метод может подсказать разработчику, какие критерии наиболее удобны для декомпозиции системы. Диаграммы классов На такой диаграмме классы изображаются в виде прямоугольников, а статические (постоянные) отношения между ними – в форме дуг. Поддерживаются три основных типа отношений между классами: – ассоциации. Ассоциация между двумя классами (бинарная ассоциация) изображается в виде линии, соединяющей прямоугольники классов. У нее есть имя и, возможно, стрелка, поясняющая, в каком направлении следует это имя читать. На каждом конце ассоциации проставляется кратность – число, свидетельствующее, сколько экземпляров одного класса связано с одним экземпляром другого класса. Дополнительно на каждом конце ассоциации может присутствовать стрелка, указывающая направление навигации вдоль данной ассоциации. – иерархии агрегирования и композиции. Это отношения вида целое/часть. Отношение композиции (изображается закрашенным ромбом) накладывает более сильные ограничения на экземпляры классов, чем отношение агрегирования (показывается незакрашенным ромбом). Ромб одной вершиной примыкает к прямоугольнику класса, являющегося частью в отношении вида «часть/целое»; – иерархия обобщения/специализации. Это отношение вида «является». Обобщение изображается в виде стрелки, ведущей от подкласса (потомка) к суперклассу (родителю), причем стрелка упирается в прямоугольник суперкласса. Видимость определяет, доступен ли элемент класса вне самого класса. Показывать видимость на диаграмме необязательно. Открытая видимость, изображаемая символом + (плюс), означает, что элемент виден извне класса. Закрытая видимость, отмеченная знаком – (минус), свидетельствует о том, что элемент виден только внутри класса, в котором он определен, а от других классов скрыт. Защищенная видимость, показываемая знаком #, говорит о том, что элемент виден внутри класса, в котором определен, а также во всех подклассах этого класса. Диаграммы взаимодействия В UML есть два вида диаграмм взаимодействия: диаграммы кооперации (collaboration diagram) и диаграммы последовательности (sequence diagram). Семантически они эквивалентны. Диаграммы кооперации. На диаграмме кооперации показывается, как объекты динамически общаются между собой, посылая и получая сообщения. Эта диаграмма представляет структурную организацию взаимодействующих объектов, изображаемых в виде прямоугольников и соединяющих их дуг. Помеченные стрелки рядом с дугами обозначают имя сообщения и направление его передачи между объектами. Отдельные сообщения в последовательности сообщений, отправляемых от одного объекта к другому, нумеруются. Диаграмма кооперации в нотации UML
Диаграммы последовательности. Другой способ показать взаимодействие объектов – воспользоваться диаграммой последовательности. Диаграмма последовательности двумерна: участвующие объекты изображаются вдоль горизонтальной оси, а время откладывается вдоль вертикальной. От прямоугольника каждого объекта идет вниз вертикальная пунктирная линия, называемая линией жизни. Период, в течение которого объект выполняет операцию, именуется активизацией. На протяжении этого периода линия жизни изображается двойной сплошной линией. Актер обычно изображается в левом верхнем углу диаграммы. Помеченные горизонтальные линии представляют пересылку сообщений. Существенны только отправитель и получатель сообщения. Сообщение посылается объектом-отправителем объекту-получателю. Время возрастает в направлении сверху вниз. Расстояние по вертикали между сообщениями не имеет значения. Диаграммы состояний В нотации UML диаграмма перехода состояний называется диаграммой состояний. На ней состояния представляются прямоугольниками со скругленными углами, а переходы – соединяющими их дугами (рис. 6.7). Начальное состояние обозначается дугой, исходящей из маленького закрашенного кружка. Может также присутствовать необязательное конечное состояние, изображаемое закрашенным кружком внутри незакрашенного (иногда его называют «бычий глаз»). Диаграмму состояний разрешается подвергнуть иерархической декомпозиции, так что надсостояние разлагается на подсостояния. Рядом с дугой, представляющей переход, находится условие перехода в виде: Событие [условие]/Действие. Событие вызывает переход в новое состояние. Если задано необязательное булевское условие, то переход осуществится, когда оно истинно. В результате перехода может быть выполнено необязательное действие. Дополнительно с состоянием иногда ассоциируются: – действие при входе в состояние; – деятельность, выполняемая во время нахождения внутри состояния; – действие при выходе из состояния. Пакеты В UML пакетом называется группа элементов модели, используемая, например, для представления системы или подсистемы. Такая группа изображается пиктограммой папки – большим прямоугольником, над которым находится прямоугольник поменьше. Пакеты бывают вложенными; между ними могут существовать отношения зависимости и обобщения/специализации. Пакеты способны содержать классы, объекты или прецеденты.
Нотация UML для пакетов Диаграммы развертывания На диаграмме развертывания очерчивается физическая конфигурация системы, то есть физические узлы и соединения между ними (например, связывающая их сеть). Узел представляется в виде куба, а соединение – в виде линии, ведущей от одного куба к другому. По сути, диаграмма развертывания – не что иное, как диаграмма классов с акцентом на узлах системы [16]. Узлом, как правило, является компьютер, при этом максимальное число экземпляров узла может быть ограничено (см. раздел 6.10). Для физического соединения имеется стереотип, задающий Механизмы расширения UML В UML имеется три механизма расширения языка [16]: – стереотипы. Стереотип определяет новый строительный блок, производный от существующего в UML элемента моделирования, но адаптированный к решаемой задаче. В UML определено несколько стандартных стереотипов, но проектировщик может создавать и собственные. Названия стереотипов заключаются в кавычки. – помеченные значения. Помеченное значение расширяет свойства строительного блока UML, сообщая тем самым новую информацию. Оно заключается в фигурные скобки {метка = значение}. Друг от друга помеченные значения отделяются запятыми. – ограничения. Ограничение задает условие, которое должно выполняться. В UML ограничение семантически расширяет элемент, добавляя новые правила или изменяя существующие. Планирование задач В системе с одним процессором ядро операционной системы должно планировать доступ параллельных задач к процессору. Ядро поддерживает список готовых к работе задач. Для назначения центрального процессора (ЦП) задачам было разработано много разных алгоритмов, в том числе циклическое обслуживание и вытесняющее планирование с приоритетами. Алгоритмы планирования задач. Цель циклического алгоритма планирования – обеспечить справедливое выделение ресурсов. Задача ставится в очередь, поддерживающую принцип «первым пришел – первым обслужен» (FIFO). Для систем реального времени циклическое планирование не годится. Задачам нужно назначать приоритеты в соответствии с важностью выполняемых операций. Так, критичные по времени задачи обязательно должны уложиться в отведенные временные рамки. Поэтому для систем реального времени больше подходит алгоритм вытесняющего планирования с приоритетами. Каждой задаче назначается приоритет, и список готовых упорядочивается по значению этого приоритета. ЦП выделяется задаче с наивысшим приоритетом. Затем эта задача выполняется до тех пор, пока не приостановится сама либо не будет вытеснена задачей с большим приоритетом (которая только что возобновила работу). Задачам с одинаковыми приоритетами ЦП выделяется по циклическому алгоритму. Контекстное переключение задач. Если задача приостанавливается из-за блокировки или потому что ее вытеснили, необходимо сохранить текущий контекст, то есть состояние процессора. Сюда относятся аппаратные регистры, счетчик команд задачи (который указывает на следующую команду, подлежащую выполнению) и другая информация. Когда задача снова получит ЦП, контекст требуется восстановить. Эта последовательность операций называется контекстным переключением. В мультипроцессорной среде с разделяемой памятью копия ядра обычно выполняется на каждом процессоре. Процессор выбирает задачу, находящуюся в начале списка готовых. Взаимно исключающий доступ к списку обеспечивает аппаратный семафор, который обычно реализуется с помощью команды Test and Set Lock (проверить и установить замок). Таким образом, одна и та же задача может в разные моменты времени исполняться на разных процессорах. В некоторых мультипроцессорных средах потоки одного многопоточного процесса могут параллельно выполняться на разных процессорах. Вопросы ввода/вывода в операционной системе Рассмотрим способы, которые операционная система применяет для работы с устройствами ввода/вывода. Существует два механизма выполнения ввода/вывода: прерывания и опрос. Рассмотрим как параллельные задачи взаимодействуют с внешними устройствами. Устройства ввода/вывода общаются с операционной системой при помощи контроллеров, которые находятся на интерфейсных платах устройства). Центральный процессор работает именно с контроллером, а не с самим устройством. У контроллера есть набор регистров, используемых для обмена информацией с ЦП. В некоторых компьютерах имеются специальные команды для доступа к регистрам контроллера. Если же применяется отображение устройств на память, то регистры контроллера представляются в виде обычных ячеек адресного пространства. Если ввод/вывод управляется прерываниями, то при поступлении входных данных и завершении операции вывода генерируется прерывание. Есть множество способов, но наиболее распространены ввод/вывод с управлением от программы и ввод/вывод, запускаемый программой. В первом случае прерывание обычно генерируется после чтения или записи каждого символа, во втором между устройством ввода/вывода и основной памятью помещается устройство прямого доступа к памяти (Direct Memory Access – DMA), управляющее передачей блоков данных между ними. По завершении передачи устройство DMA генерирует прерывание.. Когда используется ввод/вывод с опросом, прерывания отсутствуют. Поэтому система должна периодически проверять устройство ввода, чтобы понять, не пришли ли новые данные, или устройство вывода, чтобы выяснить, завершилась ли операция. Технология World Wide Web Огромная популярность Всемирной паутины (WWW), придуманной Бернер-сом-Ли из Европейской организации по ядерным исследованиям (CERN) в Женеве привела к очень быстрому росту сети Internet. Страницы WWW размещены на Web-серверах. Каждая страница обычно содержит графику и ссылки на другие страницы. Web-страница создается с помощью языка разметки, например широко распространенного языка HTML (Hyper Text Markup Language – язык разметки гипертекста) или начавшего приобретать популярность языка XML (eXtensible Markup Language – расширяемый язык разметки). Каждая страница помечается унифицированным указателем ресурса (URL), который используется в составе любой ссылки на эту страницу. Когда пользователь хочет просмотреть страницу, браузер берет из URL адрес сервера и обращается к нему с просьбой загрузить необходимые данные Внешний модуль, или вставка (plug-in), – это программа, которая помещается в браузер и расширяет его возможности – скажем, позволяет обрабатывать аудио- и видеоданные, посылаемые сервером. Внешний модуль может входить в дистрибутив браузера или загружаться отдельно с определенного сервера. С появлением WWW и Web-браузеров в начале 90-х годов браузер стал распространенным пользовательским интерфейсом для распределенных приложений. Рост популярности Всемирной паутины вывел на авансцену язык программирования Java, который широко применяется для создания апплетов. ПО промежуточного слоя Распределенным системам часто приходится работать в гетерогенных средах, когда в разных узлах установлено р
|
||||
Последнее изменение этой страницы: 2016-04-23; просмотров: 338; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.146.107.152 (0.013 с.) |