Эбберс М. Введение в современные мейнфреймы: основы z/OS

Подождите немного. Документ загружается.

242 Глава8

81 Проектировщики и программисты приложений

Задачи проектирования (designing) и разработки (developing) приложения достаточ-

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

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

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

какое место каждая из них занимает в общем представлении о стандартном жизнен-

ном цикле разработки приложений в z/OS.

Проектировщик приложений отвечает за определение наилучшего программного

решения для важного бизнес-требования. Успех любого проектирования зависит,

в том числе, и от знания проектировщиком работы предприятия, осведомленности

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

мировании и проектировании баз данных и понимания аппаратного и программно-

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

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

Кроме того, в этом процессе задействована роль аналитика бизнес-систем. Этот

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

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

и т. д.), чтобы определить бизнес-требования к приложению. Подобно проектиров

щику приложения аналитику бизнес-систем нужно иметь широкое понимание биз-

нес-целей организации и возможностей информационной системы.

Проектировщик приложений принимает тре-

бования от аналитиков бизнес-систем и конечных

пользователей. Кроме того, проектировщик опре-

деляет, какие информационные ресурсы должны

быть доступны для поддержки приложения. Затем

проектировщик приложения составляет техническое задание для реализации про-

граммистами приложений.

Программист приложений отвечает за разработку и поддержку приложений. Дру-

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

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

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

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

сколько итераций изменений кода и компиляций, компоновки приложений и модуль-

ного тестирования.

В процессе разработки проектировщик и программист должны взаимодейство-

вать с другими ролями на предприятии. Программист, например, часто работает

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

модулей приложения.

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

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

нения тестов приложения должны пройти приемочное тестирование сообщест-

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

ваниям.

Приложение–

наборфайлов,составляющих

программноеобеспечениедля

пользователя

 Проектированиеиразработкаприложенийдляz/OS 243

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

ние и доработку существующих мэйнфрейм-приложений компании. В действитель-

ности, это часто является основной задачей для многих современных программистов

мэйнфрейм-приложений. Несмотря на то, что для создания новых программ для

мэйнфреймов все еще используется COBOL (Common Business Oriented Language)

и PL/I, такие языки как Java набирают популярность точно так же, как и на распреде

ленных платформах.

82 Проектирование приложения в z/OS

На ранних этапах проектирования проектировщик приложения принимает реше-

ния относительно свойств приложения. Эти решения основываются на множестве

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

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

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

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

и его ограничений.

Проектирование приложения для z/OS вклю-

чает множество этапов, используемых при проек-

тировании приложений для других платформ,

включая распределенную среду. Тем не менее, z/OS

включает некоторые особые аспекты. В этой главе

представлено несколько примеров решений, при-

нимаемых проектировщиком приложений z/OS в процессе проектирования опреде-

ленного приложения. Этот список не является исчерпывающим, а скорее предназна-

чен для того, чтобы дать вам представление о процессе.

• «Проектирование для z/OS: пакетная или оперативная обработка?».

• «Проектирование для z/OS: источники данных и методы доступа».

• «Проектирование для z/OS: требования к доступности и рабочей нагрузке».

• «Проектирование для z/OS: обработка исключений».

Помимо этих решений, другими факторами, воздействующими на проектирова-

ние приложения для z/OS, могут быть выбор одного или нескольких языков програм-

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

аспекты:

• использование наборов символов для мэйнфреймов в разделе «Использование

набора символов EBCDIC»;

• использование интерактивной среды разработки (interactive development envi-

ronment, IDE) в разделе «Использование средств разработки приложений»;

• различия между языками программирования обсуждаются в главе 9, «Исполь-

зование языков программирования в z/OS».

Помните, что лучше всего заниматься проектированием, постоянно помня о ко-

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

к проектированию.

Проектирование–

задачаопределения

наилучшегопрограммного

решениядляопределенного

бизнес-требования

244 Глава8

821 Проектирование для z/OS:

пакетная или оперативная обработка?

При проектировании приложения для z/OS и мэйнфрейма основной вопрос заклю-

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

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

