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

Общий раздел => Теория моделирования и нотации => Тема начата: Michaj от 05 Ноября 2009, 13:33:29

Название: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 05 Ноября 2009, 13:33:29
Простите чайника. Не могу понять принципы связи между элементами различных видов диаграмм (между диграммами различных видов) одной модели. Предусмотрена ли в UML вообще, в CASE-системах в частности, и в EA в частности частности, нотация для явного отображения таких связей? Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)? Мне все время этого хочется, допускаю, что это заблуждение, но не понимаю в чем оно. Разве не естественно, если необходимость конкретного класса вытекает из существования конкретного прецедента? Разве не полезно документировать такую связь? Но я не обнаруживаю для этого методов/способов ни в UML, ни в ЕА ... Помогите разобраться, что я изначально не так понимаю?
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: bas от 05 Ноября 2009, 14:03:37
Если этот Класс (или другой элемент) - реализация ВИ, то эта связь называется трассировка (зависимость со стереотипом trace).
Эта связь полезна, ее можно указывать явно (на Д, но на другой чем ДК или ДВИ, например, на Д трассировки) или неявно (просто как связь в проекте).
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 05 Ноября 2009, 14:18:10
Организация связи между диаграммами вполне возможна: к каждому элементу практически можно прикрепить другую диаграмму + использовать разные обзорные фреймы, на которых вытаскивать соответствующие элементы разных диаграмм и связывать из зависимостями.Нотация это разрешает, инструменты реализуют это по-разному
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Виталий Григораш от 05 Ноября 2009, 14:23:50
Можно еще связь реализации сделать в EA. По сути тоже подходит. Вариант использования реализуется набором классов
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: div от 05 Ноября 2009, 14:44:10
Разве не естественно, если необходимость конкретного класса вытекает из существования конкретного прецедента?
Нет, из существования прецедента не вытекает необходимость создания конкретного класса. Любой прецедент можно реализовать многими разными наборами классов, их придумывание как раз и составляет процесс разработки архитектуры системы. Грубо говоря, реализации прецедента "пользователь садится в безлошадную повозку и едет в пункт назначения" не требует использования класса "Двигатель внутреннего сгорания". Это может быть и класс "электрический двигатель". Но когда вы выбрали класс ДВС для работы в составе системы, имеет смысл поставить трассировку от него на прецедент, чтобы потом, когда очередной разработчик предложит вместо ДВС использовать лошадь, можно было по трассировке быстро найти причину, почему лошадь нельзя.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 05 Ноября 2009, 14:56:20
Если этот Класс (или другой элемент) - реализация ВИ, то эта связь называется трассировка (зависимость со стереотипом trace).
Эта связь полезна, ее можно указывать явно (на Д, но на другой чем ДК или ДВИ, например, на Д трассировки) или неявно (просто как связь в проекте).
Спасибо, это похоже на то, что я искал :)

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

(to div) нет, я не заблуждаюсь в том, что каждому прецеденту обязательно должен соответствовать класс (не настолько):), но желание самой возможности указания подобной связи во многих случаях, казалось мне вполне оправданным. Именно для той цели, которую вы очень похоже описали ...

Спаисбо всем, уже есть пища, надо попереваривать ...
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 05 Ноября 2009, 19:56:55
не очень понимаю что вам конкретно нужно. может вы изобразите нам идею того, что вы хотите?
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Денис Иванов от 05 Ноября 2009, 23:55:30
Варианты использования суть наборы сценариев. Сценарии реализуются (в ОО системах) взаимодействием некоторого количества классов. Это "некоторое количество классов" называется кооперация. Можно провести зависимость от кооперации к варианту использования.
Ну а классы играют определенные роли в кооперации, что также можно показать стандартной нотацией UML.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 06 Ноября 2009, 16:06:25
to  Galogen, №6)
не очень понимаю что вам конкретно нужно. может вы изобразите нам идею того, что вы хотите?
– Имеется задача, которая сводится к необходимости  разработки и внедрения в существующую систему новой функциональности. Суть ее состоит в появлении нового, глобального для задачи,  сквозного опорного аттрибута, что связано с запуском производства вида продукции, значительно отличающегося от прежнего. Проблема в данном случае лежит именно в структуре, свойствах и методах классов, где сейчас ни такого аттрибута, ни методов для работы с ним, естественно нет. Алгоритмические вопросы здесь и пока для меня второстепенны. Сейчас объектная модель системы практически точно воспроизводит объектную модель бизнеса в жизни (вернее, они реально "кратны" друг-другу), что я считаю важным, и о чем я всегда специально забочусь. Поэтому UseCase-диаграмма и Class-диаграмма практически "параллельны" друг-другу. Рисунок во вложении. Но на данный момент в модели никак не отображен этот факт – что, например, класс "док.Путевка" в системе является конкретной реализацией прецедента  "Создание партии продукции". Но разве это не так, буквально? Разве это не важно для модели? Предполагая, что это "так", но не найдя самостоятельно способа задания данной связи в программе (Sparx), как ни искал, я и обратился за помощью к мэтрам... Однако, по большому счету, вопрос в том, что я пытаюсь освоить новый метод работы и пытаюсь как можно раньше сформировать у себя единый  образ дисциплины (UML), пусть даже сначала и без всех деталей. Но существуют ключевые вопросы, без которых никакой цельный образ невозможен. Одним из таких вопросов в данном случае, для меня является вопрос о взаимодействии видов диаграмм, частным случаем которого является исходный вопрос.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 07 Ноября 2009, 00:25:55
Если честно, все равно не могу просечь в чем проблема?

