Бусыгин Б.С., Коротенко Г.М., Коротенко Л.М. Введение в современную информатику

Подождите немного. Документ загружается.

170

Развитие языков программирования в направлении повышения

еффективности составления прикладных программ привёл к разделению языков

на следующие 5 уровней:

 Низкий уровень (машинно-ориентированные языки – языки

асемблера)

 Высокий уровень (процедурно-ориентированные языки: FORTRAN,

ALGOL, PL/1, Pascal). Позднее некоторые из них были доработаны до

модульно – ориентированного уровня в более поздних версиях. Сюда же

относятся языки так называемого третьего поколения (3GL) (см. главу 5).

 Уровень задачи, которая решается (проблемно-ориентированные

языки – GPS, SQL). Сюда же относятся языки четвертого поколения (4GL) (см.

главу 5)

 Объектный уровень (объектно-ориентированные (ОО) языки –

Smalltalk, С++, Delphi Object Pascal, Java, Python и т.д.).

 Компонентный уровень (компонентно-ориентированные языки –

С#, С++, Java и т.д.)

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

«тип данных» стали классы объектов (например, в языке С++, Java) или

объектные типы (язык Pascal), которые могут содержать в качестве элементов

не только данные определённого типа, но и методы их обработки (функции и

процедуры) (рис. 7.5).

Таким образом, по мере развития технологий программирования и в

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

решаемой прикладной задачи и осуществляться соответствующая интеграция

данных и программ в модулях и компонентах. По мере повышения уровня

абстракции в описании структур данных, при проектировании новых

приложений программисты все дальше отходили от фундаментальных

(базовых) встроенных типов данных (то есть символьных, целых,

действительных (реальных) и логических). Одновременно с этим, языки

программирования пополнились средствами, необходимыми для описания

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

привело к появению в программировании объектно-ориентированного подхода

Рис. 7.4. Работа программ с данными в

модульно-ориентированом стиле

Модули

Подпрограммы

и функции

Данные

171

(ООП). И это понятно, ведь и человек обычно мыслит образами и объектами.

Он знает их свойства и манипулирует ими, в соответствии с определёнными

событиями.

К понятию ООП имеет отношение целый набор следующих концепций:

 моделирование событий реального мира;

 наличие типов данных, определяемых пользователем;

 сокрытие деталей реализации;

 возможность многократного использования кода благодаря

наследованию;

 интерпретация вызовов функций на этапе использования.

Кроме того, в объектно-ориентированном подходе всегда присутствуют

три типа данных и пять операционных характеристик, которые являются

наиболее важными базовыми элементами и операциями. Типы данных

включают: объект, класс и экземпляр. Пять характеристик объектно-

ориентированной системы содержит: абстракцию (abstraction), наследование

(inheritance), инкапсуляцию (encapsulation), полиморфизм (polymorphism) и

динамическое связывание (dynamic binding). Эти элементы создают мощную

среду для разработки приложений.

Согласно ООП, объекты, которые идентичны, за исключением своих

состояний, во время выполнения программы, группируются вместе в “классы

объектов”. Так и появилось ключевое слово класс. Создание абстрактных

типов данных (классов) – это основополагающая концепция в объектно-

ориентированном программировании (рис. 7.6).

Абстрактные типы данных работают почти так же, как и встроенные

(базовые) типы данных: вы можете создавать переменные этого типа (которые

называются объектами или экземплярами, если говорить объектно-

ориентированным языком) и манипулировать этими переменными (это

Рис. 7.5. Работа объектов с данными и

между собой при ООП

Объекты (бывшие модули)

Данные, располагаемые в

объектах

Методы, располагаемые

в объектах (бывшие

процедуры)

172

называется посылкой сообщения или запросом). Вы посылаете сообщение и

объект его обрабатывает и пытается выполнить. Поэтому они могут быть

представлены как уникальные сущности в компютерной программе.

Так как класс описывает набор объектов, имеющих идентичные

характеристики (элементы данных) и черты поведения (то есть

функциональность), класс реально является типом данных, потому что число с

плавающей точкой типа Real (например, в Турбо Паскале), также имеет набор

характеристик и черт поведения. Разница состоит в том, что программист

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

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

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

добавляя спецификации новых типов данных, которые ему необходимы для

решения задачи.

Таким образом, программа позволяет адаптировать себя к языку проблемы

путём добавления любых новых типов объектов. Так что, когда Вы читаете

программный код, описывающий решение, реализованное на объектно-

ориентированном языке, то фактически читаете слова, описывающие проблему.

Это более гибкая и мощная абстракция языка, чем была в тех, что

разрабатывались ранее. Поэтому ООП позволяет Вам описать проблему в

терминах проблемы, а не в терминах компьютера, где работает решение

(программа). Каждый объект в программе выглядит, как маленький компьютер

(компонент). Он имеет состояние и может работать так, как Вы распорядитесь

(рис. 7.7). Алан Кей, автор и разработчик первого объектно-ориентированного

языка программирования SmallTalk (рис.7.8), суммирует пять основных его

характеристик.

Рис. 7.6. Объекты MyBook, являющиеся реализацией класса Book,

каждый из которых имеет своё название (Title), автора (Author),

издательство (Publisher) и год издания (Year)

Title

Author

Publisher

Year

–FrontPage 2002 для Windows

–Нолан Хестер

–«ДМК Пресс»

–2002

–VB Script и ActiveX

–Скотт Палмер

–«ПИТЕР»

–1999

Класс Book

(Книга)

Два объекта MyBook

(МояКнига)

173

Рисунок 7.8. Автор первого

ОО языка программирования

Smalltalk Аллан Кэй (позади)

и изобретатель первого

манипулятора «мышь» Дуг

Энгельбарт (Doug Engelbart)

 Всё есть объект. Следует думать об объектах, как об особых

переменных. Они сохраняют данные, но Вы можете “выполнить запрос” к

такому объекту, попросив его

самого выполнить необходимую

операцию. Теоретически Вы

можете взять любой

умозрительный компонент в

проблеме, которую Вы хотите

решить (собаку, дом, услугу и

т.д.) и представить его как объект

в вашей программе.

 Программа – это группа

объектов, которые указывают

друг другу что делать,

обмениваясь сообщениями.

Чтобы сделать запрос к объекту,

Вы “посылаете сообщение”

этому объекту. То есть, Вы

можете думать про сообщение,

как про запрос на вызов функции, которая принадлежит определенному

объекту.

 Каждый объект имеет свою

собственную память, отличную от других

объектов. Другими словами, Вы создаёте

объект нового вида, включая в

конструируемый пакет объектов, кроме

новых, уже существующие объекты (т.н.

компоненты повторного использования).

Поэтому, Вы можете построить сложные

связи, упрятывая их позади собсьвенных

простых объектов.

 Каждый объект имеет тип. Другими

словами, каждый объект представляется

экземпляром класса, где “класс” - это

синоним “типа”. Большинство важных

отличий характеристик класса состоит в том,

“Какие сообщения Вы можете ему

посылать?”

 Все объекты определённного типа

(т.е. являющиеся реализацями одного класса)

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

Так как объект типа “круг” является

объектом типа “форма”, круг гарантированно

будет принимать сообщения от формы. Это

означает, что Вы можете писать код, который общается с формой и

Рис. 7.7. Взаимодействие больших

объектов (компонентов), содержащих

внутри себя другие объекты

174

автоматически управляет всеми объектами, отвечающими описанию класса

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

Понятно, что программирование было бы очень легким делом, если бы

простое объединение объектов решало любую проблему. Сами проблемы

становятся всё масштабнее и сложнее. Должна была появиться дисциплина не

только ОО-программирования, но и ОО-проектирования. Такой дисциплиной и

должен был стать язык UML.

7.2.Моделирование сложных информационных систем

Между тем, современный рынок программного обеспечения диктует

жёсткие требования к информационным системам, которые разрабатываются.

Системы должны быть надёжными, высокопродуктивными, быть гибкими к

внесению изменений, обеспечивать возможность масштабирования и

наращивания функциональности, быть интероперабельными в сетевой среде

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

Кроме того, разработка должна вестись быстро, эффективно и с минимальными

затратами.

В связи с этим, одной из важнейших задач разработки становится

качественное проведение этапов анализа и проектирования, обеспечивающих

создание модели функционирования программной системы, которая может

заложить твердый фундамент для дальнейшей ее программной реализации с

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

сложной программной системы перед непосредственной ее реализацией

является неотъемлемой частью всего проекта, так же как чертеж является

основой для постройки большого здания. Построение модели необходимо

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

систему в целом, так и многие отдельные её функциональные части (рис. 7.9).

Таким образом, с развитием объектно-ориентированных (ОО) языков

технологий ОО программирования стали развиваться и общие объектно-

ориентированные методы разработки ПО. Действительно, бессмысленной

выглядит ситуация, когда ПО спроектировано с помощью структурного метода,

а реализовано в объектно-ориентированном стиле. Ведь главной задачей

начальных этапов разработки ПО, непосредственно предваряющих

программирование, является спецификация предметной области в терминах,

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

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

сознании специалистов предметной области (инженеров-телефонистов – при

разработки ПО для телефонной станции, инженеров-гидрогеологов – при

разработке геоинформационных систем расчёта и представления подземных

водных ресурсов, инженеров-железнодорожников – при создании систем

автоматизации железнодорожных перевозок и т.д.) на язык программистов и

программных систем) (рис. 7.10).

