Оглавление
1. Введение. 7
2. Анализ проблемы. Постановка задачи. 7
2.1. Введение. 8
2.2. Описание примера. 9
2.3. Составление списка заинтересованных лиц. 9
2.4. Анкетирование и проведение интервью.. 10
2.5. Список потребностей заинтересованных лиц. 14
2.6. Задания. 14
2.7. Контрольные вопросы.. 14
3. Моделирование объекта автоматизации. 15
3.1. Введение. 15
3.2. Введение в методологию ARIS. 15
3.3. Описание инструмента ARIS. Начало работы.. 18
3.4. Построение организационной модели. 20
3.5. Построение диаграммы цепочек добавленного качества. 23
3.6. Построение eEPC модели. 25
3.7. Описание объектов автоматизации. 31
3.8. Задания. 31
3.9. Контрольные вопросы.. 31
4. Разработка модели вариантов использования и их спецификаций. 32
4.1. Введение. 32
4.2. Разработка модели вариантов использования. 33
4.2.1. Модель вариантов использования. 33
4.2.2. Построение модели вариантов использования. 35
4.3. Спецификация вариантов использования. 38
4.3.1. Основной поток. 39
4.3.2. Альтернативные потоки. 39
4.3.3. Специальные требования. 40
4.4. Пример спецификации варианта использования. 41
4.4.1. Краткое описание. 41
4.4.2. Предварительные условия. 41
4.5. Задания. 45
4.6. Контрольные вопросы.. 45
5. Оформление технического задания в соответствии с ГОСТ 34.602-89. 46
5.1. Введение. 46
5.2. Общие сведения. 46
5.2.1. Требования к содержимому раздела. 46
5.2.2. Пример написания раздела. 47
5.3. Назначение и цели создания (развития) системы.. 49
5.3.1. Требования к содержимому раздела. 49
5.3.2. Пример написания раздела. 50
5.4. Характеристики объекта автоматизации. 51
5.4.1. Требования к содержимому раздела. 51
5.4.2. Пример написания раздела. 51
5.5. Требования к системе. 55
5.5.1. Требования к содержимому раздела. 55
5.5.2. Пример написания раздела. 56
5.6. Состав и содержание работ по созданию системы.. 60
5.6.1. Требования к содержимому раздела. 60
5.6.2. Пример написания раздела. 61
5.7. Порядок контроля и приемки системы.. 62
5.7.1. Требования к содержимому раздела. 62
5.7.2. Пример написания раздела. 62
5.8. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. 63
5.8.1. Требования к содержимому раздела. 63
5.8.2. Пример написания раздела. 63
5.9. Требования к документированию.. 66
5.9.1. Требования к содержимому раздела. 66
5.9.2. Пример написания раздела. 66
5.10. Источники разработки. 68
5.11. Правила оформления. 68
5.12. Задание. 69
5.13. Контрольные вопросы.. 69
6. Реализация архитектуры на базе объектно-реляционного отображения с типизированными объектами. 69
6.1. Введение. 69
6.1.1. Трёхслойная архитектура на базе объектно-реляционного отображения с типизированными объектами. 69
6.1.2. Бизнес-логика. 70
6.1.3. Объектно-реляционное отображение. 71
6.1.4. Структура БД.. 74
6.2. Создание проекта в Borland Developer Studio. 75
6.3. Добавление нового модуля в проект. 76
6.4. Создание классов с помощью диаграммы UML. 77
6.4.1. Добавление полей. 77
6.4.2. Добавление свойств. 78
6.4.3. Добавление процедуры.. 78
6.4.4. Добавление функции. 78
6.4.5. Создание отношений между классами. 79
6.4.6. Пример создания классов. 80
6.5. Невизуальные компоненты интерфейса используемые в примере. 83
6.5.1. TimageList 83
6.5.2. TActionManager 83
6.6. Визуальные компоненты используемые в примере. 85
6.6.1. TBitBtn. 85
6.6.2. TDBGrid. 85
6.6.3. TLabel 85
6.6.4. TEdit 86
6.6.5. TcomboBox. 86
6.6.6. TPageControl 86
6.6.7. TPanel 87
6.7. Пример разработки интерфейса. 87
6.7.1. Главная форма. 88
6.7.2. Форма редактирования параметров студента. 90
6.7.3. Форма редактирования книг. 91
6.7.4. Форма отображения списка книг. 91
6.7.5. Подключение классов. 92
6.7.6. Сохранение проекта. 96
6.8. Задание. 96
6.9. Контрольные вопросы.. 97
7. Реализация архитектуры на базе объектно-реляционного отображения с не типизированными объектами. 97
7.1. Введение. 97
7.1.1. Трёхслойная архитектура на базе объектно-реляционного отображения с не типизированными объектами. 97
7.1.2. Шаблоны проектирования. 98
7.2. Применение шаблона Information Expert 106
7.3. Применение шаблона Creator 106
7.4. Использование шаблона High Cohesion. 107
7.5. Применение шаблона Controller 107
7.6. Задание. 110
7.7. Контрольные вопросы.. 110
8. Разработка простого MDA-приложения. 110
8.1. Введение в технологию MDA.. 110
8.1.1. Архитектура, управляемая моделью MDA.. 110
8.1.2. Технология ECO.. 112
8.1.3. Язык объектных ограничений OCL. 113
8.1.4. MDI-контейнеры.. 114
8.2. Создание простого MDA-приложения. 114
8.2.1. Основные этапы разработки приложения. 115
8.2.2. Обзор возможностей Borland Developer Studio 2006 для разработки MDA-приложения. 115
8.2.3. Создание модели UML. 118
8.2.4. Создание БД и настройка ECO компонент. 120
8.2.5. Создание интерфейса. 123
8.2.6. Связывание интерфейса с моделью.. 126
8.2.7. Создание логики на OCL. 129
8.3. Задания. 133
8.4. Контрольные вопросы.. 133
9. Разработка MDA-приложения с использованием машин состояний. 133
9.1. Введение. 133
9.1.1. Автоматы.. 133
9.1.2. Состояния. 134
9.1.3. Подавтоматы.. 135
9.1.4. Диаграммы состояний. 135
9.2. Создание MDA-приложений с использованием машин состояний. 136
9.2.1. Модификация модели UML. 136
9.2.2. Создание машины состояний. 137
9.2.3. Обновление базы данных. 140
9.2.4. Модификация пользовательского интерфейса. 141
9.2.5. Связывание интерфейса с моделью.. 142
9.2.6. Применение автоформ. 143
9.2.7. Расширение пользовательского интерфейса. 145
9.3. Задания. 147
9.4. Контрольные вопросы.. 147
10. Расширенные возможности разработки MDA-приложений. 148
10.1. Создание MDA-приложения с расширенными возможностями. 148
10.2. Модификация модели UML. 148
10.3. Программное добавление объекта. 149
10.4. Программное удаление объекта. 154
10.5. Программное редактирование объекта. 156
10.6. Работа со справочником. 160
10.7. Поиск объектов. 164
10.8. Задания. 166
10.9. Контрольные вопросы.. 166
Заключение. 167
Библиографический список. 167
Введение
Программная инженерия на сегодняшний день является развивающимся направлением. В этой отрасли темпы развития, а, следовательно, и изменения очень велики. С каждым годом появляются новые методы, новые методики, новые технологи и автоматизированные средства, поддерживающие эти технологии (CASE).
Большинство крупных компаний, разрабатывающих программное обеспечение, создают собственные технологии разработки, опираясь на существующие стандарты, применяют их в своей повседневной деятельности и некоторые из них создают готовые решения для применения в бизнесе. Примерами таких технологий можно назвать RUP (Rational unified process) компании IBM Rational и MSF (Microsoft Solutions Framework) компании Microsoft.
В данном пособии описываются лабораторные работы, позволяющие понять содержание процесса разработки программных систем через поэтапное выполнения основных задач. Для описания поэтапной разработки за основу был взят классический жизненный цикл.
Технологии разработки программного обеспечения условно можно разделить на три класса:
1) Технологии программирования. Эти технологии охватывают область языков программирования (специализированные языки, процедурные языки, объектно-ориентированные языки, и т.д.), средств разработки, платформы (MS frame work dotNET, J2EE, и т.д.), предметно-ориентированные среды программирования (IBM Lotus, 1C, и т.д.).
2) Технологии разработки определённых классов систем. Все разрабатываемые системы могут быть разделены на классы, требующие определённого подхода к разработке. Так, например, можно выделить следующие классы систем: системы, автоматизирующие организационные процессы; системы, автоматизирующие проектную деятельность и технологические процессы (CAE, CAD, CAM и т.д.); системы реального времени; операционные системы; средства разработки программного обеспечения; драйверы и т.д.
3) Технологии организации и поддержки процесса разработки. Эти технологии направлены на решения одной очень сложной и важной задачи – минимизации всех затрат на разработку программного обеспечения с одновременным обеспечением надлежащего качества программной системы.
В данном практикуме технология организации и поддержки процесса разработки рассматривается на примере разработки программных систем, относящихся к классу систем, автоматизирующих организационные процессы.
Анализ проблемы. Постановка задачи
Цель работы:
– получить навыки работы с реальными заказчиками программных систем;
– научиться идентифицировать заинтересованных лиц и проводить с ними интервью;
– научиться анализировать и перерабатывать полученный материал;
– научиться формулировать проблему, актуальность и потребности заинтересованных лиц.
Введение
Цикл лабораторных работ разработан в соответствии с классическим жизненным циклом, корни которого уходят в период 70-х годов. Жизненным циклом ПО называют период от момента появления идеи создания некоторого программного обеспечения до момента завершения его поддержки фирмой-разработчиком или фирмой, выполнявшей сопровождение. В настоящее время существует большое количество жизненных циклов ПО, их модификаций и технологий разработки ПО, в том числе и стандарты (ГОСТ Р ИСО/МЭК 12207-99).
Для выполнения цикла лабораторных работ за основу был взят упрощённый жизненный цикл, включающие в себя основные содержательные этапы разработки программного обеспечения (см. Рисунок 1.1).
Рисунок 1.1 – Классический жизненный цикл ПО
Каждый из этапов разработки ПО имеет входные данные, необходимые для выполнения работ на данном этапе и выходные, которые являются результатом выполняемых работ.
На этапе анализа проблемы проводится анализ предметной области, для которой разрабатывается ПО, с целью: 1) определения границ или контура системы; 2) описания объектов автоматизации и/или формализации знаний об этих объектах; 3) выявления или определения потребностей заказчика ПО.
Анализ предметной области можно проводить, например, основываясь на теории системного анализа и использовать предложенные в ней методы.
Исходными данными для этапа системного анализа являются: 1) регламенты и должностные инструкции по работе отделов и сотрудников этих отделов; 2) анкеты опроса заинтересованных лиц; 3) записи интервью с заинтересованными лицами; 4) другие документы, имеющие отношение к исследуемому объекту.
Выходными данными или результатом этапа системного анализа является: 1) перечень заинтересованных лиц; 2) список потребностей заинтересованных лиц в разрабатываемом ПО; 3) описание объектов автоматизации; 4) модель объектов автоматизации или предметной области.
Описание примера
В данном разделе будет сформулирована задача, решением которой является разработка программного обеспечения.
И так, в результате вступления России в Болонский процесс была инициирована реформа высшего профессионального образования. В результате этой реформы Министерством образования и науки была разработана программа по переводу традиционной системы оценки успеваемости студентов в систему зачетных единиц (кредитов). Это являлось одним из условий вступления в болонский процесс, что объясняется необходимостью унификации систем высшего образования с целью обеспечения студентов единым образовательным пространством в тех странах, которые уже вступили в болонский процесс.
В рамках этой программы все вузы страны должны к установленной дате перейти на новую систему. Красноярский государственный политехнический университет (КГПУ) начал решать поставленную перед ним задачу поэтапно. Одной из задач перехода на новую систему в КГПУ является автоматизация процесса учета текущей успеваемости студентов и учета промежуточных аттестаций с целью: унификации этого процесса на всех кафедрах и факультетах вуза; реализации возможности автоматизированного формирования отчетов; публикации на сайте вуза рейтингов студентов.
