Этап 3: Определение атрибутов классов

Атрибуты являются свойствами объектов, таких, как имя, вес, скорость или цвет. При выделении атрибутов, следует учитывать следующие определения:

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

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

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

Этап 4: Выделение операторов (методов) классов.

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

При выделении операторов, следует учитывать следующие определения:

1. Метод класса должен быть свойственным тому классу, где он определен.

2. Отметим, что для обеспечения доступа к методу извне содержащего его класса может быть осуществлен только в том случае, если метод описан с открытыми (Public) правами доступа. Закрытые (Private) методы также обычно инициируются открытыми методами.

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

4. Исключение из правила принадлежности метода классу составляют методы по созданию и удалению объектов класса. Подобные методы не могут быть включены в класс, так как класс не может вызвать метод создания собственного объекта. Создание объекта класса может произойти лишь извне, то есть из другого класса.

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

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

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

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

Включает следующие элементы:

• Actor (актер)

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

Обычно значком Actor обозначают объект, который:

• взаимодействует с системой или использует систему;

• передает или принимает информацию в систему;

• является внешним по отношению к системе.

• варианты (прецеденты)

• Связи

Unidirectional Association (однонаправленная связь)

Данный инструмент позволяет обозначать связи между элементами. На диаграмме Use Case эти связи могут быть определены между use case и actor.

Значок Unidirectional Association позволяет создать однонаправленную связь класса с классом или класса с интерфейсом.

Dependency or instantiates (зависимость или реализация)

Значок Dependency or instantiates позволяет создать связь зависимости. Установка этого типа связей показывает, что класс ис­пользует другой класс как параметр в одном из методов.

Generalization (наследование)

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

Типы вариантов использования:

1. критичные (выбираются из ключевых, ложатся в основу архитектуры)

2. ключевые (без которых система не имеет смысла)

3. обычные

Создание диаграммы вариантов использования

Этап 1:

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

Этап 2:

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

Совет:

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

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

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

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

Этап 3:

Следующим важным шагом является создание связей между Актерами и вариантами использования.

Совет:

• Ассоциацию “Пользователь - Вариант использования” отображает связь использования. Обратная ассоциация «Вариант использования – пользователь” показывает, что “Вариант использования” при инициализации передает некоторую информацию пользователю.

• Не забывайте о том, что каждый пользователь на диаграмме представляет собой «Роль», которую играет тот или иной внешний объект. Причем один и тот же человек может играть несколько ролей в системе.

Правила построения вариантов использования:

1. диаграмма вариантов использования не учитывает временную последовательность.

2. Каждый вариант использования должен быть инициирован действующим лицом за некоторыми исключениями: включения и расширения.

3. нельзя моделировать связь между действующими лицами

Правила выявления вариантов использования:

• что пользователь хочет делать с системой?

• будет ли пользователь работать с информацией с помощью системы?

• нужно ли информировать о внешних событиях?

• должна ли система информировать пользователя о внешних событиях?

Как убедиться в том, что выявлены все варианты использования?

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

2. учтено ли, как будет работать с системой каждое заинтересованное лицо

3. какую информацию будет передавать системе каждое заинтересованное лицо

4. какую информацию будет получать от системы каждое заинтересованное лицо

5. учтены ли вопросы, связанные с эксплуатацией

6. учтены ли все внешние системы, которые будут взаимодействовать нашей

7. какой информацией будет обмениваться каждая внешняя система с нашей