421

UML SysML и пр. / Re: Что это за отношение?

« : 23 Июля 2008, 22:22:37 »

... у Рамбо зависимость обычно используется в том случае, когда в методе класса А в качестве параметра используется класс Б...

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

422

UML SysML и пр. / Re: Что это за отношение?

« : 23 Июля 2008, 22:21:18 »

Это зависимость.
Причем существует по крайне мере два способа ее изобразить (см. рисунок)

423

Примеры / Re: Оформление диаграммы прецедентов

« : 23 Июля 2008, 13:06:54 »

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

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

424

Для всех / Метрики

« : 21 Июля 2008, 18:04:46 »

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

Не знаю к какой группе отнести Functional Points.
Эта метрика меня интересует в первую очередь.

Различные интернет ресурсы я нашел (почитываю их потихоньку), но предпочел бы грамотную (электронную) книгу.
Также хочется посмотреть на реальный пример.

Может кто-нибудь помочь?

425

Системный Анализ и Требования / Re: Хорошие требования vs Сырые требования

« : 20 Июля 2008, 23:24:02 »

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

На сколько я понимаю - это принцип напрямую используется в alige методах разработки (Scrum, XP, UP (упомянутый Galogen) )

426

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 20 Июля 2008, 15:29:07 »

Рамбо, например, очень широко использует квалифицированную ассоциацию, по сути сводя ее до уровня понятия экземпляра связи.

Связь - экземпляр ассоциации.
Что такое "экземпляр связи" можно только догадываться.

Лучше процитировать Рамбо...

427

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 19 Июля 2008, 23:18:48 »

Может значение терминов будем брать из стандарта UML?

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

Квалификатор никак не связан с ОО, а пришел из схем баз данных.

428

Нововведения / Re: Популярно об UML 2.0

« : 18 Июля 2008, 11:20:26 »

Однако насколько я понимаю, кооперация не ограничивается только шаблонами проектирования? Вы сами сказали, что возможны и поведенческие моменты?

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

Еще интересно понять возможности использования разных дополнительных элементов типа портов, частей и т.п.

Безпредметно (без контекста) говорить об этом сложно. Гораздо продуктивнее будет привести какой-нибудь пример (например, картинку) и о ней поговорить.

Без портов вполне можно обойтись. По сути они просто указывают (и именуют) точки через которые элементы могут взаимодействовать с внешним миром.
Часть - обобщенное название элементов из которых состоит структурный классификатор (например, класс или компонент).

429

Нововведения / Re: Популярно об UML 2.0

« : 17 Июля 2008, 16:05:31 »

Что касается коллобораций и некоторых новых диаграм вполне актуально.

В UML 1 была диаграмма кооперации (Collaboration diagram), название которой вводило в заблуждение, так как люди думали, что на ней надо было рисовать кооперации, а на самом деле диаграмма кооперации отображала взаимодействие объектов при выполнении какого-нибудь сценария.
В UML 2 ошибку исправили и переименовали диаграмму кооперации в диаграмму коммуникации (Communication diagram).

Сама по себе кооперация (Collaboration)- это сущность.
Кооперация состоит из элементов(классов), суммарный эффект взаимодействия которых больше, чем сумма эффектов отдельных элементов.
Кооперация описывается со структурной (диаграммы классов) и динамической точек зрения (какая-нибудь диаграмма взаимодействия).

Каждый элемент в кооперации играет свою роль. Когда кооперация реально применяется в проекте (рисуется она на диаграмме классов), каждый из ее элементо замещается реальным классом проектируемого приложения.

Картинки позже нарисую...
Примером кооперации может служить любой образец проектирования, т.е. решение, которое можно использовать повторно.

430

Нововведения / Re: Новый термин (почти тоже что и Наследование)

« : 17 Июля 2008, 14:33:01 »

Пример.

Предметная область - линейная алгебра.
Выводится следующая иерархия (см. рис.1)

Есть Числа (интерфейс).
Комплексное число - специализация Числа.
Действительное число - специализация Комплексного числа.

Такая иерархия разумна с точки зрения предметной области.

Теперь посмотрим на программиста, который начинает делать реализацию.
Он написал оболочку классов и теперь внутрь запихивает данные.

В Числе нет данных по определению (интерфейс).
В Комплексном числе два double.
В Действительном числе должен быть один double, но к нам из Комплексного числа по наследованию уже два(!) приехало.
Получаем ситуацию, описанную автором топика.

Кто виноват?
Виновата иерархия абстракций предметной области, которая НЕ совпадает с иерархией данных.

