6.Модели и этапы разработки программного обеспечения

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная.

Каскадная модель («Водопад»)

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

Преимущества «водопада»

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

• Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».

•Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

•Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже

написал код, а технические писатели — документацию.

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

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

V-образная модель

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

36

Преимущества V-образной модели

•Количество ошибок в архитектуре ПО сводится к минимуму. Недостатки V-образной модели

•Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

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

Инкрементная модель разработки по частям

37

Преимущества инкрементной модели

•Не нужно вкладывать много денег на начальном этапе.

Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.

•Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.

•Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

•Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-

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

•Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку».Чтобы этого не случилось,

менеджер проекта должен контролировать, чем занимается каждая команда.

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

Итерационная модель, при которой заказчик не обязан

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

Преимущества итеративной модели

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

обнаруживать и устранять ошибки.

38

Недостатки итеративной модели

•Использование на начальном этапе баз данных или серверов—

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

•Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка.

Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с

инновационным подходом, когда заказчик не уверен в результате.

Спиральная модель

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

Спиральная модель похожа на инкрементную, но здесь гораздо больше

времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в

исследовательских проектах и там, где высоки риски.

Преимущества спиральной модели

•Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

•Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.

Разработка длится долго и стоит дорого. (Система «Умный дом»).

Этапы разработки ПО

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

Этапы разработки ПО

39

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

2. Анализ требований (Requirements Engineering) — это процесс сбора требований к системе, их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов.

Требование – это потребность или ожидание, которое

•установлено в явном виде (например, заказчиком)

•наследуется, как обязательное из других систем требований (ГОСТа)

•подразумевается (например, выход по ESC) Описание системы

3.Проектирование ПО. Разработка архитектуры.

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

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

атакже вопрос пользовательского интерфейса.

4.Кодирование – реализация одного или нескольких взаимосвязанных алгоритмов на некотором языке программирования.

5.Тестирование (частей ПО –> интеграция и тестирование системы в целом) - процесс, позволяющий определить корректность, полноту и качество разработанного ПО; процесс формальной проверки

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

В зависимости от используемого процесса разработки (модели разработки) шаги 2 - 5 могут быть выполнены несколько раз.

6. Документирование - это документы, сопровождающие некоторое ПО.

40

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

•Техническая - документация на код, алгоритмы, интерфейсы, API;

•Пользовательская – руководства для конечных пользователей, администраторов системы и другого персонала;

•Маркетинговая.

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

8.Сопровождение - процесс улучшения, оптимизации и устранения дефектов (ПО) после передачи в эксплуатацию. Может

потребовать до 80 % ресурсов, потребовавшихся на разработку.

7.Реляционные СУБД. Объектно-ориентированные базы

данных

Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение. Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:

41

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

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

Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) - это набор именованных схем отношений.

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа.

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

42

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

Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

Фундаментальные свойства отношений:

• Отсутствие кортежей-дубликатов. То свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения как множества кортежей. В классической теории множеств по определению каждое множество состоит из различных элементов. Из этого свойства вытекает наличие у каждого отношения так называемого первичного ключа - набора атрибутов, значения которых однозначно определяют кортеж отношения. Для каждого отношения по крайней мере полный набор его атрибутов обладает этим свойством. Однако при формальном определении первичного ключа требуется обеспечение его "минимальности", т.е. в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно отбросить без ущерба для основного свойства - однозначно определять кортеж.

• Отсутствие упорядоченности кортежей. Свойство отсутствия упорядоченности кортежей отношения также является следствием определения отношения-экземпляра как множества кортежей.

•Отсутствие упорядоченности атрибутов. Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество пар {имя атрибута, имя домена}. Для ссылки на значение атрибута в кортеже отношения всегда используется имя атрибута.

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

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

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

43

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

Вструктурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.

Вманипуляционной части модели утверждаются два

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

Наконец, в целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД.

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

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

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

44

