Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
uml 1-12.docx
Скачиваний:
1
Добавлен:
26.09.2019
Размер:
136.34 Кб
Скачать
  1. Структура uml. Строительные блоки uml. Общие механизмы uml. Архитектура языка.

структура включает:

• строительные блоки – основные элементы, отношения и диаграммы UML модели;(сущности, отношения, диаграммы)

• общие механизмы – общие UML пути достижения определенных

целей;

• архитектура – UML представление архитектуры системы.

Архитектура отвечает за высокоуровневое представление системы в ее окружении. Самое распространенное описание архитектуры – это «4+1 представление»

логическое представление (Logical view);

представление процессов (Process view);

представление реализации (Development view);

представление развертывания (Physical view);

представление прецедентов (Scenarios).

  1. Унифицированный процесс разработки (up). Аксиомы up (итерация и инкремент). Структура up. Фазы up.

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

UP базируется на трех аксиомах. Он является:

• управляемым требованиями и риском;

• архитектурно центричным;

• итеративным и инкрементным.

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

  1. Метамодель требований предъявляемых к по. Моделирование прецедентов.

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

Моделирование прецедентов – это форма выработки требований.

Моделирование прецедентов обычно происходит следующим образом:

• Устанавливаются границы потенциальной системы.

• Выявляются актеры.

• Выявляются прецеденты:

• определяется прецедент;

• устанавливаются основные альтернативные потоки.

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

  1. Обобщение актеров. Обобщение прецедентов. Отношения «include» и «extend».

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

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

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

Отношение «extend» предоставляет возможность ввести новое поведение в существующий прецедент. Базовый прецедент предоставляет набор точек расширения (extension points) – точек входа, в которые может быть добавлено новое поведение. А расширяющий прецедент предоставляет ряд сегментов вставки, которые можно ввести в базовый прецедент в места, указанные точками входа. Как вскоре будет показано, отношение «extend» может использоваться для того, чтобы точно указать, какие именно точки расширения базового прецедента подлежат расширению.

  1. Архитектура ПО. Виды архитектур. Модели UML применяемые при описании архитектуры.

  2. Объекты в UML . Классы в UML. Нотация, область действия, создание и уничтожение объектов.

Объект как «отдельную сущность с явно выраженными границами, которая инкапсулирует состояние и поведение; экземпляр класса». Объекты объединяют данные и функциональность в единый блок. Объект можно представить как единый пакет данных и функциональности. Как правило, единственный путь добраться до данных объекта – вызвать одну из предоставляемых им функций. Эти функции называются операциями (operations). Сокрытие данных объекта за уровнем операций известно как инкапсуляция (encapsulation), или сокрытие данных (data_hiding).

Класс как «дескриптор набора объектов, имеющих одинаковые атрибуты, операции, методы, отношения и поведение». Подытожить это можно так: класс – это дескриптор набора объектов, имеющих одинаковые свойства. Класс описывает свойства ряда объектов.

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

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

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]