Разработанную программу можно использовать

Аннотация: Разработка простого приложения, помогающего понять структуру приложения, освоить основные операторы, привыкнуть к среде разработки.

Цель лабораторной работы:

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

Задачи лабораторной работы:

• создать новое приложение и изучить его структуру;
• настроить интерфейс приложения;
• реализовать логику приложения.

4.1 Введение

Для достижения поставленной цели в лабораторной работе создадим приложение в среде разработки Android IDE (Eclipse и ADT ), подробно рассмотрим структуру полученного проекта и разберем назначение основных его элементов.

Чтобы дальнейшие действия приобрели некоторый смысл, сформулируем задачу, которую будет решать наше приложение , назовем его «Угадай число». Суть приложения в том, что программа случайным образом «загадывает» число от 0 до 100, а пользователь должен угадать это число. При каждом вводе числа, программа сообщает пользователю результат: введенное число больше загаданного, меньше или же «Ура, победа!» число угадано.

Как Использовать Искусственный Интеллект, чтобы Разбогатеть в 2023 году

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

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

4.2 Создание приложения и изучение его структуры

Создайте новый проект в среде Android IDE (Eclipse с ADT ). Процесс создания нового проекта и описание основных настроек подробно рассмотрен в лабораторной работе к первой лекции.

В процессе создания проекта, мы назвали его ProjectN, среда разработки подготавливает необходимые папки и файлы. Полный иерархический список обязательных элементов проекта можно увидеть на вкладке Package Explorer (аналогичную информацию предоставляет вкладка Project Explorer), иерархия полученных папок и файлов для нашего проекта изображена на рис. 4.1.

увеличить изображение
Рис. 4.1. Структура проекта ProjectN

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

• папка src — содержит файлы с исходным кодом на языке Java. Именно в этой папке размещаются все классы, создаваемые в процессе разработки приложения. Сейчас в этой папке в пакете com.example.projectn размещается единственный класс MainActivity.java . Этот класс определяет главную и единственную активность в этом приложении.

Комментарий 1: Имя пакету присваивается в процессе создания приложения в поле Package Name, использовать com . example не рекомендуется, т. к. пакет с таким именем нельзя загрузить в Google Play . Часто рекомендуют использовать в качестве имени пакета название сайта программиста, записанное в обратном порядке, можно просто использовать свои имя и фамилию. Последнее слово в имени пакета формируется автоматически и совпадает с именем проекта.

Искусственный Интеллект — Как Заработать НА АВТОМАТЕ ? Готовая Схема Заработка (2023)

Комментарий 2: Имя файлу присваивается в процессе создания приложения на этапе настройки активности. Имя определяется в поле Activity Name.

Комментарий 3: Package Explorer отображает структуру папок, которая создается в каталоге, выбранном в качестве рабочего (Workspace) при запуске Eclipse. Например, рабочий каталог называется workspaceADT, в нем для нашего проекта появилась папка с именем ProjectN, в ней есть папка src, в ней com , в ней example , в ней projectn (заметьте, что название пакета распалось на три папки, каждое слово , отделенное точкой определило новую папку). И уже в папке projectn находится файл MainActivity. java и будут размещаться другие java -файлы проекта.

• папка gen — содержит java-файлы, которые не требуется изменять и лучше вообще не трогать. Эти файлы генерируются автоматически. Нас может заинтересовать файл R.java он содержит идентификаторы (ID) для всех ресурсов приложения.
• папка res — содержит структуру папок ресурсов приложения, рассмотрим некоторые из них:

• layout — в данной папке содержатся xml-файлы, которые описывают внешний вид форм и их элементов, пока там находится только activity_main.xml;
• values — содержит XML файлы, которые определяют простые значения, таких ресурсов как, строки, числа, цвета, темы, стили, которые можно использовать в данном проекте;
• menu — содержит XML файлы, которые определяют все меню приложения.

Рассмотрим файл AndroidManifest.xml — файл в формате xml , который описывает основные свойства проекта, разрешение на использование ресурсов устройства и др. Сразу после создания приложения файл AndroidManifest. xml выглядит так, как показано на рис. 4.2.

увеличить изображение
Рис. 4.2. Файл AndroidManifest.xml только созданного проекта

Рассмотрим подробно файл манифеста.

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