ство приложений можно спроектировать в соответствии с любой из этих парадигм.

Тогда как проектировщику определить, какой подход следует использовать?

Существуют следующие причины для выбора пакетной или оперативной обра-

ботки:

• Причины для выбора пакетной обработки:

данные хранятся на ленте;

транзакции передаются для ночной обработки;

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

• Причины для выбора оперативной обработки:

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

требования к быстрому времени реагирования.

822 Проектирование для z/OS: источники данных и методы доступа

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

• Какие данные требуется сохранять?

• Каким образом будет осуществляться доступ к данным? Это включает выбор

метода доступа.

• Являются ли запросы произвольными или предсказуемыми?

• Будет ли выбрана PDS, VSAM или система управления базами данных (СУБД),

например, DB2?

823 Проектирование для z/OS: требования к доступности

и рабочей нагрузке

Относительно приложения, которое будет выполняться в z/OS, проектировщик дол-

жен быть способен ответить на следующие вопросы:

• Для какого количества данных требуется осуществлять хранение и доступ?

• Есть ли необходимость совместного доступа к данным?

• Каковы требования к времени реагирования?

• Каковы ограничения стоимости для проекта?

• Сколько пользователей будут одновременно осуществлять доступ к прило-

жению?

Каковы требования к доступности приложения (24 часа в день / 7 дней в неделю

или от 8:00 до 17:00 в рабочие дни и т. д.)?

 Проектированиеиразработкаприложенийдляz/OS 245

824 Проектирование для z/OS: обработка исключений

Могут ли возникнуть какие-либо необычные ситуации? Если да, тогда нужно учиты-

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

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

83 Жизненный цикл разработки приложения: обзор

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

требованиям (решающих определенные задачи). Решение может находиться на лю-

бой платформе или сочетании платформ, с точки зрения оборудования или опера-

ционной системы.

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

в z/OS обычно состоит из нескольких этапов:

• этап проектирования:

сбор требований – требования к пользователям, аппаратному и програм-

мному обеспечению;

выполнение анализа;

разработка структуры за несколько итераций:

 высокоуровневая структура;

 подробная структура;

• передача структуры программистам приложения;

• кодирование и тестирование приложения;

• выполнение пользовательских тестов – пользователь тестирует приложение

на функциональность и практичность;

• выполнение системных тестов:

выполнение интеграционного теста (тестирование приложения с исполь-

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

продолжают работать должным образом);

выполнение теста производительности (нагрузочного теста) с использова-

нием рабочих данных;

• перенос в рабочую среду – передача операционному персоналу – убедитесь

в том, что имеется вся документация (по обучению пользователей, операцион

ные процедуры);

• этап сопровождения – непрерывные повседневные изменения и усовершенс-

твования приложения.

На рис. 8.1 представлена схема процесса на

различных этапах жизненного цикла разработки

приложения.

На рис. 8.2 представлен этап проектирования до момента начала разработки. Пос-

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

передавать программные требования программистам приложений.

Разработка–

написание,тестирование

ипоставкаприложения

246 Глава8

Сбор

требований

Анализ

Проектирова-

ние

Кодирование

и тестирование

Пользова-

тельские

и системные

тесты

Перенос

в рабочую

среду

Обслуживание

Рис 81 Жизненныйциклразработкиприложения

Требования

Пользователи

Анализ

Проекти-

рование

Проектные

документы

Технические

Проверка

Пересмотр Пересмотр

Проверка

Ограничения

Бизнес

Рис 82 Этаппроектирования

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

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

и повторного тестирования, как показано на рис. 8.3.

Проектные

документы

Кодирование

Тестирование

Пересмотр

Протести-

рованные

программы

Рис 83 Этапразработки

После тестирования программ программистами они подлежат серии формальных

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

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

для проверки функционирования приложения в составе крупной инфраструктуры

(рис. 8.4).

 Проектированиеиразработкаприложенийдляz/OS 247

Рис 84 Тестирование

Последний этап жизненного цикла разработки состоит в переносе в рабочую

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

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

включает документацию по обучению пользователей и операционным процедурам.

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

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

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

