Атлас "машин и механизмов" или "номенклатура микросхем" - это то направление в котором по-моему стоит двигаться говоря об "идеальном" применении UML или графических нотаций вообще.
На UML не надо "программировать". На нём надо конструировать.
Из "готовых типовых решений".
Не просто "квадрат на модели", а "микросхема со входами и выходами. Раскрашенными в разные цвета.
И одноцветные входы можно соединить только с одноцветными выходами.
А внутри "микросхемы" - упаковано проектное решение. Например - "шаблон от GoF".
Или скажем - нужен классу "подсчёт ссылок". Берём "микросхему" и внедряем её внутрь класса. На UML. И в результате кодогенерации получаем что класс реализует подсчёт ссылок. (Вот тут кстати написано про реализацию - http://18delphi.blogspot.com/2013/04/iunknown.html).
Нужно чтобы класс реализовывал печать или логирование - берём нужную микросхему и внедряем её в нужный класс и подключаем выходы/входы класса (например абстракные методы) к входам/выходам микросхемы.
Нужно копирование в клипборд - берём нужную "микросхему" и внедряем её в проектный класс. Благо IDataObject - уже давным давно расписан. Осталось только взять его реализацию и "подключить" к нужным разъёмам проектируемого класса.
Нужна сериализация/десериализация - берём нужные "микросхемы" и внедряем их в проектный класс. Микросхема обеспечивает всю суть сериализации, а проектный класс - обеспечивает её нужными деталями. Подключаясь к разъёмам. А с другой стороны - подключаем эту микросхему к другим, например которые работают с БД или XML.
Нужен шаблон publisher/subscriber - берём "микросхему" publisher и внедряем её в один класс, берём "микросхему" subscriber и внедряем её в другой класс. Если надо и возможно - сразу соединяем входы/выходы между ними на модели. (Не всегда это возможно иногда это можно сделать уже только в коде)
Такая идея "повторного использования кода", но не на уровне кода, а на уровне моделей UML.
Идея понятна?
Я в скором времени постараюсь развить эту мысль. И пописать, что я думаю об этом и о том, что УЖЕ сделано.
При этом если пытаться стандартизовать ТЗ и сбор требований и отображать их на эти "микросхемы", то проектные решения хорошо лягут уже в ТЗ.
Ну как если проектируют телевизор. Там же не разрабатывают всё с нуля. Берут каскад такой. Каскад такой. Матрицу такую-то. Усилитель - такой-то. Блок питания - такой-то. Ну и немного новых проектных решений.
Давно по-моему пора переносить технические решения реальных инженерных специальностей на программный код. А не программировать "на-коленке".
Ну по-моему ничего нового я конечно не придумал. АлексадЕр по-моему писал уже про это.
Но я плотно работаю над реализацией всего описанного. Есть вопросы конечно. Дьявол - он в деталях. Но что-то - уже реализовано. Я со временем расскажу что и как.
Эти "микросхемы" на самом деле на уровне кода и есть - "примеси" (http://18delphi.blogspot.com/2013/03/blog-post_29.html). Или на уровне ТЗ - это - "аспекты" (http://18delphi.blogspot.com/2013/03/blog-post_5596.html) поведения системы.
И главное что? Берём триггеры - объединяем их - получаем микросхемы - объединяем их - получаем БИС - берём их, объединяем - получаем контроллер или материнскую плату. И таким образом - конструируем. Главное, что мы можем перемещаться с уровня на уровень и заменять одни компоненты другими.
Я для себя вообще трактую UML как "матрёшку". Одно вкладывается в другое. Мы можем посмотреть на уровень библиотек, а можем на уровень пакетов, а можем на уровень классов, а можем на уровень "микросхем" или "триггеров".
У меня есть РАБОТАЮЩИЕ примеры этого хозяйства. Но чтобы их опубликовать - надо проделать достаточно хорошую работу, чтобы вычленить компилируемый пример и набор замкнутых UML-Диаграмм образующих полное множество. Но я это сделаю. Даю вам зуб.
Также у меня есть примеры того как "стандартные аспекты ТЗ" транслируются в "стандартные проектные решения". Это я тоже постараюсь показать.
Главные слова - "микросхема" и "матрёшка".
Может быть вы подумаете и разовьёте эти идеи не дожидаясь моих примеров. Было бы интересно на это посмотреть.
И мне кстати для развития идей не хватает существующих возможностей UML-редакторов. Они заточены на "классический" UML, а не на "матрёшку" и "разъемы". Хочется уже взять какой-нибудь Star-UML и доработать. Или написать свой. Чтобы "матрёшка" и разъёмы. И "бесконечное" число вложенных друг в друга уровней.
Аналогию приведу - STL - это набор "микросхем". На уровне кода. Хочется делать такие же "микросхемы" на уровне UML.
О! "Компонентная разработка" для UML. Не на языке, а в графической нотации.
Visual Live Binding от Embarcadero кстати - робкий шаг в этом направлении. Если я его правильно трактую. Там конечно всё на "микро"-уровне, но по-моему это легко можно поднять на "макро".
Если вы меня спросите - "чем "микросхемы" на UML лучше "компонент" на языке программирования" - я вам отвечу. Тем что "микросхемы" можно внедрять в код класса и параметризовывать на этапе кодогенерации, а не на этапе компиляции.
На UML не надо "программировать". На нём надо конструировать.
Из "готовых типовых решений".
Не просто "квадрат на модели", а "микросхема со входами и выходами. Раскрашенными в разные цвета.
И одноцветные входы можно соединить только с одноцветными выходами.
А внутри "микросхемы" - упаковано проектное решение. Например - "шаблон от GoF".
Или скажем - нужен классу "подсчёт ссылок". Берём "микросхему" и внедряем её внутрь класса. На UML. И в результате кодогенерации получаем что класс реализует подсчёт ссылок. (Вот тут кстати написано про реализацию - http://18delphi.blogspot.com/2013/04/iunknown.html).
Нужно чтобы класс реализовывал печать или логирование - берём нужную микросхему и внедряем её в нужный класс и подключаем выходы/входы класса (например абстракные методы) к входам/выходам микросхемы.
Нужно копирование в клипборд - берём нужную "микросхему" и внедряем её в проектный класс. Благо IDataObject - уже давным давно расписан. Осталось только взять его реализацию и "подключить" к нужным разъёмам проектируемого класса.
Нужна сериализация/десериализация - берём нужные "микросхемы" и внедряем их в проектный класс. Микросхема обеспечивает всю суть сериализации, а проектный класс - обеспечивает её нужными деталями. Подключаясь к разъёмам. А с другой стороны - подключаем эту микросхему к другим, например которые работают с БД или XML.
Нужен шаблон publisher/subscriber - берём "микросхему" publisher и внедряем её в один класс, берём "микросхему" subscriber и внедряем её в другой класс. Если надо и возможно - сразу соединяем входы/выходы между ними на модели. (Не всегда это возможно иногда это можно сделать уже только в коде)
Такая идея "повторного использования кода", но не на уровне кода, а на уровне моделей UML.
Идея понятна?
Я в скором времени постараюсь развить эту мысль. И пописать, что я думаю об этом и о том, что УЖЕ сделано.
При этом если пытаться стандартизовать ТЗ и сбор требований и отображать их на эти "микросхемы", то проектные решения хорошо лягут уже в ТЗ.
Ну как если проектируют телевизор. Там же не разрабатывают всё с нуля. Берут каскад такой. Каскад такой. Матрицу такую-то. Усилитель - такой-то. Блок питания - такой-то. Ну и немного новых проектных решений.
Давно по-моему пора переносить технические решения реальных инженерных специальностей на программный код. А не программировать "на-коленке".
Ну по-моему ничего нового я конечно не придумал. АлексадЕр по-моему писал уже про это.
Но я плотно работаю над реализацией всего описанного. Есть вопросы конечно. Дьявол - он в деталях. Но что-то - уже реализовано. Я со временем расскажу что и как.
Эти "микросхемы" на самом деле на уровне кода и есть - "примеси" (http://18delphi.blogspot.com/2013/03/blog-post_29.html). Или на уровне ТЗ - это - "аспекты" (http://18delphi.blogspot.com/2013/03/blog-post_5596.html) поведения системы.
И главное что? Берём триггеры - объединяем их - получаем микросхемы - объединяем их - получаем БИС - берём их, объединяем - получаем контроллер или материнскую плату. И таким образом - конструируем. Главное, что мы можем перемещаться с уровня на уровень и заменять одни компоненты другими.
Я для себя вообще трактую UML как "матрёшку". Одно вкладывается в другое. Мы можем посмотреть на уровень библиотек, а можем на уровень пакетов, а можем на уровень классов, а можем на уровень "микросхем" или "триггеров".
У меня есть РАБОТАЮЩИЕ примеры этого хозяйства. Но чтобы их опубликовать - надо проделать достаточно хорошую работу, чтобы вычленить компилируемый пример и набор замкнутых UML-Диаграмм образующих полное множество. Но я это сделаю. Даю вам зуб.
Также у меня есть примеры того как "стандартные аспекты ТЗ" транслируются в "стандартные проектные решения". Это я тоже постараюсь показать.
Главные слова - "микросхема" и "матрёшка".
Может быть вы подумаете и разовьёте эти идеи не дожидаясь моих примеров. Было бы интересно на это посмотреть.
И мне кстати для развития идей не хватает существующих возможностей UML-редакторов. Они заточены на "классический" UML, а не на "матрёшку" и "разъемы". Хочется уже взять какой-нибудь Star-UML и доработать. Или написать свой. Чтобы "матрёшка" и разъёмы. И "бесконечное" число вложенных друг в друга уровней.
Аналогию приведу - STL - это набор "микросхем". На уровне кода. Хочется делать такие же "микросхемы" на уровне UML.
О! "Компонентная разработка" для UML. Не на языке, а в графической нотации.
Visual Live Binding от Embarcadero кстати - робкий шаг в этом направлении. Если я его правильно трактую. Там конечно всё на "микро"-уровне, но по-моему это легко можно поднять на "макро".
Если вы меня спросите - "чем "микросхемы" на UML лучше "компонент" на языке программирования" - я вам отвечу. Тем что "микросхемы" можно внедрять в код класса и параметризовывать на этапе кодогенерации, а не на этапе компиляции.
Вот написали - "Меня этому ещё в МВТУ учили. А потом как могли выбивали в МИТе и на производстве на первых порах :))))
ОтветитьУдалитьСобственно, прочитал первую ссылку с ОГРОМНЫМ удовольствием. Для себя сделал вывод, что речь идёт о ГОСТировании алгоритмов типовых программных продуктов."