Диссертация (1145120), страница 6
Текст из файла (страница 6)
Онисогласились вкладывать средства в модернизацию платформ, на которых работают этисистемы, чтобы сохранить бизнес-логику и среду исполнения систем неизменными.11В русскоязычной литературе термин CASE-система появился и стал активно использоваться в 90-х годах: публикации А. М. Вендрова [8] и Г. Н. Калянова [37] были знакомыочень многим людям, работающим в сфере информационных технологий. Однако в России классические CASE-системы, работающие на менфреймах, не получили распространения. Некоторой известностью пользовались «легковесные» варианты CASE-систем, работающие на персональных компьютерах, — как отдельные пакеты, так и продукты, входящие в состав более масштабных средств разработки, например, средств разработки базданных. По инерции этот же термин был перенесён и на UML-средства.28ны быть согласованы со средствами разработки [206]12.
Ещё одной причинойразвития визуального моделирования в 80-е и 90-е годы стало распространение ПО в малом и среднем бизнесе, чему в немалой степени способствовало распространение персональных компьютеров и сетей. Таким образом, возрастало количество и разнообразие проектов по созданию ПО существенно, соответственно, требовались средства качественной предпроектной работы.
Для решения этой проблемы стали активно создаваться методыобъектно-ориентированного анализа и проектирования, основанные на визуальном моделировании [182], [283], [325], [341], [347], [388], [393], [441] (обзор этих методов представлен в [438] — в этой работе описан 21 метод, но вдействительности их было больше). Для поддержки методов объектноориентированного анализа и проектирования стали создаваться инструментальные средства, которые продолжали называться CASE-системами, но,фактически, являлись уже другими продуктами — они использовались, в основном, для верхнеуровневого проектирования и не охватывали всего процесса разработки ПО.Результатом развития объектно-ориентированных методов анализа и проектирования стал стандарт UML [426], первая версия которого вышла в1997 году.
Данный язык поддерживается международным комитетом OMG,за 17 лет было выпущено более 10 версий (последняя версия под номером 2.5была выпущена в декабре 2013 года). На сегодняшний день для поддержкиUML существуют зрелые многофункциональные программные средства —UModel, MagicDraw, Enterprise Architect, IBM Rational Software Architect и др.(обзоры см. в работах [275], [309]). UML, несомненно, является наивысшейточкой развития визуального моделирования за более чем 60 лет, прошедшихс момента первой публикации фон Неймана [256]. Этот язык является признанным мировым стандартом, он повсеместно известен и преподаётся, прак12Но, с другой стороны, хотелось бы иметь платформенно-независимые модели, допускающие много вариантов реализации, в том числе с помощью разных средств разработки[348].29тически, в каждом университете мира, где преподают программирование,ИТ-технологии, бизнес-инжиниринг и пр.
В рамках UML были созданы общепринятыевидыдиаграмм —диаграммыклассов,вариантовис-пользования, конечных автоматов, компоннет и др., а также большое количество специализированных профайлов (для разработки телекоммуникационных систем, аппаратных систем, для тестирования и т.д.). UML известен ипопулярен в большей степени, чем блок-схемы или любой другой стандартили метод в области визуального моделирования.1.1.3 UML-средстваК сожалению, для UML-инструментов не существует отчётов агентстваGartner, а также других авторитетных организаций. Отсутствуют также обстоятельные современные обзоры, как, например, для EAM-инструментов.Автору удалось найти лишь работы [275], [309] и Интернет-обзоры [225],[427].В [275] предложены следующие критерии оценки UML-средств: полная поддержка UML; надёжность — отсутствие фатальных ошибок в программе, приводящих к потере данных, повреждению файлов и пр.; HTML-документация по моделям для быстрой навигации по моделибез запуска самого продукта; экспорт диаграмм в различные форматы, которые могут быть вставлены в документы или выложены в Интернет.
Примерами таких форматов могут быть GIF, PNG, JPEG; поддержка циклической разработки; интеграция с моделированием данных, то есть речь идёт об интеграцииобъектно-ориентированного подхода с разработкой баз данных.В работе сравниваются следующие UML-средства: UMLet, Visual Paradigm, Rational Rose, Magic Draw, Argo UML, Enterprise Architect.30Ресурс [225] приводит списки для UML-средств: свободно-распространяемые средства — 41 инструмент, коммерческие инструменты — 62 инструмента. Ресурс [427] является форумом, посвящённым UML-средствам и объединяет более 900 экспертов, а также ведущих производителей UML-средств.Ресурс приводит следующий рейтинг UML-средств: Enterprise Architect (компания Sparx Systems); MagicDraw (компания No Magic); UModel (компания Altova); Astah Professional (компания Change Vision); Visual Paradigm (компания Visual Paradigm); Rational Rhapsody Developer (компания IBM); Artisan Studio (компания Atego); Rational Software Architect (компания IBM).1.1.4 Использование визуального моделирования на практикеВопрос практического использования модельно-ориентированной инженерии и UML волнует исследователей и практиков давно.
С одной стороны,имеются работы, в которых однозначно высказывается мнение о широком иуспешном использовании UML [190]. С другой стороны, существуют достаточно пессимистические исследования [420], [372]. В 2008 году авторомдиссертационной работы был проведён опрос ИТ-специалистов компанийСанкт-Петербурга, и получившиеся результаты хоть и нельзя назвать полностью пессимистическими, но оптимистическими они точно не являются, вомногом, коррелируя с исследованиями, изложенными в [372].В ходе данного опроса были интервьюированы 76 респондентов из 19-тиИТ-компаний Санкт-Петербурга. Среди респондентов 47% являлись программистами, 13% — менеджерами, 7% — техническими писателями, 7% —тестировщиками, 3% — аналитиками. В своей работе UML использовали54% опрошенных. При этом 80% тех, кто использует UML, заявили, что ис31пользуют его неформально, для создания эскизов, набросков, для обмена информацией и общения, что соответствует результатам опроса, изложеннымив [372].
Программные UML-средства использовали 56% опрошенных из тех,кто использует UML. Остальные использовали UML с помощью доски/мелаи бумаги/ручки. Среди используемых программных средств лидером является Microsoft Visio, а также графические редакторы, встроенные в среды разработки. Лишь 30% из тех, кто использовал программные инструменты приработе с UML, применяли специализированные UML-пакеты типа IBM Software Architect.
Средства кодогенерации использовали только в 5% опрошенных. В большинстве случаев UML использовался в порядке личной инициативы отдельных специалистов (79%), а не как часть обязательных корпоративных или межкорпоративных стандартов, что снова соответствует результатам [372]. Среди диаграмм UML самыми распространёнными оказались: диаграммы классов (36%), вариантов использования (21%), последовательностей (16%).По версии исследования, представленного в [269], самыми распространёнными UML-диаграммами являются диаграммы вариантов использования,классов и последовательностей — то есть та же тройка, только второе местостало первым.Основной причиной затруднений в использовании UML в нашем исследовании было то, что люди не понимали, чем именно UML полезен для них.При этом половина тех, кто не использовал UML в своей работе, выразилижелание попробовать, но не имели для этого возможностей (не знали UML,его использование не было принято в компании), а половина являлись противниками визуального моделирования.Можно следующим образом обобщить обсуждение вопроса о применимости UML в сфере программной инженерии.321.
Существует некоторое количество компаний и проектов, использующих визуальное моделирование и UML высокотехнологичными способами. Такие проекты и компании автор встречал и в России, в частности, в компаниях ЗАО «Ланит-Терком» и ГП «Терком». В одном изпроектов этих компаний визуальное моделирование использовалось вразработке ПО линейки телекоммуникационных систем. Были созданысобственные язык (на основе языка SDL), метод и программные средства, включавшие генерацию программного кода по моделям; коллектив из 10–20 человек использовал и поддерживал эти средства в течение более чем 20 лет (подробности см.
в [145]). Визуальные моделиоказали большую помощь в интеграции усилий инженеров и программистов, а также при подготовке отчётной документации. Во второмпроекте этой же компании использовался уже UML: с его помощью создавались проектные спецификации, обеспечивавшие интерфейс междуархитекторами и разработчиками.
Этот интерфейс существовал и безUML, поскольку проектировщики выступали в роли заказчика — разработка была офшорная.Потом постепенно проектирование сталопроисходить также на стороне разработки, но заказчик все равнонастаивал на использовании UML для того, чтобы иметь доступ к проектным решениям. В обоих проектах визуальное моделирование использовалось масштабно, его внедрение было тщательно согласованона уровне руководства проекта, использование соответствующих практик и средств было обязательным для большинства участников проекта. Но в процентном соотношении такие проекты не составляют значительной доли среди проектов по разработке ПО.
Так, исследование[372], стремясь сделать равномерную выборку, не смогло обнаружитьтаких проектов. В приводимом выше исследовании автора данной диссертационной работы 79% тех, кто использовали UML, делали это в33порядке личной инициативы и лишь 5% опрошенных используют UMLв рамках корпоративных решений.2. UML активно используется неформально — как в порядке личной инициативы отдельных разработчиков, так и с помощью простых средств— графических редакторов общего назначения типа Microsoft Visio, атакже с помощью ручки и мела.Есть ряд причин, которые препятствуют полному принятию UML мировым сообществом программистов и его непременному использованию в каждом проекте.1.
Стандарт является очень большим по объёму (около 800 страниц), атакже сложен в понимании [226], [381], поэтому его использование напрактике ограничивается лишь несколькими видами диаграмм.2. UML не является универсальным — в качестве подтверждения этоготезиса можно обратить внимание на многочисленные профайлы UML(см. [428]), а также менее формальные расширения, например, для аспектно-ориентированного программирования [270], для разработки семейств программных продуктов [227] и т.д.3. Не существует общего, универсального процесса разработки ПО [407],а значит, распространение любой инициативы, претендующей в той илииной степени на универсализм, в среднем, ограничено существующеймерой хаоса.