Поиск по сайту:



Проверить аттестат

Мы принимаем Яндекс.Деньги

Смотри также:

WEB-программирование (вопросы + шпоры + задачи) НГТУ - Вопросы к экзамену.

Вопросы к экзамену и шпоры по отраслевому менеджменту - Вопросы к экзамену.

Примерные ответы на тест по философии - Вопросы к экзамену.

Вопросы к экзамену по курсу "Философия" - Вопросы к экзамену.

Все новинки...

Вопросы к экзамену «Визуальное программирование (вопросы + шпоры)»

Где сдавалась работаБФ НГТУ
Файл: 146.41 КБ
Поделиться:

Вопросы к государственному экзамену по предмету "Визуальное программирование".

НГТУ АВТФ 5 курс кафедра ВТ

1. Цель моделирования бизнес процессов
Моделирование бизнес-процессов - изучение логики деятельности организации.
При моделировании бизнес-процессов исследуется: Структура организации; Роли сотрудников в этой структуре; Взаимосвязи между сотрудниками; Рабочие потоки в организации - главные процессы ее деятельности; Учитываются внешние организации, которые влияют на деятельность организации.
Полученный набор сведений и данных представляет собой бизнес-модель. Бизнес-модель - это формализованное графическое представление процессов, связанных с ресурсами и отражающих существующую или предполагаемую деятельность предприятия.
Моделирование бизнес-процессов позволяет документировать особенности организации и методы, которые использует организация для достижения своих целей. Моделирование может происходить на уровне отдельных отделов организации.
Цели бизнес-моделирования:
1. обеспечить понимание структуры организации и динамики происходящих в ней процессов;
2. обеспечить понимание текущих проблем организации и возможностей их решения;
3. создать базу для формирования требований к будущему ПО организации;
4. важная цель моделирования бизнес-процессов - обучение персонала;
понимание сотрудником (новым) роль протекающих в организации бизнес-процессов и свою роль в организации.

 

2. Понятие роли в моделировании (Роли в диаграмме прецедентов)
Бизнес-роль. Ее исполняет любой человек или подразделение, который является внешними по отношению к организации, но взаимодействуют с ней. Например, клиенты организации. Одну и ту же бизнес-роль могут играть разные сотрудники организации. Выявление: какие функции системы необходимы для обеспечения потребностей клиентов.
Сотрудник. Это роль внутри организации. Это не должность. Может исполнять 2 роли. Для выявления бизнес-ролей и ролей сотрудников на бизнес-диаграмме необходимо ответить на следующие вопросы:
- Какова ответственность сотрудника
- Как он взаимодействует с другими сотрудниками.
- В каких рабочих потоках он участвует
- Какие обязанности сотрудников в каждом из рабочих потоков

 

3.Назначение диаграмм прецедентов
Диаграмма деятельности в графической форме показывает этапы рабочего процесса, последовательности операций и тех, кто отвечает за их выполнение. На диаграмме показываются бизнес варианты использования, бизнес-роли, сотрудники и отношения между ними. Стрелки от бизнес-ролей или сотрудников к ВИ показывают, кто инициирует данный ВИ. Стрелки от ВИ к бизнес-роли показывают, что инициирует в организации коммуникации с данной ролью. Каждый ВИ является законченной последовательностью событий, в результате выполнения которой исполнитель получает некоторое значение.
Диаграмма прецедентов строиться для того чтобы:
1. определить границы и контекст моделируемой предметной области на начальном этапе проектирования информационной системы.
2. сформулировать общие требования функционального поведения проектируемой системы.
3. подготовить исходную документацию для взаимодействия разрабатываемой системы с её заказчиками и пользователями.
4. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров и отношений между этими элементами.

 

4. Понятие бизнес-сущности
Сущность - любой различимый объект, информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром - Москва, Киев и т.д.
Бизнес-сущность (business entity) - специальный случай класса-сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом <<business entity>>

 

