1666

Идеи и мозговой штурм / Re: Повышение производительности аналитика

« : 31 Июля 2011, 21:08:33 »

3. Я ничего не ограничивал. В метамодели UML UC - это классификатор. Абстрактный классификатор не имеет собственных экземпляров. UCI и UCE не имеют собственных экземпляров: они выполняют экземпляры основного UC.

Почему выполняют? Встраиваются! Я все равно не понимаю в чем абстрактность? Пусть есть функция sin(x) (это примерно сильно утрирован), но почему я как актор не могу использовать функцию напрямую, если она к примеру используется другим ВИ как включаемая функциональность?

4. Наверное, Коберн ввел понятие первичного Actor (цель которого реализует UC). Взаимодействие первичного Actor создает экземпляр UC. С UC могут взаимодействовать другие Actor, но они "помогают" (пример - клиент банкомата и процессинг). Т.о., ограничение относится только к первичному Actor. Вторичные могут "помогать", взаимодействуя с экземпляром основного UC в границах основного UC, UCI или UCE.

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

2. ДД, на мой взгляд, удобнее и прагматичнее, т.к. просто нагляднее, особенно, если процесс достаточно "запутанный" (много логики). RUP вообще возможность использования ДП для этих целей не рассматривает!

Как Вы считаете обычному заказчику проще понять диаграмму или текст?

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

Мы о каких реализациях вариантов использования сейчас говорим? О бизнес-вариантах? Они не являются частью UML, хотя, вероятно, придуманы в RUP. Если о вариантах системного уровня, то правильно ли будет говорить, что сложность их проще передать через ДД. ВИ есть сборник сценариев, совокупность сценариев передаст нужную степень сложности в простой форме. Другой разговор, если есть формальные правила и способы прямой трансляции ДД в поведенческие инструменты программной реализации? То я за. Но мне думается ДД также далека от ООП, как обычная блок-схема.
Т.е. я не против рисовать или не рисовать - рисуй, пиши, делай все, что тебе кажется правильным и верным. Но если это определяется как правило, оно должно быть обоснованным

    - Я использую инструменты, которые позволяют рисовать и генерировать текст из модели в нужной мне форме

Т.е. причина в этом?

    - Я могу использовать MDA, в частности, преобразовать BUC в пакет функциональной области в модели UC, автоматизируемые действия ДД - в UC, а соответствующий раздел - в Actor (и т.п.) 

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

Наверное, теоретически возможно преобразовать описание UC на естественном языке в модель анализа. Трудно придется! А для моделей это не проблема, есть множество примеров. Если средство моделирования поддерживает MDA, в нем д.б. инструментарий для создания преобразований (так написано на сайте OMG).

Я возможно когда-то где-то что-то упустил, но не могли бы Вы указать литературу, ссылки, которые демонстрируют использования UCs в технологиях MDA.

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

Ну, тогда это уже будет не MDA, а что-то синтетическое.

По жизни. Система должна отвечать требованиям. Т.о., модель требований первична. Если требования изменились, нет другого способа довести изменения до исполнителей, кроме, как изменить модель (если документы требований генерятся из модели). Или изменить документы. Но если изменить (написать) документы проще, чем изменить модель, на фига она вообще, эта модель?

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

Конечно, никаких замеров я не делал. Но результаты видел. Я уже говорил, что я иногда зарабатываю на хлеб тем, что помогаю внедрять технологию RUP. Я прихожу не с пустыми руками. И вижу производительность до и после.

А может Вы просто научили людей работать?

Любой специалист накапливает опыт. Свой и чужой (даже самые крутые, если умные). Те примеры, которые я представляю, не предназначены для непосредственного использования.

Это я понимаю.

Думаю, Ваши инструменты позволяют использовать представленные идеи и примеры, такие, как моделирование с использованием строительных блоков, настройка шаблонов для генерации презентационных документов и т.п. Если не позволяют, хочу задать вопрос: "Неужели Вы так богаты, что можете себе позволить покупать (использовать) дешевые инструменты?"

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

Спасибо, Эдуард, за содержательные вопросы.

"Этот рад помочь" (c)

1667

Идеи и мозговой штурм / Re: Повышение производительности аналитика

« : 31 Июля 2011, 12:18:50 »

Читал первую статью: Повышение производительности аналитика 01 и смотрел приложение.

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

Есть вопросы:
1. Почему считается, что способ рисования сценариев ВИ (т.е. реализации ВИ) в виде ДД лучше, чем текст?
2. Почему считается, что реализации ВИ через ДД удобнее и прагматичнее, чем реализации сценариев чере диаграммы сценариев = ДП?
3. Почему ограничивается, что любой include и extend ВИ - есть абстрактный ВИ?
4. Почему ограничивается, запрещается наличии ассоциации между actor и include / extend ВИ ?

Вы пишите:

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

А скажите:
5. Каким образом диаграммы активностей помогают построить MDA?

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

6. Имеются ли какие-либо оценки эффективности, полезности на создание и поддержание модели или ее фрагмента отнесенного к трудозатратам на использование специалиста? Сколько вообще нужно специалистов?

