Еще цитаты

Разгребал тут файлы и нашел…

Сам он не имел охоты воевать – нелепое занятие для человека с ярко выраженной индивидуальностью.

Теодор Драйзер, Финансист

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

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

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

Это повесть о книгах, а не о злосчастной обыденности; прочитав ее, следует, наверное, повторить вслед за великим подражателем Кемпийцем: «Повсюду искал я покоя и в одном лишь месте обрел его – в углу, с книгою»

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

Ибо, по Боэцию, всего мимолетней наружность.

«Ты дьявол», – сказал тогда Вильгельм. Хорхе как будто не понял. Если бы он был зряч, я бы мог сказать, что он ошеломленно уставился на собеседника. «Я?» – переспросил он. «Ты. Тебя обманули. Дьявол – это не победа плоти. Дьявол – это высокомерие духа. Это верование без улыбки. Это истина, никогда не подвергающаяся сомнению. Дьявол угрюм, потому что он всегда знает, куда бы ни шел – он всегда приходит туда, откуда вышел.

Ты не тревожься, что доселе их нет. Это не значит, что их и не будет. Я скажу тебе: Господу угодно, чтобы были они, и истинно уже существуют они в Его помысле, хотя мой друг Оккам и отрицает вероятность подобного существования идей. Но отрицает не оттого, что отгадывать помыслы Божии предосудительно, а напротив, оттого, что число отгадок неограниченно».

Умберто Эко, Имя розы

Всякая стадность — прибежище неодаренности, все равно верность ли это Соловьеву, или Канту, или Марксу. Истину ищут только одиночки и порывают со всеми, кто любит её недостаточно. Есть ли что-нибудь на свете, что заслуживало бы верности? Таких вещей очень мало. Я думаю, надо быть верным бессмертию, этому другому имени жизни, немного усиленному.

Борис Пастернак, Доктор Живаго

Однажды, сидя в саду, молодой Августин, — тот самый, что потом крестится в Милане, городе Мартини, а еще много лет спустя станет святым, — услышал голос, говорящий: «Возьми и читай».

Умберто Эко, Диалог о вере и неверии

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

Федор Достоевский, Бесы

«Проектирование процесса проектирования» Ф.Брукса

Книга классика. Очень интересная точка зрения и ясное обоснование. Местами скучновато.

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

Итерацию целей, следует считать неотъемлемой частью процесса проектрования.

Если модель технической рациональности … не способна учитывать практическую пригодность в «расходящихся с действительностью» ситациях, тем хуже для модели.

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

«Дефрагментация мозгов. Софтостроение изнутри» Сергея Тарасова

Эту книгу я прочитал очень быстро. За 2 дня. Читал в метро, маршрутке и даже шагая по улице. Давно со мной такого не было и ничего удивительного, так как данная книга написана простым, житейско-программистским языком и является отличным образцом беллетристики.

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

Несколько цитат, как обычно.

Согласно сведениям IBM, сообщество Java-разработчиков уже к 2006 году насчитывало более 6 миллионов человек.

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

Или вот еще про шаблоны проектирования по мотивам GoF.

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

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

Немного подпортил впечатление о книге раздел, посвященный UML. Хотя многие вещи подмечены правильно, автор делает неверные выводы, так как похоже не обладает достаточной практикой использования UML в реальных проектах. Описание процесса разработки, основанного на использовании вариантов использования, которые автор упорно называет прецедентами, меня сильно насмешил. И как можно так извратить идею? Типичный пример того, как разработчики используют то, в чем совершенно не разбираются.

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

Заключение: книга однозначно рекомендуется к прочтению!

Отношения между вариантами использования

Между вариантами использования существует три вида отношений.

Первый вид — обобщение, т.е. отношение «общее» — «частное».

«Собрать урожай» — это «общее», а остальные варианты использования его частные случаи. Заметьте, что «общее» абстрактно, т.е. в реальности (на уровне экземпляров) невозможно «собрать урожай», можно либо «собрать урожай картошки», либо «собрать урожай морковки», либо «собрать урожай лука».

Второй вид — включение.

Включение подразумевает безусловное вхождение одно варианта использования в другой. «Собрать урожай» — это нечто конкретное, в которое входит и сбор картошки, и сбор морковки, и сбор лука.

Ну и третий вид — расширение.