Что же вы все-таки хотите? Показать некую связь некоего ВИ с неким классом? Так Вам уже много способов дали. Причем denis-itk дал Вам  чисто классический способ через кооперации (во многих местах можно почитать). Не нравятся кооперации, используйте трассировки, не нравятся трассировки, изобразите реализации. Не нравятся реализации - сделайте просто гиперссылку одного объекта на другой. Ну что еще посоветовать, можно добавить теги, связать эти теги и как-то прослеживать связность...

Теперь от диаграммах - это вообще что? Что это за ВИ "Свободные остатки"? Что это за зависимости "создание"? И что это за компот из "создания", "include" и "invokes". Кстати а почему include в императиве, а invokes в 3 лице?

Создание ТТН непременно включает Отгрузку со склада ГП?

А что такое за атрибут Размер(Заказ)? Отличается Размер как атрибут от Размера как класс?
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: div от 07 Ноября 2009, 15:07:54
Поэтому UseCase-диаграмма и Class-диаграмма практически "параллельны" друг-другу. Рисунок во вложении.
К меня создалось впечатление, что Вы неправильно используете Use Case'ы.
Вы по каким источникам изучали UML?
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 07 Ноября 2009, 15:28:40
Но на данный момент в модели никак не отображен этот факт – что, например, класс "док.Путевка" в системе является конкретной реализацией прецедента  "Создание партии продукции". Но разве это не так, буквально?
Вариант использования - это набор сценариев, которые описывают типичные потоки событий при взаимодействии внешних систем с системой проектируемой. Взаимодействие происходит через интерфейсы: консольные, GUI, протокольные, физические и т.п. В ходе взаимодействия происходит много разных событий, которые вызывают много разных системных операций=действий. Этими действиями нужно управлять, кто будет управлять этими действиями решать Вам, но GRASP рекомендует искать для этого класс, обладающий соответствующей ответственностью. В ходе исполнения ВИ типично, что что-то нужно взять из некоего хранилища и что-то туда положить обратно. Следовательно нужна некая структура такого хранилища. Очень часто такая структура определяется моделью предметной области и включает класс предметной области.

Поэтом на ваш вопрос: Но разве это не так, буквально? - можно ответить. Это совершенно не так!!!!

Цитировать
Разве это не важно для модели?
Что не важно для модели? Связь некоего ВИ с неким классом? Конечно, важно, это и происходит почти автоматически, если правильно использовать методологию. UML лишь язык, к нему нужно применить методологию, правила.

Цитировать
Предполагая, что это "так", но не найдя самостоятельно способа задания данной связи в программе (Sparx), как ни искал, я и обратился за помощью к мэтрам...

Нельзя найти черную кошку в темной комнате, если ее там нет (с)

Цитировать
Однако, по большому счету, вопрос в том, что я пытаюсь освоить новый метод работы и пытаюсь как можно раньше сформировать у себя единый  образ дисциплины (UML),

UML - это не дисциплина. Это язык. Не более и не менее.

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


В Вашем случае "класс "док.Путевка" в системе является конкретной реализацией прецедента  "Создание партии продукции""
- совершенно не правильный вывод.
Спросите себя что делает класс док.Путевка, для чего он предназначен, какова его ответственность?

