ППМП - Термины и определения, сокращения и обозначения

Сокращения и обозначения

ИДФ - источник данных формы
ИДС - источник данных сборки
МО - менеджер операций
МР - менеджер ресурсов
ОФ - операция формы
ППМП - платформа для создания пользовательских многооконных приложений
ФСФ - фабрика сборки форм
СФ - сборка форма

Термины и определения

Платформа

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

Диспетчер форм

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

Менеджер ресурсов

Глобальный ресурс, который содержит доступ к общим ресурсам приложения. По сути является нормативно-справочной информацией приложения, которая используется различными компонентами.

Менеджер меню

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

Операция формы

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

Сборка форм

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

Фабрика сборки форм

Описывает совокупность форм (которые могут быть вложены друг в друга) и зоны их размещения. ФСФ предназначена для описания и инициализации данными как саму сборку, так и формы входящие в состав сборки. При редактировании ФСФ в "режиме разработки" пользователю доступны для выбора формы зарегистрированные в МР.

Источник данных формы

Предназначен для получения данных, которые должны быть отображены на форме и записи данных при их изменении. ИДФ устанавливается форме при создании СФ. ИДФ позволяет изолировать форму от знания о местонахождении данных.

Источник данных сборки

Содержит данные являющиеся общими для сборки форм. ИДС доступен для получения каждой форме сборки. ИДС устанавливается форме при создании СФ.

Offtopic. Про меня один "чудак" рассказал.. Не совсем жизненно. Но "почти"правду

http://www.mountain.ru/article/article_display1.php?article_id=4534

Заметки про наш кодогенератор. Надеюсь - Макс - будет НЕ против

Отдельно про "собственный кодогенератор".

1. Он скорее "декларативный" нежели "императивный".
2. Построен на "продвинутых regexp". Очень продвинутых. С включениями
"императивного кода".
3. Использует понятие user-section. Это места в "скелете кода" куда
программист "вписывает логику" не описанную на модели.
4. Базируется на понятии <<стереотипа>>. Стереотип это - "единица
генерации". SimpleClass, Enum, Form, Project, Library, Algorythm etc. И
каждый стереотип может генерировать "свой код".  И в СВОЙ файл - если нужно.
5. Экземпляры <<стереотипов>> нарисованные программистом могут
"предварительно генерировать" ДРУГИЕ стереотипы. Например <<property>>
от <<SimpleClass>> могут генерировать <<method>> (методы доступа к
свойству). Или <<LocalizeableConst>> генерирует <<Const>> И массу
других. Уже без вмешательства "пользователя". А потом вся эта
конструкция генерируется в целевой язык.
6. Настраивается на практически любой "текстовый язык".

P.S. многие решения настолько "банальны", что мне иногда хочется
поверить в "теорию заговора". Что "киты" типа  MS или IBM - сознательно
не публикуют своих разработок в плане UML. Потому, что я иногда не
понимаю - "как мои коллеги до этого додумались", а "киты" - нет. Просто
не верится в это.

7. ОТДЕЛЬНО умеет генерировать в wiki-подобную базу знаний. Это скажем
так - отдельный "целевой язык" кодогенерации.
8. С элементами кода в этой базе умеют связываться
требования/задачи/ошибки. "Сверху". А также - изменения кода - "снизу".
Взяв отдельно взятый "элемент кода" (экземпляр <<стереотипа>>). Мы
"сверху" можем видеть - "какие запросы его меняли", а "снизу" - можем
видеть - "какие строчки кода менялись в результате этих запросов".

P.P.S. Я в его написании - участия не принимал. Я только шаблоны
кодогенерации потом писал. 

Зачем UML

http://blogs.embarcadero.com/vsevolodleonov/2013/08/02/whyumlru/

http://habrahabr.ru/post/188604/
-- там "ввязываться в драку" - не собираюсь. Если есть вопросы - задавайте тут. Или - лично.

