Raid 1 stripe size какой выбрать. Размещение базы, shadow и backup. Больше не значит лучше

За последнее десятилетие сформировалось новое направление в программотехнике: CASE (Computer-Aided Software/System Engi­neering - Технология автоматизированной разработки програм­много обеспечения). CASE-технология представляет собой сово­купность методологий анализа, проектирования, разработки и со­провождения сложных систем программного обеспечения (ПО), поддерживаемую комплексом взаимосвязанных средств автомати­зации. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.

Практически ни один серьезный зарубежный программный проект не осуществляется без использования CASE-средств. Изве­стная методология структурного системного анализа SADT (точнее ее подмножество IDEFO) принята в качестве стандарта на разработ­ку ПО Министерством обороны США. Более того, среди менедже­ров и руководителей компьютерных фирм знание основ SADT счи­тается правилом хорошего тона; при обсуждении каких-либо вопро­сов упомянутые работники способны нарисовать простейшую диа­грамму, поясняющую суть дела.

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

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

Таким образом, CASE-технологии развивают структурные ме­тодологии и делают более эффективным их применение за счет ав­томатизации.

Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов сис­темной и программной инженерии, CASE обладают следующими основными достоинствами; они улучшают качество создаваемо­го ПО за счет средств автоматического контроля (прежде всего, контроля проекта); позволяют за короткое время создавать про­тотип будущей системы, что дает возможность оценить ожидае­мый результат на ранних этапах; ускоряют процесс проектирова­ния и разработки; освобождают разработчика от рутинной рабо­ты, позволяя ему целиком сосредоточиться на творческой части разработки; поддерживают развитие и сопровождение разработ­ки; поддерживают технологии повторного использования ком­понентов разработки.

Главная особенность современного подхода к созданию ПО со­стоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудо­емкости последующих этапов.

CASE-технологии предлагают новый, основанный на автомати­зации подход к концепции ЖЦ ПО. При использовании CASE изме­няются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования.

В табл. 3.1 приведены оценки трудозатрат по фазам ЖЦ. В табл. 3.2 представлены основные изменения в ЖЦ при использова­нии CASE-технологий сравнению с традиционной разработкой.

Таблица 3.1

Оценки трудозатрат по базам жизненного цикла изделия. %

Таблица 3.2

Основные изменения в жизненном цикле изделия при использовании

CASE-технологий

Традиционная разработка	CASE-технология
Основные усилия направлены на кодирование и тестирование	Основные усилия направлены на анализ и проектирование
Бумажные спецификации	Быстрое итеративное прототипирование
Ручное кодирование	Автоматическая кодогенерация
Ручное документирование	Автоматическая генерация документации
Тестирование кодов	Автоматический контроль проекта
Сопровождение кодов	Сопровождение спецификаций проектирования

CASE-средства служат инструментарием для поддержки и уси­ления методов структурного анализа и проектирования. Фактически CASE-средства представляют собой новый тип графически-ориен­тированных инструментов, восходящих к системе поддержки ЖЦ ПО. Обычно к ним относят любое программное средство, обеспечи­вающее автоматическую помощь при разработке ПО, его сопровож­дении или деятельности по управлению проектом. Подобное программное средство обычно обладает дополнительными чертами, в число которых входят:

Мощная графика для описания и документирования систем ПО, а также для улучшения интерфейса для пользователя, развивающая творческие возможности специалистов и не отвлекающая их от про­цесса проектирования на поиск решения второстепенных вопросов;

Интеграция, обеспечивающая легкость передачи данных между средствами и позволяющая управлять всем процессом проек­тирования и разработки ПО непосредственно через процесс плани­рования проекта;

Использование компьютерного хранилища (репозитария) для всей информации о проекте; эта информация может разделяться между разработчиками и исполнителями, составляя основу для автоматического продуцирования ПО и повторного его использова­ния в будущих системах.

Помимо перечисленных основополагающих принципов (графи­ческой ориентации, интеграции и локализации всей проектной ин­формации в репозитарии), в основе концептуального построения CASE-средств лежат следующие положения:

широкое использование базовых программных средств, полу­чивших массовое распространение в других приложениях (БД и СУ БД, компиляторы с различных языков программирования, отладчи­ки, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.);

автоматизированная или автоматическая кодогенерация, вы­полняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, получения выполняемых машинных кодов из специфика­ций ПО, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ, автоматической кон­версии ранее используемых файлов в форматы, соответствующие новым требованиям;

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

доступность для разных категорий пользователей;

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

Интегрированный CASE-пакет в совокупности должен:

поддерживать графические модели;

контролировать ошибки;

организовывать и поддерживать репозитарии;

Поддерживать процесс проектирования и разработки.

Графическая ориентация CASE заключается в том, что про­граммы представляют собой схематические проекты и формы, кото­рые оказываются намного более простыми в использовании, чем многостраничные описания.

Для CASE существенны четыре типа диаграмм:

диаграммы функционального проектирования (для этих целей наиболее часто употребляются DFD-диаграммы потоков данных);

диаграммы моделирования данных (как правило, ERD-диа- граммы "сущность-связь");

3) диаграммы моделирования поведения (как правило, STD-диаграммы переходов состояний);

4) структурные диаграммы (карты), применяемые на этапе про­ ектирования и описывающие отношения между модулями и внутри- модульную структуру,

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

Важность контроля ошибок на этапах анализа требований и проектирования спецификаций обусловлена возможностью их ав­томатического обнаружения на ранних этапах ЖЦ, CASE-средства обеспечивают автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах ЖЦ, что влияет на успех разработки в целом. В подтверждение можно привести сле­дующие статистические данные, основанные на отчетах фирмы "TRW" по анализу пяти крупных проектов: при традиционной ор­ганизации работ ошибки проектирования и кодирования составля­ют 64 и 32% от общего числа ошибок, соответственно. Обнару­жить ошибки проектирования на этапе сопровождения ПО в 100 раз труднее, чем на этапах анализа требований и проектирования спецификаций.

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

На основе репозитария осуществляется интеграция CASE-средств и разделение системной информации между разработчиками.

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

Поддержка структурных методологий осуществляется за счет средств их автоматизации на следующих двух уровнях:

