UML в качестве редактора универсального браузера(Прочитано 23063 раз)
всем доброго времени суток!

хотелось бы оценить шансы проекта...
тянуть ли его дальше...

несколько лет назад начал проект 3-х звенки, основной смысл заключается в том, что клиентское приложение понятия не имеет о структуре базы, с которой работает. Если точнее, то получает описание модели данных из базы, которая лежит рядом с сервером приложений, в которой прописаны тексты селектов к подключаемой базе.
Это попытка разрешить конфликт между технологиями - объектно-ориентированным клиентским приложением и реляционными базами данных.
На уровне опытного образца решение уже есть, клиент получает датасеты, редактирует их и отправляет на сохранение.
Т.к. я сам себе заказчик и моя основная задача построение системы подготовки сделки с элементами экспертной системы, то функциональность клиентского приложения меня устраивает. Но захотелось дать "автономную жизнь" проекту.
Я попытался свести логику клиентского приложения таким образом, чтобы его поведение определялось БЕЗ ПРОГРАММИРОВАНИЯ, только на основе анализа модели, которая хранится в базе данных сервера приложений.
Но мои интеллектуальные возможности значительно ограниченны... :)
Хотел спросить знатоков, может подобные решения уже существуют, и я изобретаю велосипед ?
« Последнее редактирование: 20 Мая 2009, 09:08:58 от Evgeny_Nsk »



1. Bold for Delphi
2. ECO for C тоже от CodeGear
3. Развитие технологии fast-base
4. Есть образцы и для других технологий и языков



по Bold for Delphi читал книгу года 4 назад
многое из неё понравилось, сама идея MDA впечатлила.
но моим ощущениям - это не совсем то, о чем я попытался написать.
Bold for Delphi - это инструмент для построения монолитного приложения, очень сильно завязанное на конкретную базу данных. в моем случае речь идет об опытном образце, которое работает в 2-х совершенно различных компаниях, одно занимается поставкой электронных компонентов, а другое занимается IP-телефонией.
у этих приложений общего только базовая технология получения и обработки датасетов с сервера приложений
TCP-клиент обращается к TCP-серверу, тот в свою очередь подключается к приписанным в его настройкам базам данных, формирует и отправляет клиенту датасет.
можно привести некую аналогию между веб-сервером и интернет-браузером, браузер понятия не имеет, какая структура у базы, с которой он работает. Только в отличии от интернет-браузера опытный образец получает данные от сервера не в виде html, а в виде ClientDataSet-a, базовая технология работы с датасетом  в него уже вшита, хочется управлять размещением и взаимодействием датасетов в клиентском приложении с помощью UML



Вам надо поговорить с Тагиром Юмагузиным (yumata). Он Вам все скажет :)



Эдуард, однако спасибо за ссылочку!

3. Развитие технологии fast-base
по смыслу очень близко к тому, что я делаю.

во вкладке описание, которое я готовил для одного из венчурных фондов.
полагаю, что как и по другому моему проекту, интерес к этому появится года через 3-4 после появления опытного образца. :)




читаю доки с fast-base...
однако я не одинок в идеях... :)

кстати мне не совсем понятно, почему так мало внимания уделено проекту fast-base на форуме ?

по логике вещей это первое доступное описание нового подхода в автоматизации бизнес-процессов,
при котором требуется наличие 2-х человек со стороны заказчика - бизнес-аналитика и DBA



Евгений. Тагир пишет все один, на свой страх и совесть. Работал последние четыре года как вол. Без отдыху и перерывов. Ну есть ли у него время поддерживать ресурс. Попробуйте связаться с ним  предложить свои услуги?



я не про информацию на http://www.fast-base.ru/
я про информацию на этом форуме... :)
в России так катастрофически не хватает внимания соотечественников к интересным начинаниям.



я не про информацию на http://www.fast-base.ru/
я про информацию на этом форуме... :)
в России так катастрофически не хватает внимания соотечественников к интересным начинаниям.
Боюсь, что у активистов сообщества несколько другие интересы.

Мне, конечно, эта тема интересна. Но мало времени. Попробуйте расшатать ситуацию?



а как не хватает соотечественников, готовых поучаствовать в интересных начинаниях чем-либо еще, кроме своего внимания... знали бы вы.
однако после таких слов, как честный мужчина, я обязан как минимум создать на основе fast-base тестовое приложение... :)



Сам являюсь таким "ленивым соотечественником". Поэтому задаю вопросы:

