Автоматизированный метод корпоративной стандартизации процесса разработки систем на платформе Oracle Designer 6i.

УДК  681.31

Автоматизированный метод  корпоративной стандартизации процесса разработки систем на платформе Oracle Designer 6i.

В.И.Виноградов, Н.А. Кудинов

 

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

 

Проблема разработки программного обеспечения быстро, в срок и с  удовлетворительным качеством стоит  перед компьютерным сообществом уже давно. Еще в 70 годы Брукс в своей книге “Мифический человеко-месяц” [1] обозначил одну из основных проблем при создании программного обеспечения – нехватка времени.

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

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

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

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

Сокращение времени, затрачиваемого на разработку ПО, достигается за счет того, что наличие стандартов разработки позволяет:

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

Рассматриваемая задача может быть формализована следующим образом.

Постановка задачи

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

Пусть A- множество объектов проверки: A = , где A_i - множество однотипных объектов проверки. P-множество ограничений, описываемых набором предикатов: для и a A_i, P_i(a)->{ 0,1}

Задача, поставленная в данной работе – формализация процесса контроля за выполнением требований корпоративной  стандартизации в процессе разработки программного обеспечения включает:

• разработку формальных правил кодирования или требований, предъявляемых к исходному программному коду, что выражается в составлении системы предикатов стандартизации – { P_i };
• алгоритмизация процедур контроля соблюдения требований корпоративных стандартов, которые выражается в вычислении функции оценки качества удовлетворения требований корпоративных стандартов кодирования;
• алгоритмизация исправления типовых ошибок нарушения требований стандартизации, что выражается в определении набора функций корректировки ошибок H: H_i(a) = a*  таких, что P_i (a*)= 0, P_j(a) = 1, где a и a* A_i.

 

 

Система предикатов правил корпоративной  стандартизации

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

• Стандарт обработки ошибок на клиенте и сервере. Обеспечивает выработку единого стиля сообщений об ошибках, а также обеспечение конечного пользователя разработанных систем полной информацией о возникшей ситуации.
• Стандарт на правила формирования наименований. Описывает требования к формированию наименований таблиц, их полей, процедур, функций, переменных, констант и т. д. Улучшает читабельность и предотвращает типичные ошибки.
• Стандарт на написание клиентского и серверного кода. Описывает требования к написанию прикладными программистами исходного кода. Такие требования улучшают читабельность программ и предотвращают некоторые типовые ошибки кодирования.
• Стандарт на правила обработки транзакций. Описывает требование на использование операторов commit и rollback в PL/SQL-коде.

 

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

 

 A₁, где A₁ - множество зарезервированных слов языков SQL и PL/SQL.

P₁(a)= { 0, если ACSII(‘a’)<=ASCII(a_i)<=ASCII(‘z’) для 1<=i<=length(x),

1, в противном случае}

Все служебные зарезервированные  слова SQL и PL/SQL пишутся строчными (маленькими) буквами.

 

 A₂, где A₂ - множество идентификаторов таблиц и полей в таблицах и курсорах.

P₂(a)= { 0, если ACSII(‘A’)<=ASCII(a_i)<=ASCII(‘Z’) для 1<=i<=length(x),

1, в противном случае}

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

 

 A₃, где A₃ - множество идентификаторов типов данных, определенных пользователем.

P₃(a)= { 0, если substr(a,1,5) = ‘type_’,

1, в противном случае}

Идентификаторы типов данных, определенных пользователем, должны начинаться с префикса (type_).

 

 A₄, где A₄ - множество идентификаторов локальных констант.

P₄(a)= { 0, если substr(a,1,2) = ‘c_’,

1, в противном случае}

Идентификаторы локальных констант должны начинаться с префикса (c_)

 

 A₅, где A₅ - множество идентификаторов глобальных констант.

P₅(a)= { 0, если  substr(a,1,3) = ‘gc_’,

1, в противном случае}

Идентификаторы глобальных констант должны начинаться с префикса (gc_).

 

 A₆, где A₆ - множество идентификаторов локальных переменных.

P₆(a)= { 0, если substr(a,1,2) = ‘v_’,

1, в противном случае}

Идентификаторы локальных переменных должны начинаться с префикса (v_)

 

 A₇, где A₇ - множество идентификаторов глобальных переменных.