подготовка документации, графическая поддержка построе­ния структурных диаграмм различных типов, продуцирование спе­цификаций для детализации функциональных блоков в диаграммах и структур данных на нижних уровнях;

корректное использование шагов обработки в методологиях.

Кодогенерация осуществляется на основе репозитария и позво­ляет автоматически построить до 80...90% объектных кодов или текстов программ на языках высокого уровня. Все CASE-средства делятся на типы, категории и уровни. Классификация по типам от­ражает функциональную ориентацию CASE-средств в технологиче­ском процессе.

Анализ и проектирование. Средства этой группы использу­ют для создания спецификаций системы и ее проектирования; они поддерживают широко известные методологии проектиро­вания. К таким средствам относятся CASE. Аналитик (Эйтэкс), The Developer (ASYST Technologies), POSE (Computer Systems Advisers), ProKit *Workbench (McDonnell Douglas), Excelerator (Index Technology), Design-Aid (Nastec), Design Machine (Opti­ma), MicroStep (Meta Systems), VS Designer (Visual Software), Analist/Designer (Yourdon), Design/IDEE (Meta Software), BPWin (Logic Works), SELECT (Select Software Tools), System Architect (Popkin Software & Systems), Westmount I-CASE Yourdon (West-mount Technology B. V. & CADRE Technologies), CASE/4/0 (mic-roTOOL GmbH). Их цель заключается в определении системных требований и свойств, которыми должна обладать система, а также создание проекта системы, удовлетворяющей этим требо­ваниям и обладающей соответствующими свойствами. На выхо­де продуцируются спецификации компонентов системы и ин­терфейсов, связывающих эти компоненты, а также "калька" ар­хитектуры системы и детальная "калька" проекта, включающая алгоритмы и определения структур данных.

Проектирование баз данных и файлов. Средства этой группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в форму, обеспечивающую авто­матическую генерацию схем БД и описаний форматов файлов на уровне программного кода. В число таких средств входят: ERWin (Logic Works), Chen Toolkit (Chen & Associates), S-Designer (SDP), Designer/2000 (Oracle), Silverrun (Computer Systems Advisers).

Программирование. Средства этой группы поддерживают эта­пы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документиро­ванную выполняемую программу: COBOL 2/Workbench (Mikro Fo­cus), DECASE (DEC), NETRON/CAP (Netron), APS (Sage Software). Помимо диаграммеров различного назначения и средств поддержки работы с репозитарием, в эту группу средств включены и традици­онные генераторы кодов, анализаторы кодов (как в статике, так и в динамике), генераторы наборов тестов, анализаторы покрытия тес­тами, отладчики.

Сопровождение и реинжениринг. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирова­ния и реинжениринга: Adpac CASE Tools (Adpac), Scan/COBOL и Superstructure (Computer Data Systems), Inspector/Recoder (Language Technology). Их цель -корректировка, изменение, анализ, преоб­разование и реинжениринг существующей системы. Средства по­зволяют осуществлять поддержку всей системной документации (включая коды, спецификации, наборы тестов); контролировать по­крытие тестами для оценки полноты тестируемости; управлять фун­кционированием системы и т.п. Особый интерес представляют средства обеспечения мобильности (в CASE они получили название средств миграции) и реинжениринга.

Управление проектом. К этим средствам относятся поддержи­вающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов: Project Workbench (Applied Business Technology).

Значительно лучше соответствуют большой размерности задачи ие­рархические CASE-модели. Аббревиатура CASE (Computer-Aided Software/System Engineering) означает проектирование программного обеспечения или системы на основе компьютерной поддержки.

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

Среди отечественных систем, созданных с использованием CASE-средств, следует отметить систему БОСС-КОРПОРАЦИЯ фир­мы АйТи. На всех стадиях создания этой системы использовались сред­ства разработки, относящиеся к семейству Oracle 2000 (Designer/2000, Developer/200, Programmer/2000).

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

Следует отметить, что CASE-технологий применяются не только для создания автоматизированных систем управления, но и для разработки моделей систем, помогающих в принятии решений в области страте­гического планирования, управления финансами фирмы, обучения пер­сонала и т.д. Это направление применения CASE-технологий получило свое собственное название - бизнес-анализ.

CASE-технологий применяются также там, где проблематика пред­метной области отличается большой сложностью, например, в разработ­ке системного программного обеспечения.

Рассмотрим методологические основы CASE-технологий.

Основой CASE-методологии является моделирование. CASE-технология - это модельный метод автоматизации проектирования системы.

CASE-технология основана на парадигме: методология - метод - нотации - средства

Методология определяет общие подходы к оценке и выбору вариан­та системы, последовательность стадий и этапов проектирования, под­ходы к выбору методов.

Метод конкретизирует порядок проектирования отдельных компо­нентов системы (например, известны методы проектирования потоков данных в системе, задания спецификаций (описаний) процессов, пред­ставления структур данных в хранилище и т.д.).

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

Наконец, средства - это инструментарии, средства автоматизации проектирования в виде программных продуктов для обеспечения интер­активного режима проектирования (создание и редактирование графи­ческого проекта информационной системы) и кодогенерацни программ (автоматического создания кодов программ системы).

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

Модель системы должна отражать:

Функциональную часть системы;

Отношения между данными;

Переходы состояний системы при работе в реальном времени. Для моделирования информационной системы в трех указанных аспектах используются три разновидности графических средств с опре­деленными нотациями.

1. Диаграммы потоков данных - DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов.

2. Диаграммы „сущность-связь" - ERD (Entity Relationship Dia­grams), показывающие отношения между данными.

3. Диаграммы переходов состояний - STD (State Transitign Dia­grams) для отражения зависящего от времени поведения системы (в режиме реального времени).

Ведущая роль в моделировании принадлежит DFD.

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

Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректи­ровки основных компонентов модели в интерактивном режиме.

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

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

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

Текстовое описание;

Естественный структурированный язык;

Таблицы решений;

Деревья решений;

Визуальные языки;

Языки программирования.

Языки программирования (С, Cobol и др.) вызывают затруднения в написании алгоритмов применительно к DFD, поскольку требуют использования, помимо потоков данных, словарей данных, и требуют синхронной корректировки спецификаций процессов при корректиров­ке DFD.

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

