Файл: Отчет по преддипломной практике огу 09. 03. 02. 7223. 223 П руководитель от кафедры.docx

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

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

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

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

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


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


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


Рисунок 2.10 – Диаграмма декомпозиции функционального блока А1
На рисунке 2.11 отображена деятельность администратора системы.


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

---

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

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


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

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

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

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

При разработке объектно-ориентированных моделей информационной системы важно правильно выбрать инструментальные средства.

Инструментальные средства разработки информационной системы – это набор аппаратно-программных средств, которые обеспечивают полный цикл проектирования программного обеспечения [22].

На данный момент существует большое количество CASE-средств, которые используют при моделировании нотацию UML. Например: Rational Rose, Umbrello, Edraw Max, UML Designer, Altova UModel, Microsoft Visio, Umple, Visual Paradigm, StarUML, WhitestarUML, GenMyModel, Diagramo, Astah и др.

---

Чтобы выбрать наиболее подходящее CASE-средство, необходимо провести сравнительный анализ именно тех программных продуктов, с которыми имелся опыт работы. Следовательно, сравниваться будут StarUML, Rational Rose и Microsoft Visio.

Проведем сравнительный анализ функциональных возможностей указанных выше CASE-средств и сведем результаты сравнения в таблицу 2.3.
Таблица 2.3 – Сравнительный анализ функциональных возможностей средств ООП

№	Инструментальная среда Возможности	StarUML	Rational Rose	Microsoft Visio
1	Дистрибуция в свободном доступе	Да	Да	Нет. Необходима подписка Office 365.
2	Поддержка стандарта UML 1.4, нотации UML 2.0 на основе метамодели	Да	Нет	Да
3	Поддержка MDA	Да	Нет	Нет
4	Возможность совместной работы	Нет	Да. При помощи IBM Rational Suite и Visual SourseSafe.	Нет
5	Расширяемость	Да. Поддержка Microsoft COM.	Нет	Да. Поддержка Microsoft COM.
6	Программная функция проверки модели	Да	Да	Нет
7	Интерфейс пользователя	Простой интерфейс, есть выравнивание объектов, функция отмены предыдущих действий.	Сложный интерфейс, отсутствует выравнивание, однократная отмена предыдущих действий.	Простой интерфейс, есть выравнивание объектов, есть многократная отмена предыдущих действий.
8	Полезные дополнения	Да. Импорт файлов в Rational Rose, конвертация исходных текстов в модели, генерация исходных текстов на языках программирования.	Да. Импорт модели базы данных в SQL-запрос.	Нет
9	Возможность проведения декомпозиции	Да. Имеется неограниченное количество декомпозиций. Переход от одной нотации к другой.	Да. Имеется неограниченное количество декомпозиций.	Да. Имеется неограниченное количество декомпозиций.
10	Открытый формат программной модели	Да	Нет	Да

---

Таким образом, проведя сравнительный анализ CASE-средств для объектно-ориентированного моделирования, было выявлено, что StarUML является наилучшей из рассматриваемых.

Далее необходимо выполнить построение UML-диаграмм.

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

Диаграмма прецедентов для выбранной нами информационной системы поддержки принятия решений по замене сетевого оборудования организации, выполнена в программе StarUML и представлена на рисунке 2.13.


Рисунок 2.13 – Диаграмма прецедентов
Целью диаграмм взаимодействия является визуализация интерактивного поведения системы. Визуализация взаимодействия — сложная задача. Следовательно, решение состоит в том, чтобы использовать различные типы моделей, чтобы охватить различные аспекты взаимодействия.

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

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

---

На рисунке 2.14 изображена диаграмма взаимодействия «Запрос на замену сетевого оборудования»


Рисунок 2.14 – Диаграмма взаимодействия
Диаграмма активностей – отражает динамические аспекты поведения системы, то есть отображает потоки работ во взаимосвязанных вариантах использования. По существу, эта диаграмма представляет собой блок – схему, которая наглядно показывает, как поток управления переходит от одной деятельности к другой. Диаграммы активностей позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних действий и деятельности. Данная диаграмма была выполнена в программе StarUML на рисунке 2.15.


Рисунок 2.15 – Диаграмма активностей
Целью создания диаграммы классов является графическое представление статической структуры декларативных элементов системы (классов, типов и т. п.) Она содержит в себе также некоторые элементы поведения (например — операции), однако их динамика должна быть отражена на диаграммах других видов (диаграммах коммуникации, диаграммах состояний). Для удобства восприятия диаграмму классов можно также дополнить представлением пакетов, включая вложенные.

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

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

---