Материал: ответы_экзамен

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

Ограничения (Constraints) расширяют семантику строительных блоков UML, позволяя определять новые или изменять существующие правила. Вы можете, например, ограничить класс EventQueue так, чтобы все события добавлялись в очередь по порядку.

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

8. Артефакты начальной фазы УП.

Начальная фаза (Inception) - заключается в определении бизнес-целей проекта. Определение целей и рамок проекта.

Артефакты, которые разрабатываются на начальной фазе:

• Видение проекта (описываются общие задачи проекта, ограничения, требования).

• Модель прецедентов (функциональные требования системы).

• Дополнительная спецификация (описываются другие типы требований).

• Словарь терминов (содержит ключевую терминологию по данной предметной области).

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

• План итераций (описывается, что предстоит сделать на итерациях проекта).

• Перечень документации (перечень документов, которые будут разрабатываться в данном проекте(обязательные).

9.Классификация требований к ПО (модель FURPS+).

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

1) Functionality (функциональные требования, возможности системы и т.д.);

2) Usability (удобство использования, справочная документация и т.д.);

3) Reliability (надежность, частота сбоев, возможность восстановления, предсказуемость поведения);

4) Performance (производительность, время отклика, точность и т.д.);

5) Supportability (возможность поддержки, конфигурирования);

6) Управление системой;

7) Требования к интерфейсам;

8) Проектные ограничения;

9) Юридические вопросы;

10) Требования к реализации.

10. Артефакты фазы развития.

1) Модель предметной области. Представляет собой визуализацию понятия предметной области;

2) Модель проектирования. Набор диаграмм, описывающих логику проектного решения;

3) Описание программной архитектуры. Документ, в котором рассмотрены основные архитектурные моменты и способы их реализации;

4) Модель данных. Включает схему БД и стратегию отображения объектов;

5) Модель тестирования. Описывает задачи и способы тестирования;

6) Модель реализации (Исх. код, БД, и т.д.);

7) Проектный интерфейс пользователя.

10. Модель прецедентов. Описание прецедентов.

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

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

Развернутый формат описания прецедента:

1) Название прецедента;

2) Основной исполнитель;

3) Заинтересованные лица и их требования;

4) Предусловие (это условия которые должны быть выполнены для успешного реализации сценария). Обычно выступает успешный результат выполнения сценария;

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

6) Основной успешный сценарий – описывается типичная последовательность действий приводящая к успешному завершению сценарию и удовлетворяет интересы всех заинтересованных лиц;

7) Расширение (альтернативные потоки). Здесь остальные сценарии приводящие к успешному или неудачному сценарию прецедента. Состоит из двух частей: условия и способ обработки.

10. Диаграмма прецедентов. Взаимосвязи прецедентов.

Диаграмма прецедентов включает в себя:

- Прецеденты;

- Исполнители (актеры);

- Ассоциации/зависимости;

- Примечания.

Прецедент - задача, выполняемая в течении одного сеанса.

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

Существуют следующие виды исполнителей:

- Основной исполнитель;

- Вспомогательный исполнитель;

- Offstage, закулисный исполнитель.

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

Актеры и прецеденты могут соединятся только отношениями ассоциации.

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

1) Не следует моделировать связи между исполнителями;

2) Не следует соединять непосредственно два прецедента (кроме отношений включения, расширения, обобщения);

3) Каждый прецедент должен быть инициирован актером;

4) БД рассматривается как слой, находящийся под диаграммой.

Взаимосвязи прецедентов:

1) Обобщение.

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

2) Включение

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

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

3) Расширение

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

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

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

10. Модель предметной области.

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

Модель предметной области — это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области.

На языке UML, модель предметной области представляется набором диаграмм классов.

На диаграмму выносятся концептуальные классы, ассоциации между ними и атрибуты концептуальных классов.

В модели не отображаются операции классов и артефакты программирования.

10. Диаграмма последовательностей (когда разрабатывается, преимущества, недостатки, система обозначений).

Диаграмма последовательностей разрабатывается на этапе анализа и проектирования.

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

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

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

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

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

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

Преимущества и недостатки:

+ ясно отображает последовательность и временной порядок сообщений

+ богатый набор обозначений

- занимает много места

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

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

Исполнитель – экземпляр участника процесса

Линия жизни показывает время, в течение которого объект существует в Системе.

15. Диаграмма коммуникации (кооперации) (когда разрабатывается, преимущества, недостатки, система обозначений).

