WWW.DISSERS.RU

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

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


Pages:     || 2 | 3 | 4 | 5 |   ...   | 16 |
Санкт-Петербургский государственный университет информационных технологий, механики и оптики Учебно-методическое пособие по дисциплине «Автоматизированные методы разработки архитектуры программного обеспечения» Генельт А.Е., ассистент кафедры математического моделирования Санкт-Петербург 2007 УМП «Автоматизированные методы разработки архитектуры ПО» Оглавление Тема 1. Архитектура ПО.................................................................. 4 1.1. Проектирование архитектуры систем предметной области.. 5 1.2. Составление плана реализации модели предметной области программного обеспечения.............................................................. 6 1.3. Реализация модели предметной области ПО.......................... 7 1.4. Вопросы и задания для самостоятельной работы студента по теме «Архитектура ПО»................................................................... 8 Литература по теме «Архитектура ПО»......................................... 8 Тема 2. Генеративное, интенциональное и автоматное программирование............................................................................ 9 2.1. Проблема повторного использования кода............................. 9 2.2. Генеративное программирование...........................................11 2.3. Генераторы ПО.........................................................................12 2.4. Применение архитектурных образцов для проектирования ПО.....................................................................................................13 2.5. Интенциальное программирование........................................17 2.6. Автоматное программирование..............................................19 2.7. Вопросы и задания для самостоятельной работы студента по теме «Генеративное, интенциональное и автоматное программирование»........................................................................28 Литература по теме «Генеративное, интенциональное и автоматное программирование»....................................................Тема 3. Автоматизация архитектурного проектирования ПО...3.1. Архитектура на базе моделей.................................................3.1.1. Преобразование моделей PIM PSM................................3.1.2. Многоплатформенные модели........................................3.2. Применение CASE-технологий..............................................3.3. Вопросы и задания для самостоятельной работы студента по теме «Автоматизация архитектурного проектирования ПО»....Литература по теме «Автоматизация архитектурного проектирования ПО»......................................................................Тема 4. Компонентная архитектура..............................................4.1. Стандартная библиотека шаблонов STL...............................4.2. Строки и STL............................................................................4.3. Вопросы и задания для самостоятельной работы студента по теме «Компонентная архитектура»...............................................Литература по теме «Компонентная архитектура».....................Приложение 1. Практический подход при проектировании архитектуры ПО.............................................................................. - 2 - УМП «Автоматизированные методы разработки архитектуры ПО» Приложение 2. Текст исходного кода контейнера string библиотеки STL...............................................................................Предметный указатель.................................................................Литература..................................................................................... - 3 - УМП «Автоматизированные методы разработки архитектуры ПО» Тема 1. Архитектура ПО "...— Это отчетная карточка, — пояснил Кенорос. — Я прошелся по всем командам и оценил их успехи в определении архитектуры приложения по пятибалльной шкале. При этом я интересовался не столько качеством их построений, сколько тем, насколько детально они были проработаны. Если вы описали низкоуровневую архитектуру приложения таким образом, что она определяет все модули кода и все взаимодействия между ними — тогда Кенорос поставит вам пятерку. Если ничего такого у вас нет, то единицу. Все прочие получают какой то промежуточный балл. Вот, посмотри ка...." Первый программист Моровии“Архитектура” и “инженерия”, как виды человеческой деятельности, существовали задолго до появления компьютерных технологий. Прежде всего, эти виды деятельности связывал процесс создания проекта — прототипа, прообраза предполагаемого или возможного объекта. Иными словами проектирование содержит в своем составе понятия “архитектура” и “инженерия”, а проектирование программного обеспечения немногим отличается в этом смысле от проектирования, например, зданий и сооружений. Тенденции развития строительной архитектуры последних десятилетий связаны с максимальной функциональностью проектируемых объектов.

Архитектурное проектирование ПО также преследует аналогичную цель.

Согласно энциклопедии «Википедия»2, архитектура программного обеспечения — это представление системы программного обеспечения, дающее информацию о компонентах составляющих систему, о взаимосвязях между этими компонентами и правилах, регламентирующих эти взаимосвязи, которое предназначено для эффективной разработки проекта такой системы. Проектирование программного обеспечения, в свою очередь, подразумевает выработку свойств системы на основе анализа постановки задачи (моделей предметной области (Domain Design) и требований к ПО), а также опыта проектировщика.

Том Де Марко "Deadline. Роман об управлении проектами". М, Вершина, http://ru.wikipedia.org/ - 4 - УМП «Автоматизированные методы разработки архитектуры ПО» Авторы книги ”Порождающее программирование: методы, инструменты, применение” К. Чарнецки и У. Айзенекер [1] определяют проектирование архитектуры ПО как “высокоуровневое проектирование, целью которого является создание гибкой структуры, удовлетворяющей всем основным требованиям и предусматривающей некоторую степень свободы реализации. Как правило, из тех деталей, которые менее других подвержены изменениям, формируется «скелет».

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

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

Целью архитектурного проектирования предметной области является следующие артефакты:

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

o составление плана реализации модели предметной области;

o реализация модели предметной области.

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

В гражданском и промышленном строительстве языком описания проекта являются архитектурно-строительные чертежи и объемные модели, а также текстовые описания возводимых объектов и технологий их возведения. В качестве иллюстративных средств выражения характеристик ПО, в архитектурном проекте используются различные нотации – блок-схемы (схемы алгоритмов), ER-диаграммы, UMLдиаграммы, DFD-диаграммы, а также макеты. Каждая подсистема ПО, состоящая из совокупности ее компонентов и взаимодействий между ними, должна быть детально описана в соответствующей части проекта - 5 - УМП «Автоматизированные методы разработки архитектуры ПО» с использованием этих нотаций. Поскольку такая подсистема может выступать в качестве составного элемента более масштабной системы, в архитектурном проекте ПО обязательно содержится подробное описание укрупнённых частей системы с помощью этих же средств описания проекта.