Я думаю тут вам еще мешает что вы мыслите категориями 1С, правильно ли я понимаю?
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 17:08:40
Это сообщение я написал до того, как получил два последних ответа в топике, которые практически уже содержат ответы по некоторым моментам данного. Что-то теперь следовало бы в нем изменить, но опасаюсь, что пока буду исправлять, это тоже успеет устареть. Очень боюсь истощить Ваше терпение, но один этот разговор думаю стоит недель, если не месяцев самоварения. Мне кажется, он может помочь и другим новичкам, так как вряд-ли мои вопросы и сомнения уникальны. А на теперь уже предыдущие два ответа, я напишу отдельно.
Если честно, все равно не могу просечь в чем проблема?
Проблема в том, что проковырявшись уже достаточно долго в книгах, факах и хелпах, познакомившись с большим количеством сущностей UML и вооружившись Sparx, я так и не сумел составить какой-либо вразумительный общий образ использования дисциплины (не теории, а практики). Я опасаюсь, что разговор переходит в оффтопик, но ответ на ваш настойчивый вопрос лежит именнно в этом. Одновременно, большое спасибо за Ваши следующие вопросы, надеюсь они помогут мне задавать свои более вразумительно.
Цитировать
Что же вы все-таки хотите? Показать некую связь некоего ВИ с неким классом? Так Вам уже много способов дали. Причем denis-itk дал Вам  чисто классический способ через кооперации (во многих местах можно почитать).
Можете не верить, но видимо я в эти места не попадал… Однако прочтя советы denis-itk, я тут же отправился в Sparx с намерением ими воспользоваться. На данном, очень низком этапе своего развития, слова о кооперации классов в контексте какого либо ВИ в моем представлении приобрели образ некоего объекта Collaboration в качестве контейнера в виде рамки на диаграмме, в который следует поместить некие классы, и связать уже эту рамку с ВИ. Но, как оказалось, в диаграмме классов, в ее наборе, нет элемента типа Collaboration … Ладно, зато такой элемент есть в диаграмме ВИ. Попробовал здесь создать Collaboration, и в него из дерева модели перетащить … что? Речь ведь идет об объединении классов … Ну, перетащил в него класс. – На Collaboration возникла пупырышка с название Port (…?). Я понял, что опять делаю что-то не то …
Цитировать
Не нравятся кооперации, используйте трассировки, не нравятся трассировки, изобразите реализации. Не нравятся реализации - сделайте просто гиперссылку одного объекта на другой. Ну что еще посоветовать, можно добавить теги, связать эти теги и как-то прослеживать связность...
Я думаю, что первая проблема новичка не в том, что он не знает всех кнопок (меня уже очень давно не волнуют подобные проблемы), а в том, что иногда долго не удается уловить самой базовой логики данной области знаний (при том, что уже начитался и о достаточно специальных ее деталях). Я думаю дело в том, что авторы-источники знаний, просто упускают излагать информацию, представляющуюся им тривиальной, но которая на самом деле и составляет базовый контекст, в котором только и становится понятно то, что они излагать находят нужным и интересным… Это явление повсеместно. Каждый знает это по себе: берешь книгу в руки в первый раз – все совершенно непонятно, как на китайском языке. Открываешь ту же книгу через пару лет – и диву даешься, что там могло быть непонятным с самого начала … А все дело именно в знании контекста, – объективно – это самое элементарное, а дается - с наибольшей кровью, потому что доступные источники, как правило, это опускают. Вот что мне надо (по очень большому секрету). Извините, что получается так длинно, но это мой первый топик здесь и я (опять же!) еще не знаком с контекстом данного форума (как форума, а не UML), и лишь честно пытаюсь исчерпывающе отвечать на вопросы.
Цитировать
Теперь о диаграммах - это вообще что? Что это за ВИ "Свободные остатки"?
Я хотел отобразить ключевой объект, который автоматически формируется в процессе выполнения функций одними пользователями, и от которого зависят возможности других пользователей при исполнении ими их функций.
Цитировать
Что это за зависимости "создание"?
Прецедент, который "создается", автоматически инициируется в транзакции выполнения родительского прецедента. Но затем с ним работает (редактирует) другой пользователь.
Цитировать
И что это за компот из "создания", "include" и "invokes".
Думаю что "компот" – это следствие незнания того самого базового контекста, о котором и пытаюсь получить, прямо или косвенно, любые сведения. Например, я четко знаю что такое "эклектика", но только благодаря тому, что я знаю соответствующий контекст эстетики. А вот что такое "компот" приминительно к UML – очень хотел бы узнать.
 
