А.А. Шалыто против Г.Буча

Ну, не все же ему меня обижать-то

на цельных два месяца!!! Он не обидится???

Считаем, что:

1. нормы этики и приемлемые приемы ведения дискуссии освоены
2. отечественные стандарты 2, 19 и 34 серий вызубрены;
3. польский выучен;
4. тактика ведения боя в городских условиях с применением бронетехники освоена на практике;
5. чего-нибудь еще, но после, поскольку и так впустую потратил на Вас достаточно много времени - все простил.

С возвращением в форум!

Поскольку требования модератора к сведению приняты не были, отключаю Вас на время, необходимое и достаточное для глубокого изучения, осмысления и практического освоения:

1. норм этики и приемлемых приемов ведения дискуссии;
2. отечественных стандартов 2, 19 и 34 серий;
3. польского языка, пся крев;
4. тактики ведения боя в городских условиях с применением бронетехники;
5. чего-нибудь еще, но после, поскольку и так впустую потратил на Вас достаточно много времени.

Желаю успеха.

... о строгости ГОСТ ...
1. Смотрю ... и что видим ... например: п. 49 Спецификация программы -- есть формализованное представление требований которые должны быть удовлетворены ... и что это ТЗ это НЕ формализованное описание требований ... или ТЗ == СПЕЦИФИКАЦИЯ ПРОГРАММЫ???? не понятно ... поясните плиз ...
2. Смотрел, не нашел определения СТРУКТУРЫ программы ... подскажите точный номер пункта пожалуйста!

Да, изучил то он поболее вашего и моего вместе взятых ... это точно.

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

Есть одна очень хорошая фраза "Архитектура это дизайн, но не весь дизайн -- архитектура" ... подумайте над ее смыслом.

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

... простите ... но вы абсолютно не в теме ... ... это не то что вы предполагаете ... это даже ни каким боком не относится к понятию "качество" ... в оригинале это "quality attributes" ...
Я повторю азбучную видимо вещь ... прежде чем что-то критиковать -- изучите досконально вопрос ... а то будите как тот профеесор с автоматным программированием "иметь бледный вид перед специалистами" ... кстати на SECR на докладе Якобсона, которого профессор в своей статье критикует -- профессор не рискнул задать ему прямо НИ ОДНОГО ВОПРОСА по UML, и сидел ваш профессор аккурат передо мной, и я набллюдал за его реакцией на фразы Якобсона

Вот и я про то ... я то думал что ГОСТ воспитывает привычку досконально разбираться в вопросах ... видимо нет?

поподробнее про структуру и архитектуру можно?

Иными словами, архитектура - это аццкая смесь:
- структуры программы или системы с описанием функций составных частей и связей между ними;

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

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

Нет там и впомине этого ... Посказка для специалистов "с системным подходом, воспитанным ГОСТ": в данном контексте дизайн это не процесс ... . Вобщем-то студенты 4-го курса это уже понимают , сам читал в этом году лекцию им ... и был приятно удивлен.

Видимо вы не дочитали полностью мой ликбез ... а жаль ...

5 баллов! Я это буду цитировать ... с указанием автора конечно же! Разрешаете?
Комментарий: Обратите внимание как я научился вашему ловкому приему дискуссии, очень характерному для предствителей определенной професси особенно в советские времена -- выдеркивать из контекста фразу ...

Уже показал - см. выше. Только не надо обзывать все это модным словом архитектура

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

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

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

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

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

Источник - http://www.computer-museum.ru/histsoft/epoch.php

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

"Результат процесса анализа требований" Требования не анализировать надо, а формулировать и предъявлять. В ГОСТах все требования классифицированы, сгруппированы по классификационным признакам - давно уже проанализированы. Умными головами. А свебок предлагает мне делать уже давно и отлично сделанную умными людьми работу Ну не глупость ли? И чем любая вновь создаваемая система может идеологически отличаться от предшественниц? Требования ГОСТ 34 едины для всех видо автоматизированных систем.

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

Надо отметить, что цели прописаны правильно В 1.1 Общие концепции проектирования. Как в статье про то, как писать техническое задание.

"свебок не дает явного определения. что такое архитектурная структура". Ну и бредятина