Отступление: Еще можно построить иерархии алгоритмов подобным образом и с ней тоже может быть не все в порядке.

Что делать?

Смотрим рис.2

Это и есть bridge

431

Нововведения / Re: Популярно об UML 2.0

« : 14 Июля 2008, 22:35:10 »

UML 2.0 становится стандартом или уже стал таковым.

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

Не понятно, например, что такое collaboration и как его использовать. И вообще хотелосьбы узнать как применять новые диаграммы и как они согласуются со старыми

еще актуально?

432

Нововведения / Re: Новый термин (почти тоже что и Наследование)

« : 14 Июля 2008, 22:30:37 »

То, о чем говорит автор называется отрицательной изменчивостью.
Читаем Д.Коплиена (http://www.books.ru/shop/books/236692) и не надо ничего придумывать.

Образец проектирования bridge один из вариантов решения проблемы.

433

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 14 Июля 2008, 14:58:12 »

Наверное архитектору и не стоит вникать в детали реализации. верно? Надо делать свою задачу, а девелоперы уже будут делать свою?

В детали релизации влезать не стоит, но показать динамику и др. безусловно необходимо.
Почитай про представления (view)

434

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 14 Июля 2008, 14:56:43 »

Вот, к примеру, в моём "старом" проекте реализовано кеширование объектов. при этом формирование списков объектов и самих объектов происходит довольно быстро, но хранить списки после использования - нельзя...
Т.о. возникает задача показать на диаграмме классов, что список объектов держать членом класса -нельзя. Это можно сделать в виде отдельного комментария на диаграмме, а можно как-то более конкретно?

Это нефункциональное требование - только комментарий

435

UML SysML и пр. / Re: Ассоциации + квалификаторы

« : 14 Июля 2008, 14:33:18 »

>А.1. Нижняя ассоциация на ваших диаграммах показывает связь команды и её владельца по полю UserId, которое хранится в экземплярах класса Team. Верно?

Нижняя ассоциация отображает требование
"У каждой команды владелец может быть либо один владелец (его идентификатор хранится в поле UserId), либо ни одного владельца (UserId=0)."


>А.2. В правой части ассоциации можно было бы поставить "1", но по умолчанию 1 можно и не ставить, так?

Нет не так. Не существует кратности by default. Если ничего не стоит, то значит ничего не известно и никаких выводов (например, подразумевается 1) сделать нельзя.

>А.3. В левой, как у вас и стоит "0..1" - так и остаётся.
>А.4. По идее, для этой ассоциации тоже можно создать квалификатор Team.UserId (или просто UserId) и отобразить его со стороны класса User?
С одной стороны - Да, но назвать его надо User.id и положить на сторону team.
У тебя есть значенние ключа (team.id), но он используется, чтобы снизить кратность на полюсе User (через поле user.id)
Но с другой стороны, ты же в условиях задачи уже указал кратность и понижать ее некуда.

>А.5. Мне кажется, что здесь неплохо было бы использовать DirectedAssociation (стрелочка в сторону класса User)?
Можно. Но лучше от стрелочек воздержаться (общая практика).

>А.6. Данная ассоциация представляет, что User является владельцем Team, т.о. можно обозвать левый краяй ассоциации как "Owner", верно?
(на моём новом рисунке данная ассоциация показана снизу).

Как и было на моем рисунке... Но если ассоциация одна, то роли редко пишут. Обычно это ясно.

>Б.
>Выше (в п.А) мы описали, каким образом класс Team ссылается на класс User. А теперь, наверное, стоит описать и тот факт, что класс User может иметь метод, который возвращает список объектов класса Team, верно? С точки зрения программной реализации задачи, такой метод должен быть.

Зависит от многих вещей, но предположим...

>Б.1. Я так думаю, что чем нагружать уже существующую ассоциацию, то лучше ввести новую, верно? Если нет, то почему и как тогда надо предстваить ассоциацию?
>Б.2. Как отобразить ассоциацию, если есть необходимость показать разработчику, что такой метод должен быть членом класса User, а его реализация метода предполагает обращение к статическому метода GetTeamsByUser(User user) класса Team, который содержит все объекты своего типа в некотором статическом контейнере и при обращении отбирает те элементы, которые удовлетворяют некоему условию (в данном случае team.UserId=user.Id)

Тут начинается путаница... Ассоциация просто описывает знание одного класса о наличии другого и все. Не надо связывать ассоциации с конкретными методами. Ассоциация показывает что в run-time один объект может вызвать методы другого вот и все.

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

Предлагаю тебе исходя из всего написанного еще раз сформулировать задачу, чтобы не было неточностей. А потом поговорим...