5. Выявление актеров
Актеры - все, кто взаимодействует с разрабатываемой системой и находятся вне действия системы.
Первичные актёры - актёры, которые задействованы в основном потоке бизнес-организации
Вторичные актёры - актёры, связанные с обслуживанием системы.
Присваивая имена актёрам, следует учитывать роль, а не должность.
Варианты использования описывают все, что попадает в зону действия системы, а актёры - что находится вне границ системы.
Актеры способны выполнять различные функции в системе: вводить данные, выводить данные.
Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач.
При этом актеры служат для обозначения согласованного множества ролей, которые могут играть пользователи в процессе взаимодействия с проектируемой системой. Каждый актер может рассматриваться как некая отдельная роль относительно конкретного варианта использования. Стандартным графическим обозначением актера на диаграммах является фигурка "человечка", под которой записывается конкретное имя актера.
Актеры взаимодействуют с системой посредством передачи и приема сообщений от вариантов использования. Сообщение представляет собой запрос актером сервиса от системы и получение этого сервиса. В свою очередь, вариант использования служит для описания сервисов, которые система предоставляет актеру.
Определение сущности актера:
- В каком подразделении организации должна использоваться система
- Кто получает преимущества от внедрения системы в эксплуатацию
- Кто будет использовать систему, поставлять системе те или иные данные, обращаться к ним, вести их обновление или удаление
- Кто именно заинтересован в выполнении определенных функциональных требований
- Способен ли актер играть несколько ролей
- Разрешено ли нескольким субъектам выполнять одни и те же функции в системе
- Будет ли доступ из другой системы, будет ли система использоваться другими системами
- Кто будет администрировать систему

 

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

 

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

 

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

 

9. Отношение ассоциации
Отношение ассоциации отражает взаимодействие между актером и вариантом использования. Таким образом, это отношение устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. На диаграмме вариантов использования, так же как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта отношение может иметь кратность. Кратность ассоциации выражается целым числом, указывающим количество прецедентов или актеров, участвующих в данной ассоциации. По умолчанию принимается значение кратности, равное 1.
Отношение ассоциации - одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. Применительно к диаграммам вариантов использования ассоциация служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования. Другими словами, ассоциация специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. На диаграмме вариантов использования, так же как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь некоторые дополнительные обозначения, например, имя и кратность
В контексте диаграммы вариантов использования отношение ассоциации между актером и вариантом использования может указывать на то, что актер инициирует соответствующий вариант использования. Такого актера называют главным. В других случаях подобная ассоциация может указывать на актера, которому предоставляется справочная информация о результатах функционирования моделируемой системы. Таких актеров часто называют второстепенными. Более детальное описание семантических особенностей отношения ассоциации будет дано при рассмотрении других диаграмм в последующих лекциях.

 

10. Описание прецедентов Понятие потока событий
В краткое описание прецедентов вносят информацию о их назначениях. Такое описание обычно определяется на этапе задумки при выделении прецедентов для системы
С каждым прецедентом связаны определенные потоки событий, происходящие по мере того, как выполняется соответствующие функции системы. При описании потока определяются, что необходимо осуществить и игнорируется то, как это делается. Потоки делятся на основной и альтернативный. Схема потока событий должна содержать ответы на:
1) Как и когда прецедент инициируется и завершается?
2) Каким образом актеры взаимодействуют с системой?
3) Что представляет собой нормальная последовательность событий в прецеденте?
4) Существуют ли альтернативные потоки?
Для рассмотрения этих потоков необходимо ответить на:
1) Что делать, если интерфейс не предоставляет всё необходимое для выполнения данного прецедента?
2) Что делать, если события происходят раньше или позже, чем нужно по сценарию?
3) Как поступить, если произойдет сбой аппаратуры?
Описание потоков событий должно иметь следующие разделы:
1) в котором описываются основная информация (название, дата создания, изменения).
2) описываются предусловия - необходимое состояние или условие при котором должен выполняться вариант использования.
3) основной поток
4) альтернативный поток событий
5) постусловия - возможное состояние системы после выполнения прецедента.

 

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

 

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

 

14. Отношение включения Отношение расширения
Отношение расширения. Используется для того, чтобы выразить необязательное действие, которое может дополнять какой-то прецедент, при этом должна быть точка расширения, говорящая о наличии условия для расширения.
Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой, направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет"). Отношение расширения означает, что базовый элемент use case неявно включает поведение другого элемента use case в точке, которая определяется расширяющим элементом use case. Таким образом, исходная последовательность действий одного варианта использования расширяется посредством включения действий другого варианта использования.
Отношение включения между двумя ВИ указывает, что некоторое поведение в прецеденте включает в качестве составного компонента поведение другого прецедента.
Экземпляр одного ВИ выполняет последовательность действий, определяющую поведение экземпляра другого ВИ, после чего продолжает выполнение действий своего поведения.
Один вариант использования может быть включен в несколько других вариантов, а также включать в себя другие варианты.
Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом "include" ("включает").

 

