Жоголев Е.А. Введение в технологию программирования - файл n1.htm

приобрести
Жоголев Е.А. Введение в технологию программирования
скачать (509.8 kb.)
Доступные файлы (150):
n1.htm22kb.29.05.2009 17:09скачать
n2.gif1kb.29.05.2009 17:09скачать
n3.gif1kb.29.05.2009 17:09скачать
n4.gif1kb.29.05.2009 17:09скачать
n5.gif1kb.29.05.2009 17:09скачать
n6.gif1kb.29.05.2009 17:09скачать
n7.gif1kb.29.05.2009 17:09скачать
n8.gif1kb.29.05.2009 17:09скачать
n9.gif1kb.29.05.2009 17:09скачать
n10.gif1kb.29.05.2009 17:09скачать
n11.gif7kb.29.05.2009 17:09скачать
n12.gif1kb.29.05.2009 17:09скачать
n13.gif1kb.29.05.2009 17:09скачать
n14.gif1kb.29.05.2009 17:09скачать
n15.gif1kb.29.05.2009 17:09скачать
n16.png1kb.29.05.2009 17:09скачать
cs_t0000.gif2kb.29.05.2009 17:09скачать
n18.css
n19.gif1kb.29.05.2009 17:09скачать
n20.gif1kb.29.05.2009 17:09скачать
show_ads.js
n22.gif1kb.29.05.2009 17:09скачать
tower_t0.gif1kb.29.05.2009 17:09скачать
n24.htm26kb.29.05.2009 16:05скачать
n25.htm28kb.29.05.2009 16:00скачать
n26.htm20kb.29.05.2009 16:03скачать
n27.htm25kb.29.05.2009 16:05скачать
n28.htm21kb.29.05.2009 16:57скачать
n29.htm15kb.29.05.2009 16:55скачать
n30.htm32kb.29.05.2009 17:12скачать
n31.gif1kb.29.05.2009 17:12скачать
n32.gif1kb.29.05.2009 17:12скачать
n33.gif1kb.29.05.2009 17:12скачать
n34.gif7kb.29.05.2009 17:12скачать
n35.gif1kb.29.05.2009 17:12скачать
n36.gif6kb.29.05.2009 17:12скачать
n37.gif9kb.29.05.2009 17:12скачать
n38.gif8kb.29.05.2009 17:12скачать
n39.gif1kb.29.05.2009 17:12скачать
n40.gif1kb.29.05.2009 17:12скачать
n41.gif1kb.29.05.2009 17:12скачать
n42.gif1kb.29.05.2009 17:12скачать
n43.gif1kb.29.05.2009 17:12скачать
n44.gif1kb.29.05.2009 17:12скачать
n45.gif1kb.29.05.2009 17:12скачать
n46.png1kb.29.05.2009 17:12скачать
cs_t0000.gif2kb.29.05.2009 17:12скачать
n48.css
n49.gif1kb.29.05.2009 17:12скачать
n50.gif1kb.29.05.2009 17:12скачать
show_ads.js
n52.gif1kb.29.05.2009 17:12скачать
tower_t0.gif1kb.29.05.2009 17:12скачать
n54.htm34kb.29.05.2009 16:00скачать
n55.htm26kb.29.05.2009 15:57скачать
n56.htm25kb.29.05.2009 16:03скачать
n57.htm26kb.29.05.2009 16:03скачать
n58.htm24kb.29.05.2009 17:09скачать
n59.gif1kb.29.05.2009 17:08скачать
n60.gif1kb.29.05.2009 17:08скачать
n61.gif1kb.29.05.2009 17:08скачать
n62.gif1kb.29.05.2009 17:08скачать
n63.gif1kb.29.05.2009 17:08скачать
n64.gif1kb.29.05.2009 17:08скачать
n65.gif1kb.29.05.2009 17:08скачать
n66.gif1kb.29.05.2009 17:08скачать
n67.gif1kb.29.05.2009 17:08скачать
n68.gif9kb.29.05.2009 17:08скачать
n69.gif1kb.29.05.2009 17:09скачать
n70.gif1kb.29.05.2009 17:09скачать
n71.gif1kb.29.05.2009 17:09скачать
n72.gif1kb.29.05.2009 17:09скачать
n73.png1kb.29.05.2009 17:08скачать
cs_t0000.gif2kb.29.05.2009 17:08скачать
n75.css
n76.gif1kb.29.05.2009 17:08скачать
n77.gif1kb.29.05.2009 17:08скачать
show_ads.js
n79.gif1kb.29.05.2009 17:09скачать
tower_t0.gif1kb.29.05.2009 17:08скачать
n81.htm26kb.29.05.2009 16:05скачать
n82.htm27kb.29.05.2009 17:10скачать
n83.gif1kb.29.05.2009 17:10скачать
n84.gif1kb.29.05.2009 17:10скачать
n85.gif1kb.29.05.2009 17:10скачать
n86.gif1kb.29.05.2009 17:10скачать
n87.gif1kb.29.05.2009 17:10скачать
n88.gif1kb.29.05.2009 17:10скачать
n89.gif1kb.29.05.2009 17:10скачать
n90.gif1kb.29.05.2009 17:10скачать
n91.gif7kb.29.05.2009 17:10скачать
n92.gif1kb.29.05.2009 17:10скачать
n93.gif1kb.29.05.2009 17:10скачать
n94.gif1kb.29.05.2009 17:10скачать
n95.gif1kb.29.05.2009 17:10скачать
n96.png1kb.29.05.2009 17:10скачать
cs_t0000.gif2kb.29.05.2009 17:10скачать
n98.css
n99.gif1kb.29.05.2009 17:10скачать
n100.gif1kb.29.05.2009 17:10скачать
show_ads.js
n102.gif1kb.29.05.2009 17:10скачать
tower_t0.gif1kb.29.05.2009 17:10скачать
n104.htm34kb.29.05.2009 17:10скачать
n105.gif1kb.29.05.2009 17:10скачать
n106.gif1kb.29.05.2009 17:10скачать
n107.gif1kb.29.05.2009 17:10скачать
n108.gif1kb.29.05.2009 17:10скачать
n109.gif1kb.29.05.2009 17:10скачать
n110.gif1kb.29.05.2009 17:10скачать
n111.gif1kb.29.05.2009 17:10скачать
n112.gif1kb.29.05.2009 17:10скачать
n113.gif7kb.29.05.2009 17:10скачать
n114.gif13kb.29.05.2009 17:10скачать
n115.gif18kb.29.05.2009 17:10скачать
n116.gif1kb.29.05.2009 17:10скачать
n117.gif1kb.29.05.2009 17:10скачать
n118.gif1kb.29.05.2009 17:10скачать
n119.gif1kb.29.05.2009 17:10скачать
n120.png1kb.29.05.2009 17:10скачать
cs_t0000.gif2kb.29.05.2009 17:10скачать
n122.css
n123.gif1kb.29.05.2009 17:10скачать
n124.gif1kb.29.05.2009 17:10скачать
show_ads.js
n126.gif1kb.29.05.2009 17:10скачать
tower_t0.gif1kb.29.05.2009 17:10скачать
n128.htm34kb.29.05.2009 17:11скачать
n129.gif1kb.29.05.2009 17:11скачать
n130.gif4kb.29.05.2009 17:11скачать
n131.gif1kb.29.05.2009 17:11скачать
n132.gif1kb.29.05.2009 17:11скачать
n133.gif1kb.29.05.2009 17:11скачать
n134.gif1kb.29.05.2009 17:11скачать
n135.gif1kb.29.05.2009 17:11скачать
n136.gif1kb.29.05.2009 17:11скачать
n137.gif1kb.29.05.2009 17:11скачать
n138.gif1kb.29.05.2009 17:11скачать
n139.gif1kb.29.05.2009 17:11скачать
n140.gif1kb.29.05.2009 17:11скачать
n141.gif1kb.29.05.2009 17:11скачать
n142.png1kb.29.05.2009 17:11скачать
cs_t0000.gif2kb.29.05.2009 17:11скачать
n144.css
n145.gif1kb.29.05.2009 17:11скачать
n146.gif1kb.29.05.2009 17:11скачать
show_ads.js
n148.gif1kb.29.05.2009 17:11скачать
tower_t0.gif1kb.29.05.2009 17:11скачать
n150.pdf97kb.29.05.2009 17:14скачать

