Файл: Курсовая работа по дисциплине Методы и средства проектирования информационных систем и технологий.docx

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

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

Правила IDEF0 включают:

1. 
   ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
   
2. 
   связность диаграмм (номера блоков);
   
3. 
   уникальность меток и наименований (отсутствие повторяющихся имен);
   
4. 
   синтаксические правила для графики (блоков и дуг);
   
5. 
   разделение входов и управлений (правило определения роли данных);
   
6. 
   отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель [10].
   

Контекстный уровень диаграммы информационной системы бизнес-процессов «Библиотека вуза» представлена на рисунке 4.1.


Рисунок 4.1 – Контекстная функциональная модель в методологии IDEF0
Далее этот блок детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Декомпозиция - разделение моделируемой функции на функции компоненты. Диаграмма декомпозиции представлена на рисунке 4.2.


Рисунок 4.2 – Диаграмма декомпозиции А0
Т.к. основная деятельность — это поиск библиотечных материалов и само оформление заказа, то именно это и покажем в качестве диаграммы декомпозиции второго уровня рисунок 4.3.


Рисунок 4.3 – Декомпозиция функционального блока А2 «Абонемент»
Запись деятельности библиотеки будет фиксироваться в справочной системе, что показано на рисунке 4.4.


Рисунок 4.4 – Декомпозиция функционального блока А4 «Справочная система каталогов и карточек»

---

На рисунке 4.5 покажем иерархическую зависимость блоков.


Рисунок 4.5 – Декомпозиция дерева узлов

---

4.2 Моделирование потоков данных (DFD)

Диаграммы потоков данных (DFD - Data Flow Diagram) - основные средства моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами [11].

DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных [12].

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



Рисунок 4.6 – Таблица синтаксиса DFD
Подробная нотация синтаксиса DFD:

1) процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми;

2) внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных;

---

3) хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов;

4) поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме [14].

Пример схемы информационных потоков в виде диаграммы потоков данных (DFD) представлен на рисунке 4.7.



Рисунок 4.7 – Диаграмма потока данных

5 Объектно-ориентированное проектирование
информационной системы

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

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

Именно объектно-ориентированная декомпозиция является основополагающим принципом ООП. При этом требования к проектируемой системе представляются с точки зрения классов и объектов, выявленных в предметной области. Логическая структура системы также отображается абстракциями в виде классов и объектов [16].

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

---

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

1. 
   RUP (Rational Unified Process);
   
2. 
   OMT (Object Modeling Technique);
   
3. 
   SA/SD (Structured Analysis/Structured Design);
   
4. 
   JSD (Jackson Structured Development);
   
5. 
   OSA (Object-Oriented System Analysis).
   

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

Сущность концепции прецедентов подразумевает несколько важных пунктов:

1. 
   прецедент представляет собой завершенный фрагмент функциональных возможностей (включая основной поток логики управления, его любые вариации (под потоки) и исключительные условия (альтернативные потоки));
   
2. 
   фрагмент внешне наблюдаемых функций (отличных от внутренних функций);
   
3. 
   ортогональный фрагмент функциональных возможностей (прецеденты могут при выполнении совместно использовать объекты, но выполнение каждого прецедента независимо от других прецедентов);
   
4. 
   фрагмент функциональных возможностей, инициируемый субъектом. Будучи инициирован, прецедент может взаимодействовать с другими субъектами. При этом возможно, что субъект окажется только на принимающем конце прецедента, опосредованно инициированного другим субъектом [18].
   

Диаграмма прецедентов для выбранной нами информационной системы «Библиотека вуза», выполнена в программе Rational Rose и представлена на рисунке 5.1.

---