Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - RuZzz

Страницы: « 1 2 3 4 5 6 7 8 9 10 »
76
К сожалению я нахожусь в Петербурге. У нас подобные мероприятия либо не проходят, либо я о них не знаю.

Но вы же будете показывать примеры на RSA, а RSA это коммерческий продукт, который не поддерживает генерацию PHP кода. Или можно это обойти?

77
Рисование в виде поддиаграммы, показанной на основной диаграмме (как на рисунке) вообще не имеет смысла.

Я пришёл к такой диаграмме, взглянув на диаграмму по ссылке
http://www.vp-trainingcenter.com/summary/usingactivitydiagram.html

То есть вы этом случае рисуется активность, внутри которой рисуется детализация, но сама она ни куда не подключена, так?

В VP не нашёл элемент call bechavior action, из Action ни как не сделать поддиаграмму активности, а из активности можно сделать поддиаграмму активности.

78
А как правильно детализировать активность? На отдельной диаграмме или внутри активности?
На первой диаграмме детализация активности "Инициализация модуля MSSP в микроконтроллере" находится в sub-diagram, а на второй она находится внутри активности.

PS интересно как показывать на диаграмме активности условную компиляцию
#if   (ID_DEVICE_TYPE==4)
handler_rf(INIT);
#else
handler_mifare(INIT);
#endif

79
степень использования диаграмм, определяется пониманием UML. В процессе проектирования на каждой итерации возникает необходимость в добавлении новой диаграммы.

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

Стараюсь использовать диаграмму классов только по прямому назначению. Пишу на C потому, что для микроконтроллерах не всегда удаётся найти подходящий компилятор C++, да и производительность не всегда позволяет.

Для модулей стараюсь использовать диаграмму компонентов. Диаграмму классов просто пропускаю.

Логику описываю на диаграмме активности. Если она нарисована криво, то код программы воспринимается легче диаграммы.

Поскольку модули раскладываю по папкам изображаю структуру папок на диаграмме пакетов. Обычно для моих задач получается всего 3 пакета - drivers, libs_static(статические библиотеки написанные мной), tasks(для микроконтроллеров народ обычно разбивает программу на задачи, особенно актуально если прикручивается ОС).

Диаграмму развертывания ещё до конца не освоил, делаю лишь наброски.

Временную диаграмму в электронике обычно рисуют и не зная UML. Если не нарисовать то приходится держать её в голове.

UML скорее подходит для ООП, но для проектирования процедурных программ ничего лучше пока не нашёл.

80
На диаграмме состояний элемент "Нажата кнопка Submit" смущает. Я бы описал алгоритм этого перехода на диаграмме активности. Этот элемент, если его рисовать, назвал бы "проверка данных авторизации" то есть на более высоком уровне, чтобы исключить детали интерфейса из диаграммы состояний.

http://vv.sytes.net/files/rec/share/lib/uml/uml_sound_rec.pdf

На странице 18 изображены переходы по менюшке.

У меня пару вопросов к знатокам.
Framework(джумла например) это внешняя система, которую мы помечаем актёром на ДВИ?
Показываем ли мы framework как компонент на диаграмме компонентов?
И как показать его на диаграмме развёртывания?

То есть суть вопроса в том как указать на диаграммах присутствие framework в системе?

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

87
Примеры / Re: BUSINESS USE CASE MODEL
« : 31 Мая 2011, 21:54:31 »
так в FAQ написано
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей.
Значит БДВИ для системы не существует?

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

89
И диаграмма бизнес-объектов - это по идее и есть модель предметной области, да и вообще формулировку "диаграмма бизнес-объектов" я только на этом сайте и встречал..
Вот поэтому я и спрашиваю здесь с чем её едят, так как больше нигде не найти(на русских порталах). Например, не ясно нужно ли строить отдельно БДВИ предметной области и БДВИ системы или они по хорошему будут выглядеть одинаково и представлять из себя одну диаграмму?
FAQ на этом сайте трактует одназначно:
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей.

Но у меня закрались сомнения разве не нужно делать БДВИ для самой системы, а не для предметной области? Просто где-то видел это в инете.

90
Примеры / Re: BUSINESS USE CASE MODEL
« : 31 Мая 2011, 00:00:29 »
БДВИ для предметной области и для моделируемой системы это одно и то же? или нужно рисовать 2 диаграммы отдельно?

Страницы: « 1 2 3 4 5 6 7 8 9 10 »