Диссертация (1145120), страница 15
Текст из файла (страница 15)
Данная задача,полностью решённая для программного кода, остаётся открытой дляразличных моделей — требований, визуальных моделей и пр. Здесь речь идётне столько о версионировании подобных активов, сколько о решении задачнахождения разницы, а также слиянии разных версий, удовлетворяющихспецифическим требованиям по визуализации результатов [85] и имеющихудобные средства навигации и разрешения конфликтов [69], [84].Необходимо отметить, что DSM-пакеты, предназначенные для созданиясистемуправлениязнаниямивразныхобластях,могутиметьдополнительные функциональные компоненты.
Например, визуальныесредства в программной инженерии должны быть интегрированы со средамиразработки ПО, и эта интеграция имеет много дополнительной специфики. Сдругой стороны, для таких средств не требуется многопользовательскаяработа, как это обсуждалось выше, а для решений управления знаниями вобласти бизнес-инжиниринга такие средства нужны.Схемапредлагаемойметодологиипредметно-ориентированногомоделирования представлена на рис. 2.1.79Метод ологияСредстваверсионногоконтроляПоддержка качествавизуальныхспецификацийСредстваинтеграцииDSM-проектПлатформыИТ-решение(DSM-решение)Работа сбольшимимоделямиРискиМодель процессаразработкиСредства разработкипрограммногообеспеченияРазличные классыпрограммногообеспеченияПроекты, линейки,компанииСистемы управлениязнаниями в разныхобластяхБизнесинформатика...ОбразованиеРис. 2.1.
Схема методологии предметно-ориентированного моделированияКратко охарактеризуем её основные компоненты.1. DSM-проект — проект по разработке предметно-ориентированногорешения. Эта часть методологии включает в себя следующее: определение DSM-решения; определение DSM-платформы; модель процесса разработки DSM-решений; модель рисков DSM-проектов.2. Дополнительные функциональные компоненты DSM-решения, разработка которых обычно не охватывается имеющимися технологиями и80которые разработчикам DSM-решения необходимо создавать самостоятельно: средства версионного контроля (слияние моделей, поиск разницы); средства поддержки качества визуальных спецификаций; средства интеграции DSM-инструментов с другими программными средствами; средства работы с большими моделями.3.
DSM-решения разделяются на две категории: средства разработки программного обеспечения, которые, в своюочередь, делятся на средства, предназначающиеся для определённых сообществ, например, Java-программистам или разработчикамWeb-приложений, и средства для определённого коллектива людей в рамках компании, разработчиков линейки продуктов или команды, занимающейся разработкой большого программного продукта; средствауправлениязнанияминаосновепредметно-ориентированного моделирования для произвольных областейзнаний — бизнес-инжиниринга, образования и т.д.812.2 DSM-решениеРассмотрим детально DSM-решение23.
Оно состоит из набора рабочихпродуктов, ориентированных на конкретный рабочий процесс (существующий или вновь создаваемый) и конкретных пользователей, предназначенныйдля решения определённой задачи в некоторой предметной области. Списокрабочих продуктов DSM-решения представлен ниже: язык моделирования, программные средства, метод использования, средства интеграции, поддержка и сопровождение24.Язык моделирования (Domain Specific Language, DSL) — это визуальныйпредметно-ориентированный язык, который создаётся для применения вконкретной предметной области; в данной работе рассматриваются тольковизуальныепредметно-ориентированныеязыки(обзорпредметно-ориентированных языков и средств их поддержки можно найти в [35]).Программные средства — это DSM-пакет, функциональность и средстваразработки которого обсуждались выше.Средства интеграции — часть DSM-пакета, вынесенная в отдельныйрабочий продукт ввиду большой важности: DSM-пакет используется вопределённом технологическом контексте, то есть совместно с другимипрограммными продуктами, поэтому он должен обмениваться данными сэтим контекстом — в пакетном режиме или online (часто такую интеграциюназывают «бесшовной»).
Второй вариант реализовать труднее. Например,циклическая разработка (round trip engineering) диаграмм классов и объектноориентированных приложений означает (в пределе) возможность перехода влюбой момент из графического редактора в средство разработки (IDE) и2324Материал данного раздела следует работам автора [49], [53], [55], [315].Данное определение берет за основу определение ИТ-решения в методологии MSF [350].82обратно. Такая интеграция в ряде случаев оказывается затруднительной —одной из самых часто встречающихся проблем является обеспечение«бесшовности» и надёжности при работе с большими моделями.Метод использования — это последовательная и ясная стратегияиспользования DSM-решения, включающая описание ролей пользователей,варианты использования решения и т.д.
В силу ограниченности ресурсовDSM-проектов важно точно определить все сценарии использования DSMрешения до начала его разработки, иначе ресурсы проекта могут бытьпотрачены на создание бесполезного продукта.Сопровождение и поддержка. После сдачи решения важно наладить процесс его поддержки и развития. На практике часто данному рабочему продукту не уделяется должного внимания. Поэтому исправление ошибок и добавление новых возможностей осуществляется хаотически, что приводит кпроблемам: падает надёжность решения, неоправданно возрастает время исправления ошибок и реализации новой функциональности, последняя становится запутанной и непонятной.
Должна быть налажена также процедураконфигурационного управления исходными текстами кода решения, а такжеразличными сопутствующими документами. В силу того что решение создаётся коллективом для собственных нужд, а также из-за недостатка средств, вDSM-проектах эти азы программной инженерии часто игнорируются. В своюочередь, в перспективе это приводит к большим проблемам, посколькууспешное DSM-решение существует и развивается не один год.Как правило, при внедрении UML, BPMN и других стандартныхвизуальных языков, а также программных средств моделирования, вконкретную компанию или проект создаются специальные методики.Например, при внедрении UML определяется набор UML-диаграмм, которыйбудет использоваться, определяются также основные цели и задачи, которыеUML должен решать (например, прозрачность и контроль со сторонызаказчика архитектурных решений в проекте), определяется процесс с83ролями и пр.
Классики визуального моделирования, например, Гради Буч,неоднократно указывали на то, что визуальное моделирование не являетсякнигой поварских рецептов, и требуется тщательно прорабатывать способ егоиспользования в контексте реальных задач [182]. Можно сказать, чтовизуальное моделирование является инновациями вида organization pull, а неtechnology push [452]25.И даже если не создаётся специальногопрограммного обеспечения (DSM-решения) для работы с визуальнымимоделями, а используются стандартные средства, тоцелесообразнотщательно специфицировать способ применения визуального моделированияв данном контексте. Это будет являться слабой формой предметноориентированного моделирования.
Результат такой деятельности будемназывать DSM-методикой. Такая методика должна быть разработана в явномвиде, на её создание должны быть выделены соответствующие ресурсы. Впротивном случае во внимание менеджмента, инициирующего внедрениевизуального моделирования, попадают лишь общие задачи, которыхнедостаточнодляэффективногопроцессаидостиженияреальныхрезультатов.Состав DSM-методики напоминает DSM-решения, но имеются отличия.
Веё состав входят следующие продукты: цели и задачи, подмножествостандартногоязыкамоделирования,методипроцесс,настроенныйинструмент моделирования.25В данной работе рассматриваются pull/push стратегии внедрения инноваций в компанию: organization pull — инновации нацелены на решение конкретных проблем компании;technology push — широкомасштабное внедрение инноваций, основанное не на проблемахкомпании, а на внедряемой масштабной технологии. Во втором случае вместо конкретныхпроблем, которые будут решены после внедрения инновации (первый случай), рассматриваются показатели компании — эффективность, производительность, годовой оборотсредств, увеличение стоимости акций публичной компании, — которые будут увеличены,улучшены после внедрения инновации. При этом предполагается, что будут автоматически решены многочисленные частные проблемы организации, в том числе и те, о которыхв данный момент ничего не известно. Pull/push стратегии удобно применять при улучшении процесса разработки ПО, в частности, при создании DSM-решений.84Цели и задачи.
Как отмечалось в [357], даже при организации обученияUML в компании по разработке ПО лекторы должны понимать, что хочет отUML руководство компании. Тем более нужно это понимать при внедренииUML. Однако здесь следует различать стратегические цели менеджмента(если таковые есть) относительно визуального моделирования и болеенизкоуровневые, но в то же время и более конкретные задачи, раскрывающиеи реализующие эти цели. Например, целью менеджмента может бытьповышение доступности информации о разрабатываемых в компаниисистемах более широкому кругу людей — менеджменту, разработчикамсмежных проектов, командам сопровождения и заказчику. Эта цельвозникала в связи с определёнными бизнес-задачами компании.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
