Индустрия программирования

Фонд свободного программного обеспечения и проект GNU

Фонд свободного программного обеспечения (FSF - Free Software Foundation) представляет собой
очень интересное и во многих отношениях исключительное явление в современном мире
программирования. Многим отечественным программистам приходилось иметь дело с
программами из FSF (особенно хорошо известна система программирования GCC), однако
недостаточное количество публикаций на русском языке затрудняет понимание идеологии и целей
FSF, а также усложняет оценку имеющегося задела. Одной из целей доклада является хотя бы
частичное устранение этого пробела.

FSF - это программистская организация, основанная и возглавляемая Ричардом Столлманом
(Richard Stallman). В самой общей постановке задачей FSF является устранение ограничений по
копированию, распространению, изучению и модификации программ для компьютеров. Для
достижения этой общей задачи FSF стимулирует разработку и использование свободного
программного обеспечения, ориентированного на широкий класс применений.

В своем "Манифесте GNU" [1], написанном еще в 1985 г., Р. Столлман в качестве основной идеи,
приведшей к возникновению FSF и проекта GNU, выдвигает свое неприятие права собственности
на программы. Особенности взаимоотношений в сообществе программистов часто ставят людей
перед выбором следования естественному чувству дружбы и взаимопомощи или подчинения
препятствующего этому закону о собственности. При использовании свободного программного
обеспечения необходимость такого обременительного выбора исчезает.

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


целях.

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

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

