Работа суперскалярного конвейера
| Тип команды | Ступень конвейера | |||||||
| Целочисленная команда | 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 |
версии. Каждый интерфейс использует все преимущества (например хранимые процедуры, расширения
языка 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 к лидирующим системам управления объектами
и контроля версий для управления разработкой объемных приложений.
| Фирма | Название продукта |
| 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 обещает стать надежным основанием для разработок сложных приложений
клиент/сервер масштаба предприятия.
[]
[]
[]
в 1959 г. на конференции
Когда впервые в 1959 г. на конференции UNESCO по обработки информации г. Стречи предложил
режим разделения времени при решении задач на компьютерах - с этого момента принято
отсчитывать начало интерактивных вычислений и, следовательно, исследование человеко-
машинного интерфейса. По мере роста мощности компьютеров росли и затраты на диалоговую
компоненту программного обеспечения. Вопрос эффективности использования машин обострился
во время стремительного выхода на рынок рабочих станций, объединивших интерактивность с
графикой. Термин эффективность с тех пор изменил свое значение - если раньше он отражал такие
характеристики как процессорное время и объем занимаемой памяти, то теперь под ним понимают
простоту разработки, легкость сопровождения и удобство работы с программой. Поэтому затраты
на исследование и разработку пользовательского интерфейса являются оправданными.
Разработка любого прикладного программного обеспечения, как правило, подразумевает создание
пользовательского интерфейса. Поскольку большинство современных пользовательских
интерфейсов основываются на аналогичных идеях (активное использование "мышки",
ориентированность на объекты, графика и т.д. - имитация процессов и явлений, возможность
использования алгоритмов, знакомых каждому человеку из его обыденной жизни), то существует
возможность и необходимость разработки вспомогательного программного обеспечения,
предназначенного для создания такого рода "стандартных" интерфейсов, точнее их базисов.
С другой стороны, много- и разнообразие аппаратных и системных платформ, на которых должно
будет работать это программное обеспечение, требует его переносимости на уровне исходного
кода. Вышеизложенные требования логически приводят к идее переносимого унифицированного
программного инструментария для создания пользовательских интерфейсов или, если
рассматривать конечный прикладной программный продукт, системы (модуля, блока), которая
ведает (заведует, заправляет, обслуживает, управляет) интерфейсом с пользователем.
Можно проклассифицировать такие инструментарии ( User Interface tools) согласно схеме:
Текстовые экранные системы (curse, ncurse, etc).
Графические экранные системы.
Многооконные системы (WMS):
символьно-ориентированные (текстовые);
графические;
UI toolkits
традиционные;
объектно-ориентированные;
UIDS - User Interface Development System - система разработки
пользовательского интерфейса (инструментарий);
UIMS - User Interface Management System - система (управления)
пользовательского интерфейса (программный модуль - составная часть
конечного продукта в совокупности с соответствующей UIDS);
UIDE - User Interface Development Environment - среда разработки
пользовательского интерфейса.
Эта схема не претендует на систематическую классификацию, скорее - это просто перечисление.
В настоящее время большие усилия прикладываются к разработке методов и созданию
инструментальных средств в рамках систем, получивших название UIMS - User Interface
Management System.
Введение в 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
Контроль за доступом ко всем ресурсам
Регистрация доступа к ресурсам
Сложные механизмы предотвращения несанкционированного доступа
Гибкое администрирование прав пользователей и доступа к ресурсам
