- •Тема 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.3.3. Диаграммы последовательностей
Этот вид диаграмм используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Прямоугольники на вертикальных линиях показывают «время жизни» объекта. Линии со стрелками и надписями означают посылку соответствующих сообщений или вызов соответствующих методов у объекта.
На рис. 6.8 представлена диаграмма последовательности обработки заказа. Обработка заказа предполагает следующие действия:
вводятся строки заказа;
по каждой строке проверяется наличие товара;
если запас недостаточен, то оформляется дозаказ недостающего количества товара у генерального поставщика (повторный заказ);
оформляется поставка.
Сообщения появляются в той последовательности, как они показаны на диаграмме – сверху вниз. Если предусматривается отправка сообщения объектом самому себе (самоделегирование), то стрелка начинается и заканчивается на одной «линии жизни».
На диаграмме может быть добавлена управляющая информация: описание условий, при которых посылается сообщение; признак многократной отправки сообщения (* - маркер итерации); признак возврата сообщения и др.
Диаграммы последовательности хороши для представления взаимодействия объектов, но не очень подходят для точного определения поведения.
Если требуется отразить поведение одного объекта в нескольких прецедентах, то лучше применять диаграмму состояний. Если же требуется отразить поведение нескольких объектов в нескольких прецедентах, то лучше применить диаграмму деятельности.
Рис. 6.8. Диаграмма последовательности обработки заказа
6.3.4. Диаграммы коммуникаций
На коммуникационных диаграммах (в UML1 такие диаграммы назывались диаграммами коопераций или кооперативными диаграммами) объекты (или классы) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках одного варианта использования. Временная последовательность сообщений отражается их нумерацией.
На рис. 6.9 представлена коммуникационная диаграмма обработки заказа. Процесс обработки заказа не отличается от процесса, рассмотренного выше (рис. 6.8). В соответствии с правилами UML, необходимо придерживаться вложенной десятичной нумерации. На рис. 6.9 нумерация показывает, что методы «Проверить запас» и «Оформить дозаказ» вызываются из метода «Проверить наличие». Если нет необходимости детализировать уровень вложенности методов, то можно пренебречь правилами UML и использовать линейную нумерацию
Рис. 6.9. Коммуникационная диаграмма прохождения заказа
Коммуникационные диаграммы лучше выбирать, когда надо акцентировать внимание на связях, а более общие диаграммы последовательности удобнее, если требуется подчеркнуть последовательность вызовов.
6.3.5. Диаграммы состояний
Диаграммы состояний используются для описания поведения сложных объектов. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Обычно эти диаграммы используются для описания поведения одного объекта в нескольких прецедентах.
Состояниям соответствуют определенные значения атрибутов объектов. На диаграммах состояния изображаются прямоугольниками. Стрелки представляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта. Имеется также два вида псевдосостояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел.
Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рис. 6.10):
<Событие><Условие></Действие>.
Событие - это описание события, которое может вызвать изменение состояния. Условие - это логическое условие. Переход может быть выполнен только в том случае, если данное условие имеет значение истина. Действие представляет собой описание поведения системы во время выполнения перехода.
Рис. 6.10. Диаграмма состояний
Диаграммы состояний хорошо подходят для описания поведения одного объекта в нескольких прецедентах. Обычно эти диаграммы рисуют только для классов, которые проявляют сложное поведение.