xmlns:android	— определяет пространство имен Android, всегда должен иметь значение: » http://schemas.android.com/apk/res/android «. Обязательный атрибут.
package	— полное имя пакета, в котором располагается приложение. Обязательный атрибут. Имя должно быть уникальным, может содержать заглавные и строчные латинские буквы, числа и символ подчеркивания. Однако начинаться должно только с буквы. Для избежания конфликтов с другими разработчиками рекомендуется использовать имя вашего сайта (если он есть) записанное в обратном порядке. В нашем случае пакет имеет имя «com.example.projectn» и наше приложение не удастся разместить в Google Play (но мы на это и не претендуем). Внимание: если Вы опубликовали свое приложение, Вы не можете менять имя пакета, т.к. имя пакета служит уникальным идентификатором для приложения и в случае его смены приложение будет рассматриваться, как совсем другое и пользователи предыдущей версии не смогут его обновить.
android:versionCode	— внутренний номер версии приложения не виден пользователю. Этот номер используется только для определения является ли одна версия более современной по сравнению с другой, больший номер показывает более позднюю версию.
android:versionNumber	— номер версии, является строкой и используется только для того, чтобы показать пользователю номер версии приложения.
android:shareUserID, android:sharedUserLabel, android:installLocation	— эти атрибуты в нашем файле манифеста не представлены, про их назначение можно почитать по ссылке: http://developer.android.com/guide/topics/manifest/manifest-element.html.

Рассмотрим элемент , который показывает совместимость приложения с версиями Android . Основные атрибуты:

android:minSdkVersion	— указывает значение минимального уровня API, необходимого для работы приложения. Система Android не позволит установить приложение, если уровень API ниже, чем уровень, указанный в этом атрибуте. Внимание: если этот атрибут не указан, система установит значение по умолчанию равным «1», которое означает, что приложение совместимо со всеми версиями Android. И в случае, если приложение не совместимо со всеми версиями, установка пройдет на любую версию Android, а во время работы приложение сломается, когда попытается обратиться к недоступным элементам API. Поэтому необходимо всегда указывать значение этого атрибута.
android:targetSdkVersion	— указывает уровень API целевой платформы Android приложения, если этот атрибут пропущен, по умолчанию принимается значение android:minSdkVersion .
android:maxSdkVersion	— указывает максимальное значение уровня API, под который разрабатывалось приложение. Если значение этого атрибута ниже, чем уровень API соответствующий версии Android, на которую устанавливается приложение, то система не позволит установить такое приложение.

Если внимательно посмотреть на файл манифеста рис. 4.2, можно заметить, что данный атрибут в нем отсутствует. На самом деле разработчикам не рекомендуются задавать значение этого атрибута. Во-первых, это значение будет препятствовать использованию приложений на новых версиях Android при их появлении, несмотря на то, что все новые версии полностью обратно-совместимы. Во-вторых, стоит иметь ввиду, что задание этого атрибута может привести к тому, что приложение будет удалено с устройства после обновления Android до более высокого уровня API .

Рассмотрим элемент , который является обязательным элементом манифеста, полностью определяет состав приложения. Представляет собой контейнер для элементов , , , (и не только), каждый из которых определяет соответствующий компонент приложения. Содержит набор атрибутов, действие которых распространяется на все компоненты приложения. Рассмотрим атрибуты элемента , представленные в манифесте на рис. 4.2:

На самом деле у элемента гораздо больше атрибутов, чем нам удалось рассмотреть, найти полный список атрибутов с описаниями можно по ссылке: http://developer.android.com/guide/topics/manifest/application-element.html.

В приложении всего одна активность , других компонентов нет, в связи с этим элемент в манифесте содержит ровно один элемент activity > и больше никаких других элементов не содержит. Рассмотрим элемент , который определяет активность . Для каждой активности обязательно необходим свой элемент в манифесте. Рассмотрим атрибуты элемента , представленные в манифесте на рис. 4.3:

На самом деле у элемента гораздо больше атрибутов, чем нам удалось рассмотреть, найти полный список атрибутов с описаниями можно по ссылке: http://developer.android.com/guide/topics/manifest/application-element.html.

В манифесте для нашего приложения элемент содержит ровно один элемент: , определяющий типы намерений, которые может принимать активность . Этот элемент содержит два элемента: и .

Первый элемент определяет действия, которые проходят в фильтр намерений, при этом должен содержать хотя бы один элемент , в противном случае ни один объект -намерение не сможет пройти через фильтр и активность невозможно будет запустить. Элемент имеет единственный атрибут android_name=»android.intent.action.MAIN» .

Второй элемент определяет имя категории в фильтре намерений. Имеет единственный атрибут android_name=»android.intent.category.LAUNCHER» .

На этом разбор манифеста приложения закончим, подробно с описанием всех элементов этого файла можно познакомиться по ссылке: http://developer.android.com/guide/topics/manifest/manifest-intro.html.

Чаще всего, при создании приложения приходится иметь дело с папками src, res/layout и res/values, т.к. там находятся основные файлы проекта.

Источник: intuit.ru

Технология разработки ПО

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

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

