вторник, 6 августа 2013 г.
Есть ещё одна проблема - "размазывание бизнес-логики по различным уровням"
Есть ещё одна проблема - "размазывание бизнес-логики по различным уровням".
И это не проблема проектирования. Просто бизнес-логика такова. Часть её влияет на данные. Часть на транспорт. Часть - на различные аспекты визуализации. Она не "солидна", она - "размазана". Просто по сути своей. А не потому, что "недодумали".
Мне лично - модель - тут тоже помогает. Она позволяет проследить такую бизнес-логику.
А коли "размазывание" - имеет место, то с "болтами-гайками" - не всё так просто. Как мне кажется.
К чему это я? А к тому, что раз имеет место "сложное принятие" решений, то оно скорее всего описывается каким-то how-to. Типа - "тут заводим объект такого, то типа, тут - такого, тут протягиваем между ними мост.. и т.п." А раз есть подобные "инструкции" и how-to, то скорее всего их можно изобразить на модели в виде "чертежа". Сделав шаблонным стереотипным решением. Вот собственно это и становится - "болтами-гайками". И процесс - рекурсивный.
И это не проблема проектирования. Просто бизнес-логика такова. Часть её влияет на данные. Часть на транспорт. Часть - на различные аспекты визуализации. Она не "солидна", она - "размазана". Просто по сути своей. А не потому, что "недодумали".
Мне лично - модель - тут тоже помогает. Она позволяет проследить такую бизнес-логику.
А коли "размазывание" - имеет место, то с "болтами-гайками" - не всё так просто. Как мне кажется.
К чему это я? А к тому, что раз имеет место "сложное принятие" решений, то оно скорее всего описывается каким-то how-to. Типа - "тут заводим объект такого, то типа, тут - такого, тут протягиваем между ними мост.. и т.п." А раз есть подобные "инструкции" и how-to, то скорее всего их можно изобразить на модели в виде "чертежа". Сделав шаблонным стереотипным решением. Вот собственно это и становится - "болтами-гайками". И процесс - рекурсивный.
Offtopic. Offtopic. "Бизнес в России"
Смотрю рекламу по ТВ. Всяких Газпромов и прочих Транснефтей.
Мотивировать пытаются - "Участием в общем деле", "необходимостью стране" и прочее и прочее.
Только не деньгами.
Это очередная попытка "украсть" или "подхвачена особенность менталитета"?
Мотивировать пытаются - "Участием в общем деле", "необходимостью стране" и прочее и прочее.
Только не деньгами.
Это очередная попытка "украсть" или "подхвачена особенность менталитета"?
Зачем UML. Ещё раз
http://habrahabr.ru/post/188604/
Поверьте - никого не хочется "уговаривать". Но хочется всё же - "донести мысль". Тем более, что она кажется перспективной. И она - так или иначе - опробована на практике.
Поверьте - никого не хочется "уговаривать". Но хочется всё же - "донести мысль". Тем более, что она кажется перспективной. И она - так или иначе - опробована на практике.
Основные претензии, которые я увидел, такие:
1. У вас неправильно организован процесс.
2. У вас недостаточно выразительный язык.
3. UML - мешает полёту мысли.
4. Неудобные инструменты.
Для начала хочется сказать - ужасно неприятно полемизировать с людьми скрытыми за "никами" и анонимностью.
Значит по поводу процесса. А кто-нибудь может ответить на вопросы:
1. Вы писали проекты сравнимые хотя бы с Word?
2. Сколько в них разнородных сущностей?3. Сколько ответственностей в среднем на сущность?
4. Сколько UseCase'ов верхнего уровня в системе?
5. Каков объём требований?
6. Сколько экранных форм?
7. Сколько людей в среднем в проекте?
8. В скольких проектах используются одни и те же проектные и компонентные решения?
9. Сколько строк кода попадает в среднем в день в систему контроля версий?
10. Сколько аспектов "пронизывают" ваши приложения?
По поводу выразительности:
1. Рефакторинг. В "квадратиках" - проще.
2. Конструктивизм - возможность создания "крупных" конструкций из более "мелких" кубиков. С возможностью статической подстановки типов и определения статической арности связей.
3. Шаблонные решения. Нарисовать что-нибудь типа "фабричный метод" - однозначно проще, чем закодировать. Другие сложные шаблонные решения - тем более.
4. Тестовый проект, тестирующий GUI, из обычного проекта делается просто. Гораздо проще, чем "в коде".
5. Возможность генерации дополнительных сущностей. Например контрольных точек или обвязки для тестирования.
6. Возможность генерации инфраструктуры проекта. Например поддержки ночных сборок. Или прочих cmd-файлов или make-скриптов.
7. Наглядная трассировка требований в код и обратно.
8. Как одно из "шаблонных решений". Но стоит выделения "отдельной строкой". MVC-подобные решения - проще и правильнее воспринимаются на модели, а не в "голом" коде.
9. Форматы документов удобнее и правильнее описывать на модели (или другом мета-языке) нежели чем в императивном коде.
4. Тестовый проект, тестирующий GUI, из обычного проекта делается просто. Гораздо проще, чем "в коде".
5. Возможность генерации дополнительных сущностей. Например контрольных точек или обвязки для тестирования.
6. Возможность генерации инфраструктуры проекта. Например поддержки ночных сборок. Или прочих cmd-файлов или make-скриптов.
7. Наглядная трассировка требований в код и обратно.
8. Как одно из "шаблонных решений". Но стоит выделения "отдельной строкой". MVC-подобные решения - проще и правильнее воспринимаются на модели, а не в "голом" коде.
9. Форматы документов удобнее и правильнее описывать на модели (или другом мета-языке) нежели чем в императивном коде.
По поводу "мешает":
1. За себя лично - Я СЧАСТЛИВ, что модель ограничивает "поток сознания".
2. За других скажу - кому "мешает" - это он либо из "вредности" (чисто заради абсолютного обсуждения свободы), либо - от недостатка информации. В том-то и дело, что если что-то "мешает" - всегда можно настроить. Главное - ОСОЗНАВАТЬ - "что" и "зачем". А "абсолютная" свобода выражения "потока сознания" в код - если не "зло", то уж точно - неудобство. При достаточно большом количестве участников. По-любому возникают всякие "инструкции программирования" и прочие Development case.
to be continued...
суббота, 3 августа 2013 г.
ППМП - Термины и определения, сокращения и обозначения
Сокращения и обозначения
ИДФ - источник данных формы
ИДС - источник данных сборки
МО - менеджер операций
МР - менеджер ресурсов
ОФ - операция формы
ППМП - платформа для создания пользовательских многооконных приложений
ФСФ - фабрика сборки форм
СФ - сборка форма
ИДС - источник данных сборки
МО - менеджер операций
МР - менеджер ресурсов
ОФ - операция формы
ППМП - платформа для создания пользовательских многооконных приложений
ФСФ - фабрика сборки форм
СФ - сборка форма
Термины и определения
Платформа
Платформа для создания пользовательских многооконных приложений соответствующую современным подходам к проектированию и реализации, которой посвящен цикл статей.
Диспетчер форм
Предназначен для регистрации форм в едином пуле для возможности получения доступа к любой форме отображаемой на экране и реализации механизма обмена сообщениями между формами.
Менеджер ресурсов
Глобальный ресурс, который содержит доступ к общим ресурсам приложения. По сути является нормативно-справочной информацией приложения, которая используется различными компонентами.
Менеджер меню
Глобальный ресурс приложения, который содержит перечень операций доступных для реализации формами приложения. В менеджере меню осуществляется управление общими свойствами операции, такими как: имя, название, иконка и другие параметры.
Операция формы
Операция формы доступная для выполнения пользователем путём выбора в главном или контекстном меняю, или вызовом горячей клавиши. Операция содержит настройки указывающие, в каких меню (главном или контекстном) нужно отображать операцию. При создании формы или вызове контекстного меню механизмами платформы производится автоматическое формирование набора операций доступных для выбора пользователя.
Сборка форм
Набор связанных форм отображаемых пользователю на одном экране. В сборку обязательно входит главное окно и набор дочерних форм (необязательно), в которых отображаться информация об объекте выбранном или отображаемом в главном окне сборки.
Фабрика сборки форм
Описывает совокупность форм (которые могут быть вложены друг в друга) и зоны их размещения. ФСФ предназначена для описания и инициализации данными как саму сборку, так и формы входящие в состав сборки. При редактировании ФСФ в "режиме разработки" пользователю доступны для выбора формы зарегистрированные в МР.
Источник данных формы
Предназначен для получения данных, которые должны быть отображены на форме и записи данных при их изменении. ИДФ устанавливается форме при создании СФ. ИДФ позволяет изолировать форму от знания о местонахождении данных.
Источник данных сборки
Содержит данные являющиеся общими для сборки форм. ИДС доступен для получения каждой форме сборки. ИДС устанавливается форме при создании СФ.
пятница, 2 августа 2013 г.
Заметки про наш кодогенератор. Надеюсь - Макс - будет НЕ против
Отдельно про "собственный кодогенератор".
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. Я в его написании - участия не принимал. Я только шаблоны
кодогенерации потом писал.
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/
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-моделирование», хоть «подготовка первого спринта». Но второй этап уже не должен содержать того, что уже упоминалось в первом этапе. Куратор проекта со стороны заказчика вас будет курировать по ТЗ (которое, опять же — вы сами себе написали, но в жанре «водопадного ТЗ»). Выходов из такой ситуации несколько:
— сказать, что заказчик = дурак, требует невозможного, так программисты не работают и уйти с гордо поднятой головой (пустыми карманами);
— прогнуться под заказчика, сказав — «ок, водопад? будет тебе Ниагара»!!!
— проевангелировать заказчика, скажем, «аджайлом», оставить ТЗ в качестве формальности, но работать «гибко».
Я попробовал второй и третий пункт. Надо сказать, второй ВСЕГДА лучше для такого рода проектов. Третий пункт был весел в течение всего срока работы над проектом, но «приёмка» это вам не «куратор». Лучше или хуже — роли не играет. Надо «как положено».
Так что «водопад» не есть «зло», а «аджайл» не есть добро. А друг тебе тот, кто деньги платит.
Опять же — «кобол» не равно «водопад». «Водопад» не значит «устарел». Водопад означает «комфортные условия взаимодействия „заказчик-исполнитель“ -да! иногда в ущерб качеству/количеству функционала, потенциально-возможному.
Ну и на закуску бойкому молодняку (который, Максим, и дискет в руках не держал — удачная шутка? а?).
Альтернативы „водопадной“ модели были предложены отнюдь не айтишниками. Очень многое из того, что айтишники считают „своим“ и гордятся этим, придумано „не ими“. Очень смешно, когда молодые „переоткрывают азбучные для классического инженера идеи“. Ну или воюют с „водопадами“, а также артефактами в виде „ветряных мельниц“ типа ТЗ.
ТЗ — это большое БЛАГО для программиста. „Водопад“ — возможность творчески работать, не загоняя себя в угол."
У меня было есть достаточно опыта: работа на гос. структуры по гос. контракту.
Есть «классическое» ТЗ, которое бьется на этапы. Нет, вам вполне позволят написать первым этапом (1-2-3-4 месяца) что угодно. Хоть «сбор и анализ требований», хоть «UML-моделирование», хоть «подготовка первого спринта». Но второй этап уже не должен содержать того, что уже упоминалось в первом этапе. Куратор проекта со стороны заказчика вас будет курировать по ТЗ (которое, опять же — вы сами себе написали, но в жанре «водопадного ТЗ»). Выходов из такой ситуации несколько:
— сказать, что заказчик = дурак, требует невозможного, так программисты не работают и уйти с гордо поднятой головой (пустыми карманами);
— прогнуться под заказчика, сказав — «ок, водопад? будет тебе Ниагара»!!!
— проевангелировать заказчика, скажем, «аджайлом», оставить ТЗ в качестве формальности, но работать «гибко».
Я попробовал второй и третий пункт. Надо сказать, второй ВСЕГДА лучше для такого рода проектов. Третий пункт был весел в течение всего срока работы над проектом, но «приёмка» это вам не «куратор». Лучше или хуже — роли не играет. Надо «как положено».
Так что «водопад» не есть «зло», а «аджайл» не есть добро. А друг тебе тот, кто деньги платит.
Опять же — «кобол» не равно «водопад». «Водопад» не значит «устарел». Водопад означает «комфортные условия взаимодействия „заказчик-исполнитель“ -да! иногда в ущерб качеству/количеству функционала, потенциально-возможному.
Ну и на закуску бойкому молодняку (который, Максим, и дискет в руках не держал — удачная шутка? а?).
Альтернативы „водопадной“ модели были предложены отнюдь не айтишниками. Очень многое из того, что айтишники считают „своим“ и гордятся этим, придумано „не ими“. Очень смешно, когда молодые „переоткрывают азбучные для классического инженера идеи“. Ну или воюют с „водопадами“, а также артефактами в виде „ветряных мельниц“ типа ТЗ.
ТЗ — это большое БЛАГО для программиста. „Водопад“ — возможность творчески работать, не загоняя себя в угол."
http://habrahabr.ru/post/188604/#comment_6552308
Добавлю ОТ СЕБЯ - "В ЛЮБОМ проекте - ОПЕРАТИВНЫЕ РЕШЕНИЯ принимаются - ТОЛЬКО в "стиле XP". Но это не плохо и не хорошо. Это - ДАННОСТЬ".
Добавлю ОТ СЕБЯ - "В ЛЮБОМ проекте - ОПЕРАТИВНЫЕ РЕШЕНИЯ принимаются - ТОЛЬКО в "стиле XP". Но это не плохо и не хорошо. Это - ДАННОСТЬ".
Подписаться на:
Сообщения (Atom)