n1.htm

текстовая версия

Замок Дракона

Б   Е   З       Б   А   Ш   Н   И

на главную лекции вмик мгу
Разделяй и властвуй!
Латинское изречение

Лекция 6.
АРХИТЕКТУРА ПРОГРАММНОГО СРЕДСТВА


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

6.1. Понятие архитектуры программного средства.


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

С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация и функциональных спецификаций.

6.2. Основные классы архитектур программных средств.


Различают следующие основные классы архитектур программных средств [6.1]:
  • цельная программа;
  • комплекс автономно выполняемых программ;
  • слоистая программная система;
  • коллектив параллельно выполняемых программ.

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

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

Таким образом, в слоистой программной системе каждый слой
может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обращения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от нижнего слоя верхнему. Недопустимо использование глобальных данных несколькими слоями.
В качестве примера рассмотрим использование такой архитектуры для построения операционной системы. Такую архитектуру применил Дейкстра при построении операционной системы THE [6.2]. Эта операционная система состоит из четырех слоев (см. рис. 6.1). На нулевом слое производится обработка всех прерываний и выделение центрального процессора программам (процессам) в пакетном режиме. Только этот уровень осведомлен о мультипрограммных аспектах системы. На первом слое осуществляется управление страничной организацией памяти. Всем вышестоящим слоям предоставляется виртуальная непрерывная (не страничная) память. На втором слое осуществляется связь с консолью (пультом управления) оператора. Только этот слой знает технические характеристики консоли. На третьем слое осуществляется буферизация входных и выходных потоков данных и реализуются так называемые абстрактные каналы ввода и вывода, так что прикладные программы не знают технических характеристик устройств ввода и вывода.
Прикладные программы
3: Управление входными и выходными потоками данных
2: Обеспечение связи с консолью оператора
1: Управление памятью
0: Диспетчеризация и синхронизация процессов

