196

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 12:17:26 »

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

Выделил бы, конечно. Но спецификация ВИ - это же не диаграмма ВИ.

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

Что касается статьи по ссылке, то ВИ "Использовать банкомат" и "Выполнить одну транзакцию" кажутся мне искусственными. Я не вижу для них практического применения ни со стороны целей пользователя, ни со стороны программной архитектуры.

В статье сказано

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

Я не понимаю, зачем это вообще нужно выражать графически на диаграмме, которая не описывает поведения. Для этого есть другие диаграммы.

Но должен оговориться: если я чего-то не понимаю, это не означает, что это что-то неправильно. Если у кого-то include и extend эффективно используются, то это прекрасно.

В данном случае Эд говорит о подготовке студентов. Они, скорее всего, ещё не понимают целей, для которых может использоваться обобщение, и поэтому у них будут трудности с пониманием include и extend (и есть, судя по вопросам в этом форуме).

197

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 29 Сентября 2014, 23:46:49 »

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

А как можно дублировать поведение на диаграмме ВИ?

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

Можно найти уровень чуть повыше - дублирование механизмов реализации. Например, в АБС можно описать бухгалтерскую проводку четырьмя разными способами (что особенно смешно, так получилось в погоне за универсальностью каждого из четырёх механизмов). Это четыре разных ВИ. Тогда в ВИ более высокого уровня (настроить банковскую операцию) имеет смысл сделать include для того способа, который является предпочтительным.


Но вернёмся к банкомату. Если мы описываем цели пользователей по отношению к банкомату, то зачем нам избегать дублирования? Пользователю всё равно, как будет реализовано достижение этих целей. А целей «ввести ПИН» или «подтвердить операцию» по отношению к банкомату у него нет.

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

Все примеры диаграмм ВИ с использованием include и extend, которые я видел, рисовались со смешением этих двух уровней, поэтому они только затрудняли понимание.

198

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 26 Сентября 2014, 23:43:48 »

Еще тогда предложу к обсуждению такой экземпляр

Если роли Ученик и Родитель ничем не различаются, то зачем делать из одной роли три?
(На самом деле они, наверное, различаются, и диаграмма нужна как раз для того, чтобы показать это различие).

И снова "посмотреть профиль ученика" imho совершенно ненужный юзкейс. Да ещё сбивающий с толку (обычно под профилем понимаются настройки).

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

Гриша, ты считаешь, что этого достаточно для аргументирования проблемы?

Нет, это же было только вступление.

Я могу признать возможную пользу отношений include и extend разве что на довольно низком уровне проектирования - когда на диаграмме ВИ показываются не цели пользователей, а сценарии из уже продуманного множества, подготовленные к реализации или отчасти реализованные. Например, когда разрабатываемые ВИ должны надстраиваться над уже реализованными частями системы (хорошо это представляю, например, применительно к нашей АБС).

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

199

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 26 Сентября 2014, 14:58:01 »

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

В данном случае UC "Оформить журнал" просто не нужен. Ощущение такое, что вместо диаграммы ВИ автор изобразил структуру меню.

200

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 19 Сентября 2014, 19:03:33 »

Я ни в первом процессе, ни во втором не могу понять, чем же нужно управлять. Они же автоматические, насколько я понимаю.

201

Примеры / Re: Use case диаграмма снятия денег в банкомате

« : 17 Сентября 2014, 18:47:33 »

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

В исходном посте нет такой задачи. Задача, как я понимаю, описана в названии темы: "Use case диаграмма снятия денег в банкомате".
Значит, снятие денег в банкомате - это и есть единственный ВИ, обозначенный в задаче.

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

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

202

Примеры / Re: Use case диаграмма снятия денег в банкомате

« : 17 Сентября 2014, 12:05:44 »

Я вижу примерно такой вариант.

203

Примеры / Re: UML диаграммы по BPMN

« : 10 Сентября 2014, 22:44:23 »

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


Совершенно непонятно, что такое план проекта и зачем он нужен. Также непонятно, как связаны "товар" и "выполнение работ". Организация продаёт товары или оказывает какие-то услуги? Или диаграммы вообще относятся к разным организациям? По диаграмме восстановить это невозможно, конечно. У вас на входе только эти диаграммы, или есть какая-то словесная постановка задачи с пояснениями?

204

Работа / Re: Изменения на рынке труда

« : 06 Августа 2014, 19:01:42 »

Вот обзор (правда, довольно короткий) изменений в IT за 10 лет:
http://hh.ru/article/14828

Там есть и аналитики.

Вот здесь свежий обзор по отраслям в сравнении с прошлым годом (в IT - падение на 12%):
http://hh.ru/article/15172

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

205

Работа / Re: Изменения на рынке труда

« : 06 Августа 2014, 13:07:12 »

Типовое распределение вакансий, наверное, можно воссоздать из отчётов headhunter:
http://hh.ru/article/30

Предвижу резкое ухудшение экономической ситуации осенью этого года. Количество вакансий сократится, количество соискателей увеличится.

206

Конференции Семинары и Тренинги / Re: Конференция Разработка ПО/CEE-SECR 2014 приглашает докладчиков

« : 28 Мая 2014, 23:05:00 »

Алина, а чего у вас в тематике который год есть архитектура, тестирование и интерфейсы, но нет системного анализа, бизнес-анализа и разработки требований?

Потому что требования - лишнее звено в разработке.

207

Теория моделирования и нотации / Re: Кратность полюсов ассоциации. Различие 1--1 и 1--0..1

« : 23 Мая 2014, 00:33:23 »

Как тогда можно создать объект одного из классов если они не могут "жить" друг без друга?

Я, как бывший программист C++, всегда понимал это буквально.

При отношении 1--1 объект второго класса создаётся в конструкторе первого. Или объявлен как его атрибут.

При отношении 1--0..1 объект второго класса может создаваться в runtime, когда в нём возникает необходимость. А может и не создаваться. Обычно первый класс в этом случае содержит указатель на объект второго.

208

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 19 Мая 2014, 16:44:27 »

Интересно было бы посмотреть на основной сценарий юзкейса "Сканировать систему". И на альтернативные тоже.

209

Работа / Re: Поиск работы системным аналитиком в Европе (Британия, Нидерланды, Германия)

« : 16 Мая 2014, 17:52:16 »

Мужчинам вообще плохо понятны и совершенно не важны такие нюансы, т.к. отношение к коммуникации совершенно другое.

Это махровый женский шовинизм!

210

Работа / Re: Поиск работы системным аналитиком в Европе (Британия, Нидерланды, Германия)

« : 07 Мая 2014, 15:30:53 »

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

Хотя в Украине как-то умудряются работать на западных заказчиков - не знаю, как им это удается ))

Да прекрасно работают. У японцев, корейцев и китайцев английский в массе язык куда хуже нашего. Но глаза боятся - руки делают.

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

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