СУБД Oracle

Глава 17. Метрики, макеты и спецификации

 
 

В процессе проектирования любой системы наступает момент, когда руководитель проекта начинает преследовать вас вопросами наподобие следующих: "Сколько времени понадобится на генерацию этих модулей?", "Какими средствами вы будете пользоваться для их генерации?" И это еще в лучшем случае. Если же вам не повезет, то руководство к этому моменту уже ответит на эти вопросы к своему полному удовлетворению и перед вами встанет воистину невыполнимая задача — сделать так, чтобы предсказания руководства сбылись! (В этой главе мы попытаемся помочь вам справиться с этой задачей.)

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

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

Эта глава посвящена основам "черной магии" проектирования кода — оценке трудоемкости, составлению спецификаций и макетированию.

 

Разработка метрик проектирования и генерации модулей

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

В большинстве качественно выполняемых проектов оценку времени производят дважды:

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

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

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

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

• простой;

• средний;

• сложный;

• очень сложный.

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

Что же такое метрики? Это просто таблицы плановой трудоемкости (в человеко-днях) для каждого уровня сложности и каждого средства разработки которое будет использоваться при программировании. В табл. 17.1 мы разбили метрики на три задачи: проектирование программы, генерация и автономное тестирование.

Таблица 17.1. Примерные метрики для Oracle Forms 4.0/4.5

Oracle Forms 4/4.5

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

Генерация

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

Простой

Средний

Сложный

Очень сложный

1

3

5

6-10

1

4

10

11-15

1

3

7

8-20

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

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

• соответствующий уровень квалификации разработчиков;

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

• использование (или неиспользование) генераторов кода;

• соответствие среды разработки (аппаратные средства, программное обеспечение, сеть);

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

К сведению

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


Рис. 17.1. Влияние сложности на трудоемкость в зависимости от типа средства разработки

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

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

 

Изгнание мегамодулей

В следующих разделах мы опишем, в каких формах проявляется влияние мегамодулей. Грустно, но мегамодульная экранная форма, или форма-супермен, — весьма распространенная особенность интерактивных систем. В этих случаях часто обнаруживается, что одной формой поддерживается несколько прикладных функций. Например, в одном знаменитом приложении на базе Oracle Forms нам посчастливилось быть свидетелями того, как все DML-операции (кроме операций сопровождения справочных таблиц) содержались в одном триггере ON-COMMIT дьявольской сложности. В качестве оправдания говорилось, что так нужно пользователям. Однако причиной появления одного из нас на этом узле являлись постоянные жалобы пользователей на плохую производительность и недостаточную надежность этой экранной формы. В результате первым этапом нашей работы стало выяснение того, что пользователи хотят, чтобы приложение работало не так. Другой случай: один гордый разработчик показал нам приложение, разработанное в одной форме Oracle с 70 экранными страницами!

Предупреждение

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

 

Пакетная обработка

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

В качестве исторической справки заметим, что стандартная процедура проектирования пакетных процессов для систем с НМЛ в 60-х и начале 70-х годов предусматривала последовательный проход по главному файлу с порождением ряда последовательных (как предполагалось, более коротких) файлов для управления остальными этапами процесса. В мегамодуле мы выполняем всего-навсего такую дилетантскую работу, как создание наборов последовательных данных для последующей обработки; однако делаем все это мы в одном месте.

Ключ к реализации такого задания — построение управляющей структуры для основного цикла и последующее жесткое отделение (инкапсуляция) каждого действия, выполняющегося на каждой итерации цикла. Это позволяет модифицировать только одно из действий без воздействия на остальные. Для программиста может быть совершенно очевидно, что шаг 24 выполняется только в тех случаях, когда на шаге 17 выполняется определенное условие. Однако всем заинтересованным лицам (и особенно группе обслуживания) будет гораздо легче жить, если вы не обеспечите полную оптимизацию и не сделаете так, что шаг 17 оставит свое заключение в каком-то потайном месте, откуда его сможет взять шаг 24. Самое простое решение — заставить и шаг 17, и шаг 24 проверять базу данных на предмет выполнения вышеупомянутого условия (если повезет, то весь требуемый SQL-код и данные будут еще находиться в SGA). Если из-за того, что на этих шагах теперь приходится выбирать одни и те же данные для принятия того же самого решения, возникает серьезная проблема с эффективностью, то принятие этого решения следует инкапсулировать в процедуру, которая будет регистрировать (незаметно для этих шагов) факт выполнения необходимой обработки.

 

