1. Предварительные замечания
Прежде чем приступить собственно к докладу, хотелось бы сделать несколько предварительных замечаний, касающихся темы сегодняшнего занятия.
1. Представляется целесообразным принять во внимание то обстоятельство, что у каждого сотрудника нашего отдела имеется доступ в Интернет, поэтому каждый может в любую минуту через поисковик получить интересующую его информацию. Дело в том, что в сети уже сейчас, даже на русском языке, имеется много информации на эту тему. Поэтому простое изложение этого материала вряд ли может представить большой интерес.
2. Можно было бы довольно долго рассуждать на темы, что такое CASE-средства, с чем их едят, как они используются в тех или иных организациях, как правильно их использовать. Если выражаться образно, можно довольно долго витать в CASE-облаках. Однако мы все работаем в одной и той же конкретной организации - РУМС. А раз так, то желательно постоянно помнить об этом и стараться по мере возможности не терять привязки к конкретике. То есть мы должны исходить в своей работе из интересов нашей организации и анализировать CASE-средства исходя именно из этого обстоятельства.
3. Очевидно, что в реальности мы не можем себе позволить купить любое CASE-средство, имеющееся на рынке, тут есть вполне определенные ограничения, у кого-то могут возникнуть языковые проблемы при работе с теми зарубежными средствами, которые пока не получили достаточно широкого распространения в России и, наконец, у всех нас есть текущая плановая работа, от которой нас все равно никто не освободит.
Указанные выше три обстоятельства - доступ к сети Интернет, привязка к потребностям РУМС и ограниченность выбора CASE-средств позволяет заметно сузить диапазон обсуждаемых сегодня проблем.
Прелюдия или эпиграф
Начну с анекдота об итальянском рыбаке.
"Лежит на берегу теплого Адриатического моря итальянский рыбак и н-и-ч-е-г-о не делает. Мимо проходят американские туристы и обращаются к рыбаку с вопросом.
· А что это Вы тут лежите, ничего не делаете, не зарабатываете деньги?
· А ЗАЧЕМ?
· Ну как, удивляются американцы, Вы могли бы больше работать и стать не просто рыбаком, а владельцем лодки.
· А ЗАЧЕМ?
· Вы могли бы еще больше работать и стать владельцем нескольких лодок.
· А ЗАЧЕМ?
· Вы стали бы крупным собственником, зарабатывали бы много денег и могли бы себе позволить отдыхать на берегу и ничего не делать.
· А Я ЧТО ДЕЛАЮ?"
Анекдот любопытный. Недаром его приводят в некоторых руководствах по стратегическому менеджменту… Ответ на вопрос: а зачем мне это надо каждый дает себе сам. К сожалению, вы не получите от меня ответа на вопрос: а зачем именно вам нужны CASE-средства. Ни сегодня, ни завтра. Каждый умирает в одиночку и на этот вопрос каждый отвечает себе сам. Я же постараюсь рассказать о своем опыте, о своей точке зрения, о своей версии ответа на этот ключевой вопрос и высказать свое мнение, которое отнюдь не претендует на универсальность.
Есть такая наука: ботаника. Пестики, тычинки, стебли, корни и листья.. Описание природы. Обычно словесное, но в письменной форме. Есть другая наука: болтаника. Сегодня мы займемся именно этим: болтаника на тему что такое CASE-технологии и как с ними бороться. Прошу набраться терпения минут так на 30-40 и постараться суметь вынести мои вольные разлагольствования на вышеуказанную тему в течение всего этого промежутка времени. На всякий случай прошу прощения у дам, если некоторые примеры покажутся им чересчур, так скажем, легкомысленными..
2. Термины и определения
2.1. О терминах
Как это часто бывает, под одним и тем же термином разные люди понимают каждый свое. В этой связи начну с довольно широко известного примера: трое слепцов пытаются дать определение термина "слон". Один держит его за хобот, другой за хвост и третий за ногу. Очевидно, что определения, выданные каждым из слепцов, будут разными, хотя речь все будут вести об одном и том же объекте - слоне. Аналогично обстоит дело с термином CASE - технологии. Если набрать в строке поиска термин CASE-средства или CASE-технологии, можно получить сотни документов, так что любой из вас может это сделать самостоятельно на своем рабочем месте и… читать до потери пульса. На что можно обратить внимание?
В большинстве источников по умолчанию предполагается, что читатель уже знает, что такое CASE-средства или CASE-технологии и, более того, знает, что же сам автор публикации понимает под этим термином. Представьте, что было бы, если бы те трое слепцов надумали писать книгу на тему: слоны - общий обзор и сравнительные характеристики. И на этом основании делали бы выводы о целесообразности практического использования слонов, например, при сборе бананов или ловле рыбы, причем сами они при этом не сказали бы читателю, что слон - это что-то типа веревки (хвост), трубы (хобот) или столба (нога). Что делать читателю? Куда податься? И что интересно: выводы у трех слепцов были бы, наверное, разными. При этом довольно очевидно, что вряд ли бы они нашли взаимопонимание даже друг с другом. Хотя все они являются специалистами по CASE-технологиям, то есть, я хотел сказать, по слонам. Слоноведы, в общем... Примем для простоты, что каждый из трех слепцов добросовестный, искренний, старается во всем, что называется, дойти до сути.. А потому смотрит, что же пишут про слонов другие.. И что он видит? Тот, который слона за ногу держит, говорит, что слоны - удобный стульчик при ловле рыбы. А тот, который держал слона за хвост, с этим не согласен: слон - удобное орудие ловли, что-то типа лески. И т.д. и т.п. И вот начинают они спорить.. Как говорится, результат любого их спора можно легко предсказать заранее: переход на личности, выяснение отношений и… Да что вы понимаете! Да как вы так можете - слона на стул.. Это же веревка! Сам такой… А третий будет молча ухмыляться в усы, - он же знает, что слон - это нечто вроде трубы и только посмеивается над этими двумя.. В лучшем случае каждый останется при своих.. Почему? Просто на старте они не договорились о терминах. Такое довольно часто бывает в жизни.
Спор о терминах - занятие бесплодное. В сети Интернет информация на тему CASE-средств довольно обширная - даже на русском языке, - поэтому, чтобы не вести утомительных дискуссий, и не вдаваться в тонкости, договоримся на старте, о чем будет идти речь на предстоящих занятиях.
Расшифровка аббревиатуры CASE: Computer Aided Software Engineering, что можно перевести на русский примерно как разработка программного обеспечения с помощью компьютера . В соответствии с ГОСТ 19781-90 Программное обеспечение - совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации. А если говорить проще: ПО - это программы, используемые в компьютере вместе с их описанием. И что же мы имеем? То есть разработка программ, используемых в компьютере, с помощью компьютера. Так? А как же писать их без компьютера? Это что же получается.. Ухаживать за девушкой с помощью… девушки.. А как же ухаживать за ней когда нет девушки? Вы можете себе это представить? Я - как-то смутно. Можно, конечно, из камня там Галатею тесать или музыку сочинять, особенно когда тебе делать больше делать нечего… В общем, ясно, что ничего не ясно. Как это: разрабатывать ПО с помощью ПК? Вопрос, конечно, интересный.. Давайте разбираться вместе.
2.2. Спускаясь на землю
Очевидно, что ПО бывает разное. В частности, прикладное и системное. Тут все просто: мы работаем в ОПО - структурном подразделении РУМС и по роду своей профессиональной деятельности многие из нас вовлечены в процесс разработки прикладного ПО.
Что говорят нам наши заказчики? Обобщенно это можно охарактеризовать так: напишите нам программу, чтобы работала. Что это означает, сами заказчики, как правило, сформулировать свои желания на формальном языке не могут. И дело тут не в том, что именно нам так не повезло, и что именно наши заказчики, скажем, не сильно задумываются над тем, что они говорят и/или пишут в своих справках и ТЗ. Дело совсем даже не в этом. Заказчики у нас самые что ни на есть нор-маль-ны-е. Такая ситуация характерна для большинства организаций-заказчиков. Заказчик часто сам не знает чего хочет или знает, но не говорит, или знает, но сказать не может.. Прям как собака.. И это - нормально. Как бы то там ни было, но мы здесь, в ОПО, не можем сидеть сложа руки и смиренно ждать, когда же наши заказчики сумеют писать нам готовые ТЗ, по которым вот так вот прямо вот сразу вот можно было разрабатывать программное продукты. В этой связи, кстати, в свое время был разработан стандарт РУМС "Жизненный цикл ПО", в котором все довольно подробно расписано: что, зачем, куда и почему. И те, кто его еще не читал, можно порекомендовать пользоваться им в своей практике уже сейчас при общении с нашими заказчиками. Но в этом стандарте ничего не говорится ни о CASE-средствах, ни об особенностях разработки ПО, и даже модели ЖЦ ПО (каскадная, водопадная и спиральная), по-моему, там не описаны даже. Это все - наша внутренняя кухня. И сегодня речь идет именно об этом: о нашей внутренней кухне.
Итак, мы занимаемся разработкой прикладного ПО по просьбам трудящихся. И пусть прикладывают скорее нас, чем мы, зато в нашей комнате тепло, сухо, уютно и мухи не кусают, за что мы должны прежде всего поблагодарить наше любимое руководство, которое мы все (надеюсь) любим, ценим и уважаем. По крайней мере, к тому, кто сейчас стоит перед вами, все это относится в полной мере.
Вопрос: а как же все таки можно использовать наши компьютеры для разработки этого самого прикладного ПО?
Когда речь идет о ПО, то его можно подразделить на простое и сложное. Чтобы опять-таки не спорить о терминах, сделаем сразу оговорку: простым будем называть ПО, которое задумывается, разрабатывается, сопровождается и используется одним и тем же человеком. Ну, а сложное ПО разрабатывается коллективом разработчиков. В литературе сейчас уже практически общепризнано, что применение CASE-средств оправдано (целесообразно) именно при разработке сложного ПО, когда в одной и той же работе задействованы несколько человек, и когда ставится задача повысить производительность труда, улучшить качество программных продуктов, поддержать унифицированного и согласованного стиля работы и т.д. и т.п.
Для тех, кто не читал книгу Гради Буча "Объектно-ориентированный анализ и проектирование", возможно, будет интересно узнать, а другим же просто напомню, что его классический труд начинается со следующего анекдота.
Врач, строитель и программистка спорили о том, чья профессия древнее. Врач заметил: "В Библии сказано, что Бог сотворил Еву из ребра Адама. Такая операция может быть проведена только хирургом, поэтому я по праву могу утверждать, что моя профессия самая древняя в мире". Тут вмешался строитель и сказал: "Но еще раньше в Книге Бытия сказано, что Бог сотворил из хаоса небо и землю. Это было первое и, несомненно, наиболее выдающееся строительство. Поэтому, дорогой доктор, вы не правы. Моя профессия самая древняя в мире". Программистка при этих словах откинулась в кресле и с улыбкой произнесла: "А кто же по-вашему сотворил хаос?"
Как говорится, в каждой шутке есть доля шутки. Когда речь идет о необходимости разработки сложного (или, по терминологии Гради Буча, промышленного) ПО, возникают свои, довольно специфические проблемы, которые, возможно, и на самом деле могут быть в некоторых случаях преодолены за счет целенаправленного и осознанного использования CASE-средств, - кто знает?
Итак, мы сегодня будем говорить о CASE-средствах, то есть средствах, которые помогают разрабатывать ПО, и при этом будем иметь в виду, что заказчики у нас самые что ни на есть нормальные, но проблемы от этого, к сожалению, проще не становятся.
3. CASE-средства: как выбирать?
Итак, напомним себе тему сегодняшнего занятия - см. заголовок. Очевидно, что интерес представляет вопрос о том, какие из имеющихся сегодня на рынке и в то же время доступных нам CASE-средств мы уже сегодня можем использовать в своей практической деятельности при разработке ПО.
В литературе можно найти много хороших, красивых, умных слов о том, что такое CASE-средства, для чего они используются, что с ними можно делать, и как они позволяют нам сэкономить силы, время, деньги, нервы, здоровье и т.д. и т.п. Ну, в общем, каждый может сам читать много хорошего на эту тему. В Интернете уже столько дифирамбов на эту тему имеется, что иногда волей-неволей возникает желание сказать: "Не надо агитировать меня за Советскую власть".. Или, как людоедка Эллочка, "Не учите меня жить.. Лучше помогите материально".. В переводе на русский это будет означать, дайте мне ответ на вопрос: какое средство и где применять? В сети информация и на эту тему чрезвычайно обширна. Можно проводить долгие часы у экранов мониторов и читать, читать, читать.. Аналогично, можно было бы сейчас болтать, болтать, болтать.. Смысла во всем этом занятии я лично не вижу. Предлагаю сейчас порассуждать на эту тему, исходя из элементарного здравого смысла.
Сначала о том, из чего можно выбрать. По мнению А. Вендрова [1], на сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
-
Vantage Team Builder (Westmount I-CASE);
-
Designer/2000;
-
Silverrun;
-
S-Designor;
-
CASE.Аналитик;
Очевидно, что этот список далеко не полон. В одном из обзоров я наткнулся на такую цифру: кто-то не поленился и подсчитал, что всего имеется уже порядка 300 различных CASE-средств. При этом, как обычно, во всех публикациях самым лучшим, самым универсальным и т.д. и т.п., - короче, самым хорошим по утверждению того или иного автора, является именно то средство разработки, которым он пользуется. Причины тут понятны, в некоторых случаях кто платит, тот и заказывает музыку, в других - автор исходит из того, что у него есть под рукой. В общем, CASE-средств в мире много. Будем из этого исходить. В то же время, все мы хотим быть богатыми и здоровыми, однако количество больных и бедных в мире от этого нашего желания почему-то не уменьшается. Поэтому из самых общих соображений можно догадаться, что раз уже в мире пока нет единого универсального CASE-средства на все случаи жизни, значит, у всех у них есть какие-то свои достоинства и недостатки. Не так ли? Как же не утонуть во всем этом океане?
3.2. Компас в океане CASE-средств
Позволю себе небольшое лирическое отступление. Небольшой диалог Алисы с Чеширским котом из книги Льюиса Кэрролла, которую я очень люблю.
- Скажите, пожалуйста, куда мне идти?
- А куда ты хочешь попасть, девочка?
- А мне все равно…
- Тогда все равно, куда идти..
Возвращаясь к нашим CASE-средствам: если мы сами не знаем, зачем они нам нужны, тогда все равно, какое из них выбирать. Поэтому главная проблема состоит не в том, чтобы выбрать одно из 300, а в том, чтобы понять и ответить на следующий ключевой вопрос: а зачем? То есть, зачем нам вообще нужны в РУМС CASE-средства? Только после того как ответ на этот ключевой вопрос будет получен, можно двигаться далее. Таким образом, стрелка нашего CASE-компаса всегда смотрит на север, то есть на надпись: "А зачем мне это надо?"
Чтобы попытаться найти ответ на этот вопрос, что абсолютно необходимо сделать до того, как мы будем проводить общий обзор и тем более анализ имеющихся на рынке CASE-средств, вернемся назад, к себе, в РУМС. Очевидно, что я могу отвечать только за себя. И буду искать свой вариант ответа. И предложу его сегодня на всеобщее обозрение.
Возвращаясь к Чеширскому коту и итальянскому рыбаку, зададим себе следующий вопрос: а зачем нам это надо, - применять какие-то там CASE-средства, когда это здесь, в РУМС, никому это не нужно, когда все равно ничего не изменится, выше головы не прыгнешь, никто не оценит и… премию за это не выпишут… И вообще: начальство у нас не сильно интересуется информационными технологиями и убедить их в необходимости закупки лицензионного ПО довольно затруднительно, и т.д. и т.п. Знакомо? Вспоминая классика: "Эх, ребяты, все не так, Все не так, как надо…" Перечень претензий может быть продолжен в курилке или здесь - не суть важно. Как говорится, каждый умирает в одиночку. И если у кого-то есть желание лежать на берегу Адриатического моря и любоваться на закат, он может продолжать это делать, по крайней мере до тех пор, пока не получит гм.. пинок от руководства или хотя бы морковку…
Итак, CASE-средства, - это средства, помогающие нам разрабатывать сложное ПО с помощью компьютера. О необходимости унификации разрабатываемого ПО, создания каких-то универсальных модулей, библиотек и т.д. и т.п. говорится в этих стенах давно. У многих есть предложения, что и как делать.. В общем, не будем перечислять все эти знакомые нам всем проблемы, болячки и т.д. Обратимся лучше к примерам. Вот почему-то никого не удивляет, что, когда мы приходим в местную поликлинику на прием, там есть кабинеты окулиста, терапевта, хирурга и т.д. и т.п. То есть медицина - это одно, а вот что касается информационных технологий, то… Если развить эту аналогию дальше, можно сказать, что программист - это аналог термина "врач". Не так ли? Но у каждого из нас есть своя узкая специализация..
Я стать хотел геологом, дерматовенерологом,
Потом хотел я быть, как мама, гинекологом,
А стал невропатологом назло врагам!
Теперь лечу их молотом по головам…
А. Розенбаум
Итак, уж нам-то промеж собой вряд ли нужно объяснять, что все мы тоже специализируемся каждый в своей области. Я вот стал невропатологом, то есть, я хотел сказать, занимаюсь разработкой информационных моделей отдельных структурных подразделений РУМС и всего РУМС в целом. Отсюда вытекает и выбор того инструментария, которым я пользуюсь; и в самом деле, не будет же хирург делать операции молоточком.. Верно? Так и тут.. В общем, на эту тему у нас будут отдельные занятия, а пока вернемся к нашим ба… то есть к CASE-средствам.
Я уж вернусь к себе и изложу свою точку зрения, не претендуя на какие-либо обобщения. Но особо подчеркну: пока ответ на этот вопрос не получен, все остальные усилия бессмысленны. Тогда все равно куда идти..
4. CASE-средства - что с ними делать
4.1. Ответ на вопрос: А зачем?
Итак, мы уже договорились, что под CASE-средствами мы будем понимать средства, помогающие нам разрабатывать ПО с помощью компьютера и пока мы не ответим хотя бы сами себе на вопрос о том, а зачем нам это нужно - CASE-средства какие-то, выбирать и сравнивать смысла большого не имеет. Как говорит Чеширский кот, тогда все равно, куда идти..
Как у нас обычно разрабатывается ПО? Мы - не свободные художники. У каждого из нас есть вполне определенный план, утвержденный Главным инженером РУМС. В этом плане подробно расписано, кто чем занимается. План висит на стенде. Откуда появились пункты из этого плана? - Ясно дело, все делается по просьбам трудящихся.
Примем в качестве аксиомы следующее утверждение: мы обязаны, то есть нам это нужно, - выполнять указания Главного инженера и просьбы наших заказчиков. Обоснование: нам именно за это здесь деньги платят. Мне кажется, обоснование довольно серьезное. И именно в этом контексте будем искать ответы на вопрос, какие именно CASE-средства нам нужно использовать. Тогда как следствие, получаем ответ на вопрос Чеширского кота: мы хотим выполнить Календарный план ОПО РУМС.
В списке задач ОПО 70 позиций, - это и тарификация (биллинг и предбиллинг), анализ аварии, статистики, программы учета и т.д. Многие из них так или иначе основаны на анализе информации, идущей от станций АХЕ10-1 и АХЕ10-2. Задачи очень серьезные, масштабные и сложные. Главная сложность состоит в том, что постоянно приходят все новые и новые вводные в форме справок, запросов, служебных записок и т.д. и т.п. Как говорится в той же классической книге Гради Буча, почему-то когда строитель строит 100-этажный дом, то когда уже выстроены верхние этажи, никому не приходит в голову просить строителя переделать или расширить фундамент. А у нас это сплошь и рядом. В чем тут дело, какие выходы могут быть, - например, во внедрении спирального ЖЦ ПО или другие, лучше пусть судят те, кто сам ежедневно с этим сталкивается. Я же лучше обращусь к тем проблемам, с которыми пришлось столкнуться мне, и уже на этом - своем - примере показать и рассказать, какое именно CASE-средство было выбрано для решения поставленных задач и почему именно оно, а не какое-то другое. Вот это и будет обзором и анализом сравнительных характеристик.
4.2. Мой опыт
Примерно год назад мне была поставлена задача, которую кратко можно сформулировать следующим образом: описать технологии и построить информационные модели структурных подразделений РУМС… И далее - список подразделений.. Получив такое задание в начале 2003 г., я довольно долго чесал репу, что же мне делать и как же мне быть.. Думал на самом деле долго.. В конце концов написал отчет на тему "Моделирование РУМС", в котором, что называется, высказал все, что думал по поводу полученного задания. Пар выпустил. Кому интересно, может почитать, мне не жалко. К моему удивлению, несмотря на все эти мои выкрутасы, с работы меня тем не менее все таки не выгнали, чему я, не скрою, очень даже рад. Потому что после длительной и продолжительной болезни, то есть, раздумий, сомнений, колебаний и размышлений была методом проб и ошибок выработана итерационная процедура описания технологических процессов, структуры и информационных моделей подразделений РУМС, которая в настоящее время реализована для ряда структурных подразделений.
На следующих занятиях мне предстоит сделать сообщения по темам "Диаграммы структурно-системного анализа" и "Универсальный язык моделирования (UML)". Видимо, тогда речь пойдет более конкретно обо всех этих делах, тогда мы и рассмотрим все более подробно, уже с конкретными примерами и диаграммами, а сейчас имеет смысл на том, из каких соображений выбиралось конкретное CASE-средство.
Очевидно, что далеко не последним фактором, определяющим выбор, является фактическая доступность или недоступность того или иного приложения. На старте выбор у меня был не очень велик: речь шла о продукте фирмы Platinum All Fusion Process Modeler (BPWin) и продукте фирмы Rational - Rational Rose. Оба эти продукта имелись в моем распоряжении, и сейчас они установлены на моем РС. Кто-то может выбрать и другие продукты, - это уже не суть важно. Чем отличаются эти продукты, как с ними работать, - тоже каждый может прочитать в описаниях программ, рекламе, Интернете и т.д. Сегодня же представляется целесообразным поговорить на другую тему, а именно: ответить самим себе на вопрос: чем один лучше (хуже) другого? Как уже неоднократно отмечалось выше, при этом ключевым является вопрос: "А зачем мне это надо?" Ответ на вопрос: чтобы строить информационные модели структурных подразделений РУМС. Итак, какой же из этих двух продуктов более подходит для построения информационных моделей и описания их технологических процессов. Чтобы ответить на этот вопрос, давайте немного порассуждаем.
4.3. РУМС как объект моделирования
Итак, я оказался в ситуации, когда нужно было хоть как, но моделировать технологии РУМС в целом и его отдельных структурных подразделений. Как я уже говорил, о моделировании РУМС в целом я уже от души высказался в своем отчете "Моделирование РУМС". Там высказано немало критических замечаний, касающихся нашей с вами жизни. Очевидно, что не только я один, но и многие из нас могут выпустить довольно изрядное количество стрел и в руководство наше, и по отдельным его специалистам, и в оборудовании мы еще не совсем, и линии у нас старые и система управления не отвечает современным требованиям т.д. и т.п. На все эти критические замечания я бы хотел ответить одной только фразой, произнесенной нашим Главным инженером во время одного из технических совещаний, с которым я лично согласен, как говорится, на все 100%. Итак, можно много ругать РУМС, Директора, Главного инженера, специалистов, охранников и т.д. и т.п. Но.. Есть одно Но.. РУМС - как система, как безусловно сложная техническая система - ра-бо-та-ет… Пусть где-то плохо, пусть где-то со скрипом, но ра-бо-та-ет.. То же самое можно сказать и про наше ПО: пусть оно и написано как-то не так, и быстродействие не очень, и базы там неудобные, и методы процедурные, и т.д. и т.п., но это все - ра-бо-та-ет.. Что же из этого следует? - Следует жить.. И, как следствие, ломать - не строить. Поэтому речь сейчас будет идти все таки о путях эволюционного, а не революционного развития.
Итак, речи о необходимости ре-инжиниринга пока не идет. Поэтому на сегодняшний день представляет больший интерес проблема построения моделей структурных подразделений РУМС класса As Is а не To Be. То есть - представляет актуальность разобраться с тем, а что чем же у нас заняты люди в разных структурных подразделениях. Ну, хотя бы в самых общих чертах. Вот этим я и занимаюсь в настоящее время. И об этом я расскажу в следующий раз, когда речь будет идти о диаграммах структурно-системного анализа и универсальном языке моделирования (UML).