Визуальное компонентное программирование

Кыргызский Национальный Университет им.Ж.Баласагына

Центр Непрерывного Образования и  Повышения Квалификации

Колледж Информационных Технологий

Курсовая работа

На тему: Визуальное компонентное программирования

Группа: ПОВТ и АС 3-10

Выполнила: Урматбек кызы Айназик

Проверил: Опобеков Сатарбек

                                                          Бишкек 2013 год 

Содержание 

Введение  _____________________________________________________3

Глава 1. Обзор  существующих подходов ___________________________5

Компьютерная инженерия _______________________________________5

Язык SDL (Specification and Description Language) _____________________5

Метод OOSE (Object-Oriented Software Engineering) ___________________6

Метод Буча _____________________________________________________8

Язык UML (Unified Modeling Language) ______________________________9

Методология ROOM (Real-time Object-Oriented Modeling) _____________10

Метод RUP (Rational Unified Process) _______________________________11

Определение CASE-пакета _______________________________________13

Компонентные  системы ________________________________________14

Системы реального  времени ____________________________________15

Обзор существующих подходов к проектированию компонентного ПО с применением расширенных конечных автоматов ___________________15

Язык SDL ______________________________________________________16

Компонента  ___________________________________________________16

Интерфейс и  порт ______________________________________________18

Поведенческая модель _________________________________________19

Глава 2. Методология CASE-пакета ________________________________21

Предназначение  визуального моделирования и  определение CASE-пакета 22

Принцип представления  информации о разрабатываемой системе  с точки зрения визуального моделирования  _______________________________25

Язык визуального  моделирования  ________________________________26

Принципы  моделирования  ______________________________________28

Технологическое решение  ______________________________________28

Глава 3. Моделирование  компонентного ПО _______________________29

Компонента  ___________________________________________________30

Интерфейс ____________________________________________________30

Заключение  ___________________________________________________32

Указатель литературы __________________________________________33

Введение

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

Актуальность этого направления  обнаруживает проблемы практического  применения визуального моделирования.

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

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

Общие методы объектно-ориентированного анализа и проектирования программного обеспечения существенно повлияли на более специализированную область  компьютерной инженерии – компонентный подход к созданию ПО. Компонентность, будучи специальным частным случаем объектной ориентированности, успешно решает проблему инкапсуляции сложности. На уровне платформ программирования компонентность поддерживается широко: можно назвать ActiveX-технологии, Java Beans и т.д. Но на уровне средств визуального моделирования, предназначенных для анализа и проектирования таких систем, компонентность поддерживается слабо и неполно. В UML компонента отождествляется с классом или элементом физической структуры ПО, в ROOM (Real-Time Object-Oriented Modeling) компонента рассматривается в очень узком смысле – как “черный ящик”, способный взаимодействовать с внешним миром только через сообщения, в то время как компоненты реального ПО могут вызывать также методы друг друга и т.п.

В данной работе предложена новая  компонентная модель, основанная на модели классов UML и расширенная чертами структурных моделей ROOM и SDL (Specification and Description Language), что позволяет проектировать компонентное ПО различного вида (телекоммуникационные системы, интернет-приложения, информационные системы и т.д.).

Настоящая работа является составной частью исследований в рамках проекта Real. Лаборатория системного программирования НИИММ СПбГУ совместно с кафедрой системного программирования математико-механического факультета СПбГУ при финансовой поддержке ГП “Терком” и ЗАО “Ланит-Терком” занимается технологиями программирования с 1984 года, когда для ЕС ЭВМ был создан первый графический SDL-редактор. Дальнейшее движение осуществлялось следующих направлениях: создание средств имитационного моделирования, автоматическая генерация программ для инструментальной и целевых платформ, погружение сгенерированного ПО в целевые комплексы вычислительных средств. Важным направлением развития явилась ориентация на проблемы генерации данных. Результатом этих исследований стала объектно-базированная система RTST (Real-Time Software Technology) основанная на языке Алгол 68 и рекомендациях ITU (International Telecommunication Union). С помощью этой системы было создано несколько телефонных станций общего и специального назначения.

