Ответы на вопросы к экзамену по Методам Программирования

1.Какие причины выводят проекты создания сложных систем за рамки

установленных сроков реализации и бюджетов?

1)сложность предметной области.

2)трудность управления командой разработчиков.

Впервые столкнулись специалисты по операционным системам.

Если в 10 раз увеличить число разработчиков, то производительность не увеличится в 10 раз.

3)недостаточная формализация технологии разработки (отсутствие общепринятых стандартов решений).

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

2. Как устраняется семантический разрыв между языками программирования и

описанием задачи?

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

Фундаментальная четвертая проблема решается теорией правильности работы программы – тестированием.

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

А единственным эффективным методом сокращения этих видов семантического разрыва видится приближение языков программирования к структуре и синтаксису естественных языков.

3. Что является концептуальной основой ООП?

Обязательные свойства объектной модели:

- абстрагирование.

Выделение существенных объектов и характеристик. - инкапсуляция.

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

- модульность.

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

- иерархия абстракции по уровню.

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

Дополнительные свойства:

типизация (ограничение взаимозаменяемости классов).

параллелизм (различие активного и пассивного состояния одного и того же объекта).

устойчивость (существование объекта во времени и пространстве независимо от системы его породившей).

4.Как разрабатывается ТЗ с использованием метода вариантов использования

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

Метод вариантов использования.

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

Обычно участвуют два лица.

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

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

Пример: Управление выращиванием.

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

Цель: Минимальное количество вариантов использования с максимальным охватом системы.

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

Для оформления заказа не всегда нужно запрашивать каталог – «расширение».

Для оформления заказа всегда нужно запрашивать каталог – «включение».

5.Как используется диаграмма классов?

Диаграмма классов.

Возможно внесение изменений в диаграмму и при этом они будут вноситься в кодогенерацию.

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

Диаграммы классов рассматриваются на трех уровнях:

1)На концептуальном уровне – диаграмма отражает понятия предметной области (названия, атрибуты (без типа), операции) и статические связи.

2)На уровне спецификаций – наличие шаблонов, приложений описания атрибутов и операций с учетом синтаксиса UML.

3)На уровне реализации – шаблоны становятся методами и приложениями. Разделение на уровни не является формальной частью языка UML, но используется на практике.

Диаграмма состояний изменения проектной системы.

Диаграмма классов (концептуальный уровень).

*,1 – показатели множественности.

Каждая ассоциативная связь может иметь две роли. Каждая роль представляет

собой направление ассоциативной связи, например, от класса «Клиент» к классу «Заказ», или наоборот.

Роли могут быть именованы. Если имя роли не указано, то оно принимается совпадающим с именем соответствующего класса.

Ассоциативные связи.

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

На уровне реализации ассоциативные связи – это указатели и ссылки. Где имеется * - там массивы указателей.

На уровне спецификаций вводится понятие ответственности.

Атрибуты.

-концептуальный уровень: имена.

-уровень спецификаций: <признак видимости(public, private, protected)><имя>:<тип(int, string, bool)>=<значение(7, 0)>

-у каждого атрибута может быть одно единственное значение.

Операции.

Синтаксис на уровне спецификации:

<признак видимости><имя>(список параметров):<тип>{строка свойств}

Список параметров – это описание атрибута.

Строка свойств – ограничение переменных, правила в произвольной форме (по аналогии с комментариями).

Операции разделяются на модификаторы и запросы.

Связь тип-подтип.

Концептуальный уровень: связь – «обобщение».

ВRR есть ряд стереотипов:

Actor –действующее лицо (все они классы). Имитирует взаимодействие, его методы влияют на ход выполнения.

BusinessActor – действующее лицо непосредственно связанное с решением бизнес - задач.

Boundary – ограничение.

Control – управляющий класс.

Entity – сущность.

BusinessEntity – бизнес-сущность.

BusinessWorker – исполнитель бизнес процессов.

Interface

Document.

Стереотипы делают диаграмму более наглядной.

6. Как используется множественная и динамическая классификация, агрегация и

композиция?

Множественная классификация.

Множественно наследование определяет только единственный тип произвольного класса.

Множественная классификация определяет набор типов.

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

На Диаграммах при множественном наследовании тип может иметь несколько супертипов.

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

База данных больницы (картотека).

Допустимые и недопустимые типы для личности.

Допустимые:

Ж, пациент, медсестра.

М, пациент.

Ж, доктор, хирург.

Недопустимые:

Пациент, доктор, хирург.

М, медсестра, физиотерапевт.

Динамическая классификация.

Меняется тип объекта.

На Диаграмме классов объединяются типы и их состояния.

Позволяет моделировать тип.

Служба занятости.

Объект меняет свой тип.

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

Динамическая возможность изменения используется на концептуальном уровне. Можно заменить на ассоциативные связи, но не динамические.

Агрегация и композиция.

UML предусматривает отношения между объектами «часть-целое» и позволяет различать их степень связи.

Степень связи части и целого.

oАгрегация определяет отношение «часть -целое». При моделировании предметной области такое отношение часто описывается (машина-двигатель).

Часть внутри целого и независимо от него.

oКомпозиция – отношение «часть-целое» в более строгом смысле. Образуется тогда, когда «часть» принадлежит единственному целому и его жизненный цикл совпадает с жизненным циклом целого. При удалении целого из системы удаляется и его часть.

Реализация многоугольника.

7. Как используется механизм пакетов UML?

Механизм пакета:

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

-В один пакет могут объединяться любые однородные объекты любой диаграммы.

-Можно исследовать зависимости между пакетами. Два пакета соединяются зависимостью, если изменение одного элемента одного пакета влечет изменение другого элемента из другого пакета.

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

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

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

2)Удается минимизировать работы по тестированию.