256

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 06 Января 2011, 13:46:55 »

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

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

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

257

Примеры / Re: Не хочу больше делать ошибки с проектированием

« : 05 Января 2011, 19:39:45 »

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

Думаю, с помощью 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

258

Sparx / Re: EA 8.0 - возможность создания структурированных UseCases

« : 28 Декабря 2010, 11:50:05 »

Все это очень интересно. И полезно. Только не нужно искать очередную "серебряную пулю". И, к сожалению, это не UML.

У Коберна очень хорошие и полезные описания последовательностей взаимодействий (выполнения use case, варианта использования, я использую термин "прецедент" уже много лет, еще с UML версии 0.9). Но Коберн принципиально не использует UML. Он ему для его профессиональной деятельности не нужен.

А что такое "поток вариантов использования"? Для поклонников Коберна такое понятие вообще недопустимо (как и для поклонников UML). Это что, детерминированная последовательность выполнения прецедентов?

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

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

Технология простая, отработана давно. Я ее распространяю, когда меня приглашают внедрять IBM Rational или на курсах в моковском Интерфейсе.

259

ПО Аналитика / Re: Как отобразить в Rational Software Modeler ....

« : 20 Декабря 2010, 22:04:26 »

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

Узлы объектов на диаграмме деятельности - это экземпляры класса, и когда Вы их создаете, Вы указываете тип как ссылку на соответствующий класс ("Входящий документ"). Какой объектный узел Вы нарисуете - почти безразлично: они четырехугольничком ресуются одинаково, а их суть - это выбранный тип (класс).

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

Иногда на диаграмме деятельности показывают объектные узлы при создании объектов, или даже несколько раз один и тот же узел, чтобы продемонстрировать изменения состояния (описанное в прикрепленной Note). Если это очень нужно.

Чтобы "проваливаться" в поддиаграммы или даже использовать "поведение, предназначенное для многократного использования", т.е то, которое можно использовать в разных контекстах, нужно на диаграмме создавать не Action, а Call Bechavior. При создании элемента Вам будет предложено выбрать существующее поведение или создать новое.

Такое вызываемое поведение м.б. деятельность или взаимодействие.

Если есть вопросы, пишите, присылайте картинки. Постараюсь помочь (если это не огромный проект). Или пришлите модельный файл.

260

Обсуждение статей / Re: Предисловие к интегрированной архитектуре

« : 19 Декабря 2010, 16:48:06 »

Нет, Юра!
RUP EA не помеха.
Если внимательно посмотреть RUP, EA там присутствует.
Я так понимаю, что RUP - это не технология, а энциклопедия, обобщающая опыт разработки. А по мере расширения интересов разработки, включающая все новые концепции.

261

UML SysML и пр. / Re: Diagram: Activity vs Sequence

« : 19 Декабря 2010, 14:38:31 »

Давно дело было. Может быть это уже не интересно. Но я хотел бы добавить к выступлениям предыдущих ораторов еще один аспект.
Можно вполне выкинуть из названия темы "vs":

Хотя в UML2 диаграмма последовательности существенно расширена и ее уже никак нельзя назвать диаграммой сценариев (сценарий ифов иметь не может, это детерминированная последовательность), но все же описание логики процесса очень перегружает. Для машины - это не препятствие (различного рода преобразования MDA, в том числе кодогенерация). Но для человека - это кошмар!

В UML2 есть новая диаграмма. Я перевел ее название как "диаграмма обзора взаимодействий". Как на английском - не помню. Может быть я ошибаюсь, мне кажется, что ни в одном из инструментов моделирования она "впрямую" не реализована. Я упоминаний не встречал.

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

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

http://lnew.ucoz.ru

262

Для всех / Re: Поиск решения задачи бизнес моделирования

« : 18 Декабря 2010, 21:02:30 »

Обращайтесь. Поговорим.
http://lnew.ucoz.ru

263

Для всех / Re: Классы Qt и UML

« : 18 Декабря 2010, 20:59:12 »

1. Чтобы сказать, что не так, нужно, как отметил предыдущий оратор (я имею ввиду не слова, а дух) представлять, что сделано.
2. Судя по тому, что сначала был написан код, а потом рисуются диаграммы, они просто не нужны. Но могут поставить двойку! Придется рисовать!

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

С диаграммой классов, видимо, понятно, раз классы реализованы.

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

Желаю успеха!
http://lnew.ucoz.ru

264

Для всех / Re: Программное обеспечение системного аналитика

« : 18 Декабря 2010, 20:31:12 »

Системный аналитик (по RUP) формулирует требования к будущей системе для поддержки бизнеса заказчика. Функциональные требования к системе сегодня моделируют на UML (прецеденты (Use Cases)). Не функциональные, в основном, описывают в текстовом виде.
Вот уже два инструмента: Текстовый редактор и инструмент моделирования.
Про текстовый редактор говорили.
Инструментов моделирования масса. Я использую инструменты IBM Rational. Их тоже стало огромное количество. Есть классные, а есть - не очень.
Я использую Rational Software Architect. У него масса возможностей, которых нет у других, если нужно не только моделировать. Но это предмет отдельного спора. Кроме того, у него есть недостаток - большая цена.
По мере накопления требований, когда их становится много, ими нужно управлять, отслеживать связи между отдельными требованиями (они часто друг от друга зависят. Нужен инструмент для управления требованиями. Их тоже много, в том числе и в Rational уже целых три. Я иcпользую Rational RequisitePro.
И, конечно, требования нужно документировать. Хорошо бы сделать это вовремя, хотя бы частично, чтобы разработчики смогли использовать в процессе разработки. Требования ведь будут меняться! Придется изменять модель, требования в RequizitePro и документы. Значит, документы лучше не ручками писать, а генерить из модели. Я использую Rational SoDA (классный инструмент, незаслуженно почти забытый). Я вручную документов не пишу.
Вот так!
http://lnew.ucoz.ru