151

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 16:09:46 »

Простите, но Actor взаимодействует с системой через UC.
Или ты что-то иное имеешь ввиду, когда требуешь рисовать UC на четырехугольнике системы и рисуешь ассоциацию между Actor (вне системы) и UC (внутри системы).

И почему это, если пользователь взаимодействует с системой через интерфейс, он окажется внутри системы? Где тебя сейчас искать? В зазеркалье?

Загибаешь!

UC не содержит действия пользователя, а описывает взаимодействия пользователя с системой.
А вот система полностью реализует UC (UC Realization), предоставляя пользователю интерфейс, соответствующий описанию UC.
Т.о., UC - это свойство только системы! Значит, это функция? Правда?

А какой пример функции, который не является реализацией UC?

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

UC при этом не принадлежит системе и не является ее свойством. Он ее всего лишь описывает в ракурсе "как с нею взаимодействовать пользователю". в этом описании "упоминаются" используемые пользователем функции (вот они - свойства системы) для достижения его цели.

152

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 15:52:40 »

Какой функцией - читай интерфейсом, молоток смотрит на мир?

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

153

Задачи студентов / Re: Друзья, помогите!

« : 19 Апреля 2011, 12:43:50 »

дружище, нет такого слова "махай"
изучайте лучше матчасть.

154

Задачи студентов / Re: Друзья, помогите!

« : 19 Апреля 2011, 11:22:45 »

...<махнул рукой>... пусть тренируется...

155

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 01:07:33 »

Относительно первого - Word.
...
Я не знаю, использовал ли Microsoft термины UC, UCI, UCE. Но есть вещи, которые выполняются одинаково или почти одинаково, независимо от того, как их называют. Думаю, Word делали не один год, определяли цели, рисовали какие-то схемы взаимодействий, определяли спецификации (процессов, функций, UC - все равно, как они их называли!), планировали, для реализации функциональности создавали или использовали существующие классы и компоненты.

Скорее нет, чем да :о))) потому что сколько бы времени (пока!) ни прошло с момента его создания, какие бы компоненты и классы ни насоздавали и не использовали, но почему-то форматирование таблицы в ворде делается принципиально иначе, чем в экселе. видимо (точнее, так и есть), там другая команда над ним работала.  и были (а может и нет) у нее свои UC ... или что они там используют.

156

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 00:45:54 »

Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.

С помощью UC можно описать... а с помощью SysML спроектировать ...

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

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

Процесс, конечно же, начинается с определения цели, UC...

согласен, хотя вообще-то не о том речь-то...

157

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 19 Апреля 2011, 00:35:20 »

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

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

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

так что наезд мимо кассы, однако...

158

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 18:48:28 »

Конкретно: как и чем с помощью функций система смотрит на мир и что система экспонирует наружу, и почему с помощью функций система это может, а с помощью UC - нет.

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

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

159

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 18:42:23 »

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

Сильно! Электронный способ показывания времени ... понимаю, не говоря о механическом, даже двоичный могу понять (есть и такие часы - для программистов). Но АТОМНЫЙ??? может это все-таки способ функционирования механизма, обеспечивающего нужную точность хода, а не способ показывания времени?

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

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

вот про это. фактически, что можно с помощью программы, системы или устройства сделать (или получить).
теперь только термин "набор возможностей" или просто "возможность" осталось определить :о)))

160

Задачи студентов / Re: Друзья, помогите!

« : 18 Апреля 2011, 16:21:01 »

Нужно описать именно принцип работы кондиционера.

опять же яндекс.

161

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 18 Апреля 2011, 12:14:12 »

Не следует ли дать точное отнологическое определение понятию функция....

угу, дай...

162

Задачи студентов / Re: Друзья, помогите!

« : 18 Апреля 2011, 10:43:41 »

неее, неправильно. все легко ищется в яндексе.

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

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

P.S. и потом... кондиционеры бывают разные...

163

Работа / Re: Провокация кандидата на собеседовании, Вика Придатко

« : 15 Апреля 2011, 15:58:15 »

поведение с разным собеседником будет разным

собеседник не может быть разным, разными могут быть собеседники :о)))

164

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 14 Апреля 2011, 22:55:08 »

все-таки, думаю, не надо уподобляться Шерлоку Холмсу, ставящему в тупик своего коллегу Ватсона :о)))
лучше все же пояснять внимающему человечеству, откуда берется "приемное устройство" (и потом про купюры  разговора не шло :о))) и про сообщение о необходимости оплаты тоже).

Диаграмму последовательности многие используют как раз для поиска необходимых модельных элементов. Есть такая замечательная книжка Лармана: Применение UML и шаблонов проектирования.

Ага, так и делал. И книжка одна из самых полезных и тоже любимых в свое время.

165

Варианты Использования (Use Case) / Re: Use Case vs. Use Cases - какая должна быть степень детализации?

« : 14 Апреля 2011, 20:10:03 »

Дааа, тема пошла интереснааааяя

Действительно, будет ли достаточно такой диаграммы и возможно ДД для проектировщика? Разработчика? Достаточно ли информации тестировщику? Конструктуру внешней оболочки?

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

Далее я предложу еще такую примитивную диаграммку.

Соглашусь с Леонидом, эта диаграмма ничего сейчас не дает, кроме перечня вариантов возможных монет. а это сейчас несущественно. Поэтому предлагаю перейти к его предложению по другим диаграммам. С последовательностью очевидно возникнет некоторая трудность, т.к. у нас еще не определены подэлементы автомата, и она (диаграмма) тоже может нам ничего не дать.

P.S. согласен с Коберном: определить процесс с помощью UC невозможно, хотя что описание UC очень на него похоже и может показаться, все это является одним и тем же.