Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Темы 2.3.-2.4. Выбор и обоснование языка программирования. Использование библиотек программ, встроенные функции

Для создания моделей анализа и проектирования объектно-ориентированных программных систем используют языки визуального моделирования. Появившись сравнительно недавно, в период с 1989 по 1997 год, эти языки уже имеют представительную историю развития.

В настоящее время различают три поколения языков визуального моделирования. И если первое поколение образовали 10 языков, то численность второго поколения уже превысила 50 языков. Среди наиболее популярных языков 2-го поколения можно выделить: язык Буча (G. Booch), язык Рамбо (J. Rumbaugh), язык Джекобсона (I. Jacobson), язык Коада-Йордона (Coad-Yourdon), язык Шлеера-Меллора (Shlaer-Mellor) и т. д [41], [64], [69]. Каждый язык вводил свои выразительные средства, ориентировался на собственный синтаксис и семантику, иными словами — претендовал на роль единственного и неповторимого языка. В результате разработчики (и пользователи этих языков) перестали понимать друг друга. Возникла острая необходимость унификации языков.

Идея унификации привела к появлению языков 3-го поколения. В качестве стандартного языка третьего поколения был принят Unified Modeling Language (UML), создававшийся в 1994-1997 годах (основные разработчики — три «amigos» Г. Буч, Дж. Рамбо, И. Джекобсон). В настоящее время разработана версия UML 1.4, которая описывается в данном учебнике [53]. Данная глава посвящена определению базовых понятий языка UML.

Унифицированный язык моделирования

UML — стандартный язык для написания моделей анализа, проектирования и реализации объектно-ориентированных программных систем [23], [53], [67].

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

UML — это не визуальный язык программирования, но его модели прямо транслируются в текст на языках программирования (Java, C++, Visual Basic, Ada 95, Object Pascal) и даже в таблицы для реляционной БД.

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

Предметы — это абстракции, которые являются основными элементами в модели, отношения связывают эти предметы, диаграммы группируют коллекции предметов.

Предметы в UML

В UML имеются четыре разновидности предметов:

q структурные предметы;

q предметы поведения;

q группирующие предметы;

q поясняющие предметы.

Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для написания моделей.

Структурные предметы являются существительными в UML-моделях. Они представляют статические части модели — понятийные или физические элементы. Перечислим восемь разновидностей структурных предметов.

1. Класс — описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантику (смысл). Класс реализует один или несколько интерфейсов. Как показано на рис. 10.1, графически класс отображается в виде прямоугольника, обычно включающего секции с именем, свойствами (атрибутами) и операциями.

Рис. 10.1. Классы

2. Интерфейс — набор операций, которые определяют услуги класса или компонента. Интерфейс описывает поведение элемента, видимое извне. Интерфейс может представлять полные услуги класса или компонента или часть таких услуг. Интерфейс определяет набор спецификаций операций (их сигнатуры), а не набор реализаций операций. Графически интерфейс изображается в виде кружка с именем, как показано на рис. 10.2. Имя интерфейса обычно начинается с буквы «I». Интерфейс редко показывают самостоятельно. Обычно его присоединяют к классу или компоненту, который реализует интерфейс.

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

Рис. 10.3. Кооперации

4. Актер — набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами Use Case). Каждая роль требует от системы определенного поведения. Как показано на рис. 10.4, актер изображается как проволочный человечек с именем.

Рис. 10.4. Актеры

5. Элемент Use Case (Прецедент) — описание последовательности действий (или нескольких последовательностей), выполняемых системой в интересах отдельного актера и производящих видимый для актера результат. В модели элемент Use Case применяется для структурирования предметов поведения. Элемент Use Case реализуется кооперацией. Как показано на рис. 10.5, элемент Use Case изображается как эллипс, в который вписывается его имя.

Рис. 10.5. Элементы Use Case

6. Активный класс — класс, чьи объекты имеют один или несколько процессов (или потоков) и поэтому могут инициировать управляющую деятельность. Активный класс похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов. Как показано на рис. 10.6, активный класс изображается как утолщенный прямоугольник, обычно включающий имя, свойства (атрибуты) и операции.

Рис. 10.6. Активные классы