15 . Отношение обобщения
Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется предком или родителем по отношению А, а вариант А - потомком по отношению к варианту использования В. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения, которых нет у родителя, а также уточнять или модифицировать наследуемые от них свойства поведения.. Графически данное отношение обозначается сплошной линией со стрелкой, которая указывает на родительский вариант использования. Эта линия со стрелкой имеет специальное название - стрелка "обобщение".
Между отдельными актерами также может существовать отношение обобщения. Данное отношение является направленным и указывает на факт специализации одних актеров относительно других. Например, отношение обобщения от актера А к актеру В отмечает тот факт, что каждый экземпляр актера А является одновременно экземпляром актера В и обладает всеми его свойствами. Здесь актер В - родитель, а актер А - потомок актера В. Означает, что экземпляр потомка может взаимодействовать с такими же прецедентами, как экземпляр родителя.

 

16. Принцип WAVE
Для включения в диаграмму варианта использования следует руководствоваться wave-критерием:
What - прецедент должен описывать что нужно сделать, а не как.
Actor - прецедент должен быть описан с точки зрения исполнителя, что он делает именно для актера.
Value - прецедент должен выдать исполнителю некоторое значение, актер должен получить значение.
Entire - последовательность событий должна быть единым, неделимым процессом.
17. Выявление объектов\классов
Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).
Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса. По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами и операциями.
Иногда в обозначениях классов используется дополнительный четвертый раздел, в котором приводится семантическая информация справочного характера или явно указываются исключительные ситуации. Даже если секция атрибутов и операций является пустой, в обозначении класса она выделяется горизонтальной линией, чтобы сразу отличить класс от других элементов языка UML.
Для выявления классов следует начать с изучения потока событий.
Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он может иметь свое собственное имя и конкретные значения атрибутов. В силу самых различных причин может возникнуть необходимость показать взаимосвязи не только между классами модели, но и между отдельными объектами, реализующими эти классы.

 

18. Типы объектов Имя объекта
Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия проявляются при указании имен объектов, которые в случае объектов обязательно подчеркиваются. При этом запись имени объекта представляет собой строку текста "имя объекта:имя класса", разделенную двоеточием. Имя объекта может отсутствовать, в этом случае предполагается, что объект является анонимным, и двоеточие указывает на данное обстоятельство. Отсутствовать может и имя класса. Тогда указывается просто имя объекта. Атрибуты объектов принимают конкретные значения.

 

19. Стереотипы классов
Стереотипы классов - это механизм, позволяющий разделять классы на категории. Например, основными стереотипами, используемыми в процессе анализа системы, являются: Boundary (граничный класс), Entity (класс-сущность) и Control (управляющий класс).
Стереотип позволяет разделить предметные области и классы можно относить к определенному стереотипу. Наиболее употребительными являются классы:
КЛАСС СУЩНОСТЕЙ. Моделирует структуру данных и поведение, отличающееся стабильным характером. Такой класс отражает: качество сущности реального мира и применяется для выполнения внутренних функций системы.
Классы сущностей не зависят от окружения, то есть не чувствительны к тому, каким образом внешние обстоятельства влияют на работу системы. Эти классы используют в системе для поддержания функций, относящихся к той или иной сфере деятельности. Создаются на этапе планирования.
ГРАНИЧНЫЕ КЛАССЫ
Обслуживают взаимодействия между системой и ее окружением, обеспечивая интерфейсы для пользователя и сторонних систем, то есть это та часть системы, которая непосредственно общается с внешним миром. Для того, чтобы отыскать граничный класс, надо проанализировать пару "актер-прецедент". Классы создаются на этапе планирования и определяют интерфейс, не вдаваясь в детали интерфейса.
КЛАСС УПРАВЛЕНИЯ
Находят применение при реализации характеристик поведения системы, присущих одному или нескольким вариантам использования и координируют события, происходящие в системе.
Класс управления - это абстракция, отражающая динамику варианта использования. Их создают для каждой пары "актер-прецедент". На них возлагается функция по контролю за потоками событий, происходящих при выполнении прецедента
ВСПОМОГАТЕЛЬНЫЕ КЛАССЫ
КЛАСС ИСКЛЮЧЕНИЙ

 

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

 

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

 

