Один из идеологов объектно-ориентированного подхода и один из авторов языка моделирования UML Джеймс Рамбо пишет:
"Модель классов описывает статическую структуру системы: объекты и отношения между ними, атрибуты и операции для каждого класса объектов. Модель классов – самая важная из трёх основных моделей. Мы считаем, что в основе системы должны быть объекты, а не требуемая функциональность, потому что объектно-ориентированная система лучше соответствует реальному миру и оказывается более жизнеспособной при возможных изменениях".
Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 42.
На мой взгляд, данное утверждение в корне неверно, потому что любая система проектируется и создаётся для чего-то, т.е. предназначена для выполнения каких-то полезных функций. Эти полезные функции должны выполняться эффективно, желательно, с наименьшими затратами и с соблюдением надлежащего качества. Как результат, архитектура программы должна быть заточена под полезные функции, а не под абстрактные объекты реального мира.
В этой заметке я продолжаю разбирать задачу про "датчики и метеостанцию" из книги Гради Буча, применяя не объектно-ориентированный, а функциональный подход. Условия задачи и первоначальный разбор смотрите в предыдущих заметках:
Согласно функциональному подходу, чтобы спроектировать программу, нужно:
- сформулировать ключевые функции будущей системы;
- описать процесс выполнения полезных функций (в английском языке есть удачный термин – flow); для этого надо:
- "разбить" функции на элементарные операции;
- упорядочить эти операции во времени;
- разделить слишком длинные или слишком сложные процессы на подпроцессы;
- описать полученные подпроцессы при помощи блок-схем или functional flow block diagram (FFBD);
- составить функциональную архитектуру системы, сведя найденные элементарные операции в таблицу.
В предыдущих заметках было предложено разделить процесс считывания информации с датчиков и отображения её на экране на два независимых процесса:
- Получение данных от датчиков и сохранение их в БД.
- Считывание данных из БД и отображение их на экране.
Причина такого разбиения заключается в том, что разные концы единого процесса предъявляют к нему противоречивые требования: датчики нужно опрашивать с одной частотой, а отображать данные на экране – с другой частотой или же вообще делать это по запросу от пользователя.
Отобразим каждый из двух подпроцессов сначала в виде блок-схем, а затем – в виде FFBD диаграмм.
Рис. 1. Получение данных от датчиков (блок-схема).
Рис. 2. Отображение данных на экране (блок-схема).
Рис. 3. Получение данных от датчиков (FFBD).
Рис. 4. Отображение данных на экране (FFBD).
На мой взгляд, проектировщику следует применять оба вида диаграмм: блок-схема удобна для описания flow, а functional flow block diagram удобна для выявления и учёта элементарных операций. Впоследствии эти элементарные операции можно свести в таблицу, которая называется функциональной моделью или функциональной архитектурой системы.
Табл. 1 Функциональная архитектура программы для метеостанции.
№
|
Название функции
|
1
|
Получить данные от датчиков.
|
1.1
|
Ожидать сообщение или таймаут.
|
1.2
|
Прочитать сообщение с порта.
|
1.3
|
Извлечь полезные данные.
|
1.4
|
Определить тип данных – температура или атмосферное давление.
|
1.5
|
Извлечь значение температуры и время измерения.
|
1.6
|
Преобразовать значение температуры к градусам Цельсия.
|
1.7
|
Сохранить значение температуры и время измерения в БД.
|
1.8
|
Извлечь значение атмосферного давления.
|
1.9
|
Преобразовать значение атмосферного давления к миллиметрам ртутного столба.
|
1.10
|
Сохранить значение атмосферного давления и время измерения в БД.
|
2
|
Отобразить данные на экране.
|
2.1
|
Ожидать ввод пользователя или таймаут.
|
2.2
|
Получить значение температуры и время измерения из БД.
|
2.3
|
Преобразовать значение температуры к градусам Фаренгейта.
|
2.4
|
Отобразить значение температуры и время измерения на экране.
|
2.5
|
Получить значение атмосферного давления и время измерения из БД.
|
2.6
|
Преобразовать значение атмосферного давления к Паскалям.
|
2.7
|
Отобразить значение атмосферного давления и время измерения на экране.
|
Пункт 2.6 четвертого рисунка, поправьте, если есть возможность, смешное слово "Пасякаль"
ОтветитьУдалитьСпасибо, Павел. Исправил.
ОтветитьУдалитьЗадача хороша тем, что подходит под концепцию, программирование АСУ ТП сильно отличается от программирования бизнес-приложений. Соответственно решение задачи, подобранной под концепцию, выглядит убедительно. Попробуйте расписать в таких терминах японскую модель управления персоналом, когда у одного человека несколько начальников и несколько сотрудников на одной с ним ступени, и сотрудник взаимодействует со всеми одновременно и учитывает в своей деятельности все входящие замечания от них.
ОтветитьУдалить2 beasonde: Если думать "объектно", т.е. в терминах "начальник" и "подчинённый", то, конечно, ничего не получится, т.к. количество возможных взаимосвязей зашкаливает. Поэтому нужно думать функционально, т.е. не о том, кем является человек в модели управления, а о том, какие функции он выполняет. Нужно выявить эти функции и упорядочить, как и было продемонстрировано при решении задачи про датчики.
ОтветитьУдалитьА чем по Вашему отличается понятие роли от того, какие функции исполняет человек, имеющий эту роль?
ОтветитьУдалитьФункциональный подход отличное средство ... прошлого столетия. Картина мира изменилась.
И простите, а что Вы сами понимаете под архитектурой?
2 Эдуард: Роль - это группа функций, разве не так? Другое дело, что эта группа должна быть составлена правильно, а нередко бывает, что проектировщики обсуждают роли, не понимая, какие этим ролям будут сопоставлены функции.
ОтветитьУдалитьГоворите, функциональный подход - прошлый век? Вот сейчас завершаем работу над игрой, где наиболее сложные задачи были решены как раз при помощи функционального подхода.
Мне ближе понятие не архитектура, а конструкция.
Кирилл. Да, конечно, но то, что проектировщики не понимают какие функции сопоставляются ролям, проблемы проектировщиков, возможно аналитиков, но в любом случае проблема конкретного частного случая, необобщаемого на все ситуации.
ОтветитьУдалитьК сожалению у меня нет опыта проектирования игр, да и не знаю как и чем Вы руководствовались, когда проектировали игру. Возможно в Вашем случае - это действительно было правильно, но опять -можно ли считать, что Ваш подход - это подход, который всегда обощается?
При функциональном подходе в режиме конструирования мы задаем функцию и подбираем под нее структуру ее обеспечивающую. Но где критерий какая структура эффективнее, а какая нет? Обычно он в качественных характеристиках, которые и оказывают влияние на архитектуру. Понимаете просто наличие трех программистов в Вашей компании и потребность выполнять задача максимально быстро, на мой взгляд может оказать больше влияние на архитектуру, чем определенная фича.
Т.е. с моей позиции архитектура - это не конструкция, а принцип создания такой конструкции
Эдуард. Если бы это был частный случай, то вряд ли бы он повторялся из проекта в проект и от конторы к конторе. Практика показала: оперируя сущностями (классами, объектами, ролями), люди не понимают их функциональный смысл. Ряд разработчиков, приступая к проектированию программы, совершенно не думают о том, что у программы есть какое-то предназначение, что она разрабатывается для чего-то.
ОтветитьУдалитьБольшая игра несильно отличается от обычного бизнес-приложения, особенно, её экранная часть. То же есть формочки (экраны), то же есть база данных (конечно, не Oracle и не MS SQL), тоже есть бизнес-слой и слой доступа к данным. Геймлей, ИИ, физика, рендер, конечно, отличаются сильнее, но это никак не влияет на подход к проектированию.
Мой подход был протестирован как при разработке бизнес-приложений (в области телекоммуникаций, GPS-навигации, в IDE), так и при разработке игр.
В качестве критериев для выбора оптимальной структуры подойдут: количество обрабатываемых и/или хранимых данных, частота запросов на обработку, требуемая сложность/производительность алгоритма и т.п. Всё это хорошо описано в учебниках по алгоритмам и структурам данных.
Что касается распределения работы в команде, то, согласно моему опыту, неплохо себя проявляет функциональная декомпозиция, когда человек специализируется в рамках функционального направления. При этом, архитектор или тех. лид создаёт каркас приложения, который потом усилиями команды обрастает "мясом".
Кирилл, спасибо. Я понимаю Вашу мысль. Но мое имо, это все проблемы обучения команды, образования в России (возможно).
ОтветитьУдалитьНу скажите например, каково предназначение кружки?
Или в игре Вы используете объект "Смертельно ядовитая трава", скажите, что все эти объекты Вам говорят?
Я вовсе не хочу усомнится в Вашей квалификации и успешности применения метода. Правда Вы говорите, что метод изобретен Вами. Не мог ли бы Вы указать статьи, в которых изложены принципы Вашего метода? Просто то что я видел, укладывается в те знания и методы, которые мне известны. В том числе функциональный подход, который известен еще с эры больших ЭВМ.
Эдуард. У каждой кружки есть своё предназначение. Есть кофейные чашки, есть чашки из чайного сервиза, есть чашки для чайной церемонии, есть походные кружки, кружки офисные, подарочные и т.д. В зависимости от назначения они приобретают нужную форму и размеры, а также - подбирается материал для их изготовления.
ОтветитьУдалитьЕсли в игру был добавлен объект "смертельно ядовитая трава", то он был добавлен не просто так, а потому что, например, уровень для прохождения без этого объекта - слишком лёгкий. Таким образом, его задача - "усложнить прохождение уровня".
Эдуард. Я не писал, что метод изобретен мною. Я писал лишь о том, что метод предложен мною. Есть и некоторые доработки - выполнять проектирование процесса по аналогии с тем, как выполняется проектирование технологического процесса для производственных предприятий. Например, разбивать процесс на независимые циклы и т.п. (см. задачу про датчики).
ОтветитьУдалитьСм. также кейсы в этом блоге и мои с С.В. Сычевым статьи из списка литературы: http://askofen.blogspot.com/2010/08/blog-post.html
Кирилл, я, конечно, понимаю "гений - парадоксов друг" (c)Пушкин, но может назовете парочку - "абстрактные объекты реального мира" ;)
ОтветитьУдалитьПравильно ли я понимаю, что следуя цитате "составить функциональную архитектуру системы, сведя найденные элементарные операции в таблицу"
ОтветитьУдалитьархитектура - это список элементарных операций перечисленных в особой таблице?
Какова структура такой таблицы? Если та, что приведена на конечном рисунке, то я бы назвал это иерархическим списком.
Еще вопрос уточняющий - что есть элементарная операция, каковы критерии ее элементарности?
Спасибо
Эдуард. Это полемика с Гради Бучем, с его абстракциями сущностей, которые он рекомендует строить в процессе проектирования, "так как они прямо соответствуют сущностям предметной области" (стр. 56, 2-го издания). Смысл моей фразы таков: хоть объекты и реальные (т.е. берутся из предметной области), но из них получаются бесполезные классы или, как любит писать Буч, абстракции.
ОтветитьУдалитьКоротко ответы на Ваши вопросы:
ОтветитьУдалить1) Да.
2) Да, согласен.
3) Элементарная операция - это функция, дальнейшая декомпозиция которой на подфункции (операции) не имеет смысла.
Кирилл, спасибо за ответы.
ОтветитьУдалить1) а в чем тогда разница меджду понятием структура и архитектура, или архитектура и модель. не получается ли что использование слова архитектура дань модному слову?
2) т.е. критерием элементарности является субъективная оценка проектировщика? В принципе так часто и бывает, но может есть более точные (объективные ) критерии?
1) Функциональная архитектура - официальный термин из работы System Engineering Fundamentals. Согласен, что у нас чаще используется термин "функциональная модель".
ОтветитьУдалить2) Других критериев я пока не знаю. Думаю, если проектировщик, знает, как реализовать функцию, и она ему не кажется сложной, является предсказуемой в плане затрат, то эту функцию можно счесть элементарной операцией. В конце-концов, функциональный анализ и проектирование тоже делается для людей. Если по разработанной архитектуре легко реализовать систему, то разве этого недостаточно?
Кирилл, где можно ознакомится с текстом работы System Engineering Fundamentals? Был бы рад почитать.
ОтветитьУдалитьПолучается между термином архитектура и модель нет никакой разницы. Зачем вводить тогда лишнее понятие? Это не экономно. И видимо не соответствует реальности. Ясно, что любая архитектура - это модель, но модель - то не архитектура. Мое имо, по архитектуре нельзя легко реализовать систему. По модели невсегда это удается, она должна быть достаточно точна и однозначна.
Это, правда, философский разговор. И вести его следует в иной обстановке :)
Эдуард, с работой System Engineering Fundamentals можно ознакомиться здесь - http://www.dau.mil/pubscats/Pages/sys_eng_fund.aspx
ОтветитьУдалитьМне, в общем-то, тоже привычнее понятие "функциональная модель". Но я не против "функциональной архитектуры", раз она используется в ряде источников.
А вообще, тема проектирования ПО еще только развивается, терминология не устоялась. Так что ничего не вижу страшного в использовании разных терминов для обозначения одного и того же.