В рабочей среде изменения и усовершенствования осуществляются группой (воз-

можно, той же группой программистов), выполняющей обслуживание. В этой точке

жизненного цикла приложения изменения строго контролируются и должны тща-

тельным образом тестироваться перед реализацией в рабочей среде (рис. 8.5).

Перенос

в рабочую

среду

Рабочее

хранилище

Финальные

протестиро-

ванные

программы

Рис 85 Рабочаясреда

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

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

любой платформе или сочетании платформ. Как показано на рис. 8.6, наше приложение

может находиться в любой из трех сред: в Интернете, в сети предприятия или на цент-

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

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

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

248 Глава8

и какими средствами будут достигаться цели проекта. Для этого проводятся собесе-

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

участниками.

Базы данных

бизнес-систем

Приложения

бизнес-систем

Интерфейс

бизнес-систем

Просмотрщик

Сервер

Персональный

компьютер

«немой» терминал

Просмотрщик

Сервер

приложений

Сервер

приложений

Электронный

бизнес

Электронный бизнес

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

старых систем

Клиент-сервер

Графический

интерфейс

Терминальная

обработка

Центральный узел

Веб-

сервер

Веб-

сервер

Персональный

компьютер

Интернет Сеть предприятия

Рис 86 Сложностьрастущейинфраструктуры

Результаты этих собеседований должны передаваться на все последующие этапы

жизненного цикла проекта приложения. На определенных этапах проекта требуется

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

их требования и что наше решение соответствует их требованиям. На этих этапах

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

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

831 Сбор требований для проектирования

При проектировании приложений существует множество способов классификации

требований, в частности: функциональные требования, нефункциональные требова-

ния, новые требования, системные требования, требования обработки, ограничения

по разработке и операциям.

Компьютерные приложения работают с данными, расположенными в некотором

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

 Проектированиеиразработкаприложенийдляz/OS 249

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

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

Такое простое описание включает множество процессов и множество операций, имею-

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

Несмотря на то, что каждый проект приложения представляет особый случай

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

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

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

ную систему, но и потому, что они являются частью одной инсталляции, подключен-

ной к одним и тем же внешним системам.

Одна из проблем, с которой сталкиваются сис-

темы в целом, состоит в том, что компоненты раз-

бросаны по разным машинам, разным платфор-

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

ту в среде серверной фермы (server farm).

Важное преимущество подхода zSeries состоит в том, что обслуживание приложе-

ний может выполняться с использованием инструментов, имеющихся на мэйнфрей-

ме. Некоторые из этих инструментов мэйнфреймов позволяют различным платфор-

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

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

Ниже представлен список различных типов требований приложения. Элементы

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

• возможность доступа;

• восстанавливаемость;

• удобство обслуживания;

• доступность;

• безопасность;

• подключаемость;

• цели производительности;

• управление ресурсами;

• практичность;

• частота резервного копирования данных;

• портативность;

• веб-службы;

• модифицируемость;

• возможность взаимосвязи;

• предотвращение отказов и анализ сбоев.

84 Разработка приложения на мэйнфрейме

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

приложения. Программисту не дается полная свобода; наоборот, он должен придер-

живаться спецификаций проектировщика. Однако учитывая, что проектировщик,

Платформа–

частоотносится

коперационнойсистеме,

означаяиОС,иаппаратное

обеспечение(среду)

250 Глава8

скорее всего, не является программистом, могут потребоваться изменения из-за ог-

раничений при программировании. Но на данном этапе проекта речь идет не об из-

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

проектировщик указал ей делать.

Процесс разработки является итеративным и обычно осуществляется на уровне

модулей. Программист обычно следует приведенной ниже процедуре.

1. Разработка модуля.

2. Тестирование функциональности модуля.

3. Внесение исправлений в модуль.

4. Повторение с шага 2 до успешного выполнения.

После тестирования модуля он утверждается и фиксируется; в этом случае, если

в него впоследствии будут вноситься изменения, он будет снова тестироваться. После

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

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

Этот процесс повторяется до тех пор, пока не будут разработаны и протестирова-

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

