![](/user_photo/2706_HbeT2.jpg)
- •Технология разработки
- •Введение
- •Жизненный цикл программных систем План лекции
- •Введение
- •Программа, программная система. Программный продукт. Программная система как технологический объект.
- •Понятие жизненного цикла программных систем
- •Модели жизненного цикла программного обеспечения
- •Фазы жизненного цикла по
- •Заключение
- •Прикладной системный анализ при разработке по. Принципы структурного анализа. Процедура требований
- •План лекции
- •Введение
- •Проблема сложности ис
- •Группы средств моделирования систем
- •Заключение
- •Моделирование функций по. Нотация idef0. Case-средство bpWin
- •План лекции
- •Введение
- •ДиаграммыIdef0.
- •Виды связей вIdef0
- •Диаграмма дерева узлов
- •Диаграмма «Только для просмотра» (ForExpositionOnly–feo)
- •Case-средство bpWin
- •Заключение
- •Описание динамики системы. Нотация idef3
- •План лекции
- •Введение
- •Основные символыIdef3
- •Виды перекрестков вIdef3
- •Виды связей вIdef3
- •Пример диаграммыIdef3
- •Заключение
- •Постановка требований к данным. Словари данных. Моделирование данных в нотации idef1x. Case-средство erWin
- •План лекции
- •Введение
- •Словарь данных
- •Моделирование данных в нотацииIdef1x
- •Базовые понятияErd
- •Виды сущностей вIdef1x
- •Виды связей вIdef1x
- •Нормализация схемы данных
- •Заключение
- •Постановка требований к интерфейсу по. Понятие Usability.
- •План лекции
- •Введение
- •Эргономические цели и показатели качества программного продукта
- •Проблемы, возникающие на этапе разработки прототипа gui и варианты их решения
- •Принципы реализации пользовательского интерфейса
- •Заключение
- •Объектно-ориентированная методология проектирования по. Язык uml. Case-средство Rational Rose.
- •План лекции
- •Введение
- •Основные компоненты языка uml
- •Назначение языка uml
- •Общая структура языка uml
- •Пакеты в языке uml
- •Основные пакеты метамодели языка uml
- •Пакет Основные элементы
- •Пакет Элементы ядра
- •Пакет Вспомогательные элементы
- •Пакет Механизмы расширения
- •Пакет Типы данных
- •Пакет Элементы поведения
- •Пакет Общее поведение
- •Пакет Кооперации
- •Пакет Варианты использования
- •Пакет Автоматы
- •Пакет Общие механизмы
- •Пакет Управление моделями
- •Специфика описания метамодели языка uml
- •Особенности изображения диаграмм языка uml
- •Объектно-ориентированные case-средства (Rational Rose)
- •Структура и функции
- •Взаимодействие с другими средствами и организация групповой работы
- •Среда функционирования
- •Вариант использования
- •Интерфейсы
- •Примечания
- •Отношения на диаграмме вариантов использования
- •Отношение ассоциации
- •Отношение расширения
- •Отношение обобщения
- •Отношение включения
- •Пример построения диаграммы вариантов использования
- •Заключение
- •Проектирование внутренней структуры приложений при помощи диаграмм классов в uml
- •План лекции
- •Введение
- •Имя класса
- •Атрибуты класса
- •Операция
- •Отношения между классами
- •Отношение зависимости
- •Отношение ассоциации
- •Отношение агрегации
- •Отношение композиции
- •Отношение обобщения
- •Интерфейсы .
- •Объекты
- •Шаблоны или параметризованные классы
- •Заключение
- •Проектирование динамики приложений при помощи диаграмм переходов состояний, диаграмм последовательности и диаграмм взаимодействия в uml
- •План лекции
- •Введение
- •Автоматы
- •Состояние
- •Имя состояния
- •Список внутренних действий
- •Начальное состояние
- •Конечное состояние
- •Переход
- •Сторожевое условие
- •Выражение действия
- •Составное состояние и подсостояние
- •Последовательные подсостояния
- •Параллельные подсостояния
- •Историческое состояние
- •Сложные переходы
- •Переходы между параллельными состояниями
- •Переходы между составными состояниями
- •Синхронизирующие состояния
- •Заключительные рекомендации по построению диаграмм состояний
- •Диаграмма деятельности (activity diagram)
- •Состояние действия
- •Переходы
- •Дорожки
- •Объекты
- •Рекомендации по построению диаграмм деятельности
- •Диаграмма последовательности (sequence diagram)
- •Объекты
- •Линия жизни объекта
- •Фокус управления
- •Сообщения
- •Ветвление потока управления
- •Стереотипы сообщений
- •Временные ограничения на диаграммах последовательности
- •Комментарии или примечания
- •Пример построения диаграммы последовательности
- •Заключение
- •Управление требованиями к программному продукту. Case-средство Requisite Pro.
- •План лекции
- •Введение
- •Нормативная основа
- •Термины, сокращения и определения
- •Основные положения
- •Цели управления требованиями
- •Участники управления требованиями
- •Политика в области управления требованиями
- •Обеспечение процессов управления требований
- •Распределение ответственности
- •Аналитик
- •Менеджер проекта
- •Тестировщик
- •Проектировщик
- •Разработчик
- •Документирование
- •Обеспечение ресурсами
- •Обучение
- •Действия по управлению требованиями
- •Анализ требований
- •Разработка материалов проекта на основе требований
- •Контроль изменений требований
- •Измерения
- •Показатель важности
- •Контроль со стороны руководителя проекта
- •Контроль со стороны гок
- •Стандарт оформления требований
- •Шаблон для разработки требований
- •Правила оформления требований
- •Структурирование требований
- •Показатели качества требований
- •Проверяемость
- •Модифицируемость
- •Прослеживаемость
- •Начало работы сRequisitePro
- •Создание и настройка проекта
- •Создание проекта
- •Создание типов требований
- •Определение атрибутов
- •Создание типов документов
- •Добавление требований
- •Требования в документах
- •RequisitePro Views
- •Обсуждения
- •Заключение
- •Тестирование приложений. Функциональное тестирование, нагрузочное тестирование. Case-средстваRational Functional Tester,Rational Performance Tester.
- •План лекции
- •Введение
- •Дестабилизирующие факторы и методы обеспечения высокого качества функционирования по
- •Использование среды автоматизированного тестированияPlatinumTestBytes
- •Методы обеспечения качества и надежности программных средств
- •Использование case для повышения качества по
- •Влияние стандартов открытых систем на качество по
- •Повышение качества по путем тестирования
- •Основные особенности процесса тестирования по
- •Организационные особенности тестирования
- •Сертификация по
- •Организация и планирование тестирования для обеспечения качества по
- •Важнейшие разделы iso 9003
- •Общие положения
- •Документирование системы качества
- •Программа качества
- •Внутренние проверки системы качества
- •Корректирующие действия
- •Заключение
- •Комплексная интеграция bpWin, erWin и Paradigm Plus.
- •План лекции
- •Введение
- •Соответствие объектов моделей процессов и моделей данных
- •Экспорт между моделью данных и моделью процессов
- •Paradigm Plus: двусторонняя связь с eRwin
- •Создание физической модели данных вErWin
- •Уровни физической модели
- •Правила валидации и значения по умолчанию
- •Индексы
- •Триггеры и хранимые процедуры
- •Значения ri, используемые erWin для различных типов связей
- •Заключение
- •Стандарты, регламентирующие разработку по
- •План лекции
- •Введение
- •Iso 15504 spice
- •Серия стандартов гост 34-ххх «Информационная технология»
- •Группы процессов
- •Взаимосвязи процессов
- •Процессы инициации
- •Результаты
- •Исходная информация
- •Шаги задачи
- •Методика и подход
- •Выработать основные положения проекта
- •Определить область применения, цели и подход
- •Произвести оценку рисков
- •Получить подтверждение Заказчика и Исполнителя
- •Роли и ответственность
- •Заключение
- •Рабочий план
- •План лекции
- •Введение
- •Основные процессы планирования
- •Вспомогательные процессы планирования
- •Документ «Рабочий план»
- •По работам
- •По исполнителям
- •Диаграмма Гантта по проекту
- •Процессы управления
- •Основные процессы управления
- •Вспомогательные процессы управления
- •Основные процессы анализа
- •Вспомогательные процессы анализа
- •Заключение Заключение
- •Контрольные вопросы
- •Библиографический список
Принципы реализации пользовательского интерфейса
Стилевая гибкость– возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется в виде набора “skins”, для web-интерфейсов – с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок ПИ (цвет, иконы, подсказки и пр.).
Совместное наращивание функциональности– возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса.
Масштабируемость – возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных.
Адаптивность к действиям пользователя– приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариативность доступа к прикладным функциям (иконы, «горячие клавиши», меню …), кроме того программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации.
Независимость в ресурсах – для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, направленные на хранение и обработку данных, необходимых для поддержки пользователя (пользовательские словари, контекстно-зависимые списки, наборы данных по умолчанию или по последнему запросу, истории запросов и пр.)
Переносимость – при переходе на другую аппаратную (программную) платформу, должен осуществляется автоматически перенос и пользовательского интерфейса, и конечного приложения.
Заключение
Объектно-ориентированная методология проектирования по. Язык uml. Case-средство Rational Rose.
План лекции
Предыстория. Математические основы (теория множеств, теория графов, семантические сети).
Диаграммы структурного анализа.
Основные этапы развития UML.
Назначение языка UML.
Общая структура языка UML.
Пакеты в языке UML.
Основные пакеты метамодели языка UML (основные элементы, элементы ядра, вспомогательные элементы, механизмы расширения, типы данных, элементы поведения, общее поведение, кооперации, варианты использования, автоматы, общие механизмы, управление моделями). Специфика описания метамодели языка UML.
Особенности изображения диаграмм языка UML.
Введение
Необходимость анализа предметной области до начала написания программы была осознана давно при разработке масштабных проектов. Процесс разработки баз данных существенно отличается от написания программного кода для решения вычислительной задачи. Главное отличие заключается в том, что при проектировании базы данных возникает необходимость в предварительной разработке концептуальной схемы, которая отражала бы общие взаимосвязи предметной области и особенности организации соответствующей информации. При этом под предметной областью принято понимать ту часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения некоторой задачи.
Выделение исходных или базовых компонентов предметной области, необходимых для решения той или иной задачи, представляет, в общем случае, нетривиальную проблему. Сложность данной проблемы проявляется в неформальном характере процедур или правил, которые можно применять для этой цели. Более того, такая работа должна выполняться совместно со специалистами или экспертами, хорошо знающими предметную область. Например, если разрабатывается база данных для обслуживания пассажиров крупного аэропорта, то в проектировании концептуальной схемы базы данных должны принимать участие штатные сотрудники данного аэропорта. Эти сотрудники должны хорошо знать весь процесс обслуживания пассажиров или данную предметную область.
Для выделения или идентификации компонентов предметной области было предложено несколько способов и правил. Сам этот процесс получил название концептуализации предметной области. При этом под компонентой понимают некоторую абстрактную единицу, которая обладает функциональностью, т. е. может выполнять определенные действия, связанные с решением поставленных задач. На предварительном этапе концептуализации рекомендуется использовать так называемые CRC-карточки (Component, Responsibility, Collaborator— компонента, обязанность, сотрудники). Для каждой выделенной компоненты предметной области разрабатывается собственная CRC-карточка (рис. 24).
Общий вид CRC-карточки для описания компонентов предметной области
Появление методологии ООАП потребовало, с одной стороны, разработки различных средств концептуализации предметной области, а с другой — соответствующих специалистов, которые владели бы этой методологией. На данном этапе появляется относительно новый тип специалиста, который получил название аналитика или архитектора. Наряду со специалистами по предметной области аналитик участвует в построении концептуальной схемы будущей программы, которая затем преобразуется программистами в код. При этом отдельные компоненты выбираются таким образом, чтобы при последующей разработке их было удобно представить в форме классов и объектов. В этом случае немаловажное значение приобретает и сам язык представления информации о концептуальной схеме предметной области.
Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. Стандарт ISO/IEC 12207, хотя и описывает общую структуру ЖЦ программы, не конкретизирует детали выполнения тех или иных этапов. Согласно принятым взглядам ЖЦ программы состоит из следующих этапов:
Анализа предметной области и формулировки требований к программе
Проектирования структуры программы
Реализации программы в кодах (собственно программирования)
Внедрения программы
Сопровождения программы
Отказа от использования программы
На этапе анализа предметной области и .формулировки требований осуществляется определение функций, которые должна выполнять разрабатываемая программа, а также концептуализация предметной области. Эту работу выполняют аналитики совместно со специалистами предметной области. Результатом данного этапа должна являться некоторая концептуальная схема, содержащая описание основных компонентов и тех функций, которые они должны выполнять.
Этап проектирования структуры программы заключается в разработке детальной схемы будущей программы, на которой указываются классы, их свойства и методы, а также различные взаимосвязи между ними. Как правило, на этом этапе могут участвовать в работе аналитики, архитекторы и отдельные квалифицированные программисты. Результатом данного этапа должна стать детализированная схема программы, на которой указываются все классы и взаимосвязи между ними в процессе функционирования программы. Согласно методологии ООАП, именно данная схема должна "служить исходной информацией для написания программного кода.
Этап программирования вряд ли нуждается в уточнении, поскольку является наиболее традиционным для программистов. Появление инструментариев быстрой разработки приложений (Rapid Application Development, RAD) позволило существенно сократить время, и затраты на выполнение этого этапа. Результатом данного этапа является программное приложение, которое обладает требуемой функциональностью и способно решать нужные задачи в конкретной предметной области.
Этапы внедрения и сопровождения программы связаны с необходимостью настройки и конфигурирования среды программы, а также с устранением возникших в процессе ее использования ошибок. Иногда в качестве отдельного этапа выделяют тестирование программы, под которым понимают проверку работоспособности программы на некоторой совокупности исходных данных или при некоторых специальных режимах эксплуатации. Результатом этих этапов является повышение надежности Программного приложения, исключающего возникновение критических ситуаций или нанесение ущерба компании, использующей данное приложение.
Примечание: Рассматривая различные этапы ЖЦ программы, следует отметить одно важное обстоятельство. А именно, если появление RAD-инструментариев позволило существенно сократить сроки этапа программирования, то отсутствие соответствующих средств для первых двух этапов долгое время сдерживало процесс разработки приложений. Развитие методологии ООАП было направлено на автоматизацию второго, а затем и первого этапов ЖЦ программы.
Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). Появление первых CASE-средств было встречено с определенной настороженностью. Со временем появились как восторженные Отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над некоторой системой управления базами данных (СУБД). Хотя визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, она не решает проблем разработки приложений других типов.
Вторая причина имеет более сложную природу, поскольку связана с графической нотацией, реализованной в том или ином CASE-средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить подходящий синтаксис для визуального представления концептуальных схем БД были восприняты далеко неоднозначно. Появилось несколько подходов, которые более подробно будут рассмотрены в главе 2. На этом фоне появление унифицированного языка моделирования (Unified Modeling Language, UML), который ориентирован на решение задач первых двух этапов ЖЦ программ, было воспринято с большим оптимизмом всем сообществом корпоративных программистов.
Примечание Аббревиатура UML допускает соответствующий перевод и последующее сокращение, но ввиду неудобочитаемости получающегося "УЯМ" было решено использовать исходный термин на всем протяжении книги. Частично это можно объяснить уже сложившейся традицией применения оригинальных терминов, таких как CASE, RAD, DLL, ISDN и целого ряда других.
Последнее, на что следует обратить внимание, это осознание необходимости построения предварительной модели программной системы, которую, согласно современным концепциям ООАП, следует считать результатом первых этапов ЖЦ программы. Поскольку язык UML даже в своем названии имеет отношение к моделированию, следует дополнительно остановиться на целом ряде достаточно важных вопросов. Таким образом, мы переходим к теме, которая традиционно не рассматривается в изданиях по ООАП, но имеющая самое прямое отношение к процессу построения моделей и, собственно, моделированию. Речь идет о методологии системного анализа и системного моделирования.