Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 2 3 4 [5]   Вниз
  Печать  
Автор Тема: Разработка технических заданий и спецификаций программных продуктов.  (Прочитано 94399 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Alf
Гость
« Ответ #120 : 22-04-2006 18:36 » 

Alf, ты про это:
Цитата
-  Требования к справочной системе и документации
упомянул, только вскользь. Случайно или преднамеренно?

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

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

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

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

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #121 : 22-04-2006 18:45 » 

Цитата
- диаграммы устойчивости UML.
Второй раз замечаю, и такое название мне не знакомо. Каково английское название?
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Alf
Гость
« Ответ #122 : 22-04-2006 20:15 » 

Цитата
- диаграммы устойчивости UML.
Второй раз замечаю, и такое название мне не знакомо. Каково английское название?

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

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

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

Записан
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #123 : 23-04-2006 07:01 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Alf
Гость
« Ответ #124 : 23-04-2006 10:50 » new

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

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

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

Кроме того, для изображения граничных, сущностных объектов и контроллеров традиционно применяются особые пиктограммы, отличающиеся от изображения классов на других видах диаграмм. Но это как раз невеликая беда, поскольку всегда можно создать для них стереотипы со своими картинками. А вот автоматический контроль за соблюдением правил - вещь куда более нужная.
Записан
Страниц: 1 2 3 4 [5]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines