WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 16 |

o ”на основе анализа предметной области разрабатывается концептуальная модель системы, определяющая сущности и отношения между ними;

o в отличие от традиционных для объектно-ориентированного программирования подходов, из числа сущностей выделяются источники событий, объекты управления и автоматы. Источники событий активны – они по собственной инициативе воздействуют на автоматы.

Объекты управления пассивны – они выполняют действия по командам от автоматов. Объекты управления также могут формировать значения входных переменных для автоматов.

Автоматы активируются источниками событий и на основании значений входных переменных и текущих состояний воздействуют на объекты управления, переходя в новые состояния;

o используя нотацию диаграммы классов, строится схема связей автоматов, задающая интерфейс каждого их них. На этой схеме слева отображаются источники событий, в центре – автоматы, а справа – объекты управления.

Источники событий с помощью UML-ассоциаций связываются с автоматами, которым они поставляют события. Автоматы связываются с объектами, которыми они управляют, а также с другими автоматами, которые они вызывают или которые вложены в их состояния;

o схема связей, кроме задания интерфейсов автоматов, выполняет функцию, характерную для диаграммы классов – задает объектно-ориентированную структуру программы;

o каждый объект управления содержит два типа методов, реализующих входные переменные (xj) и выходные воздействия (zk);

o для каждого автомата с помощью нотации диаграммы состояний строится граф переходов типа Мура-Мили, в котором дуги могут быть помечены событием (ei), булевой формулой из входных переменных и формируемыми на переходах выходными воздействиями;

o в вершинах могут указываться выходные воздействия, выполняемые при входе в состояние и имена вложенных автоматов, которые активны, пока активно состояние, в которое они вложены;

o кроме вложенности автоматы могут взаимодействовать по вызываемости. При этом вызывающий автомат передает вызываемому событие, что и указывается на переходе или в вершине в виде выходного воздействия. Во втором случае - 26 - УМП «Автоматизированные методы разработки архитектуры ПО» посылка события вызываемому автомату происходит при входе в состояние;

o каждый автомат имеет одно начальное и произвольное количество конечных состояний;

o состояния на графе переходов могут быть простыми и сложными. Если в состояние вложено другое состояние, то оно называется сложным. В противном случае состояние простое. Основной особенностью сложных состояний является то, что дуга, исходящая из такого состояния, заменяет однотипные дуги, исходящие из каждого вложенного состояния;

o все сложные состояния неустойчивы, а все простые, за исключением начального – устойчивы. При наличии сложных состояний в автомате, появление события может привести к выполнению более одного перехода. Это происходит в связи с тем, что, как отмечено выше, сложное состояние является неустойчивым и автомат выполняет переходы до тех пор, пока не достигнет первого из простых (устойчивых) состояний. Отметим, что если в графе переходов сложные состояния отсутствуют, то, как и в SWITCH-технологии, при каждом запуске автомата выполняется не более одного перехода;

o каждая входная переменная и каждое выходное воздействие являются методами соответствующего объекта управления, которые реализуются вручную на целевом языке программирования. Источники событий также реализуются вручную;

o использование символьных обозначений в графах переходов позволяет весьма компактно описывать сложное поведение проектируемых систем. Смысл таких символов задает схема связей. При наведении курсора на соответствующий символ на графе переходов во всплывающей подсказке отображается его текстовое описание…” [10].

Использование инструментального средства UniMod позволяет спроектировать программу в целом.

В автоматном программировании наиболее трудоемким является процесс проектирования автоматов. Сгенерированный по автоматам код может составлять 70-80% от кода программы в целом. Остальная часть кода разрабатывается традиционным программированием и предназначена для постановщиков событий и объектов управления.

Уровень автоматизации при создании автоматных программ может быть резко повышен, если автоматы не строить эвристически, а генерировать на основе генетического программировании [13].

- 27 - УМП «Автоматизированные методы разработки архитектуры ПО» 2.7. Вопросы и задания для самостоятельной работы студента по теме «Генеративное, интенциональное и автоматное программирование» 1) Дайте определение Generative Programming.

2) Перечислите основные понятия порождающего программирования.

3) В чем отличие от просто генерации кода 4) Существуют ли проблемы при повторном использовании кода 5) Какие Вы знаете генераторы кода 6) Дайте объяснение сокращению IP.

7) Что такое автоматное программирование 8) В чем заключается подход генетического программирования 9) Назовите отличия генеративного программирования от компонентно-ориентированного программирования 10) Что такое повторное использование кода 11) Что такое паттерн проектирования 12) Что было создано в результате работ Чарльза Симони 13) Какое направление развивает Сергей Дмитриев в области разработки ПО 14) Какое направление развивает Анатолий Шалыто в области разработки ПО Литература по теме «Генеративное, интенциональное и автоматное программирование» • Чарнецки К., Айзенекер У. Порождающее программирование:

методы, инструменты, применение. СПб.: Питер, 2005.

• Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы, СПб.: Символ-Плюс, 2001.

• Дубина О. Обзор паттернов проектирования.

http://citforum.ru/SE/project/pattern/index.shtml#toc • Ксензов М. Рефакторинг архитектуры программного обеспечения:

выделение слоев. Труды Института Системного Программирования РАН, 2004 г.

• http://www.citforum.ru/SE/project/refactor/ • Fowler M. Language Workbenches: The Killer-App for Domain Specific Languages http://martinfowler.com/articles/languageWorkbench.html • The Meta Programming System (MPS), http://www.jetbrains.com/mps/ • Интервью Сергея Дмитриева. www.codegeneration.net/, http://www.codegeneration.net/tiki-read_article.phparticleId= - 28 - УМП «Автоматизированные методы разработки архитектуры ПО» • Сайт по автоматному программированию и мотивации к творчеству, http://is.ifmo.ru/ • Шалыто А. А. SWITCH-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука, 1998. http://is.ifmo.ru/books/switch/• Гуров В. С., Нарвский А. С., Шалыто А. А. Исполняемый UML в России //PCWeek/Re, 2005, № 26.

http://is.ifmo.ru/works/_umlrus.pdf • Гуров В. С., Мазин М. А., Нарвский А. С., Шалыто А. А.

Инструментальное средство для поддержки автоматного программирования //Программирование. 2007, № 6.

http://is.ifmo.ru/works/uml-switch-eclipse/ • Поликарпова Н. И., Точилин В. Н., Шалыто А. А. Разработка библиотеки для генерации автоматов методом генератического программирования. Сборник докладов X международной конференции по мягким вычислениям и измерениям. СПбГУ ЭТУ ЛЭТИ. 2007. т. 2.

http://is.ifmo.ru/download/polikarpova(LETI).pdf - 29 - УМП «Автоматизированные методы разработки архитектуры ПО» Тема 3. Автоматизация архитектурного проектирования ПО 3.1. Архитектура на базе моделей Для моделирования архитектуры разрабатываемого программного обеспечения в качестве языка описания проектируемых моделей используют унифицированный язык моделирования – UML (Unified Modeling Language). Графическое представление проекта ПО началось с применения разработанных инженерами компании IBM шаблонами для изображения блок-схем. Обычно UML применяется в качестве ручного инструмента моделирования с использованием простейших автоматизированных средств автоматизации черчения (“электронного кульмана” для получения “чертежей” программного обеспечения) наподобие базовых средств автоматизированного проектирования CAD (Computer Aided Design).

Разработанный Гради Бучем (Grady Booch), Джимом Рэмбо (James Rumbaugh) и Иваром Якобсон (Ivar Hjalmar Jacobson) графический язык UML позволяет архитектору программного обеспечения визуализировать, документировать, специфицировать и конструировать проекты ПО. Принятый организацией по стандартам Object Management Group (OMG http://www.omg.org/) в качестве стандарта моделирования алгоритмов, язык моделирования UML широко применяется сообществом разработчиков программного обеспечения. Язык UML является формальным языком спецификаций и отличается тем самым от синтаксиса традиционных формально-логических языков и языков программирования. Использование UML связано с последовательностью ведения проектных работ. Сначала проект алгоритма описывается на языке UML. После этого алгоритм вручную переписывается на языке программирования. Полученный результат компилируется в машинный код и подвергается тестированию. Если для такой последовательности применять CASE-средства, большинство из которых имеют встроенные или интегрируемые средства построения UML моделей, то в зависимости от заложенных в этих средах программирования возможностей архитектор получает возможность существенно снижать уровень ручного программирования при формировании макетов проектных решений.

Естественное развитие уровня автоматизации процесса разработки проектов ПО, а также развитие языка UML привели к смене парадигмы и к появлению идей MDA (Model Driven Architecture – "Архитектура на базе моделей"). Обозреватель журнала Computerworld Ян Метлис пишет в статье “Архитектура на базе моделей”[14]: …”Идея, лежащая в основе MDA, заключается в предельной автоматизации процесса генерации - 30 - УМП «Автоматизированные методы разработки архитектуры ПО» кода, благодаря чему разработчики могут сосредоточиться на создании самого алгоритма”. Далее Ян Метлис отмечает, что: “…OMG перенесла фокус своего внимания с архитектуры Common Object Request Broker Architecture (CORBA) на MDA в 2000 году. Тогда появилось официальное описание, положившее начало процессу классификации и стандартизации, а также создания новой лексики, в том числе основных понятий платформонезависимой модели (Platform Independent Model, PIM), платформозависимой модели (Platform Specific Model, PSM) и механизма хранения объектных метаданных (Meta-Object Facility, MOF) …”.

Целью деятельности организации OMG является разработка стандартов и спецификаций, регламентирующих применение новых информационных технологий на различных аппаратных и программных платформах. Стандарты и технологии UML, CORBA и MDA, разрабатываемые при участии OMG предлагают интегральный подход к созданию многоплатформенных приложений и обеспечивыют возможность взаимодействия между этими приложениями.

Концепцией MDA является описание представления алгоритмов на языке моделирования с последующим автоматическим преобразованием моделей в компьютерный код, причем программирование на базе моделей предполагает, что проектировщики ПО прежде всего создают наиболее подходящую модель, не "привязываясь" к платформе, на которой система будет реализована.

Таким образом, при создании модели разработчик ПО полностью абстрагируется от особенностей конкретных программных и аппаратных средств реализации ПО. Следовательно, основным элементом программирования в MDA является платформенно-независимая модель PIM (Platform Independent Model). Формируемая платформеннонезависимая модель создается на языке унифицированного моделирования UML. Перевести замысел в практическую плоскость позволили технологии объектно-ориентированного программирования (ООП), языки UML, XML, MOF и т.д.

В соответствии с идеей технологии MDA первоначально выделяется разработка бизнес-логики функционирования приложения.

Создаваемая модель приложения определяет поведение, состав и структуру проектируемого программного продукта.

На следующем этапе, после создания модели PIM, создаются одна или несколько платформенно-зависимых моделей, так называемые PSM (Platform Specific Model), назначение которых обеспечение интеграции PIM с одной или несколькими технологиями разработки программных продуктов. На этом же этапе создаются программные интерфейсы для взаимодействия данного приложения с другими.

На заключительном этапе, на основании PIM и PSM, генерируется код приложения и, при необходимости, база данных. Для нескольких PSM генерация проводится несколько раз – для каждой из - 31 - УМП «Автоматизированные методы разработки архитектуры ПО» используемых платформ. Генерация кода и баз данных при этом осуществляется автоматически, с использованием специализированных инструментальных программных средств. Важным преимуществом концепции MDA является то, что при разработке приложений основные усилия разработчиков ПО переносятся с этапа программирования на этап создания модели ПО. Кроме того, создав модель один раз, разработчии получают принципиальную возможность генерации приложений для разных аппаратных и программных платформ.

Преимущества, которые MDA предоставляет разработчикам ПО, очевидны: локализация в модели всей логики приложения и автоматическая генерация кода и баз данных.

MDA не является конкурентным подходом в сравнении какойлибо из существующих технологий создания ПО (CORBA, J2EE, Sun ONE и.NET). MDA находится на более высоком уровне обобщения процесса разработки, позволяя на этапе создания PIM-модели абстрагироваться от этих платформ, на следующем этапе выбрать одну или несколько платформ разработки и создать соответствующий набор PSM-моделей и, наконец, на этапе генерации кода получить приложение, функционирующее на этих платформах. Разработчики из OMG относятся к MDA не только как к новой технологии, а считают MDA «метатехнологией» создания ПО, которая уже «заранее интегрировала» в себя будущие средства разработки программного обеспечения. Сценарий создания приложений по технологии MDA полностью соответствует технологиии генеративного программирования: создается модель, которая поступает на вход специальной программы, а на выходе генерируются готовое приложение и база данных. Изменения, связанные с модификацией разработки также вносятся в модель, и затем процедура генерации повторяется, причем без внесения изменений в код приложения. Из этого также следует, что само понятие «разработчик программного обеспечения» позволит специалистам предметной области наиболее плодотворно участвовать в таком программировании.

В основе архитектуры MDA содержится идея о полном разделении этапов общего проектирования (моделирования) и последующей реализации приложения на конкретной программной платформе.

Первоначально при помощи специальных средств проектирования создается общая и независимая от способов реализации модель приложения, а затем осуществляется реализация программы в какойлибо среде разработки. При этом процесс разработки полностью основан на модели, которая должна содержать всю необходимую для программирования информацию.

Такой подход позволяет теоретически обеспечить:

o Независимость модели от средств разработки, которая позволяет реализовать модель на любой программной платформе.

- 32 - УМП «Автоматизированные методы разработки архитектуры ПО» o Реализованное в архитектуре MDA программное обеспечение, может быть перенесено из одной операционной системы в другую.

o Экономия ресурсов при реализации ПО для нескольких программных платформ одновременно.

Технология MDA практически позволяет автоматизировать процесс программирования. Реализация ПО в соответствии с технологией MDA позволяет автоматизиpовать создание тех типовых частей приложения, разработка которых поддается автоматизации, так, например создание пользовательского интерфейса, программирование типовых операций, создание базы данных и организация доступа к данным.

Автор книги «Delphi и Model Driven Architecture. Разработка приложений баз данных" [15] и сайта http://www.mdadelphi.com/index.phplng=ru Константин Грибачев пишет:

“…Циклограмма создания MDA-приложений также содержит потенциальную возможность итерационной разработки. Однако в этом случае разработчик возвращается на этап I и при необходимости корректирует PIM-модель (рис. 3) приложения.

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 16 |






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.