Все говорят от семантическом разрыве, но не многие предлагают пути решения проблемы.
Далее цитата из курса "Визуальное моделирование: теория и практика"
Семантический разрыв визуальных моделей и программного кода
...визуальные модели, действительно удобные в работе, "склонны" терять исполняемую семантику. Другими словами, информация, которая в них содержится, оказывается недостаточно полной и детальной, чтобы по ней вычислитель мог бы выполнить свою работу. Ведь никакая "умная" генерация не может добавить то, что отсутствует изначально. Если же визуальные модели усложнять, чтобы они были пригодны для использования вычислителем, то очень часто они теряют наглядность и становятся бесполезными. Кому нужны непонятные, но полные описания программного обеспечения, выполненные с помощью визуальных моделей? Есть тексты на языках программирования, есть документы, есть возможность спросить, в конце концов, разобраться в коде самому…
Таким образом, существует семантический разрыв между визуальными моделями и программами... ...Этот разрыв препятствует автоматической генерации программного кода по визуальным моделям в общем случае, не позволяя визуальному моделированию стать следующим шагом в развитии средств программирования, вслед за алгоритмическими языками высокого уровня.
Где выход?
Неудача решения вопроса с генерацией "в общем виде" не говорит о том, что это невозможно в частных случаях. Необходимо лишь понизить степень общности ситуации. Это можно сделать, создавая кодогерационные решения для ПО отдельных видов. Генерация кода по визуальным моделям успешно применяется в промышленности в следующих областях:
* в разработке схем реляционных баз данных;
* при создании событийно-ориентированных систем реального времени;
* при формализации бизнес-процессов компаний.
Эти области и будут подробно рассмотрены в этом курсе лекций.
Можно также разрабатывать специальные языки визуального моделирования и программные средства их поддержки для больших проектов или групп проектов, создавая для них эффективные генерационные решения. Этот случай также будет рассмотрен в данном курсе.
...
конец цитаты
Есть очень занимательная статья о контекстной технологии программирования (1 и 2). Но она, ровным счетом, ничего не проясняет, хоть и выглядит как "решение всех наших проблем".
Можно лишь сделать вывод, что решение проблемы можно искать в:
* более высоком уровне абстракции языка, на котором ведется разработка;
* использование средств традиционных для проектирования представлений предметной области,но не на полную катушку, а частично.
Первое - нам не подходит, так как у нас с этим полный консенсус и никто язык менять не соберется. Второе - уже лучше, так как опыт показывает, что умл хорош на очень отдаленных от реализации стадиях, но потом, когда сложность диаграмм растет вместе с темпами их эволюции использовать умл становится просто не возможно.
Все это навеяло новую и очень необычную для меня мысль. А что если не пытаться заставить программистов следовать пусть даже 300 тысяч раз хорошей и академичной технологии программирования? Что если инструмент формализации предметной области, действительно, мог бы подстроиться под язык реализации?
Привыкшие быть ломателями стереотипов мышления неумытых программистов сами будут ломаться под новый инструмент. Прекрасно! Вот только я пока не знаю ничего про этот инструмент. И кстати, все это похоже на то, как сумасшедший разговаривает сам с собой. Усиленно что-то сам себе доказывает не получая ответа.
19 янв. 2008 г.
7 янв. 2008 г.
Serge Segal - Об авторском праве в двадцать первом веке
Serge Segal - Об авторском праве в двадцать первом веке - толковая статья. Опубликовать ссылку не жалко.
5 янв. 2008 г.
Разработка через тестирование
Читаю статью "Организация и именование автоматизированных тестов", Кирилл Максимов (http://www.maxkir.com/sd/testing.html).
4 янв. 2008 г.
Hitman
Только что посмотрел фильм hitman. В отвратительном (camrip) качестве с ужасным переводом. Но дело даже не в том, что качество плохое, а фильм - откровенное говно.
Дело в том, что я, как раз сейчас, играю в hitman contracts (3-ая часть hitman'а). Он (hitman) - совершенно не такой. Олефант не подходит на роль убийцы - у него есть характер, он эмоционален до жопы.
У персонажа куча не свойственных ему черт:
- он ходит, как будто наложил в штаны. Походка хитмена в играх - это отдельный разговор. То, как в 1-ой и 2-ой (silent assassin) частях игры выполнена пластика главного героя - пример для многих дизайнеров игр. Походка хитмена, как машины Джеймса Бонда - всегда самые лучшие и дорогие.
- он постоянно кого-то жалеет. С этой теткой ваще полный ппц. Видит её на улице и хватается за пушку... Ну ясно было б, если б он был героем фильма Гая Ричи, но он же hitman. Бесшумный и безжалостный убийца. Прежде всего хладнокровный.
- постоянно палИт во всех почем зря. Комментировать не буду - так ясно, что в церковь он бы не полез - свидетелей сотни.
Ощущений, что режиссер получил заказ: "рассказать всем, что быть безжалостным убийцей нельзя. Эмоции всеравно возьмут верх!".
Про русских в этом фильме вообще помолчим. Полная туфта. Создатели игры вроде таких оплошностей не допускали.
Мой вариант сценария, с учетом характера хитмена из игр:
Сцена первая: маленькому мальчику хитмену делают тату со штрих кодом. Только он не морщится как девченка, а спокойно с каменным лицом сидит и ждет конча процедуры. Скорее всего наколку делают вообще в бессознательном состоянии (особенность профессии).
Сцена вторая: хитмен не моется в душе, а, скажем, чистит винтовку. И уж конечно не гладит себя по штрих коду, вспоминая о своем нелегком детстве.
Сцена третья: хитман получает задание, только тетка в компьютере не орет на весь гостиничный номер, а просто пишет на экране.
Сцена четвертая: хитмен стреляет в Михаила Беликова. Один выстрел - один труп. Чемодан уносит с собой, чтоб не впалили.
Сцена пятая: хитмену говорят, что были свидетели, а он отвечает: "свидетелей не было. Точка! Если кому-то что-то не нравится - едте и мочите сами!"
Конец фильма. Занавес.
Дело в том, что я, как раз сейчас, играю в hitman contracts (3-ая часть hitman'а). Он (hitman) - совершенно не такой. Олефант не подходит на роль убийцы - у него есть характер, он эмоционален до жопы.
У персонажа куча не свойственных ему черт:
- он ходит, как будто наложил в штаны. Походка хитмена в играх - это отдельный разговор. То, как в 1-ой и 2-ой (silent assassin) частях игры выполнена пластика главного героя - пример для многих дизайнеров игр. Походка хитмена, как машины Джеймса Бонда - всегда самые лучшие и дорогие.
- он постоянно кого-то жалеет. С этой теткой ваще полный ппц. Видит её на улице и хватается за пушку... Ну ясно было б, если б он был героем фильма Гая Ричи, но он же hitman. Бесшумный и безжалостный убийца. Прежде всего хладнокровный.
- постоянно палИт во всех почем зря. Комментировать не буду - так ясно, что в церковь он бы не полез - свидетелей сотни.
Ощущений, что режиссер получил заказ: "рассказать всем, что быть безжалостным убийцей нельзя. Эмоции всеравно возьмут верх!".
Про русских в этом фильме вообще помолчим. Полная туфта. Создатели игры вроде таких оплошностей не допускали.
Мой вариант сценария, с учетом характера хитмена из игр:
Сцена первая: маленькому мальчику хитмену делают тату со штрих кодом. Только он не морщится как девченка, а спокойно с каменным лицом сидит и ждет конча процедуры. Скорее всего наколку делают вообще в бессознательном состоянии (особенность профессии).
Сцена вторая: хитмен не моется в душе, а, скажем, чистит винтовку. И уж конечно не гладит себя по штрих коду, вспоминая о своем нелегком детстве.
Сцена третья: хитман получает задание, только тетка в компьютере не орет на весь гостиничный номер, а просто пишет на экране.
Сцена четвертая: хитмен стреляет в Михаила Беликова. Один выстрел - один труп. Чемодан уносит с собой, чтоб не впалили.
Сцена пятая: хитмену говорят, что были свидетели, а он отвечает: "свидетелей не было. Точка! Если кому-то что-то не нравится - едте и мочите сами!"
Конец фильма. Занавес.
MDE
Ну ооочень интересная статья http://citforum.ncstu.ru/computer/2006-02/.
Автор уже и так цитирует кого-то, так что ниче страшного, что я процитирую его:
...
В последние двадцать лет достижения в области языков программирования и платформ привели к повышению уровня абстракций, доступных для разработчиков, смягчив один из недостатков подхода CASE. Например, сегодня разработчики обычно используют более выразительные объектно-ориентированные языки (в частности, C++, Java и C#), а не Fortran или C. Повторно используемые библиотеки классов и платформы поддержки приложений минимизируют потребность в изобретении общих и прикладных сервисов - транзакций, отказоустойчивости, оповещения о событиях, безопасности, распределенного управления ресурсами и т.д. Все это позволяет разработчикам лучше защититься от сложности, связанной с созданием приложений на основе традиционных технологий.
Несмотря на эти достижения, остается несколько неприятных проблем. В центре этих проблем лежит сложность платформ, которая растет быстрее способности языков общего назначения маскировать ее. Например, популярные платформы промежуточного программного обеспечения J2EE, .NET и CORBA содержат тысячи классов и методов со многими сложными зависимостями и тонкими побочными эффектами, что требует значительных усилий при программировании и тщательной настройки. Более того, поскольку эти платформы быстро развиваются (а также регулярно возникают новые платформы), разработчики тратят много сил на портирование кода приложений на различные платформы или обновленные версии существующих платформ.
Родственная проблема состоит в том, что код большинства приложений и платформ по-прежнему пишется на языках третьего поколения, для чего требуется много времени и усилий, в особенности для выполнения интеграционных действий - развертывание, конфигурирование и поддержка качества системы. Например, на Java или C# трудно написать код, корректно и оптимально развертывающий крупномасштабные распределенные системы с сотнями тысяч взаимосвязанных компонентов.
Ситуацию не спасает даже использование описаний развертывания на языке XML, используемых в компонентных и сервис-ориентированных платформах промежуточного программного обеспечения, поскольку в этом случае имеется семантический разрыв между целью разработки и выражением этой цели в тысячах строк вручную произведенного XML, синтаксис которого не имеет отношения ни к семантике прикладной области, ни к цели разработки. Из-за наличия этих проблем индустрия программного обеспечения приближается к предельно допустимой сложности.
В то же время платформенные технологии нового поколения, например, Web-сервисы и архитектуры продуктовых линий (product-line architecture) становятся настолько сложными, что годами овладевают платформенными API и паттернами использования и при этом часто оказываются знакомыми только с частью возможностей регулярно используемой ими платформы. Более того, при использовании языков третьего поколения разработчики вынуждаются уделять настолько большое внимание тактическим деталям императивного программирования, что они часто не могут концентрироваться на стратегических архитектурных проблемах, таких как корректность системы в целом и ее производительность. Такие фрагментированные представления проекта в целом затрудняют разработчикам понимание того, какие части их приложений являются чувствительными к побочным эффектам, возникающим при изменении требований заказчиков и/или среды разработки. Часто это вынуждает разработчиков производить неоптимальные решения, в которых дублируются части кода, нарушаются ключевые архитектурные принципы, усложняется развитие системы и обеспечение требуемого качества.
Многообещающим подходом, направленным на решение этих проблем, является разработка технологий инженерии, управляемой моделями, (Model-Driven Engineering, MDE). При использовании MDE разработка ведется на предметно-ориентированных языках моделирования (Domain-Specific Modeling Language, DSML), в системах типов которых формализуется структура, поведения и требования приложения внутри соответствующей предметной области. DSML описываются с использованием метамоделей, в которых определяются связи между понятиями предметной области и точно специфицируется основная семантика и ограничения, ассоциируемые с этими понятиями. Разработчики применяют DSML для построения приложений, используя элементы системы типов, зафиксированной в метамодели, и выражают проектный замысел в декларативном, а не императивном стиле.
Важнейшими компонентами MDE являются трансформационные процессоры и генераторы, которые анализируют определенные аспекты моделей и синтезируют разные вида артефактов: исходный код, входные данные для имитационного моделирования, XML-описания развертывания или альтернативные представления моделей. Возможность синтеза артефактов на основе моделей помогает поддерживать согласованность между реализациями приложения и аналитической информацией о требованиях к функциональных возможностям системы и ее качества, зафиксированных в модели. Этот автоматический трансформационный процесс часто называют "правильным по построению" ("correct-by-construction") в отличие от утомительного и чреватого ошибками традиционного процесса разработки программного обеспечения вручную в стиле "построения путем коррекции" ("construct-by-correction").
...
Автор уже и так цитирует кого-то, так что ниче страшного, что я процитирую его:
...
В последние двадцать лет достижения в области языков программирования и платформ привели к повышению уровня абстракций, доступных для разработчиков, смягчив один из недостатков подхода CASE. Например, сегодня разработчики обычно используют более выразительные объектно-ориентированные языки (в частности, C++, Java и C#), а не Fortran или C. Повторно используемые библиотеки классов и платформы поддержки приложений минимизируют потребность в изобретении общих и прикладных сервисов - транзакций, отказоустойчивости, оповещения о событиях, безопасности, распределенного управления ресурсами и т.д. Все это позволяет разработчикам лучше защититься от сложности, связанной с созданием приложений на основе традиционных технологий.
Несмотря на эти достижения, остается несколько неприятных проблем. В центре этих проблем лежит сложность платформ, которая растет быстрее способности языков общего назначения маскировать ее. Например, популярные платформы промежуточного программного обеспечения J2EE, .NET и CORBA содержат тысячи классов и методов со многими сложными зависимостями и тонкими побочными эффектами, что требует значительных усилий при программировании и тщательной настройки. Более того, поскольку эти платформы быстро развиваются (а также регулярно возникают новые платформы), разработчики тратят много сил на портирование кода приложений на различные платформы или обновленные версии существующих платформ.
Родственная проблема состоит в том, что код большинства приложений и платформ по-прежнему пишется на языках третьего поколения, для чего требуется много времени и усилий, в особенности для выполнения интеграционных действий - развертывание, конфигурирование и поддержка качества системы. Например, на Java или C# трудно написать код, корректно и оптимально развертывающий крупномасштабные распределенные системы с сотнями тысяч взаимосвязанных компонентов.
Ситуацию не спасает даже использование описаний развертывания на языке XML, используемых в компонентных и сервис-ориентированных платформах промежуточного программного обеспечения, поскольку в этом случае имеется семантический разрыв между целью разработки и выражением этой цели в тысячах строк вручную произведенного XML, синтаксис которого не имеет отношения ни к семантике прикладной области, ни к цели разработки. Из-за наличия этих проблем индустрия программного обеспечения приближается к предельно допустимой сложности.
В то же время платформенные технологии нового поколения, например, Web-сервисы и архитектуры продуктовых линий (product-line architecture) становятся настолько сложными, что годами овладевают платформенными API и паттернами использования и при этом часто оказываются знакомыми только с частью возможностей регулярно используемой ими платформы. Более того, при использовании языков третьего поколения разработчики вынуждаются уделять настолько большое внимание тактическим деталям императивного программирования, что они часто не могут концентрироваться на стратегических архитектурных проблемах, таких как корректность системы в целом и ее производительность. Такие фрагментированные представления проекта в целом затрудняют разработчикам понимание того, какие части их приложений являются чувствительными к побочным эффектам, возникающим при изменении требований заказчиков и/или среды разработки. Часто это вынуждает разработчиков производить неоптимальные решения, в которых дублируются части кода, нарушаются ключевые архитектурные принципы, усложняется развитие системы и обеспечение требуемого качества.
Многообещающим подходом, направленным на решение этих проблем, является разработка технологий инженерии, управляемой моделями, (Model-Driven Engineering, MDE). При использовании MDE разработка ведется на предметно-ориентированных языках моделирования (Domain-Specific Modeling Language, DSML), в системах типов которых формализуется структура, поведения и требования приложения внутри соответствующей предметной области. DSML описываются с использованием метамоделей, в которых определяются связи между понятиями предметной области и точно специфицируется основная семантика и ограничения, ассоциируемые с этими понятиями. Разработчики применяют DSML для построения приложений, используя элементы системы типов, зафиксированной в метамодели, и выражают проектный замысел в декларативном, а не императивном стиле.
Важнейшими компонентами MDE являются трансформационные процессоры и генераторы, которые анализируют определенные аспекты моделей и синтезируют разные вида артефактов: исходный код, входные данные для имитационного моделирования, XML-описания развертывания или альтернативные представления моделей. Возможность синтеза артефактов на основе моделей помогает поддерживать согласованность между реализациями приложения и аналитической информацией о требованиях к функциональных возможностям системы и ее качества, зафиксированных в модели. Этот автоматический трансформационный процесс часто называют "правильным по построению" ("correct-by-construction") в отличие от утомительного и чреватого ошибками традиционного процесса разработки программного обеспечения вручную в стиле "построения путем коррекции" ("construct-by-correction").
...
6 дек. 2007 г.
CyberSecurity.ru | Программирование | Microsoft | Microsoft представила нову�
CyberSecurity.ru | Программирование | Microsoft | Microsoft представила новую среду для веб-разработки Volta
Если коротко, в статье рассказывается он новой среде разработки для создания распределенных приложений в сетевой среде.
Леша Паньшин часто шутит, что гугл через свои javascript'ы выполняет распределенные вычисления на машинах клиентов... Для параноиков и дебилов новый повод покричать про вселенское зло.
Если коротко, в статье рассказывается он новой среде разработки для создания распределенных приложений в сетевой среде.
Леша Паньшин часто шутит, что гугл через свои javascript'ы выполняет распределенные вычисления на машинах клиентов... Для параноиков и дебилов новый повод покричать про вселенское зло.
5 дек. 2007 г.
Яндекс роется в грязном белье!
Нет я не любитель громких заголовков. Цель этого миниопуса отнюдь не привлечь внимание к моему блогу. Просто я глубоко возмущен! Единственно, что останавливает меня от излияния своих мыслей прямо в коментах записи этого самого блога (Яндекс: Паспорт) - отсутствие желания вспоминать свой пароль от яндекс паспорта.
Ну Вы и сами посудите, друг робота Максим Петров и компания Яндекс прочитала не менее 15 тысяч писем своих пользователей и не стесняется об этом открыто говорить.
Представьте себе сейчас до революционную Россию. Какое-нибудь село. Помещик там, какой-нить. Пара богатых семей и др. и пр. Светский ужин. Почтмейстер попивая чай рассказывает собравшимся на каком-нибудь званном ужине: "Вы знаете, презабавнейшее дельце. Писать стали реже про любовь. Все больше про деньги". Чтоб с таким почтмейстером было? Яйца б ему оторвали!
И ещё говорят, что гугль захватит мир! Враки!
Ну Вы и сами посудите, друг робота Максим Петров и компания Яндекс прочитала не менее 15 тысяч писем своих пользователей и не стесняется об этом открыто говорить.
Представьте себе сейчас до революционную Россию. Какое-нибудь село. Помещик там, какой-нить. Пара богатых семей и др. и пр. Светский ужин. Почтмейстер попивая чай рассказывает собравшимся на каком-нибудь званном ужине: "Вы знаете, презабавнейшее дельце. Писать стали реже про любовь. Все больше про деньги". Чтоб с таким почтмейстером было? Яйца б ему оторвали!
И ещё говорят, что гугль захватит мир! Враки!
Подписаться на:
Сообщения (Atom)