span.fullpost {display:none;} span.fullpost {display:inline;}

суббота, 12 ноября 2011 г.

Работа с предметной областью при выполнении задания по RSLцификация)

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

Представьте, что Вы разработчик, Вам дают ТЗ, Вы должны с ним ознакомиться и реализовать то, что там написано. Представим ситуацию, Вы прочли задание и говорите: "Мне всё ясно". "Отлично", говорит заказчик, и Вы уходите работать. Когда всё готово, приходит заказчик, смотрит, что получилось, "щупает" его в разных местах - и, о, он высказывает кучу замечаний (он хотел по-другому, он подразумевал другое) ! Неужели получилась плохая работа? Или вот другой случай. Вы уходите разрабатывать систему и через некоторое время выясняется, что в ТЗ одно требование противоречит другому или в ТЗ мелькают слова "интуитивно понятные", но лишь обманчиво понятные, а на деле - совершенно непонятные! И приходится останавливать работу или, что еще хуже, приходить к мысли, что сделанное ранее надо "выкидывать в мусор", оно не соответствует реальному пониманию технического задания.

Не знаю, как Вам, а вообще-то так вести разработку неправильно. Затратно и неприятно. Было бы здорово, если основную массу дефектов в ТЗ кто-то обнаружил и исправил заранее (на самом деле, не исправил, а обнаружил, задал вопрос заказчику и на основе него исправил ТЗ, только вот, что спрашивать?). В практическом задании по RAISE Вам предлагается (в частности) выполнить функции такого "Робин Гуда". Вы должны сделать всё, чтобы разработка по точно сформулированному Вами заданию прошла без возражений к логике работы системы. Т.е. точно сформулировать требования, постановку задачи, увидеть все скрытые ранее логические зависимости понятий (эти зависимости должны быть отслежены в реализации). Требования удобно писать в виде алгебраической спецификации, потому что Вы просто синтаксически не сможете выразить какие-либо реализационные домыслы, не относящиеся к логике работы системы.

Итак, надо подумать и выразить в спецификации следующие моменты:
  • понятия, с которыми работает программа, обладают "особыми значениями" (или даже классами "особых значений"); это такие значения, на которых операции с этими понятиями должны работать принципиально по-разному; увидели такие значения - оформите их должным образом в спецификации;
  • Ваша программная система должна заинтересовывать наибольший круг пользователей; поэтому она должна удовлетворять потребностям как можно большего числа пользователей, использующих ее в разных условиях, но так, как описано в задании.
"Вгрызайтесь" в постановку задачи, пытайтесь представить всяких пользователей и в каких ситуациях они захотят использовать программу, выискивайте особые случаи, выискивайте особые виды данных, которые надо обрабатывать иначе, и, конечно, следите за совместностью и полнотой спецификации, которую Вы пишете. Предметная область, в которой должны работать программа, на самом деле намного сложнее, чем кажется на первый взгляд. Из-за такой "псевдоочевидности", первой мысли "мне всё ясно", в последствии приходится переделывать, вносить в программу то, что не было учтено сразу. А если еще и код написан так, что казалось бы очевидная его модификация ломает его "в других местах", то нужность предварительного анализа постановки задачи, не правда ли, становится еще более очевидной.