- •«Технологии разработки программного обеспечения»
- •Оглавление
- •Введение
- •Анализ проблемы. Постановка задачи
- •Введение
- •Описание примера
- •Составление списка заинтересованных лиц
- •Анкетирование и проведение интервью
- •Список потребностей заинтересованных лиц
- •Задания
- •Контрольные вопросы
- •Моделирование объекта автоматизации
- •Введение
- •Введение в методологию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
- •Программное добавление объекта
- •Программное удаление объекта
- •Программное редактирование объекта
- •Работа со справочником
- •Поиск объектов
- •Задания
- •Контрольные вопросы
- •Заключение
- •Библиографический список
Построение диаграммы цепочек добавленного качества
Для уменьшения сложности описания деятельности организации необходимо разработать иерархию моделей БП организации, начиная с самого верхнего уровня и до моделей отдельных БП на нижнем уровне. Для описания модели верхнего уровня используется диаграмма типа Value-added chain diagram (VAD), название которой можно перевести какМодель цепочки добавленного качества (стоимости).
Диаграмма цепочек добавленного качества описывает функции организации, которые непосредственно влияют на реальный выход ее продукции. Эти функции создают последовательность действий, формируя добавленные значения: стоимость, количество, качество и т.д.
Для создания диаграммы VADщелкните правой кнопкой мыши по главной папке и в появившемся контекстном меню выберитеNew→Model. Появится окно выбора модели (рисунок 2.5). Поставьте галочку в полеProcesses, что соответствует процессному представлению.
Выберите диаграмму Value-added chain diagramи нажмите кнопку «Далее». Введите имя новой модели, например «Основные процессы».
Диаграмма цепочек добавленной стоимости может содержать следующие структурные элементы: Организационная единица, Должность или позиция, функция и др. (таблица 3.2).
Таблица 3.5
Элементы диаграммы цепочки добавленного качества
№ |
Графическая нотация |
Наименование |
Описание |
1. |
|
Функция |
Действие или набор действий, выполняемых над исходным объектом (документом, материалом и т.п.) с целью получения заданного результата. |
2. |
|
Технический термин |
|
3. |
|
Организационная единица (Organizational unit) |
Элемент организационной структуры (структурное подразделение), который отвечает за выполнение определенных задач и преследует определенные цели. |
4. |
|
Кластер (экземпляр) |
Экземпляр объекта данных. Он представляет собой логический взгляд на набор объектов данных или структур |
Пример диаграммы цепочек добавленной стоимости представлен на рисунке 3.8.
Рисунок 3.9 – Основные процессы учета успеваемости студентов в системе кредитов
Маленьким значком в нижнем правом углу элемента модели помечаются те функции, для которых существуют модели, раскрывающие эту функцию. Таким механизмом реализуется принцип декомпозиции.
ПостроениеeEpCмодели
Цепочка процесса, управляемая событиями — Extended event driven process chain (eEPC).
С помощью диаграмм EPC процедуры БП представляются как логические последовательности событий. События определяют, какое состояние или отношение будет переключать функцию и какое состояние наступит после ее выполнения. Поэтому модель EPC должна всегда иметь запускающие и завершающие события.
Одно событие может инициировать выполнение одновременно нескольких функций, и, наоборот, функция может быть результатом наступления нескольких событий. Объединения нескольких событий или функций отображаются на диаграмме EPC с помощью соединителей в виде небольшого кружка. Эти соединители не только отображают графические связи между объектами модели, но и определяют логические связи между ними. Различают два типа связи логических операторов – связи событий исвязи функций.
Для создания диаграммы EPCщелкните правой кнопкой мыши по главной папке и в появившемся контекстном меню выберитеNew→Model. Появится окно выбора модели (рисунок 3.8). Поставьте галочку в полеProcesses, что соответствует процессному представлению.
Выберите диаграмму eEPCи нажмите кнопку «Далее». Введите имя новой модели.
Диаграмма цепочек, управляемых событиями кроме элементов организационной диаграммы и диаграммы данных может содержать следующие структурные элементы: функция, событие и др. (таблица 3.3).
Таблица 3.6
Элементы диаграммы цепочек, управляемых событиями
№ |
Графическая нотация |
Наименование |
Описание |
1. |
|
Функция |
Действие или набор действий, выполняемых над исходным объектом (документом, материалом и т.п.) с целью получения заданного результата. |
|
|
Событие |
Состояние, которое является существенным для управления БП и которое оказывает влияние или контролирует дальнейшее развитие одного или более БП. Изменения состояния отражаются с помощью информационных объектов |
|
|
Правило |
Представляет собой правило разветвления и слияния веток БП. Если перейти к рассмотрению каждой отдельной функции БП, то можно сказать, что правило отражает логическое соотношение между несколькими исходными для функции событиями и несколькими результирующими. |
|
|
Интерфейс функции |
Используется для обозначения функции внешнего БП, который либо не описывается в данной модели, либо является БП другой предметной области. |
|
|
Носитель информации |
Представляет собой средство хранения информации. Оно может быть реализовано, к примеру, в виде картотеки или компьютерных файлов или БД. |
|
|
Документ |
Обозначает любой вид документов. |
При построении диаграмм EPCнужно следовать следующим правилам: 1) каждая функция инициируется событием (или несколькими событиями) и завершается событием (или несколькими событиями); 2) каждая функция должна иметь входную и выходную информацию; 3) у каждой функции должно быть ответственное лицо за её выполнение. Ниже приведён пример (рисунок 3.9) блока из которого состоит (строится) вся модельEPC.
Рисунок 3.10 – Блок, из которого строится модельEPC
Пример диаграмм цепочек, управляемых событиями представлен на рисунках 3.10-3.14. Эти диаграммы раскрывают (детально описывают) процессы изображенные на рисунке 3.8.
Рисунок 3.11 – Согласование нагрузки и ответственности на кафедрах
Рисунок 3.12 – Согласование нагрузки и ответственности на кафедрах (продолжение)
Рисунок 3.13 – Промежуточный контроль успеваемости студентов
Рисунок 3.14 – Промежуточный контроль успеваемости студентов (продолжение)
Рисунок 3.15 – Текущий контроль успеваемости студентов