22. Видимость атрибутов и операций
Во второй сверху секции прямоугольника класса записываются атрибуты (attributes) объекта или свойства. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения:
<квантор видимости><имя атрибута>[кратность]:
<тип атрибута> = <исходное значение>{строка-свойство}
Квантор видимости может принимать одно из трех возможных значений и, соответственно, отображается при помощи специальных символов:
- Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.
- Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.
- И, наконец, знак "-" обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.
Квантор видимости может быть опущен. В этом случае его отсутствие просто означает, что видимость атрибута не указывается.
В третьей сверху секции прямоугольника записываются операции или методы класса. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка-свойство данной операции:
<квантор видимости><имя операции>(список параметров):
<выражение типа возвращаемого значения>{строка-свойство}
Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений. Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается.

 

23. Атрибуты класса Операции класса
Во второй сверху секции прямоугольника класса записываются атрибуты (attributes) объекта или свойства. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения
В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассматриваемый класс.
В третьей сверху секции прямоугольника записываются операции или методы класса. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам.
Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является единственным обязательным элементом синтаксического обозначения операции.

 

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

 

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

 

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

 

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

 

28. Сторожевые условия
Сторожевое условие, если оно есть, всегда записывается в прямых скобках после события-триггера и представляет собой некоторое булевское выражение.
Если сторожевое условие принимает значение "истина", то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение "ложь", то переход не может сработать, и при отсутствии других переходов объект не может перейти в целевое состояние по этому переходу.
Переходы на диаграмме деятельности
Если из состояния действия выходит единственный переход, то его можно никак не помечать. Если же таких переходов несколько, то при моделировании последовательной деятельности запускается только один из них. В этом случае для каждого из таких переходов должно быть явно записано собственное сторожевое условие в прямых скобках (см. лекцию 9). При этом для всех выходящих из некоторого состояния деятельности переходов должно выполняться требование истинности только одного из них.

 

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

 

30. Диаграмма состояний
Отображает состояние объекта и события вызывающие переход объекта из одного состояния в другое. Рассматривается на этой диаграмме что происходит, а не как. Диаграмма состояний описывает некий конечный автомат, поведение которого может быть представлено графом. Вершины этого графа - состояния, ориентированные дуги означают переход из одного состояния в другое. Поведение системы в таком графе моделируется путём от начальной вершины до конечной. Состояние в этом графе упорядочены, есть последующее и предыдущее.
Автомат характеризуется следующими свойствами:
1. Каждое состояние должно быть определено и число состояний конечно.
2. Граф не содержит изолированных вершин, каждый переход соединяет 2 состояния, в каждой вершине есть переход в последующую или в эту же вершину.
3. В каждый момент времени автомат находится в единственном состоянии.
4. Автомат не запоминает переход из состояния в состояние.
5. Время перехода на диаграмме состояний не учитывается и не существует перехода одновременно в 2 состояния.
Каждый из путей в графе соответствует определённому сценарию.

 

31. Тестирование и RUP
В случае спирального процесса (автор Барри Боэм,1988) последовательность анализ требований - проектирование - реализация - тестирование выполняется более одного раза.
Для этого может быть несколько причин:
- необходимость предупреждения рисков;
- необходимость предоставить заказчику частичную версию проекта для получения отзывов и пожеланий.
Версии продукта называют прототипами.
Каждый виток спирали соответствует созданию фрагмента или версии ПО.
Т.о. углубляются и последовательно конкретизируются детали проекта. В результате выбирается обоснованный вариант, который доводится до реализации.
Дополнительное преимущество: на каждом витке спирали можно собрать метрические характеристики проекта (трудоемкость затрат, затраты на проект, длительность, документированность).
Т.о. уточняется план-график дальнейшей работы.
Продукты, поддерживающие RUP:
1. Rational Requisite Pro - средство управление требованиями, позволяющее создавать, структурировать, устанавливать приоритеты, отслеживать и контролировать изменение требований, возникающих на любом этапе разработки.
2. Rational Clear Quest - продукт для управления, изменения и отслеживания дефектов в проекте. Он тесно интегрирует со средствами интеграции и управления требованиями и представляет собой единую среду для связи всех ошибок между собой.
3. Rational SODa - продукт для автоматической генерации документации.
4. Rational Clear Case. - продукт для управления конфигурацией программ, позволяющий поддерживать несколько версий одновременно.
5. SQA Team test - средство автоматизации тестирования.
6. Rational Robot - создание и модифицирование автоматического запуска тестов
7. Site Check - инструмент тестирования Web-сайтов на производительность и наличие неработающих ссылок.