Проектирование информационных систем
| Вид материала | Документы |
- М. В. Красильникова проектирование информационных систем раздел: Теоретические основы, 1088.26kb.
- Учебно-методический комплекс дисциплины проектирование информационных систем Для студентов, 466.59kb.
- Учебная программа дисциплины сд. Ф. 01 Проектирование информационных систем, 130.91kb.
- Лекция: Основные понятия технологии проектирования информационных систем (ИС): Предмет, 189.07kb.
- Название научной школы, направлений, 378.51kb.
- Дисциплина по выбору студента «Лингвистическое обеспечение информационных систем» Для, 20.86kb.
- Методические рекомендации по выполнению курсовой работы по курсу «Проектирование информационных, 76.85kb.
- Учебно-методический комплекс дисциплины проектирование информационных систем Специальность, 449.6kb.
- «Проектирование информационных, вычислительных и автоматизированных систем», 94.77kb.
- Вопросник по предмету: «Проектирование информационных систем» для группы мс- 71 (осенний, 29.88kb.
Проектирование информационных систем
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) для моделирования простых коопераций. Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения, более значимого, чем сумма составляющих его элементов. Например, моделируя семантику транзакций в распределенной системе, вы не сможете понять происходящие процессы, глядя на один-единственный класс, поскольку соответствующая семантика обеспечивается несколькими совместно работающими классами. С помощью диаграмм классов удается визуализировать и специфицировать эти классы и отношения между ними;
3) для моделирования логической схемы базы данных. Логическую схему можно представлять себе как чертеж концептуального проекта базы данных. Во многих сферах деятельности требуется хранить устойчивую (persistent) информацию в реляционной или объектно-ориентированной базе данных. Моделировать схемы также можно с помощью диаграмм классов.
8. Диаграмма последовательностей
На диаграммах последовательностей внимание акцентируется прежде всего на временной упорядоченности сообщений. На рис. 18.2 показано, что для создания такой диаграммы надо прежде всего расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные - правее (тем дальше, чем более подчиненным является объект). Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже. Это дает читателю наглядную картину, позволяющую понять развитие потока управления во времени.
Диаграммы последовательностей характеризуются двумя особенностями, отличающими их от диаграмм кооперации.
Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. (Обстоятельства жизненного цикла объекта можно указывать с помощью ограничений new, destroyed и transient, см. главу 15.)
Примечание: Если объект на протяжении своей жизни изменяет значения атрибутов, состояние или роль, это можно показать (см. главу 13), поместив копию его пиктограммы на линии жизни в точке изменения.
Вторая особенность этих диаграмм - фокус управления. Он изображается в виде вытянутого прямоугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие, непосредственно или с помощью подчиненной процедуры. Верхняя грань прямоугольника выравнивается по временной оси с моментом начала действия, нижняя - с моментом его завершения (и может быть помечена сообщением о возврате). Вложенность фокуса управления, вызван ную рекурсией (то есть обращением к собственной операции) или обратным вы зовом со стороны другого объекта, можно показать, расположив другой фокус управления чуть правее своего родителя (допускается вложенность произвольно! глубины). Если место расположения фокуса управления требуется указать с максимальной точностью, можно заштриховать область прямоугольника, соответствующую времени, в течение которого метод действительно работает и не пере дает управление другому объекту.
Примечание: На диаграммах кооперации линию жизни объекта явным образом не показывают, хотя можно показать сообщения create и destroy. Не показывают там и фокус управления, однако порядковые номера сообщения могут отображать вложенность.
9. Диаграмма коопераций
Диаграмма кооперации акцентирует внимание на организации объектов, прини-мающие участие во взаимодействии. Как показано на рис. 18.3, для создания диа граммы кооперации нужно расположить участвующие во взаимодействии объекта в виде вершин графа. Затем связи, соединяющие эти объекты, изображаются в вид дуг этого графа. Наконец, связи дополняются сообщениями, которые объекты при нимают и посылают. Это дает пользователю ясное визуальное представление о по токе управления в контексте структурной организации кооперирующихся объектов.
У диаграмм кооперации есть два свойства, которые отличают их от диаграмм последовательностей.
Первое - это путь. Для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути (например, local показывающий, что помеченный объект является локальным по отношению к от правителю сообщения). Имеет смысл явным образом изображать путь связи только в отношении путей типа local, parameter, global и self (но не associations).
Второе свойство - это порядковый номер сообщения. Для обозначения временной последовательности перед сообщением можно поставить номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения (2, 3 и т.д.). Для обозначения вложенности используется десятичная нотация Дьюи (1 - первое сообщение; 1.1 - первое сообщение, вложенное в сообщение 1; 1.2- второе сообщение, вложенное в сообщение 1 и т.д.). Уровень вложенности не ограничен. Для каждой связи можно показать несколько сообщений (вероятно, посылаемых разными отправителями), и каждое из них должно иметь уникальный порядковый номер.
Чаще всего вам придется моделировать неветвящиеся последовательные потоки управления. Однако можно моделировать и более сложные потоки, содержащие итерации и ветвления (для этого более удобна диаграмма деятельности - см. главу 19). Итерация представляет собой повторяющуюся последовательность сообщений. Для ее моделирования перед номером сообщения в последовательности ставится выражение итерации, например * [ i : = 1. . n] (или просто *, если надо обозначить итерацию без дальнейшей детализации). Итерация показывает, что сообщение (и все вложенные в него сообщения) будет повторяться в соответствии со значением заданного выражения. Аналогично условие представляет собой сообщение, выполнение которого зависит от результатов вычисления некоторого булевского выражения. Для моделирования условия перед порядковым номером сообщения ставится выражение, например [х>0]. У всех альтернативных ветвей будет один и тот же порядковый номер, но условия на каждой ветви должны быть заданы так, чтобы два из них не выполнялись одновременно (не перекрывались).
10. Диаграммы состояний
В UML для моделирования поведения объекта с точки зрения порядка возникновения событий используются диаграммы состояний. Из рис. 24.1 видно, что диаграмма состояний - это просто представление автомата (см. главу 21), и основное внимание уделено потоку управления от одного состояния к другому.