Форум Сообщества Аналитиков

×


Не хочу больше делать ошибки с проектированием(Прочитано 9925 раз)
Ввиду того что появилось желание узнать что такое на самом деле успешное проектирование  и грамотный программный код решил изучить 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
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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



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

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

Я Вашего инструмента не знаю. Сам использую IBM Rational Software Architect. Он дорогой, но это не инструмент для рисования, а интегрированная среда разработки, от моделирования архитектуры предприятия до ... (ну, например, разработки преобразований из модели в код на экзотическом языке).
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Простите, картинку вставить не научился.
Никак не получается.
Если хотите посмотреть, пожалуйста, расскажите, как Вы свою вставляли.
Или могу выслать по почте.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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

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



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



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

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

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

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

Относительно анализа требований. Помните про Золотую рыбку? Она буквально выполняла высказанные желания.
Alexeyzf ничего не спрашивал про анализ требований. Он хочеn писать код и учит UML.
Так давайте следовать опыту Золотой рыбки!
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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



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

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

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



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

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

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

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

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

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



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

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

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

А вот, как вставить файл картинки в сообщение, я так и не узнал. Может, этого вообще нельзя сделать?
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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

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


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



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



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

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

Ваше мнение для меня важно.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19