Диссертация (1145120), страница 5
Текст из файла (страница 5)
Данноеподмножество стандартизовано комитетом OMG в виде MOF-языка (MetaObject Facility) [364]. С его помощью описываются другие стандарты OMG,задающие различные метамодели, например, СORBA Component Model(CCM), Common Warehouse Metamodel (CWM) и др.1.1.2 История визуального моделирования6В данном разделе представлен обзор средств индустриального визуальногомоделирования ПО — то есть тех подходов, которые активно применялись/применяются на практике.
Здесь не будут рассматриваться многочисленные академические исследования, не нашедшие широкого применения виндустрии — желающим познакомиться с такими исследованиями можнопорекомендовать работы [251], [419].Необходимо отметить, что визуальное моделирование имеет солидныйвозраст для компьютерной дисциплины. Первым результатом здесь былиблок-схемы (flow сharts), предложенные фон Нейманом ещё в 40-х годах иопубликованные в работе [256].
Исходно блок-схемы рассматривались какспособ ввода в вычислительную машину сложных математических формул иалгоритмов (альтернативой в то время было программирование непосредственно в машинных кодах). Тем не менее, развитие средств программирования пошло по другому пути — стали активно развиваться всё более высокоуровневые языки программирования. Однако блок-схемы стали использоватьдля разработки проектной документации в больших проектах, разрабатываемых для военных и федеральных нужд. Официальные заказчики в таких про6Материал данного раздела излагается по книги автора диссертационной работы [46].24ектах обычно настаивали на обширной документации, этапности разработкии т.д.
Соответственно, в конце 50-х годов стали активно появляться различные варианты блок-схем, и в 1963 году в США институтом ASI7 был создансоответствующий национальный стандарт [157]. К 1970 году было выпущеночетыре версии данного стандарта. Однако по мере развития и усложненияязыков программирования стало приходить понимание того, что такой детальный способ предварительного проектирования является неоправданнойтратой усилий. Экспериментальные исследования, представленные в 1977году в работе [400], суммируют накопившийся скептицизм практиков по отношению к блок-схемам, и постепенно блок-схемы перестали использоватьсяв промышленном программировании.В конце 60-х годов в мировой компьютерной индустрии произошёл кризис, послуживший причиной образования программной инженерии.
В это жевремя появился ряд интересных исследований по проектированию искусственных систем, в частности, работы [27], [383], [384].В работе [400], фактически, доказавшей неэффективность низкоуровневыхблок-схем, было отмечено, что визуальные спецификации могут быть полезны на ранних стадиях разработки ПО, например, при анализе и концептуальном проектировании. Соответственно, с начала 70-х годов стали развиваться методы структурного анализа (structured analysis) [223], [340], [383],[384], [413], [446], [447]. Эти методы делали упор не на алгоритмической декомпозиции, как блок-схемы, а на структурной: сложность программ привелак тому, что в языках программирования появились средства разбиения программ на модули — подпрограммы, процедуры, классы, компоненты и интерфейсы, подсистемы и т.
д. Стали различать логическую структуру ПО(структурную организацию ПО с помощью языков программирования) и физическую — компоновка ПО в исполняемые модули и распределение этихмодулей по вычислительным устройствам, например, по серверной и клиент7American Standards Institute, в будущем — American National Standard Institute, ANSI.25ской частям [182]8. Кроме того, стали выделять более высокоуровневые абстракции ПО, формально описывая информацию, которая в ПО обычно явноне представлена: требования, сценарии взаимодействия с пользователем,верхнеуровневые алгоритмы и т.д.
Вся эта информация не извлекается автоматически из ПО, о чем свидетельствуют достаточно скромные успехи обратной инженерии [234]. Наконец, стали обращать внимание на моделирование предметной области, для которой ПО предназначается — её сущностей,потоков данных, алгоритмов и пр.Одним из первых методов структурного анализа был SADT (StructuredAnalysis and Design Technique) [340], работы над которым начались в MIT(Massachusetts Institute of Technology) в конце 60-х годов под руководствомD. Ross. Метод SADT является одним из самых зрелых методов визуальногомоделирования: кроме хорошо определённой нотации он включает многочисленные и подробные рекомендации по разработке моделей.
Метод SADTбыл взят за основу метода моделирования сложных систем, описанного в серии военных стандартов США IDEF [281]. В рамках этих стандартов быларазработана детальная процедура моделирования, имеющая хорошо заданные шаги моделирования, роли участников процесса (разработчик, рецензент, библиотекарь и др.) и правила взаимодействия этих ролей. SADT до сихпор применяется при моделировании бизнес-процессов, а также в управленииархитектурами предприятий. В 70-х годах появились также «легковесные»методы структурного анализа: см., например, работы [413], [446], [223].Витоге были разработаны широко известные сегодня диаграммы потоков данных (data flows), диаграммы сущность-связь (entity-relationship diagrams),8Автор здесь несколько «ускорил» эволюцию визуального моделирования, не занимаясьскрупулёзным определением того, какие именно из перечисленных выше тенденций появились в рамках структурного анализа и проектирования, а какие — в рамках объектноориентированного подхода.
Кроме того, была приведена ссылка на последнее изданиезнаменитой монографии G. Booch, переведённой на русский язык, в то время как первоеоригинальное издание вышло в 1991 году.26диаграммы конечных автоматов (state transition diagrams или statecharts) и некоторые другие формализмы и нотации9.С 80-х годов визуальные модели перестали рисовать на бумаге и на грифельных досках: для их разработки стали создавать и использовать специальные программные инструменты.
Самыми известными такими инструментами были CASE-пакеты (Computer Aided Software Engineering) [219]. Этисредства являлись инструментами разработки и функционирования приложений для менфреймов, что было актуально ввиду большого количествасредств и языков, необходимых для разработки одного приложения (средствадля работы с функциями операционной системы, для описания экранныхформ, взаимодействия с базами данных и т. д.). CASE-пакеты широко распространились к началу 90-х годов, их выпускали, развивали, покупали ведущие производители ПО — такие компании, как IBM, Computer Associates ипр. (обзор CASE-пакетов того времени можно найти в работе [248]).
С их помощью было создано большое количество информационных систем длякрупных предприятий и банков, и эти информационные системы существуюти по сей день, а соответствующие CASE-пакеты продолжают сопровождатьсяи переносятся на современные платформы. Оказалось, что безопаснее и дешевле поддерживать платформы, на которых были созданы эти системы, чем9Строго говоря, диаграммы сущность-связь, а также состояний и переходов возникли вовсе не в контексте структурного анализа. Диаграммы сущность-связь появились в1976 году в работе [209] в контексте проектирования сложных баз данных. Одно из первых упоминаний о диаграммах состояний и переходов датируется 1948 годом: в [397] этидиаграммы использовались как визуальная форма представления конечных автоматов. В1976 году вышла первая версия языка SDL, созданного европейским комитетом по телефонии и телеграфии (CCITT, ныне ITU) для проектирования телекоммуникационных систем [54]. В рамках SDL конечные автоматы были применены для проектирования логикителекоммуникационных алгоритмов, а их графическая нотация использовала элементыблок-схем.
В 1987 году в работе D. Harel [273] появился ещё один вариант диаграмм состояний и переходов, который позднее был использован в UML. Но оба вида диаграмм —сущность-связь, состояний и переходов — активно использовались в разных методологиях структурного анализа.27переделывать сами системы10. Но новых CASE-пакетов такого вида уже давно не создают — с приходом персональных компьютеров и развитиемсредств производства ПО надобность в таких интегральных средах отпала; сдругой стороны, структурный анализ, бывший одним из краеугольных камней этих систем, был существенно вытеснен объектно-ориентированныманализом и проектированием на основе UML.
Однако влияние CASE-системна визуальное моделирование было велико, и ещё долгое время визуальныесредства продолжали называть CASE-системами11.Распространение в 90-е годы персональных компьютеров совпало с развитием объектно-ориентированного программирования. Это была действительно новая парадигма разработки, а не просто новые языки программирования. В частности, средства структурного анализа и проектирования ПО, состыкованные с процедурными языками, также эволюционировали в соответствии с этой парадигмой, поскольку модели ценны не сами по себе, а какпуть к программному обеспечению, т. е.
важно, какими средствами будетразрабатываться ПО на основе данных моделей. Средства декомпозиции,применяемые при моделировании, а также используемые абстракции, долж-10В 1990-е – начале 2000 годов широкое развитие получило направление реинжинирингаустаревших систем [376]. С точки зрения бизнеса это направление ставило задачу переноса на современные платформы информационных систем, созданных в 60-е – 90-е годы наязыках COBOL, PL/1, основанных на CASE-пакетах и т.д. Однако данное направление недостигло широкого коммерческого успеха, поскольку владельцы данных информационных систем не пошли на их коренную переделку, опасаясь сопутствующих рисков.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