Расширение — это включению по условию, т.е. «собрать урожай» — это значит собрать картошку (если она выросла), собрать морковь (если она выросла) и собрать лук (если он вырос).

Заявление о прекращении сотрудничества с АйТи Подготовкой

Уважаемые коллеги, доводим до вашего сведения, что мы — Наталья Желнова, Денис Иванов, Федор Новиков и Алексей Петров завершили сотрудничество с г-ном М. Финковым и его проектом АйТи Подготовка по ряду причин личного и профессионального характера.
Все тренинги по UML и работе с требованиями мы проводим самостоятельно.

6 апреля 2013

Моделирование на UML – online

В начале мая, а если получится и раньше, собираюсь запустить проект «Моделировние на UML – online» (подписаться на рассылку можно здесь).

Проект будет представлять собой интернет-версию нашей книги «Моделирование на UML», которая вышла 3 года назад.

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

Интернет-версия книги будет содержать только ту часть бумажной, которая непосредственно касается UML (Unified Modeling Language), а это где-то 70-80% от всего объема книги.

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

Те, кто подпишется на рассылку, смогут еще до открытия получать доступ к уже выложенным на сайте материалам.

Спасибо за внимание.

Могут ли на диаграмме классов присутствовать объекты?

На этот вопрос нет правильного ответа.

Если подходить логически, то получается следующая ситуация:
С одной стороны вроде не могут, так как для классов есть диаграмма классов, а для объектов предназначается диаграмма объектов.
Но с другой стороны в UML есть отношение зависимости со стереотипом instance of, которое соединяет классификатор и его экземпляр, т.е. например, класс и объект. Если смотреть с этой стороны, то получается, что данное отношение нигде не нарисовать.

Если подходить житейски, то важно понимать, что диаграммы — это договоренность, обусловленная практикой. Договорились, что на диаграмме классов показываются классы и отношения между ними, а на диаграмме объектов, соответственно, объекты (экземпляры классов) и связи (экземпляры ассоциаций). Но никто не мешает создать новые диаграммы или изменить старые.

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

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

Когда и как нужно использовать пакеты в UML?

Целесообразно рассматривать два вида пакетов: пакеты высокого уровня и пакеты низкого уровня (это моя классификация).

Сразу приведу пример.

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

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

Если вы пользуетесь каким-либо инструментом для моделирования, то скорее всего он поддерживает несколько предопределенных наборов подобных пакетных структур. Их называют представлениями (view).
Можно сказать, что пакеты высокого уровня – это более детальное описание представлений.

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

Конечно при этом никто не запрещает вам придумать свои конфигурации, но как показывает практика хороший результат придет по прошествии времени.

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

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

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

Единственный (для меня) реальный вариант использования пакетов низкого уровня – моделирование файловой системы, когда в качестве папок используются пакеты, а файлы представляются в виде артефактов.

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

О пользовательском интерфейсе

Ниже мои мысли по поводу правил проектирования пользовательского интерфейса (которые в основном касаются web-приложений).

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

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

Только когда такой уровень декомпозиции достигнут — можно начинать проектировать пользовательский интерфейс.

При проектировании нужно иметь в виду следующее.

Когда пользователь заходит на сайт ему нужен ответ на некоторый вопрос.
Задача проектировщика пользовательского интерфейса состоит в том, чтобы как можно скорее дать пользователю понять — сможет ли он найти здесь ответ на свой вопрос или нет.
И если ответ положительный — сможет, то путь до ответа должен быть предельно ясен: имея возможность кликнуть на 10 разных кнопок пользователь должен с первого раза без тени сомнения указать ту кнопку, которая приведет его к ответу.

Композиция и агрегация

В чем отличие композиции от агрегации?

Сначала поговорим о том, что в них общего. Композиция и агрегация — частные случаи ассоциации «часть-целое».
«Часть-целое» — это просто семантическое уточнение ассоциации. Иногда оно полезно.

Отличие в нотации, как показано — цвет ромбика на полюсе «целого».

Различие между композицией и агрегацией выявляются только на уровне объектов и состоит в том, что на полюсе композиции кратность равна 0..1 (это написано в спецификации UML), а значит, в случае композиции экземпляр «части» может входить только в одно целое (или никуда не входить), в то время как в случае агрегации экземпляр «части» может входит в несколько целых.

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

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