Отчеты

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

 

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

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

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

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

 

Следует ли выполнять макетирование?

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

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

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

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

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

 

Макетирование средствами УРП

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

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

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

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

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

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

• Итеративный процесс нужно держать под контролем, и он должен иметь четкие цели. Слишком часто он становится предметом споров между разработчиками, аналитиками и пользователями. Они спорят о том, кто же сможет предложить самую классную новую штуковину для реализации в будущем интерфейсе, забывая о потребностях бизнеса, для которого это приложение создается. В какой-то момент нужно подвести черту и сказать: "Это то, что нужно". Один из способов установить лимит времени для этого процесса — использовать ограничения временными рамками, упомянутые в главе 1. Еще один способ — установить для каждой экранной формы фиксированное число итераций, после которого изменения принимаются только при очень убедительном обосновании.

• Пользуясь возможностями современных средств разработки четвертого поколения и УРП, достаточно легко придать данным привлекательный внешний вид — программа-художник позволяет "нарисовать" все, что нужно показать на экране. Но это, однако, не все. За кулисами таких экранных форм находится (или в конечном итоге будет находиться) база данных Oracle. Вы должны быть уверены, что она поддерживает структуры, которые так легко "рисовать", и мы рекомендуем на самом деле выбирать все данные, отображенные в макетах, а не просто предполагать, что выборка возможна, и жестко программировать ее. Мы должны рассматривать базу данных как неустойчивую на период макетирования; она разрабатывается средствами УРП вместе с экранными формами. К сожалению, этот метод проектирования БД не всегда дает наилучший результат.

Проектировщики должны при разработке макетов постоянно помнить обо всех этих недостатках. Необходимо совершенствовать свои навыки генерации, потому что проектирование и генерация при разработке средствами УРП тесно переплетены. Вряд ли имеет смысл производить все итерации отдельно, а затем передавать результаты для генерации окончательного варианта, ведь на этот момент будет выполнено 90% всего объема работы.

Если вы хотите больше узнать о том, как корпорация Oracle относится к использованию УРП в среде Oracle, почитайте книгу CASE Methods FastTrack: A RAD Approach (Dai Clegg, Richard Barker. Addison Wesley, 1994).

 

Макетирование при разработке без использования средств УРП

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

• оно помогает проектировщикам понять, как будет работать система (и будет ли);

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

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

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

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

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

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

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

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

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

Завершая наш разговор о макетах, воспользуемся словами из рекламы фирмы Nike — Just Do It! ("Сделайте же это!") Записки, спецификации и электронно-почтовые сообщения не очень помогают, когда приходится объяснять свои предложения пользователям и пытаться привлечь их к процессу разработки. Создание же макета — стоящее дело, особенно если этот макет относительно невелик в сравнении со всей системой. Может быть, стоит даже получить формальное одобрение результатов макетирования со стороны участвующих в проекте пользователей.

 

Где мои спецификации? Принципы разработки спецификаций модулей

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

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

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

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

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

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

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

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

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

• наняться на работу программистом и написать работающий код или

• перейти на работу в другую отрасль.

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

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

Пример 17.1. SQL-предложение, замаскированное под описательный текст, в фрагменте спецификации

Select the Quantity and Customer Name from the Order Items, Order and Customers table, where the Customer Number on the Order table matches that on the Customers table for the Customer already retrieved...

В примере 17.2 показан еще один вариант — трата времени и бумаги на то, чтобы рассказать разработчикам о том, чего им объяснять не нужно. Программисты, работающие с 3GL, знают, что для обработки наборов данных создается цикл и что в конце цикла нужно дать программе указание выйти из цикла и сделать что-то еще. Если же вам приходится объяснять программистам такие вещи, это значит, что вам нужны не длинные спецификации, а другие программисты.

Пример 17.2. Лишние инструкции в спецификации

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

В хорошей спецификации модуля должны быть перечислены таблицы и столбцы, к которым производится доступ, и указано, какие столбцы запрашиваются, вставляются, обновляются и удаляются, а какие — используются в условиях WHERE. Как мы уже упоминали, эту структуру иногда называют CRUD-матрицей, поскольку в ней указываются столбцы, данные в которых будут создаваться (CREATE), читаться {READ), обновляться (UPDATE) и удаляться (DELETE). Большинство CASE-средств, поддерживающих определение модулей, рассчитаны на получение информации такого рода и, как правило, содержат средства для ее ввода. Огромное достоинство этих матриц (особенно при использовании CASE-средств) состоит в том, что они позволяют оценить предлагаемые изменения в БД, обратившись к спецификации модуля и посмотрев, какие модули это изменение затронет.