•объединения отношений; При выполнении операции объединения двух отношений производится отношение, включающее все кортежи, входящие хотя бы в одно из отношений-операндов.

•пересечения отношений; Операция пересечения двух отношений производит отношение, включающее все кортежи, входящие в оба отношения-операнда.

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

•прямого произведения отношений. При выполнении прямого произведения двух отношений производится отношение, кортежи

которого являются конкатенацией (сцеплением) кортежей первого и второго операндов.

Специальные реляционные операции включают:

• ограничение отношения; Результатом ограничения отношения по некоторому условию является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию.

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

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

•деление отношений. У операции реляционного деления два операнда - бинарное и унарное отношения. Результирующее

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

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

45

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

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

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

46

могла бы включать три класса (то есть три типа объектов): EMPLOYEE, JOB и ASSGNMENT. Объект класса EMPLOYEE мог бы содержать такие элементы, как Emplld, Name, Address и SSNum;

объект класса JOB — элементы Jobld, JobTitle, Ski 11 Code и Dept; объект класса ASSGNMENT — элементы StartDate и TermDate.

Концептуальное представление такой базы данных (рис. 11) образуется объектами и соединяющими их линиями, показывающими отношения между различными объектами. Рассмотрев объект типа EMPLOYEE, мы увидим, что он связан с набором объектов типа ASSIGNMENT, представляющих различные назначения сотрудника на должности. В свою очередь, каждый из объектов типа ASSIGNMENT связан с объектом типа JOB, обозначающим должность, которую занимал или занимает сотрудник. Таким образом, все назначения сотрудника на различные должности можно найти, проследив связи, идущие от объекта, представляющего сотрудника. Аналогично можно узнать, какие сотрудники занимали определенную должность, изучив ссылки от объекта, представляющего должность.

Рис. 11 – Связи между объектами в объектно-ориентированной базе данных

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

47

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

Другая задача объектно-ориентированной СУБД — обеспечивать постоянное хранение переданных ей объектов. Такое требование может казаться очевидным, но в действительности хранение отличается от обычного способа работы с объектами. В обыкновенной объектно-ориентированной программе объекты, созданные в ходе выполнения, удаляются во время завершения программы. В этом смысле объекты считаются временными. Но объекты, созданные и помещенные в базу данных, должны быть постоянными — то есть их необходимо сохранить после того, как программа, создавшая их, завершится. Поэтому обеспечение постоянного хранения объектов — это существенное отклонение от нормы.

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

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

48

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

Возможность инкапсулировать технические подробности различных форматов данных полезна и в других случаях. В реляционной базе данных атрибуты отношения являются частью общего дизайна базы данных, поэтому типы, связанные с этими атрибутами, появляются во всей СУБД. (Необходимо объявлять временные переменные подходящих типов и разрабатывать процедуры для обработки данных различных типов.) Таким образом, расширение реляционной базы данных за счет добавления атрибутов новых типов (к примеру, звуковых и видео) может быть проблематичным. Действительно, это потребует расширения множества процедур во всей базе данных, чтобы они могли работать и с новыми типами. С другой стороны, в объектно-ориентированной модели процедуры, которые используются для получения объектов, обозначающих имена сотрудников, могут извлекать информацию, например из объекта, представляющего видеоклип, так как различие в типах может быть скрыто внутри соответствующих объектов. Следовательно, при помощи объектно-ориентированного подхода удобнее конструировать мультимедийные базы данных — эта возможность уже является существенным преимуществом.

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

хранения интеллектуальных объектов вместо обычных данных. Это означает, что объект может содержать методы, описывающие, как он будет отвечать на сообщения, относящиеся к его содержимому и связям. Например, каждый объект класса EMPLOYEE (см. рис. 11) может содержать методы для вывода и обновления информации, хранящейся в объекте, а также для вывода предыдущих должностей сотрудника и, возможно, для регистрации перевода сотрудника на новую должность. Аналогично, каждый объект класса JOB может обладать методами для вывода характеристик должности и, возможно, для вывода списка сотрудников, которые занимали эту должность. Так, чтобы получить историю работы сотрудника в компании, нам не нужно будет создавать внешние процедуры, описывающие, как получить информацию. Вместо этого мы просто попросим соответствующий объект сотрудника рассказать его историю работы.