В начале 90-х  годов появилось много работ  по объектно-ориентированной компьютерной инженерии. OMT/UML и ROOM стали дополнительными  источниками новых идей и подходов. Однако UML в чистом виде оказался неприменимым для создания эффективного CASE-пакета и был творчески переосмыслен участниками проекта Real.

Глава 1. Обзор существующих подходов

Компьютерная  инженерия

В 1968 году на одной из конференций НАТО по проблемам  разработки программного обеспечения  был предложен термин “Software Engineering”. Так была названа новая научная дисциплина, объектом исследования которой являются проблемы создания больших компьютерных систем.

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

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

Язык SDL (Specification and Description Language)

Specification and Description Language (SDL) в переводе с английского – язык спецификаций и описаний. Под спецификацией понимается точное формальное определение системы или ее части, под описанием – неформальная спецификация, иллюстрирующая тот или иной аспект системы. Описания используются на ранних этапах разработки системы или для ее документирования, спецификации – на стадии детального проектирования, и по ним предполагается автоматическая генерация программного кода. Тот факт, что для этих разных этапов разработки системы предлагается один язык, является несомненным достоинством SDL, поскольку в этом случае преодолевается проблема семантических разрывов.

Язык SDL предназначен для разработки событийно-ориентированных распределенных систем. Он развивается международным  комитетом ITU с 1976 года и является одним  из долгожителей в компьютерной инженерии. Есть два варианта этого языка  – текстовый (SDL/PR) и графический (SDL/GR), семантика которых, за исключением  некоторых тонкостей, совпадает. Более  десяти фирм в Европе (Telelogic, Verilog и т.д.) разрабатывают CASE-средства на основе SDL. Эти продукты используются многими крупными европейскими фирмами-производителями телекоммуникационных систем.

Кроме языка SDL комитет ITU предложил  целое семейство стандартов на средства разработки телекоммуникационных систем. Можно назвать язык высокого уровня CHILL , MSC (графический язык сценариев). В Европе ежегодно проходит большое количество конференций, где обсуждаются различные аспекты этих стандартов.

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

Метод OOSE (Object-Oriented Software Engineering)

Этот подход изложен в работе, которая является одной из фундаментальных в области объектно-ориентированных методов разработки ПО. Основная задача этого подхода: приблизить компьютерную инженерию к типовому промышленному процессу, каковым является, например, строительство. Основополагающий принцип подхода – объектная ориентированность, как для анализа, проектирования, программирования, так и для описания процесса разработки ПО в целом. Подход предназначен, в первую очередь, для разработки больших систем. На основе OOSE создан метод Objectory, реализованный в продукте фирмы Objectory AB. В 1995 году, после слияния этой фирмы с Rational Software Corp., этот метод использовался при создании RUP (Rational Unified Approach).

В OOSE предлагается компактное описание структуры компьютерной инженерии (рис. 1), в основании которой находится  понятие архитектуры. В это понятие  включаются основные концепции и  техники, определяемые как объектная  ориентированность, определенный набор  полуформальных моделей с графическими нотациями, которые предоставляются для описания разрабатываемой системы.

Выше следует метод – линейная последовательность шагов, процедура  создания идеальной системы “с нуля”. Метод описывает то, как применять  архитектуру к разработке системы.

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

И, наконец, инструментальные средства – это воплощение архитектуры, метода и процесса в конкретном программном  продукте – CASE-средстве, с помощью  которого происходит разработка системы.

Анализ и проектирование в OOSE основаны на методе случаев использования (use case approach), с помощью которых, через построение для них сценариев, выделяются объекты. Предлагается несколько объектных моделей для разных стадий разработки системы и, как в SDL, блочный анализ.