7. А также есть ли какие-то оценки именно повышения производительности работы аналитика? И что понимается под производительностью аналитика?

Спасибо

1668

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

« : 31 Июля 2011, 11:24:28 »

А Вы уверены, что говорите о ГОСТ 34.602?

Я просто не знаю в нем таких пунктов как 4.1 и 4.2.

4.1 Требования к информационной системе в целом
указываю подсистемы, их назначение и т.д

=
2.6.1. В подразделе «Требования к системе в целом» указывают:

4.2 Требования к функциям (задачам), выполняемым системой

=
2.6.2. В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:

А где в ТЗ добавлять основные сценарии к ВИ? Или нужно в пункте 4.2 писать как раз эти сценарии к функциям?

ГОСТ 34, конечно, не заточен под использование ВИ. Но ВИ могут быть описаны по-разному. В ГОСТе вполне уместно будет дать краткое описание ВИ (свободный или сжатый формат). А вот подробное описание вынести за пределы ТЗ в отдельный документ.
Все-таки у ВИ двойственная роль: с одной стороны - это действительно часть функциональных требований, с другой некоторое первичное отвлеченное от технологий реализаций решение.

1669

Идеи и мозговой штурм / Re: Повышение производительности аналитика

« : 30 Июля 2011, 19:15:14 »

Спасибо, Леонид Борисович, почитаем. Хотя я и не профессиональный аналитик

1670

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

« : 29 Июля 2011, 21:06:58 »

квест в чем

1671

Идеи и мозговой штурм / Re: Что влияет на качество документов Аналитика?

« : 29 Июля 2011, 20:03:04 »

Это все какие-то эскимосы тебе попадались. Это точно в Москве было;)?

1672

Примеры / Re: Описание поведения GUI средствами UML

« : 29 Июля 2011, 09:29:18 »

Попробуйте посмотреть в сторону диаграммы последовательности. По моему очень удобно и наглядно можно описать поведение GUI. Личных примеров привести не могу, т.к. не делаю, но чувствую что уже пора начинать

Что-то у меня есть некоторое сомнение. Раз Вы чувствует, что пришло время, может и сделаете пример ДП хотя бы для примера топикстартера?

1673

Варианты Использования (Use Case) / Re: Пример use case - дайте feedback

« : 28 Июля 2011, 21:31:02 »

Понятно, или все в отпуске, или жарко, или не покупаетесь на провокацию

Не реально. На Use Case Professionals я опубликовал ответ. На всякий случай повторю часть комментариев

Hi, gays. Tell me exactly is the UC good enough?

 UC 01: Make the order
 ID: 01
 Description:
 The employee made ​​the order, received a receipt with the bar code
 Main actor:
 The employee
 Secondary actors:
 no
 Preconditions:
 1. The employee is logged in the system.
 2. The system provided a menu to place your order.
 The main flow:
 1. While the employee chooses the desired dish
 2. The system displays the dish and the price in the order list, counting the total cost of the order
 3. The employee confirms the order
 4. The system saves the order and prints a receipt
 Postconditions:
 1. The system displays a screen with the original menu of dishes
 2. The system ends the session
 3. Order is stored in a "proposed" state
 Alternative Flows:
 1/ There is your outstanding order
 2/ Reorder during the day
 3/ Remove the chosen dish
 4/ Change the number of meals
 5/ The chosen dish is over
 6/ Cancel the order

Т.е. я взял исходный текст ВИ пропустил его через гугл-переводчик и чуть подправив опубликовал

а вот ответ

Great example, Edward, Perhaps we can pitch in and critique Edward's example and eventually come up with a "good" use case. Rather than suggest suggestions, let's point out issues, and once we agree on the issues, then Edward might offer ways to correct the issues.

 Allow me to begin:

 Often when I work with people who have a first language other than English, we have to be really careful to make sure that the intentions of the author and the understanding of the reader is consistent. Some of my questions are about the vocabulary used, which, while grammatically correct, may be inconsistently understood.

 The title "Make an Order" is too vague; the word "make" could imply constructing, assembling, or placing an order.

 The description didn't tell me much. It wasn't until I read the alternative flows that I figured out that the order has something to do with ordering food.

 Why is the actor an "employee"? That's a pretty vague term. What is the role? Does the system care that only an employee can order food?

 Precondition 2: At first I thought that the word "menu" constrains the design of the system, but the word "menu" in a food ordering system might be exactly right.

 What is the state of the "order" prior to the start of the use case?

 Main Flow:

 1. Why is the word "while" in the first sentence? Why did you use the word "dish"?
 2. "counting" implies incrementing the number of items ordered. Did you mean "calculating", to add the cost of the dish to the current order giving a new total cost?
 3. Could the employee order more than one item?
 4. This is 2 requirements: Do they have to be done in this order? Does it have to save it, or could it transmit it somewhere else?

 Alt flows: Do these have the same preconditions as the main flow?

 Post conditions: I still don't understand the context of this use case: an employee at a cash register at McDonalds? Taking orders for room service in hotel? A restaurant? Over the phone? Could the diner or meal preparer order a dish?

 Re-ordering during the day....not sure what "re-order" implies?

 Thanks Edward, this was a good start!

