CC BY
70
Предполагается, что генератор должен выполнять следующие действия:
1. Генерация таблиц БД.
2. Генерация представлений БД.
3. Генерация хранимых процедур БД или программных модулей, написанных на языках программирования, выполнение которых поддерживает ядро системы.
4. Генерация шаблонов отчётов.
5. Генерация тестовых данных.
Так каждый объект системы (<Object>) транслируется в таблицу базы данных. Связь между объектам предметной области в зависимости от своей мощности переводится в набор внешних ключей или, в случае со связью «многие ко многим», в таблицу, хранящую пары внешних ключей связываемых объектов. Группам свойств (<Properties>), объединяющих сходные характеристики объекта вместе, ставятся в соответствие представления в БД.
Выполняемые объектами операции могут быть представлены в виде хранимых процедур и функций БД или программных модулей, написанных на языках программирования, выполнение которых поддерживает ядро системы (например, JavaScript, Java, Ruby, Groovy и др.). Кроме этого, после этапа создания структуры хранения данных таблицы БД могут быть заполнены тестовыми данными, что позволит получить прототип работающей подсистемы, выполнить её тестирование, а также обнаружить ошибки и неточности в описании модели. Следует отметить тот факт, что созданное XML-представление какой-либо информационной подсистемы используется не только для генерации структуры БД и скриптов для серверной части ИС, но и для формирования интерфейса клиентской части веб-приложения. Если моделируется какая-либо картотечная или учётная информационная система, то чаще всего уже после создания модели и автоматической генерации приложения можно получить почти полностью готовый к работе комплекс.
Литература
1. Григоров А.С. Объектно-ориентированный подход к созданию типовых информационных систем для муниципальных образований. Объектные системы - 2010: Материалы I Международной научно-практической конференции. Россия, Ростов-на-Дону, 10-12 мая 2010 г / под общ.ред. П.П. Олейника. - Ростов-на-Дону, 2010. - 64-68 с.
2. Сергей Дмитриев. Языково-ориентированное программирование,
http://www.rsdn.ru/article/philosophy/LOP.xml
3. Dodds L. Code generation using XSLT, http://www- 106.ibm.com/developerworks/edu/x-dw-codexslt-i.html
УДК 519.682.4, 371.32
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД И ОБЪЕКТНООРИЕНТИРОВАННЫЕ ЯЗЫКИ КАК ПРЕДМЕТ ИЗУЧЕНИЯ1
Штанюк Антон Александрович, к.т.н., доцент, ГОУ ВПО «Нижегородский коммерческий
институт», shtan@land.ru
Существует ряд проблем, связанных с преподаванием объектно-ориентированного подхода (ООП) к разработке программного обеспечения, а также к преподаванию самих объектно-ориентированных языков (ООЯП) в высших учебных заведениях. Необходимо отметить, что рассматриваемый вопрос довольно популярен [1,2] и в этом деле пока рано ставить точку. Цель данной работы - показать, что раздельное преподавание ООП и ООЯП
1 Лауреат номинации "Лучший доклад о методах преподавания объектных технологий в ВУЗе". Автор награждается правом бесплатной публикации одного доклада по данной тематике на следующей конференции
59
не только возможно, но даже даёт некоторые преимущества в рамках подготовки специалистов по направлению «Информационные системы».
Хотелось бы провести чёткую границу между объектно-ориентированным подходом и объектно-ориентированным языком программирования. Подход традиционно определяется как парадигма и она первична, а язык - это инструмент поддержки парадигмы. Для того, чтобы понять ООП, необходимо прежде всего развить способности в области объектной декомпозиции, то есть умение представить задачу как набор взаимодействующих объектов. Это умение, по-видимому, не всегда поддаётся формализации и часто определяется человеческой способностью оперировать абстракциями. Язык программирования, наоборот, есть формализованное средство для выражения абстракций и их отношений, так что его изучение может строится на чётких формальных правилах. Следовательно, изучение принципов ООП и языков поддержки ООП может строиться по-разному.
Нужно признать, что языки, которые так или иначе ассоциируют с ООП, обладают разной степенью поддержки объектного подхода и могут быть группированы так:
1. объектные (например, Smalltalk, Simula-67, Java, C#). Обладают наибольшей поддержкой ООП, и их использование подразумевает строгое следование объектной парадигме;
2. объектно-ориентированные (например, C++, Object Pascal, Objective-C). Языки, для которых ООП является приоритетным направлением, но не единственным. Здесь уместно говорить о поддержке нескольких парадигм;
3. смешанные с поддержкой ООП на уровне расширений (например, Common Lisp с CLOS, Clojure). Объектный подход не утверждён стандартом языка и реализуется через библиотеки и расширения.
С точки зрения преподавателя, каждая группа языков обладает своими преимуществами для учебного процесса. Объектный Smalltalk наилучшим образом иллюстрирует объектную парадигму, но имеет ограниченное применение из-за проблем с быстродействием. Язык Java обладает достаточно тяжеловесными синтаксическими конструкциями и ориентирован, прежде всего, на кроссплатформенные приложения. Существует известная работа [4], в которой автор настроен скептически относительно пользы обучения на Java. Язык C# - весьма перспективный язык, во многих отношениях копирующий Java, но ориентация на продукты Microsoft и нестабильная библиотека объектов затрудняют его распространение.
Объектно-ориентированные языки и, прежде всего, С++, наиболее популярны в университетской среде нашей страны. Основным недостатком С++ можно считать его объём и обилие библиотечных средств. Изучить все аспекты С++ в рамках семестрового курса не представляется возможным. К тому же, C++ (как и С) не рекомендуется в качестве языка для обучения программированию из-за довольно большого порога вхождения [5].
Языки третьей группы, имеющие корни в Лисп-традиции, обладают поддержками множества парадигм и могут считаться наиболее перспективными для изучения в университетах, однако низкая востребованность лисп-специалистов на рынке труда не стимулирует интереса к этим языкам.
В современных курсах, построенных на изучении C++, традиционно начинают с объектной парадигмы, опираясь на популярные учебники [6], а затем приступают к систематическому изучению языка. Далее студенты бывают просто «раздавлены» обилием возможностей C++, огромным количеством терминов и в результате «лес оказывается скрыт за деревьями», то есть объектная парадигма не только не проясняется, но и предстаёт сложной и запутанной.
Достаточно давно заговорили о кризисе объектной парадигмы [3]. Разумеется, у неё всегда были и будут как влиятельные противники, так и влиятельные сторонники. Одной из крупнейших проблем является иллюстрация эффективности ООП при решении сложных задач в рамках курса, где невозможно такие примеры создать. Поэтому приходится искусственно усложнять простые задачи, или сводить их к иллюстрации простых систем
60
моделирования, вроде экологического равновесия в аквариуме. А с реальными задачами будущий специалист столкнется только после окончания учебы, устроившись на работу в серьёзную компанию.
Возникает вопрос: а можно ли начинать преподавание с языка, не вдаваясь в глубину объектной парадигмы, а потом, после усвоения технических средств и приёмов, приступать к ООП? Хотелось бы высказать несколько доводов в защиту такого подхода.
При трудоустройстве в компании по разработке ПО требуется, как правило, хорошо ориентироваться в языке, поскольку работодатель намерен сразу подключить новичка к работе, а принципы ООП будут освоены именно в процессе трудовой деятельности. Поэтому на собеседованиях чаще задают вопросы, позволяющие выявить степень владения языком, знания его особенностей, тонкостей.
Хотелось бы сказать несколько слов в защиту С++ с той точки зрения, что он допускает изучение, не вдаваясь в детали ООП. Приступать к его изучению можно сразу после знакомства с С и процедурным подходом. Основные понятия ООП могут быть вначале объяснены как средства улучшения традиционного С:
1. ссылки - как усовершенствованные указатели, разновидность «синтаксического сахара»;
2. класс - как «обёртка», высокоуровневая надстройка над множеством библиотечных функций;
3. класс - как усовершенствованная структура данных. Да, именно структура, к которой прилагаются несколько функций для работы с данными;
4. шаблоны - это удобное средство для параметризации, позволяющее сократить объём кода;
5. наследование - просто средство экономии кода, снижающее количество строк в программе.
6. потоки - более удобная модель системы ввода/вывода, по сравнению со стандартной библиотекой языка С.
При объяснении механизмов языка можно ссылаться на известные уже понятия, которые широко применялись в классическом С. Например, функции-члены класса связываются с объектом через указатели на функции, а на статические данные класса создаётся скрытый указатель.
В результате у студентов не формируется неприязни по отношению к ООП из-за упора на идеологию, а объяснения реализации механизмов языка позволяет лучше усвоить традиционно сложные разделы, посвящённые указателям и структурам.
Изучение объектного подхода может проходить на старших курсах и на основе изученных средств языка. Теперь ООП выступает как мощная идеология, для иллюстрации которой нет необходимости разбирать тонкости языка, а сразу же переходить к описанию задач. Тогда и средства ООЯП сразу найдут своё применение и будут восприняты естественным образом.
Литература
1. И.А. Барков Преподавание дисциплины «Объектно-ориентированное программирование» http://ifets.ieee.org/russian/depositorv/v12 i4/html/12.htm
2. Нефедова В. Ю. Структура, содержание и методические подходы к преподаванию в области
объектно-ориентированного языка программирования
http://www.ict.edu.ru/vconf/files/10821.doc
3. Савчук И. Почему объектно-ориентированное программирование провалилось? http://citforum.ru/gazeta/165/
4. Д. Спольски. Опасности обучения на Java, русский перевод И. Болодурин. http://local.юelonsoftware.com/wiki/Опасности обучения на Java
5. Столяров А.В. Язык Си и начальное обучение программированию. http://www.stolvarov.info/pvt/anti c
6. Буч Г. Объектно-ориентированный анализ и проектирование. - СПб.: Бином, 1998.
61
УДК 004.415.2.031.43
УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ПРОГРАММНОГО ПРОДУКТА В НЕЧЁТКИХ СИСТЕМАХ С ИСКУССТВЕННЫМ ИНТЕЛЛЕКТОМ
Степанова Анна Сергеевна, аспирант, Тамбовский государственный технический университет
Россия, Тамбов, ser23n2005@yandex.ru
Введение
Автоматизированное проектирование может быть организовано вокруг жизненных циклов продукции на основе производственных информационных технологий (развитие парадигмы компьютерно-интегрированных производств), а также деловых процессов в русле концепций реинжиниринга. Сейчас для промышленности России актуальны разработки на основе информационных технологий, производящих сложную наукоемкую продукцию [1].
Мы рассмотрим жизненный цикл программных средств (ПС) как непрерывный процесс с момента принятия решения о необходимости использования ПС до полного его изъятия из эксплуатации [2]. Структура жизненного цикла ПС базируется на трех группах процессов:
• основные процессы жизненного цикла;
• вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, конфигурационное управление, верификация, решение проблем);
• организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и совершенствование жизненного цикла ПС, обучение).
Анализ опыта организации работ на фазах жизненного цикла ПС [1] показывает, что это сложная работа, требующая высокой квалификации специалистов. Использование существующей методологической базы показало низкую точность предлагаемых методик даже по сравнению с экспертным подходом к оценке трудоемкости. На данный момент эта проблема не решена [2]. Жизненный цикл ПС носит итерационный характер: результаты очередного этапа вызывают изменения решений, выработанных на более ранних этапах проекта. Это необходимо учитывать при оценке трудоемкости процессов жизненного цикла.
Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предписывает конкретную модель жизненного цикла и методы разработки ПС. Пользователь стандарта отвечает за выбор модели жизненного цикла для конкретного проекта ПС и за адаптацию процессов, действий и задач стандарта к данной модели.
Стандарт IEEE 1209:1992 содержит рекомендации по оценке инструментальных средств и их выбору, поддерживая процессы программной инженерии, включая процессы управления проектами, разработки и последующие, а также интегральные процессы жизненного цикла программного средства.
1. Методы оценки и модели
Методологии, технологии и инструментальные средства поддержки процессов жизненного цикла составляют основу инфраструктуры проекта ПС. Многие модели оценки ПС запатентованы, следовательно, их структуру по известным причинам нельзя сравнить и сопоставить с другими. Поэтому функциональная форма этих моделей определена экспериментально на основе анализа открытых публикаций [2].
Рассмотрим две модели жизненного цикла ПС. Первая модель жизненного цикла ПС (SLIM). Л. Путнэм (L. Putnam), сотрудник компании Quantitative Software Measurement, в конце 70-х годов XX века разработал модель жизненного цикла программных средств -SLIM [4]. Модель SLIM базируется на анализе жизненного цикла на основе распределения Райли (Rayleigh distribution), отражающего соотношение между количеством исполнителей и длительностью проекта. Эта модель (рис.1) поддерживает методы оценки масштаба проекта, включая методы приближения, первичные инструкции, балльную функциональную оценку.
62
