- •«Технологии разработки программного обеспечения»
- •Оглавление
- •Введение
- •Анализ проблемы. Постановка задачи
- •Введение
- •Описание примера
- •Составление списка заинтересованных лиц
- •Анкетирование и проведение интервью
- •Список потребностей заинтересованных лиц
- •Задания
- •Контрольные вопросы
- •Моделирование объекта автоматизации
- •Введение
- •Введение в методологиюAris
- •Описание инструментаAris. Начало работы
- •Построение организационной модели
- •Построение диаграммы цепочек добавленного качества
- •ПостроениеeEpCмодели
- •Описание объектов автоматизации
- •Задания
- •Контрольные вопросы
- •Разработка модели вариантов использования и их спецификаций
- •Введение
- •Разработка модели вариантов использования
- •Модель вариантов использования
- •Построение модели вариантов использования
- •Спецификация вариантов использования
- •Основной поток
- •Альтернативные потоки
- •Специальные требования
- •Пример спецификации варианта использования
- •Алгоритм расчёта рейтингов
- •Задания
- •Пример написания раздела
- •Назначение документа
- •Наименование системы
- •Сведения о заказчике и исполнителе
- •Основания для выполнения работ, сроки и финансирование
- •Основные понятия, определения и сокращения
- •Актуальность разработки системы
- •Назначение и цели создания (развития) системы
- •Требования к содержимому раздела
- •Пример написания раздела
- •Характеристики объекта автоматизации
- •Требования к содержимому раздела
- •Пример написания раздела
- •Организация и планирование научно-исследовательской и инновационной деятельности
- •Исполнители научно-исследовательских работ
- •Учет и отчетность по научно-исследовательским работам
- •Требования к системе
- •Требования к содержимому раздела
- •Пример написания раздела
- •Требования к системе в целом
- •Требования к структуре и функционированию системы
- •Требования к численности и квалификации персонала
- •Требования к функциям (задачам)
- •Описание вариантов использования
- •Состав и содержание работ по созданию системы
- •Требования к содержимому раздела
- •Пример написания раздела
- •Порядок контроля и приемки системы
- •Требования к содержимому раздела
- •Пример написания раздела
- •Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- •Требования к содержимому раздела
- •Пример написания раздела
- •Создание служб необходимых для функционирования системы
- •Функциональные этапы внедрения системы
- •Требования к документированию
- •Требования к содержимому раздела
- •Пример написания раздела
- •Паспорт системы
- •Общее описание системы
- •Руководство администратора
- •Руководство пользователя
- •Регламент эксплуатации
- •Источники разработки
- •Правила оформления
- •Задание
- •Бизнес-логика
- •Объектно-реляционное отображение
- •Структура бд
- •Создание проекта вBorlandDeveloperStudio
- •Добавление нового модуля в проект
- •Создание классов с помощью диаграммыUml
- •Добавление полей
- •Добавление свойств
- •Добавление процедуры
- •Добавление функции
- •Создание отношений между классами
- •Ассоциация
- •Агрегация
- •Наследование
- •Пример создания классов
- •Создание классов и отношений между ними слоя объектно-реляционного отображения
- •Создание классов слоя бизнес-логики
- •Невизуальные компоненты интерфейса используемые в примере
- •TimageList
- •TActionManager
- •Визуальные компоненты используемые в примере
- •TBitBtn
- •TdbGrid
- •TcomboBox
- •TPageControl
- •Пример разработки интерфейса
- •Главная форма
- •Форма редактирования параметров студента
- •Форма редактирования книг
- •Форма отображения списка книг
- •Подключение классов
- •Сохранение проекта
- •Задание
- •Шаблоны проектирования
- •Шаблон InformationExpert(информационный эксперт)
- •Преимущества
- •Шаблон Creator(создатель)
- •Преимущества
- •Шаблон LowCoupling(слабое связывание)
- •Преимущества
- •Шаблон HighCohesion(высокое зацепление)
- •Преимущества
- •Шаблон Controller(контроллер)
- •Преимущества
- •Применение шаблонаInformationExpert
- •Применение шаблонаCreator
- •Использование шаблонаHighCohesion
- •Применение шаблонаController
- •Задание
- •Технология eco
- •Язык объектных ограничений ocl
- •Mdi-контейнеры
- •Создание простого mda-приложения
- •Основные этапы разработки приложения
- •Обзор возможностей Borland Developer Studio 2006 для разработки mda-приложения
- •Создание моделиUml
- •Создание бд и настройкаEcOкомпонент
- •Создание интерфейса
- •Связывание интерфейса с моделью
- •Создание логики наOcl
- •Задания
- •Контрольные вопросы
- •РазработкаMda-приложения с использованием машин состояний
- •Введение
- •Автоматы
- •Состояния
- •Подавтоматы
- •Диаграммы состояний
- •Создание mda-приложений с использованием машин состояний
- •Модификация модели uml
- •Создание машины состояний
- •Обновление базы данных
- •Модификация пользовательского интерфейса
- •Связывание интерфейса с моделью
- •Применение автоформ
- •Расширение пользовательского интерфейса
- •Задания
- •Контрольные вопросы
- •Расширенные возможности разработкиMda-приложений
- •СозданиеMda-приложения с расширенными возможностями
- •Модификация моделиUml
- •Программное добавление объекта
- •Программное удаление объекта
- •Программное редактирование объекта
- •Работа со справочником
- •Поиск объектов
- •Задания
- •Контрольные вопросы
- •Заключение
- •Библиографический список
Состояния
Конкретное состояние (в общем случае – статический срез системы) формируется инструментом State(Состояние). На диаграмме оно изображается в виде прямоугольника с закругленными углами. Состояние имеетимя, начинающееся с заглавной буквы. Под ним могут записыватьсяусловие идействия. Условия проверяются, а действия выполняются, когда автомат находится в соответствующем состоянии.
Отметим принятые правила оформления элементов диаграммы состояний. Элемент Stateпредставляет не действие, а описание статического состояния, в котором автомат может находиться неограниченно долго. Автомат может переходить из текущего состояния в другие состояния при выполнении определенных действий пользователя или условий, которые должны быть выполнены. Действия и условия отображаются только на линиях переходов между состояниями.
Подавтоматы
Внутри каждого состояния разрешается формировать собственный автомат (подавтомат) – мини-диаграмму состояний. Благодаря этому возможно проектировать систему постепенно, раскрывая отдельные ее элементы по мере необходимости.
Подавтомат – это автомат, вложенный в другой автомат и описывающий поведение конкретного состояния.
Диаграммы состояний
Диаграммы состояний (StateMachineDiagram) стали новым типом диаграмм в версииUML2.0. Они особенно важны для разработчика, использующего средуDelphi. Дело в том, что в последней версииDelphi2006 имеется технология моделирования ЕСОIII. Она расширена средствами визуального построения алгоритмов. С помощью этих средств описывается работа разных элементов модели. Ранее для описания модели и генерации исходного кода на языкеDelphiприменялись лишь статические диаграммы классов. Теперь задействованы и диаграммы состояний.
Диаграмма состояний –это средство, описывающее логику функционирования автоматов (машин состояний).
В основу диаграмм состояний положена концепция автоматов. Доказано, что с помощью таких автоматов можно запрограммировать произвольный алгоритм любой сложности, если его можно также записать на императивном языке программирования.
Диаграмма состояний всегда относится к конкретному классу и описывает его внутреннее функционирование. На диаграмме конкретное состояние отображается с помощью элемента Sate. Начальное и конечное состояния – элементыInitial(Начальное) иFinal(Конечное) – представлены на диаграмме сплошным кружком. Кружок, соответствующий конечному состоянию, обведен каймой. Фактически, это псевдосостояния, не возникающие при реальной работе. Начальное и конечное состояния лишь наглядно задают последовательность входа в первое рабочее состояние и выхода из последнего рабочего состояния.
Отдельное состояние может охватывать последовательность действий. Состояние, охватывающее другие состояния, называют суперсостоянием, а вложенные в него состояния –подсостояниями. Такой иерархический подход к организации состояний позволяет формировать одинаковое реакции подсостояний на уровне одного суперсостояния. Пусть, например, имеется стандартное аварийное состояние и стандартный переход в него по команде отмены. Для каждого из множества состояний диаграммы можно указать этот переход индивидуально, а можно объединить их в суперсостояние. Тогда переход в аварийное состояние представляется на диаграмме всего одной линией, исходящей из элемента, представляющего суперсостояние.
Каждое из состояний на диаграмме не обязано пассивно ожидать внешнего события, приводящего к переходу основного объекта в следующее состояние. Состояние может вести определенную деятельность. Соответствующая деятельность задается свойством состояния Doactivity(Выполнение деятельности). Нужная деятельность уже должна быть задана в проекте, например на одной из диаграмм деятельности. Подобное состояние, когда до него доходит очередь, начинает эту деятельность и ожидает ее завершения, фактически отображая не статическое состояние, а выполнение процесса. Этот процесс может быть прерван, что вызовет переход в другое состояние. Если он закончится успешно, также выполнится соответствующий переход.
В диаграммах состояний UML2.0 можно описывать историческое состояние. Обычная история состояния и глубокая история представлены как отдельные элементы:ShallowHistory(Обычная история состояния) иDeepHistory(Глубокая история).
Элемент Junction(Слияние) визуализирует слияние и разделение потоков управления. Он представляет собой промежуточный узел, по внешнему виду аналогичный начальному элементуInitial. В таком узле собираются, а потом вновь расходятся потоки управления. В диаграммах состояний можно также задействовать условный элементChoice(Выбор).