Здравствуйте, gandjustas, Вы писали:
G>1)Стоит добавить цели создания графического редактора (vision). Сейчас этих редакторов немеряно, если пытаться сделать лучше, то одной статьи не хватить даже чтобы описать чем он лучше будет. G>2)Для каждого дизайнерсокого решения указывать на достижения какой цели оно направлено. G>3)Указать итерационность процесса, выделить фичи, указать и обосновать приоритеты.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, gandjustas, Вы писали:
G>>1)Стоит добавить цели создания графического редактора (vision). Сейчас этих редакторов немеряно, если пытаться сделать лучше, то одной статьи не хватить даже чтобы описать чем он лучше будет. G>>2)Для каждого дизайнерсокого решения указывать на достижения какой цели оно направлено. G>>3)Указать итерационность процесса, выделить фичи, указать и обосновать приоритеты.
КЛ>Разве здесь цель не указана?
Указана, но не видно почему создание целого редактора необходимо для достижения цели.
Надо не просто указать некоторые хотелки, а написать хотя бы небольшой vision проекта.
Опубликовал продолжение примера по проектированию графического редактора. Опять-таки, интересует мнение коллег.
Прежде чем приступать к проектированию структур данных, следует убедиться в том, что построенная функциональная модель системы достаточно полна.
Будем считать функциональную модель полной, если рассмотрение каждого последующего прецедента не приводит к добавлению новых функций.
Основная ошибка, допускаемая неопытными разработчиками, заключается в том, что они рассматривают упрощённые прецеденты. (Или же не рассматривают их вообще.) Чтобы построить полную функциональную модель, нужно изучать сложные юз-кейсы, взятые из реальной жизни.
Вернёмся к нашему примеру – "проектирование графического редактора для создания открыток".
Классический объектно-ориентированный подход даёт проектировщику чёткое руководство, как это делать.
Прежде всего, в предметной области следует найти ключевые абстракции. Различные учебники по ООП пишут, что для графического редактора ключевой абстракцией является фигура.
Затем следует установить взаимосвязи между ключевыми абстракциями. Если взаимосвязь можно выразить отношением is-a, то такие абстракции следует связать при помощи наследования. Если взаимосвязь подходит под отношение has-a, то такие абстракции следует связать при помощи агрегации.
Для графического редактора абстрактную фигуру можно связать отношением наследования с конкретными фигурами: прямоугольником, эллипсом, треугольником и т.п.
Получается стройная и логичная картина:
class Figure;
class Rectangle : public Figure;
class Ellipse : public Figure;
class Triangle : public Figure;
К сожалению, она не позволяет создать редактор, который хоть в какой-то мере удовлетворяет потребностям пользователя.
Отличная статья, ИМХО самая полезная из всего цикла. Хотелось бы побольше объем статьи, ссылки на удачные и неудачные примеры из книг\статей\форумов.
Единственное что не понравилось — избитый до невозможности пример с фигурами.
Кстати, перечитав весь цикл понял что лучше его в обратном порядке рассказывать. Как говорится ground-up, что соответствует росту квалификации разработчика.
Здравствуйте, Кирилл Лебедев, Вы писали:
G>>Хотелось бы побольше объем статьи, ссылки на удачные и неудачные примеры из книг\статей\форумов. КЛ>Посмотрите здесь.
Уже смотрел.
Твой подход хорош, когда у тебя под рукой есть КорелДро, т.е. грубо говоря полнофункциональный прототип на котором можно заранее прогнать все функции и заранее посмотреть, что будет в конце.
То есть, в твоей задаче не надо задумываться о модели предметной области — ибо конечнй результат известне зарее и при том его можно чуть не на зуб попробовать
Представь себе — все вещи, которые используются в КорелДро, известны заранее — контуры, фигуры и тд.
Поэтому и получается такое удобное проектирование, как ты расписал.
Это будет работать до тех пор, пока у тебя есть такой КорелДро и готовая модель предметной области.
Представь себе, это есть не всегда. Функции всегда описываются в _терминах_ предметной модели.
Если термины тебе неизвестны, то сначала строится модель, потом прорабатываются функции, потом детализируется модель, детализируются функции и тд и тд и тд.
Т.е. имеем в наличии итерационный процесс и здесь пока еще про классы не было ни слова.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Нередко формулировка задачи, полученная от заказчика, вызывает у проектировщика шок: КЛ>"Спроектируйте игру для девочек 4 – 8 лет".
А вы не теряйтесь
девочка 4-8 дет → клавиатура
↑ ↓
монитор ← игра
Re[2]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Ikemefula, Вы писали:
I>Функции всегда описываются в _терминах_ предметной модели.
Бред. Функция: показать график прибыли.
Какая предметная тут область?
I>Если термины тебе неизвестны, то сначала строится модель, потом прорабатываются функции, потом детализируется модель, детализируются функции и тд и тд и тд.
Вроде как было в одной из статей. Да и я тебе говорил.
У функций есть входные и выходные данные. Модель получается систематизацией входных и выходных данных. Выдумывать её заранее контрпродуктивно.
Re[2]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Ikemefula, Вы писали:
I>Это будет работать до тех пор, пока у тебя есть такой КорелДро и готовая модель предметной области.
Если есть предметная область, то, следовательно, существует и круг задач, решаемых специалистами в рамках данной предметной области. А если есть задачи, то, следовательно, есть и подходы к решению. Вот и нужно описать эти подходы в виде юз-кейсов.
I>Если термины тебе неизвестны, то сначала строится модель, потом прорабатываются функции, потом детализируется модель, детализируются функции и тд и тд и тд. I>Т.е. имеем в наличии итерационный процесс и здесь пока еще про классы не было ни слова.
В данной публикации говорится только о проектировании реализации классов. Обо всём остальном говорится в предыдущих статьях.
Здравствуйте, Кирилл Лебедев, Вы писали:
I>>Это будет работать до тех пор, пока у тебя есть такой КорелДро и готовая модель предметной области.
КЛ>Если есть предметная область, то, следовательно, существует и круг задач, решаемых специалистами в рамках данной предметной области. А если есть задачи, то, следовательно, есть и подходы к решению. Вот и нужно описать эти подходы в виде юз-кейсов.
А что т будешь в юзкейсы писать ? Слово "транспондер" или "проключение" тебе что нибудь говорит ?
Не надо выдумывать велосипеды, открой любой гост, что фактически спецификация, как правило он или содержит раздер "термины и определения" или ссылается на другой раздел с такой информацией.
Вот в этих терминах и описываются юз-кейсы и именно с этих терминов начинается модель предметной области.
I>>Если термины тебе неизвестны, то сначала строится модель, потом прорабатываются функции, потом детализируется модель, детализируются функции и тд и тд и тд. I>>Т.е. имеем в наличии итерационный процесс и здесь пока еще про классы не было ни слова.
КЛ>В данной публикации говорится только о проектировании реализации классов. Обо всём остальном говорится в предыдущих статьях.
Мне лень бегать по форуму и искать твои посты.
Re[3]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, gandjustas, Вы писали:
I>>Функции всегда описываются в _терминах_ предметной модели. G>Бред. Функция: показать график прибыли. G>Какая предметная тут область?
Очевидно, чтото из экономика/финансы/бухгалтерия. Для этого надо знать, что же такое прибыль. Нет такого абсолютного понятия как прибыль.
G>У функций есть входные и выходные данные. Модель получается систематизацией входных и выходных данных. Выдумывать её заранее контрпродуктивно.
Я тебе уже приводил пример. Ты ничего внятного ответить не смог. А были дадены и входы и выходы и даже функция.
Re[4]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Функции всегда описываются в _терминах_ предметной модели. G>>Бред. Функция: показать график прибыли. G>>Какая предметная тут область? I>Очевидно, чтото из экономика/финансы/бухгалтерия. Для этого надо знать, что же такое прибыль. Нет такого абсолютного понятия как прибыль.
Тем не менее функциональность определена без намека на предметную область.
G>>У функций есть входные и выходные данные. Модель получается систематизацией входных и выходных данных. Выдумывать её заранее контрпродуктивно. I>Я тебе уже приводил пример. Ты ничего внятного ответить не смог. А были дадены и входы и выходы и даже функция.
Ну если бы еще денег дал за то что я этим буду заниматься, тогда поговорили бы. А так — нет.
Ты все таки утверждаешь что модель предметной области первостепенна для все программ, а тебе говорят что функциональная модель важнее.
Ты в защиту своего утверждения пока еще ничего не привел.
Re[5]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, gandjustas, Вы писали:
I>>>>Функции всегда описываются в _терминах_ предметной модели. G>>>Бред. Функция: показать график прибыли. G>>>Какая предметная тут область? I>>Очевидно, чтото из экономика/финансы/бухгалтерия. Для этого надо знать, что же такое прибыль. Нет такого абсолютного понятия как прибыль. G>Тем не менее функциональность определена без намека на предметную область.
Про то и речь — конь в вакууме. Слово вроде понятное, а что сделать надо — хз.
I>>Я тебе уже приводил пример. Ты ничего внятного ответить не смог. А были дадены и входы и выходы и даже функция. G>Ну если бы еще денег дал за то что я этим буду заниматься, тогда поговорили бы. А так — нет.
Ты вероятно привык работать со знакомыми тебе вещами.
G>Ты все таки утверждаешь что модель предметной области первостепенна для все программ, а тебе говорят что функциональная модель важнее.
Вообще то я говорил, что модель предметной области не везде нужна, т.к. много очевидных ситуаций где можно пользоваться готовой моделью или даже вообще без модели работать.
G>Ты в защиту своего утверждения пока еще ничего не привел.
Было бы так просто с функциями, ты давно бы ответил на мой вопрос.
Re[4]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Ikemefula, Вы писали:
I>А что т будешь в юзкейсы писать ? Слово "транспондер" или "проключение" тебе что нибудь говорит ?
В этой и предыдущих статьях речь идёт о проектировании системы, а не об ознакомлении с предметной областью. Понятно, что в сложных случаях разработчику нужно понимать предметную область. По этой причине, составление словаря терминов предметной области я считаю делом полезным. Однако сам по себе словарь не поможет разработать архитектуру системы и, в том числе, не поможет найти кандидаты в классы. Т.к. архитектура системы (и, соответственно, классы) есть производная от функционала.
Более того, если разработчик будет пытаться выводить классы из объектов предметной области, то он фактически загубит архитектуру, как описано здесь.
КЛ>>В данной публикации говорится только о проектировании реализации классов. Обо всём остальном говорится в предыдущих статьях. I>Мне лень бегать по форуму и искать твои посты.
А искать и не нужно. Открываешь последний пост и находишь ссылки в начале.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Прежде всего, в предметной области следует найти ключевые абстракции. Различные учебники по ООП пишут, что для графического редактора ключевой абстракцией является фигура.
Думаю, раз ты употребил "Различные учебники по ООП" стало быть не от фонаря было дело ?
Дай ссылку хоть на один учебник где такое написано ?
>мы бросились искать абстракции в предметной области
На самом деле ты ни в какую предметную область не бросался а взял абстракции от балды.
Плохая статья — выдумал миф и лихо расправился с ним.
Re[5]: Как правильно выполнять декомпозицию задачи?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>В этой и предыдущих статьях речь идёт о проектировании системы, а не об ознакомлении с предметной областью. Понятно, что в сложных случаях разработчику нужно понимать предметную область. По этой причине, составление словаря терминов предметной области я считаю делом полезным. Однако сам по себе словарь не поможет разработать архитектуру системы и, в том числе, не поможет найти кандидаты в классы.
"Словарь" является необходимым, но не является достаточным условием. Что бы было и необходимо и достаточно, надо этот "словарь" дополнить функциями.
КЛ>Более того, если разработчик будет пытаться выводить классы из объектов предметной области, то он фактически загубит КЛ>А искать и не нужно. Открываешь последний пост и находишь ссылки в начале.
Коментить в блоге мне не интересно, в блоге у тебя жиденькое обсуждение.
Здравствуйте, Ikemefula, Вы писали:
I>Думаю, раз ты употребил "Различные учебники по ООП" стало быть не от фонаря было дело ? I>Дай ссылку хоть на один учебник где такое написано ?
Да вот хотя бы у Страуструпа в разделе "1.2.4 Пределы абстракции данных".
I>Плохая статья — выдумал миф и лихо расправился с ним.
Напиши лучше.
P.S.: Мнение, не подкреплённое аргументами, неинтересно.
