Ввиду того что появилось желание узнать что такое на самом деле успешное проектирование  и грамотный программный код решил изучить UML.
После прочтения первых 3 глав Фаулера останавливаюсь на подробном изучении USE CASE феномена.
Прошу побольше критики и советов! Очень помогут. Системка маленькая, но думаю для начального этапа достаточно.


Описываю систему сбора, разделения сетевого трафика.
Использую программу gaphor под линукс, если посоветуете лучше то скажу спасибо еще раз

Краткое описание
Актеры:
net-acct – внешняя система сбора трафика с роутеров. Запускается каждые 2 минуты. Работает как демон.

Варианты использования:
<Запись трафика> – Записывает данные которые сгенерировал актер net-acct в таблицу БД
Данный use case включает <Фильтрация по направлениям >

<Фильтрация по направлению> – Фильтрует записанный трафик по направлениям (внешний мир, местная сеть, мусор и т. д.)

<Поиск клиента по IP> – Осуществляет поиск клиента по IP адресу (IP адрес выделяется при подключении клиента к системе и является статическим).

<Подсчет стоимости перелимита> – Данный Вариант использования расширяет базовый (Поиск клиента по IP) при условии что клиент был найден. В данном варианте использования 
осуществляется поиск установленного тарифа у клиента (Видимо нужно было это вынести в отдельное ВИ и не делать все так общее) и считается перелимит.

<Списания денежных средств> – Этот вариант использования расширяет базовый (<Подсчет стоимости перелимита>) в точке где проверятся сумма к списанию и списывает сумму (amount)

С Новым годом!

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

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

Теперь, конкретно.

Модельный элемент actor (в русскоязычном RUPе - субъект):
- определяет внешние границы системы (выполняет действия вне системы и обменивается с системой информацией)
- (первичный actor) имеет цель, которой он хочет достигнуть с помощью системы

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

Фактически, я вижу всего один большой и сложный use case с условным названием "Учет трафика и списание денежных средств со счета клиента". (Как название - не годится, но, кажется, отражает суть.)

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

Не нужно пытаться использовать диаграмму прецедентов, чтобы показать, как работает система. Для этого в UML есть другие средства, в том числе, краткие текстовые описания прецедентов.
Когда Вы перейдете к другим главам замечательной книжки Фоулера, Вы о них узнаете.

Есть синтаксические ошибки.

Спецификация UML допускает только следующие виды отношений между прецедентами: включение, расширение и обобщение (герерализация). Ассоциация между прецедентами "Запись трафика" и "Поиск клиента по IP" недопустима.
Двунаправленные ассоциации в UML не рисуют (их на диаграмме две).
Названия субъектов пишутся с заглавной буквы.

Желаю успехов!

Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru

Когда Вы перейдете к другим главам замечательной книжки Фоулера, Вы о них узнаете.

Значит все же я не до конца понял когда использовать диаграммы прецедентов, т.к. данную схему следовало бы рисовать как диаграмму деятельности. Это мое мнение.

Спасибо, будем углубляться в диаграммы прецедентов.

UML - это язык. Разговаривать на нем можно грамотно, и не очень.
Думаю, нужно найти потерянного субъекта. Нарисовать диаграмму прецедентов, состоящую из двух субъектов (ассоциацию с одним из них обозначить как первичную) и одного прецедента.
А потом "раскрыть" этот прецедент с помощью диаграммы деятельности. Эта диаграмма может иметь три партишена ("дорожки"), для двух субъектов и для вашей системы, которая, собственно, и обеспечивает выполнение цели первичного субъекта.
Пример диаграммы прецедентов (правда из области бизнес-моделирования, но "пельмени "Малышок" (UML) и в Африке "Малышок"") представлен ниже.
Диаграмма "живая", из текущего проекта.

Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru

Я Вашего инструмента не знаю. Сам использую IBM Rational Software Architect. Он дорогой, но это не инструмент для рисования, а интегрированная среда разработки, от моделирования архитектуры предприятия до ... (ну, например, разработки преобразований из модели в код на экзотическом языке).

