|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Подходы к преодолению сложности проектаСтр 1 из 8Следующая ⇒
Введение
Курсовой проект предназначен для студентов, изучающих дисциплину “Системы реального времени и программное обеспечение встроенных приложений”. Базовым подходом к проектированию выбран объектно-ориентированный подход. Для успешной реализации проекта студентам необходимо владеть технологией и инструментами универсального языка моделирования UML. В разделе 1 методических указаний рассматриваются общие принципы проектирования систем реального времени и встроенных приложений. Подчеркивается сложность проектирования и даются направления преодоления сложности. В разделе 2 перечислены варианты заданий на курсовое проектирование. Все варианты связаны с проектированием программного обеспечения встроенной системы. В разделе 3 представлена методика проектирования системы, основанная на объектно-ориентированном подходе. Методика сопровождается примером проектирования встроенной системы реального времени. В разделе 4 перечислены требования к пояснительной записке к курсовому проекту. В заключении приведен список литературы, рекомендуемой к использованию в просессе проектирования и реализации программного обеспечения встроенной системы.
1. Общие вопросы проектирования встроенных систем реального времени Проектирование архитектуры системы
Список сущностей, формирующих базу данных реального времени, и список задач преобразования данных, собранные на этапе анализа требований, формируют исходные данные для определения подсистем. Анализ отношений типа физического расстояния, временных связей или связей вход/выход между перечисленными компонентами позволяет выполнить группирование компонентов и тем самым произвести первоначальную декомпозицию на подсистемы, кластеры, узлы. На этом же этапе появляются и первые версии интерфейсов между подсистемами. Хорошим стилем проектирования является сокрытие сложности внутри подсистем ради упрощения интерфейсов между ними. После определения подсистем может быть выполнено распределение задач по подсистемам. Распределение задач позволяет сформировать требования к коммуникациям между ними.
На заключительном этапе проектирования должен быть выпущен документ, описывающий архитектуру системы, и содержащий, по крайней мере, следующую информацию:
1. Результаты декомпозиции системы на подсистемы и перечисление функций каждой из подсистем.
2. Спецификацию данных в интерфейсах между подсистемами. 3. Спецификацию интерфейсов ввода/вывода к объектам внешней среды.
4. Спецификацию преобразований данных, выполняемых в каждой из подсистем: список входных данных, алгоритмы преобразования, список выходных данных.
5. Анализ требований надежности и предложения по реализации этих требований (дублирование сообщений, отказоустойчивые модули).
Для определенной версии проекта должны быть “заморожены” все специфицированные интерфейсы, чтобы можно было выполнить соответствующую версию детального проектирования, реализацию и тестирование всех подсистем изолированно друг от друга.
Проектирование никогда не является линейной последовательностью действий. В процессе работы проектировщик узнает о предметной области все больше и больше, что заставляет его возвращаться к начальным этапам проектирования.
Оценка результатов проектирования архитектуры
Практически невозможно оценить качество проекта по абсолютной шкале. Лучшее, чего можно достигнуть, это создать набор показателей для сравнения проектных решений. Перечень показателей, представленных ниже, может служить в качестве исходного набора.
Тестируемость подсистем Этот показатель говорит о том, насколько полно можно проверить подсистему изолированно от других подсистем. Следующий список вопросов помогает оценить степень тестируемости подсистемы:
· Достаточно ли точно определены временные характеристики интерфейса, чтобы их можно было смоделировать на тестовом оборудовании? · Наблюдаемы ли сообщения ввода/вывода? · Можно ли установить состояние подсистемы извне, чтобы уменьшить число тестовых последовательностей? · Будут ли одни и те же входные сигналы вести к тем же самым результатам на выходе? · Существуют ли механизмы проверки отказоустойчивости подсистемы? · Можно ли реализовать эффективное встроенное самотестирование подсистемы?
Надежность подсистем Следующий список вопросов позволяет оценить потенциальную надежность подсистем проектируемой системы:
· Как влияет наиболее тяжелый отказ подсистемы на систему в целом? Как обнаруживается такой отказ? Как этот отказ влияет на критерий минимальной производительности? · Сколько времени требуется другим подсистемам, чтобы обнаружить отказ подсистемы? · Сколько времени требуется для рестарта подсистемы после отказа? Какова трудоемкость восстановления отказавшей подсистемы? · Насколько устойчив интерфейс по отношению к возможным изменениям требований? · Какова вероятность и степень изменений в оставшейся части системы?
Физические характеристики Существует вероятность появления ошибок вследствие неудачной механической конструкции системы. Следующий список вопросов позволяет оценить удачность конструкции:
· Специфицированы ли механические интерфейсы заменяемых модулей, и совпадают ли эти механические границы заменяемых модулей с границами диагностики ошибок? · Монтируются ли модули-дублеры на расстоянии друг от друга, чтобы уменьшить в случае аварии вероятность повреждения обоих модулей одновременно? · Используются ли различные источники питания модулей-дублеров, чтобы снизить возможность сбоев, обусловленных источниками питания? · Существует ли возможность сбоев в работе подсистем за счет электромагнитных помех, создаваемых кабелями и контактами? · Каковы внешние условия функционирования подсистем (температура, вибрация, влажность)? Согласованы ли эти условия со спецификацией на компоненты?
Выводы по разделу 1
Приведенные в данном разделе особенности проектирования программного обеспечения не могут быть учтены с помощью формальных рекомендаций по проектированию. Но они могут неявно присутствовать в процессе проектирования за счет опыта и квалификации проектировщика.
Задания на выполнение курсового проекта
Требуется разработать проект архитектуры программного обеспечения встроенной системы реального времени. Возможные варианты систем представлены в табл. 1. Перечисленные варианты не исключают возможности выбора студентом другого типа системы для проектирования при условии согласования с преподавателем.
Табл. 2.1. Задания для курсового проектирования
Контекстные диаграммы
Построение контекстных диаграмм на этапе анализа требований к системе позволяет описать объекты, с которыми система должна взаимодействовать, события, происходящие при этом взаимодействии, и сообщения, которыми обмениваются система и внешние объекты.
Применительно к системе лифта можно выделить следующие внешние объекты:
1. Потенциальный пассажир; 2. Пассажир; 3. Обслуживающий персонал.
Потенциальный пассажир формирует команду «Вызов лифта», в ответ на которую (через некоторое время) получает сообщение «Можно войти». Кроме того, потенциальный пассажир наблюдает за положением и направлением перемещения лифта. Пассажир формирует команду «Перевезти», в ответ на которую (через некоторое время) получает сообщение «Можно выйти». Кроме того, пассажир наблюдает за положением и направлением перемещения лифта и может послать сообщение «Тревога». Обслуживающий персонал наблюдает за состоянием лифта и принимает сигналы тревоги в случае их появления. Контекстная диаграмма взаимодействия системы лифта с внешними объектами представлена на рис. 3.1.
Рис. 3.1. Контекстная диаграмма взаимодействия системы лифта с внешними объектами
Построение сценариев
Дальнейшей детализацией вариантов использования являются сценарии. Любой отдельный вариант использования порождает множество сценариев. Например, вариант «Вызов лифта» может породить следующие сценарии:
1. Лифт уже на этаже; 2. Лифт двигается к этажу, с которого сделан вызов; 3. Лифт имеет запрос, который должен быть обработан.
В начальном этапе анализа в качестве объектов, участвующих в сценариях, выступают система и внешние объекты, определенные в контексте и вариантах использования. При последующем анализе система разбивается на объекты, и процесс построения сценариев может быть продолжен. Сценарии обеспечивают инструмент для уточнения требований к системе с учетом разнообразия возможный ситуаций, в которых может оказаться система в процессе своего функционирования. Построение и анализ сценариев – это сложная творческая деятельность.
В табл. 3.2 показан пример одного из возможных сценариев вызова лифта.
Табл. 3.2. Пример сценария вызова лифта
Две описания сценариев используют два варианта диаграмм – последовательные диаграммы и диаграммы сотрудничества.
Рис. 3.4. Диаграмма сотрудничества системы лифта
Выводы
В подразделе 3.1 показаны этапы анализа системного окружения, с целью понимания и выявления поведения системы в различных обстоятельствах. Контекстные диаграммы и варианты использования рассматривают различные аспекты этого окружения. Контекстные диаграммы рассматривают систему как целостный объект и идентифицируют события и сообщения, которыми обменивается система с внешними объектами. Варианты использования описывают различные аспекты поведения системы безотносительно внутренней структуры системы и сообщений. Варианты использования декомпозируются на функционально связанные сценарии. Сценарии описываются с использованием последовательных диаграмм и диаграмм сотрудничества. Построение перечисленного набора диаграмм (контекстной, вариантов использования, последовательных и сотрудничества) завершает внешний обзор системы. Следующий подраздел описывает последовательность определения структуры системы, как совокупности объектов и их отношений.
Определение классов
Среди объектов, определенных в описании проблемы, обычно существует много идентичных объектов. В случае лифта, например, существует множество кнопок, но они все идентичны. Каждая кнопка активизируется при отпускании, прием запроса подтверждается подсветкой. Двери лифта и всех этажей также идентичны по своей структуре и поведению. Объекты, которые идентичны по структуре и поведению, должны быть объединены в классы. В системе лифта могут быть выделены следующие классы:
1. Шахта; 2. Лифт; 3. Контроллер; 4. Группа обслуживания; 5. Этаж; 6. Индикаторы; 7. Двери. 8. Кнопки; 9. Датчики; 10. Зажим.
Для первой группы перечисленных классов будет создан единственный экземпляр:
1. Шахта; 2. Лифт; 3. Контроллер; 4. Группа обслуживания.
Для второй группы будут отсутствовать классы-наследники:
1. Этаж; 2. Индикаторы; 3. Двери. 4. Зажим.
Для третьей группы будут существовать классы-наследники. Диаграммы классов «Кнопки» и «Датчики» представлены на рис. 3.6 и рис. 3.7.
Рис. 3.6. Диаграмма классов «Кнопки»
Рис. 3.7. Диаграмма классов «Датчики»
Первый вариант диаграммы классов системы лифта показан на рис. 3.8. Диаграмма показывает основные классы и их отношения. Вследствие ограниченных возможностей графического представления диаграммы классов, типы отношений и их множественность охарактеризованы словесно.
1. Отношение «Шахта – Зажим» - зажим находится в шахте (композиция, 1 - 1); 2. Отношение «Шахта – Датчик» - экземпляр класса «Датчик» – датчик натяжения троса находится в шахте (композиция, 1 - 1); 3. Отношение «Зажим – Контроллер» - зажим управляется контроллером (ассоциация, 1 - 1); 4. Отношение «Контроллер – Группа обслуживания» – контроллер передает информацию группе обслуживания, группа обслуживания управляет системой лифта через контроллер (ассоциация, 1 - 1); 5. Отношение «Датчик – Контроллер» - экземпляры класса «Датчик» передают информацию контроллеру (ассоциация, Много-к-одному); 6. Отношение «Датчик – Лифт» - экземпляры класса «Датчик» находятся в лифте (композиция, Много-к-одному); 7. Отношение «Контроллер – Лифт» - контроллер управляет лифтом (ассоциация, 1 - 1); 8. Отношение «Дверь – Лифт» - экземпляры класса «Дверь» находятся в лифте (композиция, 1 - 1); 9. Отношение «Датчик – Этаж» - экземпляры класса «Датчик» находятся на этаже (композиция, Много-к-одному); 10. Отношение «Дверь – Контроллер» - экземпляры класса «Дверь» управляются контроллером (ассоциация, Много-к-одному); 11. Отношение «Дверь – Этаж» - экземпляр класса «Дверь» находится на этаже (композиция, 1 - 1); 12. Отношение «Кнопка – Лифт» - экземпляры класса «Кнопка» находятся в лифте (композиция, Много-к-одному); 13. Отношение «Кнопка – Этаж» - экземпляры класса «Кнопка» находятся на этаже (композиция, Много-к-одному); 14. Отношение «Индикатор – Лифт» - индикатор положения лифта находится в лифте (композиция, 1 - 1); 15. Отношение «Индикатор – Этаж» - индикатор положения лифта находится на этаже (композиция, 1 - 1); 16. Отношение «Кнопка – Контроллер» - экземпляры класса «Кнопка» передают нажатия контроллеру, а контроллер передает команду «подсветить» кнопкам (ассоциация, Много-к-одному); 17. Отношение «Индикатор - Контроллер» - индикаторы получают информацию от контроллера (ассоциация, Много-к-одному).
Рис. 3.8. Первый вариант диаграммы классов лифта
Выводы
В подразделе 3.2 выполнен этап анализа, заключающийся в определении объектов, классов и отношений в системе. Для определения объектов системы была использована стратегия «подчеркивания существительных». Затем объекты, близкие по структуре и поведению были обобщены в классы. А затем между классами описаны отношения. Отношения классифицированы и определена их множественность. Итоговым результатом подраздела является диаграмма классов. В подразделе выполнен только один проход от описания проблемы к построению диаграммы классов. На практике, как правило, необходимо выполнить ряд уточняющих проходов, поскольку после каждого прохода появляются дополнительные сведения и соображения по составу объектов, классов и отношений в системе.
Выводы
В данном подразделе мы выполнили этап проектирования, заключающийся в исследовании поведения системы. Этот этап мы выполняли путем анализа состояний объектов и анализа действий объектов. Результатом этого анализа является набор операций, выполняемых объектами. Выполнив анализ требований к системе, описав структуру объектов и их поведение, можно приступать к проектированию архитектуры системы.
Проектирование системы
Табл. 3.6. Архитектурные образцы, применимые к системам реального времени
Применительно к рассматриваемой системе лифта целесообразным выбором архитектурного образца является образец «Ведущий-Ведомый». Ведущим (клиентом) будет выступать Контроллер, заявки от которого поступают к Лифту, который будет выступать в качестве Ведомого (сервера). Указанному образцу будем следовать при формировании облика физической архитектуры и распределении задач по процессорам этой архитектуры.
Детальное проектирование
Если на этапе архитектурного проектирования определялись крупномасштабные проектные решения, а на этапе технического проектирования определялись группы взаимодействующих объектов, то на этапе детального проектирования выполняется подробное специфицирование отдельных объектов. В общем случае на данном этапе определяются решения относительно следующих характеристик объектов:
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 с.
Введение
Курсовой проект предназначен для студентов, изучающих дисциплину “Системы реального времени и программное обеспечение встроенных приложений”. Базовым подходом к проектированию выбран объектно-ориентированный подход. Для успешной реализации проекта студентам необходимо владеть технологией и инструментами универсального языка моделирования UML. В разделе 1 методических указаний рассматриваются общие принципы проектирования систем реального времени и встроенных приложений. Подчеркивается сложность проектирования и даются направления преодоления сложности. В разделе 2 перечислены варианты заданий на курсовое проектирование. Все варианты связаны с проектированием программного обеспечения встроенной системы. В разделе 3 представлена методика проектирования системы, основанная на объектно-ориентированном подходе. Методика сопровождается примером проектирования встроенной системы реального времени. В разделе 4 перечислены требования к пояснительной записке к курсовому проекту. В заключении приведен список литературы, рекомендуемой к использованию в просессе проектирования и реализации программного обеспечения встроенной системы.
1. Общие вопросы проектирования встроенных систем реального времени Подходы к преодолению сложности проекта
Проектирование – это творческая человеческая деятельность, которая не может быть сведена до некоторого ряда правил из книг – руководств по проектированию. Проектирование – это искусство, дополненное научными принципами. Поэтому тщетно пытаться установить полный набор правил проектирования, можно сформулировать лишь только общие подходы к проектированию и дать некоторые рекомендации по их использованию.
Существует общность проектной деятельности в различных областях техники. Проектировщик должен найти решение, которое удовлетворяет различным, часто конфликтным, целям. Экономическим критерием оценки полученного решения является его стоимость.
Стоимость системы прямо вытекает из сложности ее проектирования, реализации и тестирования. Постоянное снижение отношения цена/производительность аппаратного обеспечения приводит к тому, что стоимость программного обеспечения по большей части определяет стоимость всей системы. Поэтому главное усилие при проектировании программного обеспечения должно быть направлено на управление сложностью путем структурирования.
Сложность системы растет с ростом числа элементов и интенсивности их взаимодействия. Преодоление растущей сложности путем структурирования состоит в выделении таких подсистем, которые имеют высокую внутреннюю связность элементов, и в то же самое время слабо взаимодействуют между собой через простые и стабильные интерфейсы.
Два способа структурирования системы можно использовать, чтобы снизить ее сложность: горизонтальное и вертикальное структурирование.
1. Горизонтальное структурирование: горизонтальное структурирование это процесс представления системы в виде иерархически упорядоченных слоев. Структурное программирование представляет собой пример горизонтального структурирования. 2. Вертикальное структурирование: вертикальное структурирование представляет собой процесс разбиения системы на ряд почти независимых подсистем с хорошо специфицированными интерфейсами между ними. Узлы распределенной СРВ являются примерами такого разбиения.
При проектировании большого приложения могут быть использованы преимущества обоих видов структурирования. Сначала оно может быть разбито на подсистемы высокой внутренней связности и низкой внешней связности. На втором шаге каждая подсистема может быть структурирована путем разбиения на слои. Вертикальное структурирование приведет к построению распределенной системы, в которой подсистемы будут отображаться в кластеры и узлы.
Главное преимущество вертикального структурирования по сравнению с горизонтальным структурированием состоит в том, что сформированные кластеры и узлы могут рассматриваться как области ограничения распространения ошибок, что способствует построению надежной системы. В системе разбитой на слои такие области определить гораздо труднее.
|
Последнее изменение этой страницы: 2019-04-21; Просмотров: 314; Нарушение авторского права страницы
