Обсуждение

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

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

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

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

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

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

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

Тоже вариант - как public / private . Но тут ключевое слова как я понял - контракт , а стороны вступают в собой в контрактные отношения по вполне четкому транзакционному процессу, имеющими материализованный вход и материализованный выход

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

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

Ну нет, совсем другие рассуждения. Вот, почитайте, например относительно типичное рассуждение про контракты модулей -- http://leon.bottou.org/slides/2challenges/2challenges.pdf (с точностью до того, что в программной инженерии всё чуток сложней, ибо работающий код всё-таки не совсем классическая инженерная система, плюс автор честно говорит, что в инженерии машинного обучения всё ещё сложнее -- и вводит разные типы контракта в связи с этим). Я не изобретаю терминологию по ходу дела. Я обобщаю уже имеющиеся инженерные разговоры.