Более конкретно, FSF ведет разработку программ в рамках проекта GNU (аббревиатура GNU
раскрывается рекурсивно - GNU's Not Unix). Целью проекта GNU является создание полной
интегрированной программной системы, средства которой совместимы с возможностями среды
ОС Unix (как правило, возможности программ GNU шире возможностей аналогов среды Unix).

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

Подобно тому, как права обычных компаний, производящих программное обеспечение,
охраняются их знаком авторских прав (copyright), "свобода" программных систем FSF защищается
"copyleft" - комбинацией copyright и присутствующим во всех текстах FSF документом с
заголовком "GNU General Public License" [2]. В этом документе говорится о правах, которыми
располагает любой текущий владелец данного текста, и о невозможности изъятия этих прав у


любого другого субъекта.

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

Финансовой основой FSF является продажа магнитных лент и компактных дисков с текстами
программ GNU, документации в электронной и бумажной форме, а также спонсорство
коммерческих фирм и частных лиц.

В настоящее время готовы почти все компоненты программного обеспечения проекта GNU. FSF
распространяет много программ, часть которых написана непосредственно программистами FSF,
а часть передана в FSF для свободного распространения другими организациями и лицами.
Коротко охарактеризуем наиболее интересные программные продукты, распространяемые FSF [3].

Emacs - расширяемый, настраиваемый на разные типы терминалов и потребности пользователей
редактор. Расширяемость редактора основана на использовании встроенного в редактор
интерпретатора языка Лисп (диалекта Common Lisp). Одновременно с исходными текстами
редактора распространяются руководство по использованию Emacs и справочное руководство по
программированию на языке Лисп в среде Emacs. Основной версией Emacs, поставляемой и
поддерживаемой в настоящее время FSF, является Emacs V.19. Эта версия редактора сохраняет
свойства всех предыдущих версий, включая возможность использования на самых простых
алфавитно-цифровых терминалах. Однако Emacs V.19 очень хорошо работает на графических X-
терминалах. На самом деле, только после перехода к использованию Emacs на X-терминалах


можно по- настоящему оценить возможности этого редактора.

Некоторое время тому назад существовала непростая проблема локализации Emacs
применительно к особенностям национального языка. Скорее всего, найдутся люди, которые
помнят, сколько хлопот принесла работа по первой русификации Emacs. Несколько лет назад
внезапно активизировавшиеся японцы создали собственную версию редактора Emacs под
названием MULE (MULtilingual Enhancement to GNU Emacs - не подумайте чего плохого). В этой
версии используется расширенная многобайтовая кодировка символов, позволяющая в одном
сеансе редактирования употреблять символы разных алфавитов (в частности, японский,
китайский, арабский, русский, греческий и т.д.). В настоящее время MULE интегрирован в Emacs,
и серьезные проблемы локализации отсутствуют. Видимо, сегодня Emacs является лучшим
текстовым процессором, работающим в среде Unix (в действительности, эта программа
представляет собой гораздо большее, чем простой текстовый процессор).

Bison - замена стандартного генератора синтаксических анализаторов Yacc с некоторыми
расширениями. Руководство также распространяется. Люди, которые использовали Bison при
разработке компиляторов, очень хвалят программу. В последнее время FSF ослабил требования к
использованию Bison, позволив легально его применять при разработке коммерческих продуктов.

Имеются две реализации упрощенного диалекта языка Лисп - Scheme: одна из MIT (написана на
языке Си), вторая из университета г. Yale (написана на Scheme).

Поставляется набор утилит texiinfo, генерирующих печатные и гипертекстовые документы, в виде
которых в основном поставляется документация проекта GNU.

GCC - переносимый оптимизирующий компилятор. Начиная со второй версии компилятор
поддерживает языки Си (ANSI C, традиционный Си, расширенный диалект GNU C), Си++ и
Objective C. Среди оптимизаций, выполняемых GCC, содержится автоматическое распределение
регистров, выявление общих подвыражений, вынесение инвариантных выражений из тела цикла и


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

Доступен целый ряд библиотек функций для языка Си и библиотек классов для Си++ и Objective
C.

Отладчик GDB может быть использован для отладки программ, написанных на языках Си, Си++ и
Фортран.

Для работы с версиями программ в больших программных проектах поддерживаются системы
RCS (Revision Control System) и CVS (Concurrent Version System).

Распространяется громадное количество программ X11, реализация MIT X-Windows (версия 11,
релиз 6). Объем доклада не позволяет остановиться на этом более подробно.

В основном все программы, распространяемые FSF, рассчитаны на работу в среде Unix и
используются с различными вариантами этой системы, но имеются версии некоторых программ
для работы с ОС VMS, Windows NT и даже MS-DOS.

Одним из особенно важным, но еще незавершенным проектом FSF является проект Hurd. Это
свободная реализация UNIX-совместимой операционной системы, основанная на свободно
распространяемом варианте микроядра Mach, разработанного в университете Карнеги-Меллон. В
соответствии с технологией Mach разработан ряд серверов, воспроизводящих базовые функции
ядра ОС UNIX. Интерфейс системных вызовов UNIX воспроизводится с помощью специально
разработанной библиотеки Си-функций. Серверы Hurd и библиотечные функции первоначально
были разработаны на платформе PC 396, но легко переносятся на другие аппаратные платформы.
Основной текущей проблемой является массовый перенос Mach на различные платформы.

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

Основные этапы развития языка

Первые версии языка программирования Си++ (тогда он назывался "Си с классами") были
разработаны в начале 80-х годов Бьярном Страуструпом, сотрудником знаменитой AT&T Bell
Labs, где ранее были разработаны такие шедевры программирования, как операционная система
UNIX и язык программирования Си.

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

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

Как это принято в AT&T, описание нового языка не было опубликовано сразу. Первыми его
пользователями стали сами сотрудники Bell Labs. В 1993 впервые была реализована коммерческий
транслятор, и сам язык был назван "С++", что можно (имея в виду операцию инкрементирования
языка Си) трактовать как увеличенный или расширенный язык Си.

Первым транслятором языка был препроцессор cfront, транслирующий программу на Си++ в
эквивалентную программу на Си. И только в конце 80-х годов были реализованы прямые
трансляторы, не использующие Си в качестве промежуточного языка. Пионером среди таких
трансляторов стал GNU CC.

Если не считать документацию к транслятору cfront, первой книгой с описанием языка стала "The
C++ Programming Language" (Addison-Wesley, 1985), переведенная на русский язык и изданная в
1991 году (Страуструп Б. Язык программирования С++. М.: Радио и Связь, 1991).

С этого момента началось его бурное распространение и создание многочисленных
реализаций.

Модель реализации ООП была частично позаимствована из языка программирования Simula67 и


ориентировалась в основном на возможность эффективной реализации на вычислительных
машинах со стандартной архитектурой. Некоторые возможности языка Simula были отклонены,
так как, по мнению автора Си++, подталкивали разработчика к плохому стилю
программирования. Так, в первых версиях Си++ полностью отсутствовала возможность
динамической идентификации типа объекта (run-time type identification, rtti). Основные концепции
поддержки ООП в Си++ были изложены Страуструпом в статье "What is Object Oriented
Programming".

C 1985 года в язык были введены новые возможности: множественное и виртуальное наследование,
шаблоны функций и классов, обработка исключительных ситуаций. Кардинально изменена
семантика совместного использования оператора new, изменен синтаксис для вложенных
классов.

С момента опубликования и до настоящего момента язык постоянно усовершенствовался и
расширялся. Важным этапом в его развитии стала публикация в 1990 году подробного и
достаточно строгого описания языка [3]. Сокращенно эту книгу часто называют ARM. Фактически
одновременно с этим началась стандартизация языка.

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

В настоящее время одним из

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

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

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

В эру объектно-ориентированных технологий основным инструментальным языком построения


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

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

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


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

В то же время отечественная школа разработчиков компиляторов богата своими традициями.
Сильными школами специалистов в этой области славились: ИПМ, ИТМиВТ, ВЦАН, НФ
ИТМиВТ, ЛГУ, РГУ, МГУ и др. Поэтому возрождение этих традиций, создание
высококачественных отечественных компиляторов, представляется важной стратегической задачей
в области ИТ.

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

Основные задачи проекта можно сформулировать следующим образом:

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


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

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

Исследовать и разработать высокоэффективные алгоритмы и структуры
данных для реализации на их основе объектно-ориентированных шаблонных
библиотек, входящих в стандартное описание языка Си++. Создать полный
набор объектно-ориентированных шаблонных библиотек, входящих в
стандартное описание языка Си++.

Исследовать и разработать методы, высокоэффективные алгоритмы и
структуры данных, вспомогательные инструментальные средства для
реализации на их основе пакета программ для аттестации компиляторов языка
Си++ на их соответствие стандарту. Создать пакет программ для аттестации
компиляторов языка Си++ на их соответствие стандарту.
В настоящее время в НИВЦ МГУ завершается реализация действующего прототипа компилятора
языка Си++ для операционных сред SunOS и Solaris. Входной язык компилятора соответствует
последней к настоящему времени версии проекта стандарта от 28 мая 1996 г. Благодаря
оригинальным структурным решениям и алгоритмам созданный компилятор обладает
производственными характеристиками, сравнимыми с имеющимися на этой платформе
зарубежными компиляторами.

Кроме этого, разворачивается работа по реализации некоторых компонент Стандартной
Библиотеки Си++. Предполагается переносимость реализации

Наконец, проведена разработка первой версии пакета программ для аттестации компилятора на
соответствие исходному описанию.Реализация пакета основывалась на оригинальном подходе и
методах, разработанных сотрудниками НИВЦ МГУ, и подтвердила практичность предложенных
методов аттестации компиляторов. Созданная тестовая система обеспечила достаточно полное
покрытие языкового многообразия и позволила как протестировать разрабатываемый
компилятор, так и выявить многочисленные ошибки в существующих компиляторах.

Другие наиболее распространенные продукты Public Domain

Наверное, самым популярным на сегодня программным продуктом Public Domain является UNIX-
совместимая ОС Linux, созданная молодым финским программистом Линусом Торвалдсом и
поддерживаемая с помощью Internet тысячами энтузиастов. ОС Linux основана на традиционных
принципах построения ядра ОС UNIX, что не помешало энтузиастам перенести ее на несколько
популярных аппаратных платформ.

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

Альтернативой Linux является ОС Free BSD, разработанная и распространяемая университетом
Беркли. Это одна из ветвей BSD UNIX, проекта, в течение многих лет разрабатываемого в
университете Беркли. Free BSD - это эффективная и экономичная операционная система,
единственным недостатком которой можно считать ее абсолютную ориентацию на Intel-
платформы. Я знаю многих людей, которые предпочитают использовать дома Free BSD, а не
Linux.

В том же университете Беркли разработан замечательный пакет Tcl/Tk - средство для разработки
графических пользовательских интерфейсов. Это свободно распространяемый продукт, прекрасно
документированный и очень легко осваиваемый. Известны многие реальные проекты,
выполненные с использованием Tcl/Tk, например, основанный на графическом интерфейсе пакет
администрирования Linux.

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

[]
[]
[]

История стандартизации

Объединенный ANSI-ISO (ANSI X3J16; ISO WG21/N0836) комитет начал функционировать в
конце 1989 года. Целью его работы является создание единого стандарта для языка Си++ и его
библиотечных средств. За основу проекта стандарта было взято описание языка, данное в ARM, и
книга [4].

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

Работа по стандартизации Си++ осложнялась тем, что язык долгое время был открыт для
расширений. Сами формулировки правил ARM были недостаточно строги и часто требовали
уточнения. Си++ стал довольно громоздким языком (сопоставимым разве что с языком Ada), и ни
один человек сейчас не в состоянии точно помнить все его детали и тонкости.

С момента начала стандартизации несколько изменилась и сама идеология Си++. Изначально
автор отвергал возможность использования в языке средств динамического определения типов
(rtti), однако в текущем проекте стандарта такие средства имеются. Аналогично, в Си++,
описанном в ARM, есть довольно жесткие ограничения на возможность определения виртуальных
функций, которые сейчас ослаблены. Характерно, что некоторые изменения, требующие
пересмотра самой идеологии языка, вносились самим Страуструпом [11]

Изначально планировалось, что окончательная редакция проекта стандарта будет опубликована в
1994 году. Эти сроки были безнадежно провалены. Можно сказать, что последние 3 года процесс
стандартизации постоянно находится в состоянии "2 года до завершения". Так, согласно текущему
расписанию международный стандарт Си++ должен быть опубликован в конце 1998 года, во что
авторы статьи не верят.
Даже теперешние, на редкость подробные и громоздкие формулировки
семантических правил и ограничений языка явно не дотягивают до математической строгости и
оставляют простор для различных трактований.

В ранних версиях проекта стандарта не было раздела, описывающего стандартные библиотеки. Не
было описаний библиотеки и в ARM. В то же время реализация библиотеки потокового
ввода/вывода, предложенная Andrew Koenig, была повторена в нескольких реализациях и стала
стандартом "де-факто". В 1993-1994 годах в проекте стандарта было введено около семи новых
разделов для описания библиотеки.

Принципиально важным событием в истории развития стандарта стандартной библиотеки стало
включение библиотеки STL (Standard Template Library) разработанной нашим бывшим
соотечественником, сотрудником Hewllet-Packard Александром Степановым. В своей статье об
истории STL он упоминает, что изначально стремился использовать в Си++ только возможности
шаблонов, аналогичные родовым (generic) пакетам и процедурам языка Ada, но после обсуждений
со Страуструпом существующих возможностей Си++ изменил свое мнение. Комитет по
стандартизации пошел навстречу этим двум гуру, вплоть до того, что в семантику шаблонов были
внесены изменения. Этим был создан интересный прецедент в истории языков программирования:
не библиотека написана для языка, а сам язык претерпел изменения под влиянием библиотеки,
причем разработанной не автором языка.

Согласно расписанию работы комитета по стандартизации, проект стандарта принятый в апреле
1995 года, был предложен для публичного обсуждения и сделан доступен пользователям Internet.
Утверждается, что с этого момента никаких серьезных изменений в текст стандарта вноситься не
будет. Предполагалось, что в сентябре 1996 года новая редакция проекта стандарта будет вынесена
на публичное обсуждение, но не так давно этот этап был перенесен на конец года.

Компилятор Си++

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

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

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

В качестве примера радикального изменения языка можно привести главу 14 проекта стандарта
(Шаблоны). Первые версии определяли сравнительно простые средства параметризации периода
компиляции (правда, описание содержало большое количество неясных мест), которые допускали
простую модель реализации, основанную на "отложенной компиляции". Однако, в 1995 году
указанная глава подверглась кардинальной ревизии (ее объем увеличился в несколько раз) с
существенным расширением возможностей и усложнением синтаксиса и семантики. В основном это
было обусловлено стремлением поддержать возможности, заложенные в Стандартной Библиотеке
Шаблонов (Standard Template Library) Александра Степанова , которая в качестве составной
части вошла в проект стандарта. "Новые шаблоны" не допускали отложенную компиляцию, явно
требуя полного синтаксического и семантического контроля непосредственно в месте описания
шаблонов. Это привело не только к перепроектированию соответствующих компонент
компилятора, но затронуло очень многие, формально не связанные с шаблонами, его модули.


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

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

Препроцессор Си++;

Компилятор переднего плана Си++ (front-end compiler);

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

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

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

Компилятор переднего плана. Эта компонента является центральной частью всего компилятора
Си++. Она воспринимает на входе текст программы на Си++ (в терминах стандарта - translation


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

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

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

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


выше, привела к существенному (около 2- х раз) сокращению объема синтаксиса по сравнению с
аналогичным синтаксисом, используемым в свободно распространяемом компиляторе GNU
C++.

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

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

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

Генератор кода. В настоящее время в компиляторе используется фирменный генератор объектного
кода для платформ Sun и Sparc, полученный от компании-разработчика формата внутреннего
представления. Напомним, что генератор, как и другие компоненты компилятора, представляет


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

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

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

При тестировании компилятора переднего плана использовались средства аттестации,
создаваемые в рамках всего проекта (см. разд. 4). К началу октября 1996 г. компилятор успешно
обрабатывал около 97% тестов (используемый тестовый набор включает более 6000 тестов без
учета тестов на шаблонные конструкции). Проводились попытки сравнить степень соответствия
стандарту разрабатываемого компилятора с компиляторами известных фирм-производителей
инструментальных средств. Так, компилятор Watcom C++ версии 10.0 показал результат около
93%.

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

Современное состояние языка

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

Ведены новые ключевые слова-синонимы для операций (and, and_eq, bitand, bitor, compl,
not, or, or_eq, xor, xor-equ).

В языке появился булевский тип данных bool и литералы этого типа true и false.

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

Новое ключевое слово explicit позволяет запретить нежелательное использование
конструкторов как функций преобразования типов.

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

Добавлен механизм явного использования rtti (включающий операцию с ключевым словом
typeid и класс type_info стандартной библиотеки).

Добавлены новые и скорректированы старые способы явного преобразования типов
(static_cast, dynamic_cast, const_cast и reinterpret_cast).

Добавлена новая операция new[], парная к операции delete[]; для операций new и delete
изменена семантика выражения размещения с целью более безопасной обработки исключительных
ситуаций в конструкторах. Стандартная операция new теперь не может вернуть значение 0 в случае
нехватки памяти или ошибки, а генерирует исключительную ситуацию. Старый вариант,
возвращающий 0, доступен программисту только c явным указанием.

Объявления переменных теперь возможны не только в заголовке for-цикла, но и в операторах
if, while, do-while, switch.

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

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

Допускаются шаблонные функции-члены нешаблонных классов, вложенные шаблонные
классы и шаблоны - параметры шаблонов.

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

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

Ослаблено ограничение на тип, возвращаемый операцией ->. Теперь это может быть
практически произвольный тип.

Добавлено (на редкость бессмысленное) ключевое слово mutable, позволяющее допускать
изменение членов объекта константного класса.
Более подробно некоторые из этих изменений рассмотрены в статье [6].

Стандартная библиотека Си++: принципы построения

Стандартная Библиотека языка Си++ (The Standard C++ Library) представляет собой весьма
значительную (как по объему, так и по "идеологической" насыщенности) часть готовящегося
стандарта языка Си++. Описание Библиотеки (главы 17-27) в совокупности составляет более
половины общего объема Предварительного Стандарта . Помимо внушительного размера,
предлагаемый стандартный комплекс библиотечных ресурсов языка Си++ воплощает большое
количество важных принципов и подходов, отражающих современное состояние программистской
теории и практики.

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

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

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

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

Наконец, третья важная черта Библиотеки - использование механизма исключительных ситуаций
(exceptions). Практически все возможные "нештатные" эффекты в процессе выполнения
библиотечных функций специфицированы в виде исключительных ситуаций; в библиотеке
предусмотрена иерархия стандартных классов, предназначенных именно передачи значений при
возбуждении исключительных ситуаций.

Однако наиболее существенной идеологической концепцией, на основе которой строится
Стандартная Библиотека, является технология "generic programming" (обобщенного
программирования), впервые примененная для Си++ А.Степановым при разработке его Standard
Template Library (и вошедшей в качестве составной части в Стандартную Библиотеку). Как
результат, важнейшей особенностью Стандартной Библиотеки Си++ становится тенденция к
максимальному обобщению структур и алгоритмов при одновременном сохранении их
эффективности. Практически явное выделение понятийного ядра библиотеки позволило упростить
общую схему ее построения. Кроме того, произошел отказ от попыток создания замкнутой
системы классов и функций, предоставляющей пользователю фиксированный сервис. Наоборот,
основное внимание в библиотеке уделяется универсальным шаблонным средствам порождения
требуемого пользователю контекстно-ориентированного кода. С точки зрения классического
понимания слова "библиотека" С++ Standard Library скорее является средством быстрой
разработки контекстно-ориентированных библиотек, предоставляя программисту совокупность
понятий, в терминах которых он может проектировать собственные системы, и набор типовых
решений с использованием этих понятий.

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


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

Практически каждая компонента Библиотеки существенно использует возможности,
предоставляемые другими компонентами, за счет чего достигается максимальная гибкость,
общность и эффективность. В качестве примера можно привести следующую схему, отражающую
взаимодействие компонент библиотеки, используемых при реализации ввода/вывода. Здесь связь
вида Компонента1-->Компонента2 отражает тот факт, что для построения второй компоненты
привлекаются понятия из первой компоненты.

alt="Структура">

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

Заметим, что идея создания библиотек повторно используемых программных компонент реально
не столь нова, как кажется на первый взгляд. Еще в 1976 году МакИлрой в своей статье (McIlroy
"Mass-Produced Software Components") аргументировал необходимость повторного использования
программного обеспечения, в том числе стандартизации и абстрактизации наиболее часто
используемых алгоритмов и структур данных, и, по всей видимости, единственным ограничением к
созданию подобного рода библиотек являлось отсутствие развитых средств абстрактизации у
большинства распространенных к тому времени языков программирования.

Подходя к проблеме эффективности библиотеки заметим, что абстрактизация компонент


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

#include
#include
class IntGreater {
public:
bool operator()( int x, int y) const { return x>y; }
};
int main()
{
int x[1024];
............ // Инициализация
sort(&x[0],&x[1024]); // Обычное упорядочивание
sort(&x[0],&x[1024],IntGreater); // Упорядочивание по убыванию
}
При этом эффективность по скорости выполнения будет такой же, как и при написании
сортировки целых вручную, а реально может оказаться и выше за счет удачного выбора алгоритма
сортировки. Примеры использования средств STL можно найти в .

Стандартная Библиотека Си++ предоставляет:

Расширяемый набор классов и определений, необходимых для
поддержки понятий самого языка Си++ (Language Support Library).

Классы поддержки диагностики пользовательских приложений (Diagnostics
Library);

Утилиты общего назначения (General Utilities);

Контейнеры (Containers) и итераторы (Iterators);

Обобщенные алгоритмы (Algorithms);

Средства локализации программ (Locales);

Классы и функции для математических вычислений (Numeric Library);

Средства работы со строками (Strings Library);

Ввод/вывод (Input/Output Library).

Перспективы

Очень хочется, чтобы стандарт языка был наконец принят. Это может подстегнуть разработчиков
систем программирования для Си++ на максимально полную поддержку новых возможностей
языка, которые в настоящий момент не реализованы. Хочется, чтобы язык был наконец
зафиксирован, и в него не добавлялись новые средства, противоречащие старой идеологии.

И, наконец, несколько замечаний по поводу продолжительных дискуссий на темы вроде "Что
лучше - Си или Си++" или "Является ли Си++ языком ООП".

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

Бесполезно критиковать Си++ за недостаточно неполную или "неправильную" поддержку ООП.
Си++ вполне укладывается в формулировку парадигмы ООП, данную Страуструпом. Си++ не
является единственным языком ООП и имеет право на свои недостатки и своеобразие.

Сейчас ООП явно поддерживается в нескольких языках программирования, во многих не так как
Си++, и разработчик имеет возможность выбора (так, превосходно спроектированный объектно-
ориентированный язык Ada95 уже стандартизован). Постоянные упреки в адрес Си++ за
"неправильное" понимание ООП кажутся абсолютно несуразными. Даже такие столпы ООП, как
Грэди Буч [9] и Роберт Мартин [10] признают, что Си++ является вполне подходящим и неплохим
инструментом ООП.

Благодаря своим корням Си++ был быстро воспринят разработчиками, уже имеющими опыт
программирования на Си, но не избалованными дорогими и малоэффективными языками
"чистого" объектно-ориентированного программирования.

Противопоставлять Си и Си++ тоже не стоит. Один из них ортогонально расширяет другой по
нескольким направлениям, которые могут быть использованы независимо.

Си++ допускает использование в нескольких вариантах. Во-первых, он содержит язык
программирования Си, точнее, его стандартизованный диалект ANSI C почти целиком. При этом
Си++ обладает более мощными и строгими правилами проверки типов. Программист волен
использовать лишь часть возможностей Си++, не сталкиваясь при этом с неприятностями,
связанными с неполным знанием языка (то есть воспринимать Си++ как "улучшенный" Си).
Можно использовать только механизм классов и наследования, не пользуясь возможностями
обобщенного (generic) программирования, основанного на шаблонах. Наконец, многим
разработчикам приглянулась возможность обработки исключительных ситуаций, не зависящая от
других механизмов языка. Взятые вместе, эти возможности предлагают разработчику
современный, достаточно гибкий и мощный язык программирования высокого уровня с
поддержкой ООП.

Думаем, Си не нуждается в защите. По крайней мере, последние 20 лет показали, что он является
исключительно гибким и продуктивным языком, годным как для системного программирования,
так и для создания приложений широкого спектра. Почему Си имеет такой успех ? Прежде всего
потому, что вместо создания "чистого" языка Керниган и Ричи создали язык, который можно
использовать. И в этом они преуспели.

Почему успешен Си++ ? По той же причине.

Дополнительная информация по языку Си++ см.:

Тестовый пакет

4.1. Основные принципы аттестации

Исходя из общих критериев качества и требований к пакетам тестов были выбраны следующие
принципы разработки пакета аттестационных тестов для проверки компиляторов Си++ на
соответствие стандарту:

Набор аттестационных тестов должен покрывать весь стандарт языка
C++.

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

Каждая тестовая программа необходима для проверки соответствия между
реализацией некоторой языковой конструкции и ее описанием в стандарте
языка C++.
4.2. Пакет тестов

Общая структура

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

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

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

Группы тестов, соответствующие частям стандарта языка С++

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

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

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

Спецификации тестов: создание и реализация

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

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

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

Создание спецификаций А-тестов: атрибуты тестов и таблицы решений

Спецификации для А-тестов выражены в виде таблиц решений для наборов тестовых
атрибутов.

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


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

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

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

Несмотря на эти замечания, разработка спецификаций для А-тестов включает в себя следующие
четыре шага:

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

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

значение присутствует в стандарте,

значение определяет отдельную тестируемую сущность.

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

существует возможность определения наличия или отсутствие данного
эффекта,

данный эффект должен быть как можно проще.

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


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

Спецификации для Б-тестов и методы их создания отличаются от соответствующих методов для А-
тестов. Каждая такая спецификация состоит из двух частей.

Первая часть, называемая "Б-значения", состоит из набора ошибочных значений тестовых
атрибутов, определенных в соответствующей спецификации А-тестов. Каждое из ошибочных
значений должно удовлетворять следующим свойствам:

значение присутствует в стандарте языка С++,

значение определять отдельную тестируемую сущность.
Вторая часть называется "Ограничения" и состоит из формулировок ограничений, накладываемых
на программы языка С++ и явно выделенных в соответствующей части стандарта или логически
следующих из ее текста. Для некоторых ограничений явно указывается пути их нарушения.

Каждое ограничение, накладываемое на программы языка С++, может быть отражено, как в части
"Б-значения", так и в части "Ограничения", но не в обеих сразу.

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

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

Гипотезы

Так как стандарт языка C++ является неформализованным, оценка значимости тестовых
атрибутов, их значений и комбинаций этих значений также была неформализованной. Главной
целью этой оценки является систематическое уменьшение количества тестов.

С другой стороны, принципы и результаты оценки важности атрибутов должны быть хорошо


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

Для того, чтобы объяснить способ, которым оценивалась величина важности значений атрибутов,
необходимо явно сформулировать гипотезы о тестируемых свойствах реализации языка С++. Одна
из таких гипотез, называемая "Гипотеза об относительной корректности реализации", относится
ко всему пакету тестов. Эта гипотеза, называемая в дальнейшем ГОКР, формулируется так: "Когда
проверяется взаимодействие между различными языковыми конструкциями, предполагается, что
каждая из этих конструкций реализована правильно. Отсюда вытекает, что конкретное
представление данных конструкций не важно".

Предполагалось, что ГОКР будет использоваться только для ограничения количества тестов в
потенциально-бесконечном наборе тестов, а не для ограничения их сложности. Другими словами,
конкретный выбор языковых конструкций производился в соответствии с ГОКР, но был
тривиальным.

Поддержка версий

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

Строится и документиpуется список различий между стандартами C и C ++. Каждое
различие снабжается соответствующей ссылкой на стандарт языка C++.

Для каждого различия выполняется следующая последовательность шагов:

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

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

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

Если в течение выполнения шага 2. найдены новые различия между C и C++, они
объединяются в отдельный список различий. Этот список может быть добавлен к первоначальному
списку различий и тогда процесс создания набора тестов должен быть повторно начат с шага 2.,
или он может сохраняться как отдельный список, который нужно использовать при создании
следующей версии набора тестов. Выбор между этими альтернативами зависит от большого
количества неформальных причин, включая доступные ресурсы и значимости данных различий.

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

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

Классы тестов

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

А-тесты:

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

Б-тесты:

Тест относится к классу Б-тестов если он является неправильной (нарушающей требования
стандарта языка C++) программой.


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

Полученные тесты являются компиляционными тестами, содержащими нарушения стандарта,
проверяемые на этапе компиляции. Это ограничение основано на следующих допущениях:

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

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

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

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

Основные требования, предъявляемые к тестам, следующие:

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

На этапе проектирования пакета тестов трудно оценить человеческие и


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

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

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

Тесты должны быть просмотрены и отлажены для того, чтобы устранить ошибки и установить
соответствие между тестами и целями тестирования.
Специальные Требования к А-тестам

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

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

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

Специальные Требования к Б-тестам

Каждый Б-тест должен содержать ровно одну ошибку, соответствующую спецификации
теста.

Все Б-тесты в пакете тестов являются тестами процесса компиляции. (То есть, тест прошел если
его компиляция не удалась, и наоборот) Это предположение не полностью правильно, но оно
основано на общепринятой модели компилятора для языка фон Неймана и позволяет
организовывать естественную и удобную среду тестирования для B-tests.

AIM

AIM Technology

Генератор тестовых пакетов

Нагрузочные смеси (стандартные/заказные)

Сертифицированный отчет (для AIM Performance
Report II)

Стоимость системы

Детали конфигурации системы

Результаты измерений на трех тестовых пакетах:

многопользовательский тестовый пакет AIM (набор
III)

тестовый пакет утилит AIM (Milestone)

тестовый пакет для оценки различных систем (набор II)

Критерии:

Пиковая производительность (рейтинг VAX 11/780 = 1 AIM)

Максимальная пользовательская нагрузка (емкость системы)

Индекс производительности утилит (количество пользовательских
заданий пакета Milestone, выполненных за 1 час)

Пропускная способность системы (количество выполненных заданий
в минуту)

Архитектура машин с очень длинным командным словом

Пример с 7-кратным разворачиванием цикла:

Обращение к памяти 1	Обращение к памяти 2	Операция ПТ 1	Операция ПТ 2	Целочисленная операция/переход
LD F0,0(R1) LD F10,-16(R1) LD F18,-32(R1) LD F26,-48(R1) SD 0(R1),F4 SD -16(R1),F12 SD -32(R1),F20 SD 0(R1),F28	LD F6,-8(R1) LD F14,-24(R1) LD F22,-40(R1) SD -8(R1),F8 SD -24(R1),F16 SD -40(R1),F24	ADDD F4,F0,F2 ADDD F12,F10,F2 ADDD F20,F18,F2 ADDD F28,F26,F2	ADDD F8,F6,F2 ADDD F16,F14,F2 ADDD F24,F22,F2	SUBI R1,R1,#48 BNEZ R1,Loop

Скорость работы цикла: 1.28 такта на элемент

Архитектура MIPS

MIPS - 1986 г.

R2000/R3000: Silicon Graphics, Digital, Siemens Nixdorf

R3000/R3010 - 33/40 МГц, 20 SPECint 92, 23 SPECfp 92

R4000/R4400 (64-битовая архитектура)

R4000 50/100 МГц, 58 SPECint 92, 61 SPECfp 92

R4400 75/150 МГц, 94 SPECint 92, 105 SPECfp 92

R10000: 200 МГц, 800 MIPS4 команды за такт,Обмен данными - 3.2 Гбайт/с
Архитектура Alpha (64 бит)

DECchip 21064 - до 200 МГц

DECchip 21064А, 1993 г., 275 МГц

DECchip 21066, 166 МГц

DECchip 21068, 66 МГц, 8 Вт

DECchip 21066А, 100, 233 МГц

DECchip 21164:

1994 г.

300 МГц,

330 SPECint 92, 500 SPECfp 92

0,5 микрон КМОП

9,3 млн. транзисторов

POWER - 33, 41.6, 45, 50, 62.5 МГц - 134.6 SPECfp
92

POWER 2 - 66.5, 71.5 МГц, 65 Вт

23 млн. транзисторов

0.45 микрон

1217 кв. миллиметров

131 SPECint 92, 247 SPECfp 92

Состав многокристального набора:

Блок кэш-памяти команд (ICU) - 32 Кбайт, имеет
два порта с 128-битовыми шинами;

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

Блок устройств плавающей точки (FPU) - содержит два конвейера
для выполнения операций с плавающей точкой двойной точности, а
также 54 64-битовых регистра плавающей точки;

Четыре блока кэш-памяти данных - максимальный объем кэш-памяти
первого уровня составляет 256 Кбайт. Каждый блок имеет два порта.
Устройство реализует также ряд функций обнаружения и коррекции
ошибок при взаимодействии с системой памяти;

Блок управления памятью (MMU).

Эволюция в направлении Power PC:

упрощение архитектуры с целью ее приспособления
ее для реализации дешевых однокристальных процессоров;

устранение команд, которые могут стать препятствием
повышения тактовой частоты;

устранение архитектурных препятствий суперскалярной
обработке и внеочередному выполнению команд;

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

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

ясное определение линии раздела между "архитектурой"
и "реализацией";

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

Микропроцессоры Power PC:

Power PC 601

Power PC 603

Power PC 604

Power PC 620, 133 МГц, 225 SPECint92, 300 SPECfp92

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

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

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

Взаимодействия удаленный пользователь - WWW сервер Alibaba;

Взаимодействие обработчик, связанный с HTML документом - серверное приложение;

Серверное приложение - сервер СУБД.
Шлюз к базе данных состоит из двух частей: резидентной (серверной) и вызываемой WWW
сервером (клиентской).

Клиентская часть, указанная в HTML документе, передаваемом удаленному пользователю,
запускается при помощи вызова WinExec() WWW сервером Alibaba. Ей передаются данные,
введенные пользователем посредством диалогов в HTML документ, которые клиентское
приложение передает серверному. После выполнения серверным приложением SQL запроса,
клиентское приложение получает результаты от серверного приложения, производит их
декодирование и формирует на их основе HTML документ, направляемый WWW серверу для
последующей передачи его удаленному клиенту.

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

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

Архитектурные спецификации

Имеюся следующие основные эталонные модели:

Эталонная модель взаимосвязи открытых систем
(Reference Model for Open Sysnems Interconnection - RM-OSI); -
ITU-T X.200 (1994); ISO/IEC 7498-1,2,3,4:1994

Руководство по окружению открытых систем POSIX
Portable Operaring System Interface for Computer Environments)
- ISO/IEC DTR 14252;

Эталонная модель для открытой распределенной
обработки
(RM-ODR) - ITU-T Rec. 902 ISO/IEC 10746-2:1995;

Эталонная модель управления данными (Reference
Model for Data Management - RMDF) - DIS 9075:1992 ;

Эталонная модель компьютерной графики (Reference
Model of Computer Graphics - RM CG);

Эталонная модель программной инженерии (ISO 9000
- ISO 9004, ISO8402:1988);

Эталонная модель текстовых и офисных систем (ISO/IEC
TROTSM-1), в частности, общая (general) модель распределенных
офисных систем (ISO/IEC 10031:1991).

Разрабатываются и близки к опубликованию:

Методы аттестации и аттестационное тестирование
(conformance and conformance test methods);

основы общей безопасности (generic security frameworks);

качества OSI-сервиса (Quality of Service for
OSI).

Архитектуры и технологии разработки интероперабельных систем

Л.Калиниченко, Институт проблем информатики РАН,

E-mail:

Автоматическая генерация С++ кода.

Rational Rose/C++ включает средства автоматической
генерации кодов программ на языке С++. Используя информацию, содержащуюся
в модели проекта, генератор кодов формирует файлы заголовков и
файлы реализаций классов.

Создаваемая структура программы может быть уточнена путем прямого
программирования на языке С++. При повторной генерации внесенные
изменения не теряются

Стиль структуры программы в коде С++ формируется настройкой свойств
(properties) проекта.

Ошибки, обнаруженные генератором кодов С++, представляются в специальном
Log файле.

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

Rational Rose/C++ генерирует С++ код стандарта ANSI.
Базируясь на выбранных свойствах генерации, Rational Rose генерирует
следующие элементы кода:

Для каждого модуля:

Заголовочный файл и файл реализации для модуля.

#include директивы, явно или неявно определенные
в моделе.

Для каждого класса:

Определение класса.

Объявление атрибутов, отношений включения и ассоциативных
отношений.

Get и Set функции для доступа к атрибутам.

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

Объявления для операций, определенных пользователем.

Все поля документирования из спецификаций диаграмм
переносятся в код как комментарии.

Автоматическое преобразование нотаций

Ассоциативные связи позволяют документировать проектные
решения

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


Категории классов образуют
иерархию, в которой классы являются терминальными узлами

Базовые спецификации

Базовые функции ОС; определяются
стандартами по окружению открытых систем POSIX (Portable Operaring
System Interface for Computer Environments) - ISO/IEC 9945:1990.

Функции управления базами данных;
включают язык баз данных SQL (Structured Query Language), информационную
справочную систему (Information Resource Dictionary System - IRDS),
протокол распределенных операций RDA (Remote Data base Access).

Функции пользовательского интерфейса;
включают следующие ИТ: MOTIF из OSF для графического пользовательского
интерфейса (GUI); система X Windows, охватывающая рпоцедуры GUI
и телекоммуникации; стандарты для виртуального терминала (Virtual
Terminal - VT), включая Telenet, определяющую процедуры для работы
VT в символьном режиме через транпортную службу TCP/IP; cтандарты
машинной графики GKS (Grafical Kernel System - ISO/IEC 7942),
PHIGS (Programmers Hierarchical Interactive Graphics System, а
также CGI (Computer Graphics Interface).

Функции взаимосвязи открытых систем,
включая спецификации сервиса и протоколов, разработанные в соответствии
с моделью OSI (рекомендации серии X 200); стандарта локальных
сетей (IEEE 802); спецификации сети Internet.

Функции распределенной обработки,
включая базовые спецификации OSI (Remote Procedure Call - RPC;
Commitment, Concurrency and Recovery - CCR; Distributed Transaction
Processing - TP; File Transfer, Access and Management (FTAM),
OSI Management, а также API для доступа к сервису Object Request
Broker (ORB) в архитектуре CORBA, API, определяющий базовые возможности
такого сервиса (Commom Object Services - COS 1), язык спецификации
интерфейсов объектов IDL (Interface Definition Language) и его
проекции на ООП.

Распределенные приложения,
включая, спецификации специальных сервисных элементов прикладного
уровня модели OSI, стандартов Internet, OMG, X/Open. В частности,
к ним относятся: система обработки сообщений MHS (Message Handling
System - X.400), служба справочника (The Directory - X.500) и

др.

Cтруктуры данных и документов,
в том, числе средства языка ASN.1 (Abstract Syntax Notation One
- ISO/IEC 8824:1990), предназначенного для спецификации прикладных
структур данных, т.е. абстрактного синтаксиса прикладных объектов;
спецификация структур учрежденческих документов (Office Document
Architecture (ODA) - T.411-T.418, T.421, T.502, T.505, T.506;
структура документов для производства - Standard Generalized Markup
Language (SGML - ISO/IEC 8876:1986); форматы метафайла для представления
графической информации: Computer Graphics Metafile (CGM); стандарт
на сообщения и элементы данных для электронного обмена данными
в управлении, коммерции и торговле (стандарт EDIFACT - Electronic
Data Interchange for Administration, Commence and Trade); языки
описания документов гипермалтимедиа: HyTime (ISO/IEC 10744:1992),
SMDL (Standard Music Description Language - ISO/IEC 1074:1992),
SMSL (Standard Multimedia/Hypermedia Scripting Language - ISO/SC1/WG8:1993),
SPDS (Standard Page Description Language - ISO/IEC 10180:1994),
DSSSL (Document Style Semantics and Specification Language - ISO/IEC
10179), HTML (HyperText Markup Language) и др.

Borland Delphi как инструмент корпоративного разработчика

С.Орлик, Borland
Может быть немало споров - они идут постоянно - по
поводу
механизма эволюции, но никто не оспаривает самого факта.
Айзек Азимов
"В
начале"
Говоря о том или ином средстве разработки приложений всегда хочется понять какие
тенденции приводят к его появлению. Borland Delphi не является исключением из правил. Итак,
что же мы имели к середине 90-х?

Одно направление - объектно-ориентированный подход, хорошо структурирующий
задачу, как таковую, так и ее решение в виде прикладной системы.

Другое направление, возникшее во многом благодаря объектной ориентации, - визуальные
средства быстрой разработки приложений (RAD - Rapid Application Development),
основанные на компонентной архитектуре.

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

Четвертая тенденция - возможность работы с базами данных универсальными
(единообразными) методами. Если мы попытаемся оценить процент систем, которые так или
иначе требуют обработки структурированной информации (как для внутрикорпоративного
использования, так и для коммерческого или иного распространения), то окажется, что цифра 60-
70% может представлять лишь нижнюю границу. Важным свойством средств обеспечения доступа
к базам данных является их масштабируемость, как возможность не только
количественного, но и качественного роста системы. Например, обеспечение перехода от
локальных ,в том числе, файл-серверных данных к архитектуре клиент-сервер или тем более к
многоуровневой N-tier схеме.

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

Быстрая и надежная разработка приложений с использованием PowerBuilder

А.Чибисов, фирма Метатехнология

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

Цели OSE-профилей

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

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

переносимость данных

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

интероперабельность управления и безопасности

переносимость пользователей

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

легкая настраиваемость на новые технологии информационных
систем

масштабируемость прикладных платформ

масштабируемость распределенных систем

прозрачность реализаций

поддержка пользовательских требований

CPI-конвейера R4000 на тестах SPEC

Тест	CPI - конвейера	Приостановки по загрузке	Приостановки по переходам	Приостановки по результатам операции ПТ	Приостановки по структурным конфликтам ПТ
eqntott	1.88	0.27	0.61	0.00	0.00
espresso	1.42	0.07	0.35	0.00	0.00
gcc	1.56	0.13	0.43	0.00	0.00
li	1.64	0.18	0.46	0.00	0.00
doduc	2.84	0.01	0.22	1.39	0.22
nasa7	1.83	0.00	0.08	0.65	0.10
ora	4.30	0.00	0.19	3.69	0.42
spice2g6	1.91	0.30	0.29	0.26	0.06
su2cor	2.19	0.02	0.07	0.84	0.26
tomcatv	1.90	0.00	0.05	0.60	0.25
Mean	2.15	0.10	0.27	0.64	0.13

Диаграмма процессов

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

Диаграмма сценариев

Диаграммы сценариев - динамический взгляд на модель.

Диаграммы сценариев показывают основные объекты проекта и взаимодействия
между ними.

Имеется возможность задать последовательность обращений объектов
друг к другу.

Два типа сценарных диаграмм:

Диаграммы сценариев объектов

Диаграммы сценариев сообщений

Система включает средства автоматического взаимного
преобразования диаграмм сценариев.

Диаграмма состояний

Для каждого класса может быть создана диаграмма состояний.

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

Диаграммы классов

Отображают логику построения прикладной системы.

На них отображают классы, категории классов и отношения между
ними.

Возможность отражения параметризованых классов.

Допускаются разнообразные отношения: ассоциации, включения, использования,
наследования.

Имеются простые и удобные средства просмотра иерархий диаграмм
классов.

Для каждого конкретного отношения можно задать имя
и основные его характеристики

Все диаграммы сопровождаются подробными спецификациями.

Диаграммы модулей

Диаграммы модулей - физическая модель системы.

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

Диаграммы модулей образуют иерархию.

Для каждого модуля можно отдельно показать на диаграмме его файл-заголовок
и файл реализации.

Диаграммы сценариев объектов

Диаграммы сценариев сообщений могут сопровождаться
структурированным текстом.

Дисковые массивы

RAID (Redundant Array of Inexpensive disks) - избыточный массив
недорогих дисков
4 этапа процесса обслуживания:

определение отказавшего диска,

устранение отказа без останова обработки;

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

периодическая замена отказавших дисков на новые.

Уровни RAID:

RAID 0: расслоение дисков (disk stripping)

RAID 1: зеркальные диски

RAID 2: матрица с поразрядным расслоением

RAID 3: аппаратное обнаружение ошибок и четность

RAID 4: внутригрупповой параллелизм

RAID 5: четность вращения для распараллеливания записей

RAID 6: двумерная четность

Доменная служба каталогов Windows NT

Домен - это объединение одного или нескольких серверов, обеспечивающее единую базу
учетных записей пользователей

Между доменами могут существовать доверительные отношения

Графические интерфейсы и средства их разработки

С.Клименко, Институт Системного Программирования РАН,

В.Уразметов, Московский Физико-Технический Институт

Групповая работа в Rational Rose/C++

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

Декомпозиция модели на категории и управляемые части (units)
позволяет наделить разработчика своим кругом ответственности.

Rational Rose/C++ интегрируется с системой управления версиями
(PVCS) или подобными ей.

Внутри выделенного рабочего пространства участники групповой
работы могут работать на различных платформах (UNIX или Windows)
и в дальнейшем собрать единую модель.


Документирование модели

Rational Rose/C++ включает средства документирования
модели:

Вывод на печать диаграмм и спецификаций непосредственно
из Rose/C++

Генерация документации модели в RTF формате для
последующего редактирования средствами мощных редакторов типа
MicroSoft Word

Создание шаблонов для генерации проектной документации
в соответствии с заданным стандартом с помощью средства автоматизированного
документирования SoDA.

Classes

Class name:

Environmental Controller

Documentation:

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

Superclasses:



Roles/Associations:



Attributes:

Voltage : int = 220

напряжение питания

Has-A Relationships:

: Cooler

: Heater

: Light

Operations:

Define_climate( temperature : temp_range, humidity
: humid_range) : control_status

Задать климат

Terminate_climate( )

отменить заданный климат

Характеристики рабочих станций на базе процессора Alpha

Система/ Характеристики	AlphaStation 200 4/100	AlphaStation 200 4/166 и 200 4/233	AlphaStation 250 4/266	DEC 3000 модель 900
Частота	100 МГц	200 4/166: 166 МГц 200 4/233: 233 МГц	266 МГц	275 МГц
Размер кэш	512 Кб	512 Кб	2 Мб	2 Мб
Макс. размер памяти	192 Мб	192 Мб	512 Мб	1 Гб
Макс. емкость дисков (внутренняя/ общая)	3.15Гб / 29.4 Гб	3.15 Гб / 29.4 Гб	4.2Гб /29.4Гб	8.4Гб/170 Гб
Макс. пропускная способность ввода/вывода	132 Мб/с	132 Мб/с	132 Мб/с	100 Мб/с
Графика и мультимедиа	DEC864 ATI Mach64 ATI Video Basic ZLXp-Es FullVideo Supreme Встроенная стерео-аудио система	DEC864 ATI Mach64 ZLXp-Es Встроеннаястерео-аудио система	DEC864 ZLXp-Es FullVideo Supreme Встроенная стерео-аудио система	ZLX-Es ZLX-L1 ZLX-M2 J300 Голосовая аудио-система
Слоты ввода/вывода	1 PCI, 1 ISA, 1 PCI/ISA, встроенный Ethernet, FDDI, Token Ring	2 PCI/ISA C, 1 ISA, SCSI-2, Ethernet, FDDI, Token Ring	1 PCI, 1 ISA, 1 PCI/ISA, Fast SCSI-2, встроенныйEthernet, FDDI, Token Ring	6 TURBOchannel, 12 Fast SCSI-2, Ethernet, FDDI, ISDN, Prestoserve, VME
Поддержка кластеров	Ethernet, FDDI	Ethernet, FDDI	Ethernet, FDDI	Ethernet, FDDI
Операционные системы	Digital UNIX, OpenVMS, Windows NT Workstation	Digital UNIX, OpenVMS, Windows NT Workstation	Digital UNIX, OpenVMS, Windows NT Workstation	Digital UNIX, OpenVMS

unlimited users Solstice

	E3000	K250	K260
Processor	UltraSPARC	PA-8000	PA-8000
Clock Speed	167MHz	160MHz	180MHz
Cache per CPU	1MB per CPU	1MB/1MB(I/D)	1MB/1MB(I/D)
Max CPUs	6	4	4
estimated tpm	6,660 (6)	11,580 (4)	12,320 (4)
SPECrate_int95	336 (6)	390 (4)	415 (4)
SPECrate_fp95	469 (6)	380 (4)	400 (4)
Min/Max Memory	64MB-6GB	128MB-3.75GB	128MB-3.75GB
Max External Disk	>2TB	3.8TB	3.8TB
I/O Slots	6 SBus	4 HP-PB	4 HP-PB
		1 HP-HSC	1 HP-HSC
I/O Bandwidth	1.2 GBps(peak)	128 MBps(peak)	128 MBps(peak)
Hot Plug Disks	10 internal	no internal	no internal
Hot Plug Components	Power/Cooling Boards	no	no
Warranty	1 yr, on-site	1 yr, on-site	1 yr, on-site
Basic OS	Solaris 2.5. 1 unlimited users Solstice Disk-Suite, Solstice Backup	HP-UX 10.20 2-user	HP-UX 10.202-user

unlimited users Solstice Disk-

	E4000	K450	K460
Processor	UltraSPARC	PA-8000	PA-8000
Clock Speed	167MHz	160MHz	180MHz
Cache per CPU	1MB per CPU	1MB/1MB(I/D)	1MB/1MB(I/D)
Max CPUs	14	4	4
estimated tpm	11,500 (12)	11,580 (4)	12,320 (4)
LADDIS (NFSops/s)	15,674 (12)	na	9,572 (4)
LADDIS (ms/op)	21.1 (12)	na	19.9 (4)
SPECrate_int95	660 (12)	390 (4)	415 (4)
SPECrate_fp95	887 (12)	380 (4)	400 (4)
Min/Max Memory	64MB-14GB	128MB-3.75GB	128MB-3.75GB
Max External Disk	>4TB	8.3TB	8.3TB
I/O Slots	21 SBus	8 HP-PB	8 HP-PB
		5 HP-HSC	5 HP-HSC
I/O Bandwidth	2.6 GBps(peak)	288 MBps(peak)	288 MBps(peak)
Hot Plug Disks	10 internal	no internal	no internal
Hot Plug Components	Power/Cooling	no	no
		Boards
Warranty	1 yr, on-site	1 yr, on-site	1 yr, on-site
Basic OS	Solaris 2.5. 1 unlimited users Solstice Disk- Suite, Solstice Backup	HP-UX 10.20 2-user	HP-UX 10.202-user

Arrays or4 Trays and

	E5000	T520	T600
Processor	UltraSPARC	PA-7150	PA-8000
Clock Speed	167MHz	120MHz	180MHz
Cache per CPU	1MB per CPU	1MB/1MB(I/D)	1MB/1MB(I/D)
Max CPUs	14	14	12
estimated tpm	11,500 (12)	7,000 (12)	15,000 (12)
Min/Max Memory	64MB-14GB	256MB-3.75GB	na-3.75GB
Max External Disk	>6TB	20TB	30TB
I/O Slots	21 SBus	112 HP-PB	168 HP-PB or
		24 HP-HSC
I/O Bandwidth	2.6 GBps(peak)	256 MBps(peak)	na
System Bus Throughput	2.6 GBps(peak)	960 MBps(peak)	960 MBps(peak)
In-rack Devices	3 Arrays or4 Trays and Tape Unit	no internal	no internal
Hot Plug Components	Power/Cooling Boards	no	no
Warranty	1 yr, on-site	1 yr, on-site	1 yr, on-site
Basic OS	Solaris 2.5.1 unlimited users Solstice Disk-Suite, Solstice Backup	HP-UX 10.20 2-user	HP-UX 10.20 2-user

МОДЕЛЬ	G40	J40
ЦП
Тип процессора	PowerPC604	PowerPC604
Тактовая частота (Мгц)	112	112	112	112	112	112	112
Число процессоров	1	2	4	2	4	6	8
Системная шина (бит)	64	64	64	64	64	64	64
Размер кэша
L1 (команды/данные)(Кб)	16/16	16/16	16/16	16/16	16/16	16/16	16/16
L2 (Мб)	0.5	0.5	0.5	1	1	1	1
ПАМЯТЬ
Минимальный объем (Мб)	64	64	64	128	128	128	128
Максимальный объем (Мб)	1024	1024	1024	2048	2048	2048	2048
ВВОД/ВЫВОД
Количество слотов	5MCA	5MCA	5MCA	6MCA	6MCA	6MCA	6MCA
Периферийные интерфейсы	Fast/Wide SCSI-2	Fast/Wide SCSI-2
Максимальная емкость внутренних дисков (Гб)	13.5	13.5	13.5	36	36	36	36
Максимальная емкость дисковой памяти (Гб)	350	350	350	99	99	99	99
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint_rate95	33.6	66.5	122.0	71.9	138.0	205.0	258.0
SPECfp_rate95	28.2	53.3	-	57.3	107.0	159.0	200.0
SPECint_base_rate95	32.2	60.6	110.0	64.9	129.0	195.0	244.0
SPECfp_Base_rate95	26.9	50.7	-	53.4	102.0	154.0	189.0
tpmC	-	-	-	-	-	-	5774
$/tpmC	-	-	-	-	-	-	243

Инструментальная среда PowerBuilder

Инструментальная среда разработки PowerBuilder состоит из ряда интегрированных графических
инструментов - художников, позволяющих коллективу разработчиков проектировать, создавать,
интерактивно тестировать и применять приложения клиент/сервер в режиме "укажи и щелкни
кнопкой мыши". Cреда разработки PowerBuilder может быть расширена для организации
непосредственного доступа к набору инструментальных средств разработки других фирм. Интерфейс
пользователя PowerBuilder MDI позволяет разработчикам открывать окна нескольких художников
одновременно, что дает возможность мгновенно получить доступ к нужному режиму работы.
Поддержка средой разработки правой кнопки мыши упрощает и ускоряет процесс создания сложных
приложений.

Художник
приложений (Application Painter)

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


Художник окон (Window Painter)

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


Художник меню (Menu Painter)

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


Художник Окна данных (DataWindow Painter)

Художник Окна данных создает интеллектуальный объект данных для просмотра,
манипулирования и обновления реляционных баз данных без необходимости программирования на

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


Художник структур (Structure Painter)

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


Художник настроек (Preferences Painter)

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

Справка
(Help)

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


Художник баз данных (DataBase Painter)

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

Центральный репозиторий дизайна приложений (Central Application Design Repository) предоставляет
развитые возможности управления хранением расширенных атрибутов столбцов, таких как
заголовки, метки, форматы изображения, правила проверки и графические стили
редактирования.


Художник переноса данных (Data Pipeline Painter)

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


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


Художник запросов (Query Painter)

Художник запросов предоставляет графические средства для создания запросов к базам
данных и сохранения этих запросов в виде объектов. Объекты запросов можно использовать в
качестве источника информации для Окна данных и отчетов, обеспечивая еще более тесную
интеграцию с базами данных. Художник запросов полностью поддерживает графическое
рисование SQL как для таблиц, так и для представлений. Для дополнительной гибкости пользователи
при желании могут иметь полный доступ к оператору SQL Select.


Художник функций (Function Painter)

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


Художник проектов (Project Painter)

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


Художник библиотек (Library Painter)

Художник библиотек позволяет разработчикам совместно использовать все объекты
приложений, такие как окна, Окна данных, меню, структуры и Объекты пользователей
(User Objects). Эти объекты хранятся в одной или нескольких библиотеках, локализованных в одном
месте или распределенных в сети. Возможность проверки при выдаче и возврате объектов (check-
in/check-out) позволяет предотвратить одновременное обновление одного объекта несколькими
разработчиками. Предоставляются также возможности поиска в библиотеках, анализа взаимосвязи и
создания подробных отчетов для разработчиков по библиотекам и их компонентам.

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


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


Художник Объектов пользователей (User Object Painter)

Художник Объектов пользователей создает объекты, определенные пользователями, из
стандартных элементов управления Windows, предварительно определенных объектов пользователей
и элементов управления VBX. Художник Объектов пользователей может также создавать
невидимые объекты пользователя, обеспечивая полное использование объектно-ориентированной
техники разработки. Используя построитель классов C++ (C++ Class Builder), основанный на
технологии Watcom, объекты пользователя можно реализовывать на языке C++.

Запуск
(Run)

Щелчок левой кнопкой мыши на пиктограмме Run (запуск) приведет к запуску текущего приложения
в среде разработки PowerBuilder для проверки его функциональности.


Отладка (Debug)

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

Интеграция CORBA и WWW-технологий

Быстрое распространение всемирной паутины (WWW) происходило в тот период, когда
распределенные объектные системы, в особенности архитектура CORBA, проходили стадию
стабилизации и созревания. Принятие стандарта CORBA 2.0 позволяет
обеспечить поддержку глобального объектного пространства в масштабе Internet.

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

Известны два основных подхода к интеграции CORBA и WWW. Первый из них основан на
построении шлюзов между мирами WWW и CORBA, служащих для трансформации HTTP
в протокол CORBA 2.0 IIOP . Другой подход заключается во
встраивании функций CORBA в состав клиентов WWW (программ просмотра) и серверов.
Реализация второго подхода возможна либо на основе новых WWW клиентов и серверов со
встроенным IIOP, либо при помощи подгрузки (downloading) из сети модуля поддержки IIOP в
клиенте или сервере.

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

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

Интеграция СУБД в глобальную сеть Internet

Интеграция информационных ресурсов библиотеки организована путем создания на основе WWW
(World Wide Web) - технологии серверов в основных библиотеках и информационных центрах
страны с обеспечением средств доступа к ним на основе протокола TCP/IP.

Таким образом, одной из задач проекта является обеспечение стыковки базы данных СУБД
ORACLE с Internet протоколами и разработка удобного пользовательского интерфейса
позволяющего осуществлять поиск интересующей пользователя литературы. WWW - это
гипертекстовая система, использующая для общения клиента с сервером собственный протокол
HTTP (HyperText Transfer Protocol), а также поддерживающий массу различных протоколов
обмена приложений Internet. Для создания и использования гипертекстовых документов определен
язык HTML (HyperText Markup Language). Для указания ресурсов используется технология URL
(Universal Resource Locator). С помощью данной технологии реализуется взаимодействие WWW-
сервера с базами данных ORACLE. Суть такого взаимодействия заключается в том, что
программа-сервер (Alibaba) WWW способна организовать взаимодействие с классом программ
класса CGI (Common Gateway Interface). Один из вариантов использования CGI - исполнение SQL-
запросов к базе данных.

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

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

Инструментальными средствами решения этой задачи являются C, SQL и HTML, а также пакет
разработчика ODBC SDK.

Обмен данными производится на основе архитектуры клиент-сервер. Для обмена данными
используются документы MIME (Multipurpose Internet Mail Extensions) стандарта, который
включает в себя описание различных типов документов от простого текста до анимации.
Интерпретация полученных документов возлагается на средства просмотра документов
работающие на стороне клиента такие, как Modzilla, Netscape, Mozaic и им подобные,
объединяемые названием WWW browsers.

WWW сервер постоянно находится в режиме ожидания запросов на соединение от удаленных
пользователей. После установления сеанса связи с клиентским приложением просмотра
документов клиенту пересылается либо указанный им документ, либо стандартный документ-
заставка (home page) сервера.

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

В.Крюков, А.Петренко, Институт прикладной математики
им. М.В.Келдыша
РАН
Данный доклад посвящен обзору основных результатов исследований и разработок средств
поддержки разработки ПО для крупных управляющих систем реального времени, в которых
участвовал Институт прикладной математики (ИПМ) им. М.В.Келдыша РАН в содружестве с
другими научными центрами на протяжении последних 14 лет.

Начало этих работ было положено проектом Системы Автоматизации разработки Программного
Обеспечения (САПО) ПРОЛОГ для космического корабля "Буран". Второй этап этой деятельности
состоял в развитии САПО ПРОЛОГ в целях расширения сферы приложения методики разработки
систем реального времени (СРВ) и языка реального времени ПРОЛ2 за счет перехода на новые
программно/аппаратные платформы и за счет более широкого охвата фаз жизненного цикла,
начиная от эскизного проектирования, кончая тестированием. Третий этап определяется
привлечением качественно новых подходов к методам разработки и созданием инструментов,
поддерживающих эти методы. В основе этих подходов лежит идея систематизации, а там, где это
возможно, даже формализации процесса разработки, формального описания структуры
разрабатываемого программного продукта с учетом его эволюции и вариантности и формального
описания поведения, которое открывает возможности автоматизации сопоставления поведения
программной системы с ее спецификацией.

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

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

При создании программного обеспечения многоразовой космической системы (МКС) "БУРАН"

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

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

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

при кодировании информационных посылок из ЭВМ в аппаратуру;

при организации взаимодействия различных алгоритмов между собой.
Для устранения первого источника ошибок для разработки ПО МКС "БУРАН" был создан
проблемно-ориентированный язык высокого уровня для описания алгоритмов управления
бортовыми системами ПРОЛ2. Используя ПРОЛОГ алгоритмисты и разработчики бортовых
систем описывали алгоритмы, вводили их в ЭВМ и, далее, с помощью системы автоматизации
программирования автоматически получали исполняемые программы для управления бортовыми
системами.

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

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

Таким образом, интегрированный комплекс для разработки программных систем позволял:

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

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


замкнутой схеме ;

получать загрузочные модули для специализированной управляющей ЭВМ;

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

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

при отладке задавать условия испытаний программного обеспечения
управлять процессом сбора, отображения и анализа всей необходимой
информации для каждого конкретного разработчика; в ходе автономной
отладки обеспечивался контроль выполнения требований жесткого реального
времени.
Благодаря использованию интегрированного комплекса при разработке программного
обеспечения МКС "БУРАН" за 4 года было создано и отработано ПО для управления системами
МКС "БУРАН" и необходимая инфраструктура объемом свыше миллиона операторов.

В рамках второго этапа работ были разработаны язык СИПРОЛ, который является упрощенным
вариантом языка ПРОЛ2, и интегрированная система проектирования и разработки СИПРОЛ-
программ .

В ходе этих работ решались следующие проблемы:

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

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

проблема интеграции различных инструментов, поддерживающих
проектирование, кодирование, отладку и тестирование систем управления.
Все перечисленные проблемы были решены. Реализованная система СИПРОЛ была разработана
для IBM-совместимых платформ в качестве инструментальной ЭВМ. Для расширения спектра
целевых ЭВМ генератор кода позволял получать исполнимый код в форме С-программ.


Это
позволяло переносить разработанные системы управления практически на все современные
ЭВМ.

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

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

Как известно на западе в последние 3-4 года очень серьезное внимание уделяется "уровню
зрелости" (maturity level) процесса разработки. Это внимание обусловлено пониманием того факта,
что главным фактором, определяющим уверенность пользователя (покупателя или заказчика)
программного обеспечения в его качестве, не может являться какая-либо однократная проверка
качества, будь то тестирование, инспекция кода или нечто подобное. Гарантию качества дает
только совокупность мер по организации взаимодействия разработчиков, совместного
использования и разработки программ, документов и др. что в целом и определяет уровень
зрелости организации- и группы-производителя ПО. В качестве стартовой точки в систематизации
процесса разработки всеми признано введение организационных процедур и средств управления
конфигурациями ПО. В русскоязычных публикациях конфигурационное управление (КУ) часто
называется управлением версиями, хотя, в действительности, оно охватывает проблемы
структуризации и хранения программных материалов существенно шире, чем простое хранение
версий.

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

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


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

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

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

обеспечить целостность контролируемых версий.
На основе предложенного подхода была разработана система управления конфигурациями для
IDM PC. Концепция иерархического конфигурационного управления описана в href="#lit">[2].

Как известно, одной из главных проблем разработки СРВ является проблема надежности. К
средствам повышения надежности ПО, которые развивались в рамках третьего этапа относятся
методика и средства поддержки формальных спецификаций и автоматизации тестирования на
основе таких спецификаций.

Данная методика была апробирована в ходе верификации ядра реальной операционной системы
(объем около 200 тыс. строк языка высокого уровня). Формальные спецификации строились по
результатам реверс-инженеринга. В качестве языка спецификаций использовался язык RAISE
(Rigorous Approach to Industrial Software Engineering) . По разработанным
спецификациям при помощи наших инструментов были сгенерированы тесты. Уровень
автоматизации (отношение объемов автоматически сгенерированных частей тестовых программ к
объемам программ тестовой системы, написанным вручную) лежит в диапазоне 10/1-30/1. Причем,
количество тестовых вариантов (test cases) для каждой из тестируемых процедур легко варьируется
в широком диапазоне (вплоть до миллионов и большего числа вариантов). Заметим, что методика
автоматической генерации нацелена не столько на достижение большого числа тестовых
вариантов, сколько на селекцию так называемых "интересных" тестовых ситуаций, поэтому оценка
эффективности тестирования только через число тестовых вариантов не является главной и
определяющей.

Результативность предложенного подхода была продемонстрирована при тестирования


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

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

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

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

Интерфейс общения с пользователем посредством Internet

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

Реализация интерфейса пользователя проводится на стандартизированном языке WWW серверов
HTML версии 2.0. Данный язык позволяет организовывать гипертекстовые и гипермедиа
документы , в узлах которых могут находиться документы одного из стандартных MIME типов.
Второй уровень HTML позволяет встраивать в документы, передаваемые пользователю ,
стандартные объекты диалога. Данные, введенные пользователем, посредством CGI интерфейса
передаются приложению-обработчику. При построении интерфейса конструирования запросов к
базе данных было принято предположение о том, что пользователь может для запроса
использовать логическое выражение любой конструкции.

При построении указанного выражения из атомов допускается использование логических
операций NOT, AND, OR и скобок для задания порядка вычисления выражений. Данный подход
является серьезным обобщением стандартного конструирования логических выражений,
используемого в большинстве программных средств. Атомы представляются следующим образом:
.

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

автор,

коллективный автор,

тематический рубрикатор,

название

фрагмент названия

год издания,

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

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

Получаемые из базы данных результаты запроса приложения формируют в цепочку HTML
документов MIME типа "text/html" и передают их пользователю посредством WWW сервера.

Internet Information Server - составная часть Windows NT Server

Работа в качестве сервера Internet

WWW Server

FTP server

Gopher server

Консоль управления

Защита

Высокая производительность

Работа в качестве клиента

Встроены Telnet и FTP

Microsoft Internet Explorer

Использование Windows NT для построения глобальных сетей

Объединение нескольких локальных сетей в одну большую

Объединение нескольких локальных сетей с использованием линий связи

ISDN, X.25, Frame Relay, PPP

PPTP

RAS Multilink

Автодозвон

ИТОЛОГИЯ - наука об информационных технологиях

В. Сухомлин, НИВЦ МГУ, учебные материалы конференции ,

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

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

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

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

Предмет итологии - информационные технологии
(ИТ), а также процессы, связанные с их созданием и применением.

Основными методами итологии являются:

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

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

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

Аппарат (концепция и методология) проверки соответствия
(аттестации) реализаций ИТ (т.е. ИТ-систем) ИТ-спецификациям,
на основе которых данные ИТ-системы были разработаны (по существу

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

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

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

Разнообразные методы формализации и алгоритмизации
знаний, методы конструирования прикладных информационных технологий
(пара-дигмы, языки программирования, базовые открытые технологии,
функциональное профилирование ИТ и т.п.).

Язык программирования Си++: этапы эволюции и современное состояние

В.Сухомлин, Научно-исследовательский Вычислительный центр
МГУ им.
М.В.Ломоносова

Эффект конвейеризации при выполнении трех команд - четырехкратное ускорение

Типы конфликтов в конвейере:

Структурные конфликты (конфликты по ресурсам)

Конфликты по данным (зависимость команды от результатов выполнения
предыдущих команд)

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

Эволюции продуктной линии SKIP

Хотя SKIP пока не является стандартом Internet, на основе этого протокола, на правах открытого
индустриального стандарта, разработали программные продукты, по меньшей мере, три
организации: Sun Microsystems, Swiss Federal Institute of Technology и АО ЭЛВИС+. Заявили о
работе над продуктами на основе этого протокола такие организации, как Check Point Software,
Toshiba Corporation, и две небольших калифорнийских фирмы - VPNet Technology и IRE.

Уже в июле 1995 года на 33 сессии IETF разработчиками были представлены реализации
протоколов и проверена их совместимость. Тогда эти программы были достаточно далеки от
состояния, которое можно было бы характеризовать как "программный продукт".

На сегодняшний день картина изменилась, и мы имеем масштабируемый ряд продуктов защиты
информации на основе спецификации SKIP. В разработке этого ряда приняли участие, по
существу, все три из упомянутых организаций, однако на деятельности каждой из них сказалась
внутренняя специфика каждой из них. Sun Microsystems использовала SKIP, как базовое средство
защиты трафика в устройстве SunScreen - продукте, который получил признание, в частности, как
продукт 1996 года по категории firewall в журнале LAN Magazine. Продукт SunScreen анонсирован
в мае 1995 года и с тех пор находится в эксплуатации. Кроме устройства SunScreen, Sun предлагает
программную реализацию SKIP для ОС Solaris. В Швейцарии выпущена public domain версия
протокола SKIP. Разработка продуктных предложений, видимо, вследствие некоммерческой
ориентации Swiss Federal Institute of Technology, не анонсировалась. АО ЭЛВИС+, ориентируясь
на специфику российского рынка, пошел по пути разработки недорогих программных реализаций
SKIP для распространенных платформ UNIX и Windows. Помимо платформного деления, АО
ЭЛВИС+ предлагаются версии продукта с различной функциональностью: от простой программы
для защиты трафика оконечного устройства, работающего с одним выделенным сервером, до
полнофункционального продукта защиты станции в корпоративной сети, который обеспечивает

учет топологии сети и индивидуальную настройку дисциплины взаимодействия с различными ее
узлами. Кроме того, нами разработано и предлагается в виде готового продукта устройство для
коллективной защиты локальных сетей SKIPbridge. Это - аппаратно-программный комплекс на
основе SPARCserver 5, который устанавливается на интерфейсе LAN/WAN и обеспечивает
решение двух задач: SKIP-защиту входящего и исходящего трафика и реализацию заданной
политики безопасности на интерфейсе LAN/WAN путем расширенной пакетной фильтрации. На
текущий момент оттестирована совместимость всех продуктов АО ЭЛВИС+ и Sun Microsystems, и
мы можем говорить о едином, широко масштабируемом по функциональности и стоимости, ряде
продуктов. Разработка целого продуктного ряда потребовала от нас решения ряда
технологических проблем разработки ПО - от традиционных, связанных, например, с
переносимостью с платформы на платформу - до достаточно необычных, таких, как обеспечение
совместимости с продуктами других, независимо работающих, групп разработчиков и
отслеживание версионности продуктов в условиях достаточно быстро меняющейся спецификации
базового протокола. Большая часть этих проблем этапа разработки продуктов решена, что,
впрочем, не позволяет нам расслабиться, поскольку следом за проблемами разработки ПО
неизбежно встают проблемы его внедрения и сопровождения.

Сергей Дмитриевич Рябко, руководитель проектов АО ЭЛВИС+

Sergei D. Ryabko, ELVIS+ project manager
tel. (095) 531-1754

fax 531-2403

e-mail

[]
[]
[]

Эволюции спецификации SKIP

Текущая версия эскизных материалов IETF по стандарту SKIP от 14 августа 1996 года имеет ряд
отличий от первой версии, опубликованной 15 мая 1994 года.

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

Усовершенствована и стандартизована логика инкапсуляции в SKIP (туннелирования) в
соответствии со стандартом RFC 1827.

Повышена стойкость защиты системы и за счет введения временно- зависимого механизма защиты
пакетного ключа.

Появился функционально набор проектов стандартов, превращающих SKIP из отдельного
протокола в комплексное технологическое решение. Специальный документ выпущен авторами
спецификации протокола SKIP для использования сертификатов в формате X.509. Описана
процедура обмена информацией о поддерживаемых алгоритмах шифрования для данного узла.
Опуская ряд идейно более мелких коррекций спецификации, следует отметить проработку в новой
спецификации вопросов совместимости SKIP и со следующей (пока повсеместно не внедренной)
версией протокола IP (IPv6).

Кластерные архитектуры

Три составляющих:

Надежность

Готовность

Удобство обслуживания

Свойства VAX-кластеров:

Разделение ресурсов

Высокая готовность

Высокая пропускная способность

Удобство обслуживания системы

Расширяемость

Технологии параллельных баз данных:

Симметричная многопроцессорная архитектура с
общей памятью (Shared Memory SMP Architecture)

Архитектура с общими дисками (Shared Disk Architecture)

Архитектура без разделения ресурсов (Shared Nothing Architecture)

SPEC (Standard Performance Evaluation Corporation):

Разработка и публикация наборов тестов

Публикация ежеквартального отчета

Два базовых набора:

CINT92 (6 программ на Си):

теория цепей

интепретатор ЛИСП

разработка логических схем

упаковка текстовых файлов

электронные таблицы

компиляция программ

CFP92 (14 программ, из них: 2 на Си, 12 на
Фортране)

разработка аналоговых схем

моделирование методом Монте-Карло

квантовая химия

оптика

робототехника

квантовая физика

астрофизика

прогноз погоды

и др.

Типовая среда обработки транзакций
и соответствующие оценочные тесты TPC

Тест ТРС-С: единицы измерения tpm-С и $/tpm-С
Пять типов транзакций:

новый заказ, вводимый с помощью экранной формы - 45%

простое обновление базы данных, связанное с платежом - 43%

простое обновление базы данных, связанное с поставкой - 4%

справка о состоянии заказов - 4%

справка о состоянии склада - 4%

База данных компании:

Товарные склады

Район

Покупатель

Заказ

Порядок заказов

Новый заказ

Статья счета (наименование товара)

Складские запасы

История

Новые тесты: TPC-D и TPC-E

Компоненты архитектуры

Брокер Объектных Заявок. Брокер Объектных Заявок обеспечивает механизмы, позволяющие
объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь о
положении в распределенной среде и способе реализации взаимодействующих с ними объектов.
ORB отвечает за поиск реализации объекта, участвующего в заявке, подготовку объектной
реализации к приему заявки и передачу данных, являющихся результатом заявки. Интерфейс
клиента полностью независим от расположения вызываемого объекта, языка программирования,
на котором он реализован, и любых других аспектов, не отраженных в интерфейсе вызываемого
объекта. На основании совместных предложений ряда ведущих компаний OMG был разработан
стандарт Общей Архитектуры Брокера Объектных Заявок (Common Object Request Broker
Architecture (CORBA)) . CORBA определяет среду для различных реализаций
ORB, поддерживающих общие сервисы и интерфейсы. Это обеспечивает переносимость клиентов и
реализаций объектов между различными ORB.

В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту
CORBA . CORBA непрерывно совершенствуется OMG. Текущий уровень
стандарта -- CORBA 2.0.

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

Служба Уведомления Объектов о Событии (Event Notification Service).

Служба Жизненного Цикла Объектов (Object Lifecycle Service).

Служба Именования Объектов (Name Service).

Служба Долговременного Хранения Объектов (Persistent Object Service).

Служба Управления Конкурентым Доступом (Concurrency Control Service).

Служба Внешнего Представления Объектов (Externalization Service).

Служба Объектных Связей (Relationships Service).

Служба Транзакций (Transaction Service).

Служба Изменения Объектов (Change Management Service).

Служба Лицензирования (Licensing Service)/

Служба Объектных Свойств (Properties Service).

Служба Объектных Запросов (Object Query Service).

Служба Безопасности Объектов (Object Security Service).

Служба Объектного Времени (Time Service).
Функции СУБД в информационной арxитектуре. Следуя принципам модульности и
ортогональности компонентов информационной архитектуры, OMG представляет функции
управления базами данных рядом таких служб, как долговременное хранение объектов,
управление конкурентным доступом к объектам, служба транзакций, службы объектных связей,
объектных запросов, изменений объектов и т.п. Эти и другие службы, взятые вместе, реализуют
функции как объектных так и реляционных СУБД.

Спецификация служб формируется на основе опыта промышленных корпораций, входящих в
состав OMG. Существенное влияние на архитектурные решения оказывают также исследования и
разработки, воплощенные в согласованном стандарте интерфейсов объектных СУБД href="#lit">[7,13], опубликованном в конце 1993 г. группой ODMG (Object Database
Management Group). Эта группа включает представителей основных компаний - производителей
объектных СУБД.

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


как здравоохранение, производство, управление финансовой деятельностью, САПР и т.д.

Ниже кратко рассматривается состав первоначальных компонентов спецификации архитектуры
Общих Средств OMG .

Средства поддержки пользовательского интерфейса (User Interface Common
Facilities)

Средства управления информацией (Information Management Common Facilities)

Средства управления системой (System Management Common Facilities)

Средства управления задачами (Task Management Common Facilities)

Вертикальные общие средства (Vertical Common Facilities)

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

Поддержка интероперабельности брокеров в стандарте CORBA 2.0

Интероперабельность брокеров поддерживается Универсальным Межброкерным
Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP
является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и
может быть отображен в любой транспортный протокол, поддерживающий виртуальные
соединения. Одно из таких отображений - отображение GIOP в протокол TCP/IP - определено
CORBA 2.0 в качестве Межброкерного Протокола Internet (Internet Inter-ORB Protocol,
сокращенно IIOP). Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать сети
брокеров в рамках Internet и за ее пределами.

Согласно GIOP, внутренняя архитектура брокеров предполагается неизвестной. Подход, который
может быть выбран конкретным брокером для поддержки GIOP/IIOP, не определяется. Все, что
требуется для согласованного включения брокера в компьютерную сеть, - это существование
связанных с ним компонентов, способных посылать и принимать сообщения IIOP.

Спецификация GIOP включает:

Определение Общего представления данных (Common Data
Representation - CDR), являющегося, по существу, коммуникационным
синтаксисом, отображающим значения типов данных OMG IDL в формат
передачи данных между брокерами и межброкерными мостами (агентами);

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

Определение ограничений на допустимый сетевой транспорт GIOP.
Протокол IIOP, который можно считать специализацией GIOP, определяет дополнительно, как
агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP.

Концепция визуального программирования в IBM VisualAge Smalltalk

В.Орлов, IBM
VisualAge - это мощная среда для разработки приложений для архитектуры клиент-сервер. Она
ориентирована, прежде всего, на разработки бизнес-приложений, включая системы для
онлайновой обработки транзакций и системы поддержки решений. VisualAge позволяет
профессиональным разработчикам строить клиентские части прикладных систем со сложным
графическим интерфейсом, проектировать деловую логику работы приложений с доступом к
локальным и удаленным ресурсам. VisualAge представляет собой чисто обьектно-
ориентированное средство разработки, включающее набор визуальных интерактивных
инструментов, библиотеку готовых компонент и набор средств для построения клиент-
серверной среды. Поддержка графического интерфейса, предоставляемая готовыми
компонентами, отвечает CUA (Common User Access) спецификациям и содержит ряд
расширений для организации гибкого ввода-вывода в сложных формах и таблицах. Библиотека
готовых компонент предоставляет также поддержку устройств

мультимедиа, коммуникаций через протоколы APPC, TCP/IP, NetBIOS, программных
интерфейсов CICS External Call Interface, EHLLAPI, Message Queue Interface (MQI), работу с
реляционными базами данных семейств DB2, Oracle, Sybase и многое другое. Прежде чем
перейти к описанию визуального построения приложений, отметим ряд замечательных качеств
VisualAge, таких как повторное использование кода, поддержка моделей SOM и DSOM,
возможности групповой разработки приложений с использованием центрального репозитория.

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

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

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

Для VisualAge таким языком является чисто обьектно-ориентированный язык IBM Smalltalk.
Сама среда разработки VisualAge создана на Smalltalk. Среди разнообразных средств
визуального программирования VisualAge интересен именно максимально продвинутой и
последовательно реализованной концепцией обьекто-ориентированной технологии.

Приложения написанные на Smalltalk соответствуют схеме MVC (Model-View-Controller). Model
является набором объектов, выражающих бизнес-логику приложения, View представляет
объекты из пользовательского интерфейса, Controller состоит из объектов преобразующих
действия пользователя с View в запросы к Model.

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

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

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

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

Видимая деталь - деталь, имеющая видимое представление во
время исполнения программы.


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

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

Атрибуты - данные, к которым имеют доступ другие детали.
Эти данные представляют сущность и состояние детали. Например, это может
быть остаток на банковском счете, имя человека, метка на кнопке ввода.

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

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

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

Событие - Действие вызывает выполнение действия при возникновении
события.

Событие - Встроенная программа запускает выполнение встроенной
программы при возникновении события.

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

Для иллюстрации построим несколько простых приложений.

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


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

на рабочую область.


Для запоминания списка выбрана невидимая деталь Ordered Collection (Упорядоченная
коллекция), которая позволяет добавлять и удалять объекты любого типа. Логику
взаимодействия деталей можно описать следующим предложением: "При нажатии кнопки Add
добавить содержимое поля ввода в Упорядоченную коллекцию и отображать находящееся в
ней в Списке; при нажатии кнопки Remove удалить выделенный элемент Списка из
Упорядоченной коллекции". В соответствии с этим установим связи между деталями. При
нажатии кнопка генерирует событие 'clicked'
.Свяжем
это событие с действием 'add' (добавить), выполняемым Упорядоченной коллекцией



Штриховая линия говорит о том, что параметр для вызываемого действия не указан. Так как в
коллекцию добавляется содержимое поля ввода, свяжем атрибут 'object' поля ввода с
атрибутом 'anObject' связи Кнопка-Упорядоченная Коллекция.


Для того, чтобы содержимое Колекции отображалось в Списке, соединим атрибуты 'items'
Списка и 'self' Коллекции. С кнопкой "Remove" поступим аналогично кнопке "Add", только
вызываемым действием Коллекции будет теперь 'remove', а его параметром - атрибут 'selected
item' Списка.


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


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

Если в предыдущем примере список сотрудников необходимо хранить в какой-либо базе
данных, задача несколько усложнится, но подход к созданию приложения не изменится. Мы
только возьмем другую деталь вместо 'Упорядоченной коллекции' - 'Запрос к базе данных'. Она
обладает более широким набором свойств, среди которых нас больше всего интересует
действие 'выполнить запрос' ('executeQuery') и атрибут 'результирующая таблица' ('resultTable').
Действие выполняет заданное SQL выражение, а деталь 'результирующая таблица' позволяет
работать с полученным результатом. Внешне программа изменилась не существенно


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

[]
[]
[]

Критерии выбора корпоративных инструментов в применении к Borland Delphi

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

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

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

"Единство противоположностей": Нейтральность по отношению к используемым форматам
БД + поддержка специфики конкретных способов хранения/доступа к данным
Универсальный механизм доступа к данным.

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

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

Рассмотрим, насколько Delphi удовлетворяет выше перечисленным требованиям.

Delphi использует язык 3-го поколения Object Pascal, обладающий полной реализаций
основных признаков объектной ориентации (инкапсуляция, наследование, полиморфизм),
поддержкой RTTI-RunTime Type Information и встроенной обработкой исключительных ситуаций
(Exception handling).
Компонентная архитектура Delphi является прямым развитием
поддерживаемой объектной модели. Все компоненты являются объектными типами (классами), с
возможностью неограниченного наследования. Компоненты Delphi поддерживают PME-модель
(Property, Method, Events), позволяющую изменять поведение компонентов без необходимости
создания новых классов.

Delphi 2 Client/Server Suite включает систему контроля версий Intersolv PVCS, поддерживает
работу со словарем данных (Data Dictionary) и Репозитарием объектов (Object Repository). Среда
визуальной разработки Delphi позволяет единообразно работать как с предопределенными, так и с
пользовательскими компонентами, которые разрабатываются на том же языке (Object Pascal), на
котором создаются и конечные приложения.

Borland Database Engine (BDE) обеспечивает единообразную работу с локальными данными
(Paradox, dBase) и серверами БД (Oracle, Sybase, MS SQL Server, InterBase и т.д.), за счет
применения навигационных методов доступа к серверным СУБД (двунаправленные курсоры,
закладки и т.п.) и SQL - к локальным форматам (подмножество Local SQL).


Borland Database Engine

Компилятор Delphi является самым быстрым; имеет общий генератор кода с Borland C++
(Delphi 2 & BC++ 5). Компилятор Delphi (точнее, Object Pascal) является продолжением линии
компиляторов Turbo Pascal / Borland Pascal.

Открытые интерфейсы Delphi - Open Tools API - обеспечивают контроль над средой
разработки "из вне" и доступ к информации о проекте.

Delphi 2.01 Client/Server Suite включает CASE Expert, позволяющий
импортировать данные из ведущих CASE в словарь данных Delphi,
интегрировать IDE (Integrated Development Environment) с генераторами кода
(например, Silver Run RDM компании CSA, WithClass 3.0 и т.п.).

"Эксперты" (программные модули, встраиваемые в IDE) позволяют
использовать Delphi как "скелет" - общую среду разработки - для всего
комплекса используемых инструментов.

Delphi 2 включает "генератор дистрибутивов" Install Shield Express.


Интерфейсы - структура

Магнитные диски

Время обслуживания

время доступа (2-10 мс)

время ожидания (4-8 мс)

время передачи (1-4 Мбайт/с)

Время доступа в подсистеме SCSI (основной компьютер,
главный адаптер SCSI, контроллер НМД, собственно НМД):

Пересылка команд SCSI в главный адаптер

Фаза выбора устройства (главный адаптер)

Фаза команды

Фаза разъединения

Фаза повторного соединения

Фаза данных

Фаза состояния

Фаза разъединения

Основные характеристики НМД:

Емкость - до 9.1 Гбайт

Среднее время доступа - 8 мс

Скорость вращения - до 7200 оборот/мин

Время наработки на отказ - 1000000 часов
Основные характеристики магнитооптических дисков:

Емкость - до 1.3 Гбайт

Среднее время доступа - 19 мс

Среднее время наработки на отказ - 80000 часов

Механизмы межпроцессных взаимодействий в операционной системе Unix

, учебные материалы конференции ,

Традиционный подход ОС UNIX
- реакция на сложности Multics
Возникшие проблемы
Избыточный набор системных средств, предназначенных для обеспечения
возможности взаимодействия и синхронизации процессов, которые
не обязательно связаны отношением родства

IPC - Inter-Process Communication Facilities

с появлением UNIX System V Release 4.0 все эти средства были
узаконены и вошли в фактический стандарт ОС UNIX современного
образца

в разных вариантах системы средства IPC реализуются по-разному

эффективность реализации различается

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

Пакет средств IPC

UNIX System V Release 3.0

средства, обеспечивающие возможность наличия общей памяти
между процессами (сегменты разделяемой памяти - shared memory
segments)

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

средства, обеспечивающие возможность посылки процессом сообщений
другому произвольному процессу (очереди сообщений - message
queues)

Общие свойства всех трех механизмов:

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

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

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

ключ IPC_PRIVATE

ключ IPC_CREAT

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

Microsoft Exchange

Хранение и совместное использование информации

Передача сообщений

Групповое планирование

Дизайн электронных форм

Разработка приложений

Microsoft SQL Server 6.5 отвечает требованиям крупных заказчиков

Масштабируемая система с высокой производительностью

Создан для работы в распределенных средах

Прост в инсталляции и развертывании

Построен на открытой платформе

Относительно низкая цена

Является частью интегрированной системы приложений Клиент -Сервер

Множественные прикладные среды Windows NT

Виктор Олифер,






Защищенные подсистемы взаимодействуют путем передачи
сообщений, используя механизм LPC

LPC - Local Procedure Call - вызов локальных процедур

Цели подсистем окружения:

Обеспечить несколько программных интерфейсов

Экранировать базовую ОС от изменений API

Объединить общие для всех API глобальные данные, уменьшая
избыточность

Обеспечить возможность включения новых API

Защита окружений от приложений

Множественные прикладные среды обеспечивают совместимость на ДВОИЧНОМ уровне

Цели:

возможность выполнять программы, написанные для
других ОС и процессоров

встроенность средств обеспечения совместимости
в ОС

приемлемая скорость выполнения приложений

Примеры ОС, содержащих встроенные средства
обеспечения множественных прикладных сред:

OS/2 2.x

Workplace OS

Windows NT

PowerOpen

некоторые версии UNIX


Пример различия в системных вызовах:

fork() Наследует адресное пространство родителя Имеет одну нить При завершении потомка нужно послать сигнал родителю

DosExecPgm() Адресное пространство создается заново на основе файла prog.exe Имеет несколько нитей При завершении потомка созданного с опцией EXEC_SYNC идентификатор процесса нельзя повторно использовать

Цели разработки микроядра Mach

Обеспечение базовых функций для создания других
операционных систем (например, UNIX)

Поддержка больших разряженных адресных пространств

Обеспечение прозрачного доступа к сетевым ресурсам

Поддержка параллелизма как в системе, так и в
приложениях

Обеспечение переносимости Mach на различные типы
компьютеров

Абстрактная модель эмуляции UNIX на основе
Mach



Функции микроядра Mach:

управление процессами,

управление памятью,

коммуникации

функции ввода-вывода

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

Модель API на основе DLL




Системные сервисы
Менеджер объектовМонитор ссылокбезопасности
Менеджер процессовСредство вызова локальных процедур
Менеджер виртуальной памяти
Менеджер ввода-выводаЯдро
<

Обращение к системным сервисам в традиционных ОС

аппаратное прерывание

процессор переходит в режим ядра

выполняется требуемая системная функция

возврат процессора в пользовательский режим

выполнение нити с прерванного места

Вызов системной функции (API Win32) в Windows NT

Динамическая библиотека DLL Win32 обращается
к системному сервису NT с просьбой послать сообщение серверу,
выполняющему требуемую функцию

Сервис посылает сообщение и ждет ответ

Сервер получает сообщение, выполняет функцию
и отсылает ответ

NT-executive выполняет следующую последовательность
действий:

сохраняет контекст клиентской нити

выбирает серверную нить для выполнения и загружает
ее контекст

выполняет функцию API Win32, используя серверную
нить

сохраняет контекст серверной нити

загружает контекст клиентской нити и обрабатывает
результаты выполнения функции API


Оптимизация

некоторые функции API реализованы внутри библиотеки
заглушек

некоторые данные Win32 хранятся в адресном пространстве
NT-executive

запросы приложений на выполнение функций API
объединяются в пакеты

Надежность Windows NT

Все приложения выполняются в раздельных адресных пространствах

Изолированность от аппаратуры

Изолированность подсистем

Файловая система NTFS с автовосстановлением

Встроенные средства резервного копирования

Встроенные средства надежной работы с диском

Нетрадиционные среды программирования: от Корнелльского Синтезатора до Java

В.Галатенко, Jet InfoSystems,

П.Христов, Открытые системы

Новые проекты в области информационных

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

В 1993-1995 годах при поддержке Российского фонда фундаментальных исследований в ЦУПе в
рамках инициативного проекта "Гипервизор", проводились исследования целью которых была
разработка концепции и основ системы визуализации сложных трехмерных динамических сцен с
высоким уровнем реализма. Были получены подходы к решению фундаментальных задач синтеза
изображений, в частности, методы обратной трассировки на произвольной картинной
поверхности, методы непосредственной трассировки невыпуклых параметрических поверхностей
на основе решения экстремальной задачи, которые могут использоваться в качестве основы при
построении архитектур системы синтеза изображений. При этом большое внимание в проекте
было уделено принципам построения открытой, доступной развитию архитектуры системы, в
частности, - созданию системы классов с виртуальными методами (в рамках объектно-
ориентированного подхода), позволяющих избежать жесткой привязки алгоритмов к конкретному
типу вычислителя и, по возможности, свести к минимуму адаптацию алгоритма к вычислителю.

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

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

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

Для управления состояниями сцены используется интерфейс событий, при наступлении которых
образ сцены, хранимый в памяти в виде описания состояния объектов, оперативно изменяется:


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

С 1996 года инициативные исследования по виртуальной реальности в ЦУПе (также при
непосредственной поддержке РФФИ) продолжены в направлении построения концепции
индуцированной виртуальной среды.

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

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

По сравнению с обычными системами виртуальной реальности, система виртуального присутствия


должна содержать, как минимум, две дополнительные подсистемы:

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

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

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

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

Предлагаемая методология построения индуцированной виртуальной среды

включает в себя решение следующих основных задач:

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

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

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

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

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

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

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

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

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

исследования методологии построения баз структурных, морфологических
и оптических данных о естественных и техногенных 3D- объектах на основе
объектно-ориентированного подхода.
В заключение отметим, что проникновение виртуальной реальности в среду Internet (в частности,
зарождение и бурное развитие концепции VRML) открывает большие возможности для развития
телекоммуникаций в индуцированной виртуальной среде. В перспективе (по мере развития
технических возможностей систем телеметрии, слежения, каналов связи, персональных
вычислительных систем и средств отображения) любой пользователь сети Internet мог бы получить
возможность "виртуального присутствия" на борту, например, международной орбитальной
станции "Альфа" и в реальном времени "принимать участие" в проведении некоторых
экспериментов на борту (как минимум, - наблюдать за их проведением), и даже вместе с экипажем
или самостоятельно "выходить" в открытый (разумеется, виртуальный) космос или на поверхность
планеты.

Объединение подсетей в корпоративную сеть

Windows NT как сервер удаленного доступа

Поддержка NetBEUI, IPX

Поддержка TCP/IP (SLIP, PPP)

Использование RAS на предприятиях

EICON WAN Services for Windows NT

[]
[]
[]

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

И.Юков, Институт системного программирования РАН
В работе рассмотрены вопросы построения объектно-ориентированной среды для эффективной
реализации высокоинтерактивных трехмерных графических приложений в таких областях как
геометрическое моделирование, САПР и научная визуализация.

Наиболее перспективным направлением работ по созданию интегрированного программного
обеспечения в области трехмерной графики и моделирования является разработка объектно-
ориентированных инструментальных средств, с помощью которых возможна реализация
проблемно-ориентированных приложений на основе единого ядра. Этот подход позволяет,
используя единые базовые средства, реализовывать трехмерные приложения в различных
прикладных областях. Представленная объектно-ориентированная среда для разработки
трехмерных приложений является примером развития объектно-ориентированного подхода и его
применения для создания базового и прикладного программного обеспечения для решения
трудоемких задач геометрического моделирования и научной визуализации. В отличие от
большинства разрабатываемых объектно-ориентированных инструментальных пакетов, которые
организуются в конкретной операционной системе и реализуют тот или иной стандарт,
представленная среда является переносимой для широкого спектра вычислительных платформ,
открытой для поддержки различных стандартов в области геометрического моделирования и
научной визуализации, а также обеспечивает эффективную поддержку нетрадиционных
аппаратных графических акселераторов. Целью работы являлась разработка объектно-
ориентированной технологии построения функционально законченных высокоинтерактивных
трехмерных графических приложений на базе мобильной инструментальной среды, сочетающей
эффективные средства геометрического моделирования, формализованный трехмерный
пользовательский интерфейс и реализующей базовые алгоритмы синтеза, анализа и визуализации
пространственных объектов. Структуризация предметной области позволяет выделить основные
компоненты трехмерного инструментария.
На базе объектно-ориентированного подхода
сформирована смешанная геометрическая модель твердотельных пространственных объектов,
сочетающая конструктивное и граничное представления. В совокупности с базовым набором
синтеза и анализа геометрии пространственных объектов, предложены механизмы параметризации
конструктивной модели и построение на базе геометрии тела его физической модели с реальными
свойствами. Расширяемость разработанной геометрической модели обеспечивает прозрачный
переход к эффективному решению таких задач, как генерация поверхностных и объемных сеток и
последующий конечно-элементный анализ построенных объектов. Формализация понятия
"интерактивная прикладная программа" привела к прозрачной методике построения трехмерных
графических приложений, обладающих базовыми средствами визуализации и навигации в
трехмерном пространстве, позволяющей при решении конкретной прикладной задачи с
минимальными затратами времени на организацию взаимодействия с пользователем получить
мобильное графическое приложение, поддерживающее международные стандарты на
геометрическое моделирование и научную визуализацию. Результаты работы могут быть
использованы при создании систем научной визуализации и САПР, обладающих переносимостью
для широкого класса вычислительных платформ и обеспечивающих поддержку современных
международных стандартов.

[]
[]
[]

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

Сергей Паронджанов, компания Аргуссофт

Rational Rose - средство объектно-ориентированного моделирования,
поддерживающие методы Буча и ОMT.

Работа в Rational Rose основывается на построении различного рода
диаграмм, описывающих проект.

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

Общие параметры защиты системы

Ограничения для паролей

Срок действия

Минимальная длина

Минимальный интервал жизни

Сохранение истории

Блокировка учетных записей

Очереди сообщений

Четыре системных вызова:

msgget
для образования новой очереди сообщений или получения дескриптора
существующей очереди

msgsnd
для посылки сообщения (его постановки в очередь сообщений)

msgrcv
для приема сообщения (выборки сообщения из очереди)

msgctl для выполнения
управляющих действий

msgqid = msgget(key, flag);
Сообщения хранятся в виде связного списка
Декскриптор очереди сообщений - индекс в массиве
заголовков очередей сообщений
В заголовке очереди хранятся:

указатели на первое и последнее сообщение в данной
очереди

число сообщений

общий размер в байтах сообщений, находящихся в очереди

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

временные метки последних выполненных операций msgsnd,
msgrsv и msgctl

Одна из возможных конфигураций программных гнезд

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

во время работы системы менять нельзя

По духу организация программных гнезд близка к идее
потоков
Но менее гибкая схема

не допускает изменения конфигурации "на
ходу"

Взаимодействие процессов основано на модели "клиент-сервер"

процесс-сервер "слушает (listens)"
свое программное гнездо

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

ядро поддерживает внутренние соединения и маршрутизацию
данных от клиента к серверу

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

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

"домен Internet"
для процессов, которые взаимодействуют в сети в соответствии с
семейством протоколов TCP/IP

Два типа программных гнезд

с виртуальным соединением (stream sockets)

дейтаграммные гнезда (datagram sockets)

Виртуальные соединения:

передача данных от клиента к серверу в виде непрерывного
потока байтов с гарантией доставки

до начала передачи данных должно быть установлено
соединение

Дейтаграммные программные гнезда:

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

не требуется предварительное установление соединений

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

TCP для виртуальных соединений

UDP для дейтаграммного способа коммуникаций

Создание нового программного гнезда:
sd = socket(domain, type,
protocol);

domain
- домен гнезда

type - тип (с
виртуальным соединением или дейтаграммное)

protocol - желаемый
сетевой протокол

sd - дескриптор
программного гнезда

Закрытие (уничтожение) гнезда
close(sd)
Связывание ранее созданного программного гнезда
с именем:

bind(sd, socknm, socknlen);

sd
- дескриптор ранее созданного программного гнезда

socknm - адрес
структуры, которая содержит имя (идентификатор) гнезда, соответствующее
требованиям домена данного гнезда и используемого протокола

для домена системы UNIX имя является именем объекта в файловой
системе

при создании программного гнезда создается файл

socknlen - длина
в байтах структуры socknm

Запрос связи с существующим программным гнездом
со стороны процесса-клиента:
connect(sd, socknm, socknlen);

смысл параметров, как у функции bind

имя программного гнезда на другой стороне коммуникационного
канала

у гнезда с дескриптором sd
и у гнезда с именем socknm
должны быть одинаковые домен и протокол

если тип гнезда с дескриптором sd
- дейтаграммный, то connect
служит для информирования системы об адресе назначения пакетов,
которые в дальнейшем будут посылаться с помощью функции send

Информирования о том, что процесс-сервер планирует
установление виртуальных соединений через указанное гнездо:
listen(sd, qlength);

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

Выборка процессом-сервером очередного запроса на
установление соединения с указанным программным гнездом служит
функция accept:
nsd = accept(sd, address, addrlen);

sd
- дескриптор существующего программного гнезда, для которого ранее
была выполнена функция listen

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

addrlen
- адрес, по которому находится длина массива address

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

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

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

Передача и прием данных через программные гнезда
с установленным виртуальным соединением:


count = send(sd, msg, length,
flags);
count = recv(sd, buf, length,
flags);
В send:

msg
указывает на буфер с данными, которые требуется послать

length
- длина этого буфера

flags
== MSG_OOB
внеочередная посылка данных

В recv:

buf
указывает на буфер, в который следует поместить принимаемые данные

length
- максимальная длина этого буфера

flags
== MSG_PEEK
перепись сообщения в пользовательский буфер без его удаления
из системных буферов

Вместо send
и recv
можно использовать read
и write

выполняются аналогично send
и recv

Для посылки и приема сообщений в дейтаграммном
режиме:
count = sendto(sd, msg,
length, flags, socknm, socknlen);
count = recvfrom(sd, buf,
length, flags, socknm, socknlen);

смысл параметров sd,
msg,
buf
и lenght
аналогичен смыслу одноименных параметров функций send
и recv

socknm
и socknlen
функции sendto
задают имя программного гнезда, в которое посылается сообщение

могут быть опущены, если до этого вызывалась
функция connect

параметры socknm
и socknlen
функции recvfrom
позволяют серверу получить имя пославшего сообщение процесса-клиента

Немедленная ликвидация установленного соединения:
shutdown(sd, mode);

немедленно остановить коммуникации

со стороны посылающего процесса

со стороны принимающего процесса

с обеих сторон

в зависимости от значения параметра mode

shutdown отличаются
от close:

выполнение close
последней "притормаживается" до окончания попыток системы
доставить уже отправленные сообщения

shutdown разрывает
соединение, но не ликвидирует дескрипторы ранее соединенных гнезд

для ликвидации требуется вызов close

Описание общей схемы функционирования системы

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

Функционально созданное клиентское приложение разбивается на следующие блоки :

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

Блок обработки заданных удаленным клиентом данных и создания текста запроса на языке
SQL.

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

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

Блок, отвечающий за получение данных, введенных удаленным клиентом в HTML документ.

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

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

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

Блок, инициализирующий серверное приложение, регистрирующий сервис в библиотеке
DDEML и устанавливающий соединение с ODBC драйвером.

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

Определение профилей

Определение профиля включает следующие его
элементы:

сжатое определение области действия функции,
для которой определяется профиль;

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

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

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

раздел, определяющий требования на соответствие данному профилю
реализующих его ИТ-систем;

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

информативные ссылки на любые полезные документы.

Определения

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

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

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

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

ISP (International Standardized Profile - Международный
стандартизованный профиль). Согласованный на международном уровне
официальный документ, описывающий один или несколько профилей.

Таксономия (Taxonomy) - классификационная схема,
применяемая для однозначной индентификации профилей или наборов
профилей.

OSE (Open Systems Environment - Окружение открытых
систем).

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

SE-профиль. Профиль, который специфицирует все
поведение ИТ-системы или часть ее поведения на одном или большем
числе интерфейсов OSE.

OSI-профиль - конкретный профиль, составленный
из базовых стандартов, соответствующих модели OSI, и/или базовых
стандартов представления форматов и данных (т.е.
F - профилей).

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

Интероперабельность (interoperability) - возможность
совместного использования информации и ресурсов компонентами распределенной
системы.

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

Прикладное ПО (Aplication Software - Прикладное
программное обеспечение). Программное обеспечение - специфическое
для некоторого приложения и состоящее из программ, данных и документации.

Прикладная платформа (Aplication Platform). Набор
программно-аппаратных ресурсов, необходимых для поддержки услуг,
предоставляемых для выполнения прикладного ПО.

API-интерфейс (Application Program Interface
- Интерфейс прикладной программы). Интерфейс между прикладным
ПО и прикладной платформой, через который обеспечиваются все услуги.

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

HCI-интерфейс (Human/Computer Interface - Человеко-машинный
интерфейс). Граница, через которую имеет место физическое взаимодействие
между человеком и прикладной платформой.

ISI-интерфейс (Information Services Interface
- Интерфейс информационных услуг). Граница, через которую обеспечивается
сервис внешнего хранилища данных

Опыт разработки переносимой банковской

А.Федоров, Национальный банк Республики Татарстан
Во втором полугодии в Национальном Банке Республики Татарстан была поставлена работа по
созданию подсистемы денежного обращения интегрированной информационной системы (ИИС) с
применением методологии и комплекса инструментальных средств, предлагаемых "Аргуссофт
Компани". Комплекс включал CASE-средство SILVERRUN, язык четвертого поколения JAM6 и
JAM/TPi для программирования сервера приложений, монитор транзакций TUXEDO, средство
конфигурационного управления PVCS и работы с различными СУБД Q+E (новое названия
DataDirect).

Основной целью этих работ было создание подсистемы. Однако на этом проекте Центральный
Банк РФ проводил обработку составных частей своего регионального проекта, как переносимых
на достаточно широкий круг аппаратно-программных платформ (HP UX, Solaris, SCO Unix) и
реляционных СУБД (Oracle, Informix).

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

Адаптивность к изменениям административной структуры;

Наращивание выполняемых функций;

Быстрая настройка ИИС на конкретных пользователей;

Возможность получать любые информационные услуги с любых
терминалов, обслуживаемых ИИС, в пределах их полномочий;

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

Подсистема денежного обращения проектировалась нами как составная часть интегрированной
информационной системы НБ РТ.

Подсистема ОДО включает в себя следующие АРМы:

Составление отчетов по кассовым оборотам;

Анализ выполнения прогноза кассовых оборотов;

Контроль за выдачей средств на потребление;

Составление и анализ выполнения кассового плана;

Анализ сведений о просроченной задолженности по выдаче зарплаты;

Анализ сведений о состоянии лимитов остатка касс;

Анализ состояния и объема денежной массы в обороте;

Учет и анализ эмиссионно-кассовых операций;

АРМ администратора интегрированной информационной системы
(ИИС).
Для построения проектирования подсистемы денежного обращения было использовано CASE-
средство SILVERRUN фирмы CSA.

При выборе CASE-средства в ходе обследования ГУ НБ РТ год назад мы остановились на CASE-
Аналитике фирмы Эйтекс, который выгодно отличался от других аналогичных средств (доступных
для нас) дешевизной, простотой использования, наиболее подходящей нотацией Gane/Sarson.

В процессе работы над системой диаграмм бизнес-модели ГУ выявился ряд недостатков CASE-
Аналитика, поэтому нам стало ясно, что дальнейшее использование СASE-Аналитика в
проектировании интегрированной информационной системы ГУ проблематично. Какие это
недостатки:

очень бедные возможности импорта/экспорта (следовательно, не
возможна коллективная разработка модели),

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

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

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

компонента ERX (Entity Relationship Expert) помогает построить
концептуальную модель данных проекта;

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

компонента WRM (Workgroup Repository Manager) управляет общим для
всех компонент репозиторием для хранения и совместного использования
типов данных, доменов, структур данных;

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


модели Главного Управления НБ РТ были переведены нами в среду Silverrun. Максимально полно
проработана модель подсистемы ОДО как составной части ИИС.

Построена система диаграмм информационных потоков для этих подсистем с помощью
BPM-компоненты Silverrun. На дереве процессов показана иерархическая структура процессов
системы. В модели выделено 84 процесса, 9 внешних сущностей, 24 накопителя данных.
Определены: 26 базисных типов данных, 26 доменов, 54 структуры данных, информационные
потоки связаны со структурами данных и квалификаторами, построены описания всех детальных
процессов. С помощью средств документирования проекта, предоставляемых Silverrun, были
получены описания компонент диаграмм и потоков данных.

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

определено 9 основных таблиц:

определено 45 подсхем с подчиненными таблицами, выделенными в
соответствии с подпроцессами 1-го уровня DFD-диаграммы;

выделены уникальные ключи , определены отношения между таблицами;

проведена верификация модели;

сгенерированы внешние ключи подчиненных таблиц;

сформирован SQL-код для Oracle;

проведена портация модели на платформу Informix;

средствами Silverrun получена документация по сформированной
базе.

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

универсальной оболочки конфигурирования АРМов;

отдельных функциональных модулей;

оболочки администратора;

действующего макета подсистемы денежного обращения.
Основным средством разработки программного обеспечения подсистемы денежного обращения
был язык четвертого поколения JAM фирмы JYACC. JAM включает в себя следующие основные
компоненты:

экранный редактор - среду разработки экранов;

редактор меню;

отладчик;

генератор отчетов;

макетную СУБД JDB;

модули интерфейса с конкретными СУБД (ORACLE, INFORMIX);

JAM/TPI - средство программирования сервисов TUXEDO;
Для хранения описаний информационных объектов и реализации механизма наследования
используется репозиторий.

Помимо средств визуального программирования JAM имеет встроенный процедурный язык
интерпретирующего типа JPL с С-образным синтаксисом.

Разработка программного обеспечения подсистемы денежного обращения началась с переноса
функционально-логической модели из SILVERRUN в среду визуальной разработки прикладного
программного обеспечения JAM. На этой стадии были выполнены следующие работы:

Перенос схемы базы данных для СУБД ORACLE в макетную СУБД
JDB. JDB-это встроенная в среду разработки JAM СУБД с SQL языком, которая
позволяет выполнять прототипирование и тестирование приложений,
реализованных на JAM до создания реальной базы данных в СУБД ORACLE
или INFORMIX;

Формирование репозитория подсистемы денежного обращения в среде
JAM. Репозиторий первоначально формируется из схемы базы данных при
помощи операции IMPORT. При этом объекты, хранящиеся в репозитории
наследуют свойства объектов из базы данных. Затем производится
редактирование входов репозитория (вводятся русские наименования данных,
шаблоны внешнего представления данных, объекты управления приложениями
и т.д.;
Затем были выполнены следующие подготовительные работы:

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

Разработана библиотека типовых программных модулей на языке JPL. JPL
- это процедурный язык интерпретирующего типа, встроенный в среду


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

Средства регистрации пользователей ИИС НБ РТ;

Средства описания типовых программных комплексов;

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

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

Прикладное программное обеспечение подсистемы денежного обращения разрабатывалось
средствами JAM 6.10. Важным преимуществом данного инструментального комплекса и JAM в
частности является возможность проведения разработки по спиральному циклу с построением
прототипов в конце каждого цикла. В нашем случае первым действующим прототипом системы
являлось описание АРМов средствами АРМ администратора, в результате чего пользователь видел
функции АРМов в виде меню верхнего уровня до начала программирования. Затем средствами
JAM осуществлялось прототипирование экранов и, наконец двухзвенная реализация ряда
приложений служила прототипом для реализации трехзвенного варианта.

Коллективная разработка осуществлялась с использованием общего репозитория проекта и
средства управления версиями PVCS Version Manager фирмы INTERSOLV. Средствами PVCS
осуществлялось управление изменениями прикладных экранов и входов репозитория, а также
контроль состояния разработки. Важным преимущество JAM является интеграция PVCS Version
Manager со средой разработки JAM.;

Ряд приложений в подсистеме денежного обращения был реализован по трехзвенной архитектуре с
применением монитора транзакций TUXEDO и компоненты JAM/TPi. Как показал опыт данной
разработки реализация по трехзвенной архитектуре резко увеличивает эффективность приложений
расчетного характера с большим количеством обращений к базе данных. При этом нами
использовался подход при котором приложение вначале прототипировалось и тестировалось в
двухзвенном варианте, а затем путем анализа SQL-кода определялись сервисы и соответствующие
им сервисные экраны, а также параметры сервисов. Затем вызов SQL в клиентских экранах
заменялся на вызов соответствующих сервисов, а из исходного экрана формировались сервисные
экраны. По окончании данной работы сервисные экраны и файл описания сервисов переносились
на сервисную машину.

Необходимо отметить развитые средства отладки JAM, которые позволяли достаточно
качественно тестировать разрабатываемые приложения. Для анализа содержимого баз данных
нами использовалась средство Q+E.

В ходе разработки было запрограммировано более 160 экранов и отчетов на языке JAM и
средствами АРМа администратора ИИС сконфигурированы 8 АРМов подсистемы денежного
обращения.

Разработка проводилась 3,5 месяца коллективом в 3 человека. Разработка завершилась созданием
подсистемы ОДО и комплекта документации из 14 книг общим объемом 450 страниц.

В ходе работ основная часть системы разработана в среде HP UX, а отдельные компоненты,
особенно для трехзвенной архитектуры клиент-сервер - в среде Solaris. По завершении разработки
подсистемы ОДО, функционировавшей в среде HP UX - Oracle, проведен ее перенос в среду SCO


UNIX - Informix, включая базу данных, наполненную реальной информацией (с русскими
буквами). Объем базы составлял около 1,5 Мб. Перенос осуществлялся в следующем порядке:

осуществлен реинжиниринг базы данных, организованной в СУБД
Oracle, с помощью модуля SILVERRUN-RDM и моста к Oracle с получением ER-
модели;

по полученной ER-модели проведена генерация базы данных для Среды
Informix с помощью SILVERRUN-RDM и моста к Informix;

проведен перенос данных из Oracle в Informix с помощью Q+E.
Общее время переноса составило менее часа.

В заключение доклада приведу выводы об эффективности данного комплекса инструментальных
средств. Данный комплекс действительно обеспечивает разработку портируемых приложений как
по двухзвенной, так и по трехзвенной схеме. Все средства достаточно просты в освоении.
Разработка приложений средствами JAM осуществлялась достаточно быстро, причем
разработчики не имели большого опыта работы с ним. Необходимо отметить, что в настоящее
время фирма Аргуссофт поставила нам новую версию JAM-7, которая содержит генератор
типовых экранов. Его использование повышает производительность программирования в
несколько раз. Использование механизма наследования JAM позволяет резко снизить
трудоемкость внесения изменений при сопровождении.

[]
[]
[]

Организация ITU-T

(International Telecommunication Union-Telecommunications
Международный союз по телекоммуникации-телекоммуникация)

ITU-T несет ответственность за разработку и согласование
Рекомедаций, которые обеспечивают интероперабельность телекоммуникационного
сервиса в глобальном масштабе, в частности, сервиса, связанного
с передачей данных, интегрированного телекоммуникационного сервиса
для голоса и данных; сервиса передачи сообщений и справочной службы
(стандартов OSI и ODP).

Основные исследовательские группы (Study Groups -
SGs):

ITU-T

SG7 Сети передачи данных

SG8 Терминалы для услуг телематики

SG10 Языки для телекоммуникации

Имеется тесное сотрудничество между JTC1 и ITU-T.
Основной формой сотрудничества является соглашение об общем тексте
для стандартов ISO/IEC (т.е. JTC1) и рекомендаций и ITU-T/CCITT,
относящихся к одним и тем же аспектам в областях OSI и ODP.

Организация ввода/вывода

Шины:

шины процессор-память

шины ввода/вывода

Основные возможности шин

Возможность	Высокая производительность	Низкая стоимость
Общая разрядность шины	Отдельные линии адреса и данных	Мультиплексирование линий адреса и данных
Ширина (рязрядность) данных	Чем шире, тем быстрее (например, 32 бит)	Чем уже, тем дешевле (например, 8 бит)
Размер пересылки	Пересылка нескольких слов имеет меньшие накладные расходы	Пересылка одного слова дешевле
Главные устройства шины	Несколько (требуется арбитраж)	Одно (арбитраж не нужен)
Расщепленные транзакции?	Да - отдельные пакеты Запроса и Ответа дают большую полосу пропускания (нужно несколько главных устройств)	Нет - продолжающееся соединение дешевле и имеет меньшую задержку
Тип синхронизации	Синхронные	Асинхронные

Организационная структура в области стандартизации ИТ

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

а) Международные организации, входящие в структуру
ООН;

ISO (International Organization for Standardization
- Международная организация по стандартизации);

IEC (International Electrotechnical Commision
- Международная электротехническая комиссия);

ITU-T (International Telecommunication Union-Telecommunications
- Международный союз по телекоммуникации - телекоммуникация).
До 1993г. эта организация имела другое название - CCITT (International
Telegraph and Telephone Consultative Committee - Международный
консультативный комитет по телефонии и телеграфии или, сокращенно,
МККТТ). X.200, X-400, X-500, X-600.

б) Промышленные профессиональные или административные
организации;

IEEE (Institute of Electrical and Electronic
Engineers - Институт инженеров по электротехнике и электронике)
LAN IEEE802, POSIX

Internet и IAB (Internet Activities Board - Совет
управления деятельностью Internet) TCP/IP

Regional WOS (Workshops on Open Systems - Рабочие
группы по открытым системам). OSE-profiles

с) Промышленные консорциумы.

ECMA (European Computer Manufactureres Association
- Европейская ассоциация производителей вычислительных машин)
OSI, безопасность, управление, Office Document Architecture (ODE)

OMG (Object Management Group - Группа управления
объектами) RM: Common Object Request Broker Architecture (CORBA)

X/Open (Организована группой поставщиков компьютерной
техники) X/Open Portability Guide (XPG4) Common Application Environment

NMF (Network Management Forum - Форум управления
сетями)

OSF (Open Software Foundation - Основание открытого
программного обеспечения). Имеет следующие предложения:
OSF/1 (Соответствует стандарту POSIX и XPG4)
MOTIF - графический пользовательский интерфейс
(Distributed Computer Environment)
DCE - технология интеграции платформ: DEC, HP, SUN, MIT, Siemens,
Microsoft, Transarc
DME (Distributed Management Environment) ~=~ NMF

Международные организации по стандартизации, входящие в структуру ООН:

ISO (International Organization for Standartization: Международная
организация по стандартизации)

IEC
(International Electrotechnical Commision: Международная Электротехническая
Комиссия)

ITU-T
(International Telecommunications Union - Telecommunications:
Международный союз по телекоммуникации)

Промышленные, профессиональные или административные организации

IEEE (Institute of Electrical and Electronic Engineers: Институт инженеров
по электротехнике и электронике)

Internet и IAB (Internet Activities Board: Совет управления деятельностью Internet)

Regional WOS (Workshops on Open Systems: Рабочие группы по открытым системам)

Промышленные консорциумы

ECMA (European Computer Manufactures Assosiation: Европейская ассоциация производителей вычислительных машин)

OMG (Object Management Group: Группа управления объектами)

X/Open (Организован группой европейских поставщиков компьютерной техники)

NMF (Network Management Forum: Форум управления сетями)

OSF (Open Software Foundation: Фонд открытого программного обеспечения)

Основные архитектурные понятия

CISC - Complete
Instruction Set Computer (IBM/360, Intel x86)
RISC - Reduced
Instruction Set Computer (CDC 6600, Cray, IBM/801, RISC I/II,
MIPS)

упрощение и сокращение набора команд

отделение команд обработки от команд обращения к памяти

конвейерная обработка

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

увеличение размера регистрового файла

трехадресный формат команд

ориентация на статическую оптимизацию кода компилятором

Основные характеристики популярных шин

Шина IBM PC/XT:

8 бит данных, 20 бит адреса, 4 линии IRQ, 4 линии
запроса DMA

4.77 МГц, 4 Мбайт/с

Шина ISA (Industry Standard Architecture) -
IBM PC/AT:

16 бит данных, 24 бит адреса, 15 линий IRQ, 7
линий запроса DMA

8 МГц, 16 Мбайт/с

Шина EISA (Extended Industry Standard Architecture):

32 бит данных, 32 бит адреса

8 МГц, 32 Мбайт/с

Шина МСА (Micro Channel Architecture):

32 бит данных

10 МГц, 40 Мбайт/с

Шина VL-bus (VESA - Video Electronics Standard
Association):

32 бит данных

40 МГц, 130 Мбайт/с

Шина PCI (Peripheral Component Interconnect):

32 бит данных

33 МГц, 132 Мбайт/с
Шина SBus (IEEE - 1496):

32/64 бит

20/25 МГц, 80/100 Мбайт/с

Шина MBus

мультиплексирование адреса/данных:

64 бит данные

36 бит физического адреса

50 МГц, 400 Мбайт/с (125 Мбайт/с)

поддержка когерентного состояния кэш-памяти в микропроцессорной
системе

Шина XDBus:

расщепление транзакций

до 64 процессоров (SuperServer 6400 Cray Research)

50 МГц, 400 Мбайт/с (310 Мбайт/с)

Шина POWERpath-2 (Chellange - Silicon Graphics):

до 36 R4400

8-кратное расслоение ОЗУ (до 16 Гбайт)

256 бит данных, 40 бит адреса, 50 МГц

Шина SCSI (Small Computer System Interface):
1986 г. - SCSI-1
1992 г. - SCSI-2: fast mode, wide mode
SCSI-1: 8 бит, 5 Мбайт/с
Fast SCSI: 8 бит, 10 Мбайт/с
Wide SCSI: 16/32 бит, 10/20 Мбайт/с
Fast-and-Wide SCSI: 16/32 бит, 20/40 Мбайт/с

Основные характеристики рабочих станций компании SUN Microsystems

МОДЕЛЬ	SPARCstation 4	SPARCstation 5
ЦП
Тип процессора	microSPARC II	microSPARC II
Тактовая частота (МГц)	110	110
Число процессоров	1	1
Системная шина (бит)	64	64
Размер кэша (Кб) (в процессоре/на плате)	24	24
Пропускная способность системной шины (Мб/сек)	105	105
ПАМЯТЬ
Минимальный объем (Мб)	32	32
Максимальный объем (Мб)	160	256
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus
Количество слотов	1	3
Максимальная пропускная способность подсистемы в/в (Мб/сек)	52	52
Периферийные интерфейсы	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	1.05	1.05
Максимальная емкость дисковой памяти (Гб)	56	92
Количество последовательных портов	2	2
Количество параллельных портов	1	1
Сетевые интерфейсы основной/дополни-тельные	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring
ГРАФИЧЕСКАЯ ПОДСИСТЕМА	Color	Grayscale, Accelerated color (TGX, TGX+,SX,ZX)
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	78.6	78.6
SPECfp92	65.3	65.3
SPECbase_int92	68.7	68.7
SPECbase_fp92	63.0	63.0
SPECrate_int92	1864	1864
SPECrate_fp92	1549	1549
SPECrate_base_int92	1630	1630
SPECrate_base_fp92	1494	1494
MIPS	135.5	135.5
MFLOPS	21.7	21.7

МОДЕЛЬ	SPARCstation 20
	Model 71	Model 151	Model 712MP	Model 152MP	Model 514MP	Model HS14MP
ЦП
Тип процессора	SuperSPARCII	hyperSPARC	SuperSPARCII	hyperSPARC	SuperSPARC+	hyperSPARC
Тактовая частота (МГц)	75	150	75	150	50	100
Число процессоров	1	1	2	2	4	4
Системная шина (бит)	64	64	64	64	64	64
Размер кэша (Кб)	36/1024	8/512	36/1024	8/512	36/1024	8/256
(в процессоре/на плате)			/CPU	/CPU	/CPU	/CPU
Пропускная способность системной шины (Мб/сек)	105	105	105	105	105	105
ПАМЯТЬ
Минимальный объем (Мб)	32	32	64	64	64	64
Максимальный объем (Мб)	512	512	512	512	512	512
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus	Sbus	Sbus	Sbus	Sbus
Количество слотов	4	4	4	4	4	4
Максимальная пропускная способность подсистемы в/в (Мб/сек)	52	52	52	52	52	52
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	1.05	1.05	1.05	1.05	1.05	1.05
Максимальная емкость дисковой памяти (Гб)	353	353	353	353	353	353
Количество последовательных портов	2	2	2	2	2	2
Количество параллельных портов	1	1	1	1	1	1
Сетевые интерфейсы основной/дополнительные	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/ FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/ FDDI, Token Ring
ГРАФИЧЕСКАЯ ПОДСИСТЕМА	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)	Grayscale, Accelerated color (TGX, TGX+,SX,ZX)	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)	Grayscale, Accelerated color (TGX, TGX+,SX,ZX)	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)	Grayscale, Accelerated color (TGX, TGX+, SX,ZX)
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	125.8	169.4	-	-	-	-
SPECfp92	121.2	208.2	-	-	-	-
SPECbase_int92	116.4	157.4	-	-	-	-
SPECbase_fp92	109.4	188.2	-	-	-	-
SPECrate_int92	2984	4018	5726	7310	7072	8124
SPECrate_fp92	2875	4938	5439	8758	7341	8906
SPECrate_base_int92	2761	3734	5332	7004	6636	7699
SPECrate_base_fp92	2592	4464	4923	7945	6708	8328
MIPS	204.7	306.0	-	-	-	-
MFLOPS	44.4	62.8	-	-	-	-