7. Компонент — физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов. В систему включаются как компоненты, являющиеся результатами процесса разработки (файлы исходного кода), так и различные разновидности используемых компонентов (СОМ+-компоненты, Java Beans). Обычно компонент — это физическая упаковка различных логических элементов (классов, интерфейсов и сотрудничеств). Как показано на рис. 10.7, компонент изображается как прямоугольник с вкладками, обычно включающий имя.

Рис. 10.7. Компоненты

8. Узел — физический элемент, который существует в период работы системы и представляет ресурс, обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Как показано на рис. 10.8, узел изображается как куб с именем.

Рис. 10.8. Узлы

Предметы поведения — динамические части UML-моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Существует две основные разновидности предметов поведения.

1. Взаимодействие — поведение, заключающее в себе набор сообщений, которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции. Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами). Как показано на рис. 10.9, сообщение изображается в виде направленной линии с именем ее операции.

Рис. 10.9. Сообщения

2. Конечный автомат — поведение, которое определяет последовательность состояний объекта или взаимодействия, выполняемые в ходе его существования в ответ на события (и с учетом обязанностей по этим событиям). С помощью конечного автомата может определяться поведение индивидуального класса или кооперации классов. Элементами конечного автомата являются состояния, переходы (от состояния к состоянию), события (предметы, вызывающие переходы) и действия (реакции на переход). Как показано на рис. 10.10, состояние изображается как закругленный прямоугольник, обычно включающий его имя и его подсостояния (если они есть).

Рис. 10.10. Состояния

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

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

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

Рис. 10.11. Пакеты

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

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

Рис. 10.12. Примечания

 

Отношения в UML

В UML имеются четыре разновидности отношений:

1) зависимость;

2) ассоциация;

3) обобщение;

4) реализация.

Эти отношения являются базовыми строительными блоками отношений. Они используются при написании моделей.

1. Зависимость — семантическое отношение между двумя предметами, в котором изменение в одном предмете (независимом предмете) может влиять на семантику другого предмета (зависимого предмета). Как показано на рис. 10.13, зависимость изображается в виде пунктирной линии, возможно направленной на независимый предмет и иногда имеющей метку.

Рис. 10.13. Зависимости

2. Ассоциация — структурное отношение, которое описывает набор связей, являющихся соединением между объектами. Агрегация — это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями. Как показано на рис. 10.14, ассоциация изображается в виде сплошной линии, возможно направленной, иногда имеющей метку и часто включающей другие «украшения», такие как мощность и имена ролей.

Рис. 10.14. Ассоциации

3. Обобщение — отношение специализации/обобщения, в котором объекты специализированного элемента (потомка, ребенка) могут заменять объекты обобщенного элемента (предка, родителя). Иначе говоря, потомок разделяет структуру и поведение родителя. Как показано на рис. 10.15, обобщение изображается в виде сплошной стрелки с полым наконечником, указывающим на родителя.

Рис. 10.15. Обобщения

4. Реализация — семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их. Как показано на рис. 10.16, реализация изображается как нечто среднее между обобщением и зависимостью.

Рис. 10.16. Реализации

 

Диаграммы в UML

Диаграмма — графическое представление множества элементов, наиболее часто изображается как связный граф из вершин (предметов) и дуг (отношений). Диаграммы рисуются для визуализации системы с разных точек зрения, затем они отображаются в систему. Обычно диаграмма дает неполное представление элементов, которые составляют систему. Хотя один и тот же элемент может появляться во всех диаграммах, на практике он появляется только в некоторых диаграммах. Теоретически диаграмма может содержать любую комбинацию предметов и отношений, на практике ограничиваются малым количеством комбинаций, которые соответствуют пяти представлениям архитектуры ПС. По этой причине UML включает девять видов диаграмм:

1) диаграммы классов;

2) диаграммы объектов;

3) диаграммы Use Case (диаграммы прецедентов);

4) диаграммы последовательности;

5) диаграммы сотрудничества (кооперации);

6) диаграммы схем состояний;

7) диаграммы деятельности;

8) компонентные диаграммы;

9) диаграммы размещения (развертывания).

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

Диаграмма объектов показывает набор объектов и их отношения. Диаграмма объектов представляет статический «моментальный снимок» с экземпляров предметов, которые находятся в диаграммах классов. Как и диаграммы классов, эти диаграммы обеспечивают статическое проектное представление или статическое представление процессов системы (но с точки зрения реальных или фототипичных случаев).

