Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Методология решения задач проектирования ПС по Г. Майерсу

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

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

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

Решение задачи.

  • 1. Поймите задачу:
    • • изучите данные;
    • • изучите неизвестные;
    • • достаточно ли данных для решения;
    • • не противоречивы ли они.
  • 2. Составьте план:
    • • чего вы должны добиваться;
    • • какие методы проектирования будут использоваться;
    • • встречалась ли вам уже такая задача;
    • • не знаете ли вы близкой (подобной) задачи;
    • • можете ли вы воспользоваться ее результатом;
    • • можете ли вы решить более специализированную или аналогичную задачу;
    • • можете ли вы решить часть задачи.
  • 3. Выполните план:
    • • следуйте своему плану решения задачи;
    • • проверяйте правильность каждого шага.
  • 4. Проанализируйте решение:
    • • все ли данные вы использовали;
    • • проверьте правильность решения;
    • • можете ли вы воспользоваться полученным результатом или примененным методом при решении других задач?

Рассмотрим кратко элементы этой схемы. Худшая из ошибок, которые могут быть сделаны при решении задачи, - не вполне разобраться в ее постановке. Чтобы хорошо понять задачу, нужно уяснить два ее компонента: данные и неизвестное. Данные - это все факты, касающиеся задачи, и связи между фактами неизвестными. Уяснение всех данных о сложной задаче - абсолютно неизбежная и большая работа. При этом в первую очередь необходимо охватить общую картину данных без деталей, которые, однако, тоже запоминаются «в сторонке», чтобы их можно было легко вспомнить позже. Это позволяет увидеть общую картину и определить место каждой детали.

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

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

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

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

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

Явно выделенным этапом всякого процесса проектирования должна быть проверка правильности результатов, т.е. попытка найти ошибки перевода, возникшие в этом процессе. Стоимость исправления ошибки тем ниже, чем раньше она обнаружена [5, 6]. К тому же вероятность правильного исправления ошибки на ранней стадии работы над проектом значительно выше, чем в случае обнаружения ошибки на более поздних этапах.

Последовательность решения задачи

Рис. 4.2. Последовательность решения задачи

Майерс предлагает сформулировать общую философию проверки в виде правила «А'- плюс - минус один». Вопрос первостепенной важности при проверке - привлечение к этому подходящих людей. Наиболее подходящие люди - это те, в чьих интересах обнаружить все ошибки. Правило «И плюс - минус один» состоит в следующем: проверка правильности фазы N проекта должна осуществляться проектировщиками фаз А^+ 1 иЫ- 1. В основе философии правильности проверки лежит утверждение, что всякий процесс проверки правильности (тестирования) должен иметь разрушительный, даже садистский характер [11]. Цель должна состоять в том, чтобы обнаружить любой мыслимый дефект, любую слабость в проекте, а не в том, чтобы просмотреть проект и показать, что он правилен.

 
<<   СОДЕРЖАНИЕ   >>