P₇(a)= { 0, если substr(a,1,3) = ‘gv_’,

1, в противном случае}

Идентификаторы глобальных переменных должны начинаться с префикса (gc_).

 

 A₈, где A₈ - множество идентификаторов локальных курсоров.

P₈(a)= { 0 если substr(a,1,4) = ‘curs_’,

1, в противном случае}

Идентификаторы локальных курсоров должны начинаться с префикса (curs_)

 

 A₉, где A₉ - множество идентификаторов глобальных курсоров.

P₉(a)= { 0, если substr(a,1,5) = ‘gcurs_’,

1, в противном случае}

Идентификаторы глобальных курсоров должны начинаться с префикса (gcurs_).

 

 A₁₀, где A₁₀ - множество идентификаторов параметров процедур и функций.

P₁₀(a)= { 0, если substr(a,1,2) = ‘p_’,

1, в противном случае}

Идентификаторы параметров процедур и функций начинаются с префикса  (p_).

 

 A₁₁, где A₁₁ – множество исходных кодов процедур и функций.

P₁₁(a)= { 0, если в теле программы есть вызов KRN_Trace.Start_Proc, KRN_Trace.End_Proc, Exception when others then krn_trace.Error_Handler(),

1, в противном случае}

Тело каждой процедуры и функции  должно начинаться вызовом пакетной процедуры KRN_Trace.Start_Proc с именем соответствующей  процедуры в качестве аргумента и заканчиваться вызовом пакетной процедуры   KRN_Trace.End_Proc.

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

 

 A₁₂, где A₁₂ – множество исходных кодов триггеров.

P₁₂(a)= { 0, если в теле программы есть вызов KRN_Trace.Start_Trigger, K KRN_Trace.Start_Trigger,

1, в противном случае}

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

 

 A₁₃, где A₁₃ – множество исходных кодов процедур, функций или триггеров в которых используется оператор return .

P₁₃(a)={ 0, если в теле программы есть вызов KRN_Trace.End_Proc или KRN_Trace.End_Trigger перед оператором return,

1, в противном случае}

Перед обращением к оператору return в теле процедуры, функции или  триггера должен быть вызов пакетной процедуры    KRN_Trace.End_Proc или KRN_Trace.End_Trigger.

 

 A₁₄, где A₁₄ – множество исходных кодов курсоров.

P₁₄(a)={ 0, если в теле программы не используются переменные ,

1, в противном случае}

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

 

 A₁₅, где A₁₅ – множество исходных кодов процедур и функций.

P₁₅(a)={ 0, если в теле программы не используются переменные ,

1, в противном случае}

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

 

 A₁₆, где A₁₆ – множество исходных кодов процедур и функций и триггеров.

P₁₆(a)={ 0, если в теле программы нет оператора select .. into ,

1, в противном случае}

В триггерах, пакетах, процедурах и  функциях все операторы SELECT желательно выполнять в виде курсоров

Система контроля исходного кода на соответствие стандартам

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

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

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

Архитектура такого программного комплекса  представлена на рисунке 1.

Рисунок 1. Архитектура системы  контроля соблюдения требований стандартизации

 

Составными частями этой архитектуры являются следующие элементы.

Расширенная БНФ – грамматика языка  программирования, для которого вводится система стандартов кодирования. Грамматика языка записывается в расширенной  форме Бэкуса-Наура.

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

Классы проверки - множество классов, написанных на языке Java, реализующих  правила проверки.

XML-описание проекта – документ, в формате XML, содержащий структурированное описание проекта.

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

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

File2Xml – преобразователь файлов  проекта из файлового репозитория  в cпециализированное XML-описание  проекта для возможности дальнейшей  проверки.

Oracle Database Dictionary – словарь базы данных Oracle, содержащий описание проекта во внутренем формате Oracle Database.

Ora2Xml - преобразователь из словаря  Oracle Database в cпециализированное XML-описание  проекта для возможности дальнейшей  проверки.

Oracle Designer Dictionary – репозиторий средства разработки Oracle Designer, в котором хранится описание проекта в формате Oracle Designer.

Des2Xml - преобразователь описания  проекта из репозитория Oracle Designer в cпециализированное XML-описание проекта для возможности дальнейшей проверки

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

Xml2Html – компонент  преобразования  файла результата проверки в  HTML формат.

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

Схемы контроля

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