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

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

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

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

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. Класс Студент
Методы:
Тянуть_билет()
Отвечать()

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

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

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