Правда, много интересного?

1674

Примеры / Re: Пример описания поведения UI. Прошу мнений

« : 28 Июля 2011, 16:53:02 »

Не могу с вами согласиться.

2.6.1. В подразделе «Требования к системе в целом» указывают:
- дополнительные требования.
2.6.1.14. В дополнительные требования включают:
4) специальные требования по усмотрению разработчика или заказчика системы.

вот где-то здесь Вы можете описать требовнаия к пользовательскому интерфейсу, но самые общие - обратите внимание

детальные же требования, если уж излагать то, в области
2.6.3. В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.
2.6.3.2. Для информационного обеспечения системы приводят требования:
6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

1675

Примеры / Re: Пример описания поведения UI. Прошу мнений

« : 28 Июля 2011, 15:50:51 »

Requirement добавляются не в другом месте, а на той же диаграмме, попадают в дерево объектов, и будут присутствовать в сгенеренном по модели ТЗ.

Подождите, а разве это будет ТЗ? Это, пожалуй, уже постановка задачи с учетом вопросов реализации

1676

Примеры / Re: Пример описания поведения UI. Прошу мнений

« : 28 Июля 2011, 15:20:17 »

Это можно указать в Requirement, которые будут связаны с объектами диаграммы.

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

1677

Примеры / Re: Пример описания поведения UI. Прошу мнений

« : 28 Июля 2011, 15:05:33 »

 В целом их масса. ДД в данном случае - это алгоритм, алгоритм последовательный, хотя и допускающий распараллеливание.

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

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

1678

Примеры / Re: Описание поведения GUI средствами UML

« : 28 Июля 2011, 11:36:40 »

Все таки диаграммы состояний более подходят для этого.
То что ДД и ДС путают - нормально, ДД в UML 1.x подмножество ДС, но картина именилась в UML 2.0
Сейчас ДД имеют семантику сетей Петри, это ближе к системам массового обслуживания.

ДС ориентировано на объект, пользовательский ГУИ - формы и элементы - это объекты.

1679

Обсуждение статей / Re: Круглый стол «Знание UML как фактор влияния на карьеру и работу с заказчиком», Мск, 17 августа

« : 27 Июля 2011, 14:26:56 »

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

1680

Варианты Использования (Use Case) / Пример use case - дайте feedback

« : 27 Июля 2011, 13:15:07 »

Перед Вами образец варианта использования системы заказа обеда в кафетерии компании. Некоторое обсуждение происходило в теме: Какое решение оптимальнее.

Общий контекст - система по учету заказов блюд только сотрудниками компании в столовой компании в счет удержания из заработной платы

ВИ 01: Сделать заказ блюд (Заказать блюда для обеда, Заказать блюда)
ID: 1
Краткое описание:
   Сотрудник выбирает блюда из меню, меняет количество порций, если необходимо, подтверждает свой выбор по завершению заказа и получает чек со штрих-кодом
Основное действующее лицо:
   Сотрудник
Второстепенные действующие лица:
   Нет
Предусловия:
   1. Сотрудник авторизовался в системе.
    2. Система предоставила меню для размещения заказа.
Основной поток:
1. Пока сотрудник указывает желаемое блюдо
2. Система отображает блюдо, количество порций и цену в списке заказа, подсчитывая общую стоимость заказа
3. Сотрудник подтверждает заказ
4. Система сохраняет заказ и печатает чек
Постусловия:
   1. Система отображает экран с исходным меню блюд
    2. Система завершает сеанс работы с сотрудником
   3. Заказ сохранен в состоянии "предложен"
Альтернативные потоки:
Есть невыполненный заказ (у сотрудника имеется заказа в состоянии "предложен") - этот поток может возникнуть, если сотруднику нужно изменить ранее созданный заказа  до его получения
Повторный заказ в течение дня - если сотрудник хочет покушать второй раз, то он может использовать для этого блюда в ранее созданном заказе
Выбрано неверное блюдо - в ходе формирования заказа (выбора блюд), если сотрудник ошибся с этим выбором, то он может исправить это - удалив ошибочно выбранное блюдо
Изменить количество порций блюда - если требуется увеличить или уменьшить количество порций уже выбранных (отмеченных) блюд
Заказанное блюдо закончилось - если в процессе формирование заказа какое-то блюдо закончилось, то система автоматически убирает его с извещением
Отмена заказа - в любой момент до подтверждения заказа, сотрудник может отменить заказ

Альтернативные потоки не раскрыты, кроме одного

Альтернативный поток: Сделать заказ. Есть невыполненный заказ
ID: 1.1
Краткое описание:
   У сотрудника есть невыполненный заказ, который он хочет изменить
Основное действующее лицо:
   Сотрудник
Второстепенные действующие лица:
   Нет
Предусловия:
   1. Сотрудник авторизовался в системе.
    2. У сотрудника есть невыполненный заказ.
   3. Система предоставила меню для изменения заказа.   
Альтернативный поток:
1. Система отображает последний невыполненный заказ
2. Возврат к пункту 1 основного потока
Постусловия:
   нет