Шпаргалка по "Программированию и компьютерам"

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

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

Составное состояние (composite state) – такое сложное состояние, которое состоит из других вложенных в него состояний. Последние будут выступать по отношению к первому как подсостояния (substate). Хотя между ними имеет место отношение композиции, графически все вершины диаграммы, которые соответствуют вложенным состояниям, изображаются внутри символа составного состояния. В этом случае размеры графического символа составного состояния увеличиваются, так чтобы вместить в себя все подсостояния.  

Последовательные подсостояния (sequential substates) используются для моделирования такого поведения объекта, во время которого в каждый момент времени объект может находиться в одном и только одном подсостояний. 

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

Историческое состояние (history state) применяется в контексте составного состояния. Оно используется для запоминания того из последовательных подсостояний, которое было текущим в момент выхода из составного состояния. При этом существует две разновидности исторического состояния: недавнее и давнее.

Недавнее историческое состояние (shallow history state) обозначается в форме небольшой окружности, в которую помещена латинская буква "Н". При первом переходе в недавнее историческое состояние оно заменяет собой начальное состояние подавтомата.

Давнее историческое состояние (deep history state) обозначается в форме небольшой окружности, в которую помещена латинская буква "Н" с символом "*" и служит для запоминания всех подсостояний любого уровня вложенности для текущего подавтомата. 

Синхронизирующее состояние (synch state) обозначается небольшой окружностью, внутри которой помещен символ звездочки "*". Оно используется совместно с переходом-соединением или переходом-ветвлением для того, чтобы явно указать события в других подавтоматах, оказывающие непосредственное влияние на поведение данного подавтомата.

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

 

23. Диаграмма деятельности как частный случай диаграммы состояний: назначение, графическое представление.

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

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

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

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

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

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

Единственное отличие представления диаграммы деятельности от диаграммы состояний заключается в представлении дорожек.

Актер 1	Актер 2	Актер N

 

 

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

 

 

 

 

 

 

 

 

 

 

 

24. Диаграмма компонентов: назначение, графическое представление.

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

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

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

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

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

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

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

1. исходный код программ.
2. Бинарный код программ.
3. Исполняемый код программ.

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

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

 

 

 

25. Диаграмма компонентов: виды компонентов, взаимодействие компонентов, понятие интерфейса.

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

Интерфейс – код для сопряжения двух отдельных элементов системы.

Компонент графически представляется следующим образом.

<тип  ресурса>:<имя компонента>

Тип ресурса, который поддерживается в данный момент в языке UML. (в рэйшн роулз при указании конкретного типа ресурса, графическое представление компонента может автоматически изменяться):

1. Исполняемый файл (файл с расширением exe, сюда не входят веб-разработки и нестандартные расширения).
2. Динамически подключаемые библиотеки (расширение dll).
3. Веб-страницы, интернет порталы (расширение html и его расширения, веб-программирование не входит).
4. Текстовые документы и файлы справок(txt, docx, djv, hlp).
5. Базы и банки данных. (db*).
6. Файлы с исходным кодом программ на языках высокого уровня. (h - заголовочное, cpp – С, java, pas).
7. Скриптовые языки и веб-программирование. (Скриптовые и командные языки).

Виды компонентов:

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

Для наглядного представления в языке введены следующие графические стереотипы.

1. Стереотипы для компонентов развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть, динамически подключаемые библиотеки, веб-страницы и интернет порталы, файлы-справки, файлы исходного кода программ.
1. библиотеки
2. Веб-страницы и интернет порталы
3. Файлы справки
4. Исходные коды
2. Стереотипы для представления хранилищ данных.
1. База данных
2. Для облачных хранилищ
3. Текстовые документы

Другой способ спецификации – указание текстового стереотипа компонента перед его именем.

1. <<file>>определяет наиболее общую разновидность компонента произвольного файла.
2. <<executable>> исполняемые файлы.
3. <<document>> определяет разновидность файла, который представляется в виде документа произвольного содержания.
4. <<library>> статические библиотеки. Вычислительные платформы.
5. <<source>> файлы с исходным кодом программ, который должен пройти процедуру компиляции перед тем, как использоваться системой.
6. <<table>> хранилище данных, файлы доступа, базы данных, банки данных.

Интерфейсы.

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

26. Диаграмма развертывания: назначение, графическое представление.

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

Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.