436

Варианты Использования (Use Case) / Re: Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ

« : 26 Марта 2008, 01:40:42 »

Предлагаю продолжить дискуссию, п.ч. о чем я говорю, многим кажется спорным.
Прикладываю свой доклад на РИТ для этого.

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

437

Проектирование / Re: Развитие навыков ОО проектирования

« : 15 Марта 2008, 23:20:05 »

1. Начните с UML (если владеете - подтяните слабые места, особенно диаграммы компонентов, классов и последовательности)
  - Фаулер (http://www.ozon.ru/context/detail/id/2260613/)
  - Леоненков (http://www.ozon.ru/context/detail/id/3118206/)
  - Three amigos (http://www.ozon.ru/context/detail/id/3039980/)
  - Three amigos (http://www.ozon.ru/context/detail/id/2473023/)
2. Почитайте книжки об "общем" процессе разработки с исп. UML.
  - Three amigos (http://www.ozon.ru/context/detail/id/1108043/)
  - Ларман (http://www.ozon.ru/context/detail/id/3105480/)
2. Далее - паттерны проектирования. Для начала прочитайте классику
  - GoF   (http://www.ozon.ru/context/detail/id/2457392/).
  - Фаулер (http://www.ozon.ru/context/detail/id/1616782/)
3. Далее, если будет желание , можно (и нужно) почитать книги по специализированным паттернам, например Core J2EE Patterns и др.
4. В дополнение ко всему (это уже больше для архитекторов) неплохо, наверное посмотреть методологии (Zachman,  TOGAF, MODAF).

ИМХО, для проектирования необходимо знать весь процесс разработки от ВИ до тестирования и ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ

438

Обучение / Re: Обучение по курсу IBM Rational системный аналитик

« : 18 Февраля 2008, 01:15:04 »

Для людей, желающих освоить IBM Rational RequisitePro есть хорошая книжка, правда на английском.
В этой книге все расписано подробно: что нужно делать, как нужно делать и т.д.
Сам, прослушав курсы по RUP и RequisitePro после почти полугодовой работы с ними (курсы не по программе IBM), могу сказать, что ничего нового для себя оттуда не вынес. В основном это основы UML и работа с инструментами.
Если не хочется тратить деньги, а действительно получить знания и навыки, а не "бумажку" прочитайте книжку - для новичков самое то.
Что вы будете знать:
  - Основы процесса управления требованиями (RUP)
  - Навыки работы с IBM Rational RequisitePro
  - и много всего полезного

Ссылка на книгу в электронной библиотеке pdfchm.com:
http://www.isbnonline.com/Requirements-Management-Using-IBM-R-Rational-R-RequisitePro-R/book/9780321383006/

PS: Для скачивания книги необходимо зарегистрироваться

439

Примеры / Re: Описание требований к CRM

« : 16 Февраля 2008, 23:09:13 »

Александр, по ДСВИ есть несколько вопросов.

1) Актеры, отличные от Пользователя, инициируют ВИ "Войти в Систему"? Т.е. необходимо ли Секретарю, РМ и др. аутентифицироваться и авторизироваться в системе? Или они являются "потомками" актера Пользователь, но это не указано на диаграмме?
2) Подразумевается ли дальнейшее расширение ДСВИ? Если нет, тогда не совсем ясно как управлять, например, справочником, учетными записями и др? Возможно применение паттерна CRUD, который был описан Эдуардом http://www.uml2.ru/forum/index.php?topic=628.0 ?
3) Актеры РП и Пользователь оба инициируют ВИ "Назначить задание"? Другими словами и РП и Пользователь могут назначать задания кому-то (не понятно кому) или РП назначает задания пользователю (тогда необходимо изобразить направленную ассоциацию на пользователя)?

440

Варианты Использования (Use Case) / Re: Уйти от ВИ и перейти к иерархии Пользовательских Требований

« : 10 Февраля 2008, 16:11:50 »

Наткнулся в интернете на книжку по управлению требованиями
(http://www.ibmpressbooks.com/bookstore/product.asp?isbn=0321383001).
Так как книга новая, я не смог ее найти в электронном виде (может плохо искал .
Дак вот, автор предлагает добавить в пирамиде иерархии требований, ниже ВИ, еще и сценарии. Это конечно, обычный РУПовский подход, но мне показалось, что можно прикрутить его к текущей ситуации, т.е. под вариантом использования понимать, например, управление справочником, а под сценариями - создание, удаление, копирование и др.
Вобщем почитайте, если интересно (см. аттач)

441

Варианты Использования (Use Case) / Re: Уйти от ВИ и перейти к иерархии Пользовательских Требований

« : 09 Февраля 2008, 23:23:57 »

Мы же предполагаем опираться на эти ПТ как на одни из основных требований на данный момент и в будущем, и если же надо будет их детализировать, то будет это делать с помощью функц. треб. (ФТ).

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

Александр, действительно хорошая идея.
Проводя аналогию с тем, что делаю в своем проекте, прихожу к выводу, что мы с Вами столкнулись с одной и той же проблемой. А именно, как описывать пользовательские требования для "инфраструктурных" систем, т.е. систем которые не несут как таковую бизнес-логику для пользователя, а предоставляют некоторый функционал, который пользователь будет использовать для построения необходимой для него логики.
Например, из различных функций (создать каталог, добавить файл, послать сообщение) будет выстраиваться некий процесс, который уже имеет смысл для пользователя, т.е. ЦЕЛЬ.

Тогда получается, что в данном случае от варианта использования остается лишь каркас, для удобного описания и представления этих так называемых ПТ?
У нас следующий подход:
1. Мы описываем функционал (можно наверное назвать его ПТ) используя ДВИ (см. файл)
2. Далее каждую функцию описываем в виде сценария и/или диаграммы деятельности (ДД)
3. Анализируя, получаем классы анализа
4. Действия из ДД дробятся на более детальные функции системы (мы называем их системными функциями)
5. Создаем диаграммы последовательности используя полученные системные функции
6. Распределяем системные функции по компонентам системной архитектуры (трехслойная по Фаулеру). Многие системные функции как у нас получилось используются в нескольких ПТ.
Если я правильно понял, Александр, Вы предлагаете именно такой подход, только называя это другими именами.
Мы тоже называем их не ВИ, а функциональными узлами (operational nodes), т.к. используем MODAF.

Эдуард, спасибо за подсказку. Теперь понимаю свою ошибку.

442

Варианты Использования (Use Case) / Re: Уйти от ВИ и перейти к иерархии Пользовательских Требований

« : 09 Февраля 2008, 15:46:34 »

Перечисленные тобой функции - совершенно не ВИ, а лишь части ВИ. Например ВИ : Управления справочниками - типичный CRUD ВИ и ничего более. Есть даже целый проработанный шаблон где указывается пользователь и два ВИ: CRUD и X information

Эдуард, а как же описывать такой вариант использования?
Например, есть вариант использование "Управление справочниками", который, по вашему, включает в себя функции (шаги) создание, удаление, редактирование справочника. Это очень громоздкий ВИ с кучей альтернативных потоков. Имхо, каждая операция CRUD -  это отдельные ВИ, потому, что она содержит в себе различные действия, вызываются различные формы пользовательского интерфейса.

Может я и не прав, но в проекте, в котором я участвую,  ситуация аналогична той, что у Александра.
Система (аналог ECM) не имеет как такового пользователя (отдельного актора), а имеются лишь наборы прав (роли), которые позволяют пользователю использовать различные услуги системы.
Получается, что основные варианты использования такой системы это управление каталогами, управление таксономией, управление контентом, управление правами пользователя и др. Мы же сделала описанное выше пакетами ВИ, каждый из которых состоит из ВИ создать, удалить, отредактировать и т.д. Получается такой подход не правильный?

443

Проектирование / Re: Проектирование по ICONIX

« : 08 Февраля 2008, 15:52:53 »

2. строим человечк(ов)
3. рисуем граничный класс (или несколько)
4. рисуем сущностный класс (или несколько) - все согласно описанию
5. разбираем каждое предложение, извлекаем от туда глагольные фразы, смотрим на что и куда они направлены, каждую такую глагольную фразу(шаг, операцию, функцию) превращаем в управляющий класс
6. соединяем все это хозяйство по правилу noun-verb-noun или verb-verb
далее строим секвенцию
1. рисуем актера
2. рисуем формы(граничные объекты)
3. рисуем сущности
4. класс контроллер который мы определеи на диаграмме анализа превращается в сообщение в данном случае от одного класса к другому и соотвественно становится методом класса на который направлен
вот такую вещь я вычитал и книжки

Странно. У меня было совсем другое представление данного процесса.
Мы создаем диаграммы деятельности для ВИ (черный ящик), далее анализируем и получаем классы анализа (диаграмма классов). Затем действия из ДД преносим на диаграмму последовательности в виде методов. В результате получаем ВИ->ДК+ДД->ДП
На примере RSA (не знаю как в EA) могу сказать, что из collaboration получается sequience одним шелчком мыши (и наоборот). Причем, если взять вашу картинку, то мне на сиквенсе RSA нарисовал бы актора, баундари, контрол и энтити и все сообщения, передаваемые от класса к классу.
По схеме Розенберга получается, что все операции (методы) будут принадлежать либо сущностям, либо граничным классам.
Тогда как же быть, например, с Session и Entity Bean из EJB (Java)? На сколько я понимаю, в данном случае JSP (servlets) / Session Bean / Entity Bean образуют самый настоящий MVC (вернее V/ C / M).

За книгу спасибо, но прежде того, как начну скачивать - вопрос, у Вас это какая книга? Розенберг и Скотт(98) или Розенберг и Стевенс(07)?

Эдуард, книжка следующая
Addison Wesley -2001- Applying Use Case Driven Object Modeling With Uml – Rosenberg\Scott

PS Эдуард, если Вам не сложно, может выслать мне книгу Розенберга, Стивенса за 2007. Или дать ссылку на источник откуда ее можно скачать.

444

Проектирование / Re: Проектирование по ICONIX

« : 08 Февраля 2008, 11:08:16 »

В частности при реализации вариантов использования ICONIX предлагает создание диаграммы робастности (устойчивости, пригодности, надежности) по сути представляющая собой диаграмму классов, участвующих в реализации ВИ и классифицирующихся на: граничный класс (форма или интерфейс взаимодействия), управляющий класс (обычно имеющий название варианта использования) и классов-сущностей. В целом классический MVC.

Эдуард, robustness diagram в ICOMIX это то же самое что analysis diagram в RUP. Может стоит называть ее диаграмма "грубости", например. Потому, что ИМХО она показывает как раз грубые, аналитические классы и не имеет отношения к устойчивости, пригодности, надежности.

Вот интересная книжка по ICONIX. Может найдете что-нибудь полезное.

Фраза из книги

Control objects (controllers) embody much of the application logic. They serve as the connecting tissue between the users and the stored data. This is where you capture your frequently changing business rules and policies, with the idea that you can localize changes to these objects without disrupting your user interface or your database schema down the line. Once in a while (perhaps 20 percent of the time), controllers are “real objects” in a design, but most of the time, controllers serve as placeholders to make sure that you don’t forget any functionality and system behavior required by your use cases.

445

Термины и Определения / Re: Термин: Business case

« : 29 Января 2008, 22:52:43 »

Спасибо! 

446

Термины и Определения / Термин: Business case

« : 28 Января 2008, 23:50:19 »

Всем привет!
Читая BABOK, столкнулся с термином Business Case.
Хотелось бы узнать перевод этого словосочетания на русский язык.
В инете нарыл только объяснения термина на английском. Вот одно из них:
http://en.wikipedia.org/wiki/Business_case
Подскажите, что это за документ такой и его аналоги в отечественном бизнесе.

447

Проектирование / Re: Layer vs. Tier

« : 23 Января 2008, 23:17:33 »

Кажется, еще больше запутали ситуацию.

Точно

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

К сожалению, теперь я там почти не появляюсь, так как пишу диссертацию и работаю.

Я думаю действительно, авторы что-то напутали (хотя, а судьи кто ). Данные определения помоему взяты из Sun Certified Enterprise Architect for J2EE.

Как мне объяснил один знакомый архитектор:
Уровень (tier) - это некий физический элемент (абстракция), причем каждый уровень может располагаться как на отдельном компьютере, так и на нескольких. Например, сервер приложений размещен на 2 серверах (компах) и тд. Также можно все уровни разместить на одном компе, но это обычно бессмысленно.

Слой - логическое разделение. Локализовать слой на отдельный уровень не возможно.  Обычно слой может быть размыт на несколько уровней. Например, бизнес-логика частично может быть реализована и на клиенте и на сервере приложений и на уровне хранилища.

Слои обычно представляются как пакеты с классами (редко компонентами).
Уровни в виде подсистем и компонентов

448

Проектирование / Re: Layer vs. Tier

« : 22 Января 2008, 09:05:54 »

Спасибо!
Как раз для понимания этих терминов я и пользовался Фаулером, вернее при проектировании - это была единственная книга на которую ссылались. Так как Фаулер четко не дал определения layer и tier, отсюда и пошло мое не осознавание данных концепций.

Эдуард, тогда принимая во внимание то, что вы написали и то, что я написал можно сделать вывод, что я все понимаю правильно?

449

Проектирование / Layer vs. Tier

« : 22 Января 2008, 02:26:31 »

Привет Всем!
Коллеги, помогите разобраться!
Я немного запутался в понятиях layer (слой) и tier (уровень) в представлении системной архитектуры.
Расскажу свое понимание этих терминов, а вы меня исправьте или дополните.
Оба подхода, как "расслоение" (layering) так и разделение по уровням (tiers) используется для декомпозиции системной архитектуры, но, как я понял, с разных точек зрения.
Слои применяются для группировки компонентов по некоторой функциональности (представление, бизнес-логика, доступ к данным).
Уровни используются при физической реализации (клиент - сервер - хранилище).
Получается, что часть слоя представления, например, может располагаться как на клиенте, так и на сервере.
1. Если мы реализуем "толстого" клиента, то представление на клиенте, если "тонкого", то на сервере.
2. Если это desktop приложение, то все слои реализованы на клиенте.
3. Часть логики слоя "доступ к данным" может быть реализована на сервере (например, Hibernate) или в хранилище (СУБД).

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

+ Хотелось бы услышать какие диаграммы UML используются для представления данных концепций. Мне кажется, что это Component Diagram, Composite Structure Diagram, Deployment Diagram.

450

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

« : 13 Декабря 2007, 23:44:39 »

Всем привет!
Коллеги, хочу с Вами посоветоваться.
А что если для проверки качества требований, описанных в техническом задании применить следующую модель:

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

2. Для каждого типа атрибута задать некоторые коэффициенты (вербальные или числовые).
   Например. Атрибут "возможность реализации" имеет значения "возможно реализовать",
   "не возможно реализовать", "возможно, но не полностью" и тд.

3. Человек, согласующий ТЗ, для каждого требования выбирает значение атрибутов качества
    и добавляет комментарий (замечание, предложение и др.).
    Разные люди (заказчик, системный архитектор) могут выставлять значения для разных атрибутов.

4. После того, как все атрибуты описаны, с помощью допустим алгоритмов нечеткой логики
    или других механизмов обработать результаты полученных данных и для каждого требования
    определить некий показатель качества. Например, требование UC234Регистрация
    пользователя имеет показатель качества "70%" и выводы почему + комментарии.

5. Аналитик может за меньшее время оценить результаты и сделать выводы и если нужно внести
    изменения.

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

Пожалуйста, Ваша критика и замечания.