Выявление параллельных задач в системе

 

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

       В системе лифта такие объекты, как Лифт, Контроллер, Дверь, Кнопка, Датчики, могут порождать события, и в этом смысле являются активными объектами системы.

       Активные объекты системы в своем составе имеют методы, выполнение которых происходит одновременно. Выявление этих методов и позволяет определить параллельные задачи в системе.

       Представление параллельных задач в системе может быть выполнено путем трансформации диаграммы классов (рис. 3.8) в диаграмму задач.

       Диаграмма задач системы лифта представлена на рис. 3.11.

 

 

Рис. 3.11. Диаграмма задач системы лифта.

 

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

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

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

 

Этап технического проектирования

 

На предыдущем этапе проектирования – на этапе архитектурного проектирования были приняты решения относительно базовых аппаратных и программных компонентов.

Базовыми аппаратными компонентами выступали процессоры, а программными классы, объекты и задачи.

       Итогом предыдущего этапа проектирования явилась диаграмма задач системы.

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

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

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

 

Табл. 3.7. Образцы технического этапа проектирования

Категория	Имя образца	Цель
Простые образцы	Наблюдатель   Транзакции	Позволяет группе клиентов разделять сервер.   Позволяет управлять коммуникациями между объектами.
Повторно используемые образцы	Контейнер     Интерфейс   Рандеву	Позволяет агрегировать объекты и эффективно реализовывать ассоциации типа «один ко многим».   Обеспечивает отделение типа объекта от его реализации с целью поддержки множественной реализации данного типа.   Обеспечивает гибкий механизм для межзадачных коммуникаций
Образцы управления состояниями	Состояние   Таблица состояний	Обеспечивает реализацию машины состояний при редких изменениях состояний.   Обеспечивает эффективные средства поддержки машин с большим числом состояний

 

       Применительно к рассматриваемой системе лифта необходимо воспользоваться образцом «Контейнер» при реализации ассоциаций между Контроллером и Этажами. Так, информацию о положении объекта Лифт в Шахте необходимо рассылать на все этажи и целесообразно это делать одной операцией – итератором, входящей в класс Контейнер.

Детальное проектирование

 

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

       В общем случае на данном этапе определяются решения относительно следующих характеристик объектов:

 

1. Структуры данных;

2. Реализация ассоциаций;

3. Множество операций, определенных на данных;

4. Видимость данных и операций;

5. Алгоритмы, используемые для реализации этих операций;

6. Возбуждаемые и обрабатываемые исключения.

 

Структуры данных в объектах обычно просты, поскольку, если это не так, то целесообразно создать отдельный объект, чтобы хранить такие данные. Однако, необходимо определить не только структуры данных, но и диапазоны, точность, предусловия, начальные значения. Это необходимо сделать, поскольку проектируемые системы имеют дело с реальными объектами, которые должны функционировать без ошибок. Так, например, применительно к системе лифта, номер текущего этажа может быть описан типом integer, а можно ограничить этот атрибут диапазоном значений [1..N], где N – количество обслуживаемых этажей.

 

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

 

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

 

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

1. Видимыми надо делать только те данные и операции, которые необходимы объектам-клиентам;

2. Видимые операции должны быть семантически понятными.

3. Атрибуты объекта не должны быть видимы объектам-клиентам.

 

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

1. Производительность (средняя и рассчитанная на наихудший случай);

2. Требования памяти;

3. Простоты;

4. Усилия разработки;

5. Повторная используемость;

6. Расширяемость;

7. Надежность.

Перечисленные критерии конфликтны по своей сути. Выбор критериев определяется характером системы. Так, для жестких систем реального времени важным может стать критерий производительности, рассчитанной на наихудший случай. А если СРВ является еще и встроенной системой, то важными могут оказаться и требования к памяти. Для описания алгоритмов может быть использован структурированный английския язык, псевдокод, а также диаграммы активности, рассмотренные выше.

 

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

 

 

Реализация системы

 

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

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

       Активизация событий в программной модели системы должна выполняться специально выделенными для каждого события клавишами. Например, клавиши “1” – “9” могут имитировать кнопки вызова лифта с соответствующих этажей. Клавиши “q” – “o” могут имитировать кнопки запроса этажа внутри лифта.

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

       Примерный состав примитивов ядра следующий:

 

1. Создать ядро;

2. Уничтожить ядро;

3. Начать работу ядра;

4. Завершить работу ядра;

5. Создать задачу;

6. Уничтожить задачу;

7. Приостановить задачу;

8. Возобновить задачу;

9. Создать семафор;

10. Уничтожить семафор;

11. Выполнить операцию Р() семафора;

12. Выполнить операцию V() семафора;

 

Ниже приведены примеры описания объектов “задача”, “семафор” и “ядро”.

 

