376

Системный Анализ и Требования / Re: Как правильно трассировать?

« : 22 Октября 2008, 15:37:52 »

Трассировка - это направление от источника к цели, те мы трассируем от БВИ (источник) к СВИ (цель), или по другому сказать трассируем БВИ на СВИ.

А вообще, по-моему нет жесткого правила в какую именно сторону стрелочку показывать, вот отрывок статьи про трассировку

There is some question as to which direction the arrows should go: whether from lower level to higher level or from higher to lower level. Even the two examples in RequisitePro use different guidelines. The answer is that it doesn't matter, as long as you use them consistently across the project.

Я понимаю трассировку именно от верхнего уровня на нижний. Но это мое ИМХО, я так привык работать.

377

Sparx / Enterprise Architect: Трассировка требований

« : 21 Октября 2008, 17:47:41 »

Коллеги, нужна ваша помощь!
Для трассировки требований в EA мы используем матрицу отношений. Все вроде бы получается не плохо. Но возникла одна проблема, которую я не могу пока решить.
Мне необходимо получать список требований, которые не имеют трассировки. Например, список ВИ, которые не связаны ни с одной фичей (вдруг чего забыл протрейсить). Как это сделать?
Может быть возможно создать какой-нибудь отчет, но я потратив пару часов, так и не смог ничего найти. Просматривать большую кучу требований на наличие или отсутсвие трассировки не самое интересное занятие, поэтому бы хотелось узнать, как получать выборку из матрицы отношений.
Спасибо.

378

Примеры / Re: Права доступа

« : 21 Октября 2008, 09:40:16 »

Если речь идет про книгу Security Patterns: Integrating Security and Systems Engineering, то почитать в онлайне ее можно здесь http://ru.dleex.com/read/?41635

379

Варианты Использования (Use Case) / Re: вопрос знатокам Вариантов Использования

« : 20 Октября 2008, 11:45:41 »

Вот к чему приводит неаккуратное использование терминов )

Виталий, у тебя вместо «Основной сценарий» должно быть «Основной поток».

То, что там приведено — это обобщённый, сущностной (essential) сценарий.

Ага, согласен. Спасибо за исправление. Ну тогда сценарий = экземпляр ВИ. Исправил пример выше

В аттаче немного подробнее.

380

Варианты Использования (Use Case) / Re: вопрос знатокам Вариантов Использования

« : 20 Октября 2008, 10:16:06 »

2) Т.е. между вариантом использования и сценарием "просвечивает" отношение обобщения?

Я бы сказал не обобщения, а агрегация

381

Варианты Использования (Use Case) / Re: вопрос знатокам Вариантов Использования

« : 20 Октября 2008, 10:14:54 »

Вариант использования - это как правило набор потоков событий (основной + альтернативные).
Экземпляр варианта использования (сценарий) - это конкретная последовательность исполнения потоков.
Для примера, пусть у нас есть основной поток и к нему два альтернативных:

ВИ "Войти в сисетму"
O1 Основной поток. 
1. Пользователь запускает приложение.
2. Система предоставляет пользователю форму для ввода данных идентифицирующих пользователя (логин+пароль)
3. Пользователь вводит логин и пароль и подтверждает вход в систему
4. Система проверяет введенные данные и если они корректны, система предоставляет пользователю доступ к основному функионалу системы, открывая главную форму. ВИ завершен

Альтернативные потоки:
А1 [Шаг 4 О1]Неверные логин или пароль
1. Система сообщает пользователю о том, что не верный логи и пароль и приглашает пользователь снова ввести данные. Переход к шагу 3 О1.

A2 [Шаг 2 О1] Отмена
1. Пользователь отменяет вход в систему
2. Система закрывает форму ввода. Приложение закрывается. ВИ завершен.

В рамках данного варианта использования экземпляры могут быть следующие:
Сценарий 1.
О1 без алтернативных потоков (ввели данные с первого раза)
Сценарий 2.
О1 + А1 (снача ввели данные не верно, потом исправили и ввели верно)
Сценарий 3.
О1 + А1 + А2 (сначала ввели не верно, потом решили не вводить и выйти из приложения)
Сценарий 4.
О1 + А2 (решили выйти еще до ввода данных)
и тд.

382

Примеры / Re: Права доступа

« : 20 Октября 2008, 09:53:14 »

