CC BY
101
1. Упрощен процесс установки и развертывания приложения. Компоненты .NET Framework не связаны с реестром. Поэтому установка подобных приложений сводится к копированию файлов в соответствующие каталоги и созданию ярлыков. Удаление приложений сводится к удалению файлов. Это позволяет пользователю корректно устанавливать и удалять приложения без необходимости вмешательства программиста.
2. При компиляции кода для .NET Framework генерируется не традиционный код (который состоит из процессорных команд), а код на промежуточном языке CIL. Во время выполнения приложения, CLR транслирует CIL в команды конкретного процессора. Это позволяет запускать приложение на любой машине, на которой установлена соответствующая версия .NET Framework.
3. Упрощенное повторное использование кода. Этот механизм позволяет создавать собственные классы, которые в дальнейшем можно без труда использовать при разработке других приложений
4. Автоматическое управление памятью позволяет в разы упростить управление использованием ресурсов ЭВМ и отыскивать во время выполнения программы объекты, которые больше не используются приложением и могут быть удалены.
В результате написания программы были получены навыки написания событийно-ореинтированных приложений для работы с БД, с использованием языка программирования C#. Для хранения данных была использована локальная база данных SQL Server Compact Edition. Обращение к базе данных были написаны на языке LINQ.
Литература
1. Окулов С.М. Основы программирования, Издательство: БИНОМ. Лаборатория знаний, 2010 г. ЭБС Книгофонд, http://www.knigafund.ru/books/127791
2. Нагинаев В.Н. Основы алгоритмизации и программирования на языке C++: Учебное пособие, Издательство: МИИТ, 2006 г Книгофонд http://www.knigafUnd.ru/books/8264
3. Г. С. Иванова. Объектно-ориентированное программирование. - МГТУ им. Н. Э. Баумана, 2002
4. Курс: Основы информатики и программирования. Лекция №10: Основы объектно-
ориентированного программирования. Применение ООП к разработке программных проектов. Основные концепции ООП, www.intuit.ru/department/se/oip/10
УДК 004.451.8
ПЕРСПЕКТИВЫ РАЗВИТИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ОПЕРАЦИОННЫХ СИСТЕМ
Штанюк Антон Александрович, к.т.н., доцент кафедры информационных технологий в предпринимательской деятельности Нижегородского государственного университета
им. Н.И. Лобачевского, shtan@land.ru
Введение
Использование объектно-ориентированного подхода к разработке операционных систем вызывало и вызывает дискуссии среди разработчиков [1]. Существуют области, в которых ООП широко применяется - например, графические интерфейсы пользователя, - и там у объектного подхода практически нет конкурентов. Вызвано это, на наш взгляд, огромным количеством кода, стоящим за отображением информации, а также событийным характером работы программ с GUI. Производительность интерфейсов не является главным требованием, в отличие, например, от дружественности пользователю. Операционная система работает в других условиях, и требования к производительности у неё могут перекрывать все остальные, что заставляет использовать «мультипарадигмальную смесь»
35
языков и подходов к разработке. Также немаловажную роль в этой области играют традиции, которые для GUI просто диктуют использовать ООП, а вот для ОС объектный подход всерьёз не рассматривается.
Объектно-ориентированные операционные системы (ОООС) в настоящее время -большая редкость, и зачастую представляют собой экспериментальную, лабораторную разработку. Говорить о создании действительно массовой ОООС общего назначения было бы неверно [2]. Но объектные черты у многих операционных систем всё же присутствуют.
1. Отличительные признаки ОООС
ОООС присущи следующие отличительные признаки:
1. Объектная архитектура. Основная сущность в системе - объект, и архитектура всей системы является совокупностью объектов, расположенных на разных уровнях в соответствии с иерархиями «содержать» и «являться».
2. Обмен информацией внутри системы. Обмен осуществляется в терминах посылки и приёма сообщений, которые осуществляют объекты.
3. Операции ввода/вывода при взаимодействии с устройствами также представляются в терминах объектов и посылки сообщений.
4. Минимум побочных эффектов. Объекты взаимодействуют друг с другом через сообщения, и их состояние тесно связано с поведением. В этом случае побочные эффекты запрещены.
5. Поддержка микроядерной концепции, позволяющей реализовать большинство функций ядра в виде сервисов, работающих в режиме задачи, а, следовательно, допускающих реализацию в виде автономных объектов, которыми проще управлять.
6. Распределённый характер, заключающийся в способности легко обмениваться программными объектами между различными компьютерами.
7. Основной язык разработки - C++, но возможны исключения в виде Java или даже Lisp.
Безусловно, между ОООС и обычными системами, широко распространенными в мире, существует много общего. Например, можно рассматривать unix-подобную ОС как объектную с точки зрения архитектуры, если под объектами подразумевать такие крупные компоненты как ядро, оболочки, утилиты. Да и в ядре существуют модули, драйверы, имеющие чёткий программный интерфейс взаимодействия с остальными частями системы. Создание новых процессов на основе клонирования существующих, описание взаимодействия процессов в терминах «отцы», «дети», «братья» - это имеет аналогию с концепцией наследования в традиционных ОО-программах. Всё это свидетельствует о стремлении разработчиков использовать преимущества объектного подхода к разработке ПО, но не диктует им стратегию разработки от начала до конца. В самом деле, в той же unix-системе границы между модулями ядра весьма условны, существует большое количество общих данных в пространстве ядра, а управляющие структуры процессов - это просто структуры данных, не имеющих специального объектного представления. В системе причудливо переплетаются процессы и потоки, файлы и каналы, обработчики прерываний и API-функции. Такую систему логичнее описывать как огромное здание, опутанное проводами и сетью труб, чем конгломерат взаимодействующих объектов.
2. Преимущества и недостатки ОООС
К достоинствам объектно-ориентированных ОС можно отнести:
• чёткость и прозрачность архитектуры, основанной на понятиях объекта и интерфейса;
• упрощение тестируемости в связи с разделением полномочий объектов и трассировкой сообщений;
• безопасность из-за возможности проводить более гибкую политику в отношении прав различных объектов;
• хорошая сопровождаемость благодаря более ясному исходному коду;
36
• расширяемость благодаря адаптивным интерфейсам на любом уровне системы.
К недостаткам ОООС можно отнести:
• более низкая производительность из-за наличия многих звеньев в цепи передачи сообщения от объекта к другому объекту, а также необходимости использования более абстрактных механизмов для поддержки ООП;
• существенный размер кода самой системы из-за необходимости описания интерфейсов объектов даже для самых простых действий.
3. Краткий обзор некоторых существующих ОООС
Сначала хотелось бы описать наиболее успешные версии ОООС.
BeOS и Haiku - две наиболее известные операционные системы, первая из которых появилась в середине 90-х годов, но из-за лицензионной политики не сумела «выжить» на рынке, а вторая представляет собой современную версию BeOS, написанную сообществом с нуля. Главной особенностью данных систем является активное использование языка C++ вместо С и объектно-ориентированный API. У Haiku есть большие шансы стать достаточно распространённой ОС для персональных компьютеров и её разработка в настоящее время идёт очень активно, хотя система пока только подошла к стадии вета-тестирования [3].
Genera - коммерческая операционная система, начало разработки которой относится к 1982 году. Разрабатывалась система компании Symbolic для LISP-компьютеров и писалась на языке программирования LISP. В качестве пользовательского интерфейса используется оригинальная разработка под названием Dynamic Windows, которая является полностью объектной. Современные версии системы работают поверх unix. Последняя версия появилась в 1998 году.
Athene - вышла в 2000 году. Разработчик Rocklyte Systems. Пользовательское окружение целиком состоит из объектов. Процессы могут размещать объекты в разделяемой памяти и использовать совместно. Разработка приложений под Athene подчиняется ООП-методологии. Проект закрылся в 2009 году.
Chorus - микроядерная система реального времени, которую разработала компания Sun для встраиваимых систем в 80-х годах прошлого века. Последние версии системы относятся к 1997 году и, судя по всему, исходный код системы был открыт компанией-разработчиком.
Choices - система, разработанная в университете штата Иллинойс, США. Написана на С++ и использует объекты для представления элементов ядра. Используется наследование для отделения платформонезависимых классов ядра от зависимых. Поддерживает архитектуры SPARC, x86 и ARM.
GEOS - операционная система, относящаяся к разряду легковесных с графическим интерфейсом пользователя. Создавалась как надстройка над DOS, подобно первым версиям Windows. По некоторым данным, написана на Object Assembler.
Mach - ядро операционной системы, которое разрабатывалось в качестве замены современным ядрам Unix в университете Carnegie-Mellon. Микроядерная архитектура с реализацией процесса в качестве объекта, обладающего набором системных ресурсов, а также обмен сообщений между объектами ядра, позволяет отнести Mach к важным элементам ОООС. Данный проект оказал большое влияние на архитектуру ядер многих современных ОС, среди которых GNU Hurd, NEXTSTEP, MAC OS X и ряд других.
Peace - распределённая ОС, предназначенная для работы на вычислительных кластерах с большим количеством процессоров и ядер и наиболее подходящая в области параллельных вычислений.
Spring - операционная система, разработанная компанией Sun в начале 90-х годов. Относится к числу микроядерных и оказала некоторое влияние на язык Java и ОС Solaris.
TAJ - операционная система, разработанная на С++ в Индии и работающая на архитектуре x86. Поддерживает многозадачность, многопоточность, многопользовательский режим.
37
Существуют также несколько систем, написанных на языке Java и выполняющихся на виртуальной машине (jvm). К ним относятся JavaOS, JOS, JNode и JX.
JavaOS - операционная система компании Sun, разработанная в 1996 году. Код системы написан преимущественно на языке Java и может выполняться на множестве аппаратных платформ. В системе есть графический интерфейс, основанный на библиотеке AWT.
JNode - современная операционная система, написанная на языке Java в 1995 году и развивающаяся до настоящего времени. Обладает микроядром, написанным на ассемблере, и работающей поверх него JVM.
Следует отметить тот факт, что практически все представленные в данном списке системы (кроме BeOS и Haiku) никогда не были известны широким массам пользователей и даже за стенами исследовательских лабораторий, где были разработаны. Разработка многих систем была прекращена из-за финансовых проблем или в связи с переключением на более актуальные задачи.
4. Основные концепции ООП при разработке архитектуры ОООС
В результате следования принципу инкапсуляции все системные объекты скрывают в себе ресурсы и основные абстракции для работы с ними (файл, процесс, память...), сокращая при этом количество связей за счёт отделения интерфейса от реализации.
Основным способом обмена информации в системе является передача сообщений от одних объектов к другим. Благодаря расположению объектов на различных иерархических уровнях, удаётся наиболее чётко прописать их взаимодействие при решении определённых задач.
В результате использования наследования, системные объекты используют одинаковые наборы методов соответствующих классов. Классы-наследники имеют возможность переопределять родительские методы или расширять их состав. Системные объекты, вызывая методы друг друга, передают скрытые указатели, позволяющие установить принадлежность метода. Это даёт возможность контролировать права объектов на уровне передачи сообщений. Специальный системный объект ObjectProxy управляет ссылками на системные объекты и транслирует сообщения в системе, работая при этом в привилегированном режиме процессора [4].
5. Перспективы развития
На основе анализа существующих ОООС можно наметить несколько путей их развития.
Первый путь; существование в виде полностью независимых ОС для аппаратной платформы (или платформ). Развитие по данному пути осложнено необходимостью создавать аппаратно-зависимые модули, написанные на языке ассемблера и поддерживать большой спектр современного оборудования, что является трудоёмким делом. Вряд ли такая система в обозримом будущем будет успешно конкурировать с распространёнными на рынке гибридными ОС и лучше приспособленными к аппаратным новинкам. Но можно предполагать, что в дальнейшем ОООС всё-таки получат широкое распространение благодаря своим конструктивным преимуществам.
Второй путь: существовать в виде объектно-ориентированных надстроек к имеющимся ядрам или ОС. Различные системы на основе Java иллюстрируют данное направление.
Третий путь; трансформация существующих ОС или их частей, постепенное внедрение объектного подхода в существующие решения. Одним из ярких представителей этой группы систем является Haiku, в которой реализован объектный API-интерфейс, вызывающий активный интерес [3].
Литература
1. Фрактальная ОС [Электронный ресурс]: http://tunilab.org/UniEnv/FractalOS
38
2. Википедия [Электронный ресурс]: http://en.wikipedia.org/wiki/Object-oriented operating system
3. Рассвет Haiku [Электронный ресурс]: http://habrahabr.ru/post/143176
4. Vivek Kumar Singh “Object oriented operating system”[Электронный ресурс]: http://bhu.ac.in/ComputerScience/vivek/OO-OS.ppt
УДК 004.94
ПРОФИЛЬ UML ДЛЯ ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
Гурьянов Василий Иванович, к.т.н, доцент, Филиал Санкт-Петербургского государственного экономического университета в г.Чебоксары, Россия, Чебоксары, vg2007sns@rambler.ru
Введение
В последние годы в сфере имитационного моделирования отмечается возрождение интереса к имитационному моделированию на универсальных языках программирования. Естественным представляется применение таких современных методологий разработки ПО, как, например, UP [1]. Таким образом возникает задача разработки профиля UML, который разрешит использование UML-средств для разработки имитационных моделей. Однако на этом пути появляются определенные методологические трудности.
Дело в том, что в сфере имитационного моделирования имеет место уникальная ситуация. С одной стороны, UML можно использовать как язык описания имитационной модели (подобно RUP Business Modeling), с другой - как язык описания программных систем. Избежать этой двойственности невозможно. Возникает проблема непротиворечивости обеих моделей, порождая тем самым проблему встраиваемости методологии разработки имитационных моделей в методологию UP. В работе [2] предложен проект профиля (далее - Scientific Profile или UML SP), который, на наш взгляд, решает эту проблему. Профиль был проверен на ряде задач имитационного моделирования (см. [2-11]). На данный момент существует настоятельная необходимость в формальном определении этого UML-языка. В данной работе приведена метамодель UML SP и приведена аргументация в пользу предлагаемого решения. Приведен также краткий обзор опыта построения объектных имитационных моделей на этом языке.
1. Концептуальная модель
Мы будем в основном опираться на версию UML 1.5, т.к. выразительных средств этой линейки UML для целей имитационного моделирования, по меньшей мере, на данный момент оказалось достаточно. Что касается UML 2.0, то профиль подобный UML SP может потребоваться для разработки сложных имитационных моделей, использующих современные технологии, такие как MDA.
Концептуальная модель Scientific Profile выражает две основные концепции. Предполагается, что описание объекта имитационного моделирования представлено в форме глоссария. Профиль предоставляет регулярный механизм назначения предметной семантики программным сущностям. Для этого используется механизм помеченных значений для стереотипов в виде {Concept = имя концепта}. Тем самым вводится двойственная семантика. Чтобы разграничить семантики, будем говорить о вычислительной семантике и о предметной семантике. Концепты верхнего уровня фиксируются в названиях стереотипов и определяют наиболее общие понятия, которых достаточно для описания любой ситуации исследования имитационной модели.
2. Применение UML SP
Профиль построен на метаклассах UML и может использоваться в различных методологиях ООАП, однако мы будем полагать, что используется UP.
39