Диаграмма Use Case (диаграмма прецедентов) показывает набор элементов Use Case, актеров и их отношений. С помощью диаграмм Use Case для системы создается статическое представление Use Case. Эти диаграммы особенно важны при организации и моделировании поведения системы, задании требований заказчика к системе.

Диаграммы последовательности и диаграммы сотрудничества — это разновидности диаграмм взаимодействия.

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

Диаграмма последовательности — это диаграмма взаимодействия, которая выделяет упорядочение сообщений по времени.

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

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

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

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

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

Механизмы расширения в UML

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

q ограничения;

q теговые величины;

q стереотипы.

Ограничение (constraint) расширяет семантику строительного UML-блока, позволяя добавить новые правила или модифицировать существующие. Ограничение показывают как текстовую строку, заключенную в фигурные скобки {}. Например, на рис. 10.17 введено простое ограничение на свойство сумма класса Сессия Банкомата — его значение должно быть кратно 20. Кроме того, здесь показано ограничение на два элемента (две ассоциации), оно располагается возле пунктирной линии, соединяющей элементы, и имеет следующий смысл — владельцем конкретного счета не может быть и организация, и персона.

Рис. 10.17. Ограничения

Теговая величина (tagged value) расширяет характеристики строительного UML-блока, позволяя создать новую информацию в спецификации конкретного элемента. Теговую величину показывают как строку в фигурных скобках {}. Строка имеет вид

{имя теговой величины = значение}.

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

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

Рис. 10.18. Расширение класса

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

Примеры элементов со стереотипами приведены на рис. 10.19. Стереотип «exception» говорит о том, что класс ПотеряЗначимости теперь рассматривается как специальный класс, которому, положим, разрешается только генерация и обработка сигналов исключений. Особые возможности метакласса получил класс ЭлементМодели. Кроме того, здесь показано применение стереотипа «call» к отношению зависимости (у него появился новый смысл).

Рис. 10.19. Стереотипы

 

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

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

Существующие на сегодняшний день языки программирования можно выделить в следующие группы [1, 56]:

• универсальные языки высокого уровня;

• специализированные языки разработчика программного обеспечения;

• специализированные языки пользователя;

• языки низкого уровня.

В группе универсальных языков высокого уровня безусловным лидером на сегодня является язык C++. Действительно, он имеет ряд достоинств:

• масштабируемость. На языке C++ разрабатывают программы для самых различных платформ и систем;

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

• C++ имеет мощный препроцессор, унаследованный от С, но, как и любой другой мощный инструмент, требует осторожного использования;

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

При этом язык C++ обладает рядом существенных недостатков:

