Здравствуйте, уважаемые.

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

К сожалению, из моего университетского окружения о UML слышали мало кто, а применяли вообще никто, ну разве что я осмелился навалять, но это явно была хромая, препод снисходительно отнесся, ибо нам этого вообще не преподавали, и похоже не собираются.

Так, что прошу подкинуть задачку и проследить ее корректное решение.

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

разработать структуру приложения, способного решать оптимизационные задачи некоторыми алгоритмами.. 
Опишу подробно:
1. Должна содержаться постановка задачи и возможность выбора алгоритма.
2. В системе должен иметься решатель, соединяющий задачу с алгоритмом, который способен ее решить.
3. Алгоритм должен поддерживать итерационность решения, т.е. решения по шагам (нажать например кнопку - "Следующий шаг" и у тебя выполняется следующая итерация)
4. В системе должна быть подсистема отрисовки работы алгоритма (на каждом шаге)


это в общих чертах..что подробнее - спрашивай

Platon, а есть что проектировать?...
Проблема-то только в этом.

Взятые из головы примеры бессмысленны и толку вам от них никакого не будет.
Нужна реальная задача.

0000, зашибите меня коромыслом, но я никакой диаграммы классов не просматриваю вообще в вашем примере.

Вы перечислили некие требования, по которым в принципе можно начать разрабатывать ТЗ, но не более того.

Это сообщение отредактировал(а) ida - 22.12.2007, 19:34

ida, а задании по проектированию надо прямо сказать - сделай такой, класс, сделай такой, тут пронаследуй, а этот запихни туда?? так чтоли??
я дал именно требования..
вы, простите, когда ТЗ получаете, проводите анализ - у вас уже на этапе анализа появляется эти самые диаграммы анализа, которые и ведут прямо к проектированию...
челокеку хочется научиться проектировать, так вот требования..пожалуйста, составьте мне проект системы как угодно, как видите...

так что пользуясь вашей терминологией - *зашибаю вас коромыслом*

0000, я, прощаю, ТЗ не получаю - я их пишу.
Да, возможно вы правы. В задании по проектированию наверное так бывает, а вот в жизни - точно все по-другому...

может и я как неправильно выразился...
но..
все равно вся жизнь начинается с ТЗ, описания задания или требований.. по ним проводим какой-то анализ, из которого уже вытекает фаза проектирования...
говорите не так - расскажите как у вас бывает..мож чему поучусь =) 

ida, вы не правы.
0000 дал постановку, которая вполне подходит для проектирования, в т.ч. для создания диаграммы классов. конечно, задача поставлена очень абстрактно, поэтому и диаграмма будет такая же. тем не менее некоторые вещи, не вытекающие прямо из данной постановки, а рожденные в процессе анализа (пусть и умозрительного, а точнее - общего, в отсутствие достаточных данных), на диаграмме должны найти отражение.

понятно, с потолка задания трудно выдумывать, а реальные (и как правило уже реализованные) слишком громоздки для приведения их здесь

Это сообщение отредактировал(а) baldina - 24.12.2007, 23:27

Хух, дорвался до инета наконец!!!
Обидно говорить, но в VisualParadigm я не оч разобрался, поэтому связи неправильные сделаны, ну и в целом делал по чутью.

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

вот это как-то непонятно отражено.
Поясню:
Надо уяснить, что такое отрисовка работы алгоритма на каждом шаге.
Из понятия "шаг алгоритма" и понятия алгоритма в целом следует вывод, что исполняемый алгоритм имеет некое состояние (state) на каждом шаге выполнения. Т.е. в данном контексте можно рассматривать алгоритм как (конечный) автомат. 
Отрисовка - вывод состояния (например, перечень текущих переменных с их значениями).

Итак, требуется отдельное понятие "состояние", как минимум представляющее набо пар имя/значение.
На этом пока можно остановиться (хотя мысль летит дальше, можно додумать стек текущих имен и т.п.)

Далее.

Поскольку ничего более нам неизвестно, тут можно пофантазировать. Например, "задача" имеет некоторые атрибуты, указывающие класс алгоритмов, пригодных для решения. Такой будет вывод, или нет, но в результате должно быть понятно, как именно задача связана с алгоритмом через решатель. Сейчас это не понятно.

Ну и дальше в таком духе...