Цитировать
Кстати а почему include в императиве, а invokes в 3 лице?
Потому что Вы первый, кто сказал мне, что это плохо  :(
Цитировать
Создание ТТН непременно включает Отгрузку со склада ГП?
Да. ТТН это только контейнер с собственными товарно-транспортными реквизитами. Пользователь вручную, из списка допустимых Отгрузок, выполненных ранее кладовщиками на разных складах ГП, включает некоторые из них в данную ТТН в качестве оснований для Приложений к этой ТТН (собственно детальных списков продукции)
Цитировать
А что такое за атрибут Размер(Заказ)? Отличается Размер как атрибут от Размера как класс?
Из-за этого Размера весь сыр-бор. Не очень понимаю вопрос. Предполагаю (но это еще не точно), что должен быть создан класс "Размер_Заказ", который позволит где необходимо в прочих классах, создавать ссылочные аттрибуты на него, дающие доступ к значениям аттрибутов Заказчик, Длина, Ширина и пр. класса "Размер_Заказ". (дело в том, что существавшее до сих пор производство – чисто конвеерное многосерийное производство (стеклопосуда и хрусталь), не предполагавшее на этапе производства (более 100 лет существования) никакого специфицирования по потребителям, а здесь вдруг возникло производство картона (и упаковок из него, но это отдельная песня), включающее еще и его нарезку в любом формате в качестве дополнительного потребительского сервиса…).
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 17:35:21
К меня создалось впечатление, что Вы неправильно используете Use Case'ы.
У меня тоже :( Как раз пытаюсь это скорректировать
Цитировать
Вы по каким источникам изучали UML?
Кроме данного сайта, книгой Буча, точного названия нет в голове, она на работе, Уэнди Боггс, Майкл Боггс "UML и Rational Rose", Help в Sparx (но, увы, не очень силен в англ-м :( ) и прочим, что попадется ... Я не программист, но программеры на работе, которые это, казалось бы, недавно изучали в универе, разбираются в сем, оказывается, еще меньше меня...
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: AlexTheRaven от 07 Ноября 2009, 18:00:36
Связь класса с UC - вполне нормальная вещь, если понятно, для чего она нужна. Что делает ваш класс для UC? Он "аналитический" или относится к тому, что реально есть в коде? Он entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC? Что и до кого вы хотите донести этой связью, поймут ли вас?

Опять же, для чего вы используете UC? Они у вас "бизнес", "системные про взаимодействие с actor'ами" или "технические про алгоритмы системы"?

IMHO (но только IMHO)
- связь UC с аналитическими классами - это правильно, и её выстраивание - работа системного аналитика
- связь UC с отдельным классом реализации - это "мелковато", трудно поддерживать; для того, чтобы показать связь UC с кодом, лучше связывать UC с компонентами, и выстраивание такой связи - работа системного архитектора.

Про средства отображения такой связи - в Rational Rose, насколько я помню, была связь через UC Realization, в EA можно рисовать напрямую, но IMHO лучше стереотипировать и комментировать.

Чтобы отобразить в EA связь между UC и классом, UC и компонентом - достаточно
- перетащить оба элемента на одну диаграмму из дерева проекта; насколько я помню, между ними будут доступны связи dependency и trace, но их можно стереотипировать
- просто создать два элемента разных типов на одной диаграмме, переключая панели инструментов.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 18:59:16
Цитировать
Вариант использования - это набор сценариев, которые описывают типичные потоки событий при взаимодействии внешних систем с системой проектируемой.
Вот это попрошу пояснить. Почему ВИ - это "набор сценариев"? (я не спорю, я хочу понять) Во-первых, если брать диаграмму ВИ в целом, то это скорее перечисление функций (именованных), их обзор так сказать, которые требуются пользователям. Отображение их последовательностей не является назначением данного представления. Да, к нему предусмотрен сопровождающий документ "Сценарий", но это ведь все же только опция, а не одно и тоже. Но о каких "сценариях" тогда идет речь? Ведь сценарии это, суть, последовательности ... Сами элементы диаграммы, эти именованные функции, тоже называются ВИ, только в единственном числе (на данном уровне деталировки). Я знаю, что систему в целом можно представить в виде сценария, например(!), с помощью диаграммы Activity (такие у меня пока примитивные представления сложились). А кроме того, в свойствах каждого из единичных ВИ, присутствует возможность описать его внутренний сценарий. Если вы имеете ввиду, что каждый из прецедентов в диаграмме ВИ таким образом представляет некий сценарий, тогда я вашу фразу понимаю, а если нет - ну тогда значит не понимаю о чем идет речь. Собственно, вот и вопрос для начала: так правильно я понимаю ВИ или нет, и если нет, то в чем ошибка? А еще лучше, если вы не станете отвечать на мои вопросы, которые заведомо содержат новые изъяны, а попробуете просто перефразировать ваше выражение так, чтобы эти вопросы не могли возникнуть.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Григорий Печенкин от 07 Ноября 2009, 20:16:36
Вот это попрошу пояснить. Почему ВИ - это "набор сценариев"? (я не спорю, я хочу понять) Во-первых, если брать диаграмму ВИ в целом, то это скорее перечисление функций (именованных), их обзор так сказать, которые требуются пользователям. Отображение их последовательностей не является назначением данного представления. Да, к нему предусмотрен сопровождающий документ "Сценарий", но это ведь все же только опция, а не одно и тоже. Но о каких "сценариях" тогда идет речь? Ведь сценарии это, суть, последовательности ... Сами элементы диаграммы, эти именованные функции, тоже называются ВИ, только в единственном числе (на данном уровне деталировки). Я знаю, что систему в целом можно представить в виде сценария, например(!), с помощью диаграммы Activity (такие у меня пока примитивные представления сложились). А кроме того, в свойствах каждого из единичных ВИ, присутствует возможность описать его внутренний сценарий. Если вы имеете ввиду, что каждый из прецедентов в диаграмме ВИ таким образом представляет некий сценарий, тогда я вашу фразу понимаю, а если нет - ну тогда значит не понимаю о чем идет речь. Собственно, вот и вопрос для начала: так правильно я понимаю ВИ или нет, и если нет, то в чем ошибка? А еще лучше, если вы не станете отвечать на мои вопросы, которые заведомо содержат новые изъяны, а попробуете просто перефразировать ваше выражение так, чтобы эти вопросы не могли возникнуть.

Диаграмма вариантов использования - это что-то вроде оглавления, план будущей книги. А сами варианты использования - текстовое наполнение, главы этой книги.

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

Однозначного соответствия между вариантами использования и классами в большинстве систем, скорее всего, нет. Это разные сущности, Хотя это зависит от выбранной архитектуры, конечно, но мне сейчас как-то трудно представить пример такого соответствия. Скорее, каждый сценарий реализуется взаимодействием множества экземпляров разных классов.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 20:41:03
Вопрос взаимодействия диаграмм - вопрос методологии, вопрос технологии использования. Потому Вам следует изучить вопросы методологии разработки в стиле ООП. Без этого знания и понимания основ, у вас не будет движения.
Где-то в какой-то статье о UML был использован в общем-то штамп о том, что типа "не так страшен волк, как его малюют", - возьмите и попробуйте". Я в принципе из этого и исхожу. Мне UML нужен в той мере, в какой он мне нужен, а не я ему (в конечном счете). Я знаю основы ООП, со мной смело можно гаварить о "наследовании, инкапсуляции и полиморфизме ..." (господи, до чего ж длинные слова). Я не знаю ООП так, как его знают программисты, но и они не знают ООП так, как его знаю я, и стоит оставить их без присмотра, как это на каждом шагу вылазит боком. Я не знаю множества деталей использования ООП в коде, но зато я знаю что такое идея и композиция, гармония (баланс) и стиль применительно к структуре объектной модели приложения и/или его компонентов, и к бизнес-архитектуре в целом, что для программистов как правило пустые звуки, потому что этому их не учат, потому что программистская школа слишком молода и у нее еще не успела сложится своя эстетика. Понесло ... Стоп!

Цитировать
В Вашем случае "класс "док.Путевка" в системе является конкретной реализацией прецедента  "Создание партии продукции""
- совершенно не правильный вывод. Спросите себя что делает класс док.Путевка, для чего он предназначен, какова его ответственность?
Спрашиваю.-Отвечаю: документ путевка есть прогр.компонент, пользовательский интерфейс, в который пользователь вносит перечень очередной порции произведенных изделий.- Это точка, в которой эти изделия вообще впервые возникают в Системе как объекты учета (не путать с элементами справочника, - тут они заведомо присутствуют, но не являются объектами учета, пока не существует связанных с ними остатков). Это, честно, все, что пришло мне в голову :( Но я все равно не врубился, почему класс не является здесь реализацией прецедента ...

Цитировать
Я думаю тут вам еще мешает что вы мыслите категориями 1С, правильно ли я понимаю?
Относительно 1С совершенно правильно! :) А вот по поводу "мешает" мог бы поспорить, но лучше не надо... Я действительно являюсь убежденным сторонником той же концепции бухучета и ее воплощения в IT,  которой придерживалась 1С в своих старых бухгалтерских системах. Собственно, первая моя работа в сфере производства ПО, куда меня пригласили в качестве бизнес-аналитика (повезло), подспудно сопровождалась мыслью создать продукт такой же классный, как 1С, но лишенный его недостатков ;). Тогда еще не существовало 7-ки. Через несколько лет работы (1С7.5 я прозевал) случилось мое знакомство с 1С7.7, и я с изумлением узнал там множество "своих собственных" решений (конвергенция, однако!). Однако к этому времени уже пару лет моя система (ERP) работала на довольно большом предприятии (около 6000 работников, тысячи единиц номенклатуры, несколько десятков одновременно работающих пользователей), где и сейчас работает, где и возник собственно обсуждаемый вопрос. 1С в то время и близко не подходила к подобным масштабам предприятий, да и сейчас только-только подбирается, и никак не подберется ... Но, я думаю, за ней будущее, хотя и не одобряю нового ее, именно концептуально, направления. Вообще, нахожу что в России, в сфере учета, побеждает откровенное невежество, а 1С просто сдалась с этим бороться ...
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 07 Ноября 2009, 20:45:37
Michaj, Вы не прочитали сообщение №11?

Но судя по Вашим вопросам, следует еще раз перечитать книги. Причем лучше не книги по UML, а книги по использованию UML. Подойдут книги перечисленные в FAQ сайта. Крэг Ларман в этом случае отлично торкает :)
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 20:55:36
<to greesha> но я ведь практически в точности так и трактую понятие "Варианты использования", как вы описали. В чем разница?
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Денис Иванов от 07 Ноября 2009, 20:59:54
Проблема в том, что проковырявшись уже достаточно долго в книгах, факах и хелпах, познакомившись с большим количеством сущностей UML и вооружившись Sparx, я так и не сумел составить какой-либо вразумительный общий образ использования дисциплины (не теории, а практики).
Именно по UML советую прослушать/просмотреть этот курс (http://uml3.ru/index.php?option=com_content&view=article&id=9&Itemid=10).
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 21:09:04
Michaj, Вы не прочитали сообщение №11?
Мой №15, на который я возлагал особые надежды, это именно на №11
Цитировать
... Крэг Ларман в этом случае отлично торкает :)
Большое спасибо, попробую
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 21:19:44
Именно по UML советую прослушать/просмотреть этот курс (http://uml3.ru/index.php?option=com_content&view=article&id=9&Itemid=10).
На первый взгляд, чрезвычайно интересно и именно то, что мне было надо :). Спасибо! Что-то похожее предлагается на Intuit, и я пытался, но то ли там какие-то непреодолимые глюки на очередной страничке, то ли просто мелкое мошенничество, но там затея не удалась ...
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: leinsoo от 07 Ноября 2009, 21:38:53
... Предусмотрена ли в UML вообще, в CASE-системах в частности, и в EA в частности частности, нотация для явного отображения таких связей? Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?
......

В PowerDesigner данное отношение поддерживается явно. Даже по умолчанию у прецедента есть вкладка, предназначенная для ведения связей с реализационными классами и интерфейсами (см. приложенный рисунок).

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

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

В дополнение к связи с классами, у нас используется и связи с объектами БД и некоторыми другими элементами (собственное расширение).
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 21:57:26
В PowerDesigner данное отношение поддерживается явно. Даже по умолчанию у прецедента есть вкладка, предназначенная для ведения связей с реализационными классами и интерфейсами (см. приложенный рисунок).

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

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

В дополнение к связи с классами, у нас используется и связи с объектами БД и некоторыми другими элементами (собственное расширение).

Спасибо, еще один мазок в создание образа :) Мотаю на ус ... :)
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Григорий Печенкин от 07 Ноября 2009, 22:20:10
<to greesha> но я ведь практически в точности так и трактую понятие "Варианты использования", как вы описали. В чем разница?