Диаграмма коммуникации (англ. communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между объектами, а время как отдельное измерение не используется (применяются порядковые номера вызовов).

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

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

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

16. Классификация шаблонов (patterns).

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

· Архитектурные паттерны

· Паттерны проектирования

· Паттерны анализа

· Паттерны тестирования

· Паттерны реализации

1) Архитектурные паттерны (Architectural patterns) – множество предварительно определенных подсистем со спецификацией их ответственности, правил и базовых принципов установления отношений между ними. Архитектурные паттерны предназначены для спецификации фундаментальных схем структуризации программных систем. Наиболее известными паттернами этой категории являются паттерны GRASP (General Responsibility Assignment Software Pattern). Эти паттерны относятся к уровню системы и подсистем, но не к уровню классов. Как правило, формулируются в обобщенной форме, используют обычную терминологию и не зависят от области приложения.

2) Паттерны проектирования (Design patterns) – специальные схемы для уточнения структуры подсистем или компонентов программной системы и отношений между ними. Паттерны проектирования описывают общую структуру взаимодействия элементов программной системы, которые реализуют исходную проблему проектирования в конкретном контексте. Наиболее известными паттернами этой категории являются паттерны GoF (Gang of Four.

3) Паттерны анализа (Analysis patterns) – специальные схемы для представления общей организации процесса моделирования. Паттерны анализа относятся к одной или нескольким предметным областям и описываются в терминах предметной области. Наиболее известными паттернами этой группы являются паттерны бизнес-моделирования ARIS (Architecture of Integrated Information Systems), которые характеризуют абстрактный уровень представления бизнес-процессов. В дальнейшем паттерны анализа конкретизируются в типовых моделях с целью выполнения аналитических оценок или имитационного моделирования бизнес-процессов.

4) Паттерны тестирования (Test patterns) – специальные схемы для представления общей организации процесса тестирования программных систем. К этой категории паттернов относятся такие паттерны, как тестирование черного ящика, белого ящика, отдельных классов, системы. Паттерны тестирования иногда называют стратегиями или схемами тестирования.

5) Паттерны реализации (Implementation patterns) – совокупность компонентов и других элементов реализации, используемых в структуре модели при написании программного кода. Эта категория паттернов делится на следующие подкатегории: паттерны организации программного кода, паттерны оптимизации программного кода, паттерны устойчивости кода, паттерны разработки графического интерфейса пользователя и др.

17. Обязанности объектов. Шаблон Information Expert.

GRASP - это методический подход к объектному проектированию. Эти шаблоны называют также шаблонами распределения обязанностей.

В общем случае можно выделить два типа обязанностей.

1. Знание (knowing).

2. Действие (doing).

Обязанности, относящиеся к действиям объекта:

• Выполнение некоторых действий самим объектом, например создание экземпляра или выполнения вычислений.

• Инициирование действий других объектов

• Управление действиями других объектов и их координирование.

Обязанности, относящиеся к знаниям объекта:

• Наличие информации о закрытых инкапсулированных данных.

• Наличие информации о связанных объектах.

• Наличие информации о следствиях или вычисляемых величинах.

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

Если дизайн не удовлетворяет этому принципу, то при программировании получается спагетти-код, в котором очень трудно разбираться. Локализация обязанностей позволяет повысить уровень инкапсуляции и уменьшить уровень связанности. Кроме читабельности кода повышается уровень готовности компонент к повторному использованию.

18. Шаблон Creator.

Шаблон Creator решает, кто должен создавать объект. Фактически, это применение шаблона Information Expert к проблеме создания объектов.

Решение. Назначить классу B обязанность создавать экземпляры класса A, если выполняется одно из условий.

• Класс B агрегирует (aggregate) объекты A

• Класс B содержит (contains) объекты A

• Класс B записывает (records) экземпляры объектов A

• Класс B (closely uses) объекты A

• Класс B обладает данными инициализации (has the initializing data), которые будут передаваться объектам A при их создании (т.е. при создании объектов А класс В является экспертом)

Если выполняется несколько из этих условий, то лучше использовать класс В, агрегирующий или содержащий А.

Проблема. Кто должен отвечать за создание нового экземпляра некоторого класса?

Пример с Sale, SalesLineItem и ProductSpecification. Поскольку Sale агрегирует SalesLineItem, то должна содержать метод makeLineItem.

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

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

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

19. Шаблон Low Coupling.

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

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