Форум Сообщества Аналитиков
Дисциплины => Обучение => Книги, статьи и ресурсы => Тема начата: Galogen от 18 Января 2007, 00:13:47
-
(http://www.books.ru/img/446753.jpg) (http://www.books.ru/shop/books/446753?partner=uml2)
UML 2. 0. Объектно-ориентированное моделирование и разработка, 2-е изд., Рамбо Д. (http://www.books.ru/shop/books/446753?partner=uml2)
Советую посмотреть внимательно. Книгу видел в магазине лично перед НГ, но жаба задавила - больно уж дороговата. Хотя судя по содержанию и стилю написания - очень стоящая книга.
Кстати по ссылке можно ознакомится и с комментариями читателей...
-
Книгу купил. Прочитал. Восторг. Чётко, понятно и на примерах. Обязательна к прочтению. Обязательна.
-
Slav, точно говоришь? Действительно стоит потратится?
-
Ну я потратился и не пожалел. Её же Рамбо написал.
-
Книгу купил.
В целом она мне понравилась. Много упражнений.
Есть предложение, а что если, учитывая один из возможных статусов нашего форума и сайта: образовательный портал, порешать командно упражнения книги, а потом разработь систему для самостоятельного занятия
-
Впечатление от книги.
Книга будет весьма полезна изучаеющим ряд дисциплин: моделирование систем, проектирование систем, анализ систем, базы данных, оо -программирование, проектирование.
В первую очередь на мой взгляд книга предназначена для преподавателей поскольку содержит многочисленные упражнение, ответы, рекомендации по рассмотрению отдельных моментов.
Книга не является справочником по UML и основам его применения, тем неменее все основные элементы UML изложены.
В качестве сквозного примера используется традиционная задача с банкоматом(словно других нет).
Изложение материала не привязано к какому-либо процессу разработки, но явно и неявно трактуется итерационная методика разработки приложений.
Некоторые вопросы рассмотрены слишком кратко, однако вероятно идея их использования - показать связь темы обсуждаемой в книге с другими проблемами: управлением проектами. оценки рисков, выбор языков программирования, базы данных
Книга в целом не проста в прочтении - требует внимания, параграфы написаны в очень сжатой форме по существу.
Единственная проблема - в книге указана возможность использования некоторого web-ресурса, однако адрес его не указан.
Единственная ссылка на http://www.modelsoftcorp.com, но там я нашел только примеры UML моделей. А гед расположено все 200 страничное руководство для преподавателей, так и не понял
-
Кто-нибудь читал? Книги сравнимы?
Не читал, но думаю книги различны.
У Рамбо с Блаха больше дается упор на основы, моделирование и проектирование.
-
Дочитываю книгу, из странного - несмотря на то, что книга названа UML 2.0, в ней вообще не рассматриваются диаграммы компонентов и развёртывания.
Изложено много вещей по проектированию системы, которые к UML вообще прямого отношения не имеют, в результате обошлись в соотв. разделе без единой диаграммы. Например, очень мало какая литература освещает такую задачу, как "концептуализация системы".
Есть некоторая мутаница в терминах - так я и не понял, входит ли по мнению авторов аналитическая модель приложения в аналитическую модель предметной области или является отдельной моделью.
Действительно хорошо раскрыто моделирование классов, состояний. С моделированием взаимодействий похуже.
В переводе Refactoring переведён как Реорганизация, что достаточно интересно, но нетипично. Вообще говоря, понятие реорганизации в русском языке не подразумевает автоматически изменение только внутренних свойств объекта. Может перекрываться по значению с Reengineering.
Не понравилось то, что не даются ссылки на литературу, детализирующие поверхностно охваченные темы. Например, упоминают в паре параграфов про тестирование, но никуда не ссылаются. То же относительно баз данных, требований и т.д. Не понравилось, что архитектурные стили не согласованы по терминологии с такими названиями, как "каналы и фильтры", "репозиторий", "MVC". Такое ощущение, что люди пишут в какой-то своей собственной среде, не принимая во внимания параллельные процессы, происходящие в отрасли.
В названии книги Design переведено как Разработка. Повбывав бы.
-
несмотря на то, что книга названа UML 2.0, в ней вообще не рассматриваются диаграммы компонентов и развёртывания
В книге довольно четко указывается, что это не руководство по UML 2.0. Для этого имеет смысл смотреть книгу "великолепной тройки" с соответствующим названием.
Направленность на UML 2.0 проявляется в некоторых деталях использования его возможностей в диаграммах классов главным образом.
Например, очень мало какая литература освещает такую задачу, как "концептуализация системы".
Так что? Это недостаток или достоинство книги?
ак я и не понял, входит ли по мнению авторов аналитическая модель приложения в аналитическую модель предметной области или является отдельной моделью
На мой взгляд авторы книги довольно четко проводят границу между анализом ПрОб и анализом приложения.
Анализ ПрОб акцентирован на объектах предметной области. Авторы предупреждают от использования в ДК классов уровня реализации.
При анализе приложения делается акцент на объекты и классы реализующие логику приложения. Модель взаимодействия здесь становится актуальной, так как приложение (через свои интерфейсы) - это то, что возможно требуется пользователю. При этом очень показателен ход рассуждения от общего понимания к структуризации этого взаимодействия, которое помимо диаграммы взаимодействия и текстовых сценариев ориентирует на использования диаграмм деятельности (для сложных случаев сценария) и диаграм последовательности.
Анализ диаграммы классов приложения ориентирован на опрделение пограничных и управляющих классов, появления и выделение классов приложения. Тут же становится актуальной и диаграмма состояний.
Т.е. каждый этап моделирования затрагивает в той или иной степени три главне модели: модель классов, модель состояний и модель взаимодействия.
Проблема корректного перевода действительно существует, но это не вина авторов, а переводчиков к сожалению или к счастию.
Как мне кажется книгу имеет смысл воспринимать как теоретические основы. В конце концов в ней изложены концепции авторов UML. А кому как не авторам наиболее глубоко и полно понимать, что же они вкладывают во все эти понятия
-
В книге довольно четко указывается, что это не руководство по UML 2.0. Для этого имеет смысл смотреть книгу "великолепной тройки" с соответствующим названием. Направленность на UML 2.0 проявляется в некоторых деталях использования его возможностей в диаграммах классов главным образом.
Эдуард, ты зря оправдываешься за авторов, они не виноваты. Я только сейчас понял, что в исходном английском названии слова UML 2.0 вообще нет! ) Это маркетинговый приём издательства Питер на волне web2.0 и прочей фигни для создания эффекта новизны и актуальности! Поэтому у меня и произошёл такой когнитивный сбой - типа люди называют это 2.0, а ничего про специфику новой версии и её плюсы и достижения не пишут.Так что? Это недостаток или достоинство книги?
Наличие глав про проработку концепции - это несомненный плюс.
-
На мой взгляд авторы книги довольно четко проводят границу между анализом ПрОб и анализом приложения.
Да, эти виды деятельности в книге разделены, но обрати пожалуйста внимание, что я говорил не про ВИДЫ ДЕЯТЕЛЬНОСТИ, а про МОДЕЛИ.
В частности, в начале главы 13 "Анализ приложения" можно прочитать:
В этой главе, завершающей рассках об этапе анализа, рассмотрены вопросы, связанные с добавлением основных артефактов приложения в модель предметной области из предыдущей главы. Эти артефакты исследуются на этапе анализа, потому что они важны для приложения, видимы пользователям и должны быть одобрены ими. Вообще говоря, классы приложения не обязаны присутствовать в предметной области, но их можно получить из вариантов использования.
Т.е. по сути авторы предлагают взять модель ПрОбл, полученную на предыдущем этапе, и расширить её понятиями, выявляемыми на этапе анализа приложения, оставив за ней таким образом название модели ПрОбл, даже хотя она таковой уже не является. Возможно, здесь просто неудачный перевод, и в оригинале речь идёт не о том, что "артефакты приложения добавляются в модель ПрОбл", а, например, что "вдобавок к модели ПрОбл создаются артефакты Приложения, формирующие модель Приложения".
Вообще у меня есть серьёзные сомнения насчёт уместности термина "Анализ Приложения", о чём в принципе немного упоминают и авторы. Анализировать, на мой взгляд, можно только нечто существующее, как-то - Предметную область, Требования, Систему. Если же системы нет, она только создаётся, то можно её только синтезировать, проектировать, конструировать, но не анализировать.
-
Вообще у меня есть серьёзные сомнения насчёт уместности термина "Анализ Приложения", о чём в принципе немного упоминают и авторы. Анализировать, на мой взгляд, можно только нечто существующее, как-то - Предметную область, Требования, Систему. Если же системы нет, она только создаётся, то можно её только синтезировать, проектировать, конструировать, но не анализировать.
Возможно тут проблемы перевода, возможно и нет. На мой не оченьискушенный взгляд, термин анализ тут применяется как системный анализ. Безусловно разработка приложения есть суть синтеза анализируемого решения. Под анализом же здесь понимается процедура формирования решения. Т.е. решение синтезируется на основании анализа, а анализ преполагает детальное рассмотрение.
Вообще не стоит путать понятие дейтельности, артефактов с собственно с моделью. Авторя ясно и многократно повторяют: есть три модели, три напраления моделирование: моделирование и модель структуры, модель состояний и модель взаимодействия.
Этапы изучения будущей системы или существующей проходят через разные уровни: концептуализация, формализация, проектирование, конструирование. Каждый этот уровень предполагает потребность, необходимость формирования всестороннего рассмотрения системы на этом уровне через построение 3 базовых моделей в той или иной степени детальности (зависит от уровня).
Таким образом этап деятельности называемый анализом ПрОб включает по замыслу авторов все три модели - модель структуры, модель состояний и модель взаимодествий ( в оригинале последняя молдеь не раскрывается - как не важная в данном цикле задач). Авторы конечно употребляют понятие модели предметной области, которая состоит из трех сторон - основная мысль авторов - избегать использования понятий, элементов и т.п. реализации.
На этапе анализа приложения формируется модель приложения, т.е. читай системы. Здесь по мнению авторов важным становится взаимодействие частей системы между сосбой и внешними пользователями. На данном этапе анализ продалжается, но уже сосредоточен на событиях, которые должны возникать при эксплуатации системы, при удовлетворении потребностей пользователей. Выделяются, обнаруживаются, понимаются, детализируются, то есть АНАЛИЗИРУЮТСЯ внешние события, нетипичные сценарии, исключительные ситуации, произовдится структуризация взаимодейстивия (что очень правильно, ибо на стади анализа предметной области такая структуризация будет только вредить и усложнять понимание, а на стадии анализа приложения - это уже внутреняя работа разработчика). Синтез никогда не происходит без анализа. Заметь у автора везде указывается: проверка того-то по тому-то, а проверка разве не есть анализ?
Кроме того анализируется как раз НЕЧТО существующее, т.е. некоторое умозрительное представление
-
Возможно тут проблемы перевода, возможно и нет. На мой не очень искушенный взгляд, термин анализ тут применяется как системный анализ. Безусловно разработка приложения есть суть синтеза анализируемого решения.
Что такое "Разработка приложения"?
Под анализом же здесь понимается процедура формирования решения. Т.е. решение синтезируется на основании анализа, а анализ преполагает детальное рассмотрение.
Решение всегда принимается на основании рассмотрения вариантов, пусть даже вырожденно - одного. Пока нет ни единого варианта - анализировать нечего. Варианты могут быть заёмные (из других систем и оптыта), а могут быть вновьсинтезируемые.
Вообще не стоит путать понятие дейтельности, артефактов с собственно с моделью.
А я и не путаю, я говорил именно о модели (предметной области, приложения), откуда она берётся, что включает, с какими связвана.
...На этапе анализа приложения формируется модель приложения, т.е. читай системы. Здесь по мнению авторов важным становится взаимодействие частей системы между собой и внешними пользователями. На данном этапе анализ продалжается, но уже сосредоточен на событиях, которые должны возникать при эксплуатации системы, при удовлетворении потребностей пользователей.
....
Выделяются, обнаруживаются, понимаются, детализируются, то есть АНАЛИЗИРУЮТСЯ внешние события, нетипичные сценарии, исключительные ситуации, произовдится структуризация взаимодейстивия (что очень правильно, ибо на стади анализа предметной области такая структуризация будет только вредить и усложнять понимание, а на стадии анализа приложения - это уже внутреняя работа разработчика). Синтез никогда не происходит без анализа. Заметь у автора везде указывается: проверка того-то по тому-то, а проверка разве не есть анализ?
Прежде чем анализировать события, надо построить модель будущей системы, а потом уже анализировать.
Кроме того анализируется как раз НЕЧТО существующее, т.е. некоторое умозрительное представление
В момент описания будущей системы, умозрительного, достаточно хорошего представления системы ещё не существует.
-
Без слов
http://www.uml2.ru/forum/index.php?topic=96.0
-
Без слов
http://www.uml2.ru/forum/index.php?topic=96.0
Зря без слов, кстати. Смотри, где расположена эта тема:
UML2.ru: Форум по Требованиям, Проектированию, ТЗ, UML, SysML, IDEF, ARIS, BPMN, RUP, OUP, CMMI, MDA, Agile, Сообщество, Примеры
Дисциплины
Проектирование (Модераторы: bas, Денис Бесков)
Книги: UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.
Попробуй догадайся, что нужно пройти именно по этой ветке иерархии.
В качестве дополнительного упражнения попробуй воспользоваться поиском форума, забив название книги в строку поиска:
"UML 2.0. Объектно-ориентированное моделирование и разработка"
Результаты впечатляют. Поисковый движок в качестве релевантного результата, по-видимому, представил пост, содержащий больше всего букв "и". :)
-
Перенес тему с аннотацией в раздел "Аннотация книг/статей/ресурсов" и объединил две темы про одну и ту же книгу.
-
А если использовать расширенный поиск? Не пробовал? :)
-
Отчего бы лишний раз не похвалить книгу Рамбо и Блахи. Как у руководства по диаграммам классов и диаграммам состояний у неё мало соперниц. И как у сборника задач по UML. Другое дело, что перевод условий задач таков, что "методичку"-решебник, выпущенную для преподов издательством Pearson, использовать вместе с переведённой книгой затруднительно. К перетолмаченным формулировкам условий авторские решения часто не подходят.