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

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

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

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

Ну я вроде как так и старался сделать примерно.. Похоже хоть немного на правду ?

Я конечно не эксперт в ООП. Но если у класса потомка от класса родителя наследуются методы то зачем прописывать у потомков класса Module SetAccessLevel? Возможно это перезагрузка метода? В любом случае хотелось бы услышать ваши комментарии.

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

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

Кстати может сделать класс формы, как родителя класса меню? вместо наследования от класса модуль.

И если используете пакеты, то диаграмму пакетов тоже хотелось бы увидеть. Может вам лучше файл офисного пакета выкладывать. а то не хватает комментариев по диаграммам.

Ну я вроде как так и старался сделать примерно.. Похоже хоть немного на правду ?

Похоже. Но помни, не следует показывать все, показывай главное. Ведь каждый модуль можно рассмотреть отдельно. Joomla фреймвёрк MVC. Каждый функциональный блок в нем самостоятелен, покажи на одной диаграмме только функционально связанные классификаторы.

Да если смотреть на способ реализации все-таки там должен быть класс представления, класс управления и класс моделей, я не ошибаюсь?

Я конечно не эксперт в ООП. Но если у класса потомка от класса родителя наследуются методы то зачем прописывать у потомков класса Module SetAccessLevel? Возможно это перезагрузка метода? В любом случае хотелось бы услышать ваши комментарии.

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

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

не знаю.. мне уже сдавать через пару дней, а я нихрена не успеваю.. может и сделаю, если разберусь

Кстати может сделать класс формы, как родителя класса меню? вместо наследования от класса модуль.

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

Joomla фреймвёрк MVC. Каждый функциональный блок в нем самостоятелен, покажи на одной диаграмме только функционально связанные классификаторы.

да уж, жаль я раньше не знал о существовании этого шаблона.. теперь все стало понятнее.. жаль только поздновато

так это получается для каждого уровня надо свою диаграмму классов? или достаточно указания каждого из классов на 1 модели?

да уж =)
http://joomlacode.org/gf/project/joomla/scmsvn/?action=browse&path=/documentation/joomla.uml/

Диаграмма состояний для ви "загрузка заказа"

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

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

мне уже сдавать через пару дней, а я нихрена не успеваю..

Я советую оставить как есть, займитесь оформлением. А потом если будет интересно разберемся до конца, наверняка вам поставят хорошую оценку если будет хорошо подано.


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

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

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

По ДС.

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

1. В целом неплохо
2. Вход - тут можно указать либо как событие, либо как действие на переходе (скорее последнее): открыта сессия, начался сеанс
3. Вести логин и пароль - это внутренняя деятельность в состоянии Форма авторизации. Триггер=событие = Нажата кнопка Submit [Логин + пароль = @Логин + @Пароль]
4. Из этог же состоянию будет переход в само состояние (хотя можно и не указывать) Нажата кнопка Submit [Логин <> @Логин |Пароль<> @Пароль]/showMessage('Нет пользователя с такими учетными данными')
5. все что у тебя в [] - сторожевое условие, или просто УСЛОВИЕ - выражение булевского типа, а не то что у тебя. ТО что у тебя либо триггер либо действие на переходе. Сторожевое условие необязателно, но если есть то говорит возможен ли переход из одного состояния в другое. С.У. обязательно если из состояния есть несколько переходов, в текущий момент времени возможен только один т.е XOR условие
6. Выход должен приводить не к форме авторизации, а к прекращению сеанса и конечному псевдосостоянию. Либо суперсостояние Сайт  нужно убить как лишнее и не нужное, только затрудняющее понимание

ну если EA так показывает методы наследованные от родителя то не косяк.

Да не, там как раз имелась ввиду наверное перегрузка метода, а я чето забыл про эту тему, хорошо что ты напомнил =)

Я советую оставить как есть, займитесь оформлением. А потом если будет интересно разберемся до конца, наверняка вам поставят хорошую оценку если будет хорошо подано.

спасибо =) я вообще просто сдать хоть на чето надеюсь

А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других.

Ок))

А вообще, UML - весьма интересная штука, хотелось бы и дальше ей заниматься. Только вот я думаю, что все-таки для генерации кода uml не очень применим, а вот на более асбтрактном и иногда, наверное, даже бытовом уровне, его применение может быть весьма полезно имхо.

Цитата
По ДС.

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

1. В целом неплохо
2. Вход - тут можно указать либо как событие, либо как действие на переходе (скорее последнее): открыта сессия, начался сеанс
3. Вести логин и пароль - это внутренняя деятельность в состоянии Форма авторизации. Триггер=событие = Нажата кнопка Submit [Логин + пароль = @Логин + @Пароль]
4. Из этог же состоянию будет переход в само состояние (хотя можно и не указывать) Нажата кнопка Submit [Логин <> @Логин |Пароль<> @Пароль]/showMessage('Нет пользователя с такими учетными данными')
5. все что у тебя в [] - сторожевое условие, или просто УСЛОВИЕ - выражение булевского типа, а не то что у тебя. ТО что у тебя либо триггер либо действие на переходе. Сторожевое условие необязателно, но если есть то говорит возможен ли переход из одного состояния в другое. С.У. обязательно если из состояния есть несколько переходов, в текущий момент времени возможен только один т.е XOR условие
6. Выход должен приводить не к форме авторизации, а к прекращению сеанса и конечному псевдосостоянию. Либо суперсостояние Сайт  нужно убить как лишнее и не нужное, только затрудняющее понимание

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

http://caveman.ru/yii.1.1.2r2135.png вот кстати диаграмма классов yii framework. Не встречали такое для джумлы?
Обратите внимание на название пакетов.

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

После авторизации - ты пропускаешь посетителя в закрытую зону.

В любой момент времени может произойти обрыв сессии, по желанию или без посетителя.

Показав составное состояние, вовсе не нужно явно показывать переходы из всех состояний по событию выход. Если оно призойдет, тебя так и так выкинет из сеанса и тебе придется начинать новый следовательно пройдешь авторизацию

Показав составное состояние, вовсе не нужно явно показывать переходы из всех состояний по событию выход. Если оно призойдет, тебя так и так выкинет из сеанса и тебе придется начинать новый следовательно пройдешь авторизацию

ну под выходом имеется ввиду разлогинивание, это можно сделать со всех страниц сайта, но не со всех состояний. Ну типа как переход на домашнюю страницу.. Тоесть нельзя нажать, например, когда открыто диалоговое окно загрузки файла.. Я не знаю, убрать, не нужно это?

Цитата
http://caveman.ru/yii.1.1.2r2135.png вот кстати диаграмма классов yii framework. Не встречали такое для джумлы?

Я вообще таких картинок не встречал раньше =) какой псих это делал))
Для джумлы я находил только упрощенные ЕР диаграммы, например:
http://oozman.com/wp-content/uploads/2011/03/joomla-15-erd.png
http://img142.imageshack.us/img142/2519/joomla10databasetables1ge.png
хотя вторая вообще какаято странная..
Ну и по той ссылке, что я постил раньше находятся вообще все UML диаграммы, относящиеся к джумле, просто они не слеплены в 1 картинку)

вопросы по диаграмме коммуникаций:
изображаются ли на ней return messages?
в ней участвуют объекты, которые я выделил в концептуальной модели? или программные классы? или в моем случае формы?
вообще есть какие-нибудь рекомендации по этой диаграмме? А то чето в инете очень скупо описано про нее..