Что такое CASE-СРЕДСТВАCASE-средства (от англ.Computer-Aided Software
Engineering) -– это инструментальные средства
автоматизации проектирования ИС.
CASE-СРЕДСТВА это методы программной инженерии для
проектирования программного обеспечения, которые
позволяют обеспечить высокое качество программ,
отсутствие ошибок и простоту в обслуживании
программных продуктов.
Также под CASE понимают совокупность средств
проектирования информационных систем с
использованием CASE-инструментов.
Для автоматизации процессов проектирования и разработки информационных систем в 70–80-е года широко применялась структурная методология, означающая использование формализованных методов описания разрабатываемой системы и принимаемых технических решений. При этом использовались графические средства описания различных моделей информационных систем с помощью схем и диаграмм. Это явилось одной из причин появления программно-технологических средств, получивших название CASE-средств и реализующих их CASE-технологий создания и сопровождения информационных систем.
Термин CASE (Computer Aided Software/System Engineering) используется в весьма широком смысле. Первоначальное значение термина CASE ограничивалось лишь вопросами автоматизации разработки программного обеспечения. В настоящее время этот термин получил более широкий смысл, означающий автоматизацию разработки информационных систем .
CASE-средства представляют собой программные средства, поддерживающие процессы создания и/или сопровождения информационных систем, такие как: анализ и формулировка требований, проектирование баз данных и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и проектом.
CASE-систему можно определить как набор CASE-средств, имеющих определенное функциональное предназначение и выполненных в рамках единого программного продукта.
CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимосвязанных средств автоматизации.
CASE-индустрия объединяет сотни фирм и компаний различной направленности деятельности. Практически все серьезные зарубежные программные проекты осуществляются с использованием CASE-средств, а общее число распространяемых пакетов превышает 500 наименований.
Основная цель CASE-систем и средств состоит в том, чтобы отделить проектирование программного обеспечения от его кодирования и последующих этапов разработки (тестирование, документирование и пр.), а также автоматизировать весь процесс создания программных систем, или инжиниринг (от англ. engineering – разработка).
Современные CASE-средства поддерживают разнообразные технологии проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, охватывающих весь жизненный цикл программного обеспечения.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом важную роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
САSЕ-средства составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
Характерные особенности CASE-средств:
- Единый графический язык . CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. При этом программы представляются двумерными схемами (более простыми в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, облегчая им защиту проекта перед руководством, а также обеспечивая простоту сопровождения и внесения изменений в систему.
- Единая база данных проекта . Основа CASE-технологии – использование базы данных проекта (репозитария) для хранения всей информации о проекте, которая может совместно использоваться разработчиками в соответствии с их правами доступа. Содержимое репозитария включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила применения или обработки этих компонентов. Репозитарий может хранить объекты различных типов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных и логики их обработки, а также модели данных, организации и обработки, исходные коды, элементы данных и т.п.
- интеграция средств . На основе репозитария осуществляются интеграция СASE-средств и разделение системной информации между разработчиками. При этом возможности репозитария обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представления фаз жизненного цикла, передачу данных и средств между различными платформами.
- Поддержка коллективной разработки и управления проектом . CASE-технология поддерживает групповую разработку проекта, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, то есть функции, необходимые в процессе разработки и сопровождения проектов. Эти функции также реализуются на основе репозитария. В частности, через репозитарий могут осуществляться контроль безопасности (ограничения и привилегии доступа), контроль версий и изменений и т.п.
- Макетирование . CASE-технология дает возможность быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на ранних этапах разработки оценить, насколько она его устраивает и насколько она приемлема для будущих пользователей.
- Генерация документации . Вся документация по проекту генерируется автоматически на базе репозитария (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитарий (известно, что при традиционных подходах к разработке программного обеспечения документация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения).
- Верификация проекта . CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом.
- Автоматическая генерация программного кода . Генерация программного кода осуществляется на основе репозитария и позволяет автоматически построить до 85–90% текстов на языках высокого уровня.
- Сопровождение и реинжиниринг . Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов, автоматически изменять спецификации при редактировании кодов и т.п.
Разработка программ начинается с некоторого предварительного варианта системы. В качестве такого варианта может выступать специально для этого разработанный прототип, либо устаревшая система. В последнем случае для восстановления знаний о программной системе с целью последующего их использования применяют повторную разработку – реинжиниринг.
Повторная разработка сводится к построению исходной модели программной системы путем исследования ее программных кодов. Имея модель, можно ее усовершенствовать, а затем вновь перейти к разработке. Одним из наиболее известных принципов такого типа является принцип возвратного проектирования (Round Trip Engineering (RTE)).
Современные CASE-системы обеспечивают и первичную, и повторную разработку, что существенно ускоряет разработку приложений и повышает их качество.
В настоящее время среди прочих требований к CASE-средствам предъявляются следующие:
Наличие возможностей определения основной модели прикладной задачи (бизнес-модели, обычно объектно-ориентированной) и правил ее поведения (бизнес-правил);
Поддержка процесса проектирования с помощью библиотек, оснащенных средствами хранения, поиска и выбора элементов проектирования (объектов и правил);
Наличие средств для создания пользовательского интерфейса и поддержания распространенных программных интерфейсов (поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т.п.);
Наличие возможностей для создания различных распределенных клиент-серверных приложений.
Лекция 16-1 CASE-ТЕХНОЛОГИИ В СОЗДАНИИ ИС
Решение задач проектирования больших размерностей требует применения соответствующих методов и моделей. Иерархические CASE-модели (Computer-Aided Software/System Engineering - проектирование программного обеспечения/ системы на основе компьютерной поддержки) во многом отвечают предъявляемым к ним требованиям.
Практически ни один крупный зарубежный программный продукт не создается в настоящее время без использования CASE-средств, а во многих отраслях ведущих стран (особенно госсектор, оборонный комплекс, добывающая промышленность) подготовка проектной документации с использованием CASE-средств является необходимым требованием стандартов.
Областью применения CASE-технологий является, прежде всего, создание экономических ИС, особенно там, где проблематика отличается большой сложностью, например, в корпоративных ИС.
Основой CASE-методологии является моделирование. CASE-технология - это модельный метод автоматизации проектирования системы.
CASE-технология основана на взаимосвязи:
методология - метод - нотации - средства
Методология определяет общие подходы к оценке и выбору варианта системы, последовательность стадий и этапов проектирования, подходы к выбору методов.
Метод конкретизирует порядок проектирования отдельных компонентов системы (например, известны методы проектирования потоков данных в системе, задания описаний процессов, представления структур данных в хранилище и т.д.).
Нотации - графические средства обозначения и правила, предназначенные для описания структуры системы, этапов обработки информации, структуры данных (графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки).
Средства - инструментарии, средства для обеспечения интерактивного режима проектирования (создание и редактирование графического проекта ИС и кодогенерацни программ).
Построение CASE-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание подсистем.
Модель системы должна отражать: функциональную часть системы; отношения между данными; переходы состояний системы при работе.
Для моделирования ИС в указанных аспектах используются разновидности графических средств:
1. Диаграммы потоков данных - DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов.
2. Диаграммы „сущность-связь" - ERD (Entity Relationship Diagrams), показывающие отношения между данными.
3. Диаграммы переходов состояний - STD (State Transitign Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).
Ведущая роль в моделировании принадлежит DFD.
DFD предназначена для отражения взаимосвязей источников и приемников данных, потоков данных, процессов обработки (вычислительных процессов, соответствующих функциям системы), хранилищ данных (накопителей).
Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки в интерактивном режиме. Поскольку графического представления недостаточно для точного определения компонентов DFD, используются текстовые описания.
Каждый процесс (функция системы) может быть детализирована с помощью DFD нижнего уровня, где он разделяется на несколько процессов с одновременной детализацией потоков данных. Детализация процессов заканчивается, когда описание каждого детализированного процесса может быть сделано с помощью выбранного метода написания алгоритма процесса.
Визуальные языки обеспечивают автоматическую кодогенерацию, но представленные с их помощью спецификации процессов сложно корректировать.
Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса создания системы на 4 стадии:
Предпроектную (стадию анализа, прототипирования, и построения модели требовании к системе);
Проектную, предполагающую логическое проектирование системы (без программирования);
Стадию программирования (включая проектирование физической базы данных);
Послепроектную, включающую в себя ввод в действие, эксплуатацию и сопровождение системы.
На предпроектной стадии строится модель требований к системе, т. е. подробное описание того, что она должна делать, без указания путей реализации требований.
На проектной стадии происходит уточнение модели требований (разработка подробной иерархической модели на основе DFD и спецификаций процессов) и расширение ее до модели реализации на логическом уровне.
На стадии программирования осуществляется физическое проектирование системы. Эта стадия предусматривает автоматическую кодогенерацию по спецификациям процессов программного обеспечения системы и физическое проектирование базы данных.
Заключительная послепроектная стадия начинается с приемосдаточных испытаний. Далее следуют ввод в постоянную эксплуатацию, сопровождение и развитие системы.
Достоинства CASE-технологии:
1. CASE-технология создает возможность и предусматривает перенос центра тяжести в трудоемкости создания системы на предпроектную и проектную стадии. Тщательная проработка этих стадий в интерактивном режиме с компьютерной поддержкой уменьшает число возможных ошибок в проектировании, исправлять которые на последующих стадиях затруднительно.
2. Доступная для понимания пользователей-непрограммистов графическая форма представления модели позволяет осуществить принцип пользовательского проектирования, предусматривающий участие пользователей в создании системы. CASE-модель позволяет достичь взаимопонимания между всеми участниками создания системы (заказчиками, пользователями, проектировщиками, программистами).
3. Наличие формализованной модели системы на предпроектной стадии создает возможность для многовариантного анализа с ориентировочной оценкой эффективности вариантов. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована физически. Это ускоряет и удешевляет создание системы.
4. Закрепление в формализированном виде требований к системе избавляет проектировщиков от многочисленных корректировок.
5. Отделение проектирования системы от программирования создает устойчивость проектных решений для реализации на разных программно-технических платформах.
6. Наличие формализованной модели реализации системы и соответствующих средств автоматизации позволяет осуществить автоматическую кодогенерацию программного обеспечения системы и создать рациональную структуру базы данных.
7. На стадии эксплуатации системы появляется возможность внесения изменений на уровне модели, не обращаясь к текстам программ, возможно, силами специалистов отдела автоматизации фирмы.
8. Модель системы может использоваться не только как основа ее создания, но и в целях автоматизированного обучения персонала с использованием диаграмм.
9. На основе модели действующей системы может выполняться бизнес-анализ для поддержки управленческих решений и бизнес-реинжиниринг при изменении направления деятельности фирмы.
В зависимости от функционального назначения программные средства, обеспечивающие CASE-технологию, подразделяются на следующие классификационные группировки, обеспечивающие:
Анализ и проектирование информационной системы;
Проектирование баз данных;
Программирование;
Сопровождение и реинжиниринг;
Управление процессом проектирования.
Средства анализа и проектирования служат для построения CASE-модели как действующей, так и реализуемой системы управления. Они поддерживают графическое построение и контроль иерархической модели диаграмм потоков данных и описание ее компонентов. Эти средства позволяют аналитикам и проектировщикам получить доступ к базе данных проектируемой системы. К таким средствам относятся: отечественный пакет CASE. Аналитик, Design/IDEF (Meta Software), The Developer (ASYST Technologies) и др.
Для согласования требований пользователей создаются прототипы пользовательских интерфейсов, включающих в себя меню, экранные формы и отчеты в виде таблиц или графиков. Примером является Developer/2000 (Oracle).
Средства проектирования баз данных обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в третью нормальную форму и генерацию схем баз данных. Примерами таких средств является Designer/2000 фирмы Oracle, ERWin (Logic Works) и др.
Средства программирования поддерживают автоматическую кодогенерацию из спецификаций процессов, тестирование и документирование программы. К их числу относятся Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software) и др.
Средства сопровождения и реижиниринга позволяют вносить изменения в систему при меняющихся условиях бизнеса (Adpac CASE Tools фирмы Adpac и др.).
Средства управления процессом проектирования поддерживают планирование и контроль выполнения комплекса проектных работ, а также взаимодействие аналитиков, проектировщиков и программистов на основе общей БД (Project Workbench фирмы Applied Business Technology).
2.2 Разработка концептуальной модели информационной системы.
Концептуальная модель представляет объекты и их взаимосвязи без указывания способов их физического хранения. Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели должна происходить структуризация данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности
обработки. Проектирование концептуальной модели основано на анализе задач, стоящих перед рекламным агентством. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Чтобы построить необходимую нам модель, мы привели все имеющиеся данные к третьей нормальной форме, в результате чего получили следующие сущности:
· Виды блюд.
· Персонал.
· Должности.
· Постоянные клиенты.
· Заказы.
Модель строим на логическом уровне (см. рис. 2). Из рисунка 2 видно, что в модели проставлены связи. Рассмотрим их подробнее:
Таблица «Виды блюд» и таблица «Блюда» - установлена связь «один-ко-многим» при помощи первичного ключа «Код вида»;
Таблица «Должности» и таблица «Персонал» - установлена связь «один-ко-многим» при помощи первичного ключа «Код должности»;
Таблица «Блюда» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код блюда»;
Таблица «Персонал» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код работника»;
Таблица «Постоянные клиенты» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код клиента».
Рис. 2. Концептуальная модель данных
2.3 Разработка логической модели информационной системы
Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру, представление о которой можно получить из рисунка 1.
Схема 1 - Многоуровневое представление данных БД под
управлением СУБД
Различают концептуальный, внутренний и внешний уровни представления этих баз данных, которым соответствуют модели аналогичного назначения.
Концептуальный уровень соответствует логическому аспекту представления данных предметной области в интегрированном виде. Концептуальная модель состоит из множества экземпляров различных типов данных, структурированных в соответствии с требованиями СУБД к логической структуре базы данных.
Внутренний уровень отображает требуемую организацию данных в среде хранения и соответствует физическому аспекту представления данных. Внутренняя модель состоит из отдельных экземпляров записей, физически хранимых во внешних носителях.
Внешний уровень поддерживает частные представления данных, требуемые конкретным пользователям. Внешняя модель является подмножеством концептуальной модели. Возможно пересечение внешних моделей по данным. Частная логическая структура данных для отдельного приложения (задачи) или пользователя соответствует внешней модели или подсхеме БД. С помощью внешних моделей поддерживается санкционированный доступ к данным БД приложений (ограничен состав и структура данных концептуальной модели БД, доступных в приложении, а так же заданы допустимые режимы обработки этих данных: ввод, редактирование, удаление, поиск).
Проектирование базы данных состоит в построении комплекса взаимосвязанных данных. На рисунке 2 условно отображены этапы процесса проектирования базы данных.
Схема 2 - Этапы процесса проектирования базы данных
Важнейшим этапом проектирования базы данных является разработка информационно-логической (инфологической) модели предметной области, не ориентированной СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности.
Информационно-логическая (инфологическая) модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей.
При связи один ко многим (1:М) одному экземпляру информации А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.
Примером связи 1:М служит связь между информационными объектами Фамилия – Оклад:
Фамилия Оклад
В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.
При определении необходимых таблиц базы данных необходимо обеспечить первые три нормальные формы, т.е. провести нормализацию.
Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Определённый набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Первая нормальная форма. Отношение называется нормализованным или приведённым к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Вторая нормальная форма. Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов – зависимость, при которой в экземпляре информационного объекта определённому значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. В качестве примера рассмотрим графическое изображение функциональных зависимостей реквизитов работников, приведенное на рисунке 5, на котором ключевой реквизит указан звёздочкой.
Рисунок 1 - Графическое изображение функциональной зависимости реквизитов
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Третья нормальная форма. Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости.
Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо провести “расщепление” исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
Создаваемая база данных должна выполнять функции в интересах автоматизации выдачи данных об организации. Она должна иметь простой и наглядный пользовательский интерфейс, иметь минимальные системные требования.
Целью работы является создание базы данных, обеспечивающей:
быстрый ввод новых данных;
хранения и поиск уже введённых данных;
печать необходимого количества персональных отчётов.
Данными являются:
Фамилия, имя, отчество;
Дата рождения;
Занимаемая должность;
Должностной оклад;
Количество фактических дней отработанных за месяц.
Рассмотрев определенные выше задачи можно спроектировать основные таблицы базы данных.
Для этого будем пользоваться средствами Database Desktop
В этой среде создадим все необходимые таблицы для разрабатываемой базы данных. Атрибутами в этой таблице будет:
Фамилия, Имя, Отчество, Дата принятия, Адрес, Телефон, Смены, Не выходы на работу, Ставка, зарплата.
Характеристики современных операционных систем
Год за годом происходит эволюция структуры и возможностей операционных систем. В последнее время в состав новых операционных систем и новых версий уже существующих операционных систем вошли некоторые структурные элементы, которые внесли большие изменения в природу этих систем. Современные операционные системы отвечают требованиям постоянно развивающегося аппаратного и программного обеспечения. Они способны управлять работой многопроцессорных систем, работающих быстрее обычных машин, высокоскоростных сетевых приспособлений и разнообразных запоминающих устройств, число которых постоянно увеличивается. Из приложений, оказавших влияние на устройство операционных систем, следует отметить мультимедийные приложения, средства доступа к Internet, а также модель клиент/сервер.
Неуклонный рост требований к операционным системам приводит не только к улучшению их архитектуры, но и к возникновению новых способов их организации. В экспериментальных и коммерческих операционных системах были опробованы самые разнообразные подходы и структурные элементы, большинство из которых можно объединить в следующие категории.
· Архитектура микроядра.
· Многопоточность.
· Симметричная многопроцессорность.
· Распределенные операционные системы.
· Объектно-ориентированный дизайн.
Отличительной особенностью большинства операционных систем на сегодняшний день является большое монолитное ядро. Ядро операционной системы обеспечивает большинство ее возможностей, включая планирование, работу с файловой системой, сетевые функции, работу драйверов различных устройств, управление памятью и многие другие. Обычно монолитное ядро реализуется как единый процесс, все элементы которого используют одно и то же адресное пространство. В архитектуре микроядра ядру отводится лишь несколько самых важных функций, в число которых входят работа с адресными пространствами, обеспечение взаимодействия между процессами (interprocess communication - IPC) и основное планирование. Работу других сервисов операционной системы обеспечивают процессы, которые иногда называют серверами. Эти процессы запускаются в пользовательском режиме и микроядро работает с ними так же, как и с другими приложениями. Такой подход позволяет разделить задачу разработки операционной системы на разработку ядра и разработку сервера. Серверы можно настраивать для требований конкретных приложений или среды. Выделение в структуре системы микроядра упрощает реализацию системы, обеспечивает ее гибкость, а также хорошо вписывается в распределенную среду. Фактически микроядро взаимодействует с локальным и удаленным сервером по одной и той же схеме, что упрощает построение распределенных систем.
Многопоточность (multithreading) - это технология, при которой процесс, выполняющий приложение, разделяется на несколько одновременно выполняемых потоков. Ниже приведены основные различия между потоком и процессом.
· Поток. Диспетчеризуемая единица работы, включающая контекст процессора (куда входит содержимое программного счетчика и указателя вершины стека), а также свою собственную область стека (для организации вызова подпрограмм и хранения локальных данных). Команды потока выполняют ся последовательно; поток может быть прерван при переключении процессора на обработку другого потока 4 .Процесс. Набор из одного или нескольких потоков, а также связанных с этими потоками системных ресурсов (таких, как область памяти, в которую входят код и данные, открытые файлы, различные устройства). Эта концепция очень близка концепции выполняющейся программы. Разбивая приложение на несколько потоков, программист получает все преимущества модульности приложения и возможность управления связанными с приложением временными событиями.
Многопоточность оказывается весьма полезной для приложений, выполняющих несколько независимых заданий, которые не требуют последовательного исполнения. В качестве примера такого приложения можно привести сервер базы данных, который одновременно принимает и обрабатывает несколько запросов клиентов. Если в пределах одного и того же процесса обрабатываются несколько потоков, то при переключении между различными потоками непроизводительный расход ресурсов процессора меньше, чем при переключении между разными процессами. Кроме того, потоки полезны при описанном в последующих главах структурировании процессов, которые являются частью ядра операционной системы.
До недавнего времени все персональные компьютеры, рассчитанные на одного пользователя, и рабочие станции содержали один виртуальный микропроцессор общего назначения. В результате постоянного повышения требований к производительности и понижения стоимости микропроцессоров производители перешли к выпуску компьютеров с несколькими процессорами. Для повышения эффективности и надежности используется технология симметричной многопроцессорности (symmetric multiprocessing - SMP). Этот термин относится к архитектуре аппаратного обеспечения компьютера, а также к образу действий операционной системы, соответствующему этой архитектурной особенности. Симметричную многопроцессорность можно определить как автономную компьютерную систему со следующими характеристиками.
1. В системе имеется несколько процессоров.
2. Эти процессоры, соединенные между собой коммуникационной шиной или какой-нибудь другой схемой, совместно используют одну и ту же основную память и одни и те же устройства ввода-вывода.
3. Все процессоры могут выполнять одни и те же функции (отсюда название симметричная обработка).
Операционная система, работающая в системе с симметричной многопроцессорностью, распределяет процессы или потоки между всеми процессорами. У многопроцессорных систем есть несколько потенциальных преимуществ по сравнению с однопроцессорными, в число которых входят следующие.
· Производительность . Если задание, которое должен выполнить компьютер, можно организовать так, что какие-то части этого задания будут выполняться параллельно, это приведет к повышению производительности по сравнению с однопроцессорной системой с процессором того же типа. Сформулированное выше положение проиллюстрировано на рис. 2.12. В много задачном режиме в один и тот же момент времени может выполняться только один процесс, тогда как остальные процессы вынуждены ожидать своей очереди. В многопроцессорной системе могут выполняться одновременно несколько процессов, причем каждый из них будет работать на от дельном процессоре.
· Надежность. При симметричной мультипроцессорной обработке отказ одного из процессоров не приведет к остановке машины, потому что все процессоры могут выполнять одни и те же функции. После такого сбоя система продолжит свою работу, хотя производительность ее несколько снизится.
· Наращивание . Добавляя в систему дополнительные процессоры, пользователь может повысить ее производительность.
· Масштабируемость. Производители могут предлагать свои продукты в различных, различающихся ценой и производительностью, конфигурациях, предназначенных для работы с разным количеством процессоров.
Важно отметить, что перечисленные выше преимущества являются скорее потенциальными, чем гарантированными. Чтобы надлежащим образом реализовать потенциал, заключенный в многопроцессорных вычислительных системах, операционная система должна предоставлять адекватный набор инструментов и возможностей
Рис. 2.12. Многозадачность и многопроцессорность
Часто можно встретить совместное обсуждение многопоточности и многопроцессорности, однако эти два понятия являются независимыми. Многопоточность - полезная концепция для структурирования процессов приложений и ядра даже на машине с одним процессором. С другой стороны, многопроцессорная система может обладать преимуществами по сравнению с однопроцессорной, даже если процессы не разделены на несколько потоков, потому что в такой системе можно запустить несколько процессов одновременно. Однако обе эти возможности хорошо согласуются между собой, а их совместное использование может дать заметный эффект.
Заманчивой особенностью многопроцессорных систем является то, что наличие нескольких процессоров прозрачно для пользователя -за распределение потоков между процессорами и за синхронизацию разных процессов отвечает операционная система. В этой книге рассматриваются механизмы планирования и синхронизации, которые используются, чтобы все процессы и процессоры были видны пользователю в виде единой системы. Другая задача более высокого уровня - представление в виде единой системы кластера из нескольких отдельных компьютеров. В этом случае мы имеем дело с набором компьютеров, каждый из которых обладает своей собственной основной и вторичной памятью и своими модулями ввода-вывода. Распределенная операционная система создает видимость единого пространства основной и вторичной памяти, а также единой файловой системы. Хотя популярность кластеров неуклонно возрастает и на рынке появляется все больше кластерных продуктов, современные распределенные операционные системы все еще отстают в развитии от одно- и многопроцессорных систем. С подобными системами вы познакомитесь в шестой части книги.
Одним из последних новшеств в устройстве операционных систем стало использование объектно-ориентированных технологий. Объектно-ориентированный дизайн помогает навести порядок в процессе добавления к основному небольшому ядру дополнительных модулей. На уровне операционной системы объектно-ориентированная структура позволяет программистам настраивать операционную систему, не нарушая ее целостности. Кроме того, этот подход облегчает разработку распределенных инструментов и полноценных распределенных операционных систем.