Наконец, следует пересмотреть спецификацию каждого модуля в свете всех проектных решений и стандартов. Необходимо учесть взаимодействие между модулем и правилами, введенными как объекты базы данных, причем особый акцент следует сделать на обеспечении нормального интерфейса с пользователем. Например, приемлемо ли для пользователя потратить пару минут на ввод данных лишь для того, чтобы все они были при фиксации отклонены с сообщением Check constraint SYS_00023 violated? Вероятно, нет. Приемлемое решение, наверное, предусматривает ряд шагов и, возможно, включает шаблон кода для обработки ошибок, генерируемых ПО Oracle Server.

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

 

Описание экранных форм и отчетов

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

• сведения о том, что делает данная экранная форма или отчет, например, Change of Customer Status ("изменение статуса покупателя") или Aged Debt Analysis Summary ("аналитическая сводка по просроченным долгам");

• данные о навигации (откуда вызывается, что вызывает);

• список параметров (какие присутствуют входные параметры, каковы их значения по умолчанию);

• описание обработки (какие события могут происходить внутри модуля, как они обрабатываются);

• список ошибок (какие ошибки генерируются во время обработки и каковы их последствия);

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

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

 

Описание пакетных процессов

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

• формулировка функции, выполняемой данным отчетом, например, Change of Customer Status ("изменение статуса покупателя") или Aged Debt Analysis Summary ("аналитическая сводка по просроченным долгам");

• список параметров (какие нужны входные параметры, каковы их значения по умолчанию);

• восстановление (что делать, если обработка задания прекращается на полпути);

• блокировка (использование блокировок уровня таблицы или предварительных блокировок, чтобы задание не задерживалось);

• несовместимость (с оперативными функциями или другими пакетными подпрограммами);

• регистрация (где ведется журнал);

• ожидаемое состояние базы данных до и после прогона;

• ошибки (какие ошибки могут генерироваться во время обработки);

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

Более подробно пакетная обработка рассматривается в главе 20.

СУБД Oracle

(время поиска примерно 20 секунд)

Знаете ли Вы, что объектно-ориентированное сборочное программирование - это разновидность сборочного программирования:
- основанная на методологии объектно-ориентированного программирования; и
- предполагающая распространение библиотек классов в виде исходного кода (obj) или упаковку классов в динамически компонуемую библиотеку (dll).

НОВОСТИ ФОРУМАФорум Рыцари теории эфира
Рыцари теории эфира
 01.10.2019 - 05:20: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вячеслава Осиевского - Карим_Хайдаров.
30.09.2019 - 12:51: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Дэйвида Дюка - Карим_Хайдаров.
30.09.2019 - 11:53: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Владимира Васильевича Квачкова - Карим_Хайдаров.
29.09.2019 - 19:30: СОВЕСТЬ - Conscience -> РУССКИЙ МИР - Карим_Хайдаров.
29.09.2019 - 09:21: ЭКОНОМИКА И ФИНАНСЫ - Economy and Finances -> КОЛЛАПС МИРОВОЙ ФИНАНСОВОЙ СИСТЕМЫ - Карим_Хайдаров.
29.09.2019 - 07:41: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Михаила Делягина - Карим_Хайдаров.
26.09.2019 - 17:35: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Андрея Пешехонова - Карим_Хайдаров.
26.09.2019 - 16:35: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> Проблема государственного терроризма - Карим_Хайдаров.
26.09.2019 - 08:33: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от О.Н. Четвериковой - Карим_Хайдаров.
26.09.2019 - 06:29: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Ю.Ю. Болдырева - Карим_Хайдаров.
24.09.2019 - 03:34: ТЕОРЕТИЗИРОВАНИЕ И МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ - Theorizing and Mathematical Design -> ФУТУРОЛОГИЯ - прогнозы на будущее - Карим_Хайдаров.
24.09.2019 - 03:32: НОВЫЕ ТЕХНОЛОГИИ - New Technologies -> "Зенит"ы с "Протон"ами будут падать - Карим_Хайдаров.
Bourabai Research Institution home page

Боровское исследовательское учреждение - Bourabai Research Bourabai Research Institution