Таблицы и деревья решений, наглядно отражая связь комбинации условий с необходимыми действиями, не обладают процедурными воз­можностями для кодогенерации программ.

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

Содержимое каждого хранилища данных, представленного на диа­грамме потока данных, описывается словарем данных и моделью дан­ных ERD. В случае работы системы в реальном времени DFD дополня­ется STD.

Иерархическая структура CASE-модели представлена на рис. 11.9.

Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса созда­ния системы на 4 стадии:

Предпроектную (стадию анализа, прототипирования, и построения модели требовании к системе);

Проектную, предполагающую логическое проектирование системы (без программирования);

Стадию программирования (включая проектирование физической базы данных);

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

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

На проектной стадии происходит уточнение модели требований (раз­работка подробной иерархической модели на основе DFD и специфика­ций процессов) и расширение ее до модели реализации на логическом уровне. В заключение этой стадии происходит тщательный контроль проекта на уровне логической модели реализации.

На следующей стадии (программирования) осуществляется физиче­ское проектирование системы. Эта стадия предусматривает автоматиче­скую кодогенерацию по спецификациям процессов программного обес­печения системы и физическое проектирование базы данных.

Заключительная послепроектная стадия начинается с приемо­сдаточных испытаний. Далее следуют ввод в постоянную эксплуатацию, сопровождение и развитие системы.

Последовательность операций создания информационной системы на основе CASE-технологии представлена на рис. 11.10.

Рассмотрим факторы эффективности 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). Очевидна актуальность созда­ния интегрированного пакета инструментальных средств поддержки CASE-технологии на всех этапах жизненного цикла информационной системы.

Характеристики современных операционных систем

Год за годом происходит эволюция структуры и возможностей операцион­ных систем. В последнее время в состав новых операционных систем и новых версий уже существующих операционных систем вошли некоторые структурные элементы, которые внесли большие изменения в природу этих систем. Совре­менные операционные системы отвечают требованиям постоянно развивающего­ся аппаратного и программного обеспечения. Они способны управлять работой многопроцессорных систем, работающих быстрее обычных машин, высокоскоро­стных сетевых приспособлений и разнообразных запоминающих устройств, чис­ло которых постоянно увеличивается. Из приложений, оказавших влияние на устройство операционных систем, следует отметить мультимедийные приложе­ния, средства доступа к Internet, а также модель клиент/сервер.

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

· Архитектура микроядра.

· Многопоточность.

· Симметричная многопроцессорность.

· Распределенные операционные системы.

· Объектно-ориентированный дизайн.

Отличительной особенностью большинства операционных систем на сего­дняшний день является большое монолитное ядро. Ядро операционной системы обеспечивает большинство ее возможностей, включая планирование, работу с файловой системой, сетевые функции, работу драйверов различных устройств, управление памятью и многие другие. Обычно монолитное ядро реализуется как единый процесс, все элементы которого используют одно и то же адресное про­странство. В архитектуре микроядра ядру отводится лишь несколько самых важных функций, в число которых входят работа с адресными пространствами, обеспечение взаимодействия между процессами (interprocess communication - IPC) и основное планирование. Работу других сервисов операционной системы обеспечивают процессы, которые иногда называют серверами. Эти процессы за­пускаются в пользовательском режиме и микроядро работает с ними так же, как и с другими приложениями. Такой подход позволяет разделить задачу разработ­ки операционной системы на разработку ядра и разработку сервера. Серверы можно настраивать для требований конкретных приложений или среды. Выде­ление в структуре системы микроядра упрощает реализацию системы, обеспечи­вает ее гибкость, а также хорошо вписывается в распределенную среду. Факти­чески микроядро взаимодействует с локальным и удаленным сервером по одной и той же схеме, что упрощает построение распределенных систем.

Многопоточность (multithreading) - это технология, при которой процесс, выполняющий приложение, разделяется на несколько одновременно выполняе­мых потоков. Ниже приведены основные различия между потоком и процессом.

· Поток. Диспетчеризуемая единица работы, включающая контекст процессо­ра (куда входит содержимое программного счетчика и указателя вершины стека), а также свою собственную область стека (для организации вызова подпрограмм и хранения локальных данных). Команды потока выполняют­ ся последовательно; поток может быть прерван при переключении процес­сора на обработку другого потока 4 .Процесс. Набор из одного или нескольких потоков, а также связанных с этими потоками системных ресурсов (таких, как область памяти, в которую входят код и данные, открытые файлы, различные устройства). Эта кон­цепция очень близка концепции выполняющейся программы. Разбивая приложение на несколько потоков, программист получает все преимущества модульности приложения и возможность управления связанными с прило­жением временными событиями.

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

До недавнего времени все персональные компьютеры, рассчитанные на одного пользователя, и рабочие станции содержали один виртуальный микропро­цессор общего назначения. В результате постоянного повышения требований к производительности и понижения стоимости микропроцессоров производители перешли к выпуску компьютеров с несколькими процессорами. Для повышения эффективности и надежности используется технология симметричной многопро­цессорности (symmetric multiprocessing - SMP). Этот термин относится к архи­тектуре аппаратного обеспечения компьютера, а также к образу действий опера­ционной системы, соответствующему этой архитектурной особенности. Симмет­ричную многопроцессорность можно определить как автономную компьютерную систему со следующими характеристиками.

1. В системе имеется несколько процессоров.

2. Эти процессоры, соединенные между собой коммуникационной шиной или какой-нибудь другой схемой, совместно используют одну и ту же основную память и одни и те же устройства ввода-вывода.

3. Все процессоры могут выполнять одни и те же функции (отсюда название симметричная обработка).

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

· Производительность . Если задание, которое должен выполнить компьютер, можно организовать так, что какие-то части этого задания будут выпол­няться параллельно, это приведет к повышению производительности по сравнению с однопроцессорной системой с процессором того же типа. Сформулированное выше положение проиллюстрировано на рис. 2.12. В много­ задачном режиме в один и тот же момент времени может выполняться только один процесс, тогда как остальные процессы вынуждены ожидать своей очереди. В многопроцессорной системе могут выполняться одновременно несколько процессов, причем каждый из них будет работать на от­ дельном процессоре.

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

