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

×


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

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


Сообщения - rave

Страницы: 1 2 3 4 5 »
1
Всем привет. Прочитал я книгу Дина Леффингуэлла "Принцип работы с требованиями к ПО", и решил замайндмэпить ее для дальнейшей работы с изложенными в ней основными принципами. Что из это получилось, можно посмотреть тут. Строго прошу не судить, т.к. это моя первая полностью прочитанная книга по требованиям  :), плюс, можно считать, первый опыт в майндмэппинге, плюс делалось все на скорую руку, и, конечно требует некоторой реорганизации и дополнения заметками во многих местах.

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

P.S. Жду замечаний и дополнений =)

2
На русском есть ещё   "Структура бизнес-процессов для отрасли информационно-коммуникационных технологий. E-Tom для начинающих" Данный документ во вложении.

спасибо большое)

3
Tokarev_Pavel, Спасибо за материал, обязательно ознакомлюсь..

Может быть еще есть что-нибудь?)
Неужели ни у кого нет перевод книги Джона Райли, ссылку на который я давал в первом посте? :(

4
что тут нет ни 1 БА из области телекоммуникаций что ли?)

5
ух, какая тут оживленная дискуссия.. =D

6
Всем привет. Хотелось бы узнать, есть ли у кого-то материал по этой концепции? На русском языке. На английском, естественно, найти не проблема на том же тм форуме..
Желательно, чтобы кто-нибудь поделился вот этой книгой: http://books.google.ru/books?id=DHQVuTw9S1YC&dq=NGOSS&hl=ru&source=gbs_navlinks_s
Или, возможно, кто-то посоветует что-нибудь еще лучше по данной тематике?

7
кароче я защитился на 5 =) всем спасибо, особенно Эдуарду.
Правда оно того не стоило)) потомучто глядя на то, что было у остальных, я понял, что вообще зря загонялся :D
но все равно спасибо за помощь) да и для себя много нового узнал, это главное =)

8
Цитировать
Не очень понятно почему установка разрешений осуществляет форма авторизации. Ее основная обязанность предоставить возможность ввести данные и передать их тому классу, который способен выполнить цель пользователя
так у меня же так и сделано вроде.. Форма считывает данные, передает контроллеру, контроллер проверяет правильность введенных данных, наделяет пользователя соответствующим ему уровнем доступа и дает разрешение для входа на сайт.. или убрать grandpermission ? получается, что это метод формы что ли ?

10
И еще как показать на ней условие ?

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

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

Цитировать
Цитата
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 картинку)

13
Цитировать
ну если EA так показывает методы наследованные от родителя то не косяк.
Да не, там как раз имелась ввиду наверное перегрузка метода, а я чето забыл про эту тему, хорошо что ты напомнил =)
Цитировать
Я советую оставить как есть, займитесь оформлением. А потом если будет интересно разберемся до конца, наверняка вам поставят хорошую оценку если будет хорошо подано.
спасибо =) я вообще просто сдать хоть на чето надеюсь
Цитировать
А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других.
Ок))

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

Цитировать
Цитата
По ДС.

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

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

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

Страницы: 1 2 3 4 5 »