Разница, как мне кажется, в том, что use case на диаграмме вариантов использования и use case как способ описания требований к системе - это не совсем одно и то же. Или почти одно и то же, но с разных точек зрения.

Из-за этого и возникает путаница: для кого-то use case это, в первую очередь, сценарий взаимодействия с системой (для тех, кто начинал с Коберна), а для кого-то другого - функция, предоставляемая системой (для тех, кто начал с UML). Однозначного соответствия между ними может и не быть.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 07 Ноября 2009, 23:52:31
Разница, как мне кажется, в том, что use case на диаграмме вариантов использования и use case как способ описания требований к системе - это не совсем одно и то же. Или почти одно и то же, но с разных точек зрения.
Я еще раньше понял, что у ВИ есть оба эти предназначения, но пока плохо представляю, что из этого следует и из-за этого ли возникает путаница. Но, по крайней мере, что путаница имеет место,  значит мне не пригрезилось? В моей диаграмме это точно констатация "функции, предоставляемой системой".
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 08 Ноября 2009, 00:06:09
ВИ - это не функция. ВИ - это цель актера, которую система помогает достигнуть своими какими-то действиями. Именно исходя из этого и надо рассматривать ВИ. Никак иначе.

ВИ должен отражать цель. Цель имеют одушевленные предметы или предметы-аватры одушевленных :)
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 08 Ноября 2009, 00:29:08
Связь класса с UC - вполне нормальная вещь, если понятно, для чего она нужна. Что делает ваш класс для UC? Он "аналитический" или относится к тому, что реально есть в коде? Он entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC? Что и до кого вы хотите донести этой связью, поймут ли вас?
В данном случае (но только в данном), класс "док.Путевка" (наследник прототипа "Документ") действительно практически целиком и единолично реализует функционал "Создание партии ..." (т.е., я понимаю, что так бывает не везде и не всегда) и, более того, так "реально есть в коде". Насчет, "до кого хочу донести" и "поймут ли меня" ... видите ли, кроме этих, у меня существует еще один, первичный мотив - я полагаю, с помощью этих рисунков очень удобно думать (придумывать решения). Немаловажно и то, что выяснилось, что в результате, без дополнительных трудозатрат, возникает красивый материал, хорошо воспринимаемый программистами (UC+Activity). Зачем же заниматься почеркушками на бумаге, искать слова для длинных текстов и псевдокодов, если можно делать то же самое весело и сразу в "товарном виде"? Если рассматривать с этой т.з., то так ли уж важно квалифицировать "entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC?" Большая часть из перечисленного - епархия программистов, в этом я им доверяю - поэтому, честно говоря, в этом слабо или совсем не разбираюсь. Неужели мне в UML без этого не обойтись? Надеюсь, что нет.

