Прецеденты - это широко используемый механизм осмысления и формулировки требований (особенно функциональных). Они оказывают влияние на множество аспектов проекта, включая ООА/П.
Описание прецедентов - отличный метод осмысления и формулировки требований, указывающие на то, что должна делать система. В свою очередь, требования - это весь набор прецедентов, т.е. модель функционирования системы и ее окружения
Прецеденты — это механизм упрощения этапа формулировки требований для всех заинтересованных лиц. Основная идея состоит в исследовании и формулировке функциональных требований путем написания историй "из жизни системы". В принципе, описать прецеденты не сложно, хотя достаточно трудно определить, что требуется от системы и описать это на нужном уровне детализации.
Исполнитель (actor)- сущность, обладающую поведением. Исп. являются внешними по отношению к системе, но участвуют в процессе, описываемом прецедентом. Например, роли, исполняемые людьми: роль клиента.
Связи исполнителей:
1. коммуникация с прецедентом (communication);
2. обобщение (generalization).
Сценарий (scenario) - это специальная последовательность действий или взаимодействий м/у исполнителями и системой. Его иногда также называют экземпляром прецедента. В принципе, прецедент (use case) — это набор взаимосвязанных успешных и неудачных сценариев, описывающий использование системы исполнителем для решения одной из задач. Для описания прецедентов используется диаграмма прецедентов (Use case diagram).
27. Опишите стадию анализа в разработке ПО. Отличие стадии анализа от стадии планирования и стадии проектирования.
Цель анализа - представить модель поведения системы. На данном этапе не занимаются проектированием классов, представлением или другими тактическими решениями. Анализ должен объяснить, что делает система, а не то, как она это делает. В этом уже появляется различие между анализом и проектированием. В анализе мы выявляем классы и объекты (их роли, обязанности и взаимодействия). В проектировании мы создаем актеров, которые реализуют поведение, требуемое анализом. Т.о., анализ - это деятельность, которая объединяет вместе пользователей и разработчиков системы в понимании предметной области.
На стадии анализа необходимо выяснить функциональные точки системы, которые обозначают видимые извне и поддающиеся проверке элементы поведения системы. Ф-ые точки представляют преобразования, совершаемые системой.
Полный анализ необходим для того, чтобы можно было проследить ход проекта. Возможность проследить проект является основой управления риском. Имея возможность проследить процесс от функциональных точек до реализации, гораздо легче оценить влияние возможных рисков на архитектуру.
Результатом анализа должно быть описание назначения системы, здесь же описание характеристик производительности и перечисление требуемых ресурсов. В о-о проектировании такие описания получают с помощью сценариев. Диаграммы объектов должны демонстрировать взаимодействие объектов и упорядоченный процесс этого взаимодействия. Также рассматриваются диаграммы классов (чтобы показать существующие ассоциации между классами объектов) и состояний (чтобы показать ЖЦ важнейших объектов).
Результаты анализа объединяют в один документ, который формулирует требования анализа к поведению системы, иллюстрируя их построенными диаграммами. А также результатом анализа будет оценка риска, обнаружение которого в начале процесса проектирования облегчит работу на поздних этапах разработки.
Прежде, чем взяться за разработку новой системы, обычно изучают уже существующие.
28. Концептуальная модель. Понятия. Понятия-спецификации. Идентификация понятий. Два простых правила.
Концептуальная модель - представление понятий в терминах предметной области. Концептуальная модель не является моделью программных компонентов. Модель предметной области - это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области.
Последовательность создания концеп. модели:
1. Создается список понятий кандидатов
2. Отобразить их на диаграмме классов
3. Добавить ассоциации
4. Добавление атрибутов.
Понятия - представление идеи или объекта.(название класса). Идентификация понятий следует из описания прецедентов. На начальной стадии идентификации некоторые концептуальные классы упускаются из виду, а появляются позднее, при рассмотрении атрибутов и ассоциаций. Обнаруженные новые понятия добавляются в модель предметной области.
Понятие спецификация обычно используется при описании предметной области.
Понятие - спецификация требуется в случае, когда:
1. Существует необходимость описания элементов независимо от существования конкретных экземпляров объектов.
2. Если удаление экземпляров описываемых им понятий приводит к потере важной информации в связи с некорректной ассоциацией этой информации с удаляемым экземпляром.
3. Если при наличии понятия устраняется дублирование информации.
Два простых правила.
1. Если некоторый объект Х в реальном мире не является числом или строкой (текстом), то это скорее всего понятие, а не атрибут.
2. Если вы сомневаетесь в разграничении понятий и атрибутов, создавайте отдельный концептуальный класс (понятие). Атрибуты редко отображаются в концептуальной модели.
Концептуальная модель - представление понятий в терминах предметной области. Концептуальная модель не является моделью программных компонентов. Модель предметной области - это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области.
Последовательность создания концеп. модели:
1. Создается список понятий кандидатов
2.Отобразить их на диаграмме классов
3.Добавить ассоциации
4.Добавление атрибутов.
Ассоциация- это связь м/у типами (м/у экземплярами типов), отражающая некоторое значимое и полезное отношение м/у ними.
Значок ассоциации соединяет два класса и означает наличие семантической связи м/у ними.
Каждый конец ассоциации называется ролью. Роль дополнительно может иметь:
· Имя (имена ассоциаций должны начинаться с прописной буквы, т.к. ассоциация обычно представляет классификатор связей м/у экземплярами)
· Кратность (определяет, сколько экземпляров класса А может быть ассоциировано с одним из экземпляров класса В. Значение кратности определяет, сколько экз-ов одного класса может быть корректно связанно с экземпляром др. класса в некоторый конкретный момент, а не на всем промежутке времени. Например, 0 или больше;"много")
· Направление связи (у каждой ассоциации может быть выставлено направление - одно- или двунаправленное; м/у двумя типами может быть установлено несколько асс-ций)
Значок наследования, представляющего отношение "общее/частное", выглядит как значок ассоциации со стрелкой, которая указывает от подкласса к суперклассу. В соответствии с правилами выбранного языка реализации, подкласс наследует структуру и поведение своего суперкласса
Значок агрегации обозначает отношение "целое/часть" (связь "has") и получается из значка ассоциации добавлением ромбика на конце, обозначающем агрегат. Экземпляры класса на другом конце стрелки будут частями экземпляров класса-агрегата. Агрегация не требует обязательного физического включения части в целое.
Поиск ассоциации.
1. А является физической частью В.
2. А является логической частью В.
3. А физически содержится в/на В.
4. А логически содержится в В.
5. А является описанием В.
6. А является элементом транзакции или отчета В.
7. А известен зарегистрирован / записан / включен в В.
Концептуальная модель - представление понятий в терминах предметной области. Концептуальная модель не является моделью программных компонентов. Модель предметной области - это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области.
Последовательность создания концеп. модели:
1. Создается список понятий кандидатов
2. Отобразить их на диаграмме классов
3. Добавить ассоциации
4. Добавление атрибутов.
Атрибут- это абстрактное свойство объекта. На концептуальной модели добавляются простые атрибуты: строковые, скалярные, перечисляемые. Атрибуты, для которых определены соответствующие требования или для которых необходимо хранить определенную информацию. Атрибуты помещаются во второй раздел условного обозначения класса.
Атрибуты не должны использоваться для связи концептуальных классов в модели предметной области.
31. Диаграммы последовательностей на этапе анализа системы. Системные события. Алгоритм построения диаграммы последовательностей.
Одной из частей того, какие действия выполняет система, без определения механизма их реализации, является диаграмма последовательностей. Прецеденты определяют, как исполнители взаимодействуют с программной системой. Диаграмма последовательностей (Sequence Diagram) предназначена для отображения временных зависимостей, возникающих в процессе общения м/у объектами. Диаграмма строится как график и имеет два измерения. По вертикали откладывается время, по горизонтали отображаются объекты. Она состоит из следующих элементов:
- объект, обозначается прямоугольником с записанным в нем именем объекта;
- линия жизни объекта, штрих - пунктирная линия, выходящая из объекта и расположенная вдоль оси времени, обозначает время жизни объекта,
- активация, тонкий вертикальный прямоугольник, расположенный вдоль оси времени объекта, обозначающий период активной жизни объекта, либо выходит из объекта,
- вызов метода поведения объекта (сообщение), обозначается стрелкой м/у активациями объектов с именем действия, направление стрелки задает направление передачи данных,
- текстовые метки (отметки времени, описание действий и т.п.)
На диаграмме последовательностей отображаются системные события сценария некоторого прецедента. Системное событие- это событие высокого уровня, генерируемое внешним исполнителем (события с внешним входом). Системными событиям (и связным с ними системными операциями) имена нужно присваивать осмыслено, а не в терминах входных физических носителей данных или управляющих элементов пользовательского интерфейса. Системные события связаны с системными операциями, т.е операции выполняемыми системой в ответ на события.
32. Этап проектирования программного обеспечения. Основные артефакты.
Создание проекта начинается с формирования принципов использования системы. Реализация этого этапа позволяет идентифицировать внешних пользователей, блоки использования, объекты системы и связи м/у ними.
Составляется диаграмма использования, отражающая внешнее функционирование создаваемой системы.
Для каждого блока использования строится диаграмма последовательностей, на которой отображается взаимодействие во времени объектов, выполняющих поставленную задачу. Каждый объект на диаграмме последовательностей сопровождается именем класса, к которому он принадлежит. Конкретный объект является экземпляром некоторого класса. Классы образуют логическую структуру системы.
Разработка логической структуры. В Rational Rose он именуется "Logical View". Результатом данного этапа должна стать главная диаграмма, и детализирующие диаграммы для ее элементов.
На этом этапе следует определить классы, которые необходимы в системе. Экземпляры этих классов уже указаны на диаграммах последовательностей. Классы и их связи отражается в модели в виде диаграммы классов. Для каждого класса задается спецификация, описывающая состав атрибутов и методов, связи, шаблон, на основе которого создан класс, и особенности реализации. Наличие шаблонов позволяет легко создавать классы различной структуры.
Кроме диаграмм классов, для описания логики системы применяются на данном этапе применяются диаграммы состояний, диаграммы сценариев и другие элементы языка UML
Проектирование физической структуры приложения. Классы, описанные на предыдущем этапе, связываются с физическими компонентами программы при помощи диаграмм компонент.
Последним этапом в проектировании ПО является подготовка диаграммы развертывания.
Артефактом называется любой результат работы: код, схема БД, текстовые документы, диаграммы, модели и т.д. Артефакт — это не документ или диаграмма, а процесс осмысления, анализа и разработки (с последующей записью результатов во избежание повторения или забывания). Артефакты лучше зафиксировать с помощью цифровой техники и в интерактивных документах.
