- •Проектирование информационных систем
- •Для студентов пятого курса специальности 071900 – Информационные системы в технике и технологиях
- •1Введение
- •1.1Классификация методов проектирования
- •1.2Виды информационных систем
- •1.2.1Системы обработки данных
- •1.2.2Системы управления
- •1.2.3Офисные системы
- •1.2.4Системы поддержки принятия решений
- •1.2.5Экспертные системы
- •1.3Структура информационной системы
- •1.4Архитектура системы
- •1.4.1Общее понятие системной архитектуры
- •1.4.2Архитектурные уровни
- •2Проектирование информационных систем на основе объектно-ориентированного подхода
- •2.1Представления системы
- •2.2Uml-модель информационной системы
- •2.3Представления системы в rational rose
- •2.4Проектирование в rational rose
- •2.5Моделирование предметной области
- •2.5.1Моделирование организационной структуры
- •2.5.2Моделирование бизнес-процессов
- •2.5.3Моделирование бизнес-функций
- •2.5.4Моделирование документов и бизнес-сущностей
- •2.6Использование бизнес-модели на этапах разработки
- •2.7Диаграмма вариантов использования – use case diagram
- •2.7.1Обозначения в диаграмме вариантов использования
- •2.7.2Идентификация актёров и вариантов использования
- •2.7.3Категории вариантов использования
- •2.7.4Абстрактные варианты использования
- •2.7.5Конкретные варианты использования
- •2.7.6Запись актёров и вариантов использования
- •2.7.7.4Альтернативные потоки событий
- •2.7.7.5Постусловия варианта использования
- •2.8Диаграммы взаимодействия – interaction diagrams
- •2.8.1Идентификация объектов
- •2.8.2Использование диаграмм взаимодействия
- •2.8.3Диаграмма последовательности – Sequence diagram
- •2.8.4Подход к разработке диаграммы последовательности
- •2.8.5Диаграмма кооперации – Collaboration Diagram
- •2.9Диаграммы классов – class diagrams
- •2.9.1Классы
- •2.9.1.1Параметризованный класс – parameterized class
- •2.9.1.2Класс-наполнитель – instantiated class
- •2.9.1.3Утилита - utility
- •2.9.1.4Метакласс – metaclass
- •2.9.1.5Абстрактный класс – abstract class
- •2.9.2Стереотип класса
- •2.9.2.1Пограничные классы – boundary classes
- •2.9.2.2Управляющие классы – control classes
- •2.9.2.3Классы-сущности – entity classes
- •2.9.3Видимость класса – Visibility
- •2.9.4Пакеты – packages
- •2.9.5Диаграммы классов
- •2.9.6Создание диаграммы классов
- •2.9.6.1Идентификация программных классов
- •2.9.6.2Идентификация атрибутов
- •2.9.6.3Идентификация операций
- •2.9.6.4Идентификация ассоциаций
- •2.10Диаграммы состояний – statechart diagrams
- •2.10.1Основные сведения о диаграмме состояний
- •2.10.2События
- •2.10.2.1Сигнал
- •2.10.2.2С обытие вызова
- •2.10.2.3События времени и изменения
- •2.10.3Правила построения диаграммы состояний
- •2.10.4Диаграммы состояний для вариантов использования
- •2.10.5Классы и типы для диаграммы состояний
- •2.11Диаграммы компонентов – component diagrams
- •2.11.1Компоненты
- •2.11.2Основные виды компонентов
- •2.11.3Основные стереотипы компонентов
- •2.11.4Диаграмма компонентов
- •2.11.5Правила построения диаграммы компонентов
- •2.12Диаграмма развёртывания – deployment diagram
- •2.12.1Узлы - Nodes
- •2.12.2Соединения
- •2.12.3Диаграмма развёртывания
- •2.12.4Использование диаграмм развёртывания
- •2.12.4.1Встроенные системы
- •2.12.4.2Клиент-серверные системы
- •2.12.4.3Распределённые системы
- •3Системное проектирование сложных систем
- •3.1Цель и задачи системного проектирования
- •3.1.1Цель системного проектирования
- •3.1.2Задачи системного проектирования
- •3.2Структура и содержание документов системного проекта
- •3.2.1Техническое задание
- •3.2.2Описание архитектуры программного и информационного обеспечения системы
- •3.2.3Описание жизненного цикла, технологии и инструментария проектирования программного средства и базы данных
- •3.2.4Планы управления рабочими проектами
- •3.2.5Техническое задание на рабочее проектирование
- •3.2.6Системный проект
- •3.2.7Акт завершения работ и утверждения системного проекта
- •3.2.8Основные компоненты договора на детальное проектирование
- •3.3Работы и нормативные документы по системному проектированию информационной системы
- •3.4Стандарты в жизенном цикле информационных систем
- •3.4.1Нормативно-методическое обеспечение
- •3.4.2Рекомендуемые стандарты
- •4Проектирование систем как часть жизненного цикла
- •4.1Стадии и этапы жизненного цикла
- •4.1.1Исследование
- •4.1.2Проработка
- •4.1.3Создание
- •4.1.4Переходный период
- •4.2Процесс проектирования
- •4.2.1Концептуальное проектирование
- •4.2.2Логическое проектирование
- •4.2.3Физическое проектирование
2.9.6.3Идентификация операций
Операция – реализация услуги, которая может быть запрошена у любого объекта класса.
Начинать идентификацию операций класса следует после разработки диаграмм взаимодействия и выделения классов системы.
Большинство операций каждого класса можно определить путём анализа диаграмм взаимодействия модели анализа. Если сообщение calcForMe передаётся объекту класса Resource, то в классе Resource должна быть определена операция calcForMe ( ).
Существует четыре различных типа операций:
Операции реализации – Implementor operations. Данные операции реализуют некоторую бизнес-функцию. Почти все эти операции соотносятся с сообщениями на диаграмме последовательности. Важно, чтобы каждую операцию можно было проследить до требований: операция – сообщение – описание потока событий – вариант использования – требования.
Операции управления – Manager operations. Управляют созданием и разрушением объектов. В виду того, что при генерации кода конструкторы и деструкторы создаются автоматически, на диаграмме классов эти операции не отображаются.
Операции доступа – Access operations. Атрибуты класса чаще всего бывают закрытыми или защищёнными. Тем не менее, другие классы иногда должны просматривать или даже изменять их значения. Для этого и предназначены операции доступа – Get…, Set…. Эти операции точно так же не отображаются на диаграмме классов, потому что генерируются автоматически для каждого атрибута класса.
Вспомогательные операции – Helper operations. Эти операции предназначены для выполнения ответственностей класса, о которых ничего не должны знать другие классы. Это закрытые и защищённые операции класса. Вспомогательные операции можно обнаружить на диаграммах взаимодействия.
В спецификации операции необходимо задать следующую информацию:
Имя операции. Должно отражать смысл операции.
Параметры операции. Список получаемых операцией входных данных. В спецификации операции можно дополнительно задавать типы аргументов операции, но это не всегда оправданно, так как перегружает модель. Если генерация кода предполагает использование CASE-средства, то следует указывать полную информацию. Если диаграмма классов создаётся для программистов, то можно не указывать дополнительную информацию.
Тип возвращаемого значения. Тип данных результата операции. Используются или встроенные типы, или определённые в модели классы.
Видимость. Операции могут быть общими, закрытыми, защищёнными или пакетными.
В спецификации операции обязательными для заполнения являются следующие разделы:
D ocumentation – следует поместить краткое описание операции.
Postconditions – постусловия. При описании постусловий следует формулировать их в прошедшем времени, чтобы подчеркнуть уже произошедшие изменения, потому что постусловия описывают состояние системы, а не выполнение действия (создан, принял значение, связан с). Для операций следует придерживаться следующих полезных категорий постусловий:
Создание и удаление объекта. Какие новые объекты создаются в системе?
Модификация атрибута. Какие атрибуты новых или существующих объектов должны быть модифицированы (установлены, вычислены, изменены)?
Ф ормирование и разрыв ассоциации. Какие ассоциации между новыми или существующими объектами должны быть установлены или разорваны?
У всех операций есть постусловия. На этапе проектирования постусловия являются важной частью создания модели приложения. По возможности, следует достаточно подробно описывать постусловия.
Типичными ошибками при спецификации постусловий являются:
запись “Создание объекта Sale.” вместо “Создан объект Sale.”
невключение информации о формировании или разрыве ассоциации.
Preconditions – предусловия. Предусловия – это предположения о состоянии системы до начала операции. Не следует определять множество предусловий (при желании для каждой операции их можно найти очень много). Целесообразно указать факторы, существование которых необходимо проверять до начала выполнения операции.
Н е у всех операций бывают предусловия.
Операции для варианта использования Покупка товара системы POST:
Операция |
Комментарий |
Класс |
addSale ( ) |
Зафиксировать начало ввода наименований товара для текущей покупки. Отобразить дату и время покупки. |
POST |
endSale ( ) |
Зафиксировать окончание ввода наименований товара и отобразить общую стоимость покупки. |
|
enterItem ( UPC, QTY ) |
Ввести (записать) информацию о продаже товара и добавить её к общей информации о текущей продаже. Отобразить описание товара и его цену. |
|
makePayment ( AMOUNT, TOTAL ) |
Ввести информацию о платеже, вычислить баланс и выдать чек. |
Sale |
total ( SUBTOTAL ) |
Вычислить общую стоимость текущей покупки. |
|
subtotal ( ) |
Вычислить промежуточную стоимость элемента покупки. |
SaleLineItem |