Цитировать
Опять же, для чего вы используете UC? Они у вас "бизнес", "системные про взаимодействие с actor'ами" или "технические про алгоритмы системы"?
А так ли важно знать это (уметь различать) с самого начала освоения?[/quote]

Цитировать
IMHO (но только IMHO)
- связь UC с аналитическими классами - это правильно, и её выстраивание - работа системного аналитика
- связь UC с отдельным классом реализации - это "мелковато", трудно поддерживать; для того, чтобы показать связь UC с кодом, лучше связывать UC с компонентами, и выстраивание такой связи - работа системного архитектора.
А я не знаю, кто я - системный аналитик, архитектор, или бизнес-аналитик (еще есть "постановщик задач" и "инженер по АСУП":)), - я единственный аналитик и мне нужно прежде всего решить очередную головоломку. Будущая поддержка  - это еще одна головная боль... но, не все сразу...

Цитировать
Про средства отображения такой связи - в Rational Rose, насколько я помню, была связь через UC Realization, в EA можно рисовать напрямую,
Вот черт! Это же и есть буквальный ответ на исходный вопрос! Действительно, так я еще не пробовал... Попробовал, действительно можно. Единственно, - UC-диаграмма вроде как "засоряется". Поэтому попытаюсь еще разобраться с "но IMHO лучше стереотипировать и комментировать.", но это уже следующий вопрос ...

Цитировать
Чтобы отобразить в EA связь между UC и классом, UC и компонентом - достаточно
- перетащить оба элемента на одну диаграмму из дерева проекта; насколько я пиню, между ними будут доступны связи dependency и trace, но их можно стереотипировать
Действительно, можно это сделать на отдельной диаграмме, чтоб не засорять ни UC, ни Class-диаграм. А может для подобной цели еще и какой-н специальный тип(подтип?) диаграммы предусмотрен, или просто оптимален?
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 08 Ноября 2009, 00:35:30
ВИ - это не функция. ВИ - это цель актера, которую система помогает достигнуть своими какими-то действиями. Именно исходя из этого и надо рассматривать ВИ. Никак иначе.
Ну это уже максимализм. Разумеется ВИ это цель. Потому что любой функционал Системы, который предусмотрен для взаимодействия с актором, по определению преследует достижение какой-нить нужной актору цели. Но почему нельзя назвать это "функцией"? Мне кажется, это уже дело вкуса или нюанс конкретного разговора.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 08 Ноября 2009, 12:25:22
Вот черт! Это же и есть буквальный ответ на исходный вопрос! Действительно, так я еще не пробовал... Попробовал, действительно можно. Единственно, - UC-диаграмма вроде как "засоряется". Поэтому попытаюсь еще разобраться с "но IMHO лучше стереотипировать и комментировать.", но это уже следующий вопрос ...
Действительно, можно это сделать на отдельной диаграмме, чтоб не засорять ни UC, ни Class-диаграм. А может для подобной цели еще и какой-н специальный тип(подтип?) диаграммы предусмотрен, или просто оптимален?
Я так полагаю, что ответ автором найден? Если да, предлагаю дискуссию прекратить в данной теме. А если нужно обсудить тонкие моменты UML то, либо ищите имеющуюся тему (их предостаточно), либо создавайте новую коли лень искать или таковой темы на ваш взгляд нет.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Michaj от 08 Ноября 2009, 14:40:34
Я получил исчерпывающий ответ на свой исходный вопрос (в №14 от AlexTheRaven), и еще много больше, за что всем огромное спасибо. Однако, если говорить только о части ответа, буквально относящейся к исходному вопросу, то ответ оказался обескураживающим и, мне кажется, весьма показательным. Я предполагал что-то подобное (в моем сообщении №12, абзац 4), но реальность превзошла мои ожидания. То, о чем я спрашивал, уже сейчас (прошло всего часов 10, не то что 2 года), представляется мне настолько очевидным, что я просто не представляю, сам себе не верю, что искал и не мог найти этот ответ … наверное много дольше месяца… Я знаю, если не изложу это сейчас, по самой свежей памяти, то уже через пару дней, при обращении ко мне с подобным вопросом, очень вероятно, буду недоумевать точно так же, как Gologen и другие, чего же хочет спрашивающий (даже говорить стыдно). Как мог бы выглядеть ответ на мой исходный вопрос, если бы не существовал эффект вытеснения самых элементарных фактов из сознательной памяти в почти бессознательную: "1. Язык UML не регламентирует отображение семантических (понятийных) связей между сущностями (элементами) диаграмм различных типов, оставляя способ их констатации в документации, при необходимости, в произвольной, на усмотрение автора, форме; 2. В Sparx возможность документирования подобных связей поддерживается очень просто: на любую диаграмму можно физически перетащить любые объекты из дерева модели, и связать их явно одним из доступных в данной диаграмме видом связи (линии и стрелочки в тулзе диаграмм). Данная возможность является чисто сервисной – ответственность за смысл или бессмысленность подобного решения всецело возлагается на автора и его компетенцию; 3. Мне адекватность прямого связывания ВИ и Классов, в частности, представляется весьма сомнительным.", – что-то в этом роде (на 100% в точности содержания не уверен)… и весь разговор был бы много короче. Все…
Да, топик можно закрыть (я должен заблокировать тему? - не нашел в хелпе).

Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 08 Ноября 2009, 15:24:13
Да, топик можно закрыть (я должен заблокировать тему? - не нашел в хелпе).
Блокировать не надо, мало ли какие вопросы, связанные с темой возникнут.

Выводы, которые Вы сделали, в частности 1, кажутся мне спорными. Но не так важно.

Реализация связи и прослеживаемости одних элементов UML через другие, сильно зависит от инструмента.

Sparx EA предлагает свою модель, возможно далеко не идеальную и не сразу понятную.

Еще раз перечислим способы, чтобы добиться того, о чем спрашивают в топике.

В дереве проекта мы создаем в разных пакетах различные артефакты: элементы, диаграммы и т.п.
На хотелось бы продемонстрировать связь одних артефактов через другие. Связь должна определяться потребностью. В нашем случае мы хотели показать какие классы(класс) реализует ВИ (просто связан с ВИ слишком абстрактно)

1. Создать новый пакет - скажем связей между артефактами и создать новую диаграмму - по сути любую.
На эту диаграмму перетащить как Simple Link соответствующий UC и класс(классы). Связать классы с UC отношением реализации

2. Создать пакет UC realisation, в нем диаграмму реализации. Перетащить на нее UC и создать collaboration. Сделать collaboration композитной (Make Composite). Добавит диаграмму классов, куда из репозитория перетащить классы участники

3. Не делать UC Realisation, а рассматриваем UC сделать композитным и назначить нужную диаграмму (там можно назначить массу диаграмм, права по умолчанию будет открываться одна только)

При этом можно вызвать Вид Иерархии - тогда встав на UC можно проследить все его связи с другими элементами. Можно вызвать More Windows/Relationships и тоже увидеть все виды отношений данного элемента с другими

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

