С.Трофимов
Фраза, вынесенная в заголовок, создана по аналогии с “объектно-ориентированным мышлением”. Для того чтобы создавать объектно-ориентированные программы, необходимо отказаться от традиционного процедурного мышления и начать мыслить при помощи объектов [1]. То же справедливо и для CASE-средств. Для того чтобы начать создавать программные системы при помощи современных технологий, необходимо иначе взглянуть не только на процесс проектирования, но и на программирование.
Трудности внедрения CASE-технологий при создании проектов общеизвестны [2], и проектировщики систем должны быть готовы к их преодолению. Но я хочу представить эти проблемы с точки зрения программиста, который прочно обосновался в своем мире программного кода и не мыслит других возможностей для написания программ, как “строчка к строчке”, когда классы создаются последовательным наполнением методов и атрибутов.
Необходимость использования CASE-технологий непосредственно разработчиками программ менее очевидна чем для проектировщика системы [3], причем в [2] мы читаем, что “моделирование сложных программных систем с помощью CASE-средств является самостоятельным и самодостаточным видом деятельности в процессе создания ПО”, что может изначально получить негативную оценку у программистов. Мол, я пишу программы, а создавать модели – это ваши трудности.
Для большинства программистов при создании программных систем более очевидна необходимость процесса создания кода, чем моделирования самой системы. К тому же предварительное создание модели системы включает в себя дополнительные трудозатраты, результат которых виден только через некоторое время, и это при том, что освоение сложных CASE-средств требует значительных усилий.
Основной причиной, порождающей настороженное или, возможно, даже негативное отношение к CASE-средствам со стороны программистов, по моему мнению – это трудность перехода с обычного мышления к CASE-мышлению. Под ним я подразумеваю представление системы в виде объектов, которые отражаются в терминах CASE-средства, обычно в диаграммах языка UML. Причем, изначально подразумевается, что все объекты системы разрабатываются или, по крайней мере, имеют свое отражение в этих диаграммах.
Для того чтобы перейти к создании и сопровождению кода при помощи CASE-средства, поддерживающего язык UML, такого, например, как Rational Rose, программист должен перестроить свое представление о создании программ. Необходимо мыслить уже в терминах языка UML, мыслить диаграммами, а переход к такому типу мышления требует примерно такого же усилия, как переход от процедурного программирования к объектно-ориентированному.
Будет заблуждением считать, что изучив возможности редактора UML (если абстрагироваться от дополнительных функций, то таковым можно представить Rational Rose), вы начнете сразу создавать программные системы. Как утверждается в [1], диаграммы не появляются сами по себе, они – результат объектно-ориентированного проектирования, т.е. именно мышления, причем в терминах CASE-средства.
Здесь переплетаются две совершенно разные задачи:
1.Изучение языка UML и развитие CASE-мышления.
2.Изучение возможностей конкретного CASE-средства, для того чтобы легко воплотить свои мысли в программном проекте. Для первого я бы рекомендовал книги [1,4], а для второго можно воспользоваться, например [5].
Программист, приступая к изучению Rational Rose, сталкивается с этими проблемами, которые входят в противоречие с его предыдущим опытом. Считая, что CASE-средство – это просто программа, которая помогает..., автоматизирует..., решает..., он с энтузиазмом пытается в ней разобраться, но упирается в свою же косность, не позволяющую взглянуть на создаваемое ПО со стороны.
В отличие от большинства других программ, где, освоив некоторые простые функции, можно создавать нечто несложное, а затем, если понадобится, углубить свои знания, здесь невозможно даже начать работать, не охватив всех диаграмм целиком, не разобравшись как и для чего они должны использоваться.
Диаграммы UML позволяют показать различные аспекты будущей системы, создать ее модель, перед тем как с головой бросаться в написание кода. Не уяснив до конца всех возможностей создания этой модели, просто нельзя ее получить. Не построив фундамент, нельзя строить стены, но уже при закладке фундамента нужно рассчитывать на то, какие стены будут на нем стоять. И нарушение этого принципа приведет к тому, что вы получите не стройное здание программной системы, а не связанные между собой отдельные блоки, которые никуда не годятся.
Применяя CASE-мышление, программист уже сделает свои программы лучше, ведь многие программисты не знают ни способа создания хорошей, ни признаков неудачной программной архитектуры [6], а представление программных объектов в диаграммах UML позволяет наглядно увидеть ошибки и недоработки в полученной иерархии, обсудить их с коллегами и, что самое приятное, легко этой иерархией манипулировать, что при ручном кодировании программист вряд ли может себе позволить.
Таким образом, можно подвести итог, что успех внедрения CASE-систем зависит не только от усилий руководителя внедрения, но и от способности программистов освоить новое для них CASE-мышление, т.е. мышление в терминах внедряемой CASE-системы, что требует приложения значительных усилий как менеджеров, так и самих программистов. Список литературы
Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд./Пер с англ.–М.: “Издательство Бином”, СПб.: “Невский диалект”, 1999 г. –560 с., ил.
Вендров А. Ниша и внедрение CASE-средств. “Директору ИС”, ноябрь 2000. (http://www.interface.ru/CASE/botcase.htm)
Новичков А. Rational Rose для разработчиков и ради разработчиков. (http://www.interface.ru/rational/rose/develop.htm)
Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.: Мир, 1999. – 191 с., ил.
Трофимов С. CASE-технологии: практическая работа в Rational Rose – М.: ЗАО “Издательство БИНОМ”, 2001 г. – 272 с.: ил. (http://progcpp.narod.ru/rational/)
Бюрер К. От ремесла к науке: поиск основных принципов разработки ПО (http://www.interface.ru/rational/science.htm)