· Наращивание . Добавляя в систему дополнительные процессоры, пользователь может повысить ее производительность.

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

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

Рис. 2.12. Многозадачность и многопроцессорность

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

Заманчивой особенностью многопроцессорных систем является то, что наличие нескольких процессоров прозрачно для пользователя -за распреде­ление потоков между процессорами и за синхронизацию разных процессов отвечает операционная система. В этой книге рассматриваются механизмы планирования и синхронизации, которые используются, чтобы все процессы и процессоры были видны пользователю в виде единой системы. Другая за­дача более высокого уровня - представление в виде единой системы класте­ра из нескольких отдельных компьютеров. В этом случае мы имеем дело с набором компьютеров, каждый из которых обладает своей собственной ос­новной и вторичной памятью и своими модулями ввода-вывода. Распреде­ленная операционная система создает видимость единого пространства ос­новной и вторичной памяти, а также единой файловой системы. Хотя попу­лярность кластеров неуклонно возрастает и на рынке появляется все больше кластерных продуктов, современные распределенные операционные системы все еще отстают в развитии от одно- и многопроцессорных систем. С подоб­ными системами вы познакомитесь в шестой части книги.

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

1.1 Понятие термина – «CASE-средства»

Первоначально под термином «CASE-технология» (Computer – Aided Software Engineering) понималось буквально – «автоматизированная разработка ПО ИС с помощью компьютерных технологий».

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

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

Методология CASE-средства определяет этапы и шаги реализации проекта, а также правила использования методов, которыми разрабатывается проект. МетодCASE-средства –это процедура или техника генерации описаний компонентов информационной системы (проектирование потоков и структур данных). Нотация CASE-средства – отображение структуры системы, элементов данных с помощью специальных графических символов.

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

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

1.2 Типовая структура CASE-средств

CASE-средства служат инструментарием для поддержки и использования методов структурного анализа в проектировании. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме. Они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов. Фактически CASE-средства представляют собой новый тип графически-ориентированных инструментов, восходящих к системе поддержки ЖЦ ПО. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные характеристики:

мощная графика для описания и документирования систем ПО со специфическим интерфейсом пользователя, развивающая творческие возможности специалистов и не отвлекающая их от процесса проектирования на решение второстепенных вопросов;

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

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

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

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

2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.).

3. Автоматизированная или автоматическая кодогенерация, для различных платформ и различного вида кода: преобразования для получения документации; формирования структуры БД, ввода/модификации данных; получения выполняемых машинных кодов из спецификаций ПО; сборки модулей из словарей и моделей данных и повторно используемых программ.

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

5. Доступность для разных категорий пользователей.

6. Рентабельность.

7. Эффективное решение задач по сопровождению разработанного проекта, обеспечивающая способность адаптации при изменении требований и целей проекта заказчиком.

В состав практически всех современных CASE-средств входят следующие элементы :

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

средства разработки приложений, с использованием языков 4GL и генераторов кодов;

средства тестирования;

средства документирования;

графические средства анализа и проектирования, которые дают возможность создавать и редактировать модели информационных систем в виде иерархически связанных диаграмм в реализованной нотации конкретной методологии;

средства реинжиниринга;

средства конфигурационного управления;

средства управления проектом.

1.3 Эволюция развития CASE-технологий

С самого начала CASE-технологии развивались с целью преодоления ограничений «ручного» применения методологии структурного анализа и проектирования 60-70-х годов за счет ее автоматизации и интеграции в поддерживающие средства. Таким образом, CASE-технологии не могут считаться самостоятельными методологиями моделирования, они только делают более эффективными их применение, с точки зрения времени разработки.

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

1. Ассемблеров, дампов памяти, анализаторов;

2. Компиляторов, интерпретаторов, трассировщиков;

3. Символьных отладчиков, пакетов программ;

4. Систем анализа и управления исходными текстами;

5. CASE-средств анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация CASE-I);

6. CASE-средств генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла разработки ПО (вторая генерация CASE-II)

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

CASE-II отличается значительно более развитыми возможностями, улучшенными характеристиками и исчерпывающим подходом к полному жизненному циклу разрабатываемого ПО. В инструментарии CASE-II, в первую очередь, используются средства поддержки автоматической кодогенерации, а также, обеспечивается полная функциональная поддержка для выполнения графических системных требований и спецификаций проектирования; контроля, анализа и связывания системной информации и информации по управлению проектированием; построение прототипов и моделей системы; тестирования, верификации и анализа сгенерированных программ; генерации документов по проекту; контроля на соответствие стандартам по всем этапам жизненного цикла. CASE-II может включать свыше 100 функциональных компонент, поддерживающих все этапы жизненного цикла, при этом пользователям предоставляется возможность выбора необходимых средств и их интеграции в нужном составе .

1.4 Методологии проектирования, используемые в CASE–средствах

CASE-средства являются результатом естественного эволюционного развития отрасли инструментальных (или технологических) средств. CASE-технологии начали развиваться с целью преодоления ограничений методологии структурного программирования.

Эта методология, несмотря на формализацию в составлении программ, характеризуется все же сложностью понимания, большой трудоемкостью и стоимостью использования, трудностью внесения изменений в проектные спецификации. Заложенные в ней принципы позволили развивать эту методологию и повысить е эффективность за счет автоматизации наиболее рутинних этапов (рис. 1.1).

Основными стандартами методологий, реализованных в CASE-средствах, являются:

SADT (Structured Analysis and Design Technique) - методология структурного анализа и проектирования. Основана на понятиях функционального моделирования. Отражает такие системные характеристики, как управление, обратная связь и исполнитель;

IDEF0 (Integrated Definition Function Modeling) - методология функционального моделирования. Используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями. Является подмножеством методологии SADT;

DFD(DataFlow Diagram) - методология моделирования потоков данных.

Рисунок 1.1 – Сравнение традиционной разработки и разработки с использованием CASE-технологий

Следующие стандарты методологий применяются для описания обмена данными между рабочими процессами:

IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы;

IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации и ресурсов системы;