рования после завершения разработки, на самом деле тестирование постоянно вы-

полняется на этапе разработки.

841 Использование набора символов EBCDIC

Наборы данных z/OS имеют кодировку EBCDIC (Extended Binary Coded Decimal In-

terchange). Она представляет собой 8-разрядный набор символов, разработанный

до того, как такой набор символов ASCII (American Standard Code for Information

Interchange) стал общепринятым. С другой стороны, файлы z/OS UNIX имеют ко-

дировку ASCII.

Большинство знакомых вам систем используют ASCII. Важно знать о различиях

в схемах кодировки при перемещении данных с ASCII-систем на EBCDIC-системы.

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

эмулятора 3270, выполняющегося на PC в TSO-сеанс. Однако при передаче программ

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

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

символами, например, с символом OR (|) или с логическим не (not), и программист

должен проверить итоговое значение преобразованного символа.

Список символов в наборах EBCDIC и ASCII представлен в Приложении D, «Табли-

ца EBCDIC – ASCII», которое может быть полезным в этом обсуждении. И ASCII,

и EBCDIC являются 8-разрядными наборами символов. Различие состоит в способе

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

Символ EBCDIC ASCII

A 11000001(x'C1') 01000001(x'41')

B 11000010(x'C2') 01000010(x'42')

a 10000001(x'81') 01100001(x'61')

1 11110001(x'F1') 00110001(x'31')

пробел 01000000(x'40') 00100000(x'20')

 Проектированиеиразработкаприложенийдляz/OS 251

Несмотря на то, что назначение битов в ASCII может выглядеть более логичным,

имеется огромное количество существующих данных в кодировке EBCDIC и огромное

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

всех существующих данных и программ в кодировку ASCII неосуществимым.

Набор символов имеет последовательность сортировки, соответствующую двоич-

ному значению битов символов. Например, A имеет меньшее значение, чем B

и в ASCII, и в EBCDIC. Последовательность сортировки важна для сортировки, а также

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

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

наборах символов имеет следующий вид:

EBCDIC ASCII

Наименьшеезначение:

пробел пробел

знакипрепинания знакипрепинания

нижнийрегистр

цифры

верхнийрегистр верхнийрегистр

Наибольшеезначение:

цифры нижнийрегистр

Например, в EBCDIC «a» меньше, чем «A», тогда как в ASCII «a» больше, чем «A».

Цифровые символы меньше любой буквы алфавита в ASCII, однако больше любой

буквы в EBCDIC. A-Z и a-z представляют собой две непрерывные последовательности

в ASCII. В EBCDIC существуют промежутки между некоторыми буквами. В ASCII, если

отнять A от Z, получится 25. Если отнять A от Z в EBCDIC, получится 40 (в связи с про

межутками в двоичных значениях между некоторыми буквами).

Преобразование простых текстовых строк между ASCII и EBCDIC выполняется прос-

то. Ситуация усложняется, если преобразуемый символ отсутствует в стандартном на-

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

(not), используемый в одном из основных языков программирования для мэйнфреймов

(PL/I); в наборе символов ASCII нет соответствующего символа. Подобным образом не-

которые символы ASCII, используемые в программировании на языке C, отсутствовали

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

Все еще существует некоторая путаница в связи со знаком цента (¢) и символом крышки

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

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

ров символов (DBCS) главным образом для азиатских языков. Такие же наборы сим-

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

В традиционном программировании для мэйнфреймов не используются специ-

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

волы и символы новой строки (или пары символов CL/LF). Не существует понятий

двоичного и текстового файла. При правильном программировании байты могут

интерпретироваться как относящиеся к EBCDIC, ASCII или другой кодировке. При

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

их как EBCDIC-символы, так как принтер чувствителен к набору символов. Веб-сервер

z/OS Web обычно сохраняет ASCII-файлы, так как данные будут интерпретироваться

браузерами на PC, ожидающими ASCII-данных. Если никто не будет пытаться распе-

чатывать ASCII-файлы на принтере мэйнфрейма (или выводить их на терминале

3270), системе все равно, какой набор символов используется.