P.S. Зря по-моему Леонов там резко высказывается :-( :-(

P.P.S. http://blogs.embarcadero.com/vsevolodleonov/2013/08/12/why-uml-for-delphi-users/

Процитирую Леонова "о водопадной модели". Потому, что я с этим - согласен

"Кстати, «водопадную» модель реально нужно обсуждать.
У меня было есть достаточно опыта: работа на гос. структуры по гос. контракту. 
Есть «классическое» ТЗ, которое бьется на этапы. Нет, вам вполне позволят написать первым этапом (1-2-3-4 месяца) что угодно. Хоть «сбор и анализ требований», хоть «UML-моделирование», хоть «подготовка первого спринта». Но второй этап уже не должен содержать того, что уже упоминалось в первом этапе. Куратор проекта со стороны заказчика вас будет курировать по ТЗ (которое, опять же — вы сами себе написали, но в жанре «водопадного ТЗ»). Выходов из такой ситуации несколько:
— сказать, что заказчик = дурак, требует невозможного, так программисты не работают и уйти с гордо поднятой головой (пустыми карманами);
— прогнуться под заказчика, сказав — «ок, водопад? будет тебе Ниагара»!!!
— проевангелировать заказчика, скажем, «аджайлом», оставить ТЗ в качестве формальности, но работать «гибко».

Я попробовал второй и третий пункт. Надо сказать, второй ВСЕГДА лучше для такого рода проектов. Третий пункт был весел в течение всего срока работы над проектом, но «приёмка» это вам не «куратор». Лучше или хуже — роли не играет. Надо «как положено». 
Так что «водопад» не есть «зло», а «аджайл» не есть добро. А друг тебе тот, кто деньги платит.

Опять же — «кобол» не равно «водопад». «Водопад» не значит «устарел». Водопад означает «комфортные условия взаимодействия „заказчик-исполнитель“ -да! иногда в ущерб качеству/количеству функционала, потенциально-возможному.

Ну и на закуску бойкому молодняку (который, Максим, и дискет в руках не держал — удачная шутка? а?). 
Альтернативы „водопадной“ модели были предложены отнюдь не айтишниками. Очень многое из того, что айтишники считают „своим“ и гордятся этим, придумано „не ими“. Очень смешно, когда молодые „переоткрывают азбучные для классического инженера идеи“. Ну или воюют с „водопадами“, а также артефактами в виде „ветряных мельниц“ типа ТЗ.

ТЗ — это большое БЛАГО для программиста. „Водопад“ — возможность творчески работать, не загоняя себя в угол."

http://habrahabr.ru/post/188604/#comment_6552308

Добавлю ОТ СЕБЯ - "В ЛЮБОМ проекте - ОПЕРАТИВНЫЕ РЕШЕНИЯ принимаются - ТОЛЬКО в "стиле XP". Но это не плохо и не хорошо. Это - ДАННОСТЬ".

Ссылка. Ещё про UML

http://www.openarchitectureware.org/index.php

Offtopic. Похвастаюсь

Ссылки. UML "по верхам"

http://ooad.asf.ru/standarts/UML/OOPandUML/List06.aspx
http://khpi-iip.mipk.kharkiv.edu/library/case/leon/gl3/gl3.html#4
http://larin.in/archives/26

http://window.edu.ru/library/pdf2txt/745/72745/50472

Про UseCase'ы

хотите подкину пищу для раздумий? чем наследование прецедентов отличается от <<include>> и <<extends>>?

а ещё бывают "вложенные" прецеденты :)

т.е. ЧЕТЫРЕ нотации для ОЧЕНЬ похожих вещей

что такое "абстрактные" UseCase - я тоже - только недавно понял

смотрите - бывают "абстрактный" документ, юридический документ, статья словаря, пользовательская консультация :) и т.п.

вот тут и появляются связи между UseCase
и возможность "конструирования" системы на уровне UseCase
именно "конструирования".. архитектуры....

а эти "общие слова" - рождают собою - вполне конкретные проектные классы...

и Dependency Injection (http://ru.wikipedia.org/wiki/Dependency_Injection)

а вложенность UseCase трактую так - работа с ДОКУМЕНТОМ распадается на два ВЛОЖЕННЫХ UseCase - "работа с текстом" и "работа с оглавлением" - они существуют параллельно в рамках объемлющего UseCase

вложенные UseCase - это по сути - "разные области пользовательского фокуса", но существующие одновременно и взаимодействующие друг с другом

совсем грубо - Object Inspector, Project Inspector, CodeEditor в delphi ;) - это вложенные прецеденты в основном UseCase "написание программы на delphi"

Ссылки про DSL

http://habrahabr.ru/post/134039/
http://habrahabr.ru/post/128933/

http://habrahabr.ru/post/160085/
http://habrahabr.ru/post/48754/
-- по-моему - это всё - стоит прочитать.