Компьютер

Рис. 6.1. Архитектура операционной системы THE.
Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько центральных процессоров, а во-вторых, осуществлять между собой динамические (в процессе выполнения) взаимодействия, на базе которых производиться их синхронизация. Обычно взаимодействие между такими процессами производится путем передачи друг другу некоторых сообщений.
Простейшей разновидностью такой архитектуры является конвейер, средства для организации которого имеются в операционной системе UNIX [6.3]. Конвейер представляет собой последовательность программ, в которой стандартный вывод каждой программы, кроме самой последней, связан со стандартным вводом следующей программы этой последовательности (см. рис. 6.2). Конвейер обрабатывает некоторый поток сообщений. Каждое сообщение этого потока поступает на ввод первой программе, которая обработав его передает переработанное сообщение следующей программе, а сама начинает обработку очередного сообщения потока. Таким же образом действует каждая программа конвейера: получив сообщение от предшествующей программы и обработав его, она передает переработанное сообщение следующей программе, а последняя программа конвейера выводит результат работы всего конвейера (результирующее сообщение). Таким образом, в конвейере, состоящим из n программ, может одновременно находиться в обработке до n сообщений. Конечно, в силу того, что разные программы конвейера могут затратить на обработку очередных сообщений разные отрезки времени, необходимо обеспечить каким-либо образом синхронизацию этих процессов (некоторые процессы могут находиться в стадии ожидания либо возможности передать переработанное сообщение, либо возможности получить очередное сообщение).

Рис. 6.2. Конвейер параллельно действующих программ.

В более общем случае коллектив параллельно действующих программ может быть организован в систему с портами сообщений.
Порт сообщений представляет собой программную подсистему, обслуживающую некоторую очередь сообщений: она может принимать на хранение от программы какое-либо сообщение, ставя его в очередь, и может выдавать очередное сообщение другой программе по ее требованию. Сообщение, переданное какой-либо программой некоторому порту, уже не будет принадлежать этой программе (и использовать ее ресурсы), но оно не будет принадлежать и никакой другой программе, пока в порядке очереди не будет передано какой-либо программе по ее запросу. Таким образом, программа, передающая сообщение не будет находиться в стадии ожидания пока программа, принимающая это сообщение, не будет готова его обрабатывать (если только не будет переполнен принимающий порт).
Пример программной системы с портами сообщений приведен на рис. 6.3. Порт U может рассматриваться как порт вводных сообщений для представленного на этом рисунке коллектива параллельно действующих программ, а порт W - как порт выводных сообщений для этого коллектива программ.

Рис. 6.3. Пример программной системы с портами сообщений.

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

6.3. Архитектурные функции.


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

6.4. Контроль архитектуры программных средств.


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

Литература к лекции 6.


6.1. Г. Майерс. Надежность программного обеспечения. - М.: Мир, 1980. - С. 78-91.
6.2. E.W. Dijkstra. The Structure of the THE-Multiprogramming// Communications of the ACM. - 1968, 11(5). - Pp. 341-346.
6.3. М. Кристиан. Введение в операционную систему UNIX. - М.: Фи нансы и статистика, 1985. - С. 46-49.


статистика чуть выше:в начало разделавперед: лекция 7
назад: лекция 4здесь: лекция 6
Copyright © 2001-2004. Эргэл.


Учебный материал
© nashaucheba.ru
При копировании укажите ссылку.
обратиться к администрации