Реферат: Проектирование информационных систем

Проектирование информационных систем


1. Методы проектирования ИС


1.1. Методы проектирования информационных систем


Индустрия разработки автоматизированных информационных систем управления родилась в 50-х - 60-х годах и к концу века приобрела вполне законченные формы. Материалы данного руководства являются обобщением цикла лекций по Автоматизированным Банковским Системам (АБС) и Автоматизированным системам управления конструкторско-технологическим проектированием (АСУ КТП), читаемым в МГТУ им.Н.Э.Баумана. Не смотря на имеющиеся различия в реализации функциональных модулей данных систем, общие подходы к их разработки во многом схожи, что позволило нам объединить вопросы их проектирования в рамках одного издания.


На рынке автоматизированных систем для крупных корпораций и финансово-промышленных групп на сегодня можно выделить два основных субъекта: это ранок автоматизированных банковских систем (АБС) и рынок корпоративных информационных систем промышленных предприятий. Не смотря на сильную взаимосвязь этих двух рынков систем автоматизации, предлагаемые на них решения пока еще не достаточно интегрированы между собой, чего следует ожидать в недалеком будущем.


В дальнейшем под Автоматизированной Банковской Системой (АБС) будем понимать комплекс аппаратно-программных средств реализующих мультивалютную информационную систему, обеспечивающую современные финансовые и управленческие технологии в режиме реального времени при транзакционной обработке данных.


Под Автоматизированной Информационной Системой промышленного предприятия (АСУ КТП) будем понимать комплекс аппаратно-программных средств реализующих мультикомпонентную информационную систему, обеспечивающую современное управление процессами принятия решений, проектирования, производства и сбыта в режиме реального времени при транзакционной обработке данных.


Как вы видите, оба определения достаточно схожи. На сегодня существования нескольких методов построения автоматизированных информационных систем (АИС), среди которых можно выделить следующие:

1.1.1 Метод "снизу-вверх".


Менталитет российских программистов сформировался именно в крупных вычислительных центрах (ВЦ), основной целью которых было не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Этот подход во многом сохранялся и при автоматизации и сегодня. В условиях постоянно изменяющихся законодательства, правил ведения производственной, финансово-хозяйственной деятельности и бухгалтерского учета руководителю удобно иметь рядом посредника между спущенной сверху новой инструкцией и компьютером. С другой стороны, программистов, зараженных "вирусом самодеятельности", оказалось предостаточно, тем более что за такую работу предлагалось вполне приличное вознаграждение.


Создавая свои отделы и управления автоматизации, предприятия и банки пытались обустроиться своими силами. Однако периодическое "перетряхивание" инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, непрерывная работа программистов по удовлетворению все новых и новых пожеланий отдельных работников и как следствие - недовольство руководителей своими программистами несколько остудило пыл как тех, так и других. Итак, первый подход сводился к проектированию "снизу-вверх". В этом случае, при наличии квалифицированного штата программистов, вполне сносно были автоматизированы отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривалась недостаточно хорошо, особенно в перспективе.

1.1.2. Метод "сверху-вниз".


Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов (для банков это в основном - расчетно-кассовое обслуживание, для промышленных предприятий - автоматизация процессов проектирования и производства, имеется в виду не конкретных станков и т.п., а информационных потоков). Учитывая тот факт, что ядром АИС безусловно является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начали с детальной проработки данной проблемы. Системы были спроектированы "сверху", т.е. в предположении что одна программа должна удовлетворять потребности всех пользователей.


Сама идея использования "одной программы для всех" резко ограничила возможности разработчиков в структуре информационных множеств базы данных, использовании вариантов экранных форм, алгоритмов расчета и, следовательно, лишила возможности принципиально расширить круг решаемых задач - автоматизировать повседневную деятельность каждого работника. Заложенные "сверху" жесткие рамки ("общие для всех") ограничивали возможности таких систем по ведению глубокого, часто специфического аналитического и производственно - технологического учета. Работники проводили эту работу вручную, а результаты вводили в компьютер. При этом интерфейс каждого рабочего места не мог быть определен функциями, возложенными на пользователя, и принятой технологией работы. Стало очевидно, что для успешной реализации задачи полной автоматизации банка следует изменить идеологию построения АИС.


^ 2. Структурно-функциональный подход проектирования ИС: функциональная модель ИС (SADT), моделирование потоков данных (DFD), моделирование данных (ER)


Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:

графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;

строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.


Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.

Состав функциональной модели


Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу(рис.1.).


Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.





Рис 1. Функциональный блок и интерфейсные дуги


На рисунке 2, где приведены четыре диаграммы и их взаимосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.

Иерархия диаграмм


Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также представляют полный набор внешних интерфейсов системы в целом.


Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.


Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.


Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.


Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы.







Рис.2. Структура SADT-модели. Декомпозиция диаграмм


На рисунках 3 - 5 представлены различные варианты выполнения функций и соединения дуг с блоками.





Рис. 3. Одновременное выполнение





Рис. 4. Соответствие должно быть полным и непротиворечивым


Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.


На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. (рисунок 5).





Рис. 5. Пример обратной связи


Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рисунок 6).





Рис. 6. Пример механизма


Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм.


Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7 показано типичное дерево диаграмм.





Рис. 7. Иерархия диаграмм


Типы связей между функциями


Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания:





Ниже каждый тип связи кратко определен и проиллюстрирован с помощью типичного примера из SADT.


(0) Тип случайной связности: наименее желательный.


Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая показан на рисунке 8.





Рис. 8. Случайная связность


(1) Тип логической связности. Логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается.


(2) Тип временной связности. Связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.


(3) Тип процедурной связности. Процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на рисунке 9.





Рис. 9. Процедурная связность


(4) Тип коммуникационной связности. Диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные (рисунок 10).


(5) Тип последовательной связности. На диаграммах, имеющих последовательные связи, выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является более тесной, чем на рассмотренных выше уровнях связок, поскольку моделируются причинно-следственные зависимости (рисунок 11).


(6) Тип функциональной связности. Диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности. Одним из способов определения функционально-связанных диаграмм является рассмотрение двух блоков, связанных через управляющие дуги, как показано на рисунке 12.




В математических терминах необходимое условие для простейшего типа функциональной связности, показанной на рисунке 12, имеет следующий вид:

C = g(B) = g(f(A))


Ниже в таблице представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4-6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.




^ Структурный анализ потоков данных DFD


В отличии от стрелок в IDEF0, которые иллюстрируют отношения, стрелки DFD показывают как объекты реально перемещаются от одного действия к другому. Это представление потока вместе с хранилищами данных и внешними сущностями обеспечивает отражение в DFD моделях таких физических характеристик системы как движение объектов, хранение объектов, источники и потребители объектов (внешние сущности).


В DFD диаграммах преобладают имена существительные. Контекстная DFD диаграмма часто состоит из одного функционального блока и нескольких внешних сущностей.


^ Функциональные блоки


Функциональный блок DFD моделирует некоторую функцию, которая преобразует какое-либо сырье в какую-либо продукцию.





Функциональные блоки имеют входы и выходы, но не имеют управления и механизма исполнения.


^ Внешние сущности


Они обеспечивают необходимые входы для системы, являются приемниками для ее выхода. Одна внешняя сущность может одновременно представлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель).





^ Стрелки (потоки данных)


Стрелки описывают передвижения объектов от одной части системы к другой. Могут начинаться и заканчиваться в любой части блока. Также в DFD используют двунаправленные стрелки, которые нужны для отображения взаимодействия между блоками.


^ Хранение данных


В то время как потоки данных представляют объекты в процессе их передвижения, хранилище данных моделирует их во всех остальных состояниях. При моделировании производственных систем хранилищами данных служат места временного складирования, где хранится продукция на промежуточных стадиях обработки.


^ Ветвление и объединение


Стрелки на DFD диаграммах могут быть разбиты на части, и при этом каждый получившийся сегмент может быть переименован.





Стрелки могут соединяться между собой.


^ Два подхода к построению DFD модели


Диаграмму DFD можно строить с использованием подхода анализа при проектировании, применяющемся в IDEF0.


Первый подход:

Модель - физическая реализация реальной модели

Логическая модель текущего состояния системы

Новая логическая модель разрабатываемой системы

Новая физическая модель, реализующая логическую модель новой системы


Альтернативный подход - "разделение событий":

Логическая модель, отражающая систему как набор действий и описывающая, что должна делать система

Модель окружения состоит из описания назначения системы (контекстная диаграмма)

Поведение показывает, как система обрабатывает те или иные события (хранит данные и т.д.)


^ Семантическое моделирование данных, ER-диаграммы


Широкое распространение реляционных СУБД и их использование в самых разнообразных приложениях показывает, что реляционная модель данных достаточна для моделирования предметных областей. Однако проектирование реляционной базы данных в терминах отношений на основе кратко рассмотренного нами механизма нормализации часто представляет собой очень сложный и неудобный для проектировщика процесс.


При этом проявляется ограниченность реляционной модели данных в следующих аспектах:

Модель не предоставляет достаточных средств для представления смысла данных. Семантика реальной предметной области должна независимым от модели способом представляться в голове проектировщика. В частности, это относится к упоминавшейся нами проблеме представления ограничений целостности.

Для многих приложений трудно моделировать предметную область на основе плоских таблиц. В ряде случаев на самой начальной стадии проектирования проектировщику приходится производить насилие над собой, чтобы описать предметную область в виде одной (возможно, даже ненормализованной) таблицы.

Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет каких-либо средств для представления этих зависимостей.

Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области ("сущностей") и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо аппарата для разделения сущностей и связей.

^ 6.2.1. Семантические модели данных


Потребности проектировщиков баз данных в более удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных. При том, что любая развитая семантическая модель данных, как и реляционная модель, включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности выражения семантики данных.


Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических моделей, остановимся на их возможных применениях.


Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.


Менее часто реализуется автоматизированная компиляция концептуальной схемы в реляционную. При этом известны два подхода: на основе явного представления концептуальной схемы как исходной информации для компилятора и построения интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области. И в том, и в другом случае в результате производится реляционная схема базы данных в третьей нормальной форме (более точно следовало бы сказать, что автору неизвестны системы, обеспечивающие более высокий уровень нормализации).


Наконец, третья возможность, которая еще не вышла (или только выходит) за пределы исследовательских и экспериментальных проектов, - это работа с базой данных в семантической модели, т.е. СУБД, основанные на семантических моделях данных. При этом снова рассматриваются два варианта: обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций в реляционную модель данных (это задача примерно такого же уровня сложности, как автоматическая компиляция концептуальной схемы базы данных в реляционную схему) и прямая реализация СУБД, основанная на какой-либо семантической модели данных. Наиболее близко ко второму подходу находятся современные объектно-ориентированные СУБД, модели данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых - более слабы).

^ 6.2.2. Основные понятия модели Entity-Relationship (Сущность-Связи)


Далее мы кратко рассмотрим некоторые черты одной из наиболее популярных семантических моделей данных - модель "Сущность-Связи" (часто ее называют кратко ER-моделью).


На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее развитых применяется в системе CASE фирмы ORACLE. Ее мы и рассмотрим. Более точно, мы сосредоточимся на структурной части этой модели.


Основными понятиями ER-модели являются сущность, связь и атрибут.


Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа.


^ 3. Объектно-ориентированный подход проектирования ИС









^ 4. Управление требованиями к разрабатываемой ИС


Формирование требований к информационным системам

Понятие ФТИС


Формирование требований к информационным системам (ФТИС) — это комплекс работ по выработке требований к ИС на основании исходных данных и с учетом рекомендаций экспертов.p>

Цель работ по ФТИС


Практические свойства создаваемой/модернизируемой ИС описываются в различной документации (концепция, техническое задание, предложения и др.). Какие требования будут заложены в эти документы - такими свойствами и будет обладать система. Поэтому главная цель ФТИС - это качественная и скрупулезная проработка требований, учет всех нюансов будущей работы пользователей с ИС. На этом этапе важно обеспечить запас функциональной и технологической долговечности системы и возможность ее последующей модернизации.