С учетом данного определения термин «Разработка программ» будет звучать следующим образом:

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

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

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

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

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

• Проектирование приложения.
• Реализация программного кода приложения.
• Тестирование приложения.

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

Средства проектирования приложений

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

• Анализ требований.
• Разработка архитектуры будущего программного обеспечения.
• Разработка устройств основных компонент программного обеспечения.
• Разработка макетов Пользовательских интерфейсов.

Результатом проектирования обычно является «Эскизный проект» (Software Design Document) или «Технический проект» (Software Architecture Document). Задача «Анализ требований» обычно выполняется с использованием методов системологии (анализа и синтеза) с учетом экспертного опыта проектировщика. Результатом анализа обычно является содержательная или формализованная модель процесса функционирования программы. В зависимости от сложности процесса для построения данных моделей могут быть применены различные методы и вспомогательные средства. В общем случае для описания моделей обычно применяются следующие нотации (в скобках приведены программные средства, которые могут быть использованы для получения моделей):

• BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
• Блок-схемы (Vision 2003 и многие другие).
• ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
• UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
• макеты, мат-модели и т.д.

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

Целью второй и третьей задачи из приведенного списка задач является разработка модели (описания) будущей системы, понятной для кодировщика – человека, который пишет код программы. Здесь огромное значение имеет то, какую парадигму программирования (парадигму программирования также необходимо рассматривать как средство разработки) необходимо использовать при написании программы. В качестве примера основных парадигм необходимо привести следующее:

• Функциональное программирование;
• Структурное программирование;
• Императивное программирование;
• Логическое программирование;
• Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование ).

Выбор её во многом зависит от сложившихся привычек, опыта, традиций, инструментальных средств, которыми располагает коллектив разработчиков. Иногда разрабатываемый программный продукт настолько сложен, что для решения ряда задач в разных компонентах системы используются разные парадигмы. Необходимо отметить, что выбор того или иного подхода накладывает ограничения на средства, которые будут применены на этапе реализации программного кода. Результатом решения данной задачи в зависимости от подхода могут быть (в скобках приведены программные средства, которые могут быть использованы для их получения):

• диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
• описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).

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

Средства реализации программного кода

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

