Место моделирования в проектировании больших программных систем. Моделируемые аспекты программных систем

 

 

1. Место моделирования в проектировании больших программных систем. Моделируемые аспекты программных систем.

Моделирование программных систем позволяет:

• визуализировать систему в ее текущем или желательном для нас состоянии;
• определить структуру или поведение системы;
• получить шаблон, позволяющий затем сконструировать систему;
• документировать принимаемые решения, используя полученные модели.

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

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

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

Моделируемые аспекты программных  систем

• Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. В языке UML статические аспекты этого вида передаются диаграммами прецедентов, а динамические - диаграммами взаимодействия, состояний и действий.
• Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид поддерживает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям. Статические аспекты этого вида можно передавать диаграммами классов и объектов, а динамические - диаграммами взаимодействия, состояний и действий.
• Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает производительность и пропускную способность системы. Статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание уделяется активным классам, которые представляют нити и процессы.
• Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен для управления конфигурацией  системы, составляемой из независимых компонентов и файлов. Статические аспекты передают с помощью диаграмм компонентов, а динамические - с помощью диаграмм взаимодействия, состояний и действий.
• Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические - диаграммами взаимодействия, состояний и действий.

 

2. Основные понятия объектно-ориентированного подхода к проектированию программ. Абстрагирование. Ограничение доступа. Модульность. Иерархия.

Преимущества объектной модели:

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

Абстракция:

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

Инкапсуляция:

• Инкапсуляция реализует абстракцию, скрывая внутреннюю структуру объекта и предоставляя вовне только внешнее поведение – интерфейс, соответствующий принятому уровню абстракции
• Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством
• Данные и методы могут иметь модификаторы public, private  и protected определяющие степень доступности.

Модульность:

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

Иерархия:

• Это упорядочение абстракций, расположение их по уровням.
• Значительное упрощение в понимании сложных задач достигается за счет образования из абстракций иерархической структуры
• Один из видов иерархии – концепция наследования «обобщение-специализация» (is-a)
• Другой вид иерархии – агрегация (part-of)

 

3. Основные понятия объектно-ориентированного подхода к проектированию программ. Понятие класса. Понятие объекта. Инкапсуляция данных и методов.

Класс является описываемой на языке терминологии (пространства имён) исходного кода моделью ещё не существующей сущности (объекта). Фактически он описывает устройство объекта, являясь своего рода чертежом. Говорят, что объект — это экземпляр класса. Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области. Класс представляет набор объектов, которые обладают общей структурой и одинаковым поведением. Поведение выражается в терминах состояния объекта (изменения состояний) и в передаче сообщений.

Типы объектов:

• Актер (действующее лицо) – объект может воздействовать на другие объекты, но сам никогда не подвергается воздействию других объектов
• Сервер – объект может только подвергаться воздействию со стороны других объектов
• Агент – Может выступать как в активной, так и пассивной роли

Связи объектов:

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

Отношения между классами:

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

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

 

 

4. Основные понятия объектно-ориентированного подхода к проектированию программ. Роль наследования в ООП.

Наследование:

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

Одиночное наследование:

При одиночном наследовании один или несколько классов наследуют свойства ТОЛЬКО ОДНОГО родительского класса.

Множественное наследование:

Абстрактные классы – обязательно должны иметь наследников и не имеют экземпляров.

 

 

 

5. Основные понятия объектно-ориентированного подхода к проектированию программ. Свойство полиморфизма.

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

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

Полиморфизм:

• Одно и то же имя может означать объекты разных ТИПОВ
• Полиморфизм реализует адаптивное поведение класса
• Полиморфизм реализует динамическое связывание объектов

 

6. Основные понятия объектно-ориентированного подхода к проектированию программ. Понятие типизации.

Типизация:

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

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

• Статическая типизация — контроль типов осуществляется при компиляции.
• Динамическая типизация — контроль типов осуществляется во время выполнения.

Контроль типов также может  быть строгим и слабым.

• Строгая типизация — совместимость типов автоматически контролируется транслятором:

• Номинативная типизация — совместимость должна быть явно указана (наследована) при определении типа.
• Структурная типизация — совместимость определяется структурой самого типа (типами элементов, из которых построен составной тип).

• Слабая типизация — совместимость типов никак транслятором не контролируется. В языках со слабой типизацией обычно используется подход под названием «утиная типизация» — когда совместимость определяется и реализуется общим интерфейсом доступа к данным типа.

 

7. Назначение и основные свойства языка UML

UML – это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.

Артефакт — это любой созданный  искусственно элемент программной  системы.

1. Визуализация:

• Результаты обсуждения проекта и принятые решения воплощаются в виде понятных для всех схем
• Улучшается понимание всеми участниками проекта поставленной задачи
• При смене разработчиков принятые решения в виде модели не меняются

2. Специфицирование:

• Специфицируются важнейшие характеристики системы
• Спецификации охватывают различные точки зрения на систему
• Спецификации согласуются между собой

3. Конструирование:

• Модели могут быть переведены на различные языки программирования – прямое проектирование
• Программы на языках программирования могут быть реконструированы в модель – обратное проектирование

