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

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

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

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

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

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

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

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

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

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

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

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

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

Тем не менее - это не мои слова.

Ну а по поводу интерфейса http://ru.wikipedia.org/wiki/Интерфейс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аналогично и пример с принятием решения, опять выпадает из канвы рассуждения., потому как назначении системы не принять решение, а помочь его принять и скорее будет выливаться: в Оценить действие такого-то фактора на коньюктуру этого, т.е. цель моего использования инструмента в принятии решении, но цель моего конкретного использования инструмента Оценка влияния фактора. Что в данном случае будет функциональным требованием?

Система должна помочь пользователю принять решение? И как это измерить?
Или
Система должна помочь оценить влияние фактора методом стохастически сходящихся детерменистки-расходящикся векторносвернутых скаляров?

Эд, твоя цель как пользователя - принять решение о кредите и внести свое решение в систему ... система тебе для принятия решения дает данные ... Какой будет твоя цель как пользователя?

Ты победил!
Мне добавить нечего.

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

Эд, твоя цель как пользователя - принять решение о кредите и внести свое решение в систему ... система тебе для принятия решения дает данные ... Какой будет твоя цель как пользователя?

Думаю моя конечная цель принять решение, однако цель использования системы - Получить данные для принятия решения и Зафиксировать это решение.

Да в начальном моем сообщении, все возможно очевидно.

и

против


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

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

Какой функцией - читай интерфейсом, молоток смотрит на мир? (имхо можно ли вообще использовать такое сочетание?)

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

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

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

Загибаешь!

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

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

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

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

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

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

Загибаешь!

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

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

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

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

Это элементарно, Ватсон!

Холмс, опиши на хорошем английском и связано через функции интерфейс молотка, please mister.