Относительно употребленного термина “компонент”, Питер Илес (старший разработчик архитектуры информационных технологий, IBM) в статье "Что такое архитектура программного обеспечения" [2] пишет, что “…большая часть определений архитектуры не определяет термина "компонент", и стандарт IEEE 1471 – не исключение, поскольку намеренно оставляет это понятие неопределенным, чтобы оно соответствовало множеству толкований, возможных в отрасли.

Компонент может быть логическим или физическим, технологическинезависимым или технологически-связанным, крупно- или мелкогранулированным...”.

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

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

Архитектурная часть проекта сборки модели предметной области содержит описания:

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

o процессов сборки компонентов;

o обработки запросов на изменения и разработку;

o измерений, сопровождения и оптимизации бизнеспроцессов.

Данная часть проекта описывает сборку разрабатываемого объекта с вероятным использованием автоматизированных средств для сборки модели. Уровень автоматизации сборки зависит от множества факторов и связан как с программно-технической оснащённостью проекта, так и с наличием достаточного уровня применяемых артефактов предметной области (в том числе с применением повторного кода).

- 6 - УМП «Автоматизированные методы разработки архитектуры ПО» В общем случаяе возможны следующие варианты сборки моделей проектов:

o Сборка приложений из компонентов производится вручную.

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

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

o Автоматическая сборка модели объекта с применением инструментальных средств для заказчика (средств порождающего программирования), при помощи которых формируется запрос на необходимое ПО. Производство приложения может быть достигнуто одним запросом, если в нём не содержится частей, создаваемых традиционными методами разработки. Детальный процесс сборки также содержится в Руководстве разработчика. В состав проекта также входят описания архитектуры и компонентов, реализации предметно-ориентированных языков, руководства по размещению графических пользовательских интерфейсов, генераторов и инфраструктуры, при помощи которой проводится поиск, классификация, распространение компонентов и тому подобные операции, а также организации процессов производства приложений. Вся документация также формируется автоматически.

1.3. Реализация модели предметной области ПО На данном этапе производится реализация архитектуры, компонентов и плана реализации при помощи методик, содержащихся в проекте.

- 7 - УМП «Автоматизированные методы разработки архитектуры ПО» 1.4. Вопросы и задания для самостоятельной работы студента по теме «Архитектура ПО» 1) Что такое архитектура ПО 2) Какие артефакты являются целью проектирования архитектуры ПО” 3) Какова роль архитектора при создании ПО 4) В каком порядке (очередности) выполняются процессы проектирования ПО: проектирование архитектуры систем предметной области, cоставление плана реализации модели и реализация модели 5) Назовите состав архитектурной части проекта разработки программного обеспечения.

6) Какова роль архитектора при создании ПО Литература по теме «Архитектура ПО» • Чарнецки К., Айзенекер У. Порождающее программирование:

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

• Илес П. Что такое архитектура программного обеспечения http://www.interface.ru/home.aspartId=• Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы, СПб.: Символ-Плюс, 2001.

- 8 - УМП «Автоматизированные методы разработки архитектуры ПО» Тема 2. Генеративное, интенциональное и автоматное программирование "... Most new ideas in software developments are really new variations on old ideas....." Мартин ФаулерПри написании этой главы авторы собирались ответить на вопрос – что должен знать архитектор программного проекта. Немногие из опрошенных профессионалов отвечали на этот вопрос так: «то же, что и хороший программист», «всё», «то же, что и менеджер проекта/директор/технический директор». Интересен также ответ «каждый из нас время от времени работает в роли то архитектора, то технического писателя, а то и программиста одновременно».

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

2.1. Проблема повторного использования кода Каждый программист, выполняя свою работу, производит код для повторного использования и применяет код повторного использования.

Любой макрос или библиотека представляют собой ранее произведённый и оптимизированный продукт, применение которого вносит очевидные преимущества в текущую разработку. Если при проектировании следующей версии разработки или при производстве заказа сходного с ранее выполненным заказом в текущий проект вносятся фрагменты ранее произведённого кода, изменённые в соответствии с данным техническим заданием, и в этом случае повторное использование кода также вносит преимущества в новый проект. Надежды разработчика на получение надёжного и устойчивого кода в текущей разработке могут неожиданно омрачаться в связи с выявлением ошибок в ранее произведённом коде и/или с выявлением несоответствия части практически готового кода текущим потребностям заказчика. Формально ранее произведённый код может соответствовать или не соответствовать требованиям текущего проекта. Фактически любая группа разработчиков или отдельных исполнителей применяет на практике ранее разработанный код так же, как это делают мастера в других областях деятельности, имея для каждого вида работ свой набор “Новые идеи в области разработки программного обеспечения, как правило, представляют собой лишь вариации на тему старых”. Language Workbenches: The Killer-App for Domain Specific Languages (http://martinfowler.com/articles/languageWorkbench.html) - 9 - УМП «Автоматизированные методы разработки архитектуры ПО» инструментов. Для программирования мы также применяем множество доступных инструментов, но создаваемый нами код является наиболее ценным и постоянно модифицируемым набором инструментальных программных средств повторного применения.

Pages:     || 2 | 3 | 4 | 5 |   ...   | 16 |






















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

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