Разработка технических заданий и спецификаций программных продуктов.

[Alf]

Alf, ты про это:

-  Требования к справочной системе и документации

упомянул, только вскользь. Случайно или преднамеренно?

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

В моей практике, как правило, Заказчику передается два документа:

1. Руководство системного администратора - документ, в котором описаны подготовка к инсталляции продукта, сам процесс инсталляции, а также процедуры обслуживания продукта, восстановления после сбоев и т.д.

2. Руководство оператора - документ, в котором детально описан процесс работы конечного пользователя с программой (или программами), если программа предполагает интерактивное взаимодействие с оператором.

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

Что касается справочной подсистемы, то разработка полноценной контекстно-ориентированной справки со всеми гипертекстовыми наворотами настолько трудоемка (пожалуй, сравнима с разработкой самой программы), что Заказчик обычно не настаивает на ее включение в состав продукта, не желая нести дополнительные издержки, так что этот вопрос для меня скорее носит теоретический характер. Обычно руководства оператора оказывается достаточно.

[Dimka]

- диаграммы устойчивости UML.

Второй раз замечаю, и такое название мне не знакомо. Каково английское название?

[Alf]

- диаграммы устойчивости UML.

Второй раз замечаю, и такое название мне не знакомо. Каково английское название?

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

У меня как раз сейчас приятель проредил библиотеку по UML, осталось не так много. Из того, что осталось, нашел эти диаграммы в книге Дуга Розенберга и Кендалла Скотта "Применение объектного моделирования с использованием UML и анализ прецедентов". Правда, в этой книге переводчик назвал их "диаграммами пригодности", в большинстве других книг я встречал термин "диаграммы устойчивости".

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

[Dimka]

Alf, такие диаграммы видел и знаю, но полагал их частной разновидностью Collaboration Diagram. Приму к сведению.

[Alf]

Они как раз где-то посередине между диаграммами классов и кооперации, Дуг Розенберг считает их частным случаем диаграммы классов... Однако, мне кажется,  имеет смысл выделить их в отдельную категорию диаграмм, поскольку им присущ ряд дополнительных ограничений. В честности, должны выполняться четыре основные правила:

1. Актеры могут общаться только с граничными объектами.
2. Граничные объекты могут общаться только с контроллерами и актерами.
3. Сущностные объекты могут общаться только с контроллерами.
4. Контроллеры могут общаться с граничными объектами, сущностными объектами и другими контроллерами, но не с актерами.

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

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