21. UML-диаграмма прецедентов. Отношения между прецедентами.

Моделируемая система изображается в виде прямоугольника, внутри которого размещаются эллипсы, обозначающие прецеденты. В верхней части прямоугольника указано название моделируемой системы. Сам прямоугольник называют рамками системы (system boundary, subject boundary), контекстом или просто системой. Этот элемент диаграммы показывает границу между тем, что аналитик показал в виде прецедентов (внутри этих рамок), и действующими лицами (вне их). То есть внутри границы находятся прецеденты - тот функционал, который реализует система, а снаружи - действующие лица: пользователи и другие внешние сущности, взаимодействующие с моделируемой системой. Кроме рамок системы или ее контекста на диаграмме присутствуют еще два вида связанных с ней сущностей - это действующие лица (actors) и прецеденты.

Actor - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью (системой, подсистемой, классом). Актор может быть человеком, другой системой, подсистемой или классом, которые представляют нечто за пределами рассматриваемой сущности. Акторы "общаются" с системой путем обмена сообщениями. На диаграммах UML акторы изображаются в виде стилизованных человечков. Если же актор имеет атрибуты, которые важно показать, то его изображают в виде класса со стереотипом <<actor>>. Акторы не могут быть связаны друг с другом. Единственное допустимое отношение между акторами - генерализация ( наследование ).

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

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

Отношения между прецедентами:

• Обобщение (англ. Generalization, наследование) — моделирует соответствующую общность ролей. Изображается обобщение линией с "незакрашенной" треугольной стрелкой на конце. Обобщение - это отношение между предком и потомком, и стрелка всегда указывает на предка.

• Включение (англ. Include) — определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого всегда задействуется базовым вариантом использования. Изображается как зависимость (пунктирная линия со стрелкой) со стереотипом <<include>>. При этом стрелка направлена в сторону включаемого прецедента.

• Расширение (англ. Extend) — разновидность отношения зависимости между базовым вариантом использования и его специальным случаем (например оплата наличными, оплата кредитной картой являются расширением платы покупки). Изображается как зависимость со стереотипом <<extend>>.

При моделировании с использованием расширения можно указать как условия осуществления расширенного поведения, так и место - точку расширения прецедента, в которой подключаются действия из расширяющих прецедентов. Точка расширения описывается в дополнительном разделе прецедента, отделенном от его названия горизонтальной линией, причем описание начинается с ключевых слов Extension points: . Сопоставить конкретный расширяющий прецедент с определенной точкой расширения можно, прочитав условия расширения, указанные в комментариях, - само условие записывается после служебного слова "Condition:" в фигурных скобках, за которыми идет служебная фраза "Extension point:", и после нее указывается имя точки расширения.

• Ассоциация (англ. Association) — может указывать на то, что актор инициирует соответствующий вариант использования. Изображается в виде прямой линии от актора к прецеденту.

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

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

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

1. данные, называемые атрибутами (поля) – определяют структуру объекта. Значения атрибутов определяют состояние объекта.

2. объектные связи (разновидность атрибутов) – обозначают знания данным объектом других объектов (ассоциация).

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

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

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

Обычно атрибуты делают закрытыми (приватными) и для доступа реализуют методы set и get. Объекты, которые имеют только атрибуты и методы set/get/конструкторы называются немыми. Если большинство объектов немые, то программа не объектно-ориентированная.

Особенности объекта:

1. имя, по которому его можно отличить от других объектов;

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

3. объект обладает поведением, которое определяется его методами.

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

23. Основные принципы объектно-ориентированной разработки программ.

Ключевые принципы ООП:

1. все является объектами (не всегда можно соблюдать из-за ограничений языков, требований предметной области и т.д.).

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

3. каждый объект имеет независимую память, которая состоит из других объектов.

Принципы объектно-ориентированной методологии.

SOLID – аббревиатура 5 основных принципов проектирования классов в ООМ:

1. SRP (Single responsibility principle) – принцип единственной обязанности (одиночной ответственности) – на каждый объект системы должна быть возложена одна единственная обязанность. (обязанность – причина изменения объекта). Этот принцип основан на принципе высокой связности. Нарушение этого принципа – God object.

2. OCP (Open/closed principle) – принцип открытости/закрытости – программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения но закрыты для изменения. Нарушение – использование конкретных классов (объектов) без абстракции.

3. LSP (Liskov substitution principle) – принцип подстановки Барбары Лисков – объекты в программе могут быть заменены их наследниками без изменения свойств программы (функции, которые использует базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом).

4. ISP (Interface segregation principle) – принцип разделения интерфейса – множество специализированных интерфейсов лучше чем один универсальный. Клиенты (классы) не должны зависеть от методов, которые они не используют.

5. DIP (Dependency inversion principle) – принцип инверсии зависимостей:

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

• абстракции не должны зависеть от деталей, а детали должны зависеть от абстракций.

Нарушения:

• жесткость – изменение одного модуля ведет к изменению других;

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

• неподвижность – модуль очень сложно отделить от остальной части приложения для повторного использования.