Здравствуйте, bkat, Вы писали:

B>Здравствуйте, slava.4e, Вы писали:

S4>>Здравствуйте, bkat, Вы писали:

B>>>Здравствуйте, slava.4e, Вы писали:

S4>>>>В общем, буду рад если кто нибудь поделится опытом, как это сделать наиболее красиво, эффективно и при этом не разбивая на тысячу разных документов.

B>>>Общий подход — использование так называемых alternate/exception flow, как часть описания варианта использования.
B>>>Т.е. вasic flow лучше не перегружать особенностями исключительных, специальных ситуаций.

S4>>Т.е. лучше в начале представить базовый сценарий, с его описанием, а потом нарисовать alternative flow, с указанием альтернативных веток и их описанием?

B>Именно так.

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

B>Что значить абстрактны?
B>Use Case штука очень конкретна и показывает поведение системы с точки зрения пользователя.
B>О каких параметрах и сообщениях ты говоришь?
B>Не пытаешься ли ты смешать варианты использования с деталями реализации?

Как я говорил выше, я почти впервые с этим столкнулся. И, как любой, новоиспеченный, выпускник ВУЗа, я имею весьма расплывчатые представления о документации. Так что, я был бы рад, если бы ты показал где можно почитать про виды, формы и предназначение документов, необходимых для девелоперовских и инженерных задач. Если, конечно, они где нибудь сведены в один документ/статью.
В общем я не очень представляю что такое детали реализации .
Я говорю о параметрах, что передаются, например, в SIP, при создании конференций. Таких, как: Conf URI, какие то параметры в XML, в сообщениях NOTIFY, и прочие идентификаторы, параметры и значения заголовков.
Про то что Use Case это штука с точки зрения пользователя, я понял когда прочитал две книги, описывающие принципы его написания. Но мне надо что то в этом духе, только на уровне протоколов, в моем случае это HTTP и SIP.

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

B>Короче для начала я бы попытался ответить на вопрос кому вообще нужна эта документация
B>и для каких целей. Предположим что варианты использования
B>вам нужны чтобы специфицировать систему для девелоперов и тестеров.
B>У нас в этих случаях варианты использования используются только как иллюстрация формальных спецификакий.
B>В стандартном случае рисуется GUI Mockup.
B>По нему создаются описания вариантов использования (обычный текст).
B>Ну и далее следует набор формальных спецификаций (тоже обычный текст).
B>В большинстве случаев такого набора достаточно, чтобы понять что должна делать система.
B>В тривиальных или специальных случаях Mockup'ы или варианты использования опускаются.

Когда я вплотную занялся этим вопросом, читал различные форумы и статьи, я понял что нет какого то общего понимания, у большинства, и что это является огромной проблемой при разработке. Так что, как минимум, теперь, она нужна лично мне, что бы получить опыт, представление и понимание. Этакий вклад в борьбу с безграмотностью
Нам нужно следующее: документ, который описывает все возможные ситуации, на уровне протоколов сигнализации. Что бы потом, по этим Use Case, написать логику для Application Server и тестовые спецификации. Т.е. документ должен описывать сценарии, сообщения, и указать на важные параметры, на которых "завязана" логика.

B>В общем я не совсем уверен, в чем у тебя затруднения, но сдается мне,
B>что ты опускаешься в ненужных детали реализации.
B>Скорей всего поэтому и получается объемно и необозримо.

Ну, по большей части, затруднения в отсутствии опыта в написании документации
Кстати, большое спасибо за отзывчивость!