49

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

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

К сожалению, в объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или

Java.

Подведем теперь некоторые итоги:

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

Имеется возможность определения новых типов данных и операций с ними.

В то же время, ОО-модели присущ и ряд недостатков:

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

2.· Вместо чисто декларативных ограничений целостности (типа явного объявления первичных и внешних ключей реляционных таблиц

спомощью ключевых слов PRIMARY KEY и REFERENCES) или полудекларативных триггеров для обеспечения внутренней

целостности приходится писать процедурный код.

Очевидно, что оба эти недостатка связаны с отсутствием развитых средств манипулирования данными. Эта задача решается двумя способами — расширение ОО-языков в сторону управления данными (стандарт ODMG), либо добавление объектных свойств в реляционные СУБД (SQL-3, а также так называемые объектнореляционных СУБД).

Основными принципами объектно-ориентированной технологии являются: • абстракция; • инкапсуляция; • модульность; • иерархия; •

типизация; • полиморфизм; • наследование. Объектно-ориентированной БД (ООБД) является БД, которая

основывается на принципах объектно-ориентированной технологии.

50

8.Архитектуры вычислительных систем. Архитектура системы

команд

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

Архитектура вычислительной машины (англ. сomputerarchitecture)

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

Архитектура системы – совокупность свойств системы, существенных для пользования.

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

Общая классификация вычислительных систем обработки данных – архитектур

51

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

Все системы обработки данных можно разделить на два класса. Отдельные ЭВМ, вычислительные комплексы или специализированные системы образуют класс сосредоточенных (централизованных) систем, в которых реализуется вся обработка данных.

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

Архитектура системы команд

Системой команд вычислительной машины называют полный перечень команд, которые способна выполнять данная ЭВМ. В свою очередь, под архитектурой системы команд (АСК) принято определять те средства вычислительной машины, которые видны и доступны программисту.

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

-системы с одиночным потоком команд и одиночным потоком данных – ОКОД;

-системы с множественным потоком команд и одиночным потоком данных – МКОД;

-системы с одиночным потоком команд и множественным потоком данных – ОКМД;

-системы с множественным потоком команд и множественным потоком данных – МКМД;

52

Рассмотрим кратко особенности каждого класса.

Системы ОКОД.

Схематически такую систему можно представить так, как показано на рисунке 2.8. Системы этого класса – обычные однопроцессорные ЭВМ. В таких системах организация параллельной обработки заключается в совмещении во времени различных этапов разных задач, при одновременной обработке их разными устройствами. Например, одновременно работают печатающие устройства по нескольким каналам, вводятся данные с накопителей на магнитных дисках, работает процессор и т.д., и все это делается по различным программам.

Для улучшения производительности применяют:

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

•Конфликты разрешаются так же путем введения приоритетов устройств, которые определяют очередность их обращений к ОЗУ. При возникновении очередей возможны простои оборудования.

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

Если к этому еще добавить использование многомодульных ОЗУ можно добиться существенного увеличения производительности

53

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

• Кроме того, можно сократить время доступа к памяти, если применить способ чередования адресов (расслоение обращений) памяти – один модуль будет иметь четные адреса, другой нечетные и начало цикла памяти смещено на половину цикла.

Системы класса МКОД.

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

Фактический, одиночный поток команд устройством управления разделяется на несколько потоков микрокоманд (микроопераций). Каждая из микроопераций реализуется специализированным, настроенным на выполнение именно данной микрооперации устройством.

Поток данных последовательно проходит через все или часть этих специализированных АЛУ. Именно такие системы называют

54

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

Системы класса ОКМД.

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

55

Системы класса МКМД.

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

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

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

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

56