Простите, картинку вставить не научился.
Никак не получается.
Если хотите посмотреть, пожалуйста, расскажите, как Вы свою вставляли.
Или могу выслать по почте.

Простите, картинку вставить не научился.
Никак не получается.
Если хотите посмотреть, пожалуйста, расскажите, как Вы свою вставляли.
Или могу выслать по почте.

Леонид, можно обойтись без дорогих инструментов round-trip engineering, копирования диаграммы как картинки, заливки её на хостинг и вставки в пост.

Сервисы типа yuml.me позволяют генерировать диаграммы способов применения на лету, просто указываю нужные атрибуты в URL.

Прошу побольше критики и советов! Очень помогут. Системка маленькая, но думаю для начального этапа достаточно.

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

Леонид, можно обойтись без дорогих инструментов round-trip engineering, копирования диаграммы как картинки, заливки её на хостинг и вставки в пост.

Сервисы типа yuml.me позволяют генерировать диаграммы способов применения на лету, просто указываю нужные атрибуты в URL.

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

Рисовать в инструментах (дорогих) имеет смысл, если собираешься использовать информацию. Например, для генерации документов или выполнения преобразований моделей, например, из модели use cases в проектную модель, и т.д., как описано в MDA.

Относительно анализа требований. Помните про Золотую рыбку? Она буквально выполняла высказанные желания.
Alexeyzf ничего не спрашивал про анализ требований. Он хочеn писать код и учит UML.
Так давайте следовать опыту Золотой рыбки!

Alexeyzf ничего не спрашивал про анализ требований. Он хочеn писать код и учит UML.
Так давайте следовать опыту Золотой рыбки!

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

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

Бедный Alexeyzf!
Но откуда мы знаем, что он аналитик или собирается им стать?
И кто сказал, что он не выполнил анализ требований (в своей голове)?
Мало того! Откуда такая уверенность, что рисовать диаграммы нужно после анализа?

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

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

Бедный Alexeyzf!
Но откуда мы знаем, что он аналитик или собирается им стать?

Действительно! Откуда?!

И кто сказал, что он не выполнил анализ требований (в своей голове)?

И кто же этот малый?

Мало того! Откуда такая уверенность, что рисовать диаграммы нужно после анализа?

Действительно, откуда?

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

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

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

Не понял тезиса. Вы против того, что потребности и ожидания ЗЛ первичны, а модели внешних продуктов системы — вторичны?

А если Вы посмотрите мои спецификации, они очень похожи на "эффективные юзкейсы", хотя получены генерацией из модели.

Мастер может начать строить ракету хоть с туалета.

Еще раз спасибо за детальный разбор.

Я считаю интересы ЗЛ первичными, а модели - это отображение этих интересов, как их  понимает аналитик. Я уже писал выше, что моделировать не обязательно, но теперь многие это делают. И кто-то использует UML.

Если Вы хотите удостовериться, что я думаю именно так, посмотрите http://lnew.ucoz.ru, Моделирование заинтересованных лиц в TOGAF.

А вот, как вставить файл картинки в сообщение, я так и не узнал. Может, этого вообще нельзя сделать?

А вот, как вставить файл картинки в сообщение, я так и не узнал. Может, этого вообще нельзя сделать?

Под формой комментария:

• Дополнительные опции…

Вложение: [Выберите файл] Файл не выбран (Вложения)

Если Вы хотите удостовериться, что я думаю именно так, посмотрите http://lnew.ucoz.ru, Моделирование заинтересованных лиц в TOGAF.

Я тоже похвастаюсь непониманием, как работает конкретный движок сайта.
Я зашёл на страницу: http://lnew.ucoz.ru/news/modelirovanie_zainteresovannykh_lic_v_togaf/2010-12-18-7 и не обнаружил там статьи. Как до неё добраться?

Большое спасибо!

А зайдите на корень, http://lnew.ucoz.ru, Каталог статей.
Видимо, что-то со ссылкой. Я проверю, исправлю.

Ваше мнение для меня важно.