Вот кстати: Traceability in Enterprise Architect (http://www.sparxsystems.com/resources/traceability.html)
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Виталий Григораш от 09 Ноября 2009, 09:42:10
1. Создать новый пакет - скажем связей между артефактами и создать новую диаграмму - по сути любую.
На эту диаграмму перетащить как Simple Link соответствующий UC и класс(классы). Связать классы с UC отношением реализации
2. Создать пакет UC realisation, в нем диаграмму реализации. Перетащить на нее UC и создать collaboration. Сделать collaboration композитной (Make Composite). Добавит диаграмму классов, куда из репозитория перетащить классы участники
3. Не делать UC Realisation, а рассматриваем UC сделать композитным и назначить нужную диаграмму (там можно назначить массу диаграмм, права по умолчанию будет открываться одна только)
Эд, этот способ живет, имхо, только в случае когда у тебя 10-20 требований и классов (для учебных проектов сойдет).
Если порядок требований и классов переваливает хотя бы за 100, то на диаграмму их таскать - тоска смертная (проверял на себе).
Для этой цели лучше воспользоваться матрицей отношений.
Там сразу видно все элементы, которые ты хочешь соединить. Связь тоже можно выбрать.
На счет пакетов полностью согласен, удобней работать будет в матрице
 
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 09 Ноября 2009, 10:03:02
Для этой цели лучше воспользоваться матрицей отношений.
Ты, конечно, прав
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Золотая рыбка от 09 Ноября 2009, 11:10:58
Для этой цели лучше воспользоваться матрицей отношений.
Если не трудно, можно чуть-чуть поподробнее? Это просто компактная форма представления связей между артефактами, насколько я понимаю?
В EA, например, есть такой инструмент?
P.S. Отдельное спасибо Michaj за поднятую тему.
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Виталий Григораш от 09 Ноября 2009, 11:14:07
Если не трудно, можно чуть-чуть поподробнее? Это просто компактная форма представления связей между артефактами, насколько я понимаю?
В EA, например, есть такой инструмент?
P.S. Отдельное спасибо Michaj за поднятую тему.
Да, в EA это есть.
View - Relationship Matrix
Далее выбирает типы элементов которые вы хотите связать и пакеты где они находятся.
Выбираете тип связи и просто на матрице отмечаете связи.
Матрицу можно сохранить как профиль и просматривать в ресурсах проекта (View-Resources)
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 09 Ноября 2009, 11:32:01
Виталий, можешь подготовить небольшой FAQ с примером, я размещу
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: [прилетело НЛО и...] от 14 Сентября 2017, 23:02:15
Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?
По стандарту вариант использования может быть соединён связью с классификатором "сабджектом", которым может быть класс. Т. е. у класса могут быть "свои" варианты использования, описывающие способы взаимодействия с его экземплярами. Связь варианта использования с "сабджектом" изображается размещением ВИ внутри рамок его "сабджекта" (например, класса).
[Улечу, пока не пришли линчеватели из веток о том, чем является и чем не является ВИ.]
P. S. VP позволяет довольно много вольностей в соединении ВИ c классами связями разных типов. Попробуйте, будете удивлены. [Почти все, кроме допускаемой стандартом.]
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: Galogen от 15 Сентября 2017, 22:45:21
По стандарту вариант использования может быть соединён связью с классификатором "сабджектом", которым может быть класс. Т. е. у класса могут быть "свои" варианты использования, описывающие способы взаимодействия с его экземплярами. Связь варианта использования с "сабджектом" изображается размещением ВИ внутри рамок его "сабджекта" (например, класса).
[Улечу, пока не пришли линчеватели из веток о том, чем является и чем не является ВИ.]
P. S. VP позволяет довольно много вольностей в соединении ВИ c классами связями разных типов. Попробуйте, будете удивлены. [Почти все, кроме допускаемой стандартом.]

Не совсем понятно. А можно проиллюстрировать, то, что написано. А то как-то очень сложно воспринимается.
Уточню. Класс может иметь свои ВИ по отношению к другой структурной части. Правильно? Например, Класс Продажа к Единице продажи, чтобы узнать ее общую стоимость (количество*цену). А класс Единица продажи обращается к Описанию товара, чтобы узнать цену его.  И каждое такое обращение, можно представить как ВИ, т.е. Описание товара будет иметь ВИ "Получить цену", а класс ЕП - "Подсчитать стоимость" - в этом нет ничего удивительного, но , возможно, такой путь слишком затратен, как и описание системы (сложной) через все ее возможные состояния и переходы.
 
Название: Re: Явная связь класса с прецедентом - бред?
Отправлено: [прилетело НЛО и...] от 16 Сентября 2017, 12:46:10
Быстрее так, ВИ класса Продажа описывают поведение его экземпляров и экземпляров его частей (Единиц и проч.) при обработке запросов, пришедших извне. Например, со стороны класса Клиент.
Речь не о том, чтобы всю систему описывать до мельчайших винтиков. Джекобсон/Якобсон смог зашить в стандарт изобретённое им (а не авторами методик по работе с требованиями через ВИ) понимание того, что такое ВИ.