Явная связь класса с прецедентом - бред?(Прочитано 48051 раз)
Простите чайника. Не могу понять принципы связи между элементами различных видов диаграмм (между диграммами различных видов) одной модели. Предусмотрена ли в UML вообще, в CASE-системах в частности, и в EA в частности частности, нотация для явного отображения таких связей? Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)? Мне все время этого хочется, допускаю, что это заблуждение, но не понимаю в чем оно. Разве не естественно, если необходимость конкретного класса вытекает из существования конкретного прецедента? Разве не полезно документировать такую связь? Но я не обнаруживаю для этого методов/способов ни в UML, ни в ЕА ... Помогите разобраться, что я изначально не так понимаю?



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



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



Можно еще связь реализации сделать в EA. По сути тоже подходит. Вариант использования реализуется набором классов
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Разве не естественно, если необходимость конкретного класса вытекает из существования конкретного прецедента?
Нет, из существования прецедента не вытекает необходимость создания конкретного класса. Любой прецедент можно реализовать многими разными наборами классов, их придумывание как раз и составляет процесс разработки архитектуры системы. Грубо говоря, реализации прецедента "пользователь садится в безлошадную повозку и едет в пункт назначения" не требует использования класса "Двигатель внутреннего сгорания". Это может быть и класс "электрический двигатель". Но когда вы выбрали класс ДВС для работы в составе системы, имеет смысл поставить трассировку от него на прецедент, чтобы потом, когда очередной разработчик предложит вместо ДВС использовать лошадь, можно было по трассировке быстро найти причину, почему лошадь нельзя.



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

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

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

Спаисбо всем, уже есть пища, надо попереваривать ...



не очень понимаю что вам конкретно нужно. может вы изобразите нам идею того, что вы хотите?



Варианты использования суть наборы сценариев. Сценарии реализуются (в ОО системах) взаимодействием некоторого количества классов. Это "некоторое количество классов" называется кооперация. Можно провести зависимость от кооперации к варианту использования.
Ну а классы играют определенные роли в кооперации, что также можно показать стандартной нотацией UML.



to  Galogen, №6)
не очень понимаю что вам конкретно нужно. может вы изобразите нам идею того, что вы хотите?
– Имеется задача, которая сводится к необходимости  разработки и внедрения в существующую систему новой функциональности. Суть ее состоит в появлении нового, глобального для задачи,  сквозного опорного аттрибута, что связано с запуском производства вида продукции, значительно отличающегося от прежнего. Проблема в данном случае лежит именно в структуре, свойствах и методах классов, где сейчас ни такого аттрибута, ни методов для работы с ним, естественно нет. Алгоритмические вопросы здесь и пока для меня второстепенны. Сейчас объектная модель системы практически точно воспроизводит объектную модель бизнеса в жизни (вернее, они реально "кратны" друг-другу), что я считаю важным, и о чем я всегда специально забочусь. Поэтому UseCase-диаграмма и Class-диаграмма практически "параллельны" друг-другу. Рисунок во вложении. Но на данный момент в модели никак не отображен этот факт – что, например, класс "док.Путевка" в системе является конкретной реализацией прецедента  "Создание партии продукции". Но разве это не так, буквально? Разве это не важно для модели? Предполагая, что это "так", но не найдя самостоятельно способа задания данной связи в программе (Sparx), как ни искал, я и обратился за помощью к мэтрам... Однако, по большому счету, вопрос в том, что я пытаюсь освоить новый метод работы и пытаюсь как можно раньше сформировать у себя единый  образ дисциплины (UML), пусть даже сначала и без всех деталей. Но существуют ключевые вопросы, без которых никакой цельный образ невозможен. Одним из таких вопросов в данном случае, для меня является вопрос о взаимодействии видов диаграмм, частным случаем которого является исходный вопрос.



Если честно, все равно не могу просечь в чем проблема?

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

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

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

А что такое за атрибут Размер(Заказ)? Отличается Размер как атрибут от Размера как класс?



Поэтому UseCase-диаграмма и Class-диаграмма практически "параллельны" друг-другу. Рисунок во вложении.
К меня создалось впечатление, что Вы неправильно используете Use Case'ы.
Вы по каким источникам изучали UML?



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

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

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

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

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

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

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

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


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

Я думаю тут вам еще мешает что вы мыслите категориями 1С, правильно ли я понимаю?



