Как конкретно попасть на дизайн документа?

Question

Я создаю проектный документ для подсистемы безопасности, который будет написан на C ++. Я создал диаграмму классов и диаграммы последовательности для основных случаев использования. Я также указал открытые атрибуты, ассоциации и методы для каждого из классов. Но я еще не детализировал определения методов до уровня C ++. Поскольку я новичок в C ++, как и другой разработчик, мне интересно, не имеет ли это смысла идти дальше и указывать на этот уровень. Мысли?

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

Answer 1

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

Answer 2

Я бы сказал, что в этом нет никакого смысла, и что вы уже зашли слишком далеко. Если вы новичок в C ++, вы не в состоянии написать детальный проектный документ для проекта C ++. Я бы порекомендовал вам попробовать реализовать то, что у вас уже есть в C ++, учиться на неизбежных ошибках (например, открытых атрибутах), а затем вернуться и пересмотреть это.

Answer 3

Поскольку вы новичок, вероятно, имеет смысл , а не , чтобы углубиться в детали.

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

Answer 4

Это действительно зависит от того, на кого ориентирован проектный документ. Если это босс нетехнический, значит, вы хороши в том, что имеете.

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

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

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

РЕДАКТИРОВАТЬ: я много работаю в PHP, и я на самом деле использую PhpDoc для разработки документации, просто записывая сигнатуру метода без реализации, а затем помещая подробное описание того, что метод должен делать в заголовке метода Комментарии. Это поможет любому, кто использует мой класс в будущем, потому что дизайн - это документация. Я также могу изменить документацию, если мне нужно внести некоторые изменения во время кодирования.

Я много работаю в php4, поэтому не могу использовать интерфейсы. В php5 я создаю интерфейс, а затем внедряю его в другом месте.

Answer 5

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

Answer 6

Как и все остальные говорят, вы прошли мимо того, что вам нужно сделать с дизайном. У вас есть хороший набор требований к простому уровню утверждения «истина / ложь», из которого вы вывели этот дизайн? Вы можете проектировать весь день, но если у вас нет требований, которые просто говорят, ЧТО вы собираетесь делать, не имеет значения, насколько хорош ваш дизайн.

Answer 7

Вы уже достаточно далеко продвинулись в части документации. Поскольку вы все еще новичок в C ++, когда вы понимаете язык, вы можете изменить структуру своей программы. Тогда вам придется внести изменения в документацию. Я бы предположил, что вы уже зашли слишком далеко с документацией. Не нужно углубляться в это