• методы и методики алгоритмирования.
• языки программирования (C++,Си, Java, C#, php и многие другие);
• средства создания пользовательского интерфейса (MFC, WPF, QT, GTK+ и т.д.)
• средства управления версиями программного кода (cvs, svn, VSS).
• средства получения исполняемого кода (MS Visual Studio, gcc и многие другие).
• средства управления базами данных (Оracle, MS SQL, FireBird, MySQL и многие другие).
• отладчики (MS Visual Studio, gdb и т.д.).

Средства тестирования программ

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

• Тестирование на отказ и восстановление.
• Функциональное тестирование.
• Тестирование безопасности.
• Тестирование взаимодействия.
• Тестирование процесса установки.
• Тестирование удобства пользования.
• Конфигурационное тестирование.
• Нагрузочное тестирование.

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

• средства анализа кода, профилирования (Code Wizard – ParaSoft, Purify – Rational Softawre. Test Coverage – Semantic и т.д.);
• средства для тестирования функциональности (TEST – Parasoft, QACenter – Compuware, Borland SilkTest и т.д.);
• средства для тестирования производительности (QACenter Performance – Compuware и т.д).

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

Источник: technologiarpo.blogspot.com

Современные средства разработки приложений

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

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

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

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

Идеология разработки в ИТ

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

В частности, для продуктов фирмы Microsoft, выпущенных с начала 21 века, характерно окончание названия. Net (читается как Dot Net). Опираясь именно на эти решения, в дальнейшем будет проведено рассмотрение сущности идеологии открытого программирования.

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

То есть, в среду разработки приложений Visual Studio последних версий, вместе с языками программирования, включенных фирмой Microsoft (Visual C + +, Visual C , J . Net, Visual Basic. Net), могут добавляться любые языки программирования, компиляторы которых создаются другими фирмами -производителями.

На сегодняшний день, таких расширений среды Visual Studio сделано уже достаточно много, практически, они существуют для всех известных языков (Fortran, Cobol, Component Pascal, Oberon и др.). Открытость среды не означает полной свободы.

Все разработчики компиляторов, при введении нового языка в среду разработки, должны придерживаться установленных правил и ограничений. Главное ограничение, которое, одновременно, можно считать и достоинством, заключается в том, что все языки, которые включаются в среду разработки Visual Studio, должны использовать единый каркас — Framework.Net.

Каркас приложений

Понятие каркаса приложений — Framework Applications появляется в литературных источниках со второй половины 90-х годов прошлого столетия в описаниях применения Visual Studio, начиная с четвертой версии.

Роль каркаса приложений Visual C + + в ранних версиях Visual Studio выполняла библиотека классов MFC (Microsoft Foundation Classes). Библиотека классов MFC изначально представляла собой иерархически организованную коллекцию классов, в которую входили классы, способные создавать архитектуру новых приложений.

Выбирая тип приложения, разработчик получал нужную функциональную платформу, образовывалась и поддерживалась объектами классов каркаса. Например, когда разработчик выбирал из возможных типов приложений архитектуру «Документ-Представление», то в его приложение автоматически встраивались класс Document, ответственный за структуру документа и класс View — ответственный за его визуальное представление.

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

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

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

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

Каркас Framework.Net

В ходе эволюции каркаса происходит естественный процесс его отделения от среды разработки — Framework.Net становится надстройкой над операционной системой. В 2001 году Европейская ассоциация производителей компьютеров (ECMA) приняла компоненты каркаса в качестве стандарта.

В следствие чего, каркас Framework.Net получает возможность развиваться для применения на операционных платформах, отличных от Windows. Сегодня, каркас Framework.Net становится свободно распространяемым технологическим решением.

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

В составе каркаса Framework.Net можно выделить две основные компоненты:

• Статический — FCL (Framework Class Library) — библиотека классов каркаса.
• Динамический — CLR (Common Language Runtime) — общеязыковой среды выполнения.

Библиотека классов FCL является результатом эволюции библиотеки классов MFC, благодаря которому каркас Framework.Net стал единственной средой для различных языков программирования. Поэтому, на каком бы языке программирования не велась разработка, она использует классы одной общей библиотеки. Большинство классов библиотеки, образующих общее ядро, используются всеми языками каркаса. Таким образом достигается унификация следующих реализаций:

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

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

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

Например, тип данных, известный в языке Visual Basic как Integer, а в языке C как int, проецируется на тип данных FCL Int32. В каждом языке программирования, вместе с «родными» для языка названиями типов данных, разрешается использовать имена типов, принятыми в каркасе.

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

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

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

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

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

Например, примитивный тип Int32 непосредственно вложен в пространство имен System, и его полное имя, включающее имя пространства — System.Int32. В пространство System вложенный целый ряд других пространств имен, используемых при создании приложений. Переход к идеологии открытого программирования в каркасе Framework.Net реализован во многом благодаря его динамической компоненте — общеязычной исполнительной среде CLR.

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

В зависимости от типа проекта, РЕ-файл может иметь расширение exe, dll, mod или mdl. Несмотря на то, что РЕ-файл с расширением exe, он выполняется операционной системой не совсем так, как привычный exe-файл. При его запуске он распознается, как специальный промежуточный файл, и передается исполнительному среде для обработки.

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

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

Основу виртуальной машины составляют трансляторы JIT (Just In Time Compiler), которые и выполняют трансляцию промежуточного кода в командный код той вычислительной машины, где установлено и функционирует исполнительная среда. Microsoft в своей разработке использовал опыт виртуальной машины Java.

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

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

Метаданные. Перемещаемый исполнительный РЕ-файл является самодокументируемым файлом, т.е. содержит вместе с программным кодом метаданные, которые его описывают. Файл начинается с манифеста, включающий описание всех классов, которые в нем хранятся, их свойств, методов, всех аргументов этих методов, то есть всю необходимую для CLR информацию.

Поэтому, кроме РЕ-файла не требуется никаких дополнительных файлов и записей в реестре — вся необходимая информация берется из самого файла. ; Сборник мусора (Garbage Collector). Под сборкой мусора понимается освобождение оперативной памяти, занятой объектами, которые стали лишними и не используются в дальнейшей работе приложения.

Во многих языках программирования (классическим примером является язык C / C + +) память освобождает сам программист, в явной форме программируя команды как на создание, так и на удаление объектов. Чтобы предотвратить неизбежным ошибкам программиста при работе с памятью, удаление неиспользуемых объектов, т.е. сборка мусора, стала частью исполнительной среды.

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

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

События. В исполнительной среды существует свое видение того, что является типом каждого объекта. Для этого используется формальное описание общей системы типов CTS — Common Type System. Согласно этому описанию, каждый тип, кроме методов и свойств, может содержать еще и события.

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

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

Эти ограничения задаются набором общеязычной спецификации — CLS (Common Language Specification). Класс, удовлетворяющий спецификациям CLS, называется CLS-совместимым. Он доступен для использования в других языках, классы которых могут быть клиентами или наследниками совместного класса.

Спецификации CLS точно определяют, каким набором встроенных типов данных можно пользоваться в совместных модулях. Понятно, что эти типы должны быть общедоступны для всех языков, использующих каркас Framework.Net.

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

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

Источник: libtime.ru