4. Документирование:

• Требования к системе;
• Архитектура;
• Проект;
• Исходный код;
• Проектный план;
• Тест;
• Прототип;
• Версия;
• И др.

Язык UML предназначен для решения  следующих задач:

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

 

 

 

8. Язык UML. Понятия сущности, отношения, диаграммы.

Словарь UML включает три вида строительных блоков:

1. Сущности.

2. Связи.

3. Диаграммы.

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

 

 

9. Язык UML. Типы сущностей.

Сущности:

1. Структурные

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

Все структурные сущности могут иметь разновидности.

2. Поведенческие

Описывают поведение модели во времени  и пространстве.

• Взаимодействие - поведение, связанное с обменом сообщением.
• Автомат - алгоритм поведения, выраженный в последовательности состояний.

3. Группирующие

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

4. Аннотационные

• Комментарии - пояснительные части моделей.

 

 

10. Язык UML. Типы отношений.

Отношения:

• Зависимость - семантическое отношение между двумя сущностями.

• Ассоциация - структурное отношение.

• Обобщение - отношение наследования, соотношение с более общим  вариантом.

• Реализация - отношение реализации, например, интерфейса или прецедентов  и их коопераций.

 

 

11. Язык UML. Диаграмма прецедентов (использования). Вид диаграммы. Назначение диаграммы.

Диаграмма прецедентов отражает функциональное назначение системы. Является концептуальной моделью системы. Она же диаграмма использования. Формализация требований заказчика к системе.

Применение:

• моделирование контекста системы;
• охватывает внешнее окружение системы, с которой она взаимодействует;
• вводит стереотипы их поведения, связи с системой;
• моделирует требования к системе;
• устанавливает внешние связи;
• определяет поведение системы;
• определяет функциональные требования к системе.

Актёры – действующие лица, любая внешняя по отношению к системе сущность, которая взаимодействует с системой.

Прецеденты – варианты использования.

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

Взаимодействия между прецедентами и актёрами:

• ассоциация;
• расширение;
• обобщение;

• включение.

 

12. Язык UML. Диаграмма классов. Вид диаграммы. Назначение диаграммы.

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

Применение:

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

Структура класса:

• имя класса (уникальное);
• атрибуты;
• операции (методы);
• интерфейсы.

Отношения:

• ассоциация;
• агрегация;
• обобщение.

 

13. Язык UML. Диаграмма объектов. Вид диаграммы. Назначение диаграммы.

Диаграммы объектов (Object diagram) – представляет объекты и отношения между ними. Является «фотографией» сущностей, показанных на диаграмме классов.

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

 

14. Язык UML. Диаграммы взаимодействий. Диаграмма последовательностей. Вид диаграммы. Назначение диаграммы.

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

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

• Отображаются только те объекты, которые участвуют во временном взаимодействии
• Каждый объект имеет линию жизни
• На линии жизни отражается фокус управления, когда данный объект является активным
• Объекты обмениваются между собой сообщениями
• Объекты должны быть соотнесены классам

 

15. Язык UML. Диаграммы взаимодействий. Диаграмма коопераций. Вид диаграммы. Назначение диаграммы.

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

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

• Моделируется структурная организация взаимодействующих объектов
• Основное – потоки сообщений между объектами
• Последовательность сообщений задается номером сообщения
• Сообщения передаются по связям между объектами

 

16. Язык UML. Диаграмма состояний. Вид диаграммы. Назначение диаграммы.

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

Диаграмма состояний показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию.

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

 

17. Язык UML. Диаграмма деятельности. Вид диаграммы. Назначение диаграммы.

Диаграмма деятельности – динамическая модель системы. Описывает процесс  выполнения операций (описание алгоритма).

• Моделирует динамическое поведение системы
• Показывает поток переходов от одной деятельности к другой
• Используется для любых видов абстракций

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

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

 

18. Язык UML. Диаграмма компонентов. Вид диаграммы. Назначение диаграммы.

Диаграмма компонентов – описание организации компонентов и зависимостей между ними. Статическое описание системы. Представляет физическое представление системы.

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

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

Интерфейс – это набор операций, которые описывают услуги, доставляемые классом или компонентом.

Стандартные стереотипы компонентов:

• executable (исполнимый) – определяеткомпонент, который может использоваться в узле
• library (библиотека) – определяет статическую или динамическую проектную библиотеку
• table (таблица) – определяет компонент, представляющий таблицу базы данных
• file (файл) – определяет компонент, представляющий документ, который содержит исходный текст или данные
• document (документ) – определяет компонент, представляющий документ

 

19. Язык UML. Диаграмма развертывания. Вид диаграммы. Назначение диаграммы.

Диаграмма развертывания (Deployment diagram) – представляет конфигурацию обрабатывающих узлов системы и размещенных в них компонентов. Статическое описание системы.

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

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

 

20. Язык UML. Понятие прямого и обратного проектирования.

Проектирование с использованием UML может быть:

• прямое – из модели UML можно получить готовый код описания проекта: все классы и объявления переменных и методов;
• обратное – из кода можно получить диаграмму классов.