UML и странные программисты
Ох вымучался за день с говнокодом, решил передохнуть, подумать о «высоком» и написать про UML.
UML - это «унифицированный язык моделирования». Решили у нас на факультете обучить этому языку студентов, курс назвали «проектирование сложных систем»… к несчастью попали и в меня. Года полтора назад я было пытался использовать uml, но он мне с самого начала как-то не понравился, но тогда я не смог для себя определить почему.
Вероятно, сейчас мне стоит сделать лирическое отступление, и пояснить одну важную деталь:
Само название «язык» для этого инструмента совершенно не подходит, дело в том, что, по сути, он предназначен для визуального представления некой информации. Проще говоря - рисования диаграмм. Языком же принято называть то, на чём можно написать некий текст человеческими руками…
По сему, для создания UML диаграмм используются графические инструменты, некоторые из них, такие как Rational Rose умеют очень многое, но и стоят при этом - мама не горюй, да и использовать его ужасно неудобно. Есть, конечно и бесплатные, такие как линуксовая Dia. Естественно, что студентов заставили использовать крякнутый демо версию Rational Rose... но это тема другого разговора.
Одним словом, передо мною была поставлена задача спроектировать информационную систему транспортного предприятия…
Естественно, я сразу представил где и как должна работать эта система. В UML нашёлся нужный тип диаграмм - use case (варианты использования).
И тут началось самое неприятное - модель классов. По сути, на этом этапе нужно полностью спроектировать систему… до мелочей, таких как приватные методы. Для тех, кто не понимает - поясню: если описаны все классы - останется только реализовать методы и нарисовать интерфейс.
Вот тут, прошу обратить внимание: чтобы определить список полей и методов класса, на данном этапе мне необходимо было иметь полное представление о проектируемой системе. Причём не только внешнее, но и внутреннее. Ещё раз оценив варианты использования, я начал продумывать реализацию - BIG MISTAKE читалось сегодня в глазах препода. Оказывается, задача системного архитектора - создать такие классы, которые будут универсальными… и никак не будут зависить от реализации.
Идея - безусловно красивая, но, скажу по секрету, порой далека от реальной жизни. Как и многие программеры, между прочим.
В реальной то жизни главное - выбрать правильный в данном случае уровень абстракции, подумать о совместимости вперёд, расширяемости, проблемах внедрения и тех, кому этот проект может достаться по наследству. Вообще, пока в голове не будет чёткого представления того кто и как сидит перед монитором - думать о классах, мягко говоря - рано.
Но дальше стало ещё веселее, оказывается, каждая мелочь должна быть классом. Это заблуждение сейчас стало жутко распостранено… даже строка сообщения, которая может быть переслана от пользователя к пользователю должна являться классом. Даже если у сущности нет никаких методов - это класс… Вот оно поколение java… выросло.
Одним словом преподы пытался со мной спорить даже, было смешно.
Проектирование сложной системы - это ведь не бездумное придумывание универсальных классов на все случаи жизни, витая в облаках диаграмм. Это подробное изучение предметной области, выбор средств реализации и только потом проектирование внутреннего устройства системы.
Спасибо за внимание, к этому, практически не читабельному тексту.
UML - это «унифицированный язык моделирования». Решили у нас на факультете обучить этому языку студентов, курс назвали «проектирование сложных систем»… к несчастью попали и в меня. Года полтора назад я было пытался использовать uml, но он мне с самого начала как-то не понравился, но тогда я не смог для себя определить почему.
Вероятно, сейчас мне стоит сделать лирическое отступление, и пояснить одну важную деталь:
Само название «язык» для этого инструмента совершенно не подходит, дело в том, что, по сути, он предназначен для визуального представления некой информации. Проще говоря - рисования диаграмм. Языком же принято называть то, на чём можно написать некий текст человеческими руками…
По сему, для создания UML диаграмм используются графические инструменты, некоторые из них, такие как Rational Rose умеют очень многое, но и стоят при этом - мама не горюй, да и использовать его ужасно неудобно. Есть, конечно и бесплатные, такие как линуксовая Dia. Естественно, что студентов заставили использовать крякнутый демо версию Rational Rose... но это тема другого разговора.
Одним словом, передо мною была поставлена задача спроектировать информационную систему транспортного предприятия…
Естественно, я сразу представил где и как должна работать эта система. В UML нашёлся нужный тип диаграмм - use case (варианты использования).
И тут началось самое неприятное - модель классов. По сути, на этом этапе нужно полностью спроектировать систему… до мелочей, таких как приватные методы. Для тех, кто не понимает - поясню: если описаны все классы - останется только реализовать методы и нарисовать интерфейс.
Вот тут, прошу обратить внимание: чтобы определить список полей и методов класса, на данном этапе мне необходимо было иметь полное представление о проектируемой системе. Причём не только внешнее, но и внутреннее. Ещё раз оценив варианты использования, я начал продумывать реализацию - BIG MISTAKE читалось сегодня в глазах препода. Оказывается, задача системного архитектора - создать такие классы, которые будут универсальными… и никак не будут зависить от реализации.
Идея - безусловно красивая, но, скажу по секрету, порой далека от реальной жизни. Как и многие программеры, между прочим.
В реальной то жизни главное - выбрать правильный в данном случае уровень абстракции, подумать о совместимости вперёд, расширяемости, проблемах внедрения и тех, кому этот проект может достаться по наследству. Вообще, пока в голове не будет чёткого представления того кто и как сидит перед монитором - думать о классах, мягко говоря - рано.
Но дальше стало ещё веселее, оказывается, каждая мелочь должна быть классом. Это заблуждение сейчас стало жутко распостранено… даже строка сообщения, которая может быть переслана от пользователя к пользователю должна являться классом. Даже если у сущности нет никаких методов - это класс… Вот оно поколение java… выросло.
Одним словом преподы пытался со мной спорить даже, было смешно.
Проектирование сложной системы - это ведь не бездумное придумывание универсальных классов на все случаи жизни, витая в облаках диаграмм. Это подробное изучение предметной области, выбор средств реализации и только потом проектирование внутреннего устройства системы.
Спасибо за внимание, к этому, практически не читабельному тексту.