• подключение интерфейса внешнего модуля через препроцессорную вставку заголовочного файла (#include) серьезно замедляет компиляцию при подключении большого количества модулей;

• недостаток информации о типах данных во время компиляции;

• сложность для изучения и компиляции;

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

Для C++ существует большое количество библиотек классов, поддерживающих создание пользовательского интерфейса, клиент-серверных приложений, работу с базами данных и т. д., поэтому пока альтернативы C++ нет [40].

Для второстепенных проектов иногда используется Visual Basic.

Язык Java рассматривался как альтернатива Basic, но из-за отсутствия визуального средства разработки форм он пока остается малопригодным.

Современный Object Pascal, как и Pascal, предложенный Н. Виртом в середине 70-х годов XX в., остается наиболее привлекательным для обучения основам программирования в силу своей простоты, структурированности и обнаружения компилятором большого количества не только синтаксических, но и семантических ошибок.

В нынешнее время в отличие от 60-х годов XX в. языки программирования создаются крайне редко. За последние 15 лет можно отметить лишь две новинки, получившие широкое распространение — это Java (Sun Microsystems, 1995 г.), ставший популярным во многом благодаря технологии его использования в Интернете и появления такого понятия, как виртуальная Java-машина, и С# (Microsoft, 2000 г.), созданный на основе C++.

Создателем языка является сотрудник Microsoft Андреас Хейлсберг. Он стал известным в мире программистов задолго до того, как пришел в Microsoft. Хейлсберг входил в число ведущих разработчиков одной из самых популярных сред разработки — Delphi. В Microsoft он участвовал в создании версии Java — J++, так что опыта в написании языков и сред программирования ему не занимать. Как отмечал сам Андреас Хейлсберг, С# создавался как язык компонентного программирования, и в этом одно из главных достоинств языка, направленное на возможность повторного использования созданных компонентов.

Другие достоинства языка С#:

• сохраняет лучшие черты популярных языков программирования C/C++, на основе которых он создан. В связи с этим облегчается переход программистов от C++ к С#;

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

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

• реализует возможности наследования и универсализации;

• учитывает все возможности Framework.Net, так как С# создавался параллельно с данной средой;

• благодаря каркасу Framework.Net, ставшему надстройкой над операционной системой, программисты С# получают те же преимущества работы с виртуальной машиной, что и программисты Java. Эффективность кода даже повышается, поскольку исполнительная среда CLR представляет собой компилятор промежуточного языка, в то время как виртуальная Java-машина является интерпретатором байт-кода;

• мощная библиотека каркаса поддерживает удобство построения различных типов приложений на С#, позволяя легко строить Web-службы, другие виды компонентов, достаточно просто сохранять и получать информацию из базы данных и других хранилищ данных;

• является источником надежного и эффективного кода.

Кроме вышеописанных языков к группе универсальных принадлежат также Modula, Ada, COBOL, FORTRAN и некоторые другие. Каждый из вышеописанных языков имеет свои особенности и, соответственно, свою область применения. В настоящее время универсальные языки программирования применяются в самых различных областях человеческой деятельности, таких как:

• научные вычисления (языки C++, FORTRAN, Java);

• системное программирование (языки C++, Java);

• обработка информации (языки C++, COBOL, Java);

• искусственный интеллект (LISP, Prolog);

• издательская деятельность (Postscript, TeX);

• удаленная обработка информации (Perl, PHP, Java, C++);

• описание документов (HTML, XML).

С течением времени одни языки развивались, приобретали новые черты и остались востребованными, другие утратили свою актуальность и сегодня представляют в лучшем случае чисто теоретический интерес (Focal, PL/1 и др.). В значительной степени это связано с такими факторами:

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

• удобство сопровождения и тестирования программ;

• стоимость разработки с применением конкретного языка программирования;

• четкость и ортогональность конструкций языка;

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

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

• языки баз данных;

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

• языки создания систем искусственного интеллекта и т. д.

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

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

В настоящее время языки типа ассемблера обычно используют:

• при написании сравнительно простых программ, для обращения к техническим средствам, например драйверов;

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

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

 

Выбор среды программирования

Интегрированной средой разработки программного обеспечения называют систему программных средств, используемую программистами для разработки программного обеспечения [1, 56].

Обычно среда разработки включает в себя

- текстовый редактор,

- компилятор и/или интерпретатор,

- компоновщик,

- отладчик,

- справочную систему.

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

Многие современные среды разработки также включают

- инспектор объектов,

- браузер классов

- диаграмму иерархии классов,

которые используются для объектно-ориентированной разработки ПО.

Обычно среда разработки предназначается для одного определенного языка программирования, как, например, Visual Basic или Delphi, но существуют среды разработки, предназначенные для нескольких языков, такие как Eclipse или Microsoft Visual Studio.

Примеры сред разработки — Turbo Pascal, Borland C++, GNU toolchain, DrPython.

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

Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др.

Большую популярность в наши дни получила технология.NET Framework, предложенная фирмой Microsoft в качестве платформы для создания как обычных программ, так и веб-приложений. Основным преимуществом.NET является совместимость различных служб, написанных на разных языках.

Например, служба, написанная на C++ для.NET, может обратиться к методу класса из библиотеки, написанной на Delphi; на С# можно написать класс, наследующий от класса, написанного на Visual Basic.NET, а исключение, выброшенное методом, написанным на С#, может быть поймано и обработано в Delphi.

Так же как и в случае с выбором языка программирования, выбор среды программирования определяется характером проекта, привычками и навыками разработчика, веяниями времени, требованиями заказчика и просто общественным мнением: «Все подобные разработки должны выполняться в среде...»

 

<== предыдущая лекция | следующая лекция ==>
Тема 2.2. Стиль программирования | Темы 2.5.-2.6. Структурное программирование. Структурирование. Методы структурирования программ
Поделиться с друзьями:


Дата добавления: 2014-01-07; Просмотров: 1214; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.142 сек.