<

МОДЕЛЬ	Ultra 1	Ultra 2
	Model 140	Model 170	Model 170E	Model 2200
ЦП
Тип процессора	UltraSPARC-1	UltraSPARC-1
Тактовая частота (МГц)	143	167	167	200
Число процессоров	1	1	1	2
Системная шина (бит)	128/256	128/256	128/256	128/512
Размер кэша (Кб)	16+16/512	16+16/512	16+16/512	16+16/1024
(в процессоре/на плате)				/CPU
Пропускная способность системной шины (Мб/сек)	1300	1300	1300	1300
ПАМЯТЬ
Минимальный объем (Мб)	32	32	32	64
Максимальный объем (Мб)	512	512	512	1024
ВВОД/ВЫВОД
Количество слотов	3 SBus (32/ 64бит,25МГц)	3 SBus (32/ 64бит,25МГц)	2 SBus (32/64бит,25МГц) 1 UPA,83МГц	4 SBus (32/64бит,25МГц) 1 UPA,100МГц
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	1.05	1.05	1.05	2.1
Максимальная емкость дисковой памяти (Гб)	147	147	147	273
Количество последовательных портов	2	2	2	2
Количество параллельных портов	1	1	1	1
Сетевые интерфейсы	10 Мбит/с	10 Мбит/с	10/100 Мбит/с	10/100 Мбит/с
основной/дополнительные	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring	Ethernet/FDDI, Token Ring
ГРАФИЧЕСКАЯ ПОДСИСТЕМА	TurboGX, TurboGXplus	TurboGX, TurboGXplus	Creator, Creator3D, Freedom	Creator, Creator3D
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	215	252	252	332
SPECfp92	303	351	351	505
SPECbase_int92	180	204	204	260
SPECbase_fp92	271	313	313	368
SPECrate_int92	5107	5982	5982	14962
SPECrate_fp92	7175	8323	8323	18675
SPECrate_base_int92	4267	4893	4893	11927
SPECrate_base_fp92	6428	7403	7403	17464
MIPS	291	341	341	414/CPU
MFLOPS	109	126	126	136/CPU

