Ответы на билеты

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

●Цепочка обязанностей

●Команда, Action, Transaction

●Интерпретатор

●Итератор

●Посредник

●Хранитель

●Наблюдатель

●Состояние

●Стратегия

●Посетитель

●Шаблонный метод

5.Частные (шаблоны параллельного программирования) ​Используются для более эффективного написания многопоточных программ, и предоставляет готовые решения проблем синхронизации.

На наивысшем уровне существуют​архитектурные шаблоны​, они охватывают собой архитектуру всей программной системы.

6. Rational Unified Process

Использовал: https://ru.wikipedia.org/wiki/Rational_Unified_Process http://www.interface.ru/rational/interface/151199/rup/main.htm

Rational Unified Process (RUP)​— методология разработки программного обеспечения,

Воснове RUP лежат следующие принципы:

●Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

●Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

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

●Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

●Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

●Работа над проектом в сплочённой команде, ключевая роль в которой

принадлежит архитекторам.

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

Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций:

1. Начальная стадия

Вфазе начальной стадии:

●Формируются видение и границы проекта.

●Создается экономическое обоснование (business case).

●Определяются основные требования, ограничения и ключевая функциональность продукта.

●Создается базовая версия модели прецедентов.

●Оцениваются риски.

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

2. Уточнение

Вфазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:

●Документирование требований (включая детальное описание для большинства прецедентов).

●Спроектированную, реализованную и оттестированную исполняемую архитектуру.

●Обновленное экономическое обоснование и более точные оценки сроков и стоимости.

●Сниженные основные риски.

Успешное выполнение фазы разработки означает достижение этапа жизненного цикла архитектуры.

3.Построение

Вфазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности.

4.Внедрение

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

Основные потоки работ описаны в терминах работников, действий и артефактов.

●Работник​определяет поведение и ответственности индивидуума или нескольких индивидуумов, работающих вместе как группа. Это ­ важное отличие, потому что обычно о работнике думают как о конкретном человеке или группе. В Rational Unified Process, работник ­ больше роль, которая определяет, как индивидуумы должны выполнять работу.

●Действие​­ это самая маленькая часть работы, которая относится к делу; его можно интерпретировать как «техническую операцию» работника. Далее, невозможно выполнить только часть действия, хотя в пределах действия может существовать некоторая необязательная операция. Такое разделение работы

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

●Артефакты​­ искусственные объекты (конструкции моделирования и документы), которые действия выделяют, поддерживают или используют как исходную информацию.

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

7. Общая характеристика этапов анализа, проектирования и реализации программного обеспечения

Анализ

Цель: моделирование предметной области в терминах объектов классов.

Три фазы анализа:

●

Информационное

моделирование; идентификация объектов,

атрибутов,

связей.

●

Моделирование

жизненного цикла объектов в терминах

диаграмм

перехода из состояния в

состояние

●

Моделирование

процессов, алгоритмизация процессов

в

состояниях

и/или переходах.

Методики анализа.

1.

CRC­карточки

(Class­Responsibility­Collaboration) —

Класс­Взаимодействия­Сотрудничества (в лекциях ­ класс ответственности

участников).

Название класса

Действия, которые

он

Классы, с которыми данный

класс

выполняет

обменивается информацией

должен

Слева карточки

записывается ​ответственность

класса

–

что

класс

делать. Справа

карточки отмечается ​связи

класса

–

что

другие

классы

делают при взаимодействии с ними

«Организационное

мероприятие типа обзора кода» применяется на

ранних

этапах в коллективах, слабо

знакомых с объектными технологиями.

2.

Метод

неформального описания.

Все текстовые

документы по предметной области

переводятся

в

электронный вид, затем

подвергаются синтаксическому анализу

с

целью

выделения существующих глаголов

и их связей, после чего формируется

первичный словарь предметной области (классы — из существительных, методы								—
из глаголов). Применимо для предметных				областей,		слабо	знакомых
разработчику.
3. Структурный			анализ.
Основан на	функциональной и алгоритмической				декомпозиции. Начинается все
с построения словаря, строится контекстная диаграмма						типа		DFD,
детализируется.		По результатам корректируется словарь.
4. Объектно­ориентированный анализ (ОО­анализ).
Основан на	объектной декомпозиции.
Исходные данные: требования к проекту, знания разработчика и жизненный опыт.
Последовательность:

1.	Постановка	задачи, определение целей, контекста системы, требований к
производительности.
2	Построение	объектной модели:
­	выделение	объектов и классов
­	создание	словаря
­	выделение	связей между объектами

­определение атрибутов, объектов и связей

­упрощение структуры классов и организация наследования

­проверка, что для любого запроса есть путь реализации

­iterate – повторить.

3.Построение динамической модели:

­построение сценария для типовых последовательностей взаимодействия объектов

