
- •Учебник
- •Оглавление
- •Глава 1. Стандарты и профили в области информационных систем 5
- •Глава 2. Методологические основы проектирования информационных систем 33
- •Глава 3. Проектирование информационных систем 80
- •3.2.1 Основные понятия 85
- •Глава 4. Практикум по системному проектированию информационных систем 119
- •Глава 1. Стандарты и профили в области информационных систем
- •1.1. Основные этапы автоматизации информационных процессов
- •Вопросы для самопроверки
- •1.2. Подходы к построению и проектированию информационных систем
- •Вопросы для самопроверки
- •1.3. Стандарты в области информационных систем
- •1.3.1. Международный стандарт iso/iec 12207: 1995-08-01
- •1.3.2 Стандарты комплекса гост34
- •1.3.3 Методика Oracle cdm
- •Вопросы для самопроверки
- •1.4. Профили в области информационных систем
- •1.4.1. Понятие профиля ис. Цели и принципы формирования профилей информационных систем
- •1.4.2. Структура и содержание профилей информационных систем
- •1.4.3. Процессы формирования, развития и применения профилей информационных систем
- •Вопросы для самопроверки
- •Библиографический список
- •Глава 2. Методологические основы проектирования информационных систем
- •2.1. Основные понятия
- •Вопросы для самопроверки
- •2.2. Методологические подходы к проектированию информационных систем
- •Вопросы для самопроверки
- •2.3. Методология структурного анализа и проектирования информационных систем
- •2.3.1. Основные понятия idef0
- •Вопросы для самопроверки
- •2.3.2. Основные понятия методологии sadt
- •Вопросы для самопроверки
- •2.3.3. Bpwin – инструмент реализации методологий структурного анализа и проектирования
- •Вопросы для самопроверки
- •2.4. Методология объектно-ориентированного анализа и проектирования информационных систем
- •2.4.1. Сущность объектно-ориентированного подхода к анализу и проектированию ис
- •Вопросы для самопроверки
- •2.4.2.1. Диаграммы вариантов использования (модели прецедентов)
- •2.4.2.2. Диаграммы классов
- •2.4.2.3. Диаграммы взаимодействия
- •2.4.3. Методология Rational Unified Process (rup)
- •Вопросы для самопроверки
- •Библиографический список
- •Глава 3. Проектирование информационных систем
- •3.1 Модели информационных систем
- •Вопросы для самопроверки
- •3.2 Методологии проектирования информационных систем
- •3.2.1 Основные понятия
- •3.2.2 Методологии моделирования бизнес-процессов
- •3.2.3 Методология моделирования информационных систем
- •Вопросы для самопроверки
- •3.3 Методика системного проектирования
- •3.3.1 Предпроектное обследование
- •3.3.2. Создание концепции новой ис
- •3.3.3. Разработка системного проекта ис
- •Вопросы для самопроверки
- •Библиографический список
- •Глава 4. Практикум по системному проектированию информационных систем
- •Инструментальная поддержка основных этапов жизненного цикла ис линейками продуктов AllFusion и Rational
- •4.1 Методологические основы проектирования ис
- •4.1.1 Постановка задачи. Определение рабочей области моделирования
- •4.1.2 Моделирование бизнес-процессов с использованием методологии sadt и инструментария AllFusion Modelling Suite
- •4.1.3 Моделирование бизнес-процессов с использованием методологии rup и инструментария Rational Suite
- •4.1.4 Моделирование потоков данных с использованием методологии sadt и инструментария AllFusion Modeling Suite
- •4.1.5 Моделирование потоков работ с использованием методологии sadt и инструментария AllFusion Modeling Suite
- •4.1.6 Моделирование потоков работ с использованием методологии rup и инструментария Rational Suite
- •4.1.7 Создание дополнительных моделей предметной области с использованием инструментария AllFusion Modeling Suite
- •4.2 Основы системного проектирования ис
- •4.2.1 Предпроектное обследование
- •4.2.1.1 Сбор и анализ документов, описывающих процессы предметной области
- •4.2.1.2 Создание модели as-is бизнес-процессов деятельности компании
- •4.2.1.3 Создание модели информационных потоков предметной области компании
- •4.2.1.4. Определение «узких» мест и выработка предложений по усовершенствованию ис компании
- •4.2.2 Создание концепции новой ис
- •4.2.2.1 Формирование требований к новой ис
- •1. Введение
- •2. Общее описание
- •3. Функции системы
- •4. Требования к внешнему интерфейсу
- •5. Другие нефункциональные требования
- •4.2.2.2 Создание прототипов новой ис
- •4.2.3 Создание технического задания на проект ис
- •Библиографический список
- •Глоссарий
2.4.2.2. Диаграммы классов
Прежде чем определить диаграммы классов введем несколько понятий.
Объект (object) - это некая сущность реального мира или концептуальная сущность. Объект может быть чем-то конкретным, например грузовик Джо или мой компьютер, или концептуальным, как, например, химический процесс, банковская операция, торговый заказ, кредитная история или ставка прибыли. Объектом называется концепция, абстракция или вещь с четко определенными границами и значением для системы. Каждый объект в системе имеет три характеристики: состояние, поведение и индивидуальность.
Состоянием (state) объекта называется одно из условий, в которых он может находиться. Состояние системы обычно меняется во времени и определяется набором свойств, называемых атрибутами (attribute), значений свойств и отношений между объектами. Например, объект учебный курс (CourseOffering) в системе регистрации учебных курсов может находиться в одном из двух состояний: открыт для записи или закрыт для записи. Если количество студентов, зарегистрировавшихся на курс, меньше десяти, запись на курс продолжается. После регистрации десятого студента она прекращается.
Поведение (behavior) определяет, как объект реагирует на запросы других объектов и что может делать сам объект. Поведение реализуется с помощью набора операций (operation) для объекта. В системе регистрации курсов объект учебный курс может иметь операции добавить студента и удалить студента.
Индивидуальность (identity) означает, что каждый объект уникален, даже если его состояние идентично состоянию другого объекта. Например: Алгебра 101, секция 1 и Алгебра 101, секция 2 - два объекта в системе регистрации курсов. Хотя они оба являются учебными курсами, каждый из них уникален.
Класс (class) - это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.
Класс-сущность (entity class) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы. Такие классы обычно не зависят от окружения, то есть они нечувствительны к взаимодействию окружающей среды с системой. Следовательно, они не зависят от приложения и могут использоваться в различных приложениях.
Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы предоставляют интерфейс для пользователя или другой системы (то есть для актера). Они составляют внешне зависимую часть системы и используются для моделирования интерфейсов системы. Граничные классы также используются для обеспечения связи с другими системами.
Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, ревизующих заложенное в них поведение. Управляющие классы можно представить как классы, «исполняющие» прецедент и определяющие его динамику. Они обычно зависят от приложения.
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграммы классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов. Например, счет Джо - это объект. Типом такого объекта можно считать счет вообще, то есть "Счет" (account) - это класс. Классы содержат данные и поведение (действия), влияющее на эти данные. Класс Account содержит идентификационный номер клиента и действия, проверяющие его. На диаграмме классов класс создается для каждого типа объектов из диаграмм последовательности или кооперативных диаграмм. Диаграмма классов для варианта использования "Снять деньги" показана на рис. 21.
рис. 21 Диаграмма классов для варианта использования "Снять деньги"
На этой диаграмме классов показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса:
Card Reader (устройство для чтения карточек). Account (счет), ATM Screen (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй - его атрибуты. Атрибут - это некоторая информация, характеризующая класс. Например, у класса Account (счет) имеется три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). У класса Account имеется четыре операции: Open (открыть). Withdraw Funds (снять деньги), Deduct Funds (вычесть сумму денег из счета) и Verify Funds (проверить наличие денег).
Связывающие классы линии отражают взаимодействие между классами. Так, класс Account связан с классом ATM Screen (экран ATM), потому что они непосредственно сообщаются и взаимодействуют друг с другом. Класс Card Reader (устройство для чтения карточек) не связан с классом Cash Dispenser (кассовый аппарат), поскольку они не сообщаются друг с другом непосредственно. Обратите внимание, что слева от некоторых атрибутов и операций имеются маленькие значки в виде висячего замка. Они указывают, что атрибут или операция класса закрыты (private). Доступ к закрытым атрибутам или операциям возможен только из содержащего их класса. Account Number, PIN и Balance являются закрытыми атрибутами класса Account. Кроме того, операции Deduct Funds и Verify Funds также закрыты для этого класса.