Подход РБК СОФТ к ФТИС



Для качественной разработки документации, содержащей требования к ИС, РБК СОФТ привлекает специалистов самого высокого уровня.


В зависимости от поставленных целей возможны два варианта проведения работ по ФТИС:


Первый вариант (концептуальный) подразумевает разработку концепции (предложений, рекомендаций и т.п.) содержащей общие требования и технико-технологические принципы, на которых должна строиться информационная система. Данные принципы являются концептуальной основой будущей ИС. Однако на их основе могут быть разработаны более конкретные требования к ИС. Концептуальный подход позволяет более широко взглянуть на перспективы применения ИС, а также дает возможность понять, в каких направлениях необходимо осуществлять деятельность по оптимизации информационного обеспечения. Данный вариант предпочтителен при отсутствии у заказчика задокументированных (разработана концепция) представлений о планируемой информационной системе. В этом случае разрабатывается концепция информационной системы, после создания которой возможен переход к этапу создания технического задания на разработку.


Второй вариант (операционный) подразумевает разработку технического задания (тактико-технического задания, технических требований и т. п.), содержащего четко определенные, конкретные требования. На их основе можно объективно оценить проект системы, которая будет создана. Специалисты, разрабатывающие техническое задание, методически опираются на существующие отечественные и зарубежные стандарты в данной области. Данный вариант предпочтителен при наличии у заказчика уже разработанной концепции ИС на основе которой уже возможна качественная разработка технического задания на систему.


Основной принцип - четкое определение требований, выдвигаемых к ИС. Недостаток многих технических заданий- это неконкретность требований. Составляя техническое задание, мы описываем требования в количественных характеристиках, либо на основе четких критериев, не допуская таких формулировок как: "Комплекс должен надежно работать", "Рабочее место должно соответствовать эргономическим требованиям" и т.д.


На последующих этапах заказчик имеет возможность осуществить обоснованный выбор программных платформ для реализации ИС. При необходимости можно провести последовательную проверку системы на соответствие заданным требованиям.


В качестве основных направлений анализа построения ИС выдвигаются следующие:

необходимые функциональные возможности;

масштабируемость и производительность;

поддержка открытых стандартов;

экономическая эффективность;

перспективы развития;

информационная безопасность.

Комплекс работ по ФТИС


Комплекс работ, проводимых в ходе ФТИС, включает следующие этапы:



1 Этап. Обследование объекта автоматизации. Осуществляется обследование объекта автоматизации заказчика с целью формирования исходных данных для разработки требований к ИС. Исходные данные содержат информацию по организационно-штатной структуре предприятия, информационному взаимодействию, бизнес-процессам и т.д. На этом этапе выявляются критические места в деятельности организации, влияющие на эффективность ее работы. Осуществляется анализ существующих на предприятии ИС (функции, структура, взаимодействие). Проводится оценка качества функционирования и организационно-технологического уровня используемой ИС. Обосновывается необходимость совершенствования существующей ИС.


2 Этап. Формирование требований Заказчика к информационной системе. Производится анализ исходных данных, и разрабатываются требования к ИС.


3 Этап. Оформление документации. Осуществляется окончательное оформление документации на разработку ИС и ее согласование.

Преимущества РБК СОФТ

наличие высококвалифицированных специалистов в области исследования и разработки информационных систем;

наличие большого опыта разработки информационных систем любого масштаба и в различных предметных областях;

наличие сертификата соответствия стандартам качества ISO 9001:2000, что гарантирует качество предоставляемых услуг.


^ 5. Диаграмма вариантов использования. Типичный ход событий


Состав диаграммы Use Case


Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комментарии.





Ответы на следующие вопросы позволят определить актеров, взаимодействующих с системой:


кто взаимодействует с системой или использует систему;


кто передает или принимает информацию в/из системы;


кто является внешним по отношению к системе.


Каждый вариант использования показывает, как конкретный актер использует систему и в дальнейшем расширяется диаграммами состояний и последовательности действий.