Метод Буча

Основой иерархии понятий являются методология и  метод.

“Методология  – это набор методов, применяемых  в процессе всего жизненного цикла  создания программного обеспечения  и объединенных единой философской  концепцией.” В качестве такой  концепции у Буча выступает объектно-ориентированный взгляд на мир.

“Метод – это четко определенный процесс создания набора моделей  с помощью ясно специфицированных  нотаций; эти модели описывают различные  аспекты программного обеспечения.” Буч называет свой подход методом и делит его на три части – нотации, процесс, прагматика.

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

Нотация – это графический язык для описания моделей. Эта часть  метода является формальной.

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

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

Язык UML (Unified Modeling Language)

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

Язык UML развивается с 1994 года и  является результатом слияния трех самых известных объектно-ориентированных  подходов: метода Буча, OMT  и OOSE . В 1997 году UML был принят в качестве стандарта комитетом OMG и практически заменил собой остальные объектно-ориентированные подходы. UML является грандиозной попыткой выработать на основе объектно-ориентированного подхода универсальный язык графического моделирования для анализа проектированию сложных компьютерных систем. Он объединяет большое количество различных графических нотаций с целью упорядочивания хаотического набора графических средств, используемых при создании ПО. Стандартизация здесь существенно повышает уровень понимания между различными специалистами, разрабатывающими сложную систему. Кроме того, стандарт облегчает переносимость спецификаций, выполненных в разных CASE-пакетах.

Ниже кратко рассматриваются понятия UML, на которых основаны средства структурной  декомпозиции проекта и разрабатываемой  системы.

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

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

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

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

Подсистема аналогична блоку в SDL, однако в целом система понятий UML более общая, чем в SDL.

Методология ROOM (Real-time Object-Oriented Modeling)

Real-Time Object-Oriented Modeling (ROOM) – это объектно-ориентированная методология разработки систем реального времени. Она развивается канадской фирмой ObjecTime Limited, которая на основе этой методологии выпустила программный продукт ObjecTime. Методология была анонсирована в 1992 году. В 1994 году в свет вышла монография, содержащая полное описание ROOM. Эти работы являются базисом для создания мостов между программными продуктами, реализующими ROOM и UML.

ROOM содержит два уровня  представления разрабатываемой  системы:

уровень схем;

уровень детализации.

Выделение этих уровней нацелено на автоматическую кодогенерацию. Таким образом, данная методология существенно отличается от UML, где предлагаются лишь точки зрения на систему (view), применение которых не вполне понятно. Для уровня схем ROOM предлагает набор графических нотаций. Уровень детализации предполагает использование языка реализации, поскольку очевидно, что всю систему, если она достаточно сложна, не специфицировать в виде картинок, по которым можно автоматически сгенерировать работающую программу.

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

Метод RUP (Rational Unified Process)

UML является только языком  моделирования. Способы применения  вынесены из его спецификации  в отличие от предшествовавших  ему подходов. Компания Rational Corp. создала надстройку над UML под названием RUP [35], которая систематизирует процесс создания ПО на основе UML, предлагая при этом использовать определенный набор программных продуктов (главным образом, компании Rational Corp.).

Структура метода RUP представлена на рис. 2.

Фаза – это этап разработки системы. С ней, как правило, связана  промежуточная или окончательная  отчетность по проекту. RUP выделяет следующий  набор фаз:

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

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

Конструирование – фаза реализации проекта.

Передача – фаза передачи системы заказчику.

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

Метод RUP допускает итеративность  внутри одной фазы. Как правило, результатом  итерации является прототип системы. Приводятся следующие варианты количества итераций по фазам: [0,1,1,1], [1,2,2,1], [1,3,3,2]. Таким образом, формулируется общее правило  о количестве итераций внутри одного цикла: 6 плюс/минус 3.

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

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

Определение CASE-пакета

CASE-пакет является программным  продуктом, реализующим определенный  подход компьютерной инженерии.  В работе [36] дается следующие определение:

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

В этой же работе определяются основные компоненты CASE-пакета:

репозиторий;

графические редакторы;

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

средства конфигурационного  управления проектом;

средства документирования проекта;

средства тестирования;

средства управления проектом;

средства реинжениринга.

Компонентные  системы

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

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

CORBA- и COM-объекты; 

переиспользуемые динамически связываемые библиотеки с интерфейсами доступных функций на С, С++, Pascal;

Java- и C++-классы.

Понятие компоненты широко используется в различных предметных областях, например:

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

при разработке систем на основе эталонной семиуровневой модели ISO/OSI, адаптируемой для различных  телекоммуникационных стандартов (ISDN, ATM т.д.), понятие компоненты удобно использовать при моделирования уровней и функциональных сущностей.

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

Системы реального времени

Системы реального времени  являются одним из самых важных классов  программного обеспечения. Они определяются как системы, имеющие жесткие временные ограничения. При этом выделяются системы on-line, к которым относятся, в частности, многие бизнес-приложения например, система заказа авиабилетов, которая имеет много рабочих мест и должна быстро обрабатывать большое число запросов), и ПО для встроенных систем управления каким-либо оборудованием (embedded systems).

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

размер системы и “плотность”  взаимодействия между ее компонентами;

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

В монографии определяется область применимости методологии ROOM (Real-Time Object-Oriented Modeling). Определяются те характерные свойства системы, при наличии которых ROOM может успешно применяться:

временная зависимость (timeliness) процессов системы;

динамический характер внутренней структуры системы;

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

параллельность;

распределенность.

Обзор существующих подходов к проектированию компонентного ПО с применением расширенных конечных автоматов

В качестве основы компонентного  подхода выделяются следующие понятия:

компонента – это независимый, заменяемый, тиражируемый и переиспользуемый элемент ПО;

порт – это точка  входа в компоненту извне;

интерфейс – это описание правил взаимодействия компоненты с  внешним миром, который подключается к компоненте через порт.

Ниже рассматривается, в  каком виде в разных объектно-ориентированных  методологиях присутствуют эти понятия. Кроме того, в этих подходах выделяются также различные варианты поведенческой  модели как средства описания поведения  компонент.

Язык SDL

Компонента

Изначально SDL не был объектно-ориентированным. Программа на этом языке представляет собой последовательность вложенных  систем, блоков, процессов, являющихся различного вида контекстами (см. рис. 3).

В версии SDL 1992 года появились  объектно-ориентированные черты. Для  различных видов контекстов появились  типы. Для экземпляров типов предусмотрена  возможность группового описания. На рис. 4 определен тип блока BlockingStation и множество (100 шт.) объектов этого типа по имени bls, каждый из которых связан с блоком CenralUnit.

Для типов в SDL-92 есть наследование. Так, если в рассмотренном выше примере  тип блока BlockingStation является наследником типа блока LocalStation, то описание BlockingStation будет выглядеть способом, представленном на рис.5.

Следует отметить, что в SDL/GR нет графических способов изображения  связей между типами, а в UML они  существуют для ассоциаций и наследования. По отношению к UML SDL/GR можно считать  смесью диаграмм классов и диаграмм взаимодействий.

В SDL cуществует дополнительный, по сравнению с обычными языками программирования, способ общения между контекстами – через механизм передачи сообщений. Блоки одного уровня вложенности могут связываться друг с другом каналами, а процессы – сигнальными маршрутами. Основным средством адресации сообщений в SDL является имя процесса-получателя, а не канал. Каналы и сигнальные маршруты используются в большинстве случаев для наглядных графических спецификаций системы.

Сообщения определяются на правах переменных или методов в  контекстах и их доступность определяется стандартными правилами видимости. Кроме сообщений в контекстах можно определять переменные и некоторые другие сущности.