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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 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? Вероятно, нет. Приемлемое рещение, наверное, предусматривает ряд шагов и, возможно,