Виды взаимодействий


Между актерами и вариантами использования могут быть различные виды взаимодействия. Основные виды взаимодействия следующие:

Простая ассоциация - отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования. На рисунке между актером администратор и вариантом использования просматривать заказ.

Направленная ассоциация - то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.

Наследование - показывает, что потомок наследует атрибуты и поведение своего прямого предка. Может применяться как для актеров, так для вариантов использования.

Расширение (extend) - показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений "включение" расширенная последовательность может осуществляться в зависимости от определенных условий.

Включение - показывает, что вариант использования включается в базовую последовательность и выполняется всегда (на рисунке не показан).


^ 6. Концептуальная диаграмма









^ 7. Диаграммы классов

Диаграммой классов (Class diagram) называют диаграмму, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

^ Общие свойства

Диаграмме классов присущи общие для всех диаграмм свойства: имя и графическое содержание, являющееся одной из проекций модели. Вместе с тем диаграммы такого рода отличаются от остальных специфичным содержанием.

Содержание

Диаграммы классов обычно содержат следующие сущности:

классы;

интерфейсы;

кооперации;

отношения зависимости, обобщения и ассоциации.

Подобно всем остальным диаграммам, они могут включать в себя примечания и ограничения.

Также в диаграммах классов могут присутствовать пакеты или подсистемы , применяемые для группирования элементов модели в более крупные блоки. Иногда в эти диаграммы помещают экземпляры, особенно если требуется визуализировать их тип (возможно, динамический).

^ Типичные примеры применения

Диаграммы классов применяют для моделирования статического вида системы с точки зрения проектирования. В этом представлении удобнее всего описывать функциональные требования к системе - услуги, которые она предоставляет конечному пользователю.

Обычно диаграммы классов используются в следующих целях:

1) для моделирования словаря системы. Моделирование словаря системы предполагает принятие решения о том, какие абстракции являются частью системы, а какие - нет. С помощью диаграмм классов вы можете определить эти абстракции и их обязанности;

2) для моделирования простых коо
^ Термины и понятия

Диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию. Автомат (State machine) -это описание последовательности состояний, через которые проходит объект на протяжении своего жизненного цикла, реагируя на события, - в том числе описание реакций на эти события. Состояние (State) - это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события. Событие (Event) - это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие - это стимул, способный вызвать срабатывание перехода. Переход (Transition) - это отношение между двумя состояниями, показывающее, что объект, находящийся в первом состоянии, должен выполнить некоторые действия и перейти во второе состояние, как только произойдет определенное событие и будут выполнены заданные условия. Деятельность (Activity) -это продолжающееся неатомарное вычисление внутри автомата. Действие (Action) - это атомарное вычисление, которое приводит к смене состояния или возврату значения. Диаграмма состояний изображается в виде графа с вершинами и ребрами.

^ Общие свойства

Диаграмма состояний обладает свойствами, общими для всех диаграмм (см. главу 7), то есть имеет имя и графическое содержание, проецируемое на модель. От прочих диаграмм она отличается именно этим содержанием.

Содержание

Обычно диаграмма состояний включает в себя:

простые и составные состояния (см. главу 21);

переходы вместе с ассоциированными событиями и действиями (см. ту же главу).



Примечание: Диаграмма состояний, по сути, составлена из элементов, встречающихся в любом автомате. Она может содержать ветвления, разделения, слияния, состояния деятельности и действий, объекты, начальные и конечные состояния, исторические состояния и т.д., - в общем, к диаграмме состояний применимы все без исключения характеристики автомата. Диаграмму деятельности (см. главу 19) отличает от диаграммы состояний лишь то, что она состоит в основном из элементов, встречающихся в графе деятельности, и представляет собой разновидность автомата, в котором все или большая часть состояний есть состояния деятельности, а все или большая часть переходов инициируются фактом завершения деятельности в исходном состоянии.



Как и все прочие диаграммы, диаграмма состояний может содержать примечания и ограничения (см. главу 6).

^ Типичные примеры использования

Диаграммы состояний применяются для моделирования динамических аспектов си