Основные характеристики серверов AlphaServer

Система/ Характеристики	AlphaServer 400	AlphaServer 1000	AlphaServer 2000	AlphaServer 2100	AlphaServer 8200	AlphaServer 8400
Частота	166 МГц	233 МГц	4/275:275 МГц 4/233:233 МГц	5/250:250 МГц 4/275:275 МГц 4/200:200 МГц	300 МГц	300 МГц
Число процессоров	1	1	1-2	1-4	1-6	1-12
Число транзакций в сек. (tpsA)	До 130	До 300	4/275: До 625 4/233: До 400	5/250: До 1200 4/275: До 850 4/200: До 675	Свыше 2000	Свыше 3000
Макс. память	192 Мб	512 Мб	4/275: 1 Гб 4/233:640 Мб	2 Гб	6 Гб	14 Гб
Память на диске	441 Гб	220 Гб	Свыше 500Гб	500 Гб	10 Тб	10 Тб
Поддержка ввода/ вывода	2 слота PCI 3 слота EISA 1 слот PCI/EISA	2 слота PCI 7 слотов EISA 1 слот PCI/EISA	3 слота PCI 7 слотов EISA	3 слота PCI 8 слотов EISA	108 слотов PCI 8 слотов EISA	144 слота PCI 8 слотов EISA
ECC память	Нет	Да	Да	Да	Да	Да
RAID	Да	Да	Да	Да	Да	Да
Авто-перезагрузка	Да	Да	Да	Да	Да	Да
Дублирование питания	Нет	Да	Да	Да	Да	Да
Управление температурой	Нет	Да	Да	Да	Да	Да