­выделение событий и трасс событий

­построение диаграмм событий

4.	Построение	функциональной модели:
­	определить	входные/выходные данные

­построить DFD и детализировать их

­описать функции, ограничения, критерии оптимизации

5.Verify, iterate and refine

Проектирование. ​V(О_О)V ¯\_( )_/¯ (​ )​

Цель: разработка абстракций и механизмов реализации поведения модели.

2подхода:

1.Рекурсивное проектирование. Артефакты проектирования полуавтоматически строятся на основе артефактов анализа.

2.Автономное проектирование. Данные, полученные при анализе точно

учитываются при

проектировании.

Методика ОО­проектирования. На входе три модели, на выходе:

●архитектура

●описание БД

●проектир. интерфейса

●алгоритмы Последовательность:

1. Разделить систему на подсистемы

2. Идентифицировать последовательность

3. Распределить подсистемы по процессорам

4. Разобрать алгоритмы реализации всех процессов DFD и всех действий в диаграмме состояний

5. Реализовать свои методы объектов, хранящихся в БД методами	теории
реляционных БД.

Реализация

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

Сравнение существующих методологий и САSE. http://www.math.spbu.ru/user/dkoznov/papers/Real_General.pdf

https://habrahabr.ru/sandbox/43802/

Не уверена, что это то, что надо, но это все, что было найдено по сабжу.

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

1.Функциональную структуру системы;

2.Последовательность выполняемых действий;

3.Передачу информации между функциональными процессами;

4.Отношения между данными.

Наиболее распространенными моделями первых трех групп являются:

●функциональная модель SADT (Structured Analysis and Design Technique);

●модель IDEF3;

●DFD (Data Flow Diagrams) ­ диаграммы потоков данных.

Метод SADT ​представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой­либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес­процессов). Достоинствами применения моделей SADT для описания бизнес­процессов являются:

●полнота описания бизнес­процесса (управление, информационные и материальные потоки, обратные связи);

●жесткие требования метода, обеспечивающих получение моделей стандартного вида;

●соответствие подхода к описанию процессов стандартам ISO 9000.

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

Метод моделирования IDEF3 ​предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимости между ними. Хотя IDEF3 и не достиг статуса федерального стандарта США, он приобрел широкое распространение среди системных аналитиков как дополнение к методу функционального моделирования IDEF0 (модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции).

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

Диаграммы потоков данных (Data Flow Diagrams ­ DFD) ​представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления ­ продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Эти разновидности средств структурного анализа примерно одинаковы с точки зрения возможностей изобразительных средств моделирования. При этом одним из основных критериев выбора того или иного метода является степень владения им со стороны консультанта или аналитика, грамотность выражения своих мыслей на языке моделирования. В противном случае в моделях, построенных с использованием любого метода, будет невозможно разобраться. Наиболее распространенным средством моделирования данных (предметной области) является ​модель

"сущность­связь" (Entity­Relationship Model ­ ERМ). Она была впервые введена Питером Ченом в 1976 г. Эта модель традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. Одна из разновидностей модели "сущность­связь" используется в методе IDEF1Х, входящем в семейство стандартов IDEF и реализованном в ряде распространенных CASE­средств

Концептуальной основой объектно­ориентированного анализа и проектирования ПО (ООАП) является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность и иерархия) и понятия (объект, класс, атрибут, операция, интерфейс и др.). Большинство современных методов ООАП основаны на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно­экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

UML обладает механизмами расширения, предназначенными для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его метамодель. Наличие механизмов расширения принципиально отличает UML от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD и ERM. Перечисленные языки моделирования можно определить как сильно типизированные (по аналогии с языками программирования), поскольку они не допускают произвольной интерпретации семантики элементов моделей. UML, допуская такую интерпретацию (в основном за счет стереотипов), является слабо типизированным языком.

Сравнение CASE­средств

Это уж совсем что­то бесполезное, но пусть будет. http://sancase.narod.ru/Articles/UkUML.files/Part1.htm

8. Структурный подход к разработке программного обеспечения

Из ответов

Структурный подход в целом позволяет:

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

2.Расширение Ворда­Меллера и Хартли применяется для проектирования СРВ, основано на исполнении диаграмм переходов состояний, схем потоков управления, деревьев и таблиц решений

3.ER­диаграммы в нотациях Чена и Баркера используются для проектирования структур данных схем БД и т.д.

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

Декомпозиция в структурном подходе

Словарь – описывается в форме: имя потока тип атрибуты

Спецификация процессов

Применяется когда дальнейшая детализация невозможна, т.е. процесс по сути алгоритм.

Способы спецификации: ▪блок­схема; ▪псевдокод; ▪таблицы решений

▪словесное описание; ▪код на ЯП; ▪деревья решений: