- •Тема 1. Проектирование ис
- •Этапы развития ис
- •1.2. Классификация рынка современных ис
- •1.3. Проектирование ис как формализационный процесс
- •2.1.1. Основные процессы
- •2.1.2. Вспомогательные процессы
- •2.1.3. Организационные процессы
- •Вопросы.
- •Этапы развития ис.
- •Понятие программной инженерии и этапы ее развития.
- •Тема 2. Понятие жц по
- •2.1. Понятие жц по. Процессы жц по
- •2.1.4. Взаимосвязь между процессами
- •2.2. Модели и стадии жц по
- •Вопросы
- •Тема 3. Организация разработки по ис
- •3.1. Внутренняя и внешняя деятельность
- •3.2. Четыре фазы разработки по ис (во внешней деятельности)
- •3.3. Задачи разработки по ис
- •Вопросы для самоконтроля
- •Тема 4. Внутренняя (мыслительная) деятельность
- •4.1. Компетенция инженера
- •4.2. Состав, сложность задач проблемы и компетентность инженера
- •4.3. Связь понятия компетенция и умение
- •Вопросы для самоконтроля
- •Тема 5. Структурный подход к проектированию
- •5.1. Сущность структурного подхода
- •5.1.1 Подход к решению проблемы сложности больших систем
- •5.1.2. Структурный подход к разработке по
- •5.2. Методология функционального моделирования idef0
- •5.2.1. Сущность методологии idefo
- •5.2.2. Синтаксис и семантика моделей idefo
- •5.2.3. Типы связей между функциями
- •5.2.4. Построение моделей idef0
- •5.3. Методология описания бизнес-процессов idef3
- •5.3.1. Сущность методологии idef3
- •5.3.2. Синтаксис и семантика моделей idef3
- •5.3.3. Требования 1def3 к описанию бизнес-процессов
- •5.4. Взаимосвязь моделей idefo и idef3
- •5.5.Структурный анализ потоков данных
- •5.5.1.Сущность структурного анализа потоков данных
- •5.5.2. Синтаксис и семантика диаграмм потоков данных
- •5.5.3. Построение диаграмм потоков данных
- •5.6. Сравнительный анализ idefo-моделей и диаграмм потоков данных
- •5.7. Рекомендации по применению методологий функционального моделирования
- •5.8. Моделирование данных
- •5.8.1. Основные понятия
- •5.8.2. Основы методологии idef1x
- •Вопросы для самоконтроля
- •Тема 6. Объектно-ориентированный подход к проектированию
- •6.1.Сущность объектно-ориентированного подхода
- •6.2. Диаграммы uml
- •6.3. Синтаксис и семантика основных объектов uml
- •6.3.1. Диаграммы прецедентов
- •6.3.2. Диаграммы классов
- •6.3.3. Диаграммы последовательностей
- •6.3.4. Диаграммы коммуникаций
- •6.3.5. Диаграммы состояний
- •6.3.6. Диаграммы деятельности
- •6.3.7. Диаграммы компонентов
- •6.3.8. Диаграммы развертывания
- •6.4. Рекомендации по применению uml
- •Вопросы для самоконтроля
- •Тема 7. Проектирование бд
- •7.1. Особенности проектирования хранилищ данных
- •7.2. Особенности проектирования клиент-серверных ис
- •7.3.Интерфейсы доступа к бд
- •7.3.1. Odbc - открытый интерфейс доступа к бд
- •7.3.2.Объектная модель ole db
- •7.4. Классы бд
- •7.4.1. Документографические и документальные бд
- •7.4.2. Бд о продукции
- •7.4.3. Бд экономической и конъюнктурной информации
- •7.4.4.Фактографические базы социальных данных
- •7.4.5. Бд транспортных систем страны
- •7.4.6. Справочные базы для населения и организаций
- •7.4.7. Ресурсные бд
- •7.4.8. Фактографические базы научных данных
- •7.4.9. Фактографические бд в области культуры и искусства
- •7.4.10. Лингвистические бд
- •Вопросы для самоконтроля
6.2. Диаграммы uml
UML 2.0 описывает 13 официальных типов диаграмм, перечисленных в табл. 6.1. Классификация диаграмм приведена на рис. 6.1. Допустимо присутствие элементов диаграммы одного типа в другой диаграмме.
Таблица 6.1. Официальные типы диаграмм UML
№ |
Диаграмма |
Назначение диаграммы |
1 |
Классов |
Описывает классы и статические отношения между ними |
2 |
Последовательность |
Описывает взаимодействие между объектами (акцент на последовательность) |
3 |
Объектов |
Показывает взаимосвязи между объектами |
4 |
Пакетов |
Объединяет классы в группы |
5 |
Развертывания |
Показывает, на каком физическом оборудовании запускается та или иная часть ПО |
6 |
Прецедентов (использования) |
Определяет функциональные требования к ПО |
7 |
Состояний (конечных автоматов) |
Показывает как события изменяют объект в течение его жизни |
8 |
Деятельности |
Описывает логику процедур, бизнес-процессов и потоков работ |
9 |
Коопераций |
Описывает взаимодействие между объектами (акцент на обмене данными) |
10 |
Составных структур |
Разбивает класс на составляющие |
11 |
Компонентов |
Структура и взаимосвязи между компонентами, т.е. элементами ПО, которые независимо друг от друга можно обновить или купить |
12 |
Обзора взаимодействий |
Комбинация диаграммы последовательности и диаграммы деятельности |
13 |
Временная |
Описывает взаимодействие между объектами (акцент на временных ограничениях) |
Далее будут рассмотрены основные элементы диаграмм прецедентов, классов, последовательностей, коммуникаций, состояний, деятельности и компонентов.
Рис. 6.1. Классификация диаграмм UML
6.3. Синтаксис и семантика основных объектов uml
Рассматриваются некоторые диаграммы языка объектного моделирования UML.
6.3.1. Диаграммы прецедентов
Диаграммы прецедентов описывают функциональность ИС, которая будет видна пользователям системы. Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:
описывает видимую пользователем функцию;
может представлять различные уровни детализации;
обеспечивает достижение конкретной цели, важной для пользователя.
Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами или актерами. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.
На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, используются связи между прецедентами. Наиболее часто эти связи имеют тип «использование» или «расширение» (рис. 6.2). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.
На рис. 6.2 показано, что при исполнении прецедента «Сформировать заказ» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «Оценить риск сделки» и «Согласовать цену» необходимо выполнить одно и то же действие - рассчитать стоимость заказа.
Рис. 6.2. Связи на диаграммах прецедентов
Прецеденты
представляют собой ценный инструмент
для понимании функциональных требований
к системе. Первый вариант прецедентов
должен составляться на ранней стадии
выполнения проекта. Более подробные
версии прецедентов должны появляться
непосредственно перед реализацией
данного прецедента.
Важно помнить, что прецеденты представляют взгляд на систему со стороны. Поэтому соответствия между прецедентами и классами внутри системы может не быть.
Несмотря на то, что в языке UML ничего не говорится о тексте прецедентов, именно текстовое содержание прецедентов является основной ценностью этой технологии.
Большая опасность прецедентов заключается в том, что разработчики делают их очень сложными и застревают на них.