Максимальная емкость дисков включая RAID

МОДЕЛЬ	250	C10	C20	370	380	390	39H	570	580	58H	590	59H	990	R10	R20	R24
ЦП
Тип процессора	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER	POWER
	PC601	PC601	PC604		2	2	2			2	2	2	2		2	2
Тактовая частота (МГц)	66/80	80	120	62	59	66.7	66.7	50	62	55	66	66	71.5	50	66	71.5
Число процессоров	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1
Системная шина (бит)	64	64	64	64	64	64	128	64	128	256	256	128	256	64	128	128
Размер кэша
L1 (команды/данные) (Кб)	32	32	32/32	32/32	32/64	32/64	32/128	32/32	32/64	32/256	32/256	32/128	32/256	32/32	32/128	32/128
L2 (о-доп.возм.) (Мб)	-	1o	1	-	-	1o	2o	-	-	-	-	1	-	-	1	2
ПАМЯТЬ
Минимальный объем (Мб)	16	16	16	32	32	32	64	32	64	64	64	64	128	128	128	128
Максимальный объем (Мб)	256	256	256	512	512	512	512	1024	2048	2048	2048	2048	2048	1024	2048	2048
ВВОД/ВЫВОД
Количество слотов	2	3	4	4	4	4	4	8	7	7	7	7	15	8	8	15
Периферийные интерфейсы	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI	SCSI
Максимальная емкость внутренних дисков (Гб)	2	6	6	4	13.5	13.5	13.5	27	27	27	27	27	8	4	4	18
Максимальная емкость дисковой памяти (Гб)	30	70	70	274	279	279	279	499	499	499	499	499	953	476	476	476
Максимальная емкость дисков включая RAID (Гб)	194	294	294	331	336	336	336	613	613	613	613	613	1150	590	590	1160
ПРОИЗВОДИТЕЛЬНОСТЬ
SPECint92	78.8	90.5	90.5	70.3	99.3	114.3	130.2	57.5	73.3	97.6	121.6	122.4	131	57.5	122.4	134.1
SPECfp92	90.4	100.8	100.8	121.1	187.2	205.3	266.6	99.2	134.6	203.9	259.7	250.7	279	99.2	250.7	273.8
MFLOPS (Linpack DP)	15.1	20.3	22.7	25.9	49.7	55.1	-	22.2	38.1	101.1	131.1	132	141.6	22.2	132.0	141
tpmC	310	486	-	495	675	902	1000	395	510	600	726	1122	780	395	1122	1470
K$/tpmC	1.2	0.654	-			0.9		1.4			1.4	0.97				0.9
tpsA								128.5	157.2				275.7
K$/tpsA								8.5	9.2				7
SPECint_base95		2.37	3.85
SPECfp_base95		2.97	3.50

Основные характеристики серверов отделов компании SUN Microsystems

МОДЕЛЬ	SPARCserver 1000E	SPARCcenter 2000E
ЦП
Тип процессора	SuperSPARC
Тактовая частота (МГц)	85	85	85	85	85	85
Число процессоров	2	4	8	2	12	20
Системная шина (бит)	64	64	64	64	64	64
Размер кэша (Кб)	36/1024	36/1024	36/1024	36/2048	36/2048	36/2048
(в процессоре/на плате)	per CPU	per CPU	per CPU	per CPU	per CPU	per CPU
Пропускная способность системной шины (Мб/сек)	250	250	250	500	500	500
ПАМЯТЬ
Минимальный объем (Мб)	32	64	64	64	64	64
Максимальный объем (Мб)	2048	2048	2048	5120	5120	5120
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus	Sbus	Sbus	Sbus	Sbus
Количество слотов	3-12	3-12	3-12	4-40	4-40	4-40
Максимальная пропускная способность подсистемы в/в (Мб/сек)	90	90	90	180	180	180
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Стандартная емкость дисковой памяти (Мб)	1050, 2100	1050,2100	1050,2100	1050,2100	1050,2100	1050,2100
Максимальная емкость дисковой памяти (Гб)	764	764	764	4860	4860	4860
Количество последовательных портов	2-8	2-8	2-8	2-10	2-10	2-10
Сетевые интерфейсы основной/дополнительные	Ethernet, FDDI,ATM, TokenRing, FastEthernet	Ethernet, FDDI,ATM, TokenRing, FastEthernet
ПРОИЗВОДИТЕЛЬНОСТЬ
Транзакция/сек	-	-	10400	-	-	27440
NFS op/sec	-	-	3950	1750	5950	6700
SPECrate_int92	5988	11508	21758	6546	35332	57997
SPECrate_fp92	5805	11322	20851	6284	35948	54206
SPECrate_base_int92	5480	10557	20225	5875	33067	53714
SPECrate_base_fp92	5232	9943	18741	5742	32531	51489
AIM III (job/minute/)	2037/	3654/	6062/	2237/	9637/	12104/
users	1849	3327	5386	2028	8004	9436

МОДЕЛЬ	Enterprise 3000	Enterprise 4000
ЦП
Тип процессора	UltraSPARC
Тактовая частота (МГц)	167	167	167	167	167	167
Число процессоров	2	4	6	8	10	12
Размер кэша (Кб)	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512
(в процессоре/на плате)	per CPU	per CPU	per CPU	per CPU	per CPU	per CPU
Пропускная способность системной шины (Гб/сек)	2.5	2.5	2.5	2.5	2.5	2.5
ПАМЯТЬ
Минимальный объем (Мб)	64	64	64	64	64	64
Максимальный объем (Гб)	6	6	6	12	12	12
ВВОД/ВЫВОД
Количество слотов	3-9SBus	3-9SBus	3-9SBus	3-21SBus	3-21SBus	3-21SBus
Максимальная пропускная способность платы в/в (Мб/сек)	200	200	200	200	200	200
Периферийные интерфейсы	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2
Максимальная емкость внутренних дисков (Гб)	42	42	42	16.8	16.8	16.8
Максимальная емкость дисковой памяти (Тб)	2+	2+	2+	4+	4+	4+
Сетевые интерфейсы основной/дополнительные		10/100Мб/с, FDDI, ATM, TokenRing	Ethernet		10/100Мб/с, FDDI, ATM, TokenRing	Ethernet
ПРОИЗВОДИТЕЛЬНОСТЬ
TPC-C	-	-	-	-	-	11466
$/tpmC	-	-	-	-	-	189
NFS op/sec	3629	6113	8103	10151	12031	13536
SPECrate_int92	11550	22850	34817	44670	55140	65327
SPECrate_fp92	16170	31920	46309	62370	77190	91702
AIM III (job/minute/)	2982/	6090/	9280/	12180/	14790/	18560/
users	2632	5022	7440	9176	10666	11453

Основные характеристики серверов предприятий компании SUN Microsystems

МОДЕЛЬ	Enterprise 5000	Enterprise 6000
ЦП
Тип процессора	UltraSPARC
Тактовая частота (МГц)	167	167	167	167	167	167
Число процессоров	8	10	12	10	16	24
Размер кэша (Кб)	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512	16+16/512
(в процессоре/на плате)	per CPU	per CPU	per CPU	per CPU	per CPU	per CPU
Пропускная способность системной шины (Гб/сек)	2.5	2.5	2.5	2.5	2.5	2.5
ПАМЯТЬ
Минимальный объем (Мб)	64	64	64	64	64	64
Максимальный объем (Гб)	14	14	14	30	30	30
ВВОД/ВЫВОД
Количество слотов	3-21SBus	3-21SBus	3-21SBus	3-45SBus	3-45SBus	3-45SBus
Максимальная пропускная способность платы в/в (Мб/сек)	200	200	200	200	200	200
Периферийные интерфейсы	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2	F&WSCSI2
Максимальная емкость внутренних дисков (Гб)	216	216	216	162	162	162
Максимальная емкость дисковой памяти (Тб)	6+	6+	6+	10+	10+	10+
Сетевые интерфейсы основной/дополнительные		10/100Мб/с FDDI, ATM, TokenRing	Ethernet		10/100Мб/с FDDI, ATM, TokenRing	Ethernet
ПРОИЗВОДИТЕЛЬНОСТЬ
TPC-C	-	-	11466	-	-	17000
$/tpmC	-	-	191	-	-	-
NFS op/sec	10151	12031	13536	-	17771	21014
SPECrate_int92	44670	55140	65327	55140	86520	127913
SPECrate_fp92	62370	77190	91702	77190	118120	165385
AIM III (job/minute/)	12180/	14790/	18560/	-	23200/	33640/
users	9176	10666	11453	-	15000	15000

Основные характеристики серверов рабочих групп компании SUN Microsystems

МОДЕЛЬ	SPARCserver 5	SPARCserver 20
	Model 110	Model 71	Model712MP	Model151	Model152MP
ЦП
Тип процессора	microSPARC II	SuperSPARC-II		hyperSPARC
Тактовая частота (МГц)	110	75	75	150	150
Число процессоров	1	1	2	1	2
Системная шина (бит)	64	64	64	64	64
Размер кэша (Кб)	24	36/1024	36/1024	8/512	8/512
(в процессоре/на плате)			per CPU	per CPU	per CPU
Пропускная способность системной шины (Мб/сек)	105	105	105	105	105
ПАМЯТЬ
Минимальный объем (Мб)	32	32	64	64	64
Максимальный объем (Мб)	256	512	512	512	512
ВВОД/ВЫВОД
Тип шины	Sbus	Sbus	Sbus	Sbus	Sbus
Количество слотов	3	4	4	4	4
Максимальная пропускная способность подсистемы в/в (Мб/сек)	52	52	52	52	52
Периферийные интерфейсы	SCSI-2	SCSI-2	SCSI-2	SCSI-2	SCSI-2
Минимальная емкость дисковой памяти (Гб)	4.2	4.2	4.2	4.2	4.2
Максимальная емкость дисковой памяти (Гб)	118	339	339	339	339
Количество последовательных портов	2	2	2	2	2
Количество параллельных портов	1	1	1	1	1
Сетевые интерфейсы основной/дополнительные	Ethernet/FDDI, ATM, Token Ring, FastEthernet	Ethernet FDDI, ATM, Token Ring, FastEthernet	Ethernet/ FDDI, ATM, Token Ring, FastEthernet	Ethernet/ FDDI, ATM, Token Ring, FastEthernet	Ethernet/ FDDI, ATM, Token Ring, FastEthernet
ПРОИЗВОДИТЕЛЬНОСТЬ
Транзакция/сек	145	200	305	240	315
SPECrate_int92	1864	2984	5726	4018	7310
SPECrate_fp92	1549	2875	5439	4938	8758
SPECrate_base_int92	1630	2761	5332	3734	7004
SPECrate_base_fp92	1494	2595	4923	4464	7945

МОДЕЛЬ	Model 140	Ultra Enterprise 1 Model 170	Model 170E	Ultra Enterprise 150	Model 1170
ЦП
Тип процессора					UltraSPARC-1
Тактовая частота (МГц)	143	167	167	167	167	167	200	200
Число процессоров	1	1	1	1	1	2	1	2
Системная шина (бит)	128/256	128/256	128/256	128/512	128/512	128/512	128/512	128/512
Размер кэша (Кб) (в процессоре/на плате)	16+16/512 per CPU	16+16/512 per CPU	15+16/512 per CPU	16+16/512 per CPU	16+16/512 per CPU	16+16/512 per CPU	16+16/1024	16+16/1024
Пропускная способность системной шины (Мб/сек)	1300	1300	1300	1300	1300	1300	1300	1300
ПАМЯТЬ
Минимальный объем (Мб)	32	32	32	32	64	64	64	64
Максимальный объем (Мб)	1024	1024	1024	1024	2048	2048	2048	2048
ВВОД/ВЫВОД
Количество слотов	3 SBus	3 SBus	2 SBus 1 UPA	2 SBus	4 SBus 1 UPA	4 SBus 1 UPA	4 SBus 1 UPA	4 SBus 1 UPA
Периферийные интерфейсы	Fast SCSI-2	Fast SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2	F&W SCSI-2
Минимальная емкость дисковой памяти (Гб)	4.2	4.2	4.2	4.2	4.2	4.2	4.2	4.2
Максимальная емкость дисковой памяти (Гб)	324	324	324	324	1024	1024	1024	1024
Количество последовательных портов	2	2	2	2	2	2	2	2
Количество параллельных портов	1	1	1	1	1	1	1	1
Сетевые интерфейсы основной/дополнительные	10Мбит/с Ethernet/ FDDI, ATM, Token Ring	10Мбит/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring	10/100Мб/с Ethernet/ FDDI, ATM, Token Ring
ПРОИЗВОДИТЕЛЬНОСТЬ
Транзакция/сек	1250	1332	1332	1332	1350	2350	1500	2750
SPECint92	215	252	252	252	252	252	332	332
SPECfp92	303	351	351	351	351	351	505	505
SPECrate_int92	5107	5982	5982	5982	-	-	-	14962
SPECrate_fp92	7175	8323	8323	8323	-	-	-	18675
AIM 3	1305	1450	1450	-	-	-	-	-
Laddis	1812	2102	2102	-	2102	2536	2565	4303

Основные особенности итологии

Предметом итологии являются ИТ, представляемые
в двух видах:

в формальном, в виде спецификаций ИТ;

в виде ИТ-систем, т.е. реализаций спецификаций
ИТ.

Предметом итологии являются динамические развиваемые
сущности.

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

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

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

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

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

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

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

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

Является правопреемницей математики как инструмент
формализации знаний.

Основные свойства Rational Rose

охват всех этапов разработки проекта;

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

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

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

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

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

автоматическая генерация кодов на языках С++, Ada (компиляторы
поставляются), Smalltalk, SQLWindows, VisualBasic, PowerBuilder;

наличие средств групповой разработки;

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

PA-RISC (Precision Architecture)

Этапы развития архитектуры PA-RISC:

1986 г.	PA - RISC 1.1
1992 г.	РА - 7100, 33, 50, 99 МГц
1993 г.	РА - 7100 LC, 64, 80, 100 МГц
1994 г.	РА - 7150, 125 МГЦ
	РА - 7200, 90, 100 МГц
1996 г.	РА - 8000, 200 МГц
1998 г.	? VLIW-архитектура совместно с Intel

Блок-схема процессора PA 7100

Параллелизм на уровне выполнения

CPI конвейера = CPI идеального
конвейера +
+ Приостановки
из-за структурных конфликтов +
+ Приостановки
из-за конфликтов типа RAW +
+ Приостановки
из-за конфликтов типа WAR +
+ Приостановки
из-за конфликтов типа WAW +
+ Приостановки
из-за конфликтов по управлению

Метод	Снижает
Разворачивание циклов	Приостановки по управлению
Базовое планирование конвейера	Приостановки RAW
Динамической планирование с централизованной схемой управления	Приостановки RAW
Динамическое планирование с переименованием регистров	Приостановки WAR и WAW
Динамическое прогнозирование переходов	Приостановки по управлению
Выдача нескольких команд в одном такте	Идеальный CPI
Анализ зависимостей компилятором	Идеальный CPI и приостановки по данным
Программная конвейеризация и планирование трасс	Идеальный CPI и приостановки по данным
Выполнение по предположению	Все приостановки по данным и управлению
Динамическое устранение неоднозначности памяти	Приостановки RAW, связанные с памятью

Планирование загрузки конвейера:

Команда, вырабатыва-ющая результат	Команда, использующая результат	Задержка в тактах
Операция АЛУ с ПТ	Другая операция АЛУ с ПТ	3
Операция АЛУ с ПТ	Запись двойного слова	2
Загрузка двойного слова	Другая операция АЛУ с ПТ	1
Загрузка двойного слова	Запись двойного слова	0

Loop: LD F0,0(R1)
;F0=элемент вектора

ADDD F4,F0,F2
;добавляет скаляр из F2

SD 0(R1),F4
;запись результата

SUBI R1,R1,#8
;пересчитать указатель

;8 байт (в двойном слове)

BNEZ R1, Loop
;переход R1!=нулю
Цикл без планирования загрузки конвейера:

Такт
выдачи

Loop: LD F0,0(R1)
1

приостановка
2

ADDD F4,F0,F2
3

приостановка
4

приостановка
5

SD 0(R1),F4
6

SUBI R1,R1,#8
7

BNEZ R1,Loop
8

приостановка
9

Скорость работы цикла: 9 тактов на элемент
Оптимизированный цикл:

Loop: LD F0,0(R1) 1

приостановка
2

ADDD F4,F0,F2
3

SUBI R1,R1,#8
4

BNEZ R1,Loop ;задержанный
переход 5

SD 8(R1),F4 ;команда
изменяется, когда 6

;меняется
местами с командой SUB1

Скорость работы цикла: 6 тактов на элемент
Развернутый 4 раза цикл без оптимизации:

Loop: LD F0,0(R1)

ADDD F4,F0,F2

SD 0(R1),F4
;выбрасывается SUB1 и BNEZ

LD F6,-8(R1)

ADDD F8,F6,F2

SD -8(R1),F8
;выбрасывается SUB1 и BNEZ

LD F10,-16(R1)

ADDD F12,F10,F2

SD -16(R1),F12
;выбрасывается SUB1 и BNEZ

LD F14,-24(R1)

ADDD F16,F14,F2

SD -24(R1),F16

SUB1 R1,R1,#32

BNEZ R1, Loop

Скорость работы цикла: 6.8 такта на элемент
Развернутый 4 раза цикл после оптимизации:

Loop: LD F0,0(R1)

LD F6,-8(R1)

LD F10,-16(R1)

LD F14,-24(R1)

ADDD F4,F0,F2

ADDD F8,F6,F2

ADDD F12,F10,F2

ADDD F16,F14,F2

SD 0(R1),F4

SD -8(R1),F8

SD -16(R1),F12

SUB1 R1,R1,#32

BNEZ R1, Loop

SD 8(R1),F16
; 8 - 32 = -24

Скорость работы цикла: 3.5 такта на элемент

Передача данных от пользователя к обработчику

Передача данных от удаленного пользователя системы к программе обработчику идет через сеть
Internet на основе интерфейса Windows CGI. Все данные введенные пользователем вначале
передаются WWW серверу, который преобразует их к формату, отвечающему требованиям
стандарта CGI, и передает их программе обработчику, названному выше клиентским
приложением, Данные от удаленного клиента к WWW серверу поступают на основе протокола
HTTP (Hypertext Transfer Protoсol).

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

Информация о клиенте, Она включает в себя такие данные как URL адрес удаленного
клиента, его средство навигации по Internet, операционную систему, метод доступа, используемый
клиентом, регистрационные данные пользователя и прочую подобную информацию. Данные
такого рода используются обработчиком для настройки на конкретного клиента.