#include <setjmp.h>

#include <dos.h>

 

class TProcess : {                           //класс для описания задач

int stack[1000];                  //стек задачи

jmp_buf ts;                         //средство сохранения контекста задачи

public:

TProcess ( void *p ) {                    //создание задачи из функции с именем р

                   struct SREGS segs;

       segread ( &segs );

                   ts[0].j_sp    =     FP_OFF(stack) + sizeof stack;

       ts[0].j_ss     =     FP_SEG(stack);

       ts[0].j_flag  =     0x200;

       ts[0].j_cs     =     FP_SEG(p);

       ts[0].j_ip     =     FP_OFF(p);

       ts[0].j_bp    =     ts[0].j_sp;

       ts[0].j_di     =     0;

       ts[0].j_es     =     segs.es;

       ts[0].j_si     =     0;

       ts[0].j_ds    =     segs.ds;

}//TProcess

};//TProcess

 

class TSemaphore {

int count;                            //счетчик семафора

TСollection *List;              //очередь семафора

public:

TSemaphore();        //создание семафора

~TSemaphore();                 //уничтожение семафора

void P();                             //операция P семафора

void V();                            //операция V семафора

};//TSemaphore

 

#include <tv.h>

#include "proc.h"

#include "sema.h"

 

class tkernel {

TCollection *ReadyList;           //очередь готовых задач

TCollection *KillList;                //очередь уничтожаемых задач

TCollection *DelayList;            //очередь задержанных задач

TProcess     *cur;                       //дескриптор текущей задачи

unsigned long count;                      //счетчик “тиков”

void swt(jmp_buf from,jmp_buf to); //переключить контекст

public :

tkernel();                                         //создать ядро

~tkernel();                                      //уничтожить ядро

void start();                                    //начать работу ядра

void stop();                                     //завершить рабору ядра

void delay(unsigned long tik);       //задержать текущую задачу

void resume();                                //возобновить задачу

};

 

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

 

Выводы

 

       В подразделе 3.4 рассмотрены вопросы проектирования системы, для которой выполнен анализ требований и определены структура и поведение объектов.

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

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

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

       На этапе детального проектирования выполняется подробная спецификация отдельных объектов.

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

 

 

Выводы по разделу 3

 

       Раздел 3 описывает основные этапы объектно-ориентированного подхода к проектирования информационной системы.

       Хотя основное внимание и уделяется начальным этапам проектирования:

 

1. анализу требований к системе;

2. определению структуры системы;

3. описанию поведения системы;

4. архитектурному проектированию системы,

 

тем не менее, в разделе 3 затронуты все этапы, вплоть до реализации системы.

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

 

Требования к пояснительной записке

 

       Пояснительная записка должна содержать следующие части:

 

1. Титульный лист;

2. Содержание с указанием страниц;

3. Техническое задание на разработку системы;

4. Анализ требований к системе;

5. Определение структуры системы;

6. Описание поведения системы;

7. Результаты архитектурного проектирования системы;

8. Результаты технического проектирования системы;

9. Результаты детального проектирования системы;

10. Описание реализации программной модели системы;

11. Описание реализации ядра управления задачами;

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

 

Этапы 4 – 9 должны иллюстрироваться следующими видами диаграмм, построенными с использованием существующих инструментальных средств:

 

1. Контекстными диаграммами;

2. Диаграммами вариантов использования системы;

3. Последовательными диаграммами;

4. Диаграммами сотрудничества;

5. Диаграммами объектов;

6. Диаграммами классов;

7. Диаграммами состояний системы;

8. Диаграммами активности;

9. SDL-диаграммами;

10. Диаграммами задач;

11. Диаграммами развертывания.

 

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

 

1. Текст программных модулей, реализующих ядро управления задачами;

2. Текст программных модулей, реализующих объекты системы.

 

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

 

Оформление пояснительной записки должно быть выполнено в соответствии с требованиями ЕСКД и ЕСПД.

 

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

 

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. – М.: ДМК, 2000. – 432 с.: ил. (Серия «Для программистов»).

2. Модели задач синхронизации в системах реального времени: Методические указания к лабораторным работам по дисциплине “Системы реального времени” /Сост.: В. В. Сидельников, В. В. Широков. СПб.: Изд-во СПбГЭТУ “ЛЭТИ”, 2000. 36 с.

3. Методические указания к лабораторным работам по дисциплине “Операционные среды АСОИУ” /Сост.: В. В. Сидельников, В. В. Широков; ГЭТУ. СПб., 1997. 36 с.

4. Сидельников В. В., Широков В. В. Управление процессами в программных средах АСОИУ: Учеб. пособие / ГЭТУ.- С.-Пб., 1994. –64 с.

 

⇐ Предыдущая12345678

Поделиться: