Текст книги "Системы автоматизации разработки программного обеспечения"

1.4 Современные технологии разработки программного обеспечения

Разработка программного обеспечения является молодой и быстро развивающейся отраслью инженерной науки, которая подвержена постоянным и быстрым изменениям. Так, лишь в начале 90-х годов Британское сообщество вычислительной техники (British Computer Society) начало присваивать разработчикам программ квалификацию инженера (Chartered Engineer), а в Соединенных Штатах (в штате Техас) только в 1998 году стало возможным зарегистрироваться в качестве профессионального инженера программного обеспечения. Но по-прежнему, даже в начале 21-го века, общепризнанным остается тот факт, что разработке программного обеспечения не достает развитой научной базы. По некоторым оценкам, 75 % организаций программной индустрии занимаются разработкой программ на интуитивном уровне. С другой стороны, в этой области сформировалось немало интересных идей и знакомство с ними является содержанием настоящей лекции.

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

Наиболее известные технологии КОП представлены на рисунке 1.23.

Рисунок 1.23 – Технологии компонентно-ориентированного программирования

Концепция технологии COM для семейства операционных систем Windows заключается в построении программ из компонент, которые состоят из объектов, представляющих собой непосредственно исполняемый двоичный код. Важнейший признак «компонентности» – исполняемую программу можно собирать из отдельных частей без операций сборки (модуля).

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

Отличие COM от привычных объектов в стиле ООП состоит в том, что объекты ООП известны только компилятору. Это абстракции, в которых мыслит программист и которые компилятор превращает в двоичные структуры «данные + код». Технология COM есть технология, которая переносит все преимущества ООП, доступные программисту на уровне исходного текста, на двоичный уровень. Если в исходном тексте технологии ООП программист волен использовать любые объекты, но теряет всяческий контроль над тем, что сделано, как только исходный текст скомпилирован, то при использовании COM эти возможности сохраняются на протяжении всего жизненного цикла программы. Кроме того добавляются возможности разделения проекта на отдельные, повторно используемые, двоичные компоненты.

Хронология развития технологии COM показана на рисунке 1.24.

Рисунок 1.24 – Хронология развития технологии COM

Использованные сокращения: Dynamic Link Libraries (DLL) – динамически подключаемые библиотеки, Open DataBase Connectivity (ODBC) – открытый интерфейс доступа к базам данных, встроенный в Windows и Windows NT, Dynamic Data Exchange (DDE) – динамический обмен данными, Object Linking and Embedding (OLE1.0) – внедрение и связывание объектов, OLE2.0 – OLE на базе COM, Distributed COM (DCOM) – распределенная модель компонентных объектов, COM+ – новейшая технология COM.

Главная идея технологии ODBC заключается в создании промежуточного программного слоя, который определяет стандартный интерфейс для приложений. На уровне вызовов этот интерфейс использует язык SQL, а реализация взаимодействия с БД обеспечивается драйверами, поставляемые в форме DLL. Таким образом, ODBC располагается между приложением и источниками данных различных форматов.

Технологию динамического обмена данными DDE можно рассматривать как попытку стандартизации обмена данными между приложениями. Концепция Windows основана на обработке сообщений (messages). Отсюда приложения могут обмениваться друг с другом сообщениями, используя общую очередь сообщений. Проблема состоит в том, что каждое из приложений должно знать протокол обмена данными, т.е. формат сообщений. Технология DDE как раз и предложила такой стандартный протокол, реализованный во многих приложениях. Недостатками DDE является сложность программирования, невысокая надежность и то обстоятельство, что приложения должны знать формат передаваемых данных.

Технологию внедрения и связывания объектов OLE1.0 фирма Microsoft представила в 1991 г. как попытку реализации объектно-ориентированного механизма взаимодействия приложений. Главной идеей OLE является концепция составного документа, который может содержать объекты других приложений. До OLE приложения могли обмениваться статическими снимками данных через буфер обмена Windows. Однако редактирование таких данных должно выполняться тем приложением, которое их породило, а после редактирования они вновь должны быть вставлены в другой документ. Если изменяются исходные данные, то, очевидно, должны изменяться данные и в составном документе. Однако, системный буфер обмена не имеет никаких средств поддержания таких связей. Более того, проблемы возникают и при перемещении исходных данных в новое место. Внедренный с помощью OLE1.0 объект содержит статические данные и данные, необходимые для его редактирования. Для редактирования объекта пользователю приложенияконтейнера необходимо щелкнуть по объекту, вследствие чего в отдельном окне запускается исходное приложение, породившее эти данные. По окончании редактирования пользователь может сохранить данные, которые будут обновлены и в приложении-контейнере.

Недостатками технологии OLE1.0 являются:

– базовый механизм OLE1.0 – DDE по своей природе асинхронен, т.е. возврат управления при вызове любой функции происходит немедленно, но после завершения операции;

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

– связи OLE1.0 легко разрываются при перемещении файлов;

– пользователю неудобно редактировать данные в отдельном окне.

Архитектура программных компонентов, разработанных по технологии СОМ, и взаимодействие СОМ-объектов показана на рисунке 1.25.

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

Рисунок 1.25 – Архитектура приложений на основе программных компонентов

Объекты СОМ всегда функционируют в составе сервера – динамической библиотеки и исполняемого файла. Различают три типа серверов, представленных на рисунке 1.26.

Рисунок 1.26 – Реализация технологии СОМ

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

Модификация COM, обеспечивающая передачу вызовов между компьютерами, называется DCOM. При использовании удаленных серверов в адресном пространстве клиента создается proxy-объект (заместитель объекта COM), а в адресном пространстве сервера COM – заглушка, соответствующая клиенту. Получив задание от клиента, заместитель упаковывает его параметры и, используя службы ОС, передает вызов заглушке. Заглушка распаковывает задание и передает его объекту COM.

Результат возвращается объекту в обратном порядке.

Технология CORBA, разработанная группой компании OMG (группа внедрения объектной технологии программирования), реализует подход, аналогичный COM, но на базе объектов и интерфейсов СORBA. Программное ядро СORBA реализовано для всех основных аппаратных и программных платформ и потому эту технологию можно использовать для создания распределенного ПО в гетерогенной (разнородной) вычислительной среде. Организация взаимодействия между объектами клиента и сервера в СORBA осуществляется с помощью специального посредника, названного VisiBroker.

Последовательность операций технологии КОП представлена на рисунке 1.27.

Рисунок 1.27 – Последовательность технологических операций КОП

Таким образом, технология КОП существенно упрощает разработку, позволяет сократить сроки проектирования за счет повышения повторяемости элементов программных системы и автоматизации отдельных этапов разработки, т.е. реально перейти к индустриальному методу разработки программного обеспечения АИС

Современные методологии и реализующие их технологии поставляются в электронном виде вместе с CASE-средствами и включают библиотеки процессов, шаблонов, методов, моделей и других компонент, предназначенных для построения ПО того класса систем, на который ориентирована методология. CASE-средства поддерживают внедрение автоматизированных технологий на всех этапах жизненного цикла ПО – СASE-технологии (Computer-Aided Software/System Engineering – разработка программного обеспечения/программных систем с использованием компьютерной поддержки).

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

На рисунке 1.28 представлены базовые CASE-средства современных технологий разработки ПО.

Рисунок 1.28 – Базовые CASE-средства современных технологий разработки ПО

BPwin – мощный инструмент моделирования программных систем, который используется для анализа, документирования и реорганизации сложных бизнес-процессов. Модель, созданная средствами BPwin, позволяет четко документировать различные аспекты деятельности – действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. При этом формируется целостная картина деятельности предприятия – от моделей организации работы в отделах до сложных иерархических структур. Модели бизнес-процессов служат прекрасным средством документирования потребностей, помогая обеспечить высокую эффективность инвестиций в сферу IT. В руках же системных аналитиков и разработчиков BPwin – мощное средство моделирования процессов при создании корпоративных информационных систем (КИС).

BPwin совмещает в одном инструменте средства моделирования функций (IDEF0), потоков данных (DFD) и потоков работ (IDEF3), координируя эти три основных аспекта бизнеса для соответствия потребностям бизнес-аналитиков и системных аналитиков.

ERwin (AllFusion ERwin Data Modeler 4.1) предназначен для проектирования, внедрения и поддержки баз данных, хранилищ данных и моделей данных масштаба предприятия.

Интеграция с другими продуктами:

ModelMart – среда для совместной работы группы проектировщиков BPwin и/или ERwin над одним проектом. Позволяет управлять проектом моделирования, повышает скорость и эффективность работы.

ADvantage – линейка продуктов для поддержки всех стадий разработки программного обеспечения (аналог Rational Suite) В ADvantage, в частности, входит линейка CASE-средств ERwin Modeling Suite (ERwin, BPwin, ModelMart, Paradigm Plus, ERwin Examiner) и средства управления проектами. Совместное применение этих продуктов обеспечивает прочный фундамент для построения, развертывания и управления приложениями.

Paradigm Plus – средство проектирования компонентов ПО и кодогенерации. Двусторонняя связь между продуктами позволяет импортировать смоделированные бизнес-процессы в Paradigm Plus как use cases и экспортировать их в BPwin.

Model Navigator – продукт для просмотра моделей ERwin и BPwin с возможностью генерации отчетов.

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

Rational Rose – средство визуального моделирования объектноориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое, кроме того осуществляет такие подходы, как прямое и обратное проектирование.

Известны следующие продукты компании:

Rational Software Architect – средство моделирования (дальнейшее развитие Rational Rose на платформе Eclipse).

Rational PurifyPlus – набор программ для вылавливания утечек памяти, анализа области перекрытия кода и производительности кода.

Rational ClearCase – система управления версиями.

Rational RequisitePro – система управления требованиями.

Rational ClearQuest – система управления изменениями.

SoDA – система автоматизированного документирования.

Rational Robot и Rational Functional Tester – средство автоматизированного тестирования.

Rational Performance Tester – средство автоматизированного нагрузочного тестирования.

Rational Process Advisor – инструмент интеграции процесса разработки ПО при помощи инструментов разработки и тестирования.

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

Рисунок 1.29 – Последовательность технологических операций на основе CASE-средств

Таким образом, CASE-технологи позволяют автоматизировать большинство технологических операций, т.е. реально перейти к индустриальному методу разработки программного обеспечения АИС.

1 В чем заключается технология компонентно-ориетированного программирования.

2 В чем заключается концепция технологии COM.

3 В чем заключается основная идея технологии ODBC?

4 Поясните сущность технологии CORBA.

5 Перечислите последовательность технологических операций технологий КОП.

6 Перечислите базовые Case – средства современных технологий разработки ПО. Дайте основные характеристики функциональным возможностям Case – средства BP Win.

7 Дайте основные характеристики средству визуального моделирования объектно ориентированных систем.

8 Перечислите последовательность технологических операций на основе Caseсредств.

9 Дайте основные характеристики функциональным возможностям Case – средства Rational Rose.

10 Поясните архитектуру приложений на основе программных компонентов.

2 Автоматизация разработки программного обеспечения на основе UML

2.1 Спецификация программного обеспечения при использовании UML

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

В настоящее время фактически стандартным средством описания проектов ПО, создаваемого с использованием объектно-ориентированного подхода, признан унифицированный язык моделирования – UML (Unified Modeling Language), первой версии которого появилась в I995 г. Его создателями являются ведущие специалисты в области программной инженерии: Гради Буч, Ивар Якобсон и Джеймс Рамбо, которые использовали в этом языке все лучшее, что появилось в подходах этих авторов во время «войны методов».

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

Основные принципы построения моделей в UML:

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

– многомодельность (утверждение, что никакая единственная модель не может с достаточной степенью адекватности описать различные аспекты сложной системы);

– иерархичность (предполагает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений).

Спецификация разрабатываемого ПО при использовании UML объединяет несколько моделей, представленных на рисунке 2.1.

Рисунок 2.1 – Полная спецификация разрабатываемого ПО при использовании UML

Модель использования представляет собой описание функциональности ПО с точки зрения пользователя.

Логическая модель описывает ключевые абстракции предметной области ПО (классы, интерфейсы и т.д.), т.е. средства, обеспечивающие требуемую функциональность.

Модель реализации определяет организацию программных модулей в среде разработки.

Модель процессов отображает организацию вычислений и оперирует понятиями «процессы» и «нити», которые позволяют оценить производительность, масштабируемость и надежность программного обеспечения.

Модель развертывания показывает особенности размещения программных компонентов на конкретном оборудовании.

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

Для реализации каждой из указанных моделей в UML используется девять дополняющих друг друга диаграмм (могут входить в различные модели):

– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе;

– диаграммы классов (class diagrams) – для моделирования статической структуры системы;

– диаграммы поведения системы:

– диаграммы последовательности (sequence diagrams) и диаграммы кооперации (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

– диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования;

– диаграммы состояний (state chard diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

– диаграммы реализации:

– диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем);

– диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

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

Таблица 2.1– Соответствия между терминами и соответствующими нотациями

UML и предлагаемая методика Rational Unified Process поддерживаются пакетом Rational Rose фирмы Rational Software Corporation. Ряд диаграмм UML можно построить также средствами программы Microsoft Visual Modeler и других CASEсредств.

По данным «USA Today» в настоящее время 49 из 50-ти ведущих компьютерных компаний используют UML при проектировании ПО с использованием объектного подхода, что позволяет говорить о том, что сегодня UML фактически стал стандартом описания сложных программных систем.