Диссертация (1145120), страница 4
Текст из файла (страница 4)
В данном случае мы не имеемисходных, зрительно воспринимаемых форм объекта, которые в инженерномчерчении являются основой всех его схематичных изображений (вид сверху,вид сбоку, различные сечения и т.д.).В связи с этим возникаетнеобходимость зрительно чему-то уподобить ПО: оно выглядит … как что?Возникают метафоры визуализации программного обеспечения, которыеявляются результатом сопоставления абстрактных и невидимых элементовПО некоторым существующим и устойчивым зрительным образам [1].Является ли такое сопоставление действительно метафорой, то естьиспользует ли при этом какие-нибудь существующие зрительные аналогии,или создаются принципиально новые зрительные образы — это вопросфилософский. Важнолишь договориться, чтомы изображаемПОопределённым способом и, значит, в определённом смысле видим его именнотак. Тем самым, при проектировании и разработке, при передаче знаний осоздаваемом или уже готовом и работающем ПО и в других случаяхзадействуется зрительное восприятие.
В этом смысле представляют ценностьстандартные визуальные языки — в программной инженерии это, преждевсего, UML. Разработчики и аналитики привыкают к изображениям классов,объектов, процессов пакетов и т.д., а также к определённым видам диаграмм.Они привыкают мыслить, создавая диаграммы UML, а их коллеги легкочитают эти мысли по диаграммам. То есть, создавая и используя стандартныевизуальные языки, фактически, мы всё время утверждаемся в том, каквыглядит невидимое. В связи с этим изменение нотаций UML от версии кверсиинежелательно,посколькунедаётскладыватьсявизуальным17привычкам.
С другой стороны, в соответствии с современными ритмами итрадициями, стандарт, который не развивается, перестаёт интересоватьлюдей — имкажется, что оннеживой,азначит,ненужный.Этопротиворечие тормозит распространение визуального моделирования. Всвязи с этим подход SADT/IDEF0 [281], [340] является примеромпостоянства:егодиаграммысохраняютсянеизменнымивтечениенескольких десятков лет и одновременно активно используются на практике.Но данный подход принадлежит другой эпохе, поскольку он был создан,стандартизовался и распространялся, так сказать, в «докомпьютерную»эпоху.
При этом диаграммы рисовались на бумаге (например, в стандартеIDEF0 было указано, каким цветом на чертежах должен писать своизамечаниярецензент),ирабочийциклразработкидиаграммныхспецификаций не был компьютеризирован.Можно утверждать, что на сегодняшний день основной метафоройвизуализации ПО являются математические графы. При этом вершины могутобозначаться с помощью различных фигур, ребра, как правило, рисуются ввиде соединительных линий со стрелами или могут быть заданы с помощьювключения (наложения) одной фигуры в другую (такая связь означаетотношение включения5). Но, несмотря на многообразие визуальныхпредставлений, граф все равно уверенно распознаётся на таких диаграммах.На рис. 1.1 приводится несколько видов диаграмм, имеющих структуруграфа.5Оба способа для изображения связей реализованы, например, в продукте ARIS [38] —если между двумя сущностями есть отношение включения, созданное при геометрическомналожении одной фигуры на другую, то при выносе мышью наложенной фигуры из её агрегата между ними появляется линия.18Рис.
1.1. Некоторые примеры графов,используемых при визуальном моделировании ПОНа настоящий момент, несмотря на многочисленные попытки, а такжекритику [188], другой общеупотребительной метафоры визуализации ПОпока не создано. Следует отметить, что большинство видов диаграмм UMLявляются графами, однако имеются и не графы: например, диаграммыпоследовательности (sequence diagrams) или временные диаграммы (timingdiagrams).Отметим, что визуальное моделирование в программной инженериипризвано выполнять именно коммуникативную роль [59]. Об этом частозабывают, но именно облегчение коммуникации между многочисленными исущественно различными интересантами при разработке программныхсистем является здесь, на взгляд автора, главной задачей.Визуальное моделирование при разработке ПО применяется с помощьюязыков, методов и соответствующих программных средств (см. рис.
1.2).19UML, BPMN,SADT/IDEF0,IDEF1XЯзыкиВходят вRUP/USDP,Use Case Driven Approach,SADTМетодыРеализуются вПрограммныеинструментыUmodel, MagicDraw,Enterprise Architect,IBM Rational SoftwareArchitectБываютПредметноориентированныеСтандартныеРис. 1.2. Языки, методы, программные средства визуального моделированияв программной инженерииЯзыквизуальногомоделирования(визуальныйязык)являетсяфиксированным набором графических символов (нотацией), а такжевключает в себя правила построения с помощью элементов нотациивизуальных моделей (так называемые синтаксические правила).Внастоящий момент в программной инженерии распространены такие языкивизуального моделирования, как UML и BPMN.
Используются также и болеестарые языки — для моделирования бизнес-процессов SADT/IDEF0 [281],[340], для моделирования баз данных — IDEF1x [281]. Следует отметить, чтовнастоящеевремяразвиваютсятакжепредметно-ориентированныевизуальные языки.Метод использования визуального моделирования предписывает правилаприменения одного или нескольких визуальных языков для решенияопределённых задач.
Для работы с одним и тем же визуальным языком20может существовать много разных методов — именно так обстоит дело сUML.В качестве примера можно упомянуть USDP/RUP [291] —комплексный метод разработки ПО, ориентированный на UML. Необходимоотметить, что в данный момент мы говорим об универсальных способахиспользовать визуальное моделирование. Между тем на практике важнымоказывается создание конкретных методик по его применению в рамкахопределённых контекстов — компаний, семейств программных продуктов идаже единичных проектов. О таких методиках речь пойдёт ниже.Программные средства позволяют удобно работать с визуальнымиязыками,реализуябазовыесредствасозданияиманипулированияграфическими объектами; также они поддерживают методы использованиявизуального моделирования. Такие средства поддерживают следующуюфункциональность: графические редакторы, генераторы конечного кода подиаграммам, средства валидации моделей, средства импорта/экспортамоделей и пр.При визуальном моделировании, как правило, выделяют следующиеуровниабстракции:предметнуюобласть,модель,метамодель,метаметамодель.Предметная область (problem domain или domain) является некоторойчастьюреальногомира(знания,люди,бизнес-интересыипр.),рассматриваемой как одно целое в целях удовлетворения некоторыхпотребностейопределённогосообщества.Однакоэтооченьобщееопределение.
Обычно под предметной областью при разработке ПОподразумеваюттуобластьдеятельностилюдей,длякоторойПОпредназначено — то есть это либо компания, для которой создаётсяинформационнаясистема,либонекоторыйбизнес-сегмент,дляудовлетворения нужд которого создаётся «коробочный» программныйпродукт и т.д.21Модель (model) — это упрощённое описание предметной области,созданное для удобства выполнения некоторой работы. Создание ииспользование моделей позволяет игнорировать необозримое многообразиеразличных свойств предметной области и сосредоточиться лишь на тех,которые оказываются существенными для данной работы.
Фактически, речьидёт опринципеабстрагирования,определениекоторогодалещёАристотель: «метод намеренно одностороннего изучения реальности,субъективный приём мысленного разделения целого и полагание отдельносущими его частей. В принципе такое полагание не заключает никакойошибки и объективно оправдано многообразием свойств (аспектов) целого,порою столь различных, что они не могут стать предметом одной науки»[126]. В связи с этим, например, при создании информационной системы дляавтоматизациинекоторогопредприятиястроитсямодель,котораяфокусируется на потоках данных, бизнес-процессах, организационнойструктуре и пр.
В данную модель обычно не входят, например, деталипланировки офисных помещений, расписание работы компании, особенностимежличностного отношения сотрудников. В целом, можно сказать, чтопроцесс разработки ПО заключается в создании различных моделейпредметной области (технического задания, моделей анализа предметнойобласти, моделей проектирования и т.д.), уточняющих и дополняющих другдруга и завершающихся финальной моделью — программным обеспечением(см. рис. 1.3).ПредметнаяобластьМодель 1...Модель NЦелевоеПОРис. 1.3. Разработка ПО как процесс разработки моделейМодель создаётся в соответствии с некоторой точкой зрения (view point)на предметную область. Эта точка зрения определяет, какие свойствапредметной области являются существенными и должны попасть в модель, акакие оказываются несущественными [49].22В индустриальном производстве создание моделей не является единичнымпрецедентом.Например,люди,специализирующиесянаразработкеинформационных систем, создают много разных моделей для различныхкомпаний, которые оказываются похожими.
Возникает потребность в языке,который зафиксировал бы концепции и средства создания таких моделей.Предметной областью для этого языка выступают все возможные модели,которые можно создать с его помощью, поэтому такой язык называетсяметамоделью (metamodel).Бывает, что в нескольких близких предметных областях может бытьвостребовано множество различных языков моделирования; тогда для ихспецификации и разработки оказываются необходимы общие подходы.Таким образом, возникает необходимость в языке описания языков —метаметамодели (metametamodel). В качестве предметной области для этойновой модели выступают все метамодели, описываемые с её помощью.
Этуцепочку метауровней можно продолжать и далее, при этом каждыйследующийуровеньбудетявлятьсямодельюдляпредыдущего,апредыдущий уровень выступит для него в качестве предметной области, какэто проиллюстрировано на рис. 1.4.Уровень N+2Уровень N+1Уровень NРис. 1.4. Уровни метамоделированияОднако заметим, что переход на следующий метауровень оправдан тольков том случае, когда на предыдущем появляется много однородных объектов,которые нуждаются в унификации и упорядочивании, то есть требуется23создать метаописание. При этом очевидно, что в некоторый момент будетдостигнут предел — на очередном метауровне мы получим незначительноеколичество различных сущностей, и создавать следующий метауровень дляих классификации будет нецелесообразно. Язык UML, являясь метамоделью,описан с помощью своего подмножества — диаграмм классов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
