Тема: Основные положения методики выбора инструментальных средств разработки программных продуктов.

Дата: 2025-06-14; Просмотры: 1

Оценка:

0.00 из 5.00 — оценок

Скачиваний: 0

Скачать

ПЛАН ЗАНЯТИЯ

Дисциплина: МДК 03.02 Инструментальные средства разработки ПО

Преподаватель: Машарова Р.В.

Курс: 4

Группа: 1 ПКС-19

Специальность: Программирование в компьютерных системах

Дата: 21.02.2023

Время проведения: 13.30-15.00, 4 пара

Тема: Основные положения методики выбора инструментальных средств разработки программных продуктов.

Цель занятия:

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

Развивающая: развивать логическое и критическое мышление, умение обобщать и синтезировать знания

Вид занятия лекция

Литература:

1. Буч Г, Рамбо Джеймс, Джекобсон Айвар. Язык UML. Руководство пользователя. – М.: ДМК Пресс; СПб.: Питер, 2004

2. Гагарина Л. Г., Кокорева Е. В., Виснадул Б. Д. Г12 Технология разработки программного обеспечения: учебное посо­бие / под ред. Л. Г Гагариной. — М.: ИД «ФОРУМ»: ИНФРА-М, 2008

3. Жоголев Е.А., Технология программирования. М.: Научный мир, 2004

4. Крылов Е.В., Острейковский В.А., Типикин Н.Г. Техника разработки программ. Книга 2. Технология, надежность и качество программного обеспечения — М.: Высшая школа. – 2009

5. Крылова Г.Д. Основы стандартизации, сертификации, метрологии. – М.: ЮНИТИ-ДАНА, 2003

6. Лифиц И.М. Основы стандартизации, метрологии, сертификации. – М.: Юрайт, 2003

7. Маклаков С.В.. BPwin, ERwin – CASE-средства разработки информационных систем. – М., «ДИАЛОГ-МИФИ», 2010

8. Немилостива Н.И. Стандартизация, сертификация и метрология. – Владивосток: Изд-во ВГУЭС, 2002

9. Павловская Т. А. С/С++. Программирование на языке высокого уровня: Учебник для студентов вузов. - Москва [и др.]: Питер, 2012

10. Сергеев А.Г., Латышев М.В., Терегеря В.В. Метрология. Стандартизация. Сертификация. –М.: Логос, 2003

11. Сьерра К. Бейтс Б. Изучаем java. 2012

12. Файн Я. Программирование на java / Я. Файн. – 3-е изд. – США, 2011

13. Шилдт Герберт Java. Полное руководство. 8-издание / Г.Шилдт. – 8-е изд. –2012

Тема: Основные положения методики выбора инструментальных средств разработки программных продуктов.

1. Проблема выбора подходящей среды.

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

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

1.Проблема выбора подходящей среды.

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

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

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

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

Оценивая качество и эффективность операционной среды необходимо обращать внимание на интерфейсы инструментальных средств. Современный подход к пользовательскому интерфейсу был заложен в стандарте фирмы IBM. Этот стандарт воплотился во многих программных средствах, как инструментальных, так и прикладных. Стандарт определяет оконный интерфейс, правила размещения в окнах элементов управления, назначение горячих клавиш и даже рекомендует цветовые схемы интерфейса. Конечно, в рамках этого стандарта можно реализовать большое количество разнообразных интерфейсов. Развитие и нововведения в интерфейсах можно проследить на линейках продуктов типа MS Office. Одним из важных и необходимых свойств среды является возможность настройки. К интерфейсу также относится замечание об избыточности и необходимости минимизации возможностей.

Технология программирования во многом определяется языком программирования, на котором пишутся программы. В языке могут быть заложены средства, влияющие на технологичность и архитектуру разрабатываемой системы (например, объектно-ориентированность, модульность и т.п.). О распространенности языков можно судить по рейтингу, ежемесячно составляемой фирмой TIOBE. В таблице приводится первая десятка языков с наибольшими рейтингами на март 2012 и указанием тенденций в их местах по сравнению с тем же месяцем прошлого года. Рейтинг составляется по определенной методике, основанной в основном на упоминаниях в Интернете. Как видно, ведущие места занимают C-подобный языки. Язык Java прочно удерживает первую позицию в течение последних лет. Интересно, что эта десятка практически постоянна (см. рейтинги 2009 года), но доля первых трех языков снижается (с 54 до 45 % за 4 года). Это, по-видимому, связано с развитием интернет-технологий с ее скриптовыми языками Python, Perl, JavaScript и др.

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

Приведенные ниже критерии являются общими по своей природе и не принадлежат к совокупности показателей качества, приведенной в стандарте ISO/IEC 9126:

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

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

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

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

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

· экспортные ограничения.

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

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

· доступность и качество обучения. Обучение может проводиться на территории поставщика, пользователя или где-либо в другом месте.

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

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

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

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

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

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

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

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

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

· база знаний;

· сервер приложений;

· приложение пользователя.

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

· объектная модель данных;

· реляционная модель данных;

· модель данных на языке OWL;

· модель данных на языке RDF и т.д.

Рисунок 1 – архитектура системы

Онтологии, описанные на языке OWL и RDF, могут быть созданы, например, при помощи редактора онтологий Protege, а так же может быть отображена в базу данных объектно-ориентированной СУБД Cache или реляционной СУБД MS SQL Server.

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

Например, для объектной модели данных и реляционной модели данных это может быть встроенная библиотека MS Visual Studio C# System.Data; для онтологии на языке OWL это может быть библиотека OwlDotNetApi; для онтологии на языке RDF это может быть библиотека dotNetRDF.

Уровень сервера приложений включает в себя:

· подсистему работы с онтологией;

· подсистему ведения знаний;

· подсистему поиска решений.

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

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

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

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

· просмотр онтологии;

· ведение знаний;

· поиск решений.

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

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

Функция ведения знаний включает средства для предоставления возможности пользователю осуществлять добавление и изменение знаний в онтологии. Здесь возможна работа в одном из двух режимов:

· режим инженера знаний;

· режим эксперта.

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

Функция поиска решений включает средства для:

· задания критериев поиска;

· задания приоритетов критериев поиска;

· запуска процесса поиска технологий и средств разработки программного обеспечения;

· отображения найденных вариантов решений.

Эта функция определена для пользователей любого типа.

Контрольные вопросы.

1. Проблема выбора подходящей среды.

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

3. Применения интеллектуальных систем и онтологий.