1) Чем не устраивает MS Access с его мастером форм? Сначала тщательно описываете таблицы, а затем - практически одной кнопкой генерируете для них формы. Согласен, сама MS Access поддерживает MDA/MDD только на базе своих ER-диаграмм, весьма своеобразных. Но никто не мешает использовать для генерации БД другие инструменты. В том же Sybase Power Designer можно через цепочку последовательных преобразований дойти до SQL от "UML Class".

Если не устраивает тем, что M$ и проприетарщина - так есть и FOSS фреймворки с похожей функциональностью.

2) На самом деле, есть языки, на которые ближе к описанию правил, по которым ведётся бизнес. См. BPMN/BPEL, ARIS, IDEF0. Не хочется сделать BPMS?

3) Насколько я понял, Вы хотите автоматизировать и исключить (полностью!) работу программиста. Ну допустим, в Ваше приложение пришло такое "ТЗ" полностью на UML (см. прикреплённые файлы). Неполное, не везде корректное. В таком случае приложение начинает задавать вопросы: уточните то, уточните это, укажите типы данных, а какие состояния относятся к каким документам, а какого типа формы кому показывать и т.д. В результате надо наполнить модель деталями, комментариями и конкретикой настолько, что... IMHO проще и удобнее будет описать всё то же самое на языках программирования. И даже выучить по такому случаю эти языки.

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

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

Хотя, конечно, уже почти 10 лет как 21-й век на дворе. Давно пора перестать переливать интеллектуальную работу туда-сюда и делать её неотделимой от рутины, а написать действительно искусственный интеллект, который возьмёт на себя всю рутину и как минимум часть интеллектуальной работы.



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



однако после таких слов, как честный мужчина, я обязан как минимум создать на основе fast-base тестовое приложение... :)
Евгений, давай-те. Это будет интересно. А то пока только теория от Тагира, что это круто и быстро. А как оно на практике. К сожалению Тагир так занят, что у него нет времени на примеры разного плана. Можно ему помочь. Я пытался, правда, но... никак не удается разорваться, а так хочется :)



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



от себя могу сказать, что в начале девяностых (боже как давно и недавно всё это было) участвовал в разработке подобной системы (описанной в исходном посте), и более того "система" у нас была готовая и работающая, что несколько отличается от термина "прототип", а в кавычках потому как не внедренная - так уж получилось...
тогда правда технологии были другие, сейчас многое можно даже назвать смешным, но как минимум уровни базы данных, обработки и презентейшн левел были разделены. Если говорить кратко, то уровни БД и интерфейса были проработаны до состояния компонентов. Оставалось "запроектировать" уровень обработки, т.е. решить нужную задачу в терминах предметной области. По сути в основе лежала формализованная модель, корректность которой проверялась стандартным компилятором. Фактически, при этом программирование переводилось с системного на прикладной уровень - не надо было программировать БД и уровень представления, достаточно было корректно определить объекты предметной области и их связи, и засунуть полученное описание (она же модель) в обработчик. А от задания их поведения куда ж денешься?

Сама система планировалась для автоматизации банковской деятельности и была реализована менее чем за 1 месяц (прикладная часть разумеется). Базовый софт потребовал где-то до 6 месяцев (за счет использования интерфейсных наработок ТурбоВижн), при практически готовой постановке. Команда была 4 человека, из них 2 прикладника, да два программиста.
Переносимостью особой, правда, эта штука не обладала, но используемый подход, кстати, позволил относительно просто мигрировать на платформу windows (ибо интерфейс был событийно управляемый и использовал близкие к стандартным компоненты), что для дос-приложений было невсегда просто. А чем дальше, тем больше появлялось программ и систем, использующих какие-то из воплощенных нами принципов. По состоянию на сейчас дело, ясное дело, заглохло.

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

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

Так к чему это я?
1) Не надо изобретать велосипед. Многое уже придумано и реализовано. Хотя...
2) Нужно хорошо прорабатывать интерфейсы (есть даже такие специальные слова: SOAP и иже с ними)
3) Нужно по максимуму использовать стандартные, т.е. готовые компоненты.
4) Уровень программирования (в том или другом виде) никуда не девается, но может видоизменяться и сильно упрощаться. При этом желательно добавление специализации в предметной области

А вообще нужно в первую очередь решать задачу и не увлекаться чрезмерно созданием инструмента (если конечно не он сам является продуктом.

P.S. Про фастбейс ничего сказать не могу, но с задачей генерации кода сталкивался неоднократно. Без напильника там не обойтись, взять тот же дельфи. А ввод значений в окошки свойств по сути мало отличается от текстового редактора, но это уже лирика
Лью воду...




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19