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

▪​Flow формы

В результате процесс описывается множеством прямоугольников вложенных друг в друга (есть 3 основных следование, ветвление, цикл) ­ на бумаге рисовать не удобно, используются программы

­удобно для структурирования

­можно скрывать детали

Диаграммы атрибутов ​На ней описываются атрибуты сущности ­ключевые атрибуты (подчеркнуты); ­ домены назначения (обведены в овал) Пример: У кр карты, ​пароль​домен пароли, и ​номер счета​домен счета

STD (диаграммы переходов состояний) ​Рисуются состояния и переходы

Структурные карты Константайна

Для описания межмодульных взаимодействий ○→ ­ Связь по управлению, ●→ ­ Связь по данным, → ­ вызов модуля модуль | подсистема | библиотека

1­послед передача упр 2­параллел 3­сопр­ма 4­вызов модуля в цикле 5­условие 6­кратн вызов

O​MT​(Object Modeling Technique)

Технология ООА/П. Наиболее популярный до UML Минимальные различия с UML. Отличия в процессе анализа (ОМТ предполагает определенную последовательность действий)

В этой модели строятся 3 ортогональные модели:

1.Объектная модель, включается объектную диаграмму и словарь

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

3.Функциональная модель. Это DFD диаграммы и ограничения

Методика​анализа​Анализ по ОМТ – в построении вышеуказанных 3х моделей. Требования, знания в предм.обл, опыт ­> построение моделей­> ОМ, ДМ, ФМ Последовательность действий при ОО­анализе:

1.Постановка задачи, опр­ние цели, контекста системы, формулировка требований по качеству, производительности…

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

3.Построение динамической модели: а)описать сценарии типовых последовательностей взаимодействий в системе; б) выделить события и описать трассы событий; в)построить диаграммы состояний

4.Построение функциональной модели: а)определить вх. и вых. Данные; б)построить DFD­диагр и их детализировать; в) описать функции огр­ния критериев опт­ции.

5.Verify, iterate, Refine ­ проверить, повторить, улучшить

Методика проектирования ОМ, ДМ, ФМ ­> ООпроектир ­> архитектура, интерфейс пользователя, описание алгоритмов, описания БД

1)разделить систему на подсистемы; 2) идентифицировать параллельность; 3)распределить подсистемы по процессорам и задачам; 4)разраб алг­мы реализации всех процессов DFD и всех действий в диаграмме состояний; 5)реал­ть связи м/у объектами, хран­щихся в БД, методами реляционных БД

9. Методика Шлеера­Меллора

Из ответов

Методика Шлеера­Меллора.

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

Схема рабочих продуктов на примере АСУ железной дороги

Общий принцип ­ ​пошаговая детализация, описание поведения и структуры.

1.Информационное моделирование.

1.1​Выделить домены и установить мосты между ними.

Домен​­ отдельный мир, имеющий набор объектов со специфичным поведением.

Принципы выделения доменов:

1)каждый объект принадлежит только одному домену;

2)наличие объекта в одном домене треб сущ­ние др объектов в этом же домене; 3)наличие объекта в одном домене не требует сущ­ние других объектов в других доменах;

4) в разных доменах могут существовать объекты­двойники

Типы доменов

а) ​Прикладной домен​­ предм. область с точки зрения конечного пользователя, рассм­ся в контексте треб к будущей сис­ме;

б) ​Сервисные домены ​– обеспечивает механизма и ф­ции для поддержки функционирования объектов прикладного домена. ​Пр​­сигналы ­ для передачи сообщений и др данных об особых ситуациях, воник­х в сис­ме; ­процессы; ­процессы ввода/вывода­ обеспеч интерфейс с оборудованием; ­ польз интерфейс, архивация в) ​Архитектурный домен​­ обеспеч общие структуры данных и механизмы для упр­ния работой всей системы. ​Цель ­ придание однородности структуре ПО

(контейнеры, итераторы, графы)

г) ​Домены реализации ​Пр ОС, ЯП, сетевые интерфейсы Мост ­ ​связь между доменами по использованию.

Этап завершается построением схемы доменов

1.2​Сложные домены разбить на подсистемы (>50 шт => сложный).Начинается заполнение ​проектной матрицы

1.3​Для любой п/с определить и описать а) ​объекты ​(в качестве объекта следует рассматривать: ▪ реальные объекты (человек);

▪роли реальных объектов (студент);

▪ инциденты –абстракция происшедшего(зачет); ▪взаимодействия­объекты, получ в рез­те взаимод с др объектами;

▪спецификации (стандарты, критерии кач­ва, рецепты)

б) ​атрибуты​:

