А система управления проектами может входить в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.

Ну блин, как я тогда покажу как счет, например, формируется, если он у меня вне системы вообще делается (бухгалтером в 1с или там в екселе).. А так я все составляющие вместе связал..
Я сначала так и хотел сделать, типа с устными поручениями, или там по телефону.. Но что это тогда за система.. Клиент-заказ-статус-админ, все.. Не интересно.
Я могу конечно нарисовать: Клиент аплоадит заказ, админ обновляет статус... =)

Это direction. Кликаешь по имени ассоциации правой кнопкой мыши, где-то там найдешь direction

Я это находил уже, это делает ассоциацю направленной (ну на конце стрелочка рисуется всмысле), а что бы рядом со словом - не могу найти.. 8(

А все, нашел, надо на самом лейбле ткнуть, спасибо.

Я вот думаю, надо ли в моем случае делать диаграмму классов, диаграммау коммуникации, диаграмму состояний.. Они ведь больше уже к программной реализации относятся.. Мне кажется это юслесс..
Диаграмму деятельности еще можно наверное сделать..

Вот, можно так сделать? =) все довольны будут тогда)

А администратор не авторизуется? На самом деле я почитав этот форум стал выкидывать из своих диаграмм авторизацию. Так как у меня при входе на любой сайт нет цели регистрироваться и авторизоваться. Это даже напрягает. С редактированием профиля можно тоже поспорить. Хотя у меня на диаграмме этот ВИ присутствует.
Присутствует на моей диаграмме и пакет администрирование. Свою диаграмму я делал задолго до вас и пакет выглядят практически также. Только я туда добавил редактирование прав файлов. но возможно тоже выкину.
По-моему ВИ загрузка заказа должен быть на более абстрактном уровне. В книге Коберна можно почитать про уровни вариантов использования.

Но мне интереснее другое. Я как то пробовал разбивать элементы на пакеты. Получается так что ДВИ и диаграмма классов связаны одними и теми же пакетами. И когда доходим до этапа генерации кода из диаграмм, пакеты превращаются в названия папок, в которых создаются исходники. Может быть в EA тоже самое по смыслу получится? Тогда стоит называть пакеты таким образом, чтобы потом компилятор с названиями таких папок корректно работал. У меня названия пакетов это английские короткие названия. Конечно для вас это может быть не существенно, но мне хотелось бы разобраться.
Это в EA выглядит так диаграмма всех пакетов? или это только диаграмма пакетов для вариантов использования?

Я тут подразобрался, мне терь кажется, что таким образом как я вот выложил в предыдущем посте вообще нельзя с пакетами работать. Теперь у меня просто список пакетов, в каждый из которых помимо ВИ включены еще акторы, и каждый пакет я рассмотрел как отдельную ДВИ..

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

По-прежнему еще очень интересует вопрос:

Я вот думаю, надо ли в моем случае делать диаграмму классов, диаграммау коммуникации, диаграмму состояний.. Они ведь больше уже к программной реализации относятся.. Мне кажется это юслесс..

Еще услышал от препода такую тему, что "Прецеденты в диаграмме прецедентов должны идти по порядку их использования сверху вниз".. Я если честно не слышал о таком до этого.. Вроде как для этого другие диаграммы есть.. Или действительно необходимо размещать их в порядке возникновения? Просто там довольно много параллельных прецедентов например существует.. что скажете?

Еще услышал от препода такую тему, что "Прецеденты в диаграмме прецедентов должны идти по порядку их использования сверху вниз".. Я если честно не слышал о таком до этого.. Вроде как для этого другие диаграммы есть.. Или действительно необходимо размещать их в порядке возникновения? Просто там довольно много параллельных прецедентов например существует.. что скажете?

Первый раз слышу. Хотя сколько людей столько мнений. Включай свой рассудок.

Диаграмма классов нужна - все ООП на этом построено, а у тебя не будет. весь вопрос какие классы ты планируешь рассмотреть, только предметки и интерфейсные? Читай руп или иконикс, там все ответы

Диаграмма классов нужна - все ООП на этом построено, а у тебя не будет. весь вопрос какие классы ты планируешь рассмотреть, только предметки и интерфейсные? Читай руп или иконикс, там все ответы

Ну я ведь делал модель предметной области, это вроде как сродни диаграмме классов с концептуальной точки зрения. Или надо рассмотреть диаграмму классов с точки зрения спецификации\реализации ? Я тут теряюсь вообще.. Хотел без нее обойтись, у меня ведь уже есть реализация..

А какие книжки по руп\иконикс посоветуете? я юзаю "UML. Основы" Мартина Фаулера и "UML 2 и унифицированный процесс" Джим Арлоу\Айла Нейштадт..

Вот еще чо слепил.. =)

На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action

На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action

ты про "оплатить счет" --> "получить сведения об оплате" ? А чем еще соединять отправку и прием кроме стрелочки?)
Вот тут в примере даже соединено так..

Ну вообще я ни в чем не уверен, т.к. 1ый раз такую диаграмму делал =)

Я бы заменил зависимостью. пунктирной стрелкой со стереотипом типа месадж

Ну я ведь делал модель предметной области, это вроде как сродни диаграмме классов с концептуальной точки зрения. Или надо рассмотреть диаграмму классов с точки зрения спецификации\реализации ? Я тут теряюсь вообще..

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

Хотел без нее обойтись, у меня ведь уже есть реализация..

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

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

Еще порой тяжело отличать объекты класса от классов-потомков.. Например вот с группами разобраться не могу. Каждая группа это класс, или это объект класса "группа"?
Просто у них иерархическая зависимость, и все значения передаются в зависимости от включения одной группы в другую..