В принципе результатом должен стать код, сгенеренный по диаграмме, который можно будет выполнять. Без решения задачи, хотя бы отладочным выводом что и как вызывается и т.д. Т.е. архитектурное решение можно протестировать и сделать выводы о его пригодности.

Добавлено @ 01:31
И еще один момент.
Связи желательно уменьшать. В идеале Solver знает и про задачи и про алгоритмы, а задачи и алгоритмы независимы друг от друга и от солвера. Похожим образом и с визуализацией.
Т.е. если удастся, должны получиться связи вроде


Это сообщение отредактировал(а) baldina - 25.12.2007, 01:35

кстати, одна из основных причин появления UML - возможность обсуждать диаграммы с заказчиком. Т.е. они ему должны быть интуитивно понятны (ну хотя бы на крупном уровне абстракции). 

Ну, на самом деле в моей задаче состояние тоже присутствует, OptimizeAlgorithmPart, его можно назвать OptimizeAlgorithmState, согласен.


в данном случае, AlgorithmVisualizer отвечает за это состояние, и каждое состояние выводится в качестве JComponent, может быть не очень удачно, но, вашей мысли соответсствует.


Это и сделано ;) с помощью addAlgorithm(Class problemType, Algorithm algo) мы можем составить карту, привязку определенного типа задач к определенным типам алогритмов.


а разве у меня не что-то подобное?

Мне кажется не очень удачным, согласно принципа "одна задача - один класс".


Подобное - да. Видимо мысль развивалась в похожем направлении, только из диаграммы не очень очевидно. Имхо.

Добавлено через 1 минуту и 32 секунды


здесь подразумевалось, что ---> означает "знает" и "управляет". обращаю внимание, что стрелки лишь в одну сторону

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

Как описывается состояние алгоритма - зависит от задачи. Например если нам надо построите остов минимального веса, используя алгоритм Прима - мы можем в качестве состояния брать номер шага и количество вершин, уже просмотренных в графе, может сам граф в процессе...

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


Затем по поводу решателя...
В данном вопросе есть одна серьезная проблема...как связать алгоритм  с задачей..по идее алгоритм должен знать что решать, с другой стороны задача может содержать в себе алгоритм.. 
Однако последнее я считаю не целесообразным, поскольку для одной задачи может быть несколько алгоритмов решения и не дело задачи выбирать себе алгоритм..
Вот и вводится некий решатель. Он служит для связи пары задача-алгоритм.. К примеру так - каждый алгоритм однозначно может сказать какой класс задач он способен решить...из этого принципа решатель уже сам точно выберет набор алгоритмов, которые смогут решить конкретную задачу..а выбрать из них оптимальный - это уже другой вопрос, который в задаче не стоит...

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

Вот например. Корректность смотреть в комментах и гугле. 
На RSDN'е эту задачу подробно разбирали.

Да-да, именно умозрительного
Т.е. ничего общего с практикой вообще не имеющего. Я видите ли очень хорошо себе представляю, что это такое - ежедневно сталкиваюсь по работе. От такого умозрительного анализа хочется взять толстую грязную палку и проложить вдоль спины программиста  Сопровождая словами: "Нееечего выдумывать, нееечего... ТЗ дадено - по нему и пишем."

Простите, была напугана.


Совершенно верно.
Так вот из диаграммы, которую привел здесь Platon, заказчик не поймет ни черта.

Но такие диаграммы ему никто и не покажет. Ибо реализация есть личное дело разработчика.
С заказчиком обсуждаются только предметные вопросы.

Могу предложить свою версию теста на объектное мышление (т.е. проверки, насколько у человека заточены мозги под ОО-проектирование и стоит ли ему вообще в это погружаться, т.е. будет ли от этого какая-то польза).

Студент приходит на экзамен.
Отдает зачетку преподавателю, тащит билет, готовится.
Выходит отвечать. Если преподавателю нравится ответ, он ставит оценку, отдает зачетку и студент уходит. Если ответа недостаточно, преподаватель задает дополнительные вопросы. Если студент не смог ответить на дополнительне вопросы, ему предлагают тянуть другой билет или прийти на пересдачу. Решает студент.

Нарисуйте:
1. Диаграмму классов для описанного примера
2. Алгоритм - диаграмму деятельности
3. Жизненный цикл зачетки - диаграмма состояний
4. Диаграмму последовательности, где объектами будут студент и преподаватель

А там поглядим...

Это сообщение отредактировал(а) ida - 25.12.2007, 16:53