Comments 19
Что такое "система", архитектуру которой вы пытаетесь определить, и как она соотносится с software system и software architecture соответственно?
… давайте исходить из того, что речь идет о той "системной инженерии", которая Systems engineering. В этот момент утверждение "определение архитектуры системная инженерия не дает" становится заведомо ложным, потому что найти определение архитектуры, данное в рамках этой дисциплины не составляет труда. Вот только несколько из них:
A system architecture or systems architecture is the conceptual model that defines the structure, behavior, and more views of a system
system architecture [is] a set of representations of an existing (or future) system.
Systems Architecture is a generic discipline to handle objects (existing or to be created) called "systems", in a way that supports reasoning about the structural properties of these objects.
Теперь перейдем к домикам.
Итак, пусть у нас есть описание здания с точки зрения эстетики и функционального назначения. Это описание называется архитектурным описанием.
Мне не удалось найти ни одного формального определения "архитектурного описания". На чем основано утверждение "это называется"?
Архитектурное описание здания также называют для краткости – архитектурой здания.
Кто называет?
Сторонний наблюдатель, который далек от строительной отрасли, может сказать: опишите мне архитектуру здания. Строители так не говорят, они говорят: дайте мне архитектурную часть проекта. Строители выражаются более точно, но сторонний наблюдатель этого может не знать.
Нет, строители не выражаются "более точно", они просто говорят о других вещах. Стороний наблюдатель, говоря об архитектуре здания, обычно (это наблюдение основано на моем круге общения) подразумевает одно из двух: либо архитектурный стиль, к которому принадлежит знание ("готическая архитектура этого собора"), либо набор архитектурных приемов ("в архитектуре этого собора можно видеть").
Собственно, последующие полтора абзаца, будучи построенными на заведомо ложных посылках, тоже не могут быть корректными.
Теперь вопрос: у системы одна архитектура или их много?
Исходя из того определения архитектуры, которое "набор представлений" (а это доминирующее определение архитектуры как объекта, в противовес архитектуре как процессу), у системы может быть столько архитектур, сколько наблюдателей, однако многие из этих архитектур нежизнеспособны (не позволяют выносить суждения), а большая часть "гомеоморфна" (термин применен неточно) друг другу.
Но определение архитектуры мы дать так и не сможем.
Это удивительно, учитывая, что это определение уже дано.
Пусть есть здание. Это здание существует 100 лет и за время своего существования пережило 3 реконструкции. Жизненный цикл здания — 100 лет. Жизненный цикл каждой из его конструкций — 25 лет. Как это смоделировать при помощи СИ?
Я моделирую это так: есть объект — здание. У него есть атрибут Длина жизненного цикла и значение — 100 лет. Есть 4 конструкции, каждая имеет атрибут Длина жизненного цикла — 25 лет.
В СИ длина жизненного цикла объекта и его конструкции совпадают по причине того, что СИ не делает различия между объектом и конструкцией. И то и то называя системой.
Пусть есть здание. [...] Как это смоделировать при помощи СИ?
С помощью чего, простите? Системной инженерии? А это точно задача, для которой она предназначена?
В СИ длина жизненного цикла объекта и его конструкции совпадают по причине того, что СИ не делает различия между объектом и конструкцией. И то и то называя системой.
Приведите, пожалуйста, цитату из авторитетного труда по системной инженерии, который бы это подтверждал. Пока это выглядит как ваш досужий домысел (равно как и вообще вся попытка применить системную инженерию к этому примеру).
Я правильно понимаю, что в данном случае Вы моделируете здание в информационной системе (а не в виде его физического макета, например)?
Если так — то вопрос — для чего будет служить данная модель?
Если для целей учета, например, то мне кажется, что все проблемы от того, что мы, компьютерщики, по большей части немного невежественны (английское "arrogant" лучше передает смысл).
Т.е. в данном случае прекрасно подходит автоматизация в лоб, эмуляция старого бумажного варианта документирования\бюрократии. Где здание — это папка с вводным листком содержащим его основные характеристики (избыточные кеширующие данные), и вложенным набором проектных документов (могут быть сгруппированы в подпапки), каждый их которых является частью транзакции по изменению текущего реестра и, заодно, историческим свидетельством.
Как пример.
Т.е. в данном случае прекрасно подходит автоматизация в лоб, эмуляция старого бумажного варианта документирования\бюрократии.
"подходит" для каких конкретно целей? Просто "учет" — термин очень общий. Было дело, занимались мы учетом недвижимости, так там эмуляция бумаги обошлась слишком дорого и мешала последующей автоматизации. Совершенно одно дело, когда вам надо знать набор характеристик здания на каждый момент времени (за время его учета), и другое дело — когда вам надо знать проектные документы на каждый момент времени. И третье дело — когда вам надо видеть изменения в характеристиках.
Должен извиниться за маленькую провокацию (еще и ответил не в том треде).
И должен признаться, что полностью с Вами согласен.
На то и был намек, что любая модель должна отображать конретный интересующий нас срез реальности, на то она и модель. Само здание ни в какую, ни в бумажную, ни в "компьютерную" (в кавычках, потому что и тут много вариантов) систему не запихнуть. Здание останется в реальности и каждый будет ощупывать его собственной моделью. Для таракана, например, она органично ограничится только небольшим фрагментом из стены, щелей, буфетов и мест водопоя.
С другой стороны — вот мы сделали систему (больше PoC, должен признаться, надо переписывать), базируясь на тех понятиях, что появились в бумажном мире, но дополняя их за счет более высокого уровня абстрактности "электронных связей". Но суть не в этом.
Дело в том (и надеюсь Вы этого понимаете), что все три варианта информационных моделей, что Вы привели в пример — можно построить и в бумажном виде. Возможно они будут не такими очевидными для нас и покажутся жутко неудобными, но пострить можно и мегапроекты прошлого тому подтверждение. Более того, раз можно на бумаге, то в нашей, например, тоже можно, но будет гораздо удобнее. ;)
И, конечно, во всех трех случаях — это будут три разных варианта. И речь именно об этом. Хотя… именно в компьютерном виде — можно и гибрид соорудить. Все за счет избыточности, конечно (грубо говоря — папка в папке в папке), но можно.
Дело в том (и надеюсь Вы этого понимаете), что все три варианта информационных моделей, что Вы привели в пример — можно построить и в бумажном виде.
Можно. Но стоимость поддержки будет разной (и иногда — слишком высокой).
Вопрос не в том, что можно построить на бумаге. Вопрос в том, какой бумажный учет уже есть, и что эффективнее — переносить его в цифру, или строить новый, сразу цифровой.
Снова согласен.
Но, как я понимаю, автор пытается прорваться и дать рецепт актуального сферического коня в вакууме. Тому, к сожалению, много признаков, начиная от обязательного "подробности в следующем номере", до самого большого греха программиста и писателя — добавлять все больше слов, надеясь, что накопленное чудесным образом приведет к пониманию (будь читатель читателем, или машиной).
По поводу "моей" темы. Я просто хотел подчеркнуть, что мы слишком часто мыслим "компьютерными" абстракциями. То есть сразу и автоматически проецируем понятия на таблицы или классы ООП, например. Делаем, в итоге, локальный, "тараканий" срез. Который работает идеально быстро и эффективно.
Другая крайность (сам грешу), которая, как ни странно — продолжение первой — верим, вот еще чуть-чуть абстрактнее и найдется такая, которая даст ответ на все и сразу.
что эффективнее — переносить его в цифру, или строить новый, сразу цифровой
Так вот, уверен, что это отдельная тема, но просто еще раз подчеркну — давно, лет 25 назад, заметил, что мы противопоставляем одно другому. Хотя было бы правильнее при "переносе в цифру" учитывать, все-таки, накопленный багаж умений из прошлого. Правда тогда это было сложно очень представить в виду незрелости технологии. Книга "Проектирование и программная реализация экспертных систем" лежит под рукой с 91 года; абстракция "электронной таблицы" офигенно популяризировала ПК; РСУБД после придуманных на коленке индексированных файлов и, позднее, родного .DBF; что-то близкое к реальному прорыву в лице Lotus Notes — но, повторюсь, тогда было сложно.
Ну, снова, это отдельная тема. Но я верю, что пора менять ситуацию, программы, неожиданно, определяют эволюцию бизнеспроцессов, диктуют правила и модели, цементируют так, что чаще проще реальность подогнать под инструмент, чем наоборот. Конечно, часто оно и к лучшему, часто ПО компетентнее пользователя. Но с бумагой, хотя бы, понятны истоки ограничений, а главное, выясняется, что с другой стороны, с точки зрения податливости методологии — там было гораздо приятнее.
Так что подожду продолжения серии. Может быть автор, все-таки, выдаст краткое резюме и найду подтверждения своим чаяниям. :)
Я просто хотел подчеркнуть, что мы слишком часто мыслим "компьютерными" абстракциями. То есть сразу и автоматически проецируем понятия на таблицы или классы ООП, например.
Кто как. Я как раз стараюсь требовать от аналитиков ТЗ, не подверженное влиянию реализации.
Так вот, уверен, что это отдельная тема, но просто еще раз подчеркну — давно, лет 25 назад, заметил, что мы противопоставляем одно другому. Хотя было бы правильнее при "переносе в цифру" учитывать, все-таки, накопленный багаж умений из прошлого.
Учитывать — да. Переносить один-в-один — нет.
Кто как. Я как раз стараюсь требовать от аналитиков ТЗ, не подверженное влиянию реализации.
Ну, снова соглашусь. Но идеал, это чтобы аналитик сразу сам систему и настраивал. Согласны?
Учитывать — да. Переносить один-в-один — нет.
Один в один не просто не получится, это еще и глупо было бы, конечно.
Но когда мы стали отталкиваться именно от понимания, почему в бумаге было так, а не этак, оказалось, что почти все понятия старой бюрократии (после некоторой ломки парадигмы и мозга, конечно) замечательно перекладываются в ИС, а главное, воспринимаются пользователями.
Ээээ. Ок. Сейчас меня понесет про графовые базы и прочее (это вот такой новый уровень искажения абстракции), так что я замолкаю ;)
Ну, снова соглашусь. Но идеал, это чтобы аналитик сразу сам систему и настраивал. Согласны?
Нет, не согласен. Настройка — это та же разработка, а работа аналитика — это не работа разработчика. Когда аналитик сам же и настраивает, мы получаем смешение ответственностей и плохой дизайн результата.
Но когда мы стали отталкиваться именно от понимания, почему в бумаге было так, а не этак, оказалось, что почти все понятия старой бюрократии (после некоторой ломки парадигмы и мозга, конечно) замечательно перекладываются в ИС
Все понятия старой бюрократии обычно замечательно перекладываются в ИС, только вот новые задачи эта ИС (как и старая бюрократия) решать обычно оказывается не способна.
По поводу первого — настраивает что, процесс или компьютерную систему? Для меня вот это боль — почему аналитик (это же человек, который знает, как правильнее было бы информации течь, правильно?) должен работать с информационной системой через посредников (я сейчас про идеальный случай). Мы же дали возможность дизайнеру дизайнить напрямую. Почему с учетом не так? (ох далеко мы ушли от топика)
только вот новые задачи эта ИС (как и старая бюрократия) решать обычно оказывается не способна
Еще когда отправлял предыдущее сообщение — понял, что Вы про конкретную бюрократию в конкретной организации. А я про перенос понятий в общем и свободу каждого настраивать такие потоки информации, которые подходят именно ему. Ну да это требует отдельного поста (на самом деле серии), видимо и страшного холивара под ним. Как-нибудь рискну.
настраивает что, процесс или компьютерную систему?
Ни то, ни другое.
Для меня вот это боль — почему аналитик (это же человек, который знает, как правильнее было бы информации течь, правильно?) должен работать с информационной системой через посредников
Потому что он не работает с информационной системой. Работает с ней пользователь. А он участвует в ее создании. Разделение "аналитик-разработчик" позволяет аналитику строить такое ТЗ, которое максимально близко к желаемому результату, без ненужного влияния реализации (ну а разработчику, наоборот, реализовывать, имея конкретное ТЗ). У аналитика и разработчика немного разные цели, и если объединить их в одной голове, вы получите неудобный компромис.
Мы же дали возможность дизайнеру дизайнить напрямую.
Кто дал? Где дал?
А я про перенос понятий в общем и свободу каждого настраивать такие потоки информации, которые подходят именно ему.
Это как раз противоречит бюрократии. Задача (по крайней мере, некоторых) ИС — это как раз унификация "потоков информации" и процессов учета.
А он участвует в ее создании. Разделение "аналитик-разработчик" позволяет аналитику строить такое ТЗ
Ну, еще раз — я бы хотел убрать разработчика из процесса. Ну ОК — пусть разработчик будет, но не программист, а именно разработчик системы потоков информации. Называйте как хотите. Но только не нужен для этого "компьютерщик" и все тут ))
Это как раз противоречит бюрократии.
Если мы под бюрократией понимаем не что-то жуткое, а именно систему управления через "бюро" — то не противоречит. Я там оговорился — свободу не каждого, конечно, но каждой организации. Пусть каждая организация настраивает поток под свои нужды.
Пусть будут на рынке аналитики, которые знают как лучше, пусть им платится, пусть будут шаблоны потоков (то, что было в бумажной бюрократии), но пусть каждый настраивает их под себя.
Я так думаю ;)
Ну, еще раз — я бы хотел убрать разработчика из процесса. Ну ОК — пусть разработчик будет, но не программист, а именно разработчик системы потоков информации. Называйте как хотите. Но только не нужен для этого "компьютерщик" и все тут
Не выйдет. Этот "разработчик системы потоков информации" в итоге будет уметь все то же самое, что и "обычный" разработчик — начиная от, собственно, языков программирования (потому что в ваших "потоках" неизбежно будут ветвления и прочая фигня) и заканчивая версионированием, обратной совместимостью, развертыванием, тестированием и так далее.
Мы, как бы, проходили этот путь, когда работали над системой, где "все настраивает аналитик". Не работает. Нужен процесс, иначе получается мусор.
Пусть каждая организация настраивает поток под свои нужды. Пусть будут на рынке аналитики, которые знают как лучше, пусть им платится, пусть будут шаблоны потоков (то, что было в бумажной бюрократии), но пусть каждый настраивает их под себя.
Так это давно есть уже, больше чем в одном продукте. И всегда упирается в одну и ту же проблему: когда это "настроенное под себя" надо свести к стандарту (унифицировать между филиалами, унифицировать при покупке компании, отослать отчетность по стандартам государства или крупного партнера), начинается боль.
Да, давно все есть. И 1С и Excel и все метафоры монтажного стола. Возвратно-поступательное движение, но суть в том, что инструменты поднимаются все выше по лестнице асбстракций и люди тоже должны развиваться, чтобы ими управлять.
Все важнее быть творцом (разработчиком, в любой профессии). Так было всегда. И, кстати, именно в нашей области деятельности — быстро развивающиеся инструменты очень наглядно выкашивают, поколениями, уверовавших в догмы специалистов.
Происхождение объектов учета