IDEF3- методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса;

IDEF1X (IDEF1 Extended) - методология описания данных. Применяется для построения баз данных. Относится к типу методологий «Сущность-связь» (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

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

IDEF5- методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени;

ARIS - описывает бизнес-процесс в виде потока последовательно выполняемых работ;

UML - (Unified Modeling Language) унифицированный язык моделирования, основанный на объектно-ориентированном подходе. UML позволяют описать статическую структуру системы и ее динамическое поведение в соответствующих нотациях.

В CASE-средствах широко используются методологии структурного и объектно-ориентированного проектирования. Структурное проектирование основано на алгоритмической декомпозиции, а объектно-ориентированное проектирование – на объектно-ориентированной декомпозиции. Алгоритмическая декомпозиция позволяет определить порядок происходящих событий. Объектно-ориентированная декомпозиция позволяет определить иерархию классов объектов, их методы и свойства. CASE-средства, поддерживающие объектно-ориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML.

1.5 Методология CASE-средств объектно-ориентированного проектирования

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

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

Буч отмечает также ряд следующих преимуществ объектно-ориентированного подхода .

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

4. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

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

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

При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть и расходы на обучение (овладение методом, инструментальными средствами и языком программирования). Для некоторых организаций эти обстоятельства могут стать серьезными препятствиями. Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области. Переход организации на объектно-ориентированную технологию - это смена мировоззрения, а не просто изучение новых CASE-средств и языков программирования .

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

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

Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах. Объектно-ориентированное проектирование имеет точки соприкосновения с реляционным проектированием. Например, как было отмечено выше, классы в объектной модели могут некоторым образом соответствовать сущностям (в качестве упражнения можно предложить детально проанализировать все сходства и различия диаграмм «сущность-связь» и диаграмм классов). Как правило, такое соответствие имеет место только на ранней стадии разработки системы - стадии формирования требований. В дальнейшем, разумеется, цели объектно-ориентированного проектирования (адекватное моделирование предметной области в терминах взаимодействия объектов) и разработки реляционной БД (нормализация данных) расходятся. Таким образом, единственно возможным средством преодоления данного пробела является определение соответствия между объектно-ориентированной и реляционной технологиями, которое в основном сводится к отображению диаграмм классов и диаграмм «сущность – связь» реляционной модели. Одним из примеров практической реализации взаимосвязи между структурным и объектно-ориентированным подходом является программный интерфейс (мост) между структурным CASE-средством Silverrun и объектно-ориентированным CASE-средством Rational Rose, разработанный российской компанией "Аргуссофт" .Это ПО создает диаграммы классов Rational Rose на основе RDM-модели (Relational Data Model - реляционная модель данных) Silverrun и наоборот. Аналогичные интерфейсы существуют также между CASE-средствами ERwin (с одной стороны), Rational Rose и Paradigm Plus (с другой стороны).

1.6 Методология CASE-средств структурного проектирования

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

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

принцип декомпозиции - принцип решения сложных проблем путем их разбиения на множество более мелких и независимых задач, легких для понимания и решения;

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

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

принцип формализации –- заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности использования элементов системы;

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

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

Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными из них являются следующие :

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».

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

ВведениеДублирование устройств и распараллеливание нагрузки – достаточно популярная идея на современном рынке персональных компьютеров. Энтузиасты нередко прибегают к созданию видеоподсистем, в которых используется две или большее количество графических карт, а те пользователи, которые нуждаются в непревзойдённой вычислительной производительности, зачастую делают ставку на многопроцессорные рабочие станции. Подобный подход можно применить и в отношении дисковой подсистемы: достаточно простой способ увеличения скорости её работы – это формирование RAID-массива из пары (или большего количества) жёстких дисков. Массивы уровня 0 (stripe) предполагают дробление всей сохраняемой информации на равные части, которые равномерно распределяются по нескольким физическим накопителям. В результате, за счёт параллельного чтения и записи данных сразу на несколько накопителей скорость работы такой системы по сравнению с одним диском может быть повышена в несколько раз.

Собственно, на заре распространения SSD потребительского класса были достаточно популярны рассуждения о том, RAID-массив из какого количества винчестеров сможет обеспечить производительность, сравнимую со скоростью флэш-накопителя. Конечно, сейчас эти времена уже безвозвратно ушли. Внедрение стандарта SATA 6 Гбит/сек и появление нового поколения контроллеров для твердотельных накопителей привело к тому, что скорости современных SSD ушли слишком далеко от того уровня быстродействия, который могут обеспечить традиционные магнитные диски. Однако возник другой не менее интересный вопрос: можно ли дополнительно увеличить производительность дисковой подсистемы, если в массив RAID 0 собрать несколько SSD?

Действительно, причин, по которым технология RAID не должна оказывать положительный эффект в случае с SSD, на первый взгляд не видно. Твердотельные накопители показывают хорошее быстродействие при работе с небольшими блоками данных, а чипсетные RAID-контроллеры предлагают прямую связь с процессором с пропускной способностью, вполне достаточной для получения скоростей, превосходящих SATA 6 Гбит/сек в несколько раз. Так что существенного увеличения производительности работы можно ожидать и от RAID 0 на базе SSD. Идея кажется особенно привлекательной ещё и потому, что она не сопряжена ни с какими дополнительными затратами. Общая ёмкость массива RAID 0 представляет собой сумму ёмкостей входящих в него накопителей, а стоимость SSD прямо пропорциональна их ёмкости. То есть, если для создания массива пользоваться «бесплатным» RAID-контроллером встроенным в чипсет материнской платы, то в итоге мы получим примерно такую же стоимость хранения гигабайта информации, как и в случае одиночного диска большего размера.

Учитывая кажущуюся привлекательность создания RAID 0 массивов из твердотельных накопителей, мы решили проверить их работу на практике. Компания Kingston любезно согласилась предоставить нам на тесты два 120-гигабайтных и один 240-гигабайтный SSD своей топовой серии HyperX, что и дало возможность прямого сравнения RAID 0 массива из двух дисков с одиночным накопителем аналогичного объёма.

Подробнее о Kingston HyperX SSD

Накопители серии Kingston HyperX SSD – это типичные решения на базе контроллеров SandForce второго поколения, нацеленные на энтузиастов. Они базируются на хорошо знакомом нам чипе SF-2281 и комплектуются 25-нм синхронной NAND-памятью производства компаний Intel или Micron. Проще говоря, накопители HyperX используют производительный вариант актуальной платформы SandForce и по своим внутренностям аналогичны таким популярным моделям как Corsair Force Series GT или OCZ Vertex 3.

Выделяет Kingston HyperX SSD в ряду подобных SandForce-накопителей разве только более броский дизайн корпуса, да и фирменная программа Toolbox, позволяющая просматривать различную информацию о диске, включая значение атрибутов S.M.A.R.T.

Утилита эта поразительно похожа на OCZ Toolbox с вырезанной функцией обновления прошивки (для этого у Kingston предлагается специализированная программа) и без возможности Secure Erase.

Как и у всех других накопителей с контроллерами SandForce, диски Kingston HyperX SSD с ёмкостью 120 и 240 Гбайт отличаются по производительности. В официальных спецификациях это отражается следующим образом:

Причина различий состоит в количестве используемых в составе SSD оконечных NAND-устройств. Так как 25-нм кристаллы MLC флэш-памяти имеют объём 8 Гбайт, 120-гигабайтный диск содержит 16 флэш-устройств, в то время как более ёмкая модификация укомплектована 32 устройствами. Учитывая, что контроллер SandForce SF-2281 имеет восьмиканальную архитектуру, накопители с разной емкостью вынуждены использовать для каждого канала технику чередования обращений к флэш-устройствам с разной кратностью. Так, в случае 120-гигабайтного SSD чередование двукратное, а в случае 240-гигабайтного накопителя – четырёхкратное. Большая кратность чередования гарантирует более высокую производительность, так как вместо ожидания готовности NAND-устройства после очередной операции контроллер имеет возможность перейти к обслуживанию следующего устройства. По сути это похоже на реализацию подхода RAID 0, но внутри накопителя, на уровне контроллера SandForce.

Тестовая система

Для тестирования SSD-накопителей мы собрали специальную систему, построенную на материнской плате с набором логики Intel H67, который, как известно, обладает парой SATA 6 Гбит/сек портов. Именно на этих портах мы и испытываем твердотельные накопители.

В целом, тестовая конфигурация включает следующий набор оборудования:

Процессор – Intel Core i5-2400 (Sandy Bridge, 4 ядра, 3.1 ГГц, технологии EIST и Turbo Boost –отключены);
Материнская плата - Foxconn H67S (версия BIOS A41F1P01);
Память - 2 x 2 GB DDR3-1333 SDRAM DIMM 9-9-9-24-1T;
Системный накопитель – Crucial m4 256 Гбайт (CT256M4SSD2);
Тестовые накопители:

Kingston HyperX 120 Гбайт (SH100S3/120G, прошивка 332);
Kingston HyperX 240 Гбайт (SH100S3/240G, прошивка 332);

Операционная система - Microsoft Windows 7 SP1 Ultimate x64;
Драйверы:

Intel Chipset Driver 9.2.0.1030;
Intel HD Graphics Driver 15.22.1.2361;
Intel Management Engine Driver 7.1.10.1065;
Intel Rapid Storage Technology 10.8.0.1003.

Проблемы конфигурирования RAID 0 из SSD

Для создания массива из SSD-дисков мы решили пользоваться стандартным RAID-контроллером, встраиваемым в современные наборы системной логики. Чипсетные SATA-контроллеры хорошо показывают себя в работе с одиночными SSD, и вполне подходят для наших целей, тем более что врождённая поддержка RAID уже есть в большинстве современных систем, то есть не требует дополнительных финансовых затрат.

Наша стандартная тестовая платформа основывается на LGA1155-процессоре и системной плате с чипсетом H67, SATA-контроллер которого имеет встроенную поддержку RAID-массивов. Для её активации необходима смена режима работы SATA-контроллера с AHCI на RAID в BIOS. Однако простое изменение соответствующей опции в BIOS Setup приведёт скорее всего к неработоспособности операционной системы, выражающейся в возникновении «синего экрана» на этапе загрузки. Причина состоит в том, что драйвер RAID в Windows по умолчанию отключен. Обойти эту проблему можно двумя путями. Либо заново, уже в RAID-режиме, переустановить Windows, и тогда необходимый драйвер автоматически включится при установке. Либо, непосредственно перед изменением настроек SATA-контроллера в BIOS, установить в 0 значение переменной Start, находящейся в системном реестре в ветке HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Iastorv, а затем переустановить драйвер SATA-контроллера Intel Rapid Storage Technology (RST) уже в RAID-режиме.

После включения режима RAID и внедрения в систему необходимых драйверов, можно переходить непосредственно к формированию массива. Он создаётся средствами драйвера Intel RST. В процессе потребуется лишь указать диски для включения в массив и его режим работы – RAID 0.

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

По понятным причинам кэширование мы включать не рекомендуем, тем более что подобную функциональность предлагает и сама операционная система. Что же касается размера страйпа –блоков, на которые разбиваются дисковые операции для распределения по накопителям, составляющим массив, то тут слепо опираться на предлагаемые драйвером 128 Кбайт – подход не самый разумный. Большой размер страйпа имеет смысл для накопителей на магнитных дисках, так как они выполняют операции линейного чтения и записи больших блоков значительно быстрее, чем операции с маленькими блоками, требующие интенсивного перепозиционирования головок. SSD же обладают очень малым временем доступа, так что выбор небольших страйп-блоков может обеспечить лучшую производительность на операциях с файлами небольшого объёма.

И хотя скорость одиночного Kingston HyperX SSD 120 Гбайт при работе с блоками данных растёт при увеличении размера блока, это ещё ничего не значит.

Драйвер Intel Rapid Storage Technology (RST) способен достаточно интеллектуально обращаться с очередью запросов, обеспечивая высокую скорость RAID 0-массива из SSD и при использования небольших страйп-блоков. В доказательство этого мы оценили базовые характеристики производительности RAID 0-массива из пары Kingston HyperX SSD 120 Гбайт с разными размерами страйпа.

Data stripe size = 4 KB:

Data stripe size = 8 KB:

Data stripe size = 16 KB:

Data stripe size = 32 KB:

Data stripe size = 64 KB:

Data stripe size = 128 KB:

Как показывают результаты AS SSD Benchmark, скоростные показатели массива со страйп-блоками разного размера достаточно близки. Тем не менее, зависимость скорости последовательных операций, а также скорости работы с мелкими блоками при высокой глубине очереди от размера страйпа прослеживается. Наилучшее сочетание показателей производительности массива достигается при использовании 32-килобайтных блоков, так что, очевидно, настройки по умолчанию не являются оптимальными. Так как меньший размер страйпа более выгоден при работе с небольшими файлами, в случае использования дисков, основанных на платформе SandForce второго поколения, мы рекомендуем использовать размер блока в 32 Кбайта. Именно с такой настройкой мы создавали и используемый в основной части тестирования массив.

При создании RAID-массивов важно иметь в виду и ещё одну немаловажную деталь. Как только массив сформирован, он начинает рассматриваться системой как единое целое, и прямой доступ к составляющим его накопителям становится невозможен. Это – достаточно неприятный момент, сулящий серьёзные практические неудобства. Имея RAID-массив из SSD дисков, вы не сможете ни обновить их прошивку, ни посмотреть параметры S.M.A.R.T., ни выполнить операцию Secure Erase. Но что самое неприятное, учитывая специфику такого массива, операционная система не сможет передать накопителям команду TRIM, посредством которой возможно эффективное противодействие деградации производительности SSD.

Производительность

Скорость случайного и последовательного чтения/записи «свежего» накопителя

Для измерения скорости случайного и последовательного чтения и записи мы используем тест CrystalDiskMark 3.0.1. Этот бенчмарк удобен тем, что позволяет измерять скоростные характеристики SSD-накопителей как на случайных несжимаемых данных, так и при использовании полностью сжимаемых шаблонных данных. Поэтому, на приводимых далее диаграммах приводится по два числа – максимальная и минимальная скорость работы накопителя. Реальные же показатели, соответственно, будут лежать внутри изображённых диапазонов в зависимости от того, как их сможет уплотнить контроллер SF-2281.

Заметим, что приведенные в этом разделе результаты тестов производительности относятся к «свежему» (FOB - Fresh Out-of-Box) недеградировавшему состоянию накопителя.

С точки зрения практических показателей быстродействия 120-гигабайтный SSD работает существенно медленнее своего 240-гигабайтного собрата. Тем не менее, RAID 0-массив из пары 120-гигабайтных дисков всё же превосходит по скорости единичный накопитель ёмкостью 240 Гбайт. Как видим, технология RAID 0 позволяет получить выигрыш в скорости линейных операций и при работе с небольшими блоками при использовании очереди запросов большой глубины. Обычные случайные же операции с 4-килобайтными блоками не ускоряются, более того, наблюдается даже некоторое замедление, обусловленное задержками на необходимость дополнительного арбитража.

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

К сожалению, SSD-накопители демонстрируют высокую скорость, свойственную «свежему» состоянию, далеко не всё время. В большинстве случаев через какое-то время производительность понижается, и в реальной жизни мы имеем дело совсем не с теми скоростями записи, что приведены на диаграммах в предыдущем разделе. Причина данного эффекта состоит в том, что по мере исчерпания свободных страниц во флэш-памяти, контроллер SSD приходит к необходимости проводить перед сохранением данных операции очистки блоков страниц, которые добавляют существенные задержки.

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

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

Впрочем, картина катастрофического падения скорости, показанная на графике выше, несколько искусственна и характерна лишь для случая непрерывной и безостановочной записи. В реальности же, находясь в состоянии покоя, контроллеры современных SSD-дисков частично восстанавливают производительность, предварительно освобождая неиспользуемые страницы флэш-памяти. На это направлено два ключевых алгоритма: Idle-Time Garbadge Collection (сборка мусора) и TRIM. Однако в случае с массивом RAID 0 ситуация осложняется тем, что операционная система не имеет прямого доступа к SSD, в результате чего технология TRIM не работает. В связи с этим вполне вероятна ситуация, что спустя какое-то время эксплуатации единичный диск может оказаться существенно лучше RAID-массива.

Никто не мешает проверить это предположение. Для получения картины деградации дисков и RAID 0 массива мы, основываясь на методике SNIA SSSI TWG PTS, провели специальные тесты. Их суть состоит в том, что мы последовательно измерили скорость операций записи в четырёх случаях. Вначале - для «свежего» состояния массива и накопителей. Затем – после полного двукратного заполнения информацией накопителей и RAID-массива. Далее – после получасовой паузы, дающей контроллеру возможность частично восстановить производительность накопителя за счёт операции сборки мусора. И в завершение – после подачи команды TRIM.

Измерения выполнялись при помощи синтетического бенчмарка IOMeter 1.1.0 RC1, в котором мы отслеживали скорость случайной записи при работе с выровненными относительно страниц флэш-памяти блоками объёмом 4 Кбайт с глубиной очереди запросов 32 команды. При тестировании использовалось заполнение псевдослучайными данными.

Деградация производительности – это не пустой звук, а реально существующая проблема. Как видим, скорость накопителей действительно снижается в разы. Причём, как это ни прискорбно, но сборка мусора у накопителей на основе контроллера SF-2281 практически не работает. Несмотря на то, что накопители с этой архитектурой имеют резервную область, составляющую примерно 7 % от общей ёмкости, это им совершенно не помогает. Возвращает производительность к более-менее нормальному уровню лишь команда TRIM. Однако так как для RAID-массивов она не работает, в конечном итоге одиночные накопители могут предложить куда лучшее быстродействие на операциях записи, чем составленный из них массив.

Всё это означает, что те скорости записи, которые были приведены на диаграммах в предыдущем разделе, отражают лишь незначительную часть общей картины. На самом же деле, после того, как SSD перейдут из свежего в использованное состояние, соотношение результатов коренным образом поменяется. Скорость записи в этом случае будет совсем иной: результаты её измерения бенчмарком CrystalDiskMark 3.0.1 приводятся на следующих диаграммах.

Как видим, в процессе использования скорость работы RAID 0 массива из SSD снижается до такой степени, что на операциях с 4-килобайтными блоками он становится даже медленнее одиночного 120-гигабайтного накопителя, производительность которого поддерживается на хорошем уровне командой TRIM. Так что в реальной жизни создание массива RAID 0 из SSD оправдывается преимущественно высокими скоростями чтения, которые не подвержены снижению по мере заполнения накопителя данными.

Тесты в Futuremark PCMark 7

Известный тест PCMark 7 включает отдельный бенчмарк для измерения производительности дисковой подсистемы. Причём, он имеет не синтетическую природу, а, напротив, основывается на том, как работают с диском реальные приложения. Этот бенчмарк воспроизводит настоящие сценарии-трассы задействования диска в распространённых задачах и замеряет скорость их выполнения. Причём, воспроизведение потока команд делается не сплошняком, а так, как это происходит в реальности – с определёнными паузами, обусловленными необходимостью обрабатывать поступающие данные. Результатом теста является общий индекс производительности дисковой подсистемы и показатели скорости в отдельных сценариях в мегабайтах в секунду. Заметьте – производительность в сценариях в абсолютном выражении получается относительно невысокой, так как в неё вносят вклад те самые моделируемые паузы между отдельными операциями ввода-вывода. Иными словами, то, что выдаёт PCMark 7, – это скорость дисковой подсистемы со стороны приложения. Такие величины дают нам информацию не столько о чистой производительности накопителей, сколько о том, какой практический выигрыш способен привнести тот или иной SSD при реальной работе.

Тестирование в PCMark 7 мы выполняли с накопителями, находящимися в «использованном» состоянии, в котором они работают в реальных системах большинство времени. Влияние на результаты в этом случае оказывает не только скорость контроллера и установленной в накопителе флэш-памяти, но и эффективность работы внутренних алгоритмов SSD, направленных на восстановление производительности.

Интегральный показатель PCMark 7 – прекрасный ориентир для тех потребителей, кто не хочет вдаваться в подробности и довольствуется простой иллюстрацией относительной производительности накопителей. И, если верить в полученные рейтинги, массив RAID 0 обладает в целом лучшим быстродействием, чем одиночный диск аналогичной ёмкости. Если принять во внимание, что большинство жизненных сценариев использования дисковой подсистемы предполагает преобладание операций чтения, полученные результаты кажутся вполне логичными и заслуживающими доверия.

Для полноты картины следует ознакомиться и с промежуточными результатами показанными дисками и RAID-массивом при прохождении отдельных тестовых трасс. Тем более что в некоторых ситуациях отличия в быстродействии достигают более внушительного размера.

Как видим, существуют сценарии, для которых RAID-массивы из SSD на платформе SandForce второго поколения противопоказаны. Очевидно, что такая картина наблюдается в случаях, когда от дисковой подсистемы требуется активная работа с небольшими порциями данных. В данном случае это сценарии Gaming и Windows Defender.

Тесты в Intel NAS Performance Toolkit

Intel NASPT – это ещё один основанный на использовании реальных сценариев тест дисковой подсистемы. Также как и PCMark 7, он воспроизводит заранее подготовленные типовые шаблоны дисковой активности, попутно измеряя скорость их прохождения. Данный бенчмарк вместе с PCMark 7 позволяет получить отличную иллюстрацию производительности дисковой подсистемы в реальных задачах. Также как и в предыдущем случае, тестирование мы выполняли с накопителями, находящимися в устоявшемся «использованном» состоянии.

Intel NASPT совершенно однозначно ставит на первое место по производительности RAID 0 массив, состоящий из пары 120-гигабайтных накопителей. Причём, скорость такого двухдискового массива по данным теста превосходит производительность одного SSD почти что вдвое. Впрочем, столь заметный успех технологии RAID способны омрачить некоторые результаты, полученные в индивидуальных подтестах.

Всё хорошо до тех пор, пока дело касается чтения информации. Когда же тестовые сценарии включают запись, одиночный 240-гигабайтный SSD демонстрирует более высокую скорость.

Выводы

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

Создание массива RAID 0 – это один из традиционных путей для повышения производительности дисковой подсистемы. Этот приём вполне работает и для SSD, объединение в массив пары дисков действительно позволяет нарастить как линейные скорости, так и быстродействие операций над небольшими блоками с глубокой очередью запросов. Так, в процессе тестов нам удалось получить для массива поистине впечатляющие скорости последовательного чтения и записи, существенно превосходящие пропускную способность интерфейса SATA 6 Гбит/сек.

Но не следует забывать, что скорость работы современных твердотельных дисков с ростом их ёмкости увеличивается даже в рамках одной продуктовой линейки, поэтому массив уровня 0 из двух дисков может порой уступать по производительности более вместительной модели накопителя. Ещё более серьёзная проблема RAID-массива из SSD заключается в том, что большинство SATA-контроллеров, включая и встроенные в современные наборы логики, не поддерживают команду TRIM. В результате, в процессе практического использования массив существенно деградирует по скорости записи, в то время как одиночные диски этому эффекту подвержены в гораздо меньшей степени.

В итоге, RAID 0 однозначно выигрывает у одиночного диска лишь на линейных операциях, в то время как случайные запросы обнажают слабые места этого подхода. Иными словами, назвать массив RAID 0 более производительным решением, нежели одиночный флэш-диск, можно лишь с достаточно серьёзными оговорками. Впрочем, в большинстве тестов, основанных на сценариях реального использования дисковой подсистемы, массив показал всё же более высокое быстродействие. То есть, усреднённо RAID 0 себя оправдывает, тем более что он не требует никаких дополнительных финансовых затрат – стоимость за гигабайт в итоговой конфигурации получается одинаковой и для массива, и для одиночного диска.

Однако использование SSD в составе массива вызывает некоторые дополнительные неудобства. Для накопителей, собранных в массив, невозможно отслеживание их «состояния здоровья» и обновление прошивок. Кроме того, система, состоящая из пары SSD, имеет более низкую надёжность, чем один диск, причём выход из строя хотя бы одного накопителя приведёт к потере всех хранящихся в массиве данных.