Есть много различных схем реализации прав доступа. Вот одна из них, основанная на ролях
http://en.wikipedia.org/wiki/Role_based_access_control
и еще
http://www.tonymarston.net/php-mysql/role-based-access-control.html
Если нужен доступ к данным то роль, можно представлять как CRUD матрицу. Если по мимо данных нужно ограничить доступ к функциям, то можно добавить право Execute.
+ немного в аттаче

383

Идеи и мозговой штурм / Re: Нужна научная тема

« : 15 Октября 2008, 19:29:48 »

Жадный? Да? А чего жадничаешь? я вот диссер писал по плазме водорода и его смесей с азотом, но и многие тоже писали и у нас и зарубежом. Все равно у многих: разные подходы, разные методики, разные взгляды и возможности, тем и хорошо

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

384

Идеи и мозговой штурм / Re: Нужна научная тема

« : 15 Октября 2008, 14:18:50 »

Эд, если тебе нужна тема для твоих аспирантов -- то мы с тобой уже осуждали. Как вариант -- на базе модели зрелости CMM разработать модели зрелости для, например, Enterprise Architecture, ИТ-сервисов, Разработки и управления требованиями, ... на выходе получить фреймворк и инструментарий для проведения assesment-а организаций (в том же Excel). Т.е. по некоему опроснику мощному -- в зависимости от ответов получать уровень зрелости компании. Другой вопрос, что подобные работы существуют в рамках отдельных консалтинговых компаний и институтов.
  

Эд, не надо для твоих аспирантов брать тему метрик и CMMI для разработки и управления требованиями . Оставь ее мне!!!

385

Конференции Семинары и Тренинги / Re: [Семинар] Техники Вариантов Использования, 11 октября, Спб

« : 13 Октября 2008, 09:34:25 »

Друзья, всем кто пришел на семинар ОГРОМНОЕ СПАСИБО. Без Вас бы он не состоялся. Ваши пожелания обязательно учтем на следующих семинарах 

386

Конференции Семинары и Тренинги / Re: [Семинар] Техники Вариантов Использования, 11 октября, Спб

« : 06 Октября 2008, 10:11:33 »

А план моего выступления примерно такой  :

 1. Введение в паттерны ВИ:
     Классификация паттернов
     Преимущества и риски применения паттернов
 2. Знакомство с паттернами (название и описание основных паттернов)
 3. Подробное рассмотрение паттернов (назначение, разбор примера)
     * "Пакеты ВИ"
     * "Выполнить транзацию"
     * "CRUD"
     * "Многочисленные акторы"

     

387

Примеры / Re: Начинаю изучать UML, по критикуйте мою первую UseCase диаграмму

« : 06 Октября 2008, 09:45:45 »

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

mifody, а что вы имеете ввиду, когда говорите "запрос"?. Кто этот запрос инициирует, как он начинает работать? Если, запрос является следствием отработки скрипта, то где выполняется этот скрипт, в какой среде, кто его запускает? Хотелось бы услышать ответы на эти вопросы, может быть тогда удасться Вам помочь. То, что описано сейчас на диаграмме похоже на общий алгоритм обработки в системе любого запроса, так сказать "универсальный алгоритм".
Основная идея use case - показать как с помошью системы актор добивается своей цели в виде последовательность запросов актора и откликов (ответов) системы. В основном ВИ пишется как черный ящик, например, Актор выполняет в системе какое-то действие (white box - инициирует запрос), система в ответ на действие актора, выполняет определенные операции (white box - обработка запроса и возврат результатов)

Часто, на практике компонент системы можно представить ввиде актора, по отношению к другому компоненту.
Например, если система многоуровневая, то например уровень представления и бизнес логики можно разделить, и компонент "обработчик http запросов" на web-сервере может быть представлен как актор по отношению к компоненту, выполяющему запрос на сервере приложений, те по сути используется facade

388

Теория моделирования и нотации / Re: К какому классу диаграмм отнести эту?

« : 02 Октября 2008, 17:54:06 »

+1
Дерево принятия решений

389

Для всех / Re: Код vs модели

« : 02 Октября 2008, 12:20:00 »

IMHO, то что представлено в коде...

390

Для всех / Re: Код vs модели

« : 02 Октября 2008, 10:39:47 »

По-моему, очень странно нарисована картинка, причем на очень низком уровне абстрации. На сколько я понял ее суть, берем счет (объект), достаем из него баланс счета (атрибут) складываем баланс с суммой (объект) и снова записывает новое значение баланса на счет.
По сути обычная схема пополнения счета. Удобнее это описать сиквенсом, или просто словами.