"4.1 Атрибуты качества" Вот это круто, народ ошарашен... А чем же ГОСТ 28806-90 КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ не угодил? И ГОСТ 28195-89 ОЦЕНКА КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ. ОБЩИЕ ПОЛОЖЕНИЯ? Зачем народу этот, ка Вы изволите выражаться, куцый свебок, когда есть два прекраснейших ГОСТ?

Дальше, уж извините, читать не стал. Но ссылочка Ваша изрядно подняла мне настроение

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

Иными словами, архитектура - это аццкая смесь:
- структуры программы или системы с описанием функций составных частей и связей между ними;
- связи программы (системы) с другими программами (системами);
- перечня работ, выполняемых на всех стадиях и этапах создания или развития системы (программы), если дизайн - это создание или разработка.
Непонятно только, что есть принципы дизайна. Буржуи не предлагают ничего нового, чего не было бы в "устаревших" ГОСТ. Более того, архитектура, как таковая, вовсе не нужна. Зачем вводить новое объединяющее понятие? Не интегрировать надо, а наоборот, дробить. Или выполнять декомпозицию, щас так модно.

Уже показал - см. выше. Только не надо обзывать все это модным словом архитектура

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

Это же азбучные истины См. ГОСТ 19781-90. Там все расложено по полочкам, а не свалено в кучу, как в IEEE.
А то как в том стихотворении, слегка доработанном - "он знал довольно по-французски, но русского не знал"

Не ответили. Даже не дали ссылку на IEEE Std 1471-2000. Желательно в русском адекватном переводе. Ждем-с.

У меня есть в PDF ... и на английском ... а перевод на русский зачем? там и по-английски все внятно написано ... скажите ваш е-mail я вышлю ...
А что касается SWEBOK ... то перевод есть, и даже с комментариями http://www.almportal.ru/public/so/book/3-2-software_engineering_design.pdf

Согласен, что ГОСТы рассчитаны на специалистов, способных если не мыслить широко, то широко охватывать материал. А должно ли быть такое понятие, как архитектура? В этом есть необходимость? Может, построение программы есть производная от ее структуры?

Давайте не будем про широту крузогора и т.п. ... это не относится к программной архитектуре ... давайте сконцетрируемся на конкретной теме ... описание архитектуры и методы .. что рекомемндует ГОСТ и западные технологии ... все же просто.
Ок, что вы понимаете под структурой программы? ... и построение это что -- ПРОЦЕСС или это статическая сущность? Я не понимаю ваших терминов ... определите пожалйста их.

Если Вы о клиент-сервеной архитектуре, то читайте крайнюю строчку из цитаты.
С вопросами - позже, давайте точное определение из IEEE об архитектуре программы.

Только по IEEE??? ... есть еще RUP, есть TOGAF, есть Захман ... ...
*********************
Стандарт IEEE 1471 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems) приводит следующее определение архитектуры: Архитектура - это фундаментальная организация системы, выраженная в ее компонентах и их связях между собой и с внешней средой, а так же принципы и правила дизайна и развития системы.

