На этой стадии определяется функциональность системы. Каждая сущность ESD-диаграммстановится программой на сетевойND-диаграмме. Результатом стадии является представление моделируемой системы в виде набора сетевых диаграмм. Стадия завершается описанием данных и связей между процессами и программами.

Рис. 5.50. Общий вид ND-диаграммы

Стадия сети реализуется тремя шагами.

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

Основным назначением шага реализации является оптимизация системы с целью сокращения количества процессов. С этой целью выполняется объединение некоторых из них.

21. Унифицированный язык моделирования (UML).

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

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

Предметы — это абстракции, которые являются основными элементами в модели, отношения связывают эти предметы, диаграммы группируют коллекции предметов.

Предметы

В UML имеются четыре разновидности предметов:

• структурные предметы;

• предметы поведения;

• группирующие предметы;

• поясняющие предметы.

Эти предметы являются базовыми объектно-ориентированными строительными блоками. Они используются для написания моделей.

Структурные предметы являются существительными в UML-моделях. Они представляют статические части модели — понятийные или физические элементы. Перечислим восемь разновидностей структурных предметов.

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

Рис. 10.1. Классы

2. Интерфейс — набор операций, которые определяют услуги класса или компонента. Интерфейс описывает поведение элемента, видимое извне. Графически интерфейс изображается в виде кружка с именем, как показано на рис. 10.2. Имя интерфейса обычно начинается с буквы «I». Интерфейс редко показывают самостоятельно. Обычно его присоединяют к классу или компоненту, который реализует интерфейс.

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

---

Рис. 10.3. Кооперации

4. Актер — набор согласованных ролей, которые могут играть пользователи при взаимодействии с системой (ее элементами Use Case). Каждая роль требует от системы определенного поведения. Как показано на рис. 10.4, актер изображается как проволочный человечек с именем.

Рис. 10.4. Актеры

5. Активный класс — класс, чьи объекты имеют один или несколько процессов (или потоков) и поэтому могут инициировать управляющую деятельность. Активный класс похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов. Как показано на рис. 10.6, активный класс изображается как утолщенный прямоугольник, обычно включающий имя, свойства (атрибуты) и операции.

Рис. 10.6. Активные классы

6. Узел — физический элемент, который существует в период работы системы и представляет ресурс, обычно имеющий память и возможности обработки. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Как показано на рис. 10.8, узел изображается как куб с именем.

Рис. 10.8. Узлы

Предметы поведения — динамические части UML-моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Существует две основные разновидности предметов поведения. (ещё конечные автоматы)

1. Взаимодействие — поведение, заключающее в себе набор сообщений, которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. Как показано на рис. 10.9, сообщение изображается в виде направленной линии с именем ее операции.

Рис. 10.9. Сообщения

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

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

Рис. 10.11. Пакеты

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

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

Рис. 10.12. Примечания

Отношения в UML

В UML имеются четыре разновидности отношений:

1) зависимость;

2) ассоциация;

3) обобщение;

4) реализация.

Эти отношения являются базовыми строительными блоками отношений. Они используются при написании моделей.

---

1. Зависимость — семантическое отношение между двумя предметами, в котором изменение в одном предмете (независимом предмете) может влиять на семантику другого предмета (зависимого предмета). Как показано на рис. 10.13, зависимость изображается в виде пунктирной линии, возможно направленной на независимый предмет и иногда имеющей метку.

Рис. 10.13. Зависимости

2. Ассоциация — структурное отношение, которое описывает набор связей, являющихся соединением между объектами. Агрегация — это специальная разновидность ассоциации, представляющая структурное отношение между целым и его частями. Как показано на рис. 10.14, ассоциация изображается в виде сплошной линии

Рис. 10.14. Ассоциации

3. Обобщение — отношение специализации/обобщения, в котором объекты специализированного элемента (потомка, ребенка) могут заменять объекты обобщенного элемента (предка, родителя). Иначе говоря, потомок разделяет структуру и поведение родителя. Как показано на рис. 10.15, обобщение изображается в виде сплошной стрелки с полым наконечником, указывающим на родителя.

Рис. 10.15. Обобщения

4. Реализация — семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их. Как показано на рис. 10.16, реализация изображается как нечто среднее между обобщением и зависимостью.

Рис. 10.16. Реализации

Диаграммы в UML

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

22. Модели реализации объектно-ориентированных программных систем. Компонентные диаграммы и их использование.

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

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

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

Рис. 13.1. Обозначение компонента

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

---

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

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

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

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

23. Автоматизация конструирования визуальной модели программных систем.

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

Наиболее известной объектно-ориентированной CASE-системой является Rational Rose. Rational Rose используется при формировании требований, анализе, проектировании и генерации программного кода. Именно в IBM Rational Rose язык UML стал базовой технологией визуализации и разработки программных систем, что определило популярность и стратегическую перспективность этого инструментария.

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

---

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

• диаграммы классов;

• диаграммы состояний;

• диаграммы сценариев;

• диаграммы модулей;

• диаграммы процессов;

• спецификации классов, объектов, атрибутов и операций

• заготовки текстов программ;

• модель разрабатываемой программной системы.

БАЗЫ ДАННЫХ

1. Назначение и основные компоненты системы баз данных.

2. Уровни представления баз данных; понятия схемы и подсхемы.

http://mydocx.ru/9-82053.html

3. Модели данных.

4. Иерархическая, сетевая и реляционная модели данных; схема отношения.

https://infopedia.su/8x7226.html

http://www.mstu.edu.ru/study/materials/zelenkov/ch_4_1.html#4_1_2

5. Язык манипулирования данными для реляционной модели;

6. Реляционная алгебра и язык SQL.

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

8. Функциональные зависимости, декомпозиция отношений, транзитивные зависимости,

9. Проектирование с использованием метода «сущность – связь».

10. Создание и модификация базы данных.

11. Поиск, сортировка, индексирование базы данных.

12. Создание форм и отчетов.

13. Физическая организация базы данных.

14. Хешированные, индексированные файлы;

15. Защита баз данных.

16. Целостность и сохранность баз данных.

1. Назначение и основные компоненты системы баз данных.

База данных (БД) – совокупность структурированных взаимосвязанных данных, относящихся к определённой предметной области и организованных таким образом, что эти данные могут быть использованы для решения многих задач многими пользователями.

Система управления базами данных (СУБД) - это совокупность программ и языковых средств, предназначенных для управления данными в базе данных, ведения базы данных и обеспечения взаимодействия её с прикладными программами.

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

В соответствии с рис. 1.6 СУБД обеспечивает выполнение двух групп функций:

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

• управление хранением и обработкой данных в БД.

Таким образом, обращение к базе данных возможно только через СУБД.

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

---

Смотрите также файлы

• Рабочая тетрадь по теоретической механике 3.pdf

• Информационные технологии. Лекции.docx

• Инструктаж по технике безопасности на уроках информатики.docx

• Тема 1.1 Основные понятия теории множеств.docx

• ЧМ Контрольная работа 1.docx