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

• Автор: Костарев, Александр Николаевич
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2004
• Место защиты: Москва
• Количество страниц: 186 с. : ил.

ОГЛАВЛЕНИЕ
Введение.

Глава 1. Анализ развития промышленных программных систем

1.1 Гибкость и расширяемость программного обеспечения.

1.1.1. Программные комплексы, создаваемые на заказ

1.1.2. Тиражные программные комплексы.

1.2. Подсистемы программирования

1.2.1. Этапы развития.

1.2.2. Недостатки первых подсистем программирования.

1.2.3. Механизмы взаимодействия приложений в операционных средах i i.

1.2.4. Интеграция с компонентной архитектурой i ivX

1.3. Параллельные и распределенные вычисления.
1.4. Выводы по главе 1
Глава 2. Технология построения контейнеров управляющих элементов ivX.
2.1. Общие принципы создания ivXконтейнеров
2.2. Архитектурные решения
2.2.1. Устройство объекта контейнера
2.2.1.1. Класс xi.
2.2.1.2. Класс x
2.2.1.3. Класс x
2.2.1.4. Класс
2.2.2. Устройство объекта связи с управляющим элементом.
2.2.2.1. Классы ix и ix
2.2.2.2. Класс xi
2.2.2.3. Класс xi
2.2.2.4. Класс i
2.2.3. Устройство объекта расширенного управляющего элемента
9 2.2.3.1. Класс САхИетВаБе
2.2.З.2. Класс СКеш
2.2.4. Подходы к использованию библиотеки
2.3. Автоматизация процесса разработки АсбуеХконтейнера.
2.4. Выводы по главе 2.
Глава 3. Методы обнаружения исключительных ситуаций
3.1. СПметод
3.1.1. Пример использования
3.2 АСметод
3.2.1. Пример использования
3.3. Сравнительный анализ представленных методов.
3.4. Метод обнаружения исключительных ситуаций в Утприложениях.
3.4.1. Теоретическое обоснование.
3.4.1.1. Операционная семантика функции Сгеа1еТЬгеас1
3.4.1.2. Операционная семантика критических секций.
3.4.1.3. Операционная семантика функции Vii.
3.4.1.4. Операционная семантика функции Vii
3.4.1.5. Операционная семантика семафоров
3.4.1.6. Операционная семантика событий
3.4.1.7. Операционная семантика мьютексов
3.4.2. Пример работы
3.5. Выводы по главе 3
Глава 4. Инструментальный комплекс КРогтБ.
4.1. Архитектура приложений КЗРоппб
4.2. Структура КБРоппб.
4.3. Средства разработки ЛЗРоггпб.
4.3.1. Особенности Дизайнера ЯЗРопиб.
4.3.2. Генератор кода.
4.3.3. Редактор исходного кода
4.3.4. Особенности экранных форм.
4.3.5. Механизм вывода информации на печать.
4.3.6. Компонентный подход
4.3.7. Настраиваемые элементы управления
4.3.8. Окна в .
4.3.9. Особенности меню в .
4.3 Связь форм с данными.
4.3 Редактор списков иконок
4.4. Компоненты , созданные на основе предложенной технологии построения ivXконтейнеров.
4.4.1. Контейнер оконная оболочка для одного ivXэлемента
4.4.2. Управляющий элемент форма.
4.4.3. Управляющий элемент печатная страница.
4.4.4. Управляющий элемент табулятор.
4.4.5. Объект меню.
4.4.6. Представление форм в виде самостоятельных управляющих элементов ivX
4.5. Выводы по главе 4.
Заключение.
Литература


Тротт, эксперты в области объектно-ориентированного программирования, провели исследование вопроса качества предоставляемых заказчиком требований к создаваемому программному продукту, результаты которого отражены в работе [] и заключаются в том, что, в большинстве случаев, требования являются неполными, противоречивыми, не описывающими поставленную задачу подробно. Практически не было выявлено проектов, для которых “предоставленные требования не только исчерпывающе полные, ясные и понятные, но также включают описание всех функциональных возможностей, которые потребуются заказчику в течение пяти последующих лет! Главный вывод, сделанный по результатам этого исследования, сформулирован в [] так: “требования к программному обеспечению всегда изменяются”. Приведенные рассуждения говорят о том, что необходимо научиться приспосабливать создаваемый программный код к неизбежному внесению изменений” []. Для эффективной обработки возникающих изменений при создании программного обеспечения в настоящее время используется объектно-ориентированная парадигма [ — ] в совокупности с шаблонами проектирования [ - ]. Ценность шаблонов проектирования состоит в том, что они не были кем-то придуманы, скорее они были “идентифицированы как уже существующие в разработках, выполненных сообществом создателей программного обеспечения. Каждый из шаблонов отражает те результаты, которые были достигнуты в высококачественных проектах при решении определенных, специфических проблем” []. Необходимость создания программного кода, устойчивого к внесению изменений, подтверждается практикой, однако, стоит отметить, что устойчивость к изменениям касается не только программного кода, но и всей системы в целом. Другими словами, архитектура системы должна включать механизмы расширения функциональных возможностей системы и настройки системы под конкретного пользователя в минимальные сроки и с наименьшими затратами. Все программные комплексы, предназначенные для автоматизации какой-либо предметной области, можно разделить на два класса: создаваемые на заказ и тиражные, представляющие собой “коробочный” продукт. Комплексы первого типа характеризуются тем, что они разрабатываются по требованиям конкретного заказчика и используются, в большинстве случаев, только им. Комплексы второго типа реализуют набор готовых типовых решений и предназначены для продажи нескольким потребителям. Специфика целевого назначения существенно сказывается на подходах к разработке. Практика показывает, что такие комплексы, обычно, не содержат каких-либо специальных подсистем, позволяющих конечным пользователям расширять их функциональные возможности. Процесс внесения изменений и расширений представляет собой стандартную схему: заявка от пользователя, говорящая о необходимости внесения ряда изменений; выезд специалиста-аналитика, выполняющего анализ и формулирующего проблему разработчикам; собственно, внесение изменений; компоновка новой версии системы; внедрение. Здесь в полной мере должны применяться методы создания программного кода, устойчивого к изменениям. Важно отметить, что объектный подход и шаблоны проектирования могут быть использованы в большинстве инструментальных средств разработки приложений. Более того, практически все современные среды разработки приложений, особенно предоставляющие возможности по созданию графического пользовательского интерфейса, ориентированы, в основном, на поддержку именно этого подхода. Описанный процесс внесения изменений занимает достаточно большой временной промежуток. Даже в случае небольших доработок он требует выезда специалистов, создания новых исполняемых модулей, а также полной или частичной переустановки системы у клиента. Также необходимо отметить, что при прочих равных условиях, создание системы на заказ обходится покупателю значительно дороже, чем аналогичная система, выполненная в коробочном варианте (при условии ее существования). В качестве примеров “заказных” систем можно привести программные продукты, созданные при участии автора ВЦ МЭИ: “Мэрия”, “Гостиница СНГ”, “Студент” и др.