▪описать обл­ть допуст значений и тип;

▪вар­ты описаний ОДЗ: перечисления, дипазон, правила для опр­ния допуст значений. Типы атрибутов​:

▪​описательный ­ ​реальная характеристика объекта, абстрагируемого как атрибут. Изменение этого атрибута означает, что изменяется какой­то аспект объекта;

▪​указывающий​–для обозначения экземпляра объекта (часто это id или его часть). Его изменение означает изменение обозначения объекта.

▪​вспомогательный ­ ​для связи экземпляра одного объекта с экземплярами другого Правила для атрибутов​:

1.Любой атрибут имеет единственное значение в любой момент времени (нет атрибутов без значений)

2. Значение не должно содержать внутренние структуры 3. Если объект имеет составной идентификатор (из нескольких указывающих

атрибутов), то описательные атрибуты должны представлять характеристику всего объекта, а не его части.

в) ​связи​­ абстракция отношений, систематически возникающих между объектами (1:1, 1:n, n:m). Если добавить условность (не всем участвовать в связи), то возможны еще 7 типов связей.

­ 1:1 формализация вспомогательным атрибутом на любой стороне связи ­ 1:n формализация добавлением атрибута со стороны связи многие

­ n:m формализация добавлением нового ассоциативного объекта, содержащего необходимые вспомогательные атрибуты г) группы объектов вида «надтип­подтип»

Этап 1.3 заканчивается построением объектов, атрибутов, связей. Строится информационная модель подсистемы.

2​.Моделирование состояний

2.1​Определить ЖЦ всех экземпляров объектов в виде конечного автомата и построить диаграмму переходов.

Состояние объекта​­ положение объекта, в котором применим определенный набор правил поведения.

­состояние создания объекта. Объект создается по внешнему сигналу.

­неподвижное состояние (объект не может покинуть это состояние)

­обычное состояние

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

Событие​­ абстракция инцидента или сигнала, сигнализирующего об изменении состояния чего­либо. Инцидент может порождать несколько сигналов (и событий). Бывают: ­внутренние события; ­внешние ( запрашиваемые ­ последствия действий в объекте/системе; незапрашиваемые)

Действие ​– операция, которая должна быть выполнена, когда объект переходит в определенное состояние.

Результат 2.1 – модель состояний для объекта.

2.2​Определить ЖЦ динамических связей. Для этого выявить случай конкуренции объектов в установленной связи и формализовать их с помощью ассоциативного объекта со своей моделью состояния.

2.3​построение модели взаимодействия объектов и п/с

3.Моделирование процессов

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

Для любого действия строится диаграмма потоков данных, и действие разделяется на элементарные операции, которые называются «процессоры»

Типы процессов:

­аксессоры ­ обеспечивают к данным объекта

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

­преобразования

­проверки

10. UML. Элементы моделей, основные отношения

Элементы моделей UML

●примечание — неинтерпритируемый текст, присоединенный к нужному элементу модели.

Структурные элементы:

­Класс — описание группы сходных объектов, прямоугольник, разбитый на секции. Секции — имя класса, поля, методы.

Доп секция сопровождается обозначением названия в виде стереотипа (ключевое слово). Примеры доп. секций — exeption, signal и т. д. Число секций может меняться.

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

Пример:

­ связь реализации ­ зависимость по использованию

­Шаблон — описание класса с одним или более несвязанными формальными

­Утилита — группа глобальных переменных и функций так же как класс со

­Прецедент использования use case ­ модуль связанных функциональных возможностей вместе с действиями, выполняемыми системой. Изображается сплошным овалом. Как правило, прецедент реализуется в результате сотрудничества объектов.

Отношения в UML

1. Зависимость​(dependensy)

Изображается ­­­> A ­­­> B (A зависит от B)

Представляет семантическую связь между двумя элементами модели. Читается – этот элемент зависит​от этого. На зависимости может быть показан необязательный стереотип или имя. Виды зависимости уточняется с помощью стереотипа:

­friend – смысл как в C++

­bind – связь между формальными и фактическими переменными шаблона

­uses – использование. В общем случае в языках программирования не выражается.

2. Обобщение​(generalization)

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

Общий Частный​

C обобщением используются не стереотипы, а ограничения. A , B : A, C : A, B

3. Ассоциация

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

Проще ­ показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому. Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в».

Изображается сплошной линией.