Форум Сообщества Аналитиков

×


Контрольная по ООП.(Прочитано 7286 раз)
Контрольная по ООП. : 06 Мая 2010, 20:10:55
Добрый вечер.

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

С UML столкнулся впервые. Учусь на заочном. Преподаватель прочитал несколько лекций по книге Г.С. Ивановой "Объектно-ориентированное программирование" и практически показал как это примерно делается, на одном примере (предметная область - Библиотека). И вот с таким багажом пришлось делать контрольную...

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

P.S. Если будет необходимо выложу файл модели (Rational Rose).



Re: Контрольная по ООП. Ответ #1 : 07 Мая 2010, 09:11:04
А какую оценку вы ожидаете?



Re: Контрольная по ООП. Ответ #2 : 07 Мая 2010, 14:40:49
А какую оценку вы ожидаете?

 Я ожидаю оценку правильности моей работы. Хотя бы в общих чертах.

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




Re: Контрольная по ООП. Ответ #3 : 07 Мая 2010, 16:54:52
Алекс,

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

С одной стороны сама работа выглядит добротной. Или шаблон хороший, или объяснения были четкие.

С другой стороны есть ощущения попытки использовать UML ради самого UML.

Для начала не очень понятна цель применения вариантов использования.

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

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

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

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

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

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

Но меню оно же не само по себе, оно на чем-то расположено? Справка - термин куда-то выводится, подробное его описание тоже где-то проявляется

Цитировать
меню, следующий термин, предыдущий термин, заданный термин, запись, файл, имя файла, сообщение об отсутствии информации.

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

Не совсем ясно, что тут имелось в виду.

Диаграммы состояний объектов не ясны, не ясен смысл их изображения и выбор объектов.

Непонятно разделения чего-то на два объекта Следующий и Предыдущий, не понятно, куда девался Текущий.

Если бы был объект Запись, у которого есть признак-состояние Текущая, Следующая, Предыдущая, Первая, Последняя, ну тут было бы понятнее.

Поиск - все таки это процесс. Процесс - безусловно смена состояний во времени. Но состояние это характеристика объекта. Тогда не понятно что описывает диаграмма состояний Поиск. ДС какого объекта - всей программы в целом?

Диаграмма последовательностей действий для какого сценария описывается - а ведь она описывает именно реализацию (возможную) сценария варианта использования. А у Вас похоже все в кучу

Ну про диаграмму компоновки и размещения я умолчу.

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

Как-то так



Re: Контрольная по ООП. Ответ #4 : 07 Мая 2010, 18:25:36
Эдуард,

большое спасибо за быстрый ответ и, особенно, за столь детальную оценку моей работы!

Цитировать
С другой стороны есть ощущения попытки использовать UML ради самого UML.

Тут Вы попали в самую точку!!! Это и есть использование UML ради самого UML. Цель этого задания - научить нас моделированию систем при помощи UML. Вы же заметили, что использована очень простая предметная область и в реальной жизни для нее никогда бы не потребовалось использование средств моделирования. Например, если б было нужно сделать заданный текст помощи средствами программирования, то в C++Builder на эту программу у меня ушло бы порядка получаса и я бы никогда бы не додумался использовать в этих целях UML (даже если бы я его хорошо знал). Но ведь задание было четкое - использовать все виды спецификаций и все виды диаграмм UML.  И вот только по этому пришлось делать:

Цитировать
Ну про диаграмму компоновки и размещения я умолчу.

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



Re: Контрольная по ООП. Ответ #5 : 07 Мая 2010, 20:44:58
Тут Вы попали в самую точку!!! Это и есть использование UML ради самого UML. Цель этого задания - научить нас моделированию систем при помощи UML.  И вот только по этому пришлось делать:
Понимаете использование UML в Вашем случае может быть вполне корректным. Правда применять use case может быть не нужно. Ведь модель взаимодействия не ограничивается use case.

Диаграммы состояний следует применять для объектов, которые ДЕЙСТВИТЕЛЬНО меняют свое состояние во времени, и это вызывает определенные события в системе. Указатель на такие объекты - это изменение значений атрибутов такого объекта во времени его жизни.

ООП вполне можно было применить в вашем случае, если развить сначала концептуальную модель справочной системы. Далее определив системные события (в первую очередь внешние), можно выделить системные функции.

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

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

Они уже формируются в компоненты и далее уже можно показать размещение этих компонентов по процессам.

Понятна цель преподавателя, правда каков из этого результат? Вот вопрос... Оценку то какую поставили?



Re: Контрольная по ООП. Ответ #6 : 07 Мая 2010, 23:12:28

Цитировать
Понятна цель преподавателя, правда каков из этого результат? Вот вопрос... Оценку то какую поставили?

Сессия начнется 13.05, поэтому пока никакой оценки нет. Собственно, по этому предмету у нас - зачет и судя потому, что, я наверно снова буду единственным, кто сдаст контрольную - то проблем быть не должно. Другой вопрос, что учусь я по специальности - Информационные системы и технологии, и скорее всего UML еще у нас будет - и на 5-м курсе и особенно на дипломе (о чем нас настойчиво предупреждает этот преподаватель). Так что с UML мне еще придется разбираться поподробнее.

Спасибо за помощь!




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19