В 1972 году была создана первый ОО язык SmallTalk, а в 1980-м – ОО язык С++.

175

Динамическая модель

Статическая модель

Логическая модель

Физическая модель

Структура классов

Структура объектов

Архитектура модулей

Архитектура процессов

Рис. 7.9. Физическая модель сложной информационной

системы (вверху) и комплекс описывающих её объектно-

ориентированных моделей во взаимосвязи

Важным звеном в развитии ОО технологий анализа, проектирования и

разработки программных систем стало образование в 1989 году

Рис. 7.10. Автоматизация железнодорожных перевозок с

помощью геоинформационных систем (ГИС) в Австрии

176

некоммерческого консорциума «Группа Управления Объектами» (Object

Management Group – OMG

) (рис. 7.11), который объединил таких ведущих

производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и

некоторых других. Это объединение стало мощным катализатором активизации

продолжения работ по унификации методов и разработке индустриальных

стандартов в области создания интероперабельных

, неоднородных,

распределённых, объектных сред в информационных технологиях.

Принятие OMG, начиная с 1991 года, ряда версий индустриального

стандарта CORBA (Common Object Request Broker Architecture), а также

активное практическое внедрение самих CORBA-технологий, не могли не

вызвать большого интереса разработчиков и пользователей этого стандарта к

