Создание графического интерфейса пользователя

Презентация к лекции

Введение в CASE-средства

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

Такие средства называют CASE-средствами (Computer-Aided Software Engineering) — инструментами автоматизированной программной инженерии. Они охватывают весь жизненный цикл больших систем: от анализа требований до управления конфигурацией.

Итоги анализа моделей и методологий

Модель жизненного цикла — наиболее абстрактная формализация процесса создания ПО, а методология — набор практических приёмов реализации проекта. Выбор модели критически сказывается на успехе проекта, поскольку определяет:
• архитектуру решения (количество и взаимодействие компонентов);
• применяемые технологии;
• экономику и план проекта.

Каскадная модель предполагает один проход проектирования и жёсткую документную ориентацию. Модель «build and fix» (кодирование с исправлением ошибок) вообще не охватывает полный цикл. Итеративные и эволюционные модели обеспечивают получение работоспособного продукта в конце каждого частичного цикла, допуская раннее начало сопровождения и более гибкое реагирование на изменения.

При выборе модели необходимо учитывать:
• опыт и зрелость проектной команды;
• требования к дисциплине проектирования;
• знание CASE-средств, применяемых на всех этапах.

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

Архитектурные основы корпоративных систем

Базы данных

В основе корпоративных систем лежат базы данных (БД) большого объёма. Их проектирование включает:
• построение общей архитектуры — ER-модели (Entity-Relationship) и структуры отношений;
• выбор физической структуры хранения;
• стратегию резервирования, восстановления после сбоев и резервного копирования;
• механизмы доступа к данным и ограничения целостности;
• семантическое моделирование: отражение декомпозиции предметной области в схеме БД для минимизации изменений при её коррекции.

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

Распределённая архитектура

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

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

Современные корпоративные приложения реализуют трёхзвенную архитектуру с явным разделением логики:
1. Презентационная логика (интерфейс пользователя).
2. Бизнес-логика (алгоритмы предметной области).
3. Логика доступа к ресурсам (работа с БД и внешними системами).

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

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

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

Тенденции развития корпоративных систем

Современные направления включают:
• Компонентную разработку на платформах вроде .NET Framework и Java Beans с возможностью гибкой замены и доработки компонентов.
• Мобильные версии приложений, предоставляющие доступ к данным с мобильных устройств (язык C# на платформе .NET или Java).
• Кроссплатформенность — переносимость между операционными системами и прикладными средами.
• Интероперабельность (interoperability) — способность компонентов взаимодействовать независимо от платформы.
• Безопасность как сквозное требование.

Все модели жизненного цикла опираются на инвариантный математический фундамент — прежде всего теорию объектов. Важнейшие стандарты, которым необходимо следовать: UML (Unified Modeling Language), RUP (Rational Unified Process), MSF (Microsoft Solution Framework), объектные модели COM/DCOM/COM+, Java Beans, стандарт брокеров объектных запросов CORBA (Common Object Request Broker Architecture). Проектирование сложных систем требует понимания природы объектных моделей, а строгие методологии (RUP, MSF) позволяют адаптироваться к требованиям заказчика и обеспечить полную проектную документацию.

Итоговый программный продукт — это не только код, но и полный комплект документации: техническое задание, диаграммы (прецедентов, классов, последовательности, состояний, потоков данных и др.), документация к модулям, руководства по установке, настройке и эксплуатации.

CASE-средства: определение и функции

CASE-средства — инструментарий, поддерживающий полный жизненный цикл корпоративных приложений, решающий следующие задачи:
1. Анализ и спецификация требований — формализация функциональных и нефункциональных требований.
2. Проектирование прикладного ПО и баз данных: построение диаграмм (ER, классов и др.), архитектурное проектирование.
3. Генерация кода — автоматическое создание сигнатур классов по диаграммам, генерация схем БД на основе ER-модели.
4. Трассировка спецификаций — контроль соответствия требований проектным решениям и коду.
5. Тестирование — автоматизация функционального, нагрузочного тестирования и тестирования пользовательских интерфейсов.
6. Документирование — создание и синхронизация версий документации, сопоставимой по объёму с кодом.
7. Обеспечение качества — комплексная проверка и верификация.
8. Управление конфигурацией — учёт всех модулей и документации, управление версиями и сборками.
9. Управление проектом — организация взаимодействия участников (пример: Microsoft Visual Studio Team System).
10. Реинжиниринг — анализ и перепроектирование существующих компонентов.

Компоненты современных CASE-средств

1. Репозиторий — единое хранилище метаданных проекта, обеспечивающее:
o хранение версий (базовых линий — baseline и ветвей — branch) с операциями блокировки (lock) и заморозки стабильных релизов;
o синхронизацию локальных версий с глобальной сборкой;
o контроль целостности проектных спецификаций и структур данных.
2. Графические средства анализа и проектирования — редакторы диаграмм. Например, Microsoft Visual Studio интегрирована с Visio для поддержки UML и других нотаций; Rational Rose ориентирована на UML. Альтернативные стандарты включают DFD (диаграммы потоков данных) и ER-диаграммы.
3. Средства разработки кода — редакторы с технологией IntelliSense (подсветка синтаксиса, автодополнение членов классов).
4. Средства управления конфигурацией — версионный контроль всех артефактов проекта.
5. Средства документирования — автоматическая генерация и версионирование проектной документации.
6. Средства тестирования — например, Rational Robot для автоматизации регрессионного и нагрузочного тестирования.
7. Средства управления проектом и реинжиниринга.

Классификация CASE-средств

Классификацию проводят по нескольким критериям:
По степени интегрированности

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

По поддерживаемым стандартам

• Наличие поддержки UML, DFD, ER-моделей.
• Форматы хранения (например, XML).
• Поддержка методологий RUP, MSF.

По моделям данных и интеграции с СУБД

• Какие модели поддерживаются: реляционная, объектная, сетевая, иерархическая.
• С какими конкретными СУБД (Oracle, Microsoft SQL Server) возможна интеграция, включая генерацию ограничений целостности, триггеров и хранимых процедур на языках типа PL/SQL (Oracle).

По программно-аппаратной платформе

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

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

Краткие итоги

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

На эту методологическую основу наслаивается инструментальный уровень — CASE-средства, автоматизирующие полный цикл программной инженерии. Их ключевая ценность не просто в ускорении рисования диаграмм или генерации заготовок кода, а в обеспечении целостности и связности всех артефактов проекта через единый репозиторий. Благодаря этому трассировка требований, управление версиями, синхронизация документации с кодом и конфигурационный контроль становятся не разрозненными задачами, а взаимосвязанными процессами, объединёнными общей моделью данных. На практике способность CASE-средства поддерживать конкретные стандарты (UML, RUP или MSF), целевую СУБД и выработанную методологию прямо влияет на дисциплину команды и качество результата. Интегрированные комплексы нивелируют риск расхождения проектной документации с реальным кодом, а локальные инструменты эффективны лишь при условии ручной стыковки их выходных данных.

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