Информация введенная пользователем в HTML документ. Для осуществления ввода данных в
HTML документы, для их последующей передачи WWW серверу используется язык HTML второго
уровня, который допускает размещение в документе стандартных объектов диалога. Для этого в
HTML второго уровня используется тэг FORM, внутри которого и размещаются тэги,
соответствующие объектам диалога. Для передачи введенных данных HTML предусматривает
использование одного из двух основных методов передачи: GET и POST. Взаимодействие с
использованием метода GET происходит гораздо быстрее, но этот метод в соответствии со
стандартом CGI рекомендуется использовать только, если в результате обработки данных не
произойдет никаких изменений в окружающем мире. В соответствии со стандартом CGI при
использовании метода GET данные введенные пользователем, помещаются в переменную
окружения QUERY_STRING в виде поле1=значение1 & поле2=значение2... с заменой пробелов на
символ '+', а специальных символов на их коды. При использовании метода POST
преобразованные, как и при использовании метода POST, данные поступают в стандартный поток
ввода обработчика. Стандарт Windows CGI при использовании обоих методов помещает значение
переменной QUERY_STRING в раздел [CGI] файла данных, а при использовании метода POST
WWW сервер еще и декодирует строку - значение этой переменной и помещает пары поле-значение
в раздел [Form Literal файла данных, а при необходимости, также и в разделы [Form External] и
[Form Huge].

Переработка результатов SQL запроса и передача их пользователю

Данные получаемые клиентским приложением от серверного приложения подвергаются
дальнейшей обработке. Так как удаленный клиент системы использует одно из средств навигации
по Internet, и согласно стандарту Windows CGI, WWW серверу должен быть передан документ
одного из MIME типов. Исходя из того, что передаваемые данные представляют собой строки
символов , и необходимости разбиения результатов для удобства их анализа на несколько файлов,
для возвращаемых документов был выбран MIME тип "text/html".

Клиентское приложение получает данные от серверного приложения в виде записей, разделенных
символом STRUCTDELIMITER. Поля записи разделены символом FIELDDELIMITER.
Клиентское приложение получает из файла данных CGI имя и путь доступа к файлу, который
должен быть передан WWW серверу, создает этот файл и записывает в него строку,
идентифицирующую MIME тип документа: Content-type text/html. Далее полученную первую
порцию данных от серверного приложения клиентское приложение после декодировки записей и
полей записывает в созданный файл. Клиентское приложение, анализируя полученный от
серверного приложения признак, получает информацию о наличии дополнительной группы
данных, Если серверное приложение готово передать следующую часть данных, то клиентское
приложение создает временный файл и помещает в первый файл после данных ссылку на
созданный файл, то есть указывая его URL. Затем клиентское приложение получает от серверного
приложения и записывает в файл следующую порцию данных. Эти операции, включая создание
очередных файлов, повторяются пока серверное приложение передает результирующее множество
клиентскому приложению. В результате этого создается цепочка HTML файлов, которые
удаленный пользователь может последовательно просматривать с помощью своего средства
навигации по Internet ( Netscape, Microsoft Internet Explorer и т.д.), Просмотр цепочки документов
в прямом направлении обеспечивается наличием встроенных в документы ссылок на следующий
документ, а просмотр в обратном направлении поддерживается встроенной в навигаторы
возможностью отката к предыдущему документу.

Перспективы использования Delphi

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

В рамках новой инициативы Golden Gate, Borland объединяет уже имеющиеся технологии с
достижениями Open Environment Corporation - OEC (приобретена компанией Borland) в области
средств для построения многоуровневых, распределенных систем. Продукт OEC OLEnterprise
обеспечивает распределенные вычисления на базе технологий OLE automation / RPC (Remote
Procedure Call) поверх D-COM и в отсутствии такового на всех платформах Windows (в том числе
Win16). Полная автоматизация импорта/экспорта объектов в сети позволяет избежать
необходимости изменения кода приложений для их взаимодействия на разных участках сети.

В силу того, что Delphi полностью поддерживает OLE-automation и предоставляет
высокоуровневые средства работы с этими механизмами (специализированные классы, эксперты,
языковые расширения), вариант совместного использования Delphi & OLEnterprise может оказать
решающее воздействие на архитектуру системы => распределенные вычисления и локальные
рабочие места - все в одном коде.


OEC Architecture

Так как Delphi обеспечивает создание "чистого" (native) кода посредством компиляции (например
в самодостаточную - без интерпретатора - динамическую библиотеку DLL), возможна тонкая
интеграция полученных программных модулей не только с 3-ми клиентскими приложениями но и с
серверами приложений и баз данных на платформах Windows (в большей степени Windows NT, как
следствие ее приспособленности для поддержки серверных звеньев). В качестве примера можно
привести построение определяемых пользователем функций UDF для серверов БД Borland
InterBase (например, для специфической обработки BLOB-полей).

Главной целью Golden Gate является объединение лучших черт архитектуры клиент/сервер и

модели intranet. И первым этапом ее реализации является добавление средств интеграции с
Internet-технологиями в уже имеющиеся средства разработки. Delphi не является исключением.
Выпущенная летом 1996 года обновленная версия Delphi 2.01 включает поддержку модулей
сопряжения с Internet для Windows 95/NT - WinINET; возможность построения блоков расширения
Microsoft Information Server через интерфейсы ISAPI & ISAPI Filter; 8 элементов ActiveX,
полностью реализующих логику поддержки основных Internet-протоколов и HTML (обработка +
отображение => построение броузеров) в виде повторно используемых компонентов.


ActiveX

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


Golden Gate


Delphi 2.0

Software Digest March 1996, NSTL

Client-Server Development Tools
RatingProductPerformanceVersatilityEase of Use"Delphi's performance is head and shoulders above all of its competitors"

****	Delphi	9.6	9.2	7.3
***	Visual Basic	8.3	8.2	6.9
**	SQL Windows	5.2	9.1	6.7
**	Power Builder	5.4	7.8	6.8

[]
[]
[]

Поддержка разнообразных клиентов

Клиентская часть включена в поставку

MS-DOS, Windows, Windows for Workgroups, Windows 95, OS/2, Macintosh, Netware, UNIX

Windows NT Workstation - защищенный клиент

Пользователи и группы

Учетные записи: локальные и глобальные

Встроенные учетные записи

Группы: локальные и глобальные

Встроенные группы

Пользовательские профили

Сценарии регистрации в сети

Использование домашнего каталога

Потоки (streams)

UNIX System V

библиотека TLI (Transport Layer Interface)

транспортный сервис на основе стека протоколов TCP/IP

Позволяют организовывать разнообразные виды коммуникации
процессов
Многообразие и сложность набора функций библиотеки
TLI
Относится к теме реализаций семиуровневой модели
ISO/OSI

Потребности применений

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

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

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

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

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

Миграция унаследованных систем. Любая система после создания противодействует изменениям и
имеет тенденцию быстрого превращения в бремя организации (т.н. legacy systems - унаследованные
системы, использующие "уставшие" технологии, архитектуры, платформы, а также собственно

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

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

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

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

Архитектура промежуточного слоя (middleware)

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

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


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

OMG на основе объектной технологии и идеи интероперабельности вводит концепцию
промежуточного слоя последовательно, радикально и до конца. Технически интероперабельность
компонентов (представляемых объектами) решена введением базовой объектной модели,
унифицированного языка спецификации интерфейсов объектов, отделением реализации
компонентов от спецификации их интерфейсов, введением общего механизма поддержки
интероперабельности объектов (брокера объектных заявок, играющего роль "общей шины",
поддерживающей взаимодействие объектов). Тем самым достигается однородность представления
компонентов и их взаимодействия. Далее, для формирования информационной арxитектуры
вводится слой унифицированных (ортогональных) служб, которые используются как при
конструировании прикладных систем, так и для формирования функционально законченных
средств промежуточного слоя, предлагающих конкретные виды услуг. Существенно, что и службы
и средства представляются однородно своими объектными интерфейсами, что позволяет
обеспечить их интероперабельность посредством брокера объектных заявок.

Объектная модель OMG. Объектная модель OMG определяет общую объектную семантику для
спецификации базовыx характеристик объектов стандартным, независимым от реализации
образом.

Объектная модель OMG определяется в виде объектной модели -- ядра (Core Object Model (COM))
и совокупности расширений. Объектная модель -- ядро специфицирует некоторый набор базовых
понятий. Примерами понятий COM являются объекты, операции, типы, отношение тип/подтип,
наследование, интерфейс типа. Каждое расширение вводит дополнительный набор понятий.
Расширяться может либо COM, либо уже существующие и согласованные расширения.


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

Эталонная модель архитектуры OMG. Эталонная Модель определяет
концептуальную схему для поддержки технологии, удовлетворяющей техническим требованиям
OMG. Она идентифицирует и характеризует компоненты, интерфейсы и протоколы, составляющие
Архитектуру Управления Объектами OMG (Object Management Architecture (OMA)), не определяя,
впрочем, их детально.

Согласованная с OMA прикладная система состоит из совокупности классов и экземпляров,
взаимодействующих при помощи Брокера Объектных Заявок (Object Request Broker (ORB)).
Объектные Службы (Object Services) представляют собой коллекцию служб, снабженных
объектными интерфейсами и обеспечивающих поддержку базовых функций объектов. Общие
Средства (Common Facilities) образуют набор классов и объектов, поддерживающих полезные во
многих прикладных системах функции. Прикладные объекты представляют прикладные системы
конечных пользователей и обеспечивают функции, уникальные для данной прикладной
системы.

Пример устранения конфликтов компилятором

Последовательность операторов:
a = b + c
d = e - f

Неоптимизированнаяпоследовательность команд	Оптимизированнаяпоследовательность команд
LW Rb,b	LW Rb,b
LW Rc,c	LW Rc,c
ADD Ra,Rb,Rc	LW Re,e
SW a,Ra	ADD Ra,Rb,Rc
LW Re,e	LW Rf,f
LW Rf,f	SW a,Ra
SUB Rd,Re,Rf	SUB Rd,Re,Rf
SW d,Rd	SW d,Rd

Принципы организации основной памяти

Производительность основной памяти:

задержка

полоса пропускания

Задержка памяти:

время доступа (access time)

длительность цикла (cycle time)

Основные типы ЗУПВ:

СЗУПВ

ДЗУПВ

Обращение к ДЗУПВ:

RAS (row-access strobe) - строб адреса строки

CAS (column-access strobe) - строб адреса столбца

Временные параметры ДЗУПВ
(в последней строке приведены ожидаемые параметры):

Год появления	Емкость кристалла	Длительность RAS	Длительность CAS	Время цикла	Оптими-зированный режим
		max	min
1980 1983 1986 1989 1992 1995?	64 Кбит 256 Кбит 1 Мбит 4 Мбит 16 Мбит 64 Мбит	180 нс 150 нс 120 нс 100 нс 80 нс 65 нс	150 нс 120 нс 100 нс 80 нс 60 нс 45 нс	75 нс 50 нс 25 нс 20 нс 15 нс 10 нс	250 нс 220 нс 190 нс 165 нс 120 нс 100 нс	150 нс 100 нс 50 нс 40 нс 30 нс 20 нс

Увеличение полосы пропускания:

увеличение разрядности

расслоение памяти

использование специфических свойств ДЗУПВ:

блочный режим (nibble mode)

страничный режим (page mode)

режим статического столбца (static column)

оптимизация интерфейса между ДЗУПВ и ЦП (RAMBUS)

Проблема защиты информации в Internet

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

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

Технологией, предлагающей необходимые для применения в масштабах Internet универсальность и
общность, представляется существующая на сегодняшний день в виде промышленного стандарта
Sun Microsystems и проекта стандарта Internet (draft RFC, Request for comments) спецификация,
сокращенно называемая SKIP (Simple Key management or Internet Protocol - Простой протокол
управления ключами в интерсети). Эта спецификация была разработана компанией Sun
Microsystems в 1994 году и предложена в качестве стандарта Internet.

Процессоры с архитектурой 80х86 и Pentium

Этапы развития архитектуры 80 х 86:

1978 г.	- Intel 8086 (16 бит)
1980 г.	- Intel 8087 (сопроцессор ПТ)
1982 г.	- Intel 80286 (16 бит)
1987 г.	- Intel 80386 (32 бит)
1989 г.	- Intel 80486 (32 бит)
1993 г.	- Pentium (32 бит)

Рейтинг iCOMP:

Процессор	Тактовая частота (МГц)	Рейтинг iCOMP
386SX 386SL 386DX 386DX i486SX i486SX i486SX i486DX i486DX2 i486DX i486DX2 i486DX4 i486DX4 Pentium Pentium Pentium Pentium Pentium Pentium	25 25 25 33 20 25 33 33 50 50 66 75 100 60 66 90 100 120 133	39 41 49 68 78 100 136 166 231 249 297 319 435 510 567 735 815 1000 1200

Особенности Р6:

4-5 миллионов транзисторов

200 МГц (200 MIPS)

неупорядоченное выполнение команд

переименование регистров

расширение суперскалярных возможностей

Программные гнезда (sockets)

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

выполняющимся на одном компьютере

в пределах одной локальной сети

разнесенным на разные компьютеры территориально распределенной
сети

Первое решение:

UNIX BSD 4.1 в 1982 г.

Три составляющих:

компонент уровня программных гнезд (независящий
от сетевого протокола и среды передачи данных)

компонентом протокольного уровня (независящий от среды передачи
данных)

компонентом уровня управления сетевым устройством

Программные каналы

Создание неименованного программного канала
pipe(fdptr);

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

обычные дескрипторы файлов

два элемента таблицы открытых файлов процесса

Создание именованных программных каналов
(или получение доступа к существующим)
Обычный системный вызов open

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

аналогично обрабатывается открытие для чтения

имеется флаг NO_DELAY

Запись и чтение: read
и write

при записи данные помещаются в начало канала

при чтении выбираются из конца канала

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

Окончание работы процесса: close

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

Протокол SKIP

Почему же SKIP представляется решением, адекватным задачам защиты информации в масштабах
такой сети, как Internet?

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

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

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

В основе SKIP лежит криптография открытых ключей Диффи-Хеллмана.

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

Работа суперскалярного конвейера

Тип команды	Ступень конвейера
Целочисленная команда	IF	ID	EX	MEM	WB
ПТ команда	IF	ID	EX	MEM	WB
Целочисленная команда		IF	ID	EX	MEM	WB
ПТ команда		IF	ID	EX	MEM	WB
Целочисленная команда			IF	ID	EX	MEM	WB
ПТ команда			IF	ID	EX	MEM	WB
Целочисленная команда				IF	ID	EX	MEM	WB
ПТ команда				IF	ID	EX	MEM	WB

Пример цикла:

Loop: LD F0,0(R1) ;F0=элемент
вектора

ADDD F4,F0,F2 ;добавление
скалярной величины из F2

SD 0(R1),F4 ;запись
результата

SUBI R1,R1,#8 ;декрементирование
указателя

;8 байт
на двойное слово

BNEZ R1,Loop ;переход
R1!=нулю
Оптимизированная программа после 5-кратного
разворачивания цикла:

Целочисленная команда	Команда ПТ	Номер такта
Loop: LD F0,0(R1) LD F8,-8(R1) LD F10,-16(R1) LD F14,-24(R1) LD F18,-32(R1) SD 0(R1),F4 SD -8(R1),F8 SD -16(R1),F12 SD -24(R1),F16 SUBI R1,R1,#40 BNEZ R1,Loop SD -32(R1),F20	ADDD F4,F0,F2 ADDD F8,F6,F2 ADDD F12,F10,F2 ADDD F16,F14,F2 ADDD F20,F18,F2	1 2 3 4 5 6 7 8 9 10 11 12

Скорость работы цикла: 2.4 такта на элемент

Разделяемая память

shmget
создает новый сегмент разделяемой памяти или находит существующий
сегмент с тем же ключом
shmat
подключает сегмент с указанным дескриптором к виртуальной памяти
обращающегося процесса
shmdt
отключает от виртуальной памяти ранее подключенный к ней сегмент
с указанным виртуальным адресом начала
shmctl
служит для управления параметрами, связанными с существующим сегментом
После подключения сегмента разделяемой памяти к виртуальной
памяти процесса, он может обращаться к соответствующим элементам
памяти с использованием обычных машинных команд чтения и записи
shmid = shmget(key, size,
flag);

size
определяет желаемый размер сегмента в байтах

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

реальный размер сегмента можно узнать с помощью системного
вызова shmctl

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

создание сегмента не означает немедленного выделения под него
основной памяти

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

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

virtaddr = shmat(id, addr,
flags);

id
- это ранее полученный дескриптор сегмента

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

virtaddr - реальный
виртуальный адрес начала сегмента

не обязательно совпадает со значением прямого параметра addr

если addr ==
0, ядро выбирает наиболее удобный виртуальный адрес начала сегмента

shmdt(addr);

addr
- виртуальный адрес начала сегмента в виртуальной памяти, ранее
полученный от системного вызова shmat

shmctl(id, cmd, shsstatbuf);

cmd
идентифицирует требуемое конкретное действие

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

Реинжениринг модели

Rational Rose/C++ включает анализатор C++ (Analyzer),
поставляемый как отдельно исполняемый модуль, который грузится
независимо от Rose/C++.

Реинжениринг модели это процесс исследования программного кода
для извлечения информации о его структуре. Analyzer извлекает
информацию из С++ кодов и использует ее для построения модели
программного кода.

После работы анализатора модель может быть перенесена в систему
в виде диаграмм классов и модулей и проанализирована средствами
Rational Rose/C++.

Анализируется только структура кода. Исходный код может содержать
ошибки реализации

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

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

выбора исходных модулей для включения в модель;

выбора элементов диаграмм (классов, отношений, комментариев
и т.д.) для отображения в модели


Степень визуализации проанализированной информации
при передачи ее в Rational Rose/C++ настраивается. Это позволяет
производить анализ с различным уровнем детализации.

Роль и назначение концепции профиля

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

Поддерживает и связывает воедино такие аспекты,
как: определение, документирование, стандартизация, реализация,
аттестация реализаций, сопровождение спецификаций ИТ.

Поддерживает создание системы идентификации и
классификационной схемы ИТ-профилей.

Поддерживает единую методику документирования
ИТ-профилей (в виде ISP).

Профиль является базисом для создания средств
(тестовых пакетов - test suites) и методов тестирования реализаций
ИТ, с целью аттестации последних на международном уровне.

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

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

Роль Windows NT Server в домене

Первичный контроллер домена

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

Регистрация пользователей

Вторичный контроллер домена

хранение резервной копии базы учетных записей и ее тиражирование

Регистрация пользователей

Сервер

исполнение серверных приложений

Семафоры

Обобщение классического механизма семафоров общего
вида Диекстры
Целесообразность обобщения сомнительна
Обычно использовался облегченный вариант двоичных семафоров
Известен алгоритм реализации семафоров общего вида на основе двоичных
Семафор в ОС UNIX:

значение семафора

идентификатор процесса, который хронологически последним работал
с семафором

число процессов, ожидающих увеличения значения семафора

число процессов, ожидающих нулевого значения семафора

Три системных вызова:

semget
для создания и получения доступа к набору семафоров

semop для манипулирования
значениями семафоров

semctl для выполнения
управляющих операций над набором семафоров

id = semget(key, count,
flag);

key,
flag
и id
- обычный смысл

count - число
семафоров в наборе семафоров, обладающих одним и тем же ключом

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

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

oldval = semop(id, oplist,
count);

id
- дескриптор группы семафоров

oplist - массив
описателей операций над семафорами группы

count - размер
этого массива

возвращается значение последнего обработанного семафора

Элемент массива oplist:

номер семафора в указанном наборе семафоров

операция

флаги

Если проверка прав доступа проходит нормально

указанные в массиве oplist
номера семафоров не выходят за пределы общего размера набора семафоров

для каждого элемента массива oplist
значение семафора изменяется в соответствии со значением поля
"операция"

Значение поля операции положительно

значение семафора увеличивается на единицу

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

Значение поля операции равно нулю

если значение семафора равно нулю, выбирается
следующий элемент массива oplist

иначе число процессов, ожидающих нулевого значения
семафора, увеличивается на единицу

обратившийся процесс переводится в состояние
ожидания (усыпляется)

Значение поля операции отрицательно
(1) его абсолютное значение меньше или равно значению
семафора

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

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

(2) значение семафора меньше абсолютной величины
поля операции

число процессов, ожидающих увеличения значения
семафора увеличивается на единицу

текущий процесс откладывается

Стремление добиться возможности избегать тупиковых
ситуаций
Системный вызов semop
выполняется как атомарная операция
Флаг IPC_NOWAIT заставляет
ядро ОС UNIX не блокировать текущий процесс

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

semctl(id, number, cmd,
arg);

id
- это дескриптор группы семафоров

number
- номер семафора в группе

cmd
- код операции

arg - указатель
на структуру, содержимое которой интерпретируется в зависимости
от операции

Можно уничтожить индивидуальный семафор в указанной
группе

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

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

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

Семантика аттестации на соответствие профилю

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

Аттестационные требования классифицируются
следующим образом:

обязательные требования (mandatory requirements),
т.е. требования, которые должны рассматриваться во всех случаях;

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

Дополнительно, требования могут определяться
как:

безусловные, применимые всегда;

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

Чтобы оценить соответствие конкретной реализации,
необходимо иметь некоторое описание (заявку) реализованных возможностей,
включая описание опций и ограничений с тем, чтобы реализация могла
быть испытана на соответствие только требованиям, соответствующим
ее возможностям и только им. Такое описание называется заявкой
соответствия реализации (Implementation Comformance Statement
- ICS).

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

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

Семейство Powersoft Enterprise Series

PowerBuilder™ входит в состав Powersoft Enterprise Series™, семейство инструментальных
средств для разработки масштабируемых приложений в среде клиент/сервер, которые могут быть
использованы различными категориями пользователей организации - от разработчиков сложных
корпоративных информационных систем до разработчиков на уровне отделов и конечных
пользователей.

Построенные на унифицированной платформе клиент/сервер и единой объектной технологии
продукты Powersoft Enterprise Series представляют собой среду разработки приложений в
масштабах предприятия(Enterprise Development Architecture).

В Powersoft Enterprise Series входят различные редакции PowerBuilder. PowerBuilder Enterprise
предназначен для создания сложных многоплатформных приложений клиент/сервер коллективами
профессиональных разработчиков. PowerBuilder Team/ODBC обеспечивает возможность
коллективной разработки и работает с серверами баз данных через ODBC. PowerBuilder Desktop
предназначается индивидуальным разработчикам, создающим автономные приложения под Windows
с помощью Watcom SQL и настольных баз данных. Advanced Developer Toolkit включает библиотеку
многократно используемых объектов, а также развитые инструментальные средства, такие как
редактор изображений и построитель инсталляционных дискет, а также поддержку хранимых процедур
баз данных, NetWare и ввод данных с помощью пера.

В Powersoft Enterprise Series также включен InfoMaker™ - персональный инструмент разработки в
среде клиент/сервер, который позволяет конечным пользователям создавать запросы, формы, отчеты и
деловую графику. Пользователи могут манипулировать данными, применяя подход, основанный на
формах и не требующий программирования.


Продукты для всех

WATCOM C, C++ PowerBuilder Enterprise
PowerBuilder Team/ODBC PowerBuilder Desktop
InfoMarker

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

Серверы

Типы серверов:	Ресурс
Файл-сервер Сервер баз данных Принт-сервер Вычислительный сервер Сервер приложений	Файловая система База данных Принтеры Прикладные пакеты программ

Классификация по масштабу сети:

Типовой файл-сервер рабочей группы (20-30 человек):

Процессор - Intel 486DX2/66, Pentium

Память - больше 32 Мб

Диски - больше 2 Гб

Сетевой адаптер - Ethernet (10 Мбайт/с), Token Ring
(16 Мбайт/с)

Шина в/в - EISA (33 Мбит/с), PCI (132 Мбит/с)

Программное обеспечение - Novell NetWare

Суперсервер:

Процессоры - 2 и более (Intel 486, Pentium),
RISC (PA-RISC, Alpha, P4XXX, SuperSPARC)

Многоуровневая шинная архитектура

Технология дисковых массивов RAID

Симметричная многопроцессорная обработка

Операционные системы - UNIX, Windows NT

Система программирования тройного стандарта (3С++)

В.Сухомлин, Научно-исследовательский Вычислительный центр
МГУ им.
М.В.Ломоносова.

Сложные проекты на базе современных информационных технологий

Г.Элькин, Компания Элко Технологии
Выполнение крупных проектов - основное направление деятельности компании ЭЛКО
Технологии. Мы обеспечиваем:

обследование предприятия и моделирование его деловых процессов;

разработку плана реинжиниринга предприятия;

разработку бизнес-планов предприятий и проектов;

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

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

проектирование баз данных корпоративных систем;

разработку прикладных программ в технологии клиент/сервер;

обучение всех категорий пользователей в авторизованном учебном центре;

внедрение и последующее сопровождение систем.

В августе 1996 года в ЭЛКО Технологии завершено предпроектное обследование в рамках
разработки двух автоматизированных информационных систем. В состав технических предложений на разрабатываемые системы вошли:

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

разработка планов реинжиниринга предприятий;

определение Автоматизированных Рабочих Мест (АРМов) и
информационного взаимодействия между АРМами и внешними базами данных;

определение основных задач и направлений, решаемых в системе;

постановки всех функциональных подсистем;

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

проектирование концептуальной модели базы данных;

определение основных входных и выходных сообщений;

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

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

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

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

В качестве общесистемных программных средств выбраны:

Операционная система NetWare 4.1

Система обмена сообщениями GroupWise

Сервер реляционных баз данных SQL Base

Инструментальные средства разработки приложений Centura Team
Developer

Пакет офисных программ Microsoft Office
В спецификацию локальной вычислительной сети включено сетевое оборудование фирмы
Cabletron.

В настоящее время разрабатывается прикладное программное обеспечение систем. Сдача систем в
промышленную эксплуатацию состоится в мае 1997 года.

Завершается выполнение совместного проекта ЭЛКО Технологии и германской фирмы Siemens
Nixdorf. Для одного из ведущих правительственных ведомств России создана мощная
корпоративная сеть, испытания которой успешно завершены в июле 1996 г. в Дрездене.

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

В проекте используется новейшее сетевое оборудование для локальных сетей и их объединения в
различных коммуникационных средах, поставляемое компанией Cabletron Systems, и компьютеры
фирмы Siemens Nixdorf.

В результате успешного завершения ряда проектов в ЭЛКО Технологии разработаны системы,
ставшие сейчас тиражируемыми продуктами:

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

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

[]
[]
[]

Служба каталогов Windows NT - ядро информационной системы

Единая база учетных записей

Однократная регистрация пользователей

Централизованное управление учетными записями

Централизованное управление ресурсами

двухярусная модель управления

Интеграция с другими службами

Репликация базы

SNA Server - обеспечение связи с большими и мини компьютерами

Взаимодействие с ES9000 и AS400

Обеспечение "прозрачного" подключения к хостам

на клиентах не требуется делать изменения

Высокая нагрузочная способность

Поддержка широкого спектра протоколов

Современное состояние свободно распространяемого программного обеспечения

С.Кузнецов, Центр Информационных Технологий
В докладе описывается текущее состояние бесплатно (свободно) распространяемого программного
обеспечения. Эта тема является практически бесконечной, и любой рассказ о ней объективно носит
абсолютно субъективный характер. С другой стороны, будучи очевидно важным для всего
человечества, свободное программное обеспечение особенно важно для России и других
государств, образовавшихся на осколках коммунизма. Слишком часто у нас не хватает денег,
чтобы приобрести действительно нужное программное обеспечение. Нужно понять, что очень
часто это не должно порождать неразрешимые проблемы. Да, мы не очень богаты (увы!), но мы и
не слишком глупы, чтобы не справиться с освоением программных продуктов со статусом public
domain.

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

Современные аппаратные платформы

В. Шнитман,
Общие требования, предъявляемые к современным компьютерам:

Отношение стоимость/производительность

Надежность и отказоустойчивость

Масштабируемость

Совместимость и мобильность программного обеспечения

Классификация компьютеров по областям применения:

Персональные компьютеры и рабочие станции

X-терминалы

Мейнфреймы

Создание приложения в среде PowerBuilder

Возможности Художника баз данных (DataBase Painter) обеспечивают тесную интеграцию с
широким спектром поддерживаемых баз данных с полным использованием специфических
особенностей каждой из них. PowerBuilder позволяет разработчикам создавать приложения с
прозрачным доступом и обновлением множественных источников данных.

Создание и управление базой данных

Художник баз данных предоставляет доступ к Художнику администрирования данных
(Data Administration Painter) - интерактивному блокноту для записи и графического представления
операторов SQL, которые затем немедленно выполняются СУБД. Художник администрирования
баз данных позволяет создавать, удалять и модифицировать пользователей системы управления
базами данных, а также указывать привилегии и ограничения доступа в соответствии с
возможностями управления доступом выбранной СУБД.

Художник манипулирования данными(Data Manipulation Painter) позволяет предварительно
просматривать существующие данные, заполнять новые таблицы, а также тестировать форматы
изображений, правила проверки и стили редактирования на реальных данных.

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

Репозиторий дизайна приложений (Application Design
Repository)

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

открывающиеся Окна данных (DataWindows), одно- и многострочные стили редактирования,
а также шаблоны редактирования ввода данных.

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

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

Создание приложения в среде PowerBuilder

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


Шаг
Процедура
Используемые инструменты

1	Создание объекта приложения	Художник приложений(Application Painter)
2	Проектирование графического интерфейса пользователя	Художники окон, меню и объектов пользователя (Window, Menu and User Object Painters)
3	Определение поведения объектов	Художник PowerScript (PowerScript Painter)
4	Определение режимов работы с данными	Художник Окна данных(DataWindow Painter)
5	Генерация отчетов	Художник отчетов (Report Painter)
6	Добавление подсказок в приложение	Функции PowerScript
7	Управление приложением	Художник библиотек (Library Painter)
8	Отладка приложения	Отладчик (Debugger)
9	Поставка завершенного приложения	Художник приложений (Application Painter, Project Painter)

<


Объекты, элементы управления и события

Разработка в среде PowerBuilder базируется на создании объектов, элементов управления и событий.
Приложения PowerBuilder состоят из объектов (таких как окна, Окна данных, меню и объекты
пользователя) и элементов управления (таких как Командные кнопки(CommandButtons) и
Радиокнопки (RadioButtons)).

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

PowerBuilder - система, управляемая событиями. Разработчики определяют атрибуты, а также
поведение объектов и элементов управления в соответствии с конструкцией приложения.

Управление объектами

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

Объектная технология

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

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

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

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

SPARC - Scalable Processor Architecture

Поставщики:

Texas Instruments

Fujitsu

LSI Logic

Bipolar International Technology

Pilips

Cypress Semiconductor

SPARC International: 250 членов
Этапы развития процессоров SPARC:

1987 г.	- Fujitsu, 16/67 МГц, 10 MIPS
1988 г.	- Fujitsu, 25 МГц, 15 MIPS
1990 г.	- Cypress, LSI Logic, 40 МГц, 28 MIPS
1993 г.	- Texas Instruments, Super SPARC, 50, 60, 75, 85 МГц
1993 г.	- Texas Instruments, MicroSPARC, 50 МГц
1994 г.	- Fujitsu, MicroSPARC II, 70, 85, 110 МГц
1994 г.	- Fujitsu, HyperSPARC, 100, 125, 150 МГц
1995 г.	- Texas Instruments, UltraSPARC I, 143, 167 МГц
1996 г.	- Texas Instruments, UltraSPARC II, 200 - 275 МГц
1998 г.	- Texas Instruments, UltraSPARC III, 500 МГц

Список литературы

G.Booch, Object-Oriented Analysis and Design with Applications, Benjamin/Cummings Series
in OO Software Eng., 1994.

Майкл Л. Броди, "Интероперабельные информационные системы в науке", Сборник
материалов семинара, Москва, апрель 6-7, 1995.

Брюхов Д.О., Задорожный В.И., Калиниченко Л.А., Курошев М.Ю., Шумилов С.С.
Интероперабельные информационные системы: архитектуры и технологии. СУБД, N 4, 1995

P.Coad and E.Yourdon, Object-Oriented Analysis (Second Edition), Prentice Hall, 1991.

Hutt A. (editor). Object Analysis and Design. Description of methods. Object management group.
John Wiley and Sons. 1994. p. 202

I.Jacobson, M.Christerson, P.Jonsson, G.Overgaard, Object-Oriented Software Engineering - A Use
Case Driven Approach, Addison-Wesley, 1992.

Калиниченко Л.А. Стандарт систем управления объектными базами данных ODMG-93:
краткий обзор и оценка состояния. СУБД, N 1, 1996

Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в
архитектуре CORBA. СУБД, N 2, 1996

Калиниченко Л.А., Когаловский М.Р. Интероперабельность брокеров в стандарте CORBA 2.0.
СУБД, N 3, 1996

Калиниченко Л.А. СИНТЕЗ: язык определения, проектирования и программирования
интероперабельных сред неоднородных информационных ресурсов (вторая редакция) Сентябрь
1993.

Kalinichenko L.A. A Complementary Architecture Integrating Industrial and Semantic
Interoperation Environments. Institute for Problems of Informatics, Russian Academy of Sciences,
Technical Report, 1993.

Kalinichenko L.A. Emerging semantic-based interoperable information system technology.
Computers as our better partners. Proceedings of the International IISF/ACM Symposium, Tokyo,
World Scientific, 1994.

The Object Database Standard: ODMG-93. Ed. by R.G.G. Cattell, Morgan Kaufmann Publ., 1994.

Object Management Group, "The Common Object Request Broker: Architecture and Specification",
OMG Document Number 91.12.1, December 1991.

Object Management Group, "Object Services Architecture", Revision 8.0, 09 December 1994.

Object Management Group, "Common Facilities Architecture", Revision 2.0, September 1994.

Object Management Group, "Common Facilities Architecture", Revision 3.0, November 1994.

Object Management Group, "Common Facilities Roadmap", Revision 3.1, January 1995.

OMG, "Common Object Services Specification Volume1 (COSS1), March 1994.

Object Management Group, " Object Management Architecture Guide", OMG Document Number
92.11.1, September 1, 1992.

J.Rumbaugh et al., Object-Oriented Modeling and Design, Prentice Hall,
1991.

Клименко С.В., Уразметов В.Ф. Internet. Среда обитания информационного общества.
РЦФТИ, Протвино, 1995.

Sutherland I.E. Sketchpad: man-mashine graphical communication system. PhD Thesis
Massachussets Institute of Technology.

Newman W.M. A system for interactive graphical programming. Prog Spring Joint Comput. Conf.
Spartan Books, Baltimore, USA, 1968.

Myers B. Creating dynamics interaction techniques by demonstration. ACM CHI 87-GI Conference,
1987.

Kasik D.A. A user interface management system. Computer Graphics -- 1982. -- V.\.16, N\,4. --
pp.\,99--106.

Eckardt. User Interface Toolkits and User Interface Management Systems, ZGDV e.V. Darmstadt,
FRG.

Ziegler J.E. Direct Manipulation Techniques for Human-Computer Interfaces. Eurographics-90,
Technical Report Series.

Allari S. et al. Achievements Derived from the Adoption of UIMS with Graphic Interaction
Techniques in Vitamin Project. Proceeding of the Graphics and Interaction in ESPRIT Session.
Eurographics'89.

Cockton G. Interaction Ergonomics, Control and Separation: Open Problems in User Interface
Systems., AMU8811/03H, Scotish HCI Centre, 1988.

Prime M. User Interface Managment Systems - A Current product Rewiew. Computer Graphics
Forum 9, 1990.

Kilgour A. Theory and practice in user interface management systems. SYSTEMS vol 29, no. 4, 1987.

XFaceMaker: An Interface generator for OSF/Motif.

[]
[]
[]

Стандарт DDE межпроцессного взаимодействия в операционной системе Windows

Механизм DDE (Dynamic Data Exchange) представляет собой механизм динамического обмена
данными, позволяющий создать постоянно действующие каналы между несколькими
одновременно работающими приложениями операционной системы Windows. Эти каналы могут
создаваться автоматически при запуске приложения или при необходимости, а также по явному
запросу пользователя. После создания каналы могут функционировать без вмешательства
пользователя. Механизм DDE основан на использовании стандартной архитектуры "клиент -
сервер". В терминологии DDE приложение, посылающее данные называется сервером, а
принимающее - клиентом.

В DDE определены несколько стандартных типов сообщений, при помощи которых можно
передавать в приложения дескрипторы объектов глобальной памяти, содержащих необходимые
данные.

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

Для работы с использованием технологии DDE приложение-клиент и приложение сервер должны
зарегистрироваться в динамической библиотеке DDEML. Кроме этого сервер должен
зарегистрировать предоставляемые им сервисы, а также темы и элементы данных, входящие в эти
сервисы. После этого клиент может создавать канал, ассоциированный с сервисом и темой,
поддерживаемыми сервером.

По каналу могут передаваться данные трех типов:

Запрос клиента к серверу на передачу обратно определенных данных,

Передача данных от клиента к серверу,

Передача клиентом серверу команды, которую сервер должен выполнить.
В более поздних версиях операционных систем семейства Windows механизм DDE был дополнен
управляющей библиотекой динамического обмена DDEML, которая позволяет упростить
использование механизма DDE, а также является совместимой с операционными системами
Windows NT и Windows 95, не поддерживающими старый стандарт, и с сетевым вариантом DDE -
Network DDE.

Стандартные интерфейсы WWW серверов

Для организации передачи данных из HTML документа технология WWW серверов использует
CGI интерфейс обмена данными между сервером и приложением-обработчиком(в Windows
подобных операционных системах это Windows CGI интерфейс). При переходе по гиперсвязи из
гипертекстового HTML документа адрес гиперузла вместе с необходимой дополнительной
информацией передается от клиента к WWW серверу. WWW сервер анализирует тип документа ,
который находится в указанном узле и либо сразу после некоторой обработки передает документ
клиенту, либо, если в узле находится документ с MIME типом "application/...", то запускает это
приложение на исполнение и затем возвращает результаты работы этого приложения клиенту. При
запуске приложения приложению передается информация о клиенте и информация, получаемая из
HTML документа клиента, например из объектов диалога, обозначаемых тэгом FORM.

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

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

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

Сервер запускает обработчик с помощью WinExec() с командной строкой следующего вида:

обработчик файл-данных-CGI файл-контекста выходной-файл URL-аргументы, где файл-данных-CGI - файл, в который сервер записывает служебную информацию, файл-контекста - файл, в который сервер записывает данные, введенные пользователем в HTML документ, выходной-файл - файл, в который обработчик должен записать результаты работы, URL-аргументы - все, что следует за '?' в URL запросе.

Windows-сервер передает данные программе обработчику через Windows "private profile" файл в
формате пар ключ-значение.

Файл CGI данных содержит следующие разделы:

[CGI]

[Accept]

[System]

[Extra Headers]

[Form Literal]

[Form External]

[Form Huge]

Структура JTC1 и состав основных подкомитетов по стандартизации ИТ

В 1987 г. ISO и IEC объединили свою деятельность в области стандартизации ИТ, создав единый орган JTC1 (Joint Technical Committee 1 - Объединенный технический коммитет 1), предназначенный для формирования всеобъемлющей системы базовых стандартов в области
ИТ и их расширений для конкретных сфер деятельности.

Работа над стандартами ИТ в JTC1 тематически распределена
по подкомитетам (Subcommittees - SC).

В дополнение создана специальная группа по функциональным
стандартам (Special Group on Functional Standards - SGFS) для
обработки предложений по Международным стандартизованным профилям
(International Standardized Profiles - ISP s), представляющим
пределения профилей ИТ.

Ниже показаны подкомитеты и группы JTC1, связанные
с разработкой стандартов ИТ, относящихся к окружению открытых
систем (Open Systems Environment - OSE).

JTC1:

C2 - Символьные наборы и кодирование информации

SC6 - Телекоммуникация и информационный обмен
между системами

SC7 - Разработка программного обеспечения и системная
документация

SC18 - Текстовые и офисные системы

SC21 - Открытая распределенная обработка (Open
Distributed Processing - ODP), управление данными (Data Management
- DM) и взаимосвязь открытых систем (Open System Interconnection
- OSI)

SC22 - Языки программирования, их окружения и
интерфейсы системного программного обеспечения

SC24 - Компьютерная графика

SC27 - Общие методы безопасности для ИТ-приложений

SGFS - Специальная группа по функциональным стандартам

Структура знаний итологии

Структура знаний имеет многоуровневую организацию

Концептуальный уровень или уровень метазнаний, состоит из
архитектурных спецификаций, называемых эталонными моделями (Reference
Model). Архитектурные спецификации предназначены для структуризации
спецификаций функций некоторой области.

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

Локальные профили (например, OSI - профили)

OSE-профили (специализация поведения открытых систем

Полные OSE-профили (профили платформ и систем).

OSE-профили прикладных технологий

Стратегические профили (например, GOSIP).

Спецификации OSE предназначены для описания поведения ИТ-систем
на их границах, называемых интерфейсами.

Построение OSE-спецификаций осуществляется с помощью аппарата
профилей на основе базовых или стандартных спецификаций.

Структура знаний итологии

Стратегические профили ( GOSIP)

Профили прикладных технологий

Полные OSE-профили (профили платформ, систем)

OSE-профили

Локальные профили (в частности, OSI - профили)

Базовые спецификации

Архитектурные спецификации (Эталонные модели)

Структуры данных, используемые для организации очередей сообщений

msgsnd(msgqid, msg, count,
flag);

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

count - задает
размер сообщения в байтах

flag определяет
действия ядра при выходе за пределы допустимых размеров внутренней
буферной памяти

Условия успешной постановки сообщения в очередь:

процесс должен иметь право на запись в очередь

длина сообщения не должна превосходить верхний предел

общая длина сообщений не должна превосходить установленного
предела

тип сообщения должен быть положительным целым числом

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

обратившийся процесс откладывается до разгрузки
очереди

но есть флаг IPC_NOWAIT
(как для семафоров)

count = msgrcv(id, msg,
maxcount, type, flag);

msg
- указатель на структуру данных в адресном пространстве пользователя
для размещения принятого сообщения

maxcount
- размер области данных (массива байтов) в структуре msg

type
специфицирует тип сообщения, которое желательно принять

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

count
- реальное число байтов, переданных пользователю

Значением параметра type является нуль

выбирается первое сообщение

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

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

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

если задан флаг MSG_NOERROR,
то выборка сообщения производится, и в буфер пользователя переписываются
первые maxcount
байтов сообщения

Значение type есть положительное целое число

выбирается первое сообщение с таким же типом

Значение type есть отрицательное целое число

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

В очереди отсутствуют сообщения, соответствующие
спецификации type

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

но есть флаг IPC_NOWAIT

msgctl(id, cmd, mstatbuf);

опрос состояния описателя очереди сообщений

изменение его состояния

уничтожение очереди сообщений

Свойства профилей

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

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

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

Systems Management Server -

Инвентаризация

техники

программного обеспечения

Распространение программ

в локальных и глобальных сетях

без вмешательства пользователя

Удаленная диагностика

Диагностика сети

Перехват управления

Управление серверными приложениями

Таксономия OSE-профилей

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

Структурированный идентификатор имеет следующие
компоненты:

Корневой мнемоники или корня (root mnemonic)
- короткой символьной строки, обозначающей область использования
OSE-профиля. Например, EDI (для Electronic Data Interchange) или
MED (для медицинских приложений).

Числовая строка, средующая за корнем и используемая
для разбиения на подразделы области применения профиля.

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

C - для CSI

I - для ISI

H - для HCI

P - для API

(Рассматривается использование буквы F для F-профилей).

Примеры:

идент-р	облать OSE-профиля	тип интерфейсов
AMHnnn-C	Messaging functions	CSI
AFTkkk-CP	File function	CSI/API
WINaaa-H	Windows functions	HCI
MEDkkk-CHP	Medical functions	CSI/HCI/API

В таксономии возможно указание профилей, цитируемых
в конкретном OSE-профиле, при этом для идентификации OSE-профиля
используется функциональная форма записи:

MEDkkk-CHP(FTmmm-CP, WINiii-H)

Классы OSI-профилей:

А - прикладные профили, требующий услуг транспортного
уровня в режиме

с установлением соединения

B - прикладные профили, требующий услуг транспортного уровня
в режиме

без установления соединения

F - профили представления и форматов обмениваемых данных

R - ретрансляционные профили, реализуют функции ретрансляции,

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

(между профилями различных транспортных классов профилей,
т.е. Т и U,

ретрансляция отсутствует).

T - транспортные профили, обеспечивающие услуги транспортного
уровня в

режиме с установлением соединения

U - транспортные профили, обеспечивающие услуги транспортного
уровня в

режиме без устанолвения соединения

Классы T- и U-профилей подразделяются на группы.

Группа - набор T- или U-профилей, которые являются
совместимыми, в том смысле, что ИТ-системы, реализующие различные
профили из данной группы, могут осуществлять взаимодействие в
соотвествии с моделью OSI минимально в объеме обязательных средств
профилей этой группы.

Таксономия подсетевых услуг

abcd	Тип подсети
1	СЕТЬ ДАННЫХ С КОММУТАЦИЕЙ ПАКЕТОВ (СДКП)
2	ЦИФРОВОЙ КАНАЛ ДАННЫХ
3	АНАЛОГОВЫЙ ТЕЛЕФОННЫЙ КАНАЛ
4	ЦИФРОВЫЕ СЕТИ ИТЕГРАЛЬНОГО ОБСЛУЖИВАНИЯ (ISDN)
41	Служба полупостоянных каналов
411	В-канал
4111	Работа ООД-ООД по Х.25
42	Служба в режиме коммутации каналов
421	В-канал
4211	Работа ООД-ООД по Х.25
5	ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СЕТИ
51	CSMA/CD
52	Шина с маркерным доступом
53	Кольцо с маркерным доступом
54	FDDI

Примеры идентификаторов транспотных профилей:


TB4111 Работа ООД-ООД
по Х.25 через ISDN (COTS over CONS)

TA51 CSMA/CD LAN (COTS
over CLNS)

Технология ODBC организации доступа к базам данных

ODBC (Open Database Connectivity) является средством, позволившим унифицировать
организацию взаимодействия с различными базами данных. Для этого доступ к базе данных
осуществляется при помощи специального ODBC драйвера, который транслирует запросы к базе
данных со стандарта языка SQL на язык, поддерживаемый конкретной системой управления
базами данных.

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

ODBC драйвер представляет собой динамическую библиотеку (DLL), которая может
использоваться приложением для получения доступа к конкретному источнику данных. Каждой
системе управления базами данных необходим свой ODBC драйвер.

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

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

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

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

соединения с базой данных.

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

Установка и контроль установленных значений ODBC драйвера. Функции этой группы
позволяют редактировать атрибуты соединения и конкретного запроса к базе данных.

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

Исполнение SQL запроса. Эта группа вызовов позволяет выполнять ранее подготовленные или
вновь создаваемые SQL запросы и управляет передачей параметров в SQL запросы.

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

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

Завершение выполнения запроса и разрыв соединения.

Технология проектирования и создания

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

Рассматриваются:

CASE Vantage Team фирмы Cayenne;

средства разработки Informix-4GL и NewEra фирмы Informix и SuperNOVA фирмы Four
Seasons;

кодогенераторы Grindery и среда быстрой разработки GRABBER фирмы DataX/FLORIN.

Такой выбор:

обеспечивает нам достаточно широкий набор инструментов логического
проектирования, включая:

анализ и перепроектирование существующих бизнеспроцессов,

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

проектирование аппаратного комплекса,

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

принципы построения интерфейса;

обеспечивает возможность выбирать для каждого фрагмента приложения наиболее
адекватные средства реализации, включая Informix-4GL, NewEra и SuperNOVA

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

гарантирует автоматическую генерацию и поддержку подробной документации на всех фазах
проектирования

обеспечивает быстрое прототипирование системы на основе автоматической генерации SQL-
скриптов и кода программы

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


[]
[]
[]

Тезисы доклада

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

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

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

В качестве примера подобной программной системы разумно использовать информационную
среду World Wide Web и язык программирования (или составления сценариев?) Java. В этом случае мы имеем гипертекстовую модель представления информации, компонентную модель программного обеспечения, инкрементальный анализ программ и их компиляцию в необходимый момент времени, наличие виртуальной машины (интерпретатора) Java.

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

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

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

Основным содержанием доклада является следующее.

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

Рассматриваются процессы создания и модель жизненного цикла ИС, определяемые
стандартами ISO.

Предлагается методология и технология создания ИС, реализуемая в АО "Аргуссофт
компани", основанная на самых современных методах и стандартах и поддержанная
согласованным набором современных методик и инструментальных средств.


С июня этого года фирма "Аргуссофт" проводит работы в Национальном Банке
Республики Татарстан по созданию автоматизированной подсистемы банковского
надзора за деятельностью кредитных организаций. Основная цель этих работ
помимо создания подсистемы - проверка эффективности применения методологий
DATARUN и RAD в банковской деятельности. Работы проводятся на основе
комплекса инструментальных средств, предлагаемых "Аргуссофт" - CASE-
средство SILVERRUN, язык четвертого поколения JAM7, средство
конфигурационного управления PVCS.

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

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

Рассматриваются основные шаги методологии DATARUN и описывается,
каким образом эти шаги были реализованы при обследовании отдела
банковского надзора и как они были дополнены с учетом имеющегося опыта.

Рассматриваются основные шаги методологии RAD и описывается,
каким образом эти шаги реализуются при создании подсистемы банковского
надзора за деятельностью кредитных организаций и как они дополнены с
учетом имеющегося опыта
Лапин Сергей Александрович

Аргуссофт Компани, тел. 288-30-14

[]
[]
[]

Методология создания глобальной информационной системы.

Архитектура информационной системы (Глобальное информационное пространство).

Структура управления информационной системой.

Реализация информационной системы на базе реляционной СУБД PROGRESS.

Компонентное программирование - новый шаг в развитии объектно-ориентированного
подхода.

Компонентные серверы приложений.

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

[]
[]
[]

Типичные функции, которые подсистемы

Создание и завершение процессов и нитей

Регистрация и управление взаимоотношениями между
процессами

Чтение, запись и другие действия с адресными
пространствами процессов - клиентов

Останов нити клиента, изменение пользовательского
контекста нити, рестарт этой нити

Захват и обработка исключительных ситуаций (exeptions),
генерируемых клиентскими процессами




Отличия 32-битного API Win32 от 16-битного
Windows API:

использование 32-битной плоской модели памяти

расширенные функции по управлению вводом-выводом,
памятью, объектами

поддержка многонитевости, безопасности

улучшены функции по управлению графикой и окнами

Преемственность API Win32

управление окнами и пользовательским интерфейсом
из Windows 3.0

пользовательский интерфейс Windows NT полностью
совместим с пользовательским интерфейсом Windows 3.1

графическая часть подсистемы Win32 является
полностью новой

новое свойство Win32 - безопасность






Подсистема OS/2

символьно-ориентированные приложения OS/2 1.х

компьютеры на базе процессоров х86

запуск из командной строки Windows NT, из Program
Manager или косвенно из приложений OS/2 или Win32

распознаются по заголовку исполняемого файла

для загрузки приложения - вызов подсистемы OS/2

запускается процесс OS/2SRV подсистемы окружения
OS/2

попытки выполнить сегменты ввода-вывода в кольце
2 завершаются кодом "Общий сбой по защите"

Объекты Windows NT встраиваются внутрь объектов
OS/2

Нить получает приоритет и идентификатор, которые
являются допустимыми в OS/2

Подсистема окружения OS/2 использует возможности
большой памяти Windows NT

Подсистема Posix (Portable Operation System Interface based on UNIX)

запуск из консольного текстового окна Windows
NT, с помощью File Manager, Program Manager и косвенно из другого
приложения POSIX

на диске должен находится по крайней мере один
раздел NTFS

Подсистема POSIX непосредственно не поддерживает
печать

Командный процессор Windows NT поддерживает команды
всех подсистем окружения


Механизм вызова локальных процедур (Local Procedure Call, LPC)

Назначение - прозрачный
вызов процедур одного процесса из другого процесса внутри одной
машины


LPC - локальный вариант RPC

Для прикладного программиста совершенно прозрачен

Системный программист оформляет библиотеку стабов
LPC и библиотеку функций сервера LPC и регистрирует последнюю
в ядре

Механизм передачи параметров и результаты в LPC -
передача асинхронных сообщений через общую память
Передача сообщений при реализации LPC


Передача сообщений через коммуникационные
порты

Коммуникационные порты
- очереди фиксированной длины в виртуальном адресном пространстве
ядра.

Передача сообщений через разделяемую секцию памяти

Клиентский стаб сам решает, какого размера сообщения понадобятся
для передачи параметров процедуры

Если потребуется сообщение 256 байт, то стаб создает секцию
памяти и отображает ее (с помощью менеджера виртуальной памяти)
в свое адресное пространство и пространство процесс-сервера

Типовая архитектура машины с распределенной памятью

Преимущества механизма на базе общей памяти:

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

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

Более низкая задержка обмена и лучшее использование полосы
пропускания при обмене малыми порциями данных.

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

Преимущества механизма на базе передачи сообщений:

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

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

Характеристики производительности механизма
обмена:

Полоса пропускания

Задержка

Упрятывания задержки

Типы протоколов когерентности кэш-памяти:

Протоколы на основе справочника (directory based)

Протоколы наблюдения (snooping)

Протоколы записи с аннулированием (write invalidate protocol)

Протокол записи с трансляцией (write broadcast protocol)

Примеры протоколов наблюдения:

Наименование	Тип протокола	Стратегия записи в память	Уникальные свойства	Применение
Одиночная запись	Запись с аннулированием	Обратное копирование при первой записи	Первый описанный в литературе протокол наблюдения	-
Synapse N+1	Запись с аннулированием	Обратное копирование	Точное состояние, где "вла-дельцем является память"	Машины Synapse Первые машины с когерентной кэш-памятью
Berkely	Запись с аннулированием	Обратное копирование	Состояние "разделяемый"	Машина SPUR университета Berkely
Illinois	Запись с аннулированием	Обратное копирование	Состояние "приватный"; может передавать данные из любого кэша	Серии Power и Challenge компании Silicon Graphics
"Firefly"	Запись с трансляцией	Обратное копирование для "приватных" блоков и сквозная запись для "разделяемых"	Обновление памяти во время трансляции	SPARCcenter 2000

Типовая структура документа ISP

FOREWORD // Предисловие

INTRODUCTION // Введение

1. SCOPE // Область применения + Scenario

2. NORMATIVE REFERENCES // Нормативные ссылки

3. DEFINITIONS // Определения

4. ABBREVIATIONS // Сокращения

5. CONFORMANCE // Соответствие

6. Requirements specifications related to each base standard // Спецификации требований для каждого базового стандарта

NORMATIVE ANNEXES - задающие требования соотвествия профиля в
табличном представлении.

INFORMATIVE ANNEXES - содержащие объяснения и руководства, если
это требуется.

В дополнении к 10000-1 приводятся правила составления каждого
из элементов ISP, соответствующие правилам IEC/ISO. (В случае
разбиения ISP на части, каждая часть должна удовлетворять этой
структуре).

Типы диаграмм, поддерживаемые Rational Rose

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

Диаграммы Классов (Classes)	Статическая модель
Диаграммы состояний и переходов (State Transition Diagram)	Динамическая модель
Диаграммы сценариев объектов (Object Message Diagram)	Функциональная модель
Диаграммы сценариев сообщений (Message Trace Diagram)	Функциональная модель
Диаграммы модулей (Modules) Диаграммы процессов (Processes)	Диаграммы потоков данных в функциональной модели ОМТ больше не поддерживаются и заменены на сценарные диаграммы

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

Требования к сети крупной организации

Надежность

Защищенность

Управляемость

Простая модифицируемость

Поддержка различных клиентов

Минимальные затраты на техническую поддержку

Требования к содержанию и формату ISP

Профили непосредственно связаны с базовами стандартами
и аттестация на соответствие профилю подразумевает аттестацию
на соответствие этим базовым стандартам.

ISPs должны удовлетворять правилам IEC/ISO для представления
проектов и самих международных стандартов.

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

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

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

Для каждого профиля должна обеспечиваться спецификация тестирования
профиля (Profile Test Specification), которая определяется или
как часть ISP или как отдельный самостоятельный ISP. В последнем
случае в исходном ISP используется ссылка на этот документ.

UIDS/UIMS

Введение в UIMS

Родоначальником систем интерактивного взаимодействия человека с машиной является Ульям
Ньюман (1968, Reaction Handler. A System for Interactive Graphical Programming). А впервые
название UIMS появилось в статье Д.Казика Tiger в 1982г..

Основные концепции UIMS были выработаны на ряде семинаров:

1983	Workshop on "User Interface Management Systems", Seeheim, FRG;
1986	ACM SIGGRAPH Workshoop on "Software Tools for User Interface Management Systems", Seattle, USA;
1987	Glasgow University Workshop on "User Interface Management Systems";
1990	ESPRIT/Eurographics International Workshop on "User Interface Management Systems and Environments", Lisbon.

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

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

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

использование графических символов ("икон") для представления объектов

стиль взаимодействия, называемый непосредственным манипулированием

популярность "мыши" как устройства позиционирования на экране

объектно-ориентированный стиль программирования.
С тех пор система классификации инструментария для создания и управления пользовательским
интерфейсом рассматривается на трех уровнях:

системы управления окнами (WMS - Window Manager System);

специализированный инструментарий;

обычный (MacIntosh, SunView . . .)

объектно-ориентированный (Smalltalk-80, Andrew, InterView)

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

Системы управления окнами (WMS)

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

WMS, операционная среда связанных с окнами ресурсов управления, осуществляет поддержку:

перекрывающихся окон (прямоугольных областей экрана);

различных устройств ввода (цифровых и аналоговых);

курсоров;

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

Возможны реализации WMS двух типов: базовая система (Kernel System), работающая на одной


машине, и сетевая (Network oriented), реализуемая на основе модели клиент-сервер.

Инструментарий создания пользовательского
интерфейса

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

Возможные модели управления, по терминологии конференции 1982 года в Сиэтле:

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

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

Смешанная, приводящая к появлению новой компоненты - связной области, являющейся


"транслятором" между двумя Стандартными и тесно связанными компонентами. Это наиболее
общая из моделей.
Пути реализации:

механизм обратного вызова (прикладная программа организована как
набор процедур вызываемых инструментарием);

разделяемая память;

передача сообщений;

механизм обработки событий.
Дальнейшее развитие инструментария привело к появлению понятия Widget (заготовка) - объекта
более сложного, чем перечисленный выше набор простых средств ввода в прикладную программу,
хотя и включающих в себя эти средства. Такой инструментарий не стандартизован, различные
фирмы (Apple, Sun, etc.) предлагают существенно разный набор средств, как по номенклатуре, так
и по функциональным возможностям. В качестве примера рассмотрим набор простых, составных и
дополнительных заготовок, предоставляемых программным продуктом OSF/Motif.

Основные:
Область рисования	графическое пространство
Разделитель	линии разделяющие области
Метка	статический текст
Шкала	слайдер для получения числа
Зона прокрутки	управление прокруткой
Три типа Кнопок	управляющие кнопки с различным статусом
Каскадные Кнопки	кнопки для каскадных меню
Необязательные поля	отображение перечислимых значений переменной
Текст	ввод и редактирование текста
Команды	клавиатура с описанием
Составные:
Доска объявлений	панель с произвольным размещением объектов
Экранная форма	форма размещения объектов с выравниванием
Список	список строк
Вертикальное подокно	столбец с изменяемой высотой
Строка/Столбец	объект с ограничениями по строкам и столбцам
Зона меню	область меню для выпадающего меню
Кадр	контейнер для поддержки 3D обрамления
Дополнительные:
Прокрутка текста	область прокрутки текста
Прокрутка списка	область прокрутки списка
Окно прокрутки	обобщенная область прокрутки
Радио поле	набор радио кнопок
Поле выбора	выбор из списка строк
Поле выбора файла	специализированная область селектирования файлов
Основное окно	прикладное окно верхнего уровня
Поле диалога	транзитное поле диалога
Диалог в экранной форме	транзитное поле диалога для экранных форм
Меню	"выпадающее" или "выпрыгивающее" меню
Сообщение/предупреждение	зона диалога для печати сообщений

?


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

Системы управления интерфейсом пользователя

В научной литературе пока нет согласованного взгляда на термин UIMS - точное его значение
само является объектом исследования.

Классическое определение было выработано на семинаре в Глазго в 1987г.

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

Одна из версий принадлежит Майерсу: "Система проектирования интерфейса пользователя есть
интегрированный набор средств, помогающих программисту в создании и управлении
различными интерфейсами пользователя. Эти системы обычно называют системами управления
пользовательским интерфейсом (UIMS - User Interface Management Systems), но предпочтительнее
называть их системами проектирования (UIDS - User Interface Development Systems), поскольку
UIMS ассоциируется только с частью системы, работающей во время исполнения программы (но
не с частью, используемой во время разработки), или с системами, включающими явные
компоненты управления диалогом. UIDS обеспечивает как разработку, так и реализацию
интерфейса и, таким образом, покрывает более широкий класс программ".

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

UIMS следует разрабатывать в условиях междисциплинарной кооперации экспертов с тем, чтобы
создавать, подгонять (приспосабливать), управлять и экспериментировать с (такие эксперименты
активно проводятся в m\$oft) взаимодействием между пользователем и прикладной программой
опосредованным интерфейсами различных стилей, разными устройствами и методиками
(техниками). Основной целью UIMS является освобождение программиста не только от
низкоуровневого программирования и заботы о непосредственном управлении устройствами
ввода/вывода, но и от проблем интерфейса, носящих не программный, а например, эстетический и
т.п., характер, которые являются вотчиной художников, дизайнеров интерфейсов, предметом
психологии, эргономики и т.п. Система обычно включает как составную часть набор
инструментов для обеспечения поддержки создания, отладки, тестирования и апробирования
интерактивных человеко-компьютерных систем. UIMS должна включать обстоятельное множество
инструментов дизайнера интерфейса. UIMS призвана снижать затраты на создание программного
обеспечения. Поскольку в UIMS акцент делается на описании, а не на кодировании, то UIMS
можно описывать как язык четвёртого поколения.

Важно чётко различать прикладного программиста и дизайнера пользовательского интерфейса.
Они могут быть одним и тем же лицом, но это совсем не обязательно. Разделение частей
пользовательского интерфейса и собственно приложения и является целью UIMS. Это разделение
делает возможным распределение функций прикладного программиста и дизайнера
пользовательского интерфейса между разными людьми. Также должно быть возможно
использовать различные интерфейсы с одним и тем же приложением.

Разработчик прикладного программного обеспечения использует UIMS, чтобы определить диалог
между пользователем и приложением, который не зависит от приложения. На приложение
налагается внешнее управление. Система управляет выводом приложения - его представлением на
устройстве вывода, и поддерживает используемые методы взаимодействия.

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

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

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

Требования к UIMS, критерии оценки

Множество требований, предъявляемых к UIMS, и критериев их оценки строится, исходя из
основной эталонной модели UIMS (см. рис.1). Эта модель представляет систему в виде двух
компонент: инструментария, используемого на стадии разработки диалога и части, относящейся ко
времени исполнения (run-time portion). UIMS обычно предоставляет способ управлять
последовательностью действий конечного пользователя. Структура диалога задается вне
прикладной программы.


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

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

Стадия разработки пользовательского интерфейса

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

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


либо через непосредственное манипулирование, либо через системы меню, либо на командной
основе (через командную строку). Выбор варианта из полученного множества - за дизайнером.

Явная семантика. Семантика приложения может быть выражена в поведении (в терминах
поведения) объектов и действий пользовательского интерфейса. Например, красный цвет
ассоциируется с риском, а зелёный - с безопасностью. Такие ассоциативные связи могут быть
выгодно использованы в интерфейсе. UIMS должна предоставлять возможность определять и по
мере необходимости позже изменять подобные зависимости (отношения).

Критерии разработки

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

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

Техника взаимодействия. UIMS должна поддерживать широкий диапазон приложений и
пользователей. UIMS должна также поддерживать широкий диапазон стилей взаимодействия: как


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

Далее мы будем использовать термин "графический ввод" для обозначения простого
распознавания символов; "стандартное меню" - для меню, которое видно на экране всегда.

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

Подгонка интерфейса. Предоставляет ли UIMS возможность настройки интерфейса конечным
пользователем или разработчиком? Управление настройкой может быть лексического уровня,
например, пользователь определяет, где и как расположены меню и другие интерактивные
графические объекты на экране, использовать ли для привлечения внимания пользователя
звуковой или световой сигнал. Управление может быть частью синтаксиса взаимодействия, т.е.
структура диалога может изменяться пользователем, с тем чтобы изменять существующие
команды, вводить новые, добавлять новые функциональные возможности в пользовательский
интерфейс.

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

Взаимоотношение пользовательского интерфейса и прикладного
кода

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


Управление системой может осуществляться как из
интерфейсной части (посредством UIMS), так и из прикладной части.

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

Разделение пользовательского интерфейса прикладной части. UIMS должна отделять прикладную
часть программы от интерфейсной. Должно быть возможно работать над этими частями
раздельно.

Осуществляет ли управление UIMS или приложение? Управление системой может осуществлять
либо UIMS - посредством управляющих действий со стороны интерфейсной части, либо
прикладная часть. Приложение может запрашивать у пользователя ввод, либо же инициатива во
взаимодействии принадлежит пользователю. Если управление принадлежит UIMS, то обычно она
вызывает прикладные модули по мере необходимости в ответ на действия конечного пользователя.
Такое управление можно назвать "внешним". Если управление всегда осуществляется из
прикладной части, то такое управление можно назвать "внутренним". Третий вид управления -
пользователь полностью управляет системой. Настоящая UIMS предоставляет средства для
осуществления внешнего управления, в то время как инструментарий предоставляет средства
только для создания системы с внутренним управлением.

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

Реализация

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


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

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

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

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

Сложность программирования. Использование таких возможностей, как интерактивный дизайн
диалога и пробная работа, избавляют разработчика диалогов от необходимости формального
программирования. Единственно необходимым остаётся только программирование прикладной
части системы. Ясен пень, если прикладная часть создаётся отдельно и другим человеком, то
дизайнеру интерфейса вообще не надо писать никаких программ. Эффективно интерфейс можно
было бы создать полностью средствами UIMS.

Система может быть формально описана в терминах языка типа BNF или же конечных автоматов.


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

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

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

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

Выражения и типы

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

Типы, определяемые пользователем. Прикладной программист или дизайнер диалога должны
иметь возможность пользоваться средствами языка программирования, на котором пишется
система (например, "C"), для создания различных структур данных, например, записей событий.

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


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

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

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

Взаимодействие с устройствами

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

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

Низкоуровневое управление. Иногда возникает необходимость управлять устройствами на низком
уровне из контекста языков высокого уровня. В ОС UNIX разработчик должен был бы
переделывать устройства в ядре, но это очень непросто сделать в UIMS. Возможно использование
низкоуровневого управления, чтобы получить отклик, который соответствует используемой
технике взаимодействия. UIMS должна быть достаточно мощной, чтобы было возможно описать
полный спектр интерактивных методик, но качество взаимодействия будет зависеть от того,
насколько низкого уровня управление графическими устройствами ввода-вывода может быть
использовано в диалоговой системе. Поддержка UIMS такой деятельности может оказаться весьма
полезной. Но необходимость в задании управления на таком уровне должна отсутствовать -
дизайнер не должен об этом думать, если он того не хочет.

Конкурирующие потоки ввода-вывода. UIMS сама должна управлять конкурирующими потоками


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

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

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

Диалоговая последовательность. Допускает ли UIMS неограниченную свободу движения по
диалогу? Диалог может быть "плоским" - так что большинство команд доступны во входной точке
диалога. Как только выбор сделан, этот путь должен быть завершён прежде, чем пользователь
вернётся ко входной точке. Диалог может быть:

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

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

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


Если UIMS не работает в
многооконной среде, то сможет ли она обеспечить одновременную работу множества приложений?
Даёт ли UIMS возможность использования в приложении многих окон? И если даёт, то допускает
ли она одновременный ввод и вывод во всех окнах? UIMS ведь может и предоставлять только
возможность ввода в одном окне и вывода - в другом. Если UIMS предоставляет приложению
множество окон, то может ли приложение каким-либо образом получить информацию, в какое
именно окно был произведён вывод.

X Window. Система X Window (или просто X), разработанная в MIT, заслужила
неимоверно широкую популярность, особенно в сообществе UNIX. В X базовая
оконная система предоставляет высокопроизводительную графику в иерархически организованное
множество окон изменяемых размеров. Вместо конкретного пользовательского интерфейса X
предоставляет набор примитивов, поддерживающих несколько стилей и придерживающихся
некоторых идеологий. В отличие от большинства оконных систем базовая система в X
определяется протоколом клиент-сервер: асинхронная потоковая (stream-based)
межпроцессная связь замещает традиционный интерфейс, построенный на подпрограммных и
системных ("ядерных") вызовах, предоставляя возможности использования распределённой
графики.

Использование X Windows в UIMS резко повышает её аппаратную и программную
переносимость.

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


может отнять много времени.

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

Связи низкого уровня

Это охватывает возможные связи (коммуникации, взаимодействия) UIMS с другими объектами
(процессами, операционной системой, etc.) в компьютерной системе.

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

Помощь

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

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

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

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

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

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

Классификация требований к UIMS, обобщения

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

поддержка пользователя разного уровня;

обеспечение обработки ошибок и восстановления.

Разработчик программного обеспечения:

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

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

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

упрощение разработки повторным использованием программных
компонент;

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

Конечный пользователь:

согласованность интерфейса по прикладным программам;

многоуровневая поддержка сопровождения или функций помощи;

поддержка процесса обучения;

поддержка расширяемости прикладных программ.
Эти цели определяют следующие функциональные характеристики UIDS/UIMS:

работа с входными устройствами;

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

обработка ошибок пользователя;

реализация обратной связи;

поддержка обновления/изменения данных прикладной задачи;

поддержка задач развития интерфейса;

синтаксическая поддержка.
Наиболее часто используется модель (в вышеозначен

ной классификации - третья ("смешанная")), введённая на конференции в Seeheim (1983), в
соответствии с которой UIMS состоит из трёх компонент:

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

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

получаемые в системе представления, в соответствии с синтаксисом
диалога;

модель интерфейса прикладной программы, представляющая семантику
диалога и управляющая функциональностью прикладной программы.
На её основе определяется структура эталонной модели UIDS/UIMS, представленная на
рис.1.

разработки...">

Рис.1. Уровни в системах разработки пользовательского
интерфейса

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

языковая;

графическая;

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

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

сети меню;

диаграммы состояний и переходов;

контекстно-свободные грамматики;

языки событий;

декларативные языки;

обычные языки программирования;

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

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


на экране (визуальное программирование, программирование демонстраций, программирование
по примерам). Она проста для использования не программистами, но:

трудна в реализации;

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

размещение на экране интерактивных средств

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

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

Возможные реализации:

создание интерфейса на основе списка процедур прикладной
программы (Mike);

создание интерфейса по типам параметров процедур (Control Panel
Interface);

создание интерфейса на основе определения семантики прикладной
задачи, описываемой на специальном языке (IDL).
Четвёртый подход связан с принципом, называемом "Direct Manipulation" - DM, рассматриваемым
в следующем разделе. Основное свойство этого подхода состоит в том, что пользователь
взаимодействует с индивидуальными объектами, а не со всей системой как единым целым.

"Непосредственное манипулирование" (DM - Direct Manipulation)

Во многих отношениях технология непосредственного манипулирования рассматривается как
новая генерация методов программирования в области проектирования интерфейса с
пользователем, имеющих такое же значение как разработка языка четвёртого поколения для
разработки баз данных. Начало этому подходу положили исследования, проводимые в центре Palo
Alto корпорацией Xerox (Xerox PARC).

Что же такое непосредственность? Можно выделить четыре аспекта этого понятия:

Семантическая непосредственность. Определяется через "расстояние" между пользовательскими
намерениями и операциями предоставляемыми системой. Пользователю важно, что:

в любое время он может передать свои намерения системе и

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

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

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

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

Формальная непосредственность. Этот аспект относится к естественности восприятия
(немедленной, непосредственной понимаемости) системного вывода, простоте и эффективности
обработки элементов ввода и устройств (клавиатура, кнопки, работа с мышью и т.п).


Увеличению
степени формальной непосредственности может способствовать использование представления в
виде пиктограмм при выборе объектов и функций вместо символических имён команд, хорошо
структурированный экран и понятное обозначение функциональных клавиш. Ещё одним важным
требованием является использование принципа "Что вы видите - то и получите" (WYSIWYG -
What You See Is What You Get), в соответствии с которым на экране формируется именно то
изображение, которое будет получено при конечной выдаче.

Компоненты DM интерфейса. На верхнем уровне DM систем обычно находится одна из метафор
графического представления (типа метафоры письменного стола, конкретный объект). Через этот
верхний уровень пользователю доступны прикладные программы, работающие на окнах. В окнах,
подокнах и компонентах экрана доступны различные средства выбора объектов, функций
инициирования и управления. Типичными компонентами используемыми для манипуляций с
объектами и управляющими функциями являются:

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

Управления (Controls): элементарные средства инициации функций
или ввода параметров. Например, Motif предоставляет следующие типы
управления:
>

кнопки различного вида (простые, радио, контрольные);
>

зоны (boxes) вывода, ввода, форматного ввода;
>

валюаторы (шкалы, . . .).

Меню: рассматриваемые как совокупность элементарных
управлений с типовой организацией (в Open Look меню есть просто набор
кнопок). Наиболее часто используемые типы меню: "выпадающие" (pull-down),
"выпрыгивающие" (pop-up) и каскадные.

Зоны диалога (Dialog boxes): для выдачи сообщений или ввода
подтверждения.
Другие компоненты DM интерфейса связаны с представлением информации, например, икон,


которые могут быть, а могут и не быть связаны с определённым поведением. Чаще всего их
поведение подобно кнопкам или представляет специфическое поведение объектов "письменного
стола".

Синтаксические моды и обратная связь

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

Требования к конструированию DM интерфейсов:

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

возможность создания новых типов технологий;

использования подходящего, простого в изучении

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

обеспечение семантической обратной связи,

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

выражение синтаксиса в терминах индивидуальных объектов.
Пример реализации UIDS/UIMS

В заключении приведём в качестве примера описание системы UIMS XFaceMaker3 фирмы Non
Standard Logics, созданной на базе OSF/Motif и X Window System.

Проектирование интерфейса. Пользователь создает интерфейс в интерактивном
режиме, используя предопределённые элементы - заготовки (Widgets).

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


предопределенную установку соответствующего выбора, в частности в зонах диалога.

Спецификация поведения интерфейса. Описывается на С-подобном командном языке
(Face). Динамика поведения интерфейса трактуется XFM3 как целостная часть вместе с
геометрическим представлением.

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

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

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

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

Эффективность конечного приложения. Результат проектирования реализуется двумя
способами: либо интерпретацией описания, аналогично режиму TRY, либо компиляцией
интерфейса вместе со всеми описаниями в С код.

Выведение

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

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



Рис. 2. Рекомендованная эталонная модель.

Имеется несколько открытых проблем в разработке UIMS, которые можно определить как:

эргономика взаимодействия;

управление диалогом;

отделение интерфейса пользователя;

сопровождение, мобильность и эффективность.
Пока не существует единственной стратегии конструирования UIMS.


Нужны эксперименты и
опыт. Сфера быстро развивающаяся, сулящая многочисленные выгоды.

Появившиеся стандарты (пока де-факто), по крайней мере на нижних уровнях систем (X-Window и,
в какой-то степени OSF/Motif), и активность разработчиков многих фирм дают надежду, что
ситуация в ближайшее время может измениться к лучшему.

Перспективы в области разработки человеко-машинных интерфейсов в настоящее время связаны,
главным образом, с такими направлениями развития новых информационных технологий, как:

системы мультимедиа;

экспертные системы;

системы виртуальной реальности;

вездесущие системы (ubiquitous);

. . .
Наиболее интересными и фантастическими являются вездесущие системы.

Исследованиями и разработками таких систем занимаются в ведущих центрах по изучению
человеко-машинного интерфейса, в частности, в Xerox PARC. Фундаментальные концепции
вездесущих систем были рассмотрены на конференции Еврографика'90 в приглашённом докладе
У.Ньюмана (Rank Xerox EuroPARC).

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

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

[]
[]
[]

Управление правами на доступ к ресурсам системы

Доступ к файлам на локальном компьютере

Доступ к сетевым ресурсам

Доступ к сетевым принтерам

Управление учетными записями

Назначение имени и пароля

Определение принадлежности к группам

Ограничение по месту регистрации

Ограничение по времени

Устройства архивирования информации

Тип НДЛ	Емкость	Скорость передачи данных	Скорость пересылки по шине	Коэффициент использования шины SCSI
4 мм 8 мм 8 мм 1/2" 9 дор. 1/4" QIC	5 Гб 2.3 Гб 5 Гб 120 Мб 150 Мб	920 Кб/c 220 Кб/c 500 Кб/c 780 Кб/c 200 Кб/c	5 Мб/с (синх.) 1.2 Мб/с (асинх.) 3 Мб/с (асинх.) 1.2 Мб/с (асинх.) 1.0 Мб/с (асинх.)	25 % 25 % 20 % 65-75 % 28 %

Возможности интеграции и направления развития

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

Открытая среда разработок клиент/сервер (CODE -
Clent/Server Open Development Environment)

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

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

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


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

исполнения тестов приложений.

Фирма	Название продукта
Software Quality Automation	TeamTest
Mercury Interactive	QA Partner
Seguie Software	PowerRunner
Softbridge	Automated Test Facility

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

Фирма	Название продукта
Chen & Assotiates	ER-Modeller
Intersolv	Excelerator
LBMS	System Engineer
Logic Works	ERwin/ERX
Visible Systems	Visible Analyst Workbench

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

Фирма	Название продукта
Greenberg & Russel	Object Start
PowerServ	PowerTOOL
ServerLogic	PowerClass
Visual Tools	Formula One, ImageStream, First Impression

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

Фирма	Название продукта
Hewlett Packard	Allbase/SQL, Image/SQL
IBM	DB2/2, DB2/6000
Informix	Online
Microsoft	SQL Server
Oracle	Oracle Server
Sybase	SQL Server, SQL Anywhere
Information Builders	EDA/SQL

?


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

Фирма	Название продукта
Gradient Technologies	Visual DCE
Tangent International	Distributed Computing Intergator for TopEnd
Tangent International	Distributed Computing Intergator for Tuxedo
Transarc	EncinaBuilder

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

Фирма	Название продукта
Lotus Development	Notes

У многих организаций сохранились информационные системы, разработанные для
больших ЭВМ. Различные продукты для доступа к данным позволяют интегрировать их в
PowerBuilder, не прибегая к низкоуровневому программированию.

Фирма	Название продукта
Attachmate Corp	Extra!
Wall Data	Rumba

Лидирующие производители систем управления документами и изображениями
участвуют в программе CODE, позволяя разработчикам интегрировать эти технологии с
приложенями на PowerBuilder.

Фирма	Название продукта
FileNet Corp	WorkFLO
Wang Laboratories	Wang OpenImage
Watermark Software	Watermark Discovery Edition

Централизованная система управления библиотеками объектов PowerBuilder
представляет собой открытую среду для групповой разработки приложений и управления проектом.
Предоставляются прямые связи из среды PowerBuilder к лидирующим системам управления объектами
и контроля версий для управления разработкой объемных приложений.

Фирма	Название продукта
Intersolv	PVCS
Legent Corp	Endevor
Mortice Kern Systems	RCS

Направления дальнейшего развития

Дальнейшее развитие PowerBuilder связывается с новой версии 5.0, которая должна появиться в первой
половине 1996 года.

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

Новая версия выйдет для платформ Windows 95, Windows NT, Windows 3.X и будет поддерживать
разработку как 32, так и 16 разрядных приложений. На платформе NT будут поддерживаться
двухбайтовые символы. Затем последуют версии PowerBuilder для UNIX и Macintosh. В новой версии
реализована полная поддержка элементов управления Windows 95, таких, как диалоги с закладками,
иерархические списки и т.д. Полностью поддерживается OLE 2.0.

Добавлена возможность построения многоуровневых приложений средствами PowerBuilder,
распределяя различные компоненты приложений по сети. Для передачи данных будут поддерживаться
протоколы Winsock, Named Pipes и Sybase Open Client/Server.

Расширены возможности PowerScript, пополнился список встроенных функций. Улучшены Окна
Данных, которые теперь смогут отображать информацию из базы данных непосредственно
используя элементы управления OLE (OCX) или в формате RTF.

Новая версия PowerBuilder обещает стать надежным основанием для разработок сложных приложений
клиент/сервер масштаба предприятия.

[]
[]
[]

Введение в PowerBuilder

PowerBuilder включает набор инструментов, обеспечивающих всестороннюю поддержку разработки
приложений: Интеллектуальный SQL (SQL Smart), Удобные объекты (Object Easy),
Коллективную разработку (Enterprise Enabled) и Интегрированную среду проектирования
(Developer Designed).

Интеллектуальный SQL (SQL Smart)

Поддержка множества СУБД

Интеллектуальный объект Окно данных (DataWindow), управляющий
взаимодействием с базами данных

Богатые возможности создания отчетов с использованием деловой графики

Мощные средства управления базами данных
Возможности SQL Smart, входящего в состав PowerBuilder, обеспечивают тесную интеграцию с
основной базой данных. PowerBuilder поддерживает широкий спектр систем управления
реляционными базами данных и полностью использует специфические особенности каждой из них.
Разработчики могут использовать встроенную высокопроизводительную реляционную базу данных
WATCOM SQL для создания автономных приложений, а также для обеспечения работы приложений
вне сервера.

Только PowerBuilder имеет объект Окно данных (DataWindow). Интеллектуальный объект
Окно данных позволяет манипулировать данными из реляционных баз данных без
программирования на SQL. С помощью Окна данных можно извлекать, обновлять, добавлять,
удалять, просматривать, печатать и сохранять данные в любом из 10 форматов файлов. Окно данных
непосредственно управляет взаимодействием и манипуляциями с базой данных.

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

комбинирования текстовой и графической информации.

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

Удобные объекты (Object Easy)

Наследование, инкапсуляция и полиморфизм

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

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

PowerBuilder включает графическую среду для создания определенных пользователем объектов,
событий и функций, которая значительно упрощает повторное использование кода и делает более
удобным сопровождение. Поддержка многоуровневого наследования облегчает разработку и
сопровождение библиотек объектных классов. Доступ к элементам управления других фирм, таким
как объекты VBX и C++, осуществляется прозрачно при помощи Художника объектов
пользователя (User Objects Painter).

Коллективная разработка(Enterprise Enabled)

Менеджер общей библиотеки объектов

Центральный репозиторий дизайна приложений

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


разработчиков информационных систем при помощи менеджера общей библиотеки объектов
(Common Object Library Manager) и центрального репозитория дизайна приложений (Central
Application Design Repository). Менеджер библиотеки осуществляет проверку при выдаче и возврате
(check-in/check-out) для предотвращения одновременного обновления одного объекта несколькими
разработчиками, предоставляет возможности поиска в библиотеках, анализирует взаимосвязи, а также
создает подробные отчеты для разработчиков по библиотекам и их компонентам. Менеджер
библиотеки может быть расширен для интеграции с инструментами лидеров CASE-индустрии
популярными системами контроля версий других фирм, таких как PVCS фирмы Intersolv Corporation,
позволяя разработчикам использовать уже сделанные инвестиции в эти продукты.

PowerBuilder также имеет центральный репозиторий дизайна приложений (Central Application Design
Repository), который доступен всему коллективу разработчиков и позволяет им определять
расширенные атрибуты таблиц и столбцов, такие как заголовки и метки. Центральный репозиторий
дизайна позволяет стандартизировать и ускорять процесс разработки приложений.

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

Интегрированная среда проектирования (Developer
Designed)

Полностью интегрированное окружение

Быстрая итеративная разработка

Поддержка Windows 3.X, Windows 95, Windows NT, работа под Unix, Macintosh

Мощный язык 4GL управления данными PowerScript

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


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

PowerBuilder - это быстрая итеративная среда разработки. Так как PowerBuilder имеет возможности
независимой компиляции, интегрированной отладки и тестирования, можно создать и отладить
приложение, не выходя из среды разработки.

PowerBuilder полностью поддерживает Microsoft Windows, включая все сообщения Windows, элементы
управления, многооконные приложения MDI (Multiple Document Interface), связывание и встраивание
объектов OLE (Object Linking and Embedding), динамический обмен данными DDE (Dynamic Data
Exchange) и вызовы динамически связываемых библиотек DLL (Dynamic Link Library) для интеграции
с существующими приложениями на PC. Графический интерфейс пользователя GUI (Graphical User
Interface) может быть создан разработчиком приложения без необходимости программировать на
низком уровне, например, на языке C, или использовать комплект разработчика программ Windows
SDK (Software Development Kit).

PowerBuilder содержит PowerScript - мощный, похожий на Basic, язык управления данными 4GL,
позволяющий разработчику легко включать простую и сложную деловую логику в приложения. Этот
язык состоит более чем из 100 функций для манипулирования объектами, числами и текстом, функций
обработки дат и времени, функций ввода/вывода, а также функций для полной поддержки OLE и DDE
как в качестве клиента, так и в качестве сервера. Инструмент, входящий в состав PowerBuilder, -
Художник функций (Function painter), позволяет разработчику легко расширять командный язык,
добавляя к нему определяемые пользователем функции. Внешние функции можно декларировать,
после чего они становятся доступными в приложениях PowerBuilder так же, как и встроенные функции,
что позволяет взаимодействовать с внешними процедурами на 3GL, которые работают на сервере или
клиенте.

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

Выполнение по предположению (speculation)

Пример:

for (p=head; p <>
nil; *p=*p.next) {

*p.value =
*p.value+1;

}
Последовательность команд:

J looptest

start: LW R5,0(R4)

ADDI R5,R5,#1

SW 0(R4),R5

LW R4,4(R4)

looptest: BNEZ R4,start
Однажды развернутый цикл:

J looptest

start: LW R5,0(R4)

ADDI R5,R5,#1

SW 0(R4),R5

LW R4,4(R4)

BNEZ R4,end

LW R5,0(R4)

ADDI R5,R5,#1

SW 0(R4),R5

LW R4,4(R4)

looptest: BNEZ R4,start

end:

Взаимодействие серверного и клиентского приложений

Задачами серверного приложения являются:

получение от клиентского приложения текста SQL запроса,

исполнение указанного SQL запроса,

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

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

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

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

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

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

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

Клиентское приложение, получив транзакцию об окончании асинхронного запроса к
серверному приложению, анализирует переданный серверным приложением признак. Если,
согласно признаку, получены еще не все данные, то клиентское приложение посылает повторный
запрос на передачу данных серверному приложению. Серверное приложение, получив транзакцию,
производит идентификацию клиентского приложения по идентификатору канала. Если, согласно
статусу клиентского приложения, оно ожидает дополнительные данные, то серверное приложение
извлекает из таблицы регистрации идентификатор SQL запроса и продолжает получение
результатов этого, ранее выполненного запроса. Далее взаимодействие серверного и клиентского
приложений происходит как и в пункте 4. Пункт 5 повторяется до момента передачи всего
полученного результирующего множества от серверного к клиентскому приложению. По
завершению этой передачи строка таблицы регистрации занимаемая клиентским приложением
освобождается и в графу статуса помещается признак "свободна".

Клиентское приложение закрывает канал и деинициализирует себя в библиотеке
DDEML.

Windows NT - эффективный сервер приложений

Microsoft BackOffice

SQL Server,

SNA Server,

SMS Server,

Exchange Server,

Internet Information Server

Приложения третьих фирм

Informix, Oracle, Gupta, SAP, Platinum...

Windows NT Server - современная 32-разрядная сетевая ОС

Архитектура клиент-сервер

Поддержка Win16, Win32, DOS, OS/2, POSIX

Поддержка многоплатформенности и многопроцессорности

Intel, Alpha, MIPS, PowerPC

стандартная версия - до 4 процессоров

максимум - 32 процессора

X Window

X Window или просто X - это система для создания графического
пользовательского интерфейса, изначально - на компьютерах, работающих под управлением ОС
UNIX. X была создана в MIT (Масачусетский Технологический Институт). В
настоящее время уже выпущена версия 11.6 (X11R6) и активно идёт подготовка к выпуску версии
7.

Особенностью X Window является её архитектура - она построена по схеме клиент--сервер.
Взаимодействие X-клиента и X-сервера происходит в рамках соответствующего
протокола прикладного уровня - X-протокола. X Window безразличен
используемый транспорт, которым может быть служить как локальный UNIX -socket, так
и любой сетевой, например, TCP. Это означает, что X-клиент и X-сервер могут
"проживать" и на разных компьютерах, т.е. программа может осуществлять ввод-вывод
графической информации на экране другого компьютера, причём, различия в архитектуре X-
клиента и X-сервера не играют никакой роли - это обеспечивается стандартом X-
протокола. Система обеспечивает графический вывод на экран машины, воспринимает
сигналы от устройств ввода, таких, как клавиатура и мышь, и передаёт их программам. Следует
отметить, что устройство вывода может иметь более одного экрана. X обеспечивает вывод
на любой из них. Всё это: экран (экраны), устройства ввода (клавиатура, мышь) называется в
терминах X Window - дисплей.

Благодаря своей архитектуре X Window свободно используется в распределённых
вычислительных системах, например, в сетях TCP/IP (internet).

X позволяет пользователю (за дисплеем) общаться со многими программами
одновременно. Чтобы вывод из них не смешивался, система создаёт на экране дисплея
"виртуальные подэкраны" - окна. Каждое приложение (как правило) рисует только в своём окне
(или своих окнах). X предоставляет набор средств для создания окон, их перемещения по
экрану, изменения их размеров, вывода в них и т.п.

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

Система стандартизует способ задания ресурсов приложений, управления ими, и содержит ряд
процедур для работы с ними. Эта совокупность функций называется "менеджер ресурсов" (Xrm -
X resource manager). "Хранилище" параметров программы называется базой данных
ресурсов.

X функционирует согласно идеологии управляемости событиями (event-driven architecture)
- она организует общение между самими программами и между программами и внешней средой
посредством событий. Событие есть единица информации, идентифицирующая происходящие в
системе изменения или действия. По идентификатору события можно получить информацию о нём
- вид события, его характеристики, где оно произошло и т.п..

Общее устройство X Window

Система X Window представляет собой совокупность программ и библиотек. "Сердцем" её
является специальная программа - X-сервер. Это отдельный UNIX -процесс,
имеющий место быть на компьютере, к которому присоединён дисплей. Именно сервер знает
особенности конкретной аппаратуры, знает, что надо предпринять, чтобы вывести какой-либо
графический объект, например, примитив, на экран. Он же умеет воспринимать и обрабатывать
сигналы, приходящие от клавиатуры и мыши.

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

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


Система предоставляет стандартную библиотеку процедур, с
помощью которых программы осуществляют доступ к услугам X

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

X окно

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

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

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

X Window позволяет программе создавать несколько окон одновременно. Они связаны в
иерархию, в которой одни являются "родителями", а другие - "потомками". Сам сервер на каждом
экране создаёт одно основное окно, являющееся самым верхним "родителем" всех остальных окон.
Это окно называется "корневым" (root).

Управление окнами

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

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


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

при создании окна X могут быть переданы "рекомендации" (hints) о
начальном положении окна, его геометрии, минимальных и максимальных
размерах и т.д.;

можно использовать встроенный в X способ общения между
программами - механизм "свойств".
Графические возможности X Window

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

Значение пикселя не задаёт цвет точки на экране непосредственно, но задаёт номер ячейки в
специальном массиве, в которой и хранится значение цвета, т.е. значение пикселя задаёт номер
цвета в текущей палитре.

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

"Свойства" и атомы

В X Window встроены средства для обеспечения информацией между программами-
клиентами. Для этого используется механизм "свойств" (properties). "Свойство" - это
информационная структура, связанная с некоторым объектом, например, окном, доступная всем
клиентам X. Каждое свойство имеет имя и уникальный идентификатор - атом. Обычно,
имена свойств записываются большими буквами. Атомы используются для доступа к содержимому
свойств с тем, чтобы уменьшить объём информации, пересылаемой между клиентами и X
сервером.

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

Некоторые свойства и соответствующие им атомы являются предопределёнными и создаются в
момент инициализации сервера.

[]
[]
[]

В докладе дан краткий обзор

В докладе дан краткий обзор информационной арxитектуры систем на основе объектной
теxнологии и принципов интероперабельности компонентов, развиваемыx OMG.

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

В ходе решения поставленной задачи - реализации информационно-поисковой системы
библиотечного типа - был проделан следующий объем работ:

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

Во-вторых, была разработана схема функционирования системы и на основе ее анализа
реализовано архитектурное решение системы.

В третьих, была проведена реализация системы с использование языков C, HTML и SQL.

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

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

[]
[]
[]

Защищенность Windows NT

Сертифицирована на соответствие уровню С2

Контроль за доступом ко всем ресурсам

Регистрация доступа к ресурсам

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

Гибкое администрирование прав пользователей и доступа к ресурсам



    Программирование: Языки - Технологии - Разработка

• Программирование
  
• Технологии программирования
  
• Разработка программ
  
• Работа с данными
  
• Методы программирования
  
  
• IDE интерфейс
  
• Графический интерфейс
  
• Программирование интерфейсов
  
• Отладка программ
  
• Тестирование программ
  
  
• Программирование на Delphi
  
• Программирование в ActionScript
  
• Assembler
  
• Basic
  
• Pascal
  
  
• Perl
  
• VBA
  
• VRML
  
• XML
  
• Ada
  
  
• Lisp
  
• Python
  
• UML
  
• Форт
  
• Языки программирования
  

---

---