UML
Поскольку я в разное время работал и начальником отдела программирования и начальником сектора программирования, то мне приходилось координировать работу множества программистов. В то время, когда я этим занимался, обьектное программирование было экзотикой - и все делалось по старинке, с помощью обыкновенного процедурно-ориентированного программирования (частично сверху вниз, частично снизу вверх) - т.е люди, работавшие с самым низким уровнем, говорили, что им надо на вход для работы с сетью, с системой и с оборудованием, а сверху (от заказчика) мы получали сигнатуры для обращения к нашему продукту. А далее все распределялось по уровням, определялись сигнатуры методов и функции каждого метода. Тогда уже каждый программист мог отдельно от других писать свой кусочек. В такой схеме самая большая нагрузка ложилась на меня, на координатора проекта, надо было перераспределить все фукнции по уровням, определить каждому его интерфейсы. Плюс бесконечные поправки по ходу дела, которые выражались в миллионе всяких дополнительных флажков в числе необязательных параметров. Работать было невыносимо тяжело, я увязал во множестве вспомогательных деталей и терял нить проекта в целом - в общем, чувствовалось, что процесс проектирования идет не так как надо...
Это сейчас CASE-средства в связи с их необычайной важностью уже прочно вошли даже в институтские программы, а в то время никаких графических средств проектирования не существовало. Единственными инструментами графического описания программ были деревья (ох, не раз приходилось мне писать сортировки), конечные автоматы (применялись для проектирования компиляторов, я лично пользовался ими для фиксации состояний программы и таблицы переходов, когда было много глобальных переменных). Но в процедурно-ориентированном программировании в небольших проектах даже потребности в более продвинутых графических средствах не было (для описания линейного поведения программы вполне хватало блок-схемы алгоритма). А вот в обьектно-ориентированном программировании - где нет начала и конца - лишь от движения мышки на одном компьютере где-то совсем на другой машине неожиданно и незапланированно выпрыгивают какие-то события, меняющие состояние программы - вот тут нужны гораздо более изощренные средства даже для небольших проектов. А поскольку обьектно-ориентированное программирование уже захватило весь этот мир, то со временем средства формализации и графического проектирования программ стали интересовать меня все больше.
В общем, несмотря на то, что ушел с этой работы, я все равно не переставал интересоваться - а как же все-таки облегчить процесс координации труда программистов. Сначала я узнал о методике MSF(Microsoft Solution Framework) - купил книжку по этой методике и прочитал ее. Но чесно говоря, она меня не впечатлила - пережевывается жвачка про трехуровневую архитектуру, фазы проектирования: анализ, планирование, тестирование и т.д. - все это и так давно известно... Позже я узнал и о других методиках проектирования программ: XP (eXtreme Programing), CDM Advantage(Oracle) , ASD (Adaptive Software Development) и, наконец, RUP (Rational Rose Process). Последняя мне показалась наиболее интересной.
Но, до самого последнего времени, само по себе программирование под .NET никак не завязывалось в моей голове в один узел с UML:
- Я давно рисую всякие картинки в MS VISIO, которое рекламируется Microsoft как средство построения UML-диаграмм. Но фактически, ничего, кроме примитивных рисунков, никак с программами не связанных, в Visio сделать нельзя.
- Visual Modeller из состава Visual Studio 6 тоже меня не впечатлил, т.к. опять же это опять получалась посторонняя приблуда, никак непосредственно с программированием не связанная.
- А вот Visual Paradigm показался мне уже на порядок более серьезным средством, ибо обладал тремя неотъемлимыми качествами настоящего помошника программиста:
=====> Автоматическая генерация программного кода по UML диаграмме,
=====> Reverse Engineering, т.е. обратное построение UML-диаграммы по готовому программному продукту,
=====> И наконец, автоматическая синхронизация программирования и его документирования в UML-диаграммах.
К моему великому сожалению, это средство работало только на Java, которую я не знаю. - Все то же самое можно сказать и о Rational Rose.
- Некоторое время у меня стоял Objecteering/UML Modeller, однако моя бесплатная Personal Edition кода на VisualBasic не генерировала, а ключей для других редакций я не нашел, чтобы проверить ее совместную работу с .NET Framework.
Но вот случилось чудо - просматривая новые книги, выпущенные издательством Sybex, я обратил внимание на вот эту книгу. Просмотрев оглавление и примеры, я понял, что теперь все идеи UML работают не только в Rational Rose на J2EE, но и на майкрософтовской платформе. Это произошло после того, как компанию Rational купило IBM. Теперь, оказывается у IBM теперь есть не только DOMINO, J2EE-студия и DB2, но и вся линейка продуктов от Rational. Из которых самая (на мой взгляд замечательная штука - Rational XDE Developer для Visual Studio NET. И эта самая штука настолько замечательно интрегрирована в .NET студию, что вручную писать что-либо даже не хочеться! Естественно, есть и Reverse Engineering и автоматическая синхронизация программного кода и диаграмм и генерация программ по диаграммам и шаблоны в XML-файлах. Все отлично задокументировано и работает совершенно без глюков. Как приятно, что в NET студии теперь уже не нужно как раньше возиться с пикселами и байтами, а так, только рисовать квадратики - а пикселы и байты создадутся сами. Понравилось мне все, даже то, как сложные диаграммы, с событиями, переходами и пр. экспортируются в XML-формат. Кстати, минимальный размер памяти для запуска Rational XDE - 512M. Ну, еще чтобы работать с ним, вам придется решить вопрос с кодом активации. Никаких креков не надо, для активации нужен простой текстовый файл с расширением UPD, который вы легко найдете в Инете.
Тем, кто хочет сразу освоить XDE - я рекомендую посмотреть:
Кроме того, здесь я выкладываю полное описание собственно языка UML:
Очевидно, что очень многие вещи под .NET (начиная просто от HTML-форм до готовых WEB-приложений типа электронного магазина) если, конечно, полностью впитать всю эту технологию, теперь можно делать, наверное, еще раз в десять быстрее - я вижу в этом пик развития программной индустрии. Тем более - не какой-то там малораспространенный WebSphere Studio, а NET-Бейсик от Microsoft! А ведь сама по себе NET-студия (даже без этой приблуды) - просто реактивный лайнер по сравнению с шестой студией. Пока там в шестой студии переберешь на сервере переменые, чтобы узнать, что там взбрело в голову нажать юзеру на клиенте - может целый день уйти на обработку переменных ASP-состояния одной приличной страницы. А в NET-студии юзер только коснулся коснулся мышкой на клиентском компе, а у тебя на сервере - уже прыгает целая куча событий. Ну а если этим самым Rational XDE еще дальше ускорять разработку и документирование программ в NET-студии ...
)
|
|