пятница, 19 апреля 2013 г.

Ещё немного про UML

Атлас "машин и механизмов" или "номенклатура микросхем" - это то направление в котором по-моему стоит двигаться говоря об "идеальном" применении 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 лучше "компонент" на языке программирования" - я вам отвечу. Тем что "микросхемы" можно внедрять в код класса и параметризовывать на этапе кодогенерации, а не на этапе компиляции.

1 комментарий:

  1. Вот написали - "Меня этому ещё в МВТУ учили. А потом как могли выбивали в МИТе и на производстве на первых порах :))))
    Собственно, прочитал первую ссылку с ОГРОМНЫМ удовольствием. Для себя сделал вывод, что речь идёт о ГОСТировании алгоритмов типовых программных продуктов."

    ОтветитьУдалить