методам ОО анализа и проектирования, к осознанию необходимости выработки

стандарта языка моделирования, который должен был бы стать основой

продвижения указанных технологий. В круг задач OMG входила также

поддержка создания систем, опирающихся на архитектуру CORBA,

обеспечение интероперабельности использующих такие технологии объектно-

ориентированных инструментальных средств и интеграция накопленного

многочисленными коллективами опыта в этой области.

Вместе с тем, многообразие возникших в 80-х

годах методик и техник ОО моделирования

привело к настоящей "войне методов", развёрнутой

конкурентами и ставшей причиной того, что идеи

объектно-ориентированного подхода при

проектировании систем стали терять своих

приверженцев. Корпоративный мир ожидал

появления концепции и реализующего её языка,

способных объединить лучшие методы и

представить общую нотацию для единого

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

любой проектируемой информационной системы.

Но так, как к середине 90-х существовало уже более 50-ти разнообразных

объектно-ориентированных языков моделирования

информационных систем,

разработчики и заказчики затруднялись при выборе метода проектирования ИС,

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

нотацию. В то же время, в число передовых вырвались улучшенные версии

некоторых конкурирующих методологий, среди которых особенно выделялись

Образованная в апреле 1989 года одиннадцатью крупными компаниями, Object Management Group™ (OMG™)

уже в 2003 году объединяла более чем 800 организаций-членов. В рамках деятельности корпорации

разрабатываются коммерчески перспективные и независимые от производителей спецификации для

софтверной индустрии. OMG™ продвигает Архитектуру, Ведомую Моделью (Model Driven Architecture ™ ) в

качестве «Архитектуры Выбора для Связанного (коммуникациями) Мира» ("Architecture of Choice for a

Connected World" ™) на базе разрабатываемых ею стандартных всемирно известных спецификаций: CORBA®,

CORBA/IIOP™, UML™, XMI™, MOF™, Object Services, Internet Facilities и Domain Interface.

Интероперабельность – взаимная возможность/способность информационных систем или компьютеров

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

функциональными блоками таким образом, чтобы пользователь при этом практически ничего не должен был

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

Рис. 7.11. Логотип

организации

OMG

177

техника Booch'90 (автор Гради Буч (Grady Booch)) (рис. 7.12), объектно-

ориентированная методология OMT (Object Modeling Technique) (автор Джим

Рамбо (Jim Rumbaugh)) (рис. 7.13) и ОО подход Fusion.

Эти и некоторые другие методы начали

смешивать техники друг друга, в результате чего

появилось несколько широко известных методологий:

OOSE (Object Oriented System Engineering), OMT-2 и

Booch'93. Но, в целом, каждый из перечисленных

методов обладал своей спецификой и оставался

обособленным от других, при определенной

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

каждого из существующих методов можно выразить

следующим образом.

OOSE представлял собой UseCase-

ориентированный подход, который обеспечивал

прекрасные решения в области бизнес-инжиниринга

а также при анализе требований к системам. OMT-2

хорошо зарекомендовал себя на стадии анализа в системах, где решающую

роль играла модель хранения данных. Техника Booch'93 была полезна на стадии

проектирования и играла большую роль при построении систем со сложными

алгоритмами функционирования.

В результате серии переговоров и содействия

OMG было решено начать разработку

Унифицированного Языка Моделирования UML (Unified

Modeling Language) как унификацию двух методов

(Booch'93 и OMT). При поддержке большой

софтверной фирмы Rational Software Corporation в

октябре 1994 года работа была начата Гради Бучем

(Grady Booch) и Джимом Рамбо (Jim Rumbaugh).

Первая версия Унифицированного Метода (Unified

Method 0.8) появилась в октябре 1995 года, после чего

к работе присоединился Айвар Якобсон (Ivar Jacobson)

(рис. 7.14), который включил в общий процесс

унификации идеи своего метода OOSE. Таким образом,

на первом концептуальном этапе UML имел трёх

авторов: Буча, Рамбо и Якобсона, каждый из которых,

был идеологом свого собственного ОО метода визуального моделирования. В

октябре 1996 года была выпущена редакция UML 0.91, в которой нашли

отображение многочисленные предложения, которые "три друга (three amigos)"

получили в течение 1996 года. Катализатором объединения усилий по

унификации UML стал выпуск консорциумом OMG "запроса на предложения"

Бизнес-инжиниринг – деятельность, направленная на проектирование и реализацию бизнес-приложений, т.е.

программных средств для решения деловых и экономических задач.

Рис. 7.12.

Гради Буч

Рис. 7.13.

Джим Рамбо

178

для UML (RFP - Request for Proposal), так как выпуск RFP является первым

щагом процедуры принятия OMG того или иного стандарта.

Посля этого Rational Software под своей эгидой

объединила специалистов в организацию "Консорциум

UML партнёров" ("UML Partners consortium") для

подготовки формального определения UML 1.0 в

качестве единого мирового стандарта. В работе

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

известных компаний как: DEC, Hewlett-Packard, Corp,

IBM, ICON Computing, MCI Systemhouse, Microsoft,

Oracle, Rational Software, TI, Unisys и др.

Каждый из партнеров OMG внёс свой весомый

вклад в разработку общего проекта. Hewlett-Packard,

например, обеспечивала связь между моделями UML и

концепцией ″повторного использования″, а IBM

разрабатывала язык OCL (Object Constraint Language –

Язык Объектных Ограничений ), описывающий семантику языка UML.

Корпорация Microsoft розвивала концепцию компонентного программирования

в рамках модели (СОМ – Component Object Model) и использования моделей и

артефактов UML в репозитории

моделей, приложений и их взаимосвязей (рис.

7.15).

Следует отметить, что впервые программный продукт Microsoft Repository,

основанный на технологиях СОМ начал распространяться в составе Microsoft

Visual Basic 5.0. Только до 2000-го года было продано более 700 000 его копий

Репозиторий – хранилище метаинформации (описательной информации) о разрабатываемых приложениях,

компонентах, хранилищах данных, базах данных и т.д. Содержит также, модели процессов, происходящих в

системе, модели данных, используемых системой и объектную модель с соответствующим описанием каждой

из компонент. Как правило, является специализированным крупным программным продуктом или частью

другого ПО.

Рис. 7.14.

Айвар Якобсон

Рис. 7.15. Модель представления репозитория корпорации Microsoft

Общие форматы

API

Согласованные

описания

Модель

Описываемые

компоненты

Хранилище

Программная

система

Программная

система

Объекты

Зависимости

ИНТЕРФЕЙСЫ

ОТКРЫТАЯ ИНФОРМАЦИОННАЯ

МОДЕЛЬ

179

и более 65-и компаний разработали приложения, которые использовали

Microsoft Repository.

Oracle расширила рамки UML для моделирования бизнес-моделей в базах

данных. Общий список соисполнителей оказался достаточно обширным, так

как каждая компания в работе решала свои конкретные задачи, но при этом

согласовывая их с общим направлением работ. С учётом усилий всех

официальных участников, в январе 1997года, OMG утвердил вариант UML 1.0,

а после детального рассмотрения и учёта всех отзывов представителей

общественности – вариант UML 1.1.

Именно этот вариант UML 1.1 в ноябре 1997 года был утверждён как

стандарт ИТ отрасли.

Тогда же, OMG принял UML, как главную спецификацию для реализации

представления OMA (Object Modeling Architecture – Архитектуры

Моделирования Объектов).

"Предоставляя разработчикам,

которые работают с любыми ОО и

другими языками программирования

((рис.7.16) и на любых платформах,

общий язык моделирования, для

построения распределённых (и

бизнес) приложений, в

информационных системах, этот

подход должен вносить

необходимую согласованность в

развитие сложной дисциплины

реализации программных

приложений" (так было объявлено

Ричардом Соли, председателем и

исполнительным директором

OMG).

Он также заявил, что UML не

является чей либо собственностью,

он открыт для всех. Хотя UML и

является строго определенным во

всех отношениях языком, он не

ставит барьеров на пути развития

средств моделирования. Язык UML

может быть расширен без

переопределения своего ядра.

Предусматривается использование

UML в качестве основы для создания программных средств визуального

моделирования информационных систем с дальнейшей имитацией их работы в

этой среде.

4GL, 4th Dimension, ABAP/4, ActiveX, Ada, adb, ALGOL,

Apl, ASM, ASN.1, ASP (Active Server Pages), Assembler,

ATL (Class Library), awk, AWT Library, bash, Basic,

Bourne-Shell, C, C++, CA-EARL, CA-SORT, Centura Team

Developer, CFE, CGI, Chill, CL/400, Clarion, Clipper,

CLIST, CLOS, CLP, Cobol, CORBA IDL, C-Shell, CSP, DCL,

DEC C, Delphi, Delta, Designer/2000, Developer/2000,

DeveloperStudio, DHTML, DirectX, Drive (Siemens), Easy

for Turbo Databank, Easytrieve Plus, Eiffel, Emacs,

ESQL/C, EXEC, FOCUS, Forth, Fortran, Foxpro, GINO-F,

GNU-make, GRIT, HASKELL, HP Basic, HP PCL, HP VEE,

HPGL, HPSG, HTML, HyperTalk, ILE/400, Imake, IMSL,

Informix 4GL, Informix ESQL/C, Java, JavaScript, JCL,

JSP (JavaServerPages), KBV, Korn-Shell, Ksh, K-Shell,

LabView, Libraries, Lingo, LISP, Lotus Notes Script, M4,

Macro Programing, MAGUS, make, Make-Maker, Mantis,

Maschinensprachen, Mbed, MFC (Class Library), ML,

Modula-

2, Motif, MPGS, Mumps, Natural, Nexpert,

Oberon, Objective, Object-PAL, Occam, OCL, OjectView,

Open-GL, Optima++, OQL, Oracle Forms, Oracle Reports,

Oracle SQL Plus, OWL (Class Library), Paisy, Pascal, Perl,

PFC, Phigs, PHP, PIC, PL/1, PL/SQL, PL/Z, PLDS, PLM,

Power++, PowerBasic, PowerBuilder, PowerHouse

Cognos, PROGRESS-4GL, Prolog, Psion OPL, Python, QMF,

Qt, RAMIS II (4GL), Rational Rose, rcs, ReXX, RPG, SAL,

SAPIENS, SAS, sccs, Scheme, Script Languages, S-

Designor, SDL, sed, SESAM, sh, Shell, Simula, Simula67,

Siron, Smalltalk, SmartWare, SML, Softedit, S-Plus, SPS,

SQL/Windows, STEP-

5 (Siemens SPS), STL (Class

Library

), Superbase unter Windows, Swing, System

Builder Plus, TAL, Tcl/Tk, tclsh/wish, tcsh, Tex/LaTeX,

Textedit, TK-Library, ToolBook (OpenScript), tools.h++

(Class Library), UIL, UNIFACE, UNIX Shells, UTM, Visual

Basic, (VBA) Visual Basic for Applications (Excel, Access,

и т.д.), VBScript, vi, Visual Age, Visual C++, Visual Cafe,

Visual J++, Visual Objects, Visual SourceSafe, Vocal,

VRML, Windows API, WSH (Windows Scripting Host),

xedit, XML, yacc/lex, zApp (Class Library), ZINC

Рис. 7.16. Известные современные

языки и концепции

программировання