Дипломное проектирование закрытого портала для оптовых покупателей(Прочитано 57617 раз)
Цитировать
А система управления проектами может входить в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.

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

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



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



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



Вот, можно так сделать? =) все довольны будут тогда)
« Последнее редактирование: 01 Июня 2011, 08:18:28 от rave »



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

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



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

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

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



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



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

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



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

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

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



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




На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action
« Последнее редактирование: 08 Июня 2011, 00:21:46 от RuZzz »



На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action
ты про "оплатить счет" --> "получить сведения об оплате" ? А чем еще соединять отправку и прием кроме стрелочки?)
Вот тут в примере даже соединено так..

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



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



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

Видел, что некоторые строят диаграмму классов предметной области. В ней не упоминаются классы самой системы. Сам не разобрался насколько она нужна, если есть диаграмма бизнес-объектов. Эдуард вероятно говорил о диаграмме классов для реализации системы. Скорее всего в вашем случае нужно смотреть на реализацию и по ней делать диаграмму классов.
Ваша система реализована на классах или процедурах?
Хотел без нее обойтись, у меня ведь уже есть реализация..
У вас хорошо получается, зачем останавливаться :) Ваш пример поможет не только нам лучше разобраться, но и многим другим. Тема очень актуальная. Кроме того, сделав полную модель системы, вы можете найти ошибки в реализации.
« Последнее редактирование: 08 Июня 2011, 10:27:57 от RuZzz »



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

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




 

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