Как отмечают некоторые авторы, это определение достаточно общее и "академическое" ([Albin, 2003], [Garland & Anthony, 2003]) и может быть применимо не только для программного обеспечения. Для большей ясности, требуется построить классификацию различных видов архитектур, отталкиваясь от которой говорить о конкретном виде архитектуры и способах ее представления (что наиболее важно с точки зрения практического использования).
Так, например, [Garland & Anthony, 2003], говоря об "архитектурной организации" больших программных систем, выделяюет различные типы архитектуры, и в частности, говоряит про Архитектуру предприятия (Enterprise Architecture), которая определяется в терминах ее сотавляющих -- бизнес-архитектуры, программной архитектуры, технологической и инфраструктурной архитектуры, архитектуры информации и данных.
Бизнес-архитектура (Business Architecture) определяется как ключевые бизнес-стратегии, организационную структуру, бизнес-цели, и связанные с ними бизнес-процессы.
Технологическая архитектура (Technology/Infrastructure Architecture) - к этому виду архитектуры относят компьютерные сети и сетевое оборудование, аппаратное окружение, в котором функционирует ПО, операционные системы и др. технологические аспекты, которые способствуют коммуникациям распределенных компонент ПО и поддерживают среду работы ПО.
Архитектура информации и данных (Data Architecture) - определяет как собственно структурированы данные, как и то, где они хранятся и обрабатываются в целом для предприятия или в конкретном ПО.
Системная архитектура (Systems Architecture) - включает Программную архитектуру, Технологическую архитектуру, Архитектуру информации и данных.
SEI (http://www.sei.cmu.edu/architecture/) и Len Bass, Paul Clements и Rick Kazman [Bass, Clements, Kazman, 2003] приводят следующее определение Программной архитектуры (Software Architecture): Программная архитектура программы или компьютерной системы есть структура или множество структур данной системы, которая включает в себя составные части (элементы) данной системы, экспонируемые свойства этих составных частей и их взаимосвязи.

Говоря про "экспонируемы свойства" или, точнее про "видимые извне свойства", имеются ввиду те "предположения", которые могут сделать одни элементы системы относительно сервисов, общих ресурсов, характеристик производительности, обработки исключений и т.п. других элементов [Bass, Clements, Kazman, 2003].

TOGAF, позиционирующийся как Enterprise Architecture Framework, оперирует теми же составляющими Enterprise Architecture.
*****************
Вот вам обозорчик ... а про клиент-серверную архитектуру говорить и описывать неинтересно .... уж тогда давайте про layers поговорим, а не про tiers ...
А теперь скажите что за архитектуру в ГОСТ кроме этого куцего абзаца есть еще написано ... как же по ГОСТ-то описывать архитектуру -- или как хочешь так и пиши? ... что строгость ГОСТ тут уже не рулит? (Это вопрос был № 1)

Вопрос № 2. Алгоритм программы .... тоже интересно очень взглянуть на правила описания алгоритмов ... и желательно систем автоматизации бизнеса, а не управления танками ... у вас же богатый опыт работы с ГОСТ ... подкинте учебный примерчик на который взглянуть можно?

Вопрос №3. В ГОСТ читаем "- структура программы с описанием функций составных частей и связи между ними;" Как ГОСТ определяет что есть структура программы??? И на каких уровнях эта структура должна рассматриваться ... что есть состаные части ... это классы? ...

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

Не ответили. Даже не дали ссылку на IEEE Std 1471-2000. Желательно в русском адекватном переводе. Ждем-с.

Согласен, что ГОСТы рассчитаны на специалистов, способных если не мыслить широко, то широко охватывать материал. А должно ли быть такое понятие, как архитектура? В этом есть необходимость? Может, построение программы есть производная от ее структуры?

Если Вы о клиент-сервеной архитектуре, то читайте крайнюю строчку из цитаты.
С вопросами - позже, давайте точное определение из IEEE об архитектуре программы.

Вы, свми же пардон, провоцируете и конечно же ожидаете именно такой реакции ... просто очень напоминает стиль и методы тех -- кого <удалено модератором> ... зато теперь понимаю ваши пределы . Но бог сними, давайте о деле и по теме, если вы не возражаете ...

Так вот, хотел узнать про комментарии по поводу архитектуры ... мы остановились на вашей рекоммендации взглянуть в ГОСТ 19.402 на тему архитектуры. Я ответил на вопрос про то, что я понимаю под архитектурой (уточним, что речь шла именно о программной архитектуре) ... Начнем с того что серия 19 ГОСТ не самая современная, и написано там, довольно скудно IMHO о том, что же и каким образом следует описывать программную архитектуру, да собственно поняти архитектура там я не увидел ... в связи с этим вопросы:
1. существуют ли примеры или методические указания о том КАКИМ образом следует и что следует там описывать ?
2. про схемы алгоритмов и то является ли это программной архитектурой ...?

byur, здесь профессиональный форум, а не чат для обкуренных подростков. Понимаю, что RUP'ом это не предусмотрено, тем не менее предлагаю тщательнее подбирать выражения.

Уверены что дело в технологиях? ...

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

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

Блин ... вы и вправду думаете что все такие глупые и не в курсе как и чего нужно делать ??? Да плевать ваши <удалено модератором> хотели на служебки ...

ГОСТы? не было нужды постигать ....

Хм ... в мир иной уходят ... к сожалению ...

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

Это ваши домыслы а не сказанное "иными словами" ... не нужно <удалено модератором> приемов ведения дискуссии... , вот именно, что готовы взяться, за то что делать не умеете -- ручки шариковые ... большевизм рулит ... ...

Опишите ка по ГОСТ процесс создания бутера ... чтобы по нему можно было сделать бутер ... выложите к себе на сайт ... там и изучим .

Не ем фаст фуд ни ихний ни наш ... . Сало -- рулез форевер .

То что в IEEE Std 1471-2000 написано или в SWEBOK ... то и понимаю ...
А вот в ГОСТ что-то не густо по этому поводу ...:
"6. В разделе «Описание логической структуры» должны быть указаны:
алгоритм программы;
используемые методы;
структура программы с описанием функций составных частей и связи между ними;
связи программы с другими программами.
Описание логической структуры программы выполняют с учетом текста программы на исходном языке."

Очень информативно ... а примерчик есть где-нить, описания архитектуры? ...

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

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

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

А как же Вы, простите, постигли?

Эт точно. Но уходят, уходят профи...

Главное, чтобы прокурору и судье читать было приятно, и не до чего нельзя было докопаться

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

Во! Наконец-то! Есть понимание, что бутерброд - штука небезопасная, отравиться можно. Поэтому по ГОСТ делать надо Так софтинка тоже штука небезопасная, когда на компах выполняется

Мне удалось убедить тогда еще десятилетнюю дочь, что в нормальной чебуречной лучше и вкуснее, чем в макдоналсе На практике

Например, по ГОСТ 19.402. Только хотелось бы уточнить, что Вы понимаете под архитектурой программы

Неа ... по их технологиям когда сделано -- то оно почему-то работает ... я вот в Австрии имел удовольствие работать ... дык Интернет просто летал и самое удивительное не падал ... а у нас в универе -- канал через ЦУП шел ... и нивзирая на халявный для универа трафик -- статьи из сборников научных (опубликованных в Инете) приходилось и через FTPmail иной раз закачивать ...
А у нас реалии таковы, что жмутся на каналы Банки, как мелкие, так и не очень ... так данные мегами по модему качают ... изсестноые случаи, когда сидит народ до 12 ночи, ждет пока закачаются данные ... а ведь ИТ-шники ноют, что нужно нормальный канал поставить ... да кто иж слушает ... рулят-то бывшие ГБ-шники ... им плевать на то что люди до 12 сидят.

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

Тоже неправда ваша ... контор, которые делают по RUP по поальцам пересчитать можно и ни одна из них не является разработчиком банковского софта ... увы -- как раз, нам всякие Диасофты, новые Афины, и прочия околобанковские конторы, все ТЗ типа по ГОСТ норовят всучить ... а там -- жуть .... дело конечно не в ГОСТ, а в людях, которые по ГОСТ писать не умеют ... где уж им премудрости RUP постичь ... .

Могу только в общих чертах сказать что делает сейчас НИИПП для него ... но это относится к ОЛС ... делается все по-нашему, по-бразильски -- героичискими услилиями нескольких предпенсионного возраста математиков (алгоритмы распознавания) ... и студентов ... ... кстати по ГОСТ ... требования "летчики" из КБ выкатывают -- читать приятно ... практически SRS по IEEE 830 ...

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

Вот например для создания бутерброда с джемом и маслом ... это я бы помотрел комплект документов по ГОСТ ... и попробовать по ним сделать бутер ... . Кстати, таким образом один буржуй здорово опустил наших спецов ... но это отдельная тема ...

Кстати -- вопрос .. а как по ГОСТ архитектуру ПО описать?

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

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

Раз непонятно, значит, статьи не читали. Вот ссылки:
- Страшная правда о юзабилити. Часть I;
- Страшная правда о юзабилити. Часть II.
Если вопросы останутся, готов расписать для вас тезисы.

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

Кто щас начальник ЦУП? Надо спросить у него, что за юзабилисты там такие поганые пульты ему юзабилизировали
Интересно, а вот у истребителя пятого поколения кресло летчика юзабильное? Юзабильнее, чем в субару или мерсе? Коль скоро Вы принимали участие в создании истребителя пятого поколения?

Скорее, просто невостребованы. Зачем родине профессионалы, если в ВТО вступать собирается

А представьте, что принципиальная разница между тем и тем особо мне неинтересна. Поэтому сходу отвечать не готов. Но предлагаю поиграть в одну увлекательную игру: берем всем хорошо известную простую вещь типа спичечной коробки или шариковой ручки, Вы проектируете эту вещь своими буржуйскими методологиями, а я использую родные советские ГОСТ. А потом посмотрим, что у Вас и у меня получится

Так что, возметесь расписать документацию, технологические процессы на шариковую ручку (телевизор, кресло пилота) и т.д. с помощью РУПов и докфлоу/воркфлоу

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

Какая там сложность? Автоматное программирование доступно даже младенцу

Угу. В настоящее время по западным схемам усилиями господ юзабилистов создается юзабилити-"индустрия"

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

Скажите, а почему вы не ответили про принципиальную разницу, м/у автоматным программированием и docflow/workflow системами???

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

Какая там сложность? Автоматное программирование доступно даже младенцу

Угу. В настоящее время по западным схемам усилиями господ юзабилистов создается юзабилити-"индустрия"

Вам об это доложил сам г-н Шалыто?

Высокий, в очках ... седоватый но энергичный. Честно не помню фамилию, но ЛИТМошник с горящими глазами, возбуждался при словосочетании "автоматное программирование" -- еще участвовал в круглом столе по эксперементу с UML, где поставленный над студентами эксперимент статистически показал "поезность и информативность UML при описании дизайна системы". На прямой вопрос об использовании OCL, сказал, что они его использовали ... т.к. работали с "чистым UML" ... (что уже говорит о многом)
Далее -- дама из Цефея, типа математик, тоже про автоматное программирование все вещала и про то, что UML устарел, работать с требованиями не нужно ... и т.п. ... короче опустили ее парой вопросов по UML ...

Могу привести несколько цитат из статьи:

"неудачное название языка, так как он предназначен «не для моделирования как такового» [7], а для создания моделей в виде
диаграмм, позволяющих описывать различные «стороны» программного обеспечения" ...
-- это конечно же спроный вопрос, т.к. нужно четко понимать что есть моделирование вообще .. и для этого одного толкового словаря русского языка не достаточно ... а желательно поднять еще и англоязычные толковые словари.

"не рассмотрены особенности реализации
предложенных моделей, например, в части их
разработки с использованием шаблонов и образцов"
а зачем паттерны в ЯЗЫК-то закладывать???? ... достаточно того что GOF и прочия их описали на этом языке (UML)! Да все case средства их поддерживают ....

"применяются весьма странные термины, например,
«событие-триггер» и «сторожевое условие», в то
время как в вычислительной технике термины
«событие», «триггер» и «условие» имеют вполне
определенный и традиционный смысл"

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

"необоснованно много внимания уделяется
диаграммам прецедентов (диаграммам
использования), в которых «прецедент (Use case)
специфицирует поведение системы или ее части и
представляют собой описание множества
26
последовательностей действий (включая варианты),
выполняемых системой (совокупностью образующих
ее объектов) для того, чтобы актер мог получить
определенный результат» [7]. При сложном
поведении рассматриваемых компонент построить на
этапе проектирования исчерпывающие диаграммы
такого типа практически невозможно. Обратим
внимание, что в рассмотренном в настоящей главе
примере вообще нет актера (пользователя),
который хотел бы получить результат, отличный от
простого выполнения танком требований среды
разработки, и поэтому в данном случае
отсутствует возможность построения
рассматриваемой разновидности диаграмм;"

А это ... в сад, однозначно ... при всем уважении к их сединам и знаниям ... в этой области они, пардон, плохо осведомлены ... следовало бы более детально изучить вопрос про юзкейсы, прежде чем ляпнуть такое на всю страну ... читать Коберна ... . Не те книги по юзкейсам они читали ... и дело не в праве атора ... а в том, что если наезжаешь -- то знай досконально предмет наезда ...
Тогда бы не возникло желания пытаться применить определенный подход (use case approach), там где он не применим ... а специалистам по UML это давно известно ... так что, даже без SECR, есть вопросы к их квалификации в UML ... .

каждая диаграмма состояний предназначена «для
моделирования жизненного цикла объекта» [7].
Поэтому при построении таких диаграмм могут
использоваться вложенные состояния, но не
вложенные автоматы. Действительно, если
применять термин «жизненный цикл», то без учета
реинкарнации одному объекту может
соответствовать только одна диаграмма состояний.
Делая акцент на поведении объекта, а не на его
жизненном цикле, вопрос об единственности
автомата для каждого объекта снимается. У
объекта может быть много методов, часть из
27
которых (а не только один) могут быть
автоматными. При такой трактовке использование
автоматов в объектном программировании
становится более понятным по сравнению с
приведенными выше определениями «пророков»;

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

"ввиду того, что в работах [12,33] показано, что
параллельные процессы могут быть описаны
системой взаимосвязанных графов переходов, то в
применении диаграмм деятельностей нет
необходимости;"

О ... это видимо шадевр научно мысли ... ... activity диаграммами достсточно удобно описывать бизнес-процессы ... ах, да ... они ж автоматами их описывать будут ... и потом начотделу автоматизации фирмы-заказчика будут дополнительно курс лекций по их интерпретации автоматов читать, вместе с софтом на автоматизацию БП ... ню ню ...

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

О да ... разница принципиальная между этими диаграммами ... .

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

Как впрочем и UML может описать любые системы ... ну и что?
Только сложность описания на автоматах и его информативность не соизмерима со стоимостью проекта по автоматизации бизнес-процессов .

Раз они сделали индустрию -- значит уже не "кулибины" ... наши же профессора -- кишка тонка сделать индустрию ... поэтому их никто и не вопринимает в мире серьезно, поэтому и "кулибины" ...

А с другой стороны, поясните-ка мне чем автоматное програмимрование принципиально отличается от docflow и workflow систем??? Будет интересно услышать ответ ... только не надо говорить что не знаете что это такое .

Где же обещанный Эльбрус-2000? ....

Почему же ... Solaris например ... .

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

Вам об это доложил сам г-н Шалыто?

Право автора.

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

Бесспорно.

Только почему-то сейчас в почете западные "кулибины", а не отечественная профессура. Без особых, надо сказать, на то оснований.

Согласен. Во время оно было принято решение отойти от отечественной линейки БЭСМ и пересесть на ЕС ЭВМ. Результат - Эльбрус не сделали, Пентковский свалил в загранку и сделал пентиум. Со слов специалистов - уж больно пентиумовкая архитектура напоминает бэсмовскую.

Или белорусы. И правильно, поскольку более устойчивые системы, возможно, и не существуют.

Вот комментарий "человека оттуда" - http://forum.philosoft.ru/cgi-bin/forum/ikonboard.cgi?s=990b908a189b85d08232fa3693e59bfa;act=ST;f=24;t=30;st=30;&#entry43

Особенно понравилось позиционирование г-на Буча как пророка-коммерсанта А сколько их сейчас, таких импортных кашпировских.

Эх, бросить бы все, да поехать в Питер, поучиться серьезно и систематически конечным автоматам!

Еще один комментарий ... ребята конечно подпрыгнули на патриотической волне, но у нас все заканчивается "научными отчетами" ... и в практику не идет. Индустрии им не сделать, как нашим не сваять "отечественный процессор" (про Эльбрус-2000 наслышаны уже все наверное ... и где он?) и "отечественную ОС" -- в лучшем случае на ядре Linux сваяют ... как немцы . Так что пиар НИИШной разработки, которая "ограниченно будет применяться группой единомышленников" ... вполне допускаю, что они смогут успешно решать свои задачи, вопрос в цене ...

Особенно понравилось позиционирование г-на Буча как пророка-коммерсанта А сколько их сейчас, таких импортных кашпировских.

Эх, бросить бы все, да поехать в Питер, поучиться серьезно и систематически конечным автоматам!

.. да, слышал я про автоматное порграмирование и про ЛИТМОшников ... один из них даже на SECR 2005 вырвался (http://secr.ru), и этими идеями одна дама из Цефея пыталась отпиарится ... -- все дружно посмеяслись, особенно над тем, как дама путает RUP и UML и требования и дизайн. К сожалению большинство из этих ребят довольно слабо представляют себе что такое UML, к сожалению они даже про OCL не слышали (и в своей статье почему-то не упоминают про него). А уж про использование юзкейсов -- так это вопиющая безграмотность в вопросе области применимости юзкейсов. Коберна например они даже не включили в список литературы ... Опять видим, что "Пастернака я не читал, но осуждаю" .
В сухом остатке -- любые методы имеют право на жизнь, в т.ч. и автоматное программирование может быть успешно применено для решения определенного класса задач (как и юзкейсы те же ...). Только разница в том, что Буч, Якобсон и прочия, не "наезжают" на другие языки и нотации моделирования ... а эти наезжают, причем не являсь общепризнанными экспертами в области UML ...
Что-то напоминает известную басню Крылова про Слона и Моську ... или попытку "схавать" бюджет нашего минобороны ...

P.S. Одинаково с опаской отношусь как западникам так и к словянофилам ... истина, как обычно, посередине. А кулибинство на Руси всегда было в почете ... .