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

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

К сожалению, из моего университетского окружения о 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

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

и во-вторых...ТЗ толком-то не дадено , дан именно набор требований...так что палки тут ни причем 

вот вы так все говорите, сталкиваетесь, сталкиваетесь...а нас все никак не столкнете с этим..ну пример бы свой хоть дали...

Хороший пример. Похоже на пример работы банкомата, который так любят американские афторы  

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

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

Вот мои наработки по задаче:

Platon, с диаграммой деятельности я в целом согласна.
С остальными - нет.

Работа над ошибками.

1. Диаграмма последовательностей.

Постараюсь попозже нарисовать, а пока объясняю.
Итак, у нас есть два объекта - Преподаватель и Студент.
В хронологическом порядке сообщения, которыми они обмениваются, будут такими:
1.1. Преподаватель -> Студенту: Билет
Студент готовится (обработка)
1.2. Студент -> Преподавателю: Ответ
1.3. Преподаватель -> Студенту: Оценка
ВСЕ!

Это основной поток.
Если есть желание, можно нарисовать альтернативные, например:
1.3. Преподаватель -> Студенту: Дополнительный вопрос
1.4. Студент - > Преподавателю: Ответ на вопрос
1.5. Преподаватель -> Студенту: Оценка

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

2. Диаграмма классов.

Попутно будет ясно, почему Экзамен не является объектом.

Я согласна с классами:
Преподаватель, Студент, Зачетка, Билет, Предмет (хотя последние два для нашей задачи лишние)

Экзамен, ЭкзаменующийПреподаватель, ЭкзаменуемыйСтудент, СостояниенаЭкзамене и его потомки - это не классы, а состояния.

ОтветНаВопрос и ДопВопрос - это не классы, а сообщения.

Чтобы понять, почему, вспомним, что такое состояние.
Состояние - это набор значений атрибутов класса.

У нас есть классы Студент и Преподаватель. Если бы мы нарисовали жизненный цикл студента на экзамене, то выделили бы несколько его состояний: 
перед вытягиванием билета, 
после вытягивания билета до момента ответа, 
после ответа до получения оценки, 
после получения оценки и т.д.

Они не являются классами, т.к. сами по себе никакой смысловой нагрузки не несут. Иными словами, их можно использовать лишь применительно к классу Студент.

Хороший вопрос на стадии оптимизации диаграммы классов: "Где это используется?" Если вы обнаруживаете класс, который нигде не используется сам по себе - значит, он лишний. Т.е. это либо атрибут, либо состояние, либо сообщение.

Это сообщение отредактировал(а) ida - 9.1.2008, 09:37

Здорово!!! А то я думал, мне уже никто не ответит!!!

Всех с прошедшими праздниками и с приближающимся старым-новым годом!

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

ЗЫ. как вообще картинку нормально запостить, Platon, расскажи плз..



http://ipicture.ru/uploads/080111/6d6CCr55R4.jpg

ida, жду Ваших комментариев.

Ну, на самом деле, это лишь логическое разделение объекта студент, потому что к примеру у студента могут быть много таких подобъектов: СтудентНаКонтрольной, СтудентНаЛекции и прочее. Я полагаю, что все эти функции в одном объекте Студент поддерживать очень сложно,более того составные классы позволят работать над ними нескольким разработчикам, разве нет?


как я вычитал из умной книжки, эта фишка называется делегированием, не понимаю почему они не являются классами?
В книге пример: class Window, в нем class Shape, и определены методы getArea() {return shape.getArea(); }, paing(Graphics g) { g.paintShape(shape); }

и тут также, к примеру, представьте студент в состоянии подготовки, и тут к нему запрос от препода отвечать объект подготовки на этот запрос выкинет преподу исключение: "не правильное состояние, я еще не готов!" вот и всё.
Так что я бы тут поапеллировал.


ну, на самом деле они весьма хлипкие для классов, но как сообщения, я что-то не пойму как это?

Добавлено через 2 минуты и 40 секунд
0000, нажимаю на pic на панели инструментов.

И в этом ваша концептуальная ошибка.

Путать классы с состояниями - ошибка грубейшая. Она проходит с опытом.

Вторая ошибка - скакать от реализации. Ее допускают разработчики.
Нас с вами сейчас не волнует, какими программными классами вы опишете модель предметной области - мы с вами модель еще толком не построили. Что вы уже собрались программировать?... Вот и получаются кривые-косые-корявые-горбатые компоненты, непригодные не то что для повторного применения, а вообще мало к чему пригодные.

Почитайте книжку "UML 2.0", авторы - Рамбо и Блаха. Там очень хорошо и подробно расписаны моделирование и предметной области, и приложения.

Это сообщение отредактировал(а) ida - 12.1.2008, 18:42

Дай Бог.


А как же не скакать? Всё равно же, надо думать о том как это будет реализовано... Чем меньше детализация, тем больше воли программисту.



спасибо за индивидуальную рекомендацию! Я видимо, привык сначала попробовать, потом мне скажут, что я делаю всё не правильно, и только потом с поубавленным пылом сажусь за книжки ^_^

Если вас не затруднит, не могли бы вы скинуть ссылочку на книжку в свободном доступе?

Добавлено через 1 минуту и 31 секунду
или хотя бы написать фамилии на буржуйском.

Platon, книжку я покупала на Озоне. Выглядит она вот так.

Насчет свободного доступа - честно говоря, не искала.

А по поводу опыта - когда нам в Политехе преподавали ООП, слушала как совершенную дичь. Сравнительно недавно поняла, почему. Потому что скакали от реализаци. Нас учили, как программировать. А надо было учить - как понять задачу. И только потом - программировать (что в этом случае будет происходить гораздо быстрее). Собственно, время, затраченное на составление грамотной модели - это время, которое вам потом не надо будет тратить на написание кода, т.к. вы найдете оптимальное решение. И свои 10 классов сведете к 2-3. Но это надо сначала увидеть. Хотя бы на бумаге.

Это сообщение отредактировал(а) ida - 14.1.2008, 10:59

Не поверите, но я вам верю ^_^ 
Более того, такой опыт уже получил совсем недавно. Правда, об идеальном UML говорить не пришлось, но людям на удаленном компьютере стала ясна моя мысль, пошли советы, пошла реконструкция, в итоге не написав ни одной строчки кода, были выявлены неправильности и уязвимости системы, также была проведена оптимизация, как вы заметили, уменьшилось число классов. В итоге, получилось уже что-то хорошее ^_^

0000, а что вы скажете по поводу такой модели:

1. Класс Преподаватель
Методы:
Слушать_ответ()
Задавать_вопрос()
Ставить_оценку()

2. Класс Студент
Методы:
Тянуть_билет()
Отвечать()

Что интересно: вы оба поместили на диаграмму классов Предмет - хотя его не было в описании задачи (!!!). Это пример того, как работают стереотипы у нас в голове. Для нас ведь совершенно не важно, по какому предмету сдается экзамен. Это лежит за рамками задачи. Вот если бы пример был из области, которая вам совершенно незнакома, лишних классов на диаграмме бы не появилось - вы бы просто не знали об их существовании.

эээ..у меня в диаграмме нет предмета...

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

че-то зачахла тема...

Я у себя в журнале разбираю задачки.
Отвечаю всем, если задача решаема средствами UML.

вот еще пример:



Задача: найти ошибку в этой модели и объяснить, в чем она заключается.

Направление поиска: ошибка в части отношений (пользуясь терминологией UML).


Это сообщение отредактировал(а) ida - 5.10.2009, 18:28