Это сообщение я написал до того, как получил два последних ответа в топике, которые практически уже содержат ответы по некоторым моментам данного. Что-то теперь следовало бы в нем изменить, но опасаюсь, что пока буду исправлять, это тоже успеет устареть. Очень боюсь истощить Ваше терпение, но один этот разговор думаю стоит недель, если не месяцев самоварения. Мне кажется, он может помочь и другим новичкам, так как вряд-ли мои вопросы и сомнения уникальны. А на теперь уже предыдущие два ответа, я напишу отдельно.
Если честно, все равно не могу просечь в чем проблема?
Проблема в том, что проковырявшись уже достаточно долго в книгах, факах и хелпах, познакомившись с большим количеством сущностей UML и вооружившись Sparx, я так и не сумел составить какой-либо вразумительный общий образ использования дисциплины (не теории, а практики). Я опасаюсь, что разговор переходит в оффтопик, но ответ на ваш настойчивый вопрос лежит именнно в этом. Одновременно, большое спасибо за Ваши следующие вопросы, надеюсь они помогут мне задавать свои более вразумительно.
Цитировать
Что же вы все-таки хотите? Показать некую связь некоего ВИ с неким классом? Так Вам уже много способов дали. Причем denis-itk дал Вам  чисто классический способ через кооперации (во многих местах можно почитать).
Можете не верить, но видимо я в эти места не попадал… Однако прочтя советы denis-itk, я тут же отправился в Sparx с намерением ими воспользоваться. На данном, очень низком этапе своего развития, слова о кооперации классов в контексте какого либо ВИ в моем представлении приобрели образ некоего объекта Collaboration в качестве контейнера в виде рамки на диаграмме, в который следует поместить некие классы, и связать уже эту рамку с ВИ. Но, как оказалось, в диаграмме классов, в ее наборе, нет элемента типа Collaboration … Ладно, зато такой элемент есть в диаграмме ВИ. Попробовал здесь создать Collaboration, и в него из дерева модели перетащить … что? Речь ведь идет об объединении классов … Ну, перетащил в него класс. – На Collaboration возникла пупырышка с название Port (…?). Я понял, что опять делаю что-то не то …
Цитировать
Не нравятся кооперации, используйте трассировки, не нравятся трассировки, изобразите реализации. Не нравятся реализации - сделайте просто гиперссылку одного объекта на другой. Ну что еще посоветовать, можно добавить теги, связать эти теги и как-то прослеживать связность...
Я думаю, что первая проблема новичка не в том, что он не знает всех кнопок (меня уже очень давно не волнуют подобные проблемы), а в том, что иногда долго не удается уловить самой базовой логики данной области знаний (при том, что уже начитался и о достаточно специальных ее деталях). Я думаю дело в том, что авторы-источники знаний, просто упускают излагать информацию, представляющуюся им тривиальной, но которая на самом деле и составляет базовый контекст, в котором только и становится понятно то, что они излагать находят нужным и интересным… Это явление повсеместно. Каждый знает это по себе: берешь книгу в руки в первый раз – все совершенно непонятно, как на китайском языке. Открываешь ту же книгу через пару лет – и диву даешься, что там могло быть непонятным с самого начала … А все дело именно в знании контекста, – объективно – это самое элементарное, а дается - с наибольшей кровью, потому что доступные источники, как правило, это опускают. Вот что мне надо (по очень большому секрету). Извините, что получается так длинно, но это мой первый топик здесь и я (опять же!) еще не знаком с контекстом данного форума (как форума, а не UML), и лишь честно пытаюсь исчерпывающе отвечать на вопросы.
Цитировать
Теперь о диаграммах - это вообще что? Что это за ВИ "Свободные остатки"?
Я хотел отобразить ключевой объект, который автоматически формируется в процессе выполнения функций одними пользователями, и от которого зависят возможности других пользователей при исполнении ими их функций.
Цитировать
Что это за зависимости "создание"?
Прецедент, который "создается", автоматически инициируется в транзакции выполнения родительского прецедента. Но затем с ним работает (редактирует) другой пользователь.
Цитировать
И что это за компот из "создания", "include" и "invokes".
Думаю что "компот" – это следствие незнания того самого базового контекста, о котором и пытаюсь получить, прямо или косвенно, любые сведения. Например, я четко знаю что такое "эклектика", но только благодаря тому, что я знаю соответствующий контекст эстетики. А вот что такое "компот" приминительно к UML – очень хотел бы узнать.
 
Цитировать
Кстати а почему include в императиве, а invokes в 3 лице?
Потому что Вы первый, кто сказал мне, что это плохо  :(
Цитировать
Создание ТТН непременно включает Отгрузку со склада ГП?
Да. ТТН это только контейнер с собственными товарно-транспортными реквизитами. Пользователь вручную, из списка допустимых Отгрузок, выполненных ранее кладовщиками на разных складах ГП, включает некоторые из них в данную ТТН в качестве оснований для Приложений к этой ТТН (собственно детальных списков продукции)
Цитировать
А что такое за атрибут Размер(Заказ)? Отличается Размер как атрибут от Размера как класс?
Из-за этого Размера весь сыр-бор. Не очень понимаю вопрос. Предполагаю (но это еще не точно), что должен быть создан класс "Размер_Заказ", который позволит где необходимо в прочих классах, создавать ссылочные аттрибуты на него, дающие доступ к значениям аттрибутов Заказчик, Длина, Ширина и пр. класса "Размер_Заказ". (дело в том, что существавшее до сих пор производство – чисто конвеерное многосерийное производство (стеклопосуда и хрусталь), не предполагавшее на этапе производства (более 100 лет существования) никакого специфицирования по потребителям, а здесь вдруг возникло производство картона (и упаковок из него, но это отдельная песня), включающее еще и его нарезку в любом формате в качестве дополнительного потребительского сервиса…).



К меня создалось впечатление, что Вы неправильно используете Use Case'ы.
У меня тоже :( Как раз пытаюсь это скорректировать
Цитировать
Вы по каким источникам изучали UML?
Кроме данного сайта, книгой Буча, точного названия нет в голове, она на работе, Уэнди Боггс, Майкл Боггс "UML и Rational Rose", Help в Sparx (но, увы, не очень силен в англ-м :( ) и прочим, что попадется ... Я не программист, но программеры на работе, которые это, казалось бы, недавно изучали в универе, разбираются в сем, оказывается, еще меньше меня...



Связь класса с 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, но их можно стереотипировать
- просто создать два элемента разных типов на одной диаграмме, переключая панели инструментов.
« Последнее редактирование: 08 Ноября 2009, 12:55:29 от AlexTheRaven »




 

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