Hi! My name is Damir. I’m co-founder at IFAB.ru and i’m pretty good at these scary things

  • Startups
  • E-Commerce
  • Process development
  • Process implementation
  • Project management
  • Financial modeling
  • Business strategy

You can reach me out via these networks

Are you hiring? Check out my CV

My CV page

Билеты по ООАиП

>> Ответы на вопросы по курсу ООАиП (Не билеты) <<
[anti-both] БИЛЕТ № 1

1. Классификация подходов к программированию.
Классификация подходов к программированию.
Основные подходы к программированию:
• структурный, модульный;
• функциональный;
• логический;
• объектно-ориентированный (ООП);
• смешанный (комбинированный, интегрированный);
• компонентно-ориентированный (Java, .NET);
• чисто объектный

Декларативные языки программирования
Время появления: 1960-е г.г.

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

Примеры:
LISP (Interlisp, Common Lisp, Scheme), SML, Haskell, Prolog

Императивные (процедурные)
языки программирования
Время появления: 1950-е г.г.

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

Функциональные языки программирования
Время появления: 1960-е г.г.

Краткая характеристика:

программа – функция, аргументы которой, возможно, также являются
функциями

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

Недостатки:
• нелинейная структура программы;
• относительно низкая эффективность

Примеры:
LISP, SML, CaML, Haskell, Miranda, Hope

Объектно-ориентированные языки программирования
Время появления: 1970-е г.г.
Краткая характеристика:
программа – описание объектов, их совокупностей, отношений между ними
и способов их взаимодействия
Преимущества:
• интуитивная близость к произвольной предметной области;
• моделирование сколь угодно сложных предметных областей;
• событийная ориентированность;
• высокий уровень абстракции;
• повторное использование описаний;
• параметризация методов обработки объектов
Недостатки:
• сложность тестирования и верификации программ

Примеры:
C++, Java, Visual Basic, C#, Eiffel, Oberon
2. Понятие связности.

Связность или сцепление (англ. cohesion) — характеристика внутренней взаимосвязи между частями одного модуля. Связность модуля – это мера зависимости его частей. Чем выше связность модуля, тем лучше результат проектирования.

Всего существуют семь типов связности:

-> Связность по совпадению.
Это когда в модуле отсутствуют явно выраженные внутренние связи.

-> Логическая связность.
Части модуля объединены по принципу функционального подобия.

-> Временная связность.
Части модуля не связаны, но необходимы в один и тот же период времени. Очень часто временную связность можно наблюдать в функциях, инициализирующих систему, уж очень велико желание запихать все в одно место!

-> Процедурная связность.
Части модуля связаны порядком выполняемых ими действий. Бывает путаю данный тип связности с временной связностью.

-> Коммуникативная связность.
Части модуля связаны по данным. Не знаю как у тебя, а у меня постоянно есть соблазн запихать все данные в одну структуру и передавать в каждую функцию все подряд. На самом деле очень порочное желание и делать так, конечно же, не стоит!

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

-> Функциональная связность.
Части модуля вместе реализуют одну функцию.


БИЛЕТ № 2

1. Особенности подхода ООАиП.
При объектно-ориентированном подходе программа представляет собой описание объектов, их свойств (или атрибутов), совокупностей (или классов), отношений между ними, способов их взаимодействия и операций над объектами (или методов).
Несомненным преимуществом данного подхода является концептуальная близость к предметной области произвольной структуры и назначения. Механизмнаследования атрибутов и методов позволяет строить производные понятия на основе базовых и таким образом создавать модель сколь угодно сложной предметной области с заданными свойствами.
Еще одним теоретически интересным и практически важным свойством объектно-ориентированного подхода является поддержка механизма обработки событий, которые изменяют атрибуты объектов и моделируют их взаимодействие в предметной области.
Перемещаясь по иерархии классов от общих понятий предметной области к более конкретным (или от более сложных – к более простым) и наоборот, программист получает возможность изменять степень абстрактности или конкретности взгляда на моделируемый им реальный мир.
Использование ранее разработанных (возможно, другими коллективами программистов) библиотек объектов и методов позволяет значительно сэкономить трудозатраты при производстве программного обеспечения, в особенности, типичного.
Объекты, классы и методы могут быть полиморфными, что делает реализованное программное обеспечение более гибким и универсальным.
Сложность адекватной (непротиворечивой и полной) формализации объектной теории порождает трудности тестирования и верификации созданного программного обеспечения. Пожалуй, это обстоятельство является одним из самых существенных недостатков объектно-ориентированного подхода к программированию.
Наиболее известным примером объектно-ориентированного языка программирования является язык C++, развившийся из императивного языка С. Его прямым потомком и логическим продолжением является язык С#, который изучается в данном курсе. Другие примеры объектно-ориентированных языков программирования: Visual Basic, Java, Eiffel, Oberon.

2. Предварительное ОО-проектирование ПО.
Предварительное ОО-проектирование ПО включает в себя выделение надлежащим образом совокупности объектов и отношений между ними, что позволяет построить объектную модель определенной предметной области, а на основе такой модели разработать программные средства для исследования этой предметной области и принятия решений.
Объектно-ориентированное проектирование (Object-Oriented Design – OOD) – это поступательный итеративный процесс. Граница между объектно-ориентированным анализом и проектированием расплывчата и построение проекта программного изделия состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование и по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.
Процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:
– Определение классов и объектов на определенном уровне абстракции.
– Определение семантики классов.
– Определение (идентификация) связей между классами и объектами.
– Реализация классов.
На каждом повторении этого цикла уточняются описания классов и перерабатываются проектные документы.

БИЛЕТ № 3

1. Предварительные диаграммы классов.
Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.
Диаграмма классов представляет собой граф, вершинами которого являются элементы типа «классификатор», связанные различными типами структурных отношений. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи.
2. Применение Microsoft .NET для ООАиП. (!Большой текст!)
Корпорацией Microsoft предложен новаторский компонентно-ориентированный подход к программированию, который является развитием объектно-ориентированного направления. Согласно этому подходу, интеграция объектов (возможно, гетерогенной природы) производится на основе интерфейсов, представляющих эти объекты (или фрагменты программ) как независимые компоненты. Такой подход существенно облегчает написание и взаимодействие программных «молекул»-компонент в гетерогенной среде проектирования и реализации. Стандартизируется хранение и повторное использование компонент программного проекта в условиях распределенной сетевой среды вычислений, где различные компьютеры и пользователи обмениваются информацией, например, взаимодействуя в рамках исследовательского или бизнес-проекта.
Строгая иерархичность организации пространств для типов, классов и имен сущностей программы позволяет стандартизировать и унифицировать реализацию.
Новый подход к интеграции компонент приложений в среде вычислений Internet (или так называемые веб-сервисы) дает возможность ускоренного создания приложений для широкого круга пользователей.
Универсальный интерфейс .NET Framework обеспечивает интегрированное проектирование и реализацию компонентов приложений, разработанных согласно различным подходам к программированию.
оворя о .NET как о технологической платформе, нельзя не отметить тот факт, что она обеспечивает одновременную поддержку проектирования и реализации программного обеспечения с использованием различных языков программирования. При этом поддерживаются десятки языков программирования, начиная от самых первых (в частности, COBOL и FORTRAN) и заканчивая современными (например, C# и Visual Basic). Ранние языки программирования до сих пор активно используются, в частности, для обеспечения совместимости с ранее созданными приложениями, критичными для бизнеса (скажем, COBOL весьма широко применялся для создания прикладных программ, поддерживающих финансовую деятельность).
Прежде всего, необходимо отметить поддержку многоязыковой среды разработки приложений CLR (Common Language Runtime).
Эта возможность появилась благодаря универсальному межъязыковому интерфейсу Common Language Infrastructure, или CLI, который поддерживает разработку программных компонентов на различных языках программирования.
Несомненным преимуществом для программистов является то, что они могут разрабатывать (или дорабатывать) программное обеспечение на наиболее подходящем языке программирования.
Отметим еще два существенных обстоятельства. Во-первых, основные сервисные возможности для разработчиков, которые предоставляет среда .NET (отладка, анализ кода и т. д.) не зависят от конкретного языка программирования, и, следовательно, программистам нет необходимости заново постигать особенности среды разработки, если требуется перейти с одного языка на другой. Во-вторых, несмотря на то, что еще не все языки программирования поддерживаются .NET, существует возможность самостоятельной разработки транслятора для любого языка программирования, причем это не вызывает трудностей даже у программистов, практически не имеющих профессиональной подготовки в области разработки компиляторов.
Существенным преимуществом конструктивного решения .NET является компонентно-ориентированный подход к проектированию и реализации программного обеспечения. Суть подхода состоит в принципиальной возможности создания независимых составляющих программного обеспечения с унифицированной интерфейсной частью для многократного повторного и распределенного использования. При этом продуктивность решения обусловлена многоязычностью интегрируемых программных проектов (концепция .NET потенциально поддерживает произвольный язык программирования, в числе наиболее известных языков – C#, Visual Basic, C++ и др.).
Одним из принципиальных технологических преимуществ проектирования и реализации программного обеспечения, декларируемых Microsoft, является так называемый компонентный подход к программированию.
В своей основе указанный подход совпадает с традиционным объектно-ориентированным, однако он имеет ряд важных особенностей.
Центральной концепцией подхода (и это очевидно уже из названия) является понятие компонента.
В отличие от «традиционных» объектов ООП компоненты обладают следующими характеристическими свойствами:
– в целом компонент обладает более высоким уровнем абстракции по сравнению с объектом (под последним понимается конструкция уровня языка программирования);
– компоненты могут содержать в своем составе множественные классы;
– компоненты с точки зрения пользователя являются инвариантами по отношению к тому языку программирования, на котором они реализованы.
Таким образом, оказывается, что в общем случае разработчик и пользователь компонента могут быть территориально разделены и имеют возможность использовать различные языки программирования в рамках единой среды разработки приложений Microsoft .NET.
//////////////////////////////////////////SUM UP!!!!!!!!!!!!!!!!!/////////////
Прежде всего, перечислим основополагающие понятия, характеризующие каждый из подходов. Затем сопоставим эти подходы друг с другом с целью поиска аналогий между ними.

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

При этом под классом понимается базовая сущность, определяемая как совокупность элементов.

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

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

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

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

Во-первых, разработчики отмечают достаточно высокие требования к аппаратному обеспечению (в частности, объем оперативной памяти должен быть не менее 256 мегабайт, свободный объем жесткого диска для работы с Microsoft Visual Studio .NET – не менее 10 гигабайт).

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

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

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

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

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

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

БИЛЕТ № 4

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

-определить общие границы и контекст моделируемой предметной области;
-сформулировать общие требования к функциональному поведению проектируемой системы;
-разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
-подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть диаграммы вариантов использования состоит в следующем. Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру.
Цель варианта использования заключается в том, чтобы определить законченный аспект или фрагмент поведения некоторой сущности без раскрытия её внутренней структуры. В качестве такой сущности может выступать система или любой элемент модели, который обладает собственным поведением.
Каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая сущность по запросу актера, то есть определяет способ применения этой сущности. Сервис, который инициализируется по запросу актера, представляет собой законченную неделимую последовательность действий. Это означает, что после того как система закончит обработку запроса, она должна возвратиться в исходное состояние, чтобы быть готовой к выполнению следующих запросов
Варианты использования могут применяться как для спецификации внешних требований к проектируемой системе, так и для спецификации функционального поведения уже существующей системы. Множество вариантов использования в целом должно определять все возможные стороны ожидаемого поведения системы. Кроме этого, варианты использования неявно устанавливают требования, определяющие, как актеры должны взаимодействовать с системой, чтобы иметь возможность корректно работать с предоставляемыми сервисами. Для удобства множество вариантов использования может рассматриваться как отдельный пакет.
Примерами вариантов использования могут являться следующие действия: проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение дополнительной информации о кредитоспособности клиента, отображение графической формы на экране монитора и другие действия.
2. Понятие класса.
Класс – это абстрактное понятие, сравнимое с понятием категория в его обычном смысле.

По определенным свойствам этого элемента можно установить, что он принадлежит к какой-то категории. Сама категория определяется общими свойствами, которые имеют все экземпляры этой категории.
Класс в ООП – это абстрактный тип данных, который включает в себя не только данные, но и функции и процедуры.
Функции и процедуры класса называются методами и содержат исходный код, предназначенный для обработки внутренних данных объекта данного класса.
После того, как Вы объявили состав класса, необходимо определить (описать), что делает каждая функция-член (метод).
Существует 2 способа включения метода в класс:
Определение метода при описании класса.
Объявление метода при описании, а его описание – при вызове.
Методы, определенные внутри класса, являются неявно встроенными.

БИЛЕТ № 5

1. Понятие объекта.
Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов). Как правило, при рассмотрении объектов выделяется то, что объекты принадлежат одному или нескольким классам, которые в свою очередь определяют поведение (являются моделью) объекта. Время с момента создания объекта (конструкция) до его уничтожения (деструкция) называется временем жизни объекта. Объект наряду с понятием «класс», является важным понятием объектно-ориентированного подхода в программировании. Объекты обладают свойствами наследования, инкапсуляции и полиморфизма.
Термин объект в программном обеспечении впервые был введен в языке Simula и применялся для моделирования реальности. Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы.
Объект — сущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса (например, после запуска результатов компиляции (и связывания) исходного кода на выполнение).
2. Сценарии использования.
Сценарий использования, вариант использования, прецедент (англ. Use Case) – в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.
В системном проектировании сценарии использования применяются на более высоком уровне чем в при разработке программного обеспечения, часто представляя цели заинтересованных лиц или миссии. На стадии анализа требований сценарии использования могут быть преобразованы в ряд детальных требований и задокументированы с помощью диаграмм требований SysML или других подобных механизмов.

БИЛЕТ № 6

1. Понятие атрибута.
Атрибут – это некоторая дополнительная информация, которая может быть приписана к типам, полям, методам, свойствам и некотрым другим конструкциям языка. Атрибуты поещаются в исполняемый файл и могут оттуда при необходимости извлекаться.
Все атрибуты (в отличие, скажем, от атрибутов языка IDL) являются классами (потомками класса System.Attribute). В отличие от атрибутов IDL набор атрибутов .NET открыт для дополнения, т. е. вы можете определять собственные атрибуты и применять их к вышеуказанным элементам вашего кода.
Атрибуты делятся на предопределенные (встроенные) и пользовательские (которые пишет программист).
Встроенные атрибуты могут использоваться, например, при сериализации (сохранении в поток) данных класса. Скажем, вам надо, чтобы у класса сохранялись не все данные – в этом случае вы можете пометить те данные, которые не надо сохранять, специальным атрибутом.
Еще пример применения атрибутов. Компоненты, которые вы располагаете на форме (кнопки, метки и т. п.) имеют некоторый набор свойств (шрифт, местоположение, видимость и т. п.). В IDE Visual Studio вы можете выбрать в окне Properties один из двух способов расположения этих свойств – по алфавиту или по категориям. Так вот, в какую категорию попадет то или иное свойство, определяется специальным встроенным атрибутом.
2. Схема данных. ER-диаграммы.
Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы.
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).
На практике понятия ER-модель и ER-диаграмма часто не различают, хотя для визуализации ER-моделей предложены и другие графические нотации (см. ниже).
ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

БИЛЕТ № 7

1. Понятие метода.
Процедуры и функции, связанные с классом. Они определяют действия, которые можно выполнять над объектом такого типа, и которые сам объект может выполнять.
Классы могут наследоваться друг от друга. Класс-потомок получает все поля и методы класса-родителя, но может дополнять их собственными либо переопределять уже имеющиеся. Большинство языков программирования поддерживает только единичное наследование (класс может иметь только один класс-родитель), лишь в некоторых допускается множественное наследование — порождение класса от двух или более классов-родителей. Множественное наследование создаёт целый ряд проблем, как логических, так и чисто реализационных, поэтому в полном объёме его поддержка не распространена. Вместо этого в 1990-е годы появилось и стало активно вводиться в объектно-ориентированные языки понятие интерфейса. Интерфейс — это класс без полей и без реализации, включающий только заголовки методов. Если некий класс наследует (или, как говорят, реализует) интерфейс, он должен реализовать все входящие в него методы. Использование интерфейсов предоставляет относительно дешёвую альтернативу множественному наследованию.
Взаимодействие объектов в абсолютном большинстве случаев обеспечивается вызовом ими методов друг друга.

2. Уточненное ОО-проектирование ПО.
Уточнённое ОО-проектирование ПО включает в себя выделение надлежащим образом совокупности объектов и отношений между ними, что позволяет построить объектную модель определенной предметной области, а на основе такой модели разработать программные средства для исследования этой предметной области и принятия решений.
Объектно-ориентированное проектирование (Object-Oriented Design – OOD) – это поступательный итеративный процесс. Граница между объектно-ориентированным анализом и проектированием расплывчата и построение проекта программного изделия состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование и по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.
Процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:
– Определение классов и объектов на определенном уровне абстракции.
– Определение семантики классов.
– Определение (идентификация) связей между классами и объектами.
– Реализация классов.
На каждом повторении этого цикла уточняются описания классов и перерабатываются проектные документы.

БИЛЕТ № 8

1. Извлечение существительных.
По поводу извлечения существительных – это выборка из тех.задания существительных, которыми будут названы ваши классы. Например, если вам нужно описать работу лифта, то существительными будут лифт, кнопка. Также есть извлечение глаголов, соответственно для методов. Для нашего примера это будет подъем лифта или нажатие кнопки.
2. Концепция абстракции.
Абстракция – базовое понятие объектно-ориентированного программирования
Понятие абстракции в математике и программировании. Математическая модель абстракции. Сте-
пень абстракции как средство оптимизации модели предметной области. Примеры использования
абстракции: банковские и геоинформационные системы, моделирование живых существ в водной
среде. Связь абстракции с модульной декомпозицией при объектно-ориентированном проектирова-
нии и программировании. Демонстрация и анализ концепции абстракции на примере разработки
Java-программ (Интернет-магазин), а также при разработке классов (Банковский счет и др.).

БИЛЕТ № 9

1. Детализация диаграмм классов.
Детализация диаграммы классов объектов выполняется путем уточнения классов-объектов. Интерфейсные классы объектов соответствуют актерам прецедентов использования, а управляющие классы объектов – координирующим функциям обработки объектов-сущностей. Уточнение диаграммы состояний объектов выполняется в связи с детализацией диаграммы прецедентов использования и диаграммы классов объектов.
-Class diagram отражают статическую структуру классов объектов
-Рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов
-Классы объектов могут иметь различные стереотипы поведения: объекты-сущности, управляющие объекты, интерфейсные объекты
Объекты связываются статическими отношениями, которые отражают постоянные связи между объектами независимо от выполнения конкретного бизнес-процесса
К статическим отношениям относятся: обобщение, агрегация, ассоциация объектов
Зависимость – отношение использования, согласно
которому изменение в спецификации одного
элемента (например, класса «товар») может повлиять
на использующий его элемент (класс «строка
заказа»). Часто зависимости показывают, что один класс
использует другой в качестве аргумента
2. Концепция инкапсуляциии.
Инкапсуляция – базовое понятие объектно-ориентированного программирования
Связь инкапсуляции с модульной декомпозицией программного продукта. Применение принципа
«Разделяй и властвуй». Разделение интерфейса и реализации инкапсулированных программных объектов. Признаки инкапсуляции: общедоступный интерфейс и сокрытие реализации.
Демонстрация и анализ концепции инкапсуляции на примере разработки Java-программы (Интернет-магазин), а также при разработке классов (Банковский счет и др.).
Инкапсуляция — свойство языка программирования, позволяющее пользователю не задумываться о сложности реализации используемого программного компонента (то, что у него внутри), а взаимодействовать с ним посредством предоставляемого интерфейса (публичных методов и членов), а также объединить и защитить жизненно важные для компонента данные. При этом пользователю предоставляется только спецификация (интерфейс) объекта.
Пользователь может взаимодействовать с объектом только через этот интерфейс. Реализуется с помощью ключевого слова: public.
Пользователь не может использовать закрытые данные и методы. Реализуется с помощью ключевых слов: private, protected, internal.

БИЛЕТ № 10

1. Концепция наследования.
Наследование – базовое понятие объектно-ориентированного программирования. Наследование – механизм, дающий возможность создавать новые классы на основе уже существующего класса. Понятие базового и производного классов. Концепции абстрактного класса и метода.
Наследование реализации, поведения и свойств. Переопределение метода. Виды наследования. Единственность и множественность наследования. Особенности реализации концепции наследования в различных языках программирования (Java, С#). Интерфейс как особый род абстрактного класса. Сравнение отношений частичного порядка (ISA) и структурного вхождения. Применение наследования при модульной декомпозиции – преимущества и ограничения. Проблема «хрупких» базовых
классов. Демонстрация и анализ концепции наследования на примере разработки Java-программы (Интернет-магазин), а также при разработке классов (Банковский счет, Моделирование животного мира и др.).
Наследование — механизм объектно-ориентированного программирования (наряду с инкапсуляцией, полиморфизмом и абстракцией), позволяющий описать новый класс на основе уже существующего (родительского), при этом свойства и функциональность родительского класса заимствуются новым классом. Другими словами, класс-наследник реализует спецификацию уже существующего класса (базовый класс). Это позволяет обращаться с объектами класса-наследника точно так же, как с объектами базового класса.
2. Ревизия проекта. Порядок, особенности.

Говоря кратко, ревизия кода это то, что происходит, когда кто-то просматривает ваш код и делает относительно него замечания.

Выделим некоторые виды ревизий.
В первую очередь стоит упомянуть о предварительных обзорах, т.е. ревизиях патчей перед их внесением в основную ветку кода проекта. Классический пример таких ревизий в сообществе свободного ПО – размещение патча новым разработчиком в списке рассылки. В некоторых проектах предварительные обзоры применяются даже к коду опытных разработчиков (например, Twisted, Bazaar, Linux).
Отметим также ревизии кода пост-фактум. Такое часто случается в проектах свободного ПО, когда кто-то вносит в проект какой-нибудь нетривиальный код. Обычно рецензент, найдя ошибку в патче, уведомляет о ней путём опубликования (в списке рассылки – прим. перев.) ответа на сообщение о фиксации (commit) соответствующего изменения.
Ревизии также могут проводиться в форме проверки наугад. При этом подходе старший программист инспектирует некоторые произвольные участки кода в репозитории и оставляет замечания о его структуре и качестве.
Наконец, ревизии могут быть незапланированными. Это обычно случается поздней ночью, когда программист возится с кодом в каком-нибудь дальнем углу проекта, возможно отлавливая там ошибки. Такие ревизии обычно сопровождаются нецензурными восклицаниями и гневными комментариями. Зачастую они совершенно бесполезны для автора кода, поскольку ему вряд ли повезёт их услышать.

 

БИЛЕТ № 11

1. Концепция полиморфизма.
Полиморфизм – основополагающая концепция объектно-ориентированного программирования. Полиморфизм – средство унификации и повторного использования программного кода. Представление вариативного выбора поведения программного кода для полиморфных классов и методов. Связь
концепции полиморфизма с инкапсуляцией и наследованием. Расширения полиморфизма: параметрический полиморфизм, переопределение и перегрузка методов. Ранее связывание (во время компиляции) и
позднее связывание (во время выполнения). «Ленивые» (отложенные, «замороженные») вычисления. Демонстрация и анализ концепции полиморфизма на примере разработки Java-программы (Интернет-
магазин), а также при разработке классов (Банковский счет, Моделирование животного мира и др.).
Полиморфизм (в языках программирования) — возможность объектов с одинаковой спецификацией иметь различную реализацию.
Язык программирования поддерживает полиморфизм, если классы с одинаковой спецификацией могут иметь различную реализацию — например, реализация класса может быть изменена в процессе наследования.
Кратко смысл полиморфизма можно выразить фразой: «Один интерфейс, множество реализаций».
Полиморфизм позволяет писать более абстрактные программы и повысить коэффициент повторного использования кода. Общие свойства объектов объединяются в систему, которую могут называть по-разному — интерфейс, класс. Общность имеет внешнее и внутреннее выражение:
внешняя общность проявляется как одинаковый набор методов с одинаковыми именами и сигнатурами (именем методов и типами аргументов и их количеством);
внутренняя общность — одинаковая функциональность методов. Её можно описать интуитивно или выразить в виде строгих законов, правил, которым должны подчиняться методы. Возможность приписывать разную функциональность одному методу (функции, операции) называется перегрузкой метода (перегрузкой функций, перегрузкой операций).
2. Реализация ПО. Общая схема.
Это процесс поэтапной реализации и подключения классов к проекту. Процесс начинается с создания основной программы или проекта будущего программного продукта. Затем реализуются и подключаются классы, так чтобы создать грубый, но, по возможности, работающий прототип будущей системы. Он тестируется и отлаживается. Например, таким прототипом может служить система, включающая реализацию основного интерфейса программного продукта (передача сообщений в отсутствующую пока часть системы не выполняется). В результате мы получаем работоспособный прототип продукта, который может быть, например, показан заказчику для уточнения требований. Затем к системе подключается следующая группа классов, например, связанная с реализацией некоторого пункта меню. Полученный вариант также тестируется и отлаживается, и так далее, до реализации всех возможностей системы.
Использование поэтапной реализации существенно упрощает тестирование и отладку программного продукта.
Модификация. Это процесс добавления новых функциональных возможностей или изменение существующих свойств системы. Как правило, изменения затрагивают реализацию класса, оставляя без изменения его интерфейс, что при использовании ООП обычно обходится без особых неприятностей, так как процесс изменений затрагивает локальную область. Изменение интерфейса – также не очень сложная задача, но ее решение может повлечь за собой необходимость согласования процессов взаимодействия объектов, что потребует изменений в других классах программы. Однако сокращение количества параметров в интерфейсной части по сравнению с модульным программированием существенно облегчает и этот процесс.
Простота модификации позволяет сравнительно легко адаптировать программные системы к изменяющимся условиям эксплуатации, что увеличивает время жизни систем, на разработку которых затрачиваются огромные временные и материальные ресурсы.
Особенностью ООП является то, что объект или группа объектов могут разрабатываться отдельно, и, следовательно, их проектирование может находиться на различных этапах. Например, интерфейсные классы уже реализованы, а структура классов предметной области еще только уточняется. Обычно проектирование начинается, когда какой-либо фрагмент предметной области достаточно полно описан в процессе анализа.

БИЛЕТ № 12

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

Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
Модульное тестирование заключается в написании небольших тестов для каждой нетривиальной функции или метода исходного кода программы в отдельности. Это дает следующие преимущества:
-> Уверенность в работоспособности модулей в отдельности
-> Проверка старой функциональности при внесении новой (регрессивное тестирование)
-> Спецификация по использованию классов и методов основной программы (косвенная документация)
Основные принципы модульного тестирования:
– Отдельные тесты маленькие и быстрые
– Автоматический запуск набора тестов
– Независимость тестов друг от друга и от порядка следования
– Найденная ошибка – повод для написания теста под нее
– Иерархическая структура тестов
– Тесты отделены от основного проекта
– Наличие системы именования тестов
Для облегчения задачи создания вспомогательных тестовых проектов существуют специальные тестовые фреймворки, которые в большинстве своем выполняют следующие задачи:
– Предоставление каркаса для построения тестовых наборов
– Дополнительные макросы для проверок условий в коде
– Выявление ошибок по нескольким уровням критичности
– Регистрация ошибок, формирование отчетов
– Дополнительные средства мониторинга
Среди основных требований к системам тестирования можно выделить следующие:
– Мощность и гибкость при выполнении основных функций
– Легкость в освоении и использовании
– Кроссплатформенность

2. Понятие ЖЦ ПО.
Жизненный цикл системы включает фазы:
– Постановка задачи (характер/масштаб)‏
– Анализ требований
– Проектные спецификации
– Проектирование системы
– Реализация
– Тестирование и передача заказчику
– Сопровождение
ЖЦ – непрерывный, замкнутый, итерационный процесс!

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.
Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
В настоящее время известны и используются следующие модели жизненного цикла:
– Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
– Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
Спиральная модель. На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки – анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.
В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:
1. Основные процессы:

  • приобретение;
  • поставка;
  • разработка;
  • эксплуатация;
  • сопровождение.
  1. Вспомогательные процессы:
  • документирование;
  • управление конфигурацией;
  • обеспечение качества;
  • разрешение проблем;
  • аудит;
  • аттестация;
  • совместная оценка;
  • верификация.
  1. Организационные процессы:
  • создание инфраструктуры;
  • управление;
  • обучение;
  • усовершенствование.

Согласно стандарту ISO/IEC серии 15288 [7] в структуру ЖЦ следует включать следующие группы процессов:
1. Договорные процессы:
o приобретение (внутренние решения или решения внешнего поставщика);
o поставка (внутренние решения или решения внешнего поставщика).
2. Процессы предприятия:
o управление окружающей средой предприятия;
o инвестиционное управление;
o управление ЖЦ ИС;
o управление ресурсами;
o управление качеством.
3. Проектные процессы:
o планирование проекта;
o оценка проекта;
o контроль проекта;
o управление рисками;
o управление конфигурацией;
o управление информационными потоками;
o принятие решений.
4. Технические процессы:
o определение требований;
o анализ требований;
o разработка архитектуры;
o внедрение;
o интеграция;
o верификация;
o переход;
o аттестация;
o эксплуатация;
o сопровождение;
o утилизация.
5. Специальные процессы:
o определение и установка взаимосвязей исходя из задач и целей.
Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 2.2.
Таблица 2.2. Стадии создания систем (ISO/IEC 15288)
№ Стадия Описание
1 Формирование концепции Анализ потребностей, выбор концепции и проектных решений
2 Разработка Проектирование системы
3 Реализация Изготовление системы
4 Эксплуатация Ввод в эксплуатацию и использование системы
5 Поддержка Обеспечение функционирования системы
6 Снятие с эксплуатации Прекращение использования, демонтаж, архивирование системы

БИЛЕТ № 13

1. Тестирование ПО от кода. Общая схема.

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

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

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

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

Степень покрытия кода обычно выражают в виде процента. Например, «мы протестировали 67 % кода». Смысл этой фразы зависит от того какой критерий был использован. Например, 67 % покрытия путей — это лучший результат чем 67 % покрытия операторов. Вопрос о связи значения покрытия кода и качества тестового набора ещё до конца не решён.

Существует несколько различных способов измерения покрытия, основные из них:

  • покрытие операторов — каждая ли строка исходного кода была выполнена и протестирована;
  • покрытие условий — каждая ли точка решения (вычисления истинно ли или ложно выражение) была выполнена и протестирована;
  • покрытие путей — все ли возможные пути через заданную часть кода были выполнены и протестированы;
  • покрытие функций — каждая ли функция программы была выполнена;
  • покрытие вход/выход — все ли вызовы функций и возвраты из них были выполнены.

2. Фазы ЖЦ ПО. Экономка ЖЦ ПО.
2.1. Этапы ЖЦ ПО
• Анализ и спецификация требований
• Эскизное и детальное проектирование
• Реализация и тестирование
• Сопровождение и вывод из эксплуатации
2.2. Экономическая специфика этапов ЖЦ ПО
• Стоимость и структура затрат
• Связь этапов ЖЦ ПО с моделями
• Поддерживающий инструментарий (CASE-средства)‏
• Метрики оценки ЖЦ ПО
Цель антикризисной разработки ПО: многомерная оптимизация модели ЖЦ с учётом:
– сроков
– стоимости
– качества
– сопровождаемости
Приоритетность параметров оптимизации зависит от характера и масштаба ПО и др. кризисных факторов.
Для оптимизации ЖЦ необходима чёткая декомпозиция на процессы, адекватный выбор методов и средств разработки ПО.
Стадии ЖЦ ПО, общие для всех моделей:
– Анализ требований
– Подготовка спецификаций
– Проектирование
– Реализация
– Интеграция
– Сопровождение
– Вывод из эксплуатации
Оптимизация может упрощать или даже исключать некоторые стадии ЖЦ.
Основные затраты – на сопровождение (особенно для длительных проектов и сложных систем).
Средства, увеличивающие расширяемость ПО (и/или сроки обновления и тестирования) более эффективны, чем все ухищрения при кодировании.
Фазы, предшествующие кодированию и следующим за ним, 30% затрат (кодирование – 5%) :
– обрамляющие стадии улучшают ПО и ускоряют кодирование.
Большинство ошибок – в ходе проектирования и спецификаций (нужны формальные методы анализа).
Цена поиска ошибок экспоненциально растёт по мере продвижения проекта по ЖЦ.
Ошибки следует выявлять ASAP (as soon as possible)!
(иначе – сквозная трассировка ВСЕХ артефактов ПО).
Грамотная постановка, выбор модели/архитектуры, чёткая ревизия проекта, дисциплина, стандарты, знание CASE, разумная достаточность документации – ключи к экономии.

БИЛЕТ № 14

1. Модели ЖЦ ПО.
Модели ЖЦ ПО – “скелет” скелет антикризисной оптимизации:
Модель «проб и ошибок» (build-and-fix)
«Однопроходная» водопадная модель.
«Циклический» ЖЦ:
– модель быстрого прототипирования
– инткремент(аль)ная модель
– модель синхронизации и стабилизации
– спиральная модель
– ОО – модель
В настоящее время известны и используются следующие модели жизненного цикла:
Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
Спиральная модель. На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки – анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

2. Тестирование ПО от спецификаций. Общая схема.
Эквивалентное разделение <приложения> (Equivalence partitioning)
Рассматриваемая область приложения разделяется на коллекцию наборов или эквивалентных классов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик <спецификации>. Репрезентативный набор тестов (иногда – только один тест) формируется из тестов эквивалентных классов (или наборов классов).
Анализ граничных значений (Boundary-value analysis)
Тесты строятся с ориентацией на использование тех величин, которые определяют предельные характеристики тестируемой системы. Расширением этой техники являются тесты оценки живучести (robustness testing) системы, проводимые с величинами, выходящими за рамки специфицированных пределов значений.
Таблицы принятия решений (Decision table)
Такие таблицы представляют логические связи между условиями (могут рассматриваться в качестве “входов”) и действиями (могут рассматриваться как “выходы”). Набор тестов строится последовательным рассмотрением всех возможных кросс-связей в такой таблице.
Тесты на основе конечного автомата (Finite-state machine-based)
Строятся как комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели (переходов и состояний приложения).
Тестирование на основе формальной спецификации (Testing from formal specification)
Для спецификации, определенных с использованием формального языка, возможно автоматически создавать и тесты для функциональных требований. В ряде случаев могут строится на основе модели, являющейся частью спецификации, не использующей формального языка описания.
Случайное тестирование (Random testing)
В отличие от статистического тестирования (будет рассматриваться в 3.5.1 “Operational profile”), сами тесты генерируются случайным образом по списку заданного набора специфицированных характеристик.

БИЛЕТ № 15

1. Особенности ОО-модели ЖЦ ПО.
Преимущество: Итеративная разработка с распараллеливанием, хорошо подходит для проектирования ОО-приложений
Недостаток: Без дисциплины, стандартов, знаний CASE (слабые ограничения процесса проектирования), может выродиться в «пробы и ошибки»
Пробы и ошибки:
Преимущество: Экономия для малых проектов с простыми требованиями/сопровождением.
Недостаток: Неприменима для проектов от 1000 строк.
2. Тестирование ПО на основе исполнения кода.
Тесты, базирующиеся на блок-схеме (Control-flow-based criteria)

Набор тестов строится исходя из покрытия всех условий и решений блок-схемы. В какой-то степени напоминает тесты на основе конечного автомата. Отличие – в источнике набора тестов. Максимальная отдача от тестов на основе блок-схемы получается когда тесты покрывают различные пути блок-схемы – по-сути, сценарии потоков работ (поведения) тестируемой системы. Адекватность таких тестов оценивается как процент покрытия всех возможных путей блок-схемы.
Тесты на основе потоков данных (Data-flow-based criteria)

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

Ссылочные модели для тестирования, ориентированного на код (Reference models for code-based testing – flowgraph, call graph)

Является не столько техникой тестирования, сколько контролем структуры программы, представленной в виде дерева вызовов (например, sequence-диаграммы, определенной в нотации UML и построенной на основе анализа кода).

БИЛЕТ № 16

1. ОО-анализ требований к ПО.
При объектно-ориентированном подходе анализ требований к системе сводится к разработке моделей этой системы. Моделью системы (или какого-либо другого объекта или явления) мы называем формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами. Построение моделей – широко распространенный способ изучения сложных объектов и явлений. В модели опущены многочисленные детали, усложняющие понимание. Моделирование широко распространено и в науке, и в технике.
Модели помогают:
проверить работоспособность разрабатываемой системы на ранних этапах ее разработки;
общаться с заказчиком системы, уточняя его требования к системе;
вносить (в случае необходимости) изменения в проект системы (как в начале ее проектирования, так и на других фазах ее жизненного цикла).
Модели, разработанные и отлаженные на первой фазе жизненного цикла системы, продолжают использоваться на всех последующих его фазах, облегчая программирование системы, ее отладку и тестирование, сопровождение и дальнейшую модификацию.Модели системы не связаны с языком программирования, на котором будет реализована система. Объектная модель описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В объектной модели отражается прежде всего прагматика разрабатываемой системы, что выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы.

2. Тестирование ПО на без исполнения кода.

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

БИЛЕТ № 17

1. Интеграция ПО. Общая схема. Виды и особенности.

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

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

Continuous integration процесс состоит из нескольких этапов, некоторые из которых обязательны, другие нет:

  • Trigger — обязателен

Цикл интеграции начинается со срабатывания триггера. Это может быть одно из следующих событий:

  • изменение в системе контроля версий
  • изменение в файловой системе
  • определенный момент времени
  • сборка другого проекта
  • нажата «красная» кнопка
  • изменение на веб сервере
  • Update — обязателен

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

  • Analyse — не обязателен

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

  • наличие типичных ошибок
  • статические характеристики кода: сложность, размер, прочее
  • соответствие принятым стандартам кодирования
  • Build — а как без него?

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

  • UnitTest — крайне желателен

В методологии Extreme Programming модульное (unit) тестирование является неотъемлемой частью разработки приложения. Модульные тесты изначально автоматизированы, их включение в процесс интеграции крайне желательно. (см. Модульное тестирование – билет 12)

  • Deploy — нужен по обстоятельствам

Проект необходимо «развернуть». В случае веб-приложения это выкладывание на веб-сервер (сервер приложений) и запуск. Для GUI приложений это (пере)установка в системе. Этап развертывание должен проходить как можно более «чисто». При этом для последующего тестирования часто необходимо привести приложение в некое «стандартное» состояние:

  • «залить» дамп базы
  • настроить в стандартном режиме
  • убрать следы предыдущей деятельности приложения
  • Test — не обязателен, но крайне желателен

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

  • Archive — желателен

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

  • Report — обязателен

В конце идет важный этап генерации и публикации отчетов.

2. Спецификация требований к ПО.
Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и графических моделей.
В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях.
Этапу разработки требований, возможно, предшествовало технико-экономическое обоснование, или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.
Виды требований по уровням:
– Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
– Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
– Функциональные требования — определяют «как» реализовать продукт. Описывается в системной спецификации (system requirement specification, SRS).
Виды требований по характеру:
– Функциональный характер — требования к поведению системы
– Бизнес-требования
– Пользовательские требования
– Функциональные требования
– Нефункциональный характер — требования к характеру поведения системы
– Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
– Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и ПО.
– Атрибуты качества
– Внешние системы и интерфейсы
– Ограничения
Источники требований:
– Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
– Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
– Текущая организация деятельности объекта автоматизации
– Модели деятельности (диаграммы бизнес-процессов)
– Представления и ожидания потребителей и пользователей системы
– Журналы использования существующих программно-аппаратных систем
– Конкурирующие программные продукты

Характеристики качественных требований:
Единичность. Требование описывает одну и только одну вещь.
Завершённость. Требование полностью определено в одном месте и вся необходимая информация присутствует.
Последовательность. Требование не противоречит другим требованиям и полностью соответствует внешней документации.
Атомарность. Требование «атомарно». То есть оно не может быть разбито на ряд более детальных требований без потери завершённости.
Отслеживаемость. Требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и документировано.
Актуальность. Требование не стало устаревшим с течением времени.
Выполнимость. Требование может быть реализовано в пределах проекта.
Недвусмысленность. Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировка. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.
Обязательность. Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования.
Проверяемость. Реализованость требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ.

Методы выявления требований:
– Интервью, опросы, анкетирование
– Мозговой штурм, семинар
– Наблюдение за производственной деятельностью, «фотографирование» рабочего дня
– Анализ нормативной документации
– Анализ моделей деятельности
– Анализ конкурентных продуктов
– Анализ статистики использования предыдущих версий системы

БИЛЕТ № 18

1. Архитектурное проектирование ПО. Общая схема.
1) Структурирование системы: Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами.
2) Моделирование управления: Разрабатывается базовая модель управления взаимоотношениями между частями системы.
3) Модульная декомпозиция: Каждая определённая на первом этапе подсистема разбивается на отдельные модули. Здесь определяются типы модулей и типа их взаимосвязей.
Результатом процесса архитектурного проектирования является документ, отображающий архитектуру системы. Он состоит из набора графических схем представлений моделей системы с соответствующим описанием. В описании должно быть указано, из каких подсистем состоит система и из каких модулей слагается каждая подсистема. Графические схемы моделей системы позволяют взглянуть на архитектуру с разных сторон. Как правило, разрабатывается четыре архитектурные модели:
1. Статическая структурная модель, в которой представлены подсистемы или компоненты, разрабатываемые в дальнейшем независимо.
2. Динамическая модель процессов, в которой представлена организация процессов во время работы системы.
3. Интерфейсная модель, которая определяем сервисы, предоставляемые каждой подсистемой через общий интерфейс.
4. Модели отношений, в которых показаны взаимоотношения между частями системы, например поток данных между подсистемами.
2. Сборочное тестирование ПО. Порядок и технологии.
(Сборочное тестирование, integration testing или interface testing)
Входные требования – Архитектура системы или модель “верхнего уровня” системы (System Design или High Level Design)
Объект тестирования – Собранная из компонентов система или подсистема
Определение – На данном уровне тестируются объединенные элементы (компоненты или подсистемы) общей системы, чаще всего некоторая взаимодействующая между собой группа элементов.
Комплексное тестирование направлено не на проверку функционирования каждого из компонентов, а на проверку взаимодействия компонентов в соответствии с «Архитектурой системы».
Тесты данного уровня обычно проверяют все интерфейсы взаимодействия между компонентами, определенные в системной архитектуре, до тех пор, пока все компоненты не будут разработаны, отлажены и проинтегрированы друг с другом в единую систему.

БИЛЕТ № 19

1. Диаграммы потоков данных.
Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Диаграммы потоков данных (Data flow diagramming, DFD):
являются основным средством моделирования функциональных требований к проектируемой системе; создаются для моделирования существующего процесса движения информации; используются для описания документооборота, обработки информации; обеспечивают проведение анализа и определения основных направлений реинжиниринга ИС.
DFD-диаграммы создавались как средство проектирования программных систем, тогда как IDEF0 – как средство проектирования систем вообще, поэтому DFD имеют более богатый набор элементов, адекватно отражающих их специфику (например, хранилища данных яв-ляются прообразами файлов или баз данных).
Наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логиче-скую незавершенность IDEF0, а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной, и построить полную функциональную спецификацию разрабатываемой системы.
Существуют и поддерживаются рядом CASE-инструментов алгоритмы автоматического пре-образования иерархии DFD в структурные карты, демонстрирующие межсистемные и внут-рисистемные связи, а также иерархию систем, что в совокупности с мини-спецификациями является завершенным заданием для программиста.
С помощью DFD-диаграмм требования к проектируемой ИС разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель декомпозиции DFD-функций – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. На схемах бизнес-процесса отображаются:
функции процесса; входящая и исходящая информация, при описании документов; внешние бизнес-процессы, описанные на других диаграммах; точки разрыва при переходе процесса на другие страницы.
2. Приемочное тестирование ПО. Порядок и технологии.
В общем случае приемочным тестированием называют тестирование, целью которого является определение пригодности продукта. Обычно производится с помощью набора тестов (автоматически или вручную), которые заранее подготовлены и ожидают определенного результата.

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

БИЛЕТ № 20

1. Диаграммы последовательностей.

Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML.

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.
2. Документирование ПО. Виды документов.

БИЛЕТ № 21

1. Диаграммы взаимодействия.
Диаграммы взаимодействий используются для моделирования динамических аспектов системы. Сюда входит моделирование конкретных и прототипических экземпляров классов, интерфейсов, компонентов и узлов, а также сообщений, которыми они обмениваются, – и все это в контексте сценария, иллюстрирующего данное поведение. Диаграммы взаимодействий могут существовать автономно и служить для визуализации, специфицирования, конструирования и документирования динамики конкретного сообщества объектов, а могут использоваться для моделирования отдельного потока управления в составе прецедента.
2. Сопровождение ПО. Виды сопровождения.
Сопровожде́ние программного обеспечения — процесс улучшения, оптимизации и устранения дефектов программного обеспечения (ПО) после передачи в эксплуатацию. Сопровождение ПО — это одна из фаз жизненного цикла программного обеспечения, следующая за фазой передачи ПО в эксплуатацию. В ходе сопровождения в программу вносятся изменения, с тем, чтобы исправить обнаруженные в процессе использования дефекты и недоработки, а также для добавления новой функциональности, с целью повысить удобство использования (юзабилити) и применимость ПО.
В модели водопада, сопровождение ПО выделяется в отдельную фазу цикла разработки. В спиральной модели, возникшей в ходе развития объектно-ориентированного программирования, сопровождение не выделяется как отдельный этап. Тем не менее, эта деятельность занимает значительное место, учитывая тот факт, что обычно около 2/3 жизненного цикла программных систем занимает сопровождение.
Сопровождаемость программного обеспечения — характеристики программного продукта, позволяющие минимизировать усилия по внесению в него изменений:
– для устранения ошибок;
– для модификации в соответствии с изменяющимися потребностями пользователей.

БИЛЕТ № 22

1. Диаграммы переходов состояний.
Диаграмма состояний связывает события и состояния. При приеме события следующее состояние системы зависит как от ее текущего состояния, так и от события; смена состояния называется переходом. Диаграмма состояний – это граф, узлы которого представляют состояния, а направленные деги, помеченные именами соответствующих событий, – переходы. Диаграмма состояний позволяет получить последовательность состояний по заданной последовательности событий.
2. Проектирование интерфейсов ПО.

БИЛЕТ № 23

1. Виды и особенности диаграмм при ООАиП.
2. Многократное использование ПО.

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

Самый распространённый случай повторного использования кода — библиотеки программ. Библиотеки предоставляют общую достаточно универсальную функциональность, покрывающую избранную предметную область. Примеры: библиотека функций для работы с комплексными числами, библиотека функций для работы с 3D-графикой, библиотека для использования протокола TCP/IP, библиотека для работы с базами данных. Разработчики новой программы могут использовать существующие библиотеки для решения своих задач и не «изобретать велосипеды».


БИЛЕТ № 24

1. Понятие модульности.

2. Применение CASE-средств при ООАиП.

БИЛЕТ № 25

1. Классификация подходов к программированию.

Декларативное программирование описывает каково нечто, а не как его создать.
Императивное(процедурное) программирование описывает процесс вычисления в виде инструкций, изменяющих состояние программы.
Структурное программирование – методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков.
Функциональное программирование – парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).
Логическое программирование – парадигма программирования, основанная на автоматическом доказательстве теорем, а также раздел дискретной математики, изучающий принципы логического вывода информации на основе заданных фактов и правил вывода.
Объектно-ориентированное программирование – парадигма программирования, в которой основными концепциями являются понятия объектов и классов.
2. Понятие сцепления.

В методе проектирования, известном как “структурное проектирование” особое значение придается важности использования модульных структур. Этот метод был основан на анализе “сцепления” и “связности” модулей.
Сцепление модулей представляет из себя меру условной независимости модулей, которая описывает их читабельность и сохранность. На сто процентов независящие модули могут корректироваться без каких-или последствий товарищ для товарища. Чем преимущественно информационной части о модулях употребляется в остальных модулях, тем преимущественно ступень его сцепления. Сцепления модулей классифицируют последующим образом:
– Самый маленький – независящие модули. Вероятна корректировка отдельными группами программистов без учета конфигураций вносимых иными группами.

– Сцепление по предоставленным. Модули обмениваются предоставленными обычного вида, этот модуль знает лишь имя иного и число встречаемых и передаваемых характеристик.
– Сцепление по эталону. Модули обмениваются параметрами необычного вида. В данном варианте каждому из модулей обязана быть знаменита структура характеристик. Возможность ошибок растет, потому что изменение структуры в один-одинешенек из модулей просит внесения поправок в модули связанные с ним.
– Сцепление по корпоративной области. Модули употребляют одну и ту же глобальную структуру предоставленных. Изменение в глобальной структуре просит пересмотра всех связанных модулей.
– Сцепление по управлению. 1 из модулей заведует действием вычислений в ином за счет сброса и конструкции флагов. Ежели значение флага дается как отдаваемый параметр, то сцепление будет являться сцеплением по предоставленным либо эталону.
– Сцепление по наружным ссылкам. Возникает при обращении к предоставленным спустя наружные точки входа.
– Сцепление по кодам. Возникает при употреблении одних и тех же участков кода.
Убавление ступени сцепления упрощает модификацию отдельных долей проекта, но сможет привести к избыточности кода и предоставленных.


Ответы на вопросы из программы курса
1. Метрики сложности программных систем

Соответственно метрики для классификации и оценки программных систем. Выделяют Метрики размера программ:

  • Кол-во строк исходного текста
  • Кол-во операторов и операндов – метрика Холстеда,

Метрики сложности потока управления и данных программ:

  • Плотность управления переходов внутри программ
  • Взаимосвязи переходов
  • Подсчет точек пересечения
  • Метрика Джилба (насыщенность выражениями IF_THEN_ELSE)
  • По методу граничных значений (по графам)
  • Метрика Чепина (оценка информационной прочности)

2. Методы проектирования сложных программных систем

Структурное проектирование ПС.

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

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

2)    принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Также основными принципами являются следующие:

3)    принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;

4)    принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы;

5)    принцип непротиворечивости – заключается в обоснованности и согласованности элементов;

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

Методология структурного анализа и структурного проектирования ПС предполагает использование одного из стилей проектирования:

  • нисходящего (Top-of-Design);
  • восходящего (Bottom-of-Design).

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

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

3. Принципы, методы и приемы декомпозиции сложных систем при OOAD

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

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

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

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

  • Определение системных свойств, значимых для решения поставленной задачи.
  • Поиск составных частей системы и их свойств, оказывающих решающие влияние на выделенные системные свойства.

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

4. Виды объектно-ориентированных моделей

Предлагается выделить два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структурном уровне поддерживаются сложные объекты, их идентификация и разновидности связи “isa”.

Важным аспектом является четкое разделение схемы БД и самой БД. В качестве первичных концепций схемного уровня ООБД выступают типы и классы. Отмечается, что во всех системах, использующих только одно понятие (либо тип, либо класс) это понятие неизбежно перегружено: тип предполагает наличие некоторого множества значений, определяемого структурой данных этого типа; класс также предполагает наличие множества объектов, но это множество определяется пользователем. Таким образом, типы и классы играют разную роль, и для строгости и недвусмысленности требуются одновременное поддержание обоих понятий.

Автор [63] не представляет полной формальной модели структурного уровня ООБД, но выражает уверенность, что текущего уровня понимания достаточно, чтобы формализовать такую модель. Что же касается поведенческого уровня, предложен только общий подход к требуемому для этого логическому аппарату (логики первого уровня недостаточно).

Важным, хотя и недостаточно обоснованным предположением Беери является то, что двух традиционных уровней – схемы и данных для ООБД недостаточно. Для точного определения ООБД требуется уровень мета-схемы (см. также [65]), содержимое которой должно определять виды объектов и связей, допустимых на схемном уровне БД. Мета-схема должна играть для ООБД такую же роль, какую играет структурная часть реляционной модели данных для схем реляционых баз данных.

Имеется достаточное количество других публикаций, отноcящихся к теме объектно-ориентированных моделей данных [61-62, 64, 65-68], но они либо затрагивают достаточно частные вопросы, либо используют слишком серьезный для этого обзора математический аппарат (к числу последних относится работа Леллани и Спиратоса [68], в которой объектно-ориентированная модель данных определяется на основе теории категорий).

Для иллюстрации текущего положения дел мы кратко рассмотрим особенности конкретной модели данных, применяемой в объектно-ориентированной СУБД O2 [29, 32] (это, конечно, тоже не модель данных в классическом смысле).

В O2 поддерживаются объекты и значения. Объект – это пара (идентификатор, значение), причем объекты инкапсулированы, т.е. их значения доступны только через методы – процедуры, привязанные к объектам. Значения могут быть атомарными или структурными. Структурные значения строятся из значений или объектов, представленных своими идентификаторами, с помощью конструкторов множеств, кортежей и списков. Элементы структурных значений доступны с помощью предопределенных операций (примитивов).

Возможны два вида организации данных: классы, экземплярами которых являются объекты, инкапсулирующие данные и поведение, и типы, экземплярами которых являются значения. Каждому классу сопоставляется тип, описывающий структуру экземпляров класса. Типы определяются рекурсивно на основе атомарных типов и ранее определенных типов и классов с применением конструкторов. Поведенческая сторона класса определяется набором методов.

Объекты и значения могут быть именованными. С именованием объекта или значения связана долговременность его хранения (persistency): любые именованные объекты или значения долговременны; любые объект или значение, входящие как часть в другой именованный объект или значение, долговременны.

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

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

В модели O2 поддерживается множественное наследование классов на основе отношения супертип/подтип. В подклассе допускается добавление и/или переопределение атрибутов и методов. Возможные при множественном наследовании двусмысленности (по именованию атрибутов и методов) разрешаются либо путем переименования, либо путем явного указания источника наследования. Объект подкласса является объектом каждого суперкласса, на основе которого порожден данный подкласс.

Поддерживается предопределенный класс “Оbject”, являющийся корнем решетки классов; любой другой класс является неявным наследником класса “Object” и наследует предопределенные методы (“is_same”, “is_value_equal” и т.д.).

Специфической особенностью модели O2 является возможность объявления дополнительных “исключительных” атрибутов и методов для именованных объектов. Это означает, что конкретный именованный объект-представитель класса может обладать типом, являющимся подтипом типа класса. Конечно, с такими атрибутами не работают стандартные методы класса, но специально для именованного объекта могут быть определены дополнительные (или переопределены стандартные) методы, для которых дополнительные атрибуты уже доступны. Подчеркивается, что дополнительные атрибуты и методы привязываются не к конкретному объекту, а к имени, за которым в разные моменты времени могут стоять вообще говоря разные объекты. Для реализации исключительных атрибутов и методов требуется развитие техники позднего связывания.

В [29] приводится достаточно формализованное описание модели O2, мы для простоты изложения и понимания следовали [32], где модель описывается на содержательном уровне. В следующем разделе мы среди прочего рассмотрим особенности языков программирования и запросов системы O2, которые, конечно, тесно связаны со спецификой модели данных.

5. Этапы OOAD: анализ, проектирование, реализация, тестирование, сопровождение. Особенности, экономика, технологии

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

Проектирование. Различают:

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

• физическое проектирование, при котором приходится принимать во внимание указанные факторы.

Логическое проектирование заключается в разработке структуры классов: определяются поля для хранения составляющих состояния объектов и алгоритмы методов, реализующих аспекты поведения объектов. При этом используются рассмотренные выше приемы разработки классов (наследование, композиция, наполнение, полиморфизм). Результатом является иерархия или диаграмма классов, отражающие взаимосвязь классов, и описание классов. Физическое проектирование включает объединение описаний классов в модули, выбор схемы их подключения (статическая или динамическая компоновка), определение способов взаимодействия с оборудованием, с операционной системой и/или другим программным обеспечением, обеспечение синхронизации процессов для систем параллельной обработки и т.д.

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

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

6. Объект: определение и основные характеристики

Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов). Объекты принадлежат одному или нескольким классам, которые в свою очередь определяют поведение (являются моделью) объекта. Время с момента создания объекта (конструкция) до его уничтожения (деструкция) называется временем жизни объекта. Объекты обладают свойствами наследования, инкапсуляции и полиморфизма. Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы.

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

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

7. Абстракция и методы классификации объектов

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

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

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

Концептуальная кластеризация. При таком подходе сначала формируются концептуальные описания классов (кластеров объектов), а затем мы классифицируем сущности в соответствии с этими описаниями.

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

8. Отношения между объектами: моделирование, проектирование, визуализация

9. Диаграммы объектов: фаза OOAD, назначение, компоненты

10. Классы: определение, назначение, моделирование

11. Роль классов и объектов в анализе и проектировнии.

Определите понятия/классы и установите основные связи между ними. Главное в хорошем проекте – прямо отразить какое-либо понятие “реальности”, т.е. уловить понятие из области приложения классов, представить взаимосвязь между классами строго определенным способом, например, с помощью наследования, и повторить эти действия на разных уровнях абстракции.

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

Предлагаем следующую стратегию(минимализм):

  1. Рассмотрите, каким образом объект класса будет создаваться, копироваться (если нужно) и уничтожаться.
  2. Определите минимальный набор операций, который необходим для понятия, представленного классом.
  3. Рассмотрите операции, которые могут быть добавлены для удобства записи, и включите только несколько действительно важных.
  4. Рассмотрите, какие операции можно считать тривиальными, т.е. такими, для которых класс выступает в роли интерфейса для реализации производного класса.
  5. Рассмотрите, какой общности именования и функциональности можно достигнуть для всех классов компонента.

Иногда полезно классифицировать операции класса по тому, как они работают с внутренним состоянием объектов:

  1. Базовые операции: конструкторы, деструкторы, операции копирования.
  2. Селекторы: операции, не изменяющие состояния объекта.
  3. Модификаторы: операции, изменяющие состояние объекта.
  4. Операции преобразований, т.е.  операции, порождающие объект другого типа, исходя из значения (состояния)  объекта,  к которому они применяются.
  5. Повторители: операции, которые открывают доступ к объектам класса или используют последовательность объектов.

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

12. Отношения между классами

Каждый класс, как не раз отмечалось, играет две роли: он является модулем – архитектурной единицей, и он имеет содержательный смысл, определяя некоторый тип данных.

Определение 1. Классы А и В находятся в отношении “клиент-поставщик“, если одним из полей класса В является объект класса А. Класс А называется поставщиком класса В, класс В называется клиентом класса А.

Определение 2. Классы А и В находятся в отношении “родитель – наследник“, если при объявлении класса В класс А указан в качестве родительского класса. Класс А называется родителем класса В, классВ называется наследником класса А.

Оба отношения – наследования и вложенности – являются транзитивными. Если В – клиент А и С – клиент В, то отсюда следует, что С – клиент А. Если В – наследник А и С – наследник В, то отсюда следует, что С – наследник А.

Для отношения наследования используется терминология, заимствованная из естественного языка. Прямые классы-наследники часто называются сыновними или дочерними классами. Непрямые родители называются предками, а их непрямые наследники – потомками.

Отношение вложенности

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

13. Наследование

Мощь ООП основана на наследовании. Когда построен полезный класс, то он может многократно использоваться. Повторное использование – это одна из главных целей ООП.

Класс-потомок наследует все возможности родительского класса – все поля и все методы, открытую и закрытую часть класса. Правда, не ко всем полям и методам класса возможен прямой доступ потомка. Поля и методы родительского класса, снабженные атрибутом private, хотя и наследуются, но по-прежнему остаются закрытыми, и методы, создаваемые потомком, не могут к ним обращаться напрямую, а только через методы,наследованные от родителя. Единственное, что не наследует потомок – это конструкторы родительского класса. Конструкторы потомок должен создавать сам.

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

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

Вызов конструктора родителя происходит не в теле конструктора, а в заголовке, пока еще не создан объект класса

14. Критерии оценки качества модульной декомпозиции

Пять критериев
Метод проектирования, который можно называть “модульным”, должен удовлетворять пяти основным требованиям:

  • Декомпозиции (decomposability).
  • Композиции (composability).
  • Понятности (understandability).
  • Непрерывности (continuity).
  • Защищенности (protection).

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

Следствием требования декомпозиции является разделение труда (division of labor): как только система будет разложена на подсистемы, работу над ними следует распределить между разными разработчиками или группами разработчиков. Это трудная задача, так как необходимо ограничить возможные взаимозависимости между подсистемами:

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

Наиболее очевидным примером обсуждаемого метода1), удовлетворяющим критерию декомпозиции, является метод нисходящего (сверху вниз) проектирования (topdown design).

15. Диаграмма состояний связывает события и состояния. При приеме события следующее состояние системы зависит как от ее текущего состояния, так и от события; смена состояния называется переходом. Компоненты.Диаграмма состояний – это граф, узлы которого представляют состояния, а направленные деги, помеченные именами соответствующих событий, – переходы. Диаграмма состояний позволяет получить последовательность состояний по заданной последовательности событий.

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

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

16. Диаграмма активностей (или, как часто говорят, диаграмма деятельности) – диаграмма UML. Они позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое. Но этот вид может быть использован и для описания динамики совокупности объектов. Они применимы и для детализации некоторой конкретной операции. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми деятельностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей. Может быть присоединена к любому элементу модели, имеющему динамическое поведение, траекторию объекта, или поток объекта (object flow)на диаграмме деятельности можно изобразить.

– Для моделирования процессов

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

– Для моделирования операций

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

17. Модели жизненного цикла программного продукта.

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

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

– Поэтапная модель с промежуточным контролем Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

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

 

 

 

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

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

 

18.

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

Моделирование исключений производится так:

  1. Для каждого класса и интерфейса и для каждой определенной в них операции рассмотрите, какие исключения могут возбуждаться.
  2. Организуйте исключения в иерархию. На верхних уровнях разместите общие исключения, на нижних – специализированные, а при необходимости введите промежуточные исключения.
  3. Укажите для каждой операции, какие исключения она может возбуждать. Это можно сделать явно на диаграмме (проведя зависимости типа send от операции к ее исключениям) или же поместить перечень исключений в спецификацию операции.

Исключение в Java — это объект, который описывает исключительное состояние, воз­никшее в каком-либо участке программного кода. Когда возникает ис­ключительное состояние, создается объект класса Exception. Этот объект пересылается в метод, обрабатывающий данный тип исключительной ситуации. Исключения могут возбуждаться и «вруч­ную» для того, чтобы сообщить о некоторых нештатных ситуациях.

Типы исключений

В вершине иерархии исключений стоит класс Throwable. Каждый из типов исключений является подклассом класса Throwable. Два непосредственных наследника класса Throwable делят иерархию подклассов исключений на две различные ветви. Один из них — класс Ехception — используется для описания исключительных ситуации, кото­рые должны перехватываться программным кодом пользователя. Другая ветвь дерева подклассов Throwable — класс Error, который предназначен для описания исклю­чительных ситуаций, которые при обычных условиях не должны перехватываться в пользовательской программе.

Неперехваченные исключения Объекты-исключения автоматически создаются исполняющей средой Java в результате возникновения определенных исключительных состо­яний.

(Для задания блока программного кода, который требуется защитить от исключений, исполь­зуется ключевое слово try. Сразу же после try-блока помещается блок catch, задающий тип исключения которое вы хотите обрабатывать. В некоторых случаях один и тот же блок программного кода может воз­буждать исключения различных типов. Для того, чтобы обрабатывать по­добные ситуации, Java позволяет использовать любое количество catch-разделов для try-блока. Наиболее специализированные классы исключений должны идти первыми, поскольку ни один подкласс не будет достигнут, если поставить его после суперкласса. Следующая про­грамма перехватывает два различных типа исключений, причем за этими двумя специализированными обработчиками следует раздел catch общего назначения, перехватывающий все подклассы класса Throwable. Оператор throw используется для возбуждения исключения «вруч­ную». Для того, чтобы сделать это, нужно иметь объект подкласса клас­са Throwable, который можно либо получить как параметр оператора catch, либо создать с помощью оператора new. Ниже приведена общая форма оператора throw. Иногда требуется гарантировать, что определенный участок кода будет выпол­няться независимо от того, какие исключения были возбуждены и пере­хвачены. Для создания такого участка кода используется ключевое слово finally.)

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

19. Моделирование взаимодействия объектов

20. Диаграммы взаимодействия: фазы применения, назначение, компоненты.

21. Потоки управления: фазы применения, назначение

Поток представляет собой поток управления (вызов функции, метода, последовательность команд), выполняемых независимо (физически параллельно или в режиме переключения ядром операционной системы (ОС)) от основного потока управления (main) и других потоков. Каждый поток имеет собственный локальный контекст – локальные данные и «историю вызовов», т.е. стек. В технологии ООП потоки реализуются в виде класса, имеющего объявленный метод (run), выполняемый в каждом объекте в виде независимого потока. К сожалению, в Си++ концепция потоков  не поддерживается. Потоковое программирование весьма плодотворно при программировании систем, в которых имеется множество идентичных независимо исполняемых работ. Реализация потоков обычно поддерживается на уровне ОС.

Для ООП

Поток управления: определенная последовательность вызовов функций. Поток управления: состоит из двух частей — неопределенная последовательность взаимодействий объектов и определенная последовательность вызвов методов внутри объекта.

Для КОП

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

22) Прецеденты. Проектирование программной системы с использованием прецедентов

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

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

1. Диаграммы прецедентов.

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

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

 

Актеры не являются частью системы – они представляют что угодно (или кого угодно), что взаимодействует с системой. Прецедент использования – это последовательность выполняемых системой транзакций, приводящих к измеримому результату, важному для конкретного актера. Между прецедентами использования может существовать два типа связей:

  • включение (include, uses);
  • расширение (extend).

23) Разработка прецедентов. Назначение и компоненты диаграммы прецедентов.

 

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

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

К прецедентам в UML применимы следующие виды отношений:

  • Ассоциация (англ. Association) — может указывать на то, что актер инициирует соответствующий вариант использования.

В том числе между прецедентами:

  • Расширение (англ. Extend) — разновидность отношения зависимости между базовым вариантом использования и его специальным случаем.
  • Включение (англ. Include) — определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.
  • Обобщение (англ. Generalization, наследование) — моделирует соответствующую общность ролей.

 

24)     Смотри 23 и 22

25)     Диаграммы взаимодействия: фазы применения, назначение, компоненты.

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

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

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

Как правило, диаграммы взаимодействий (см. главу 15) содержат:

  • объекты
  • связи
  • сообщения

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

26)Модели жизненного цикла программных продуктов

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.

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

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

Итерационная модель, это рациональная комбинация двух предыдущих моделей.

27) Особенности процесса RUP в соотнесении с известными моделями жизненного цикла

RUP

Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее – Rational) для управления процессами разработки. Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.

Жизненный цикл проекта

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

Начало (Inception)

Фаза Начало обычно состоит из одной итерации. В ходе выполнения этой фазы необходимо:

  • Определить видение и границы проекта.
  • Создать экономическое обоснование (business case).
  • Идентифицировать большую часть прецедентов использования и подробно описать несколько ключевых прецедентов.
  • Найти хотя бы одно возможное архитектурное решение.
  • Оценить бюджет, график и риски проекта.

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

Проектирование (Elaboration)

В результате выполнения этой фазы на основе требований и рисков проекта создается основа архитектуры системы. Проектирование может занимать до двух-трех итераций или быть полностью пропущенным (если в проекте используется архитектура существующей системы без изменений). Целями этой фазы являются:

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

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

Построение (Construction)

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

Внедрение (Transition)

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

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

Рабочий процесс

В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles). Артефактами являются спецификации, модели, исходный код и т.п. Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline). В RUP определены шесть инженерных и три вспомогательные дисциплины. В них входят:

  • Бизнес-моделирование (Business Modeling) – исследование и описание существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.
  • Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.
  • Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.
  • Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.
  • Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.
  • Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.
  • Управление конфигурациями и изменениями (Configuration and Change Management) – управление версиями исходного кода и документации, процесс обработки запросов на изменение (change requests).
  • Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.
  • Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки.

 

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

Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников. При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.

 

28) Процессы, фазы, и итерации в ходе OOAD

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

Фазы начала и исследования охватывают проектные стадии жизненного цикла процесса разработки; фазы построения и внедрения относятся к производству. Внутри каждой фазы происходит несколько итераций. Итерация (iteration) представляет полный цикл разработки, от выработки требований во время анализа до реализации и тестирования. Итерация – это завершенный этап, в результате которого выпускается версия (для внутреннего или внешнего использования) исполняемого продукта, реализующая часть запланированных функций. Затем эта версия от итерации к итерации наращивается до получения готовой системы. Во время каждой итерации выполняются особые рабочие процессы, хотя в разных фазах основной упор делается на разных работах. В начальной фазе главной задачей является выработка требований, в фазе исследования – анализ и проектирование, в фазе построения – реализация, а в фазе внедрения – развертывание.
Конечным результатом является выпуск готового продукта. Все фазы и итерации подразумевают определенные затраты усилий на снижение рисков. В конце каждой фазы находится четко определенная опорная точка, где оценивается, в какой мере достигнуты намеченные цели и не следует ли внести в процесс изменения, прежде чем двигаться дальше.
Прохождение через четыре основные фазы называется циклом разработки. Каждый цикл завершается генерацией версии системы. Первый проход через все четыре фазы называют начальным циклом разработки. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы: начальную, исследования, построения и внедрения. Система таким образом эволюционирует, поэтому все циклы, следующие за начальным, называются эволюционными.

 

29) Определение  прецедентов на различных этапах OOA

 

30) Проектирование системной архитектуры

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

Статический срез системной архитектуры на определенный момент времени включает:

  • архитектуру приложений — функциональный и компонентный состав информационной системы
  • архитектуру данных — способы взаимодействия систем и хранения данных
  • архитектуру оборудования — используемые технические средства/решения

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

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

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

 

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

• Диаграмма взаимодействия крупных модулей – схемы

• Диаграмма плана счетов  – своя нотация

• Диаграмма схемы сущностей                             – UML

• Понятийное описание алгоритма  – Текст + схемы

• Схема переходов документа                               – Граф

• Сценарий использования интерфейсов             – Текст + схемы

31. Моделирование программной системы с использованием представлений

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

Моделирование системы с использованием различных представлений осуществляется следующим образом:

  1. Решите, какие именно виды лучше всего отражают архитектуру системы и возможный технический риск, связанный с проектом. При этом стоит начать с описанных выше пяти взглядов на архитектуру (см. главу 2).
  2. В отношении каждого из выбранных видов определите, какие артефакты необходимо создать для отражения его наиболее существенных деталей. Эти артефакты по большей части будут состоять из различных диаграмм UML.
  3. В ходе планирования процесса решите, какие из диаграмм удобнее всего превратить в инструмент контроля (формального или неформального) за разработкой системы. Эти диаграммы вы будете периодически корректировать и сохранять в составе проектной документации.
  4. На всякий случай сохраняйте даже забракованные диаграммы, – они могут пригодиться при анализе результатов ваших действий и для экспериментов по изменению каких-либо рабочих параметров.

Допустим, если вы моделируете простое приложение, выполняемое на одном компьютере, могут потребоваться только ниже перечисленные диаграммы:

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

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

Если система построена на архитектуре “клиент/сервер”, то стоит включить в работу диаграммы компонентов и развертывания для моделирования конкретных физических деталей реализации.

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

  • вид с точки зрения прецедентов – диаграммы прецедентов и диаграммы действий (для моделирования поведения);
  • вид с точки зрения проектирования – диаграммы классов (структурное моделирование), диаграммы взаимодействия (моделирование поведения), диаграммы состояния (моделирование поведения);
  • вид с точки зрения процессов – снова диаграммы классов (структурное моделирование) и диаграммы взаимодействия (моделирование поведения);
  • вид с точки зрения реализации – диаграммы компонентов;
  • вид с точки зрения развертывания – диаграммы развертывания.

 

32. Качество, надежность программного продукта и их метрики

Качество программного средства(software quality) – совокупность свойств программного средства (ПС), которые обусловливают его пригодность удовлетворять заданные или подразумеваемые потребности в соответствии с его назначением.

ОБЩИЕ ХАРАКТЕРИСТИКИ КАЧЕСТВА ПРОГРАММНОГО СРЕДСТВА

1. Функциональность программного средства (functionality)

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

2. Удобство использования программного средства (usability)

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

3. Эффективность программного средства (efficiency)

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

Примечание: правильнее эту характеристику называть производительностью (performance); тогда как эффективность дожна также зависеть от затрат на создание и внедрение ПС.

4. Сопровождаемость программного средства(maintainability)

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

5. Мобильность программного средства (portability)

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

6. Надежность программного средства (reliability)

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

В зависимости от характеристик и особенностей показателя качества применяются различные виды метрик и шкал для их измерения.

Первый вид метрик, которому соответствует интервальная шкала, характеризуется реально измеряемыми физическими показателями, например

  • временем выполнения программы,
  • числом маршрутов в программе,
  • числом таблиц в базе данных,
  • объемом программы и т.д.

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

Второй вид метрик (порядковая шкала) позволяет ранжировать некоторые характеристики путем сравнения с опорными значениями. Для объекта измерения устанавливается приоритетность признаков. Различают абсолютные и относительные порядковые метрики, первые из которых показывают больше или меньше значение данного параметра программы по сравнению с опорным, а второй – во сколько раз больше или меньше. Математические преобразования с такими показателями более ограничены, чем у первого вида метрик.

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

33. Пакеты классов в Java-технологии

Java package (пакет Java) — механизм, позволяющий организовать Java классы в пространства имен аналогично модулям в языке программирования Модула.

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

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

Классы, определенные без явно заданных модификаторов доступа (public, protected, private), видимы только внутри пакета.

Основные пакеты в J2SE 6.0

 

 

java.lang — basic language functionality and fundamental types
java.util — collection data structure classes
java.io — file operations
java.math — multiprecision arithmetics
java.nio — the New I/O framework for Java
java.net — networking operations, sockets, DNS lookups, …
java.security — key generation, encryption and decryption
java.sql Java Database Connectivity (JDBC) to access databases
java.awt — basic hierarchy of packages for native GUI components
javax.swing — hierarchy of packages for platform-independent rich GUI components

 

Все классы Java распределяются по пакетам. Кроме классов пакеты могут включать в себя интерфейсы и вложенные подпакеты (subpackages).

Каждый пакет образует одно пространство имен (namespace). Это означает, что все имена классов, интерфейсов и подпакетов в пакете должны быть уникальны. Имена в разных пакетах могут совпадать, но это будут разные программные единицы. Таким образом, ни один класс, интерфейс или под-пакет не может оказаться сразу в двух пакетах. Если надо использовать два класса с одинаковыми именами из разных пакетов, то имя класса уточняется именем пакета: пакет.класс . Такое уточненное имя называется полным именем класса (fully qualified name).

Пакетами пользуются еще и для того, чтобы добавить к уже имеющимся правам доступа к членам класса private, protected и public еще один, “пакетный” уровень доступа.

Если член класса не отмечен ни одним из модификаторов private, protected, public, то, по умолчанию, к нему осуществляется пакетный доступ (default access), а именно, к такому члену может обратиться любой метод любого класса из того же пакета. Пакеты ограничивают и доступ к классу целиком — если класс не помечен модификатором public , то все его члены, даже открытые, public , не будут видны из других пакетов. Чтобы создать пакет надо просто в первой строке Java-файла с исходным кодом записать строку package имя; , например:

package mypack;

Тем самым создается пакет с указанным именем mypack и все классы, записанные в этом файле, попадут в пакет mypack . Повторяя эту строку в начале каждого исходного файла, включаем в пакет новые классы.

Если пакет не создавать, то файлы с откомпилированными классами попадают в безымянный пакет, которому соответствует текущий каталог (current working directory)

файловой системы. Вот поэтому у нас class-файл всегда оказывался в том же каталоге, что и соответствующий Java-файл.

Безымянный пакет служит обычно хранилищем небольших пробных или промежуточных классов. Большие проекты лучше хранить в пакетах. Например, библиотека классов Java 2 API хранится в пакетах java, javax, org.omg. Пакет Java содержит только подпакеты applet, awt, beans, io, lang, math, net, rmi, security, sql, text, util и ни одного класса. Эти пакеты имеют свои подпакеты, например, пакет создания ГИП и графики java.awt содержит подпакеты color, datatransfer, dnd, event, font, geometry, im,image, print.

 

34. Базовые классы пространства имен System

Java Platform, Standard Edition, сокращенно Java SE (ранее Java 2 Standard Edition или J2SE) — стандартная версия платформы Java 2, предназначенная для создания и исполнения апплетов и приложений, рассчитанных на индивидуальное пользование или на использование в масштабах малого предприятия. Не включает в себя многие возможности, предоставляемые более мощной и расширенной платформой Java 2 Enterprise Edition (J2EE), рассчитанной на создание коммерческих приложений масштаба крупных и средних предприятий.

java.lang

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

Основные классы в java.lang:

Object — этот класс является корнем иерархии классов в Java;

Enum — базовый класс для перечислимого типа (с версии J2SE 5.0);

Class — класс является основным в подсистеме интроспекции Java;

ClassLoader — абстрактный класс, определяет, как загружаются классы. Ваше приложение может создавать подклассы, расширяющие ClassLoader, реализуя его методы. Это позволяет загружать классы другими способами, нежели тот, которым выполняется обычная загрузка в системе времени выполнения Java. Однако обычно вы не должны этого делать;

Throwable — класс является базовым для иерархии классов исключений;

Error, Exception, RuntimeException — базовые классы для каждого подтипа исключений;

Thread — класс, содержащий операции над потоками исполнения;

String — класс для представления строк и их значений;

StringBuffer и StringBuilder — классы для работы со строками (StringBuilder с версии J2SE 5.0);

Comparable — интерфейс для поддержки обобщённого сравнения и упорядочения объектов (с версии J2SE 1.2);

Iterable — интерфейс для поддержки улучшенного цикла for (с версии J2SE 5.0);

ClassLoader, Process, Runtime, SecurityManager, System — выполняют «системные операции». Управляют динамической загрузкой классов, созданием внешних процессов, получением информации об окружающей среде (например времени суток), и следят за выполнением политик безопасности;

Math и StrictMath — содержат основные математические функции, такие как вычисление синуса, косинуса и квадратного корня (StrictMath с версии J2SE 1.3);

Классы-обёртки над примитивными типами, которые превращают их в объекты;

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

Все классы из пакета java.lang автоматически подключаются в каждый исходный файл программы. Явное подключение не требуется.

java.lang.annotation

В этом пакете определен интерфейс Annotation, а также перечисления ElementType и RetentionPolicy.

java.lang.instrument

Пакет определяет средства, которые могут быть использованы для добавления инструментария для разных аспектов выполнения программ. Он определяет интерфейсы Instrumentation и ClassFileTransformer, а также класс ClassDefinition.

java.lang.management

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

java.lang.ref

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

java.lang.reflect

Пакет java.lang.reflect обеспечивает механизм отражения — способность программного обеспечения к самоанализу (то есть получению информации об имеющихся в системе классах, их методах, полях и связях). Отражение — важная возможность, необходимая при использовании компонентов, называемых Java Beans.

java.io

Содержит классы для обеспечения файлового ввода-вывода информации, несколько классов абстракции ввода/вывода, а также набор классов для обработки вводимой информации: выделения токенов и т. д.

java.math

Содержит классы для вычислений над большими целыми числами (класс BigInteger) и над десятичными дробями произвольной точности (класс BigDecimal).

java.net

Содержит классы, позволяющие приложению работать с сетью, предоставляя абстракции для сетевых адресов, соединений, реализацию сокетов и т. д.

java.text

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

java.util

Вспомогательные классы и интерфейсы. Очень удобные и используемые практически в каждой программе.

java.applet

Для работы в браузере

java.beans

java.awt

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

java.rmi

java.security

java.sql

JDBC (Java Database Connectivity)

javax.swing

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


35. Определение класса и его компонент в языке Java

Базовым элементом объектно-ориентирован­ного программирования в языке Java являет­ся класс. Классы в Java не обязательно должны содержать метод main. Единственное назначение этого метода — указать интерпретатору Java, откуда надо начинать выполнение программы. Для того, чтобы создать класс, достаточно иметь исходный файл, в котором будет присутствовать ключевое слово class, и вслед за ним — допустимый идентификатор и пара фигурных скобок для его тела. Класс определяет структуру объекта и его методы, образующие функциональный интерфейс. В процессе выполнения Java-программы система использует определения классов для создания представителей классов. Представители являются реальными объектами. Термины «представитель», «экземпляр» и «объект» взаимозаменяемы.

Определение класса на языке Java с помощью оператора class:

  class MyClass {
      String name = "Example";
      // "Конструктор"
      public MyClass(String name) {
          this.name = name;
      }
      // "Метод"
      public String getName() {
          return name;
      }
  }

 

Создание экземпляра класса:

  MyClass my = new MyClass("Example 2");

 

36. Методы классов. Перегрузка методов.

Методы – это подпрограммы, присоединенные к кон­кретным определениям классов. Они описываются внутри определения класса на том же уровне, что и переменные объектов. При объявлении метода задаются тип возвращаемого им результата и список параметров. Общая форма объявления метода такова:

тип имя_метода (список формальных параметров) {

тело метода:

}

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

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

При вызове перегруженного метода для определения нужной версии Java использует тип и/или количество аргументов метода. Следовательно, перегруженные методы должны различаться по типу и/или количеству их параметров. Хотя возвращаемые типы перегруженных методов могут быть различны, самого возвращаемого типа не достаточно для различения двух версий метода. Когда Java встречает вызов перегруженного метода, она просто выполняет ту его версию, параметры которой соответствуют аргументам, использованным в вызове.

37. Принципы инкапсуляции и модификаторы доступа в языке Java

Свойства инкапсуляции:

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

 

Основой инкапсуляции в Java является класс. Класс определяет данные и код некоторого набора объектов. Объект является экземпляром класса. Таким образом, класс – это логическая конструкция, а объект – физическая реальность.

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

Цель класса – инкапсуляция сложности. Для этого у методов и переменных внутри класса могут быть модификаторы доступа (public, private).

Инкапсуляция означает, что данные объекта недоступны его клиентам непосредственно. Вместо этого они инкапсулируются — скрываются от прямого доступа извне. Инкапсуляция предохраняет данные объекта от нежелательного доступа, позволяя объекту самому управлять доступом к своим данным.

  1. Модификаторы доступа являются реализацией принципа инкапсуляции в языке Java.

  2. Изменяя модификаторы, можно контролировать область видимости

Полей

Методов

классов

Модификаторы полей

Отсутствие модификатора – поле доступно только из текущего пакета.

static – поле принадлежит структуре класса. Одно значение присуще всем экземплярам.

final – поле не может быть изменено.

transient – не участвует в процессе сериализации по умолчанию.

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

protected – поле не может быть использовано нигде кроме данного класса и всех его наследников.

volatile – значение этого поля будет обновляться каждый раз при обращении к нему.

 

Модификаторы методов

Отсутствие модификатора – доступен только из данного пакета.

public – метод доступен из любого пакета (публичный API).

final – не может быть переопределен в наследнике.

static – метод принадлежит классу.

abstract – метод не имеет реализации.

synchronized – запрещено одновременное выполнение метода на разных потоках.

native – метод имеет реализацию на языке C.

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

protected – метод не может быть использован ниоткуда кроме данного класса (его объекта) и всех его наследников (их объектов).

Модификаторы классов

Отсутствие модификатора – доступен в текущем пакете.

public – класс доступен из любого пакета (публичный API).

final – не может расширяться методом наследования от него.

abstract – класс является абстрактным, нельзя создать объект этого класса.

static – допустимо только для вложенных классов.

 

 

38. Отношения наследования. Реализация наследования в языке Java

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

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

Единичное наследование:

–          подкласс может наследовать свойства единственного базового класса;

–          детали реализации могут изменяться, если родительский класс объявлен абстрактным (abstract).

–          класс может наследовать свойства класса.

–          подкласс с неявным базовым классом наследует свойства класса «объект» (java.lang.Object).

Особенности наследования в Java

  • Определение производного класса снабжается описателем extends.
  • «Нижние» уровни «расширяют» «верхние» новыми свойствами/методами, сохраняя свойства/методы «верхних уровней»
  • Наследование может быть многоуровневым – общие атрибуты/методы «выталкиваются» как можно «выше» по иерархии
  • Подкласс НЕ может обращаться к элементам суперкласса с модификатором  private (а лишь public или protected)

 

Иерархия классов и наследование в Java

 

Java разрешает уровни наследования, определяемые в непосредственном/косвенных суперклассах

Возможные способы изменения подклассом поведения и структуры суперкласса:

  • расширение суперкласса добавлением новых данных и методов;

  • замена методов суперкласса переопределением;

–           слияние методов вызовом одноименных методов из суперклассов. Суперкласс по умолчанию – java.lang.Object.

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

 

 

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

 

Класс может заимствовать методы другого класса. Язык Java поддерживает операцию наследования:

// наследование производится с помощью

// ключевого слова extends

public class Dragon extends Reptile {

//внутреннее поле класса

private String magic = “fire”;

public String getMagic(){

//возврат результата

return fire;

}

}

 

39. Формы полиморфизма. Реализация полиморфизма в языке Java

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

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

Полиморфизм при помощи абстрактных классов. Абстрактные классы поддерживают как наследование, так и возможности интерфейсов. При построении сложной иерархии, для обеспечения полиморфизма программисты часто вынуждены вводить методы в классы верхнего уровня при том, что эти методы ещё не определены. Абстрактный класс – это класс, экземпляр которого невозможно создать; этот класс может лишь служить базовым классом при наследовании. Нельзя объявлять абстрактные конструкторы или абстрактные статические методы. Некоторые или все члены этого класса могут оставаться нереализованными, их реализацию должен обеспечить наследующий класс. Производные классы, которые не переопределяют все абстрактные методы, должны быть отмечены как абстрактные. Порожденный класс может реализовывать также дополнительные интерфейсы.

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

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

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

Полиморфизм через переопределение методов Если перегруженные методы с одинаковыми именами находятся в одном классе, списки параметров должны отличаться. Но если метод подкласса совпадает с методом суперкласса (порождающего класса), то метод подкласса переопределяет метод суперкласса. Совпадать при этом должны и имена методов и типы входных и выходных параметров. В данном случае переопределение методов является основой концепции динамического связывания (или позднее связывание), реализующей полиморфизм. Суть динамической диспетчеризации методов состоит в том, что решение на вызов переопределенного метода принимается во время выполнения, а не во время компиляции. Однако final-методы не являются переопределяемыми, их вызов может быть организован во время компиляции и называется ранним связыванием.

Пример, который иллюстрирует динамическую диспетчеризацию методов (файл Dispatch.java):

class A

{

void callme()

{

System.out.println(“Метод callme класса A”);

}

}

class B extends A

{

//Переопределить callme

void callme()

{

System.out.println(“Метод callme класса B”)

}

}

class C extends A

{

//Переопределить callme

void callme()

{

System.out.println(“Метод callme класса С”);

}

}

class Dispatch

{

public static void main(String args[])

{

A a = new A();        //объект типа A

B b = new B();        //объект типа B

C c = new C();        //объект типа C

A r;                  //определить ссылку типа A

r = a;                //r указывает на A-объект

r.callme();           //вызывает A-версию callme

r = b;                //r указывает на B-объект

r.callme();           //вызывает B-версию callme

r = c;                //r указывает на C-объект

r.callme();           //вызывает C-версию callme

}

}

Вывод программы

Метод callme класса A

Метод callme класса B

Метод callme класса C

В Java все методы используют позднее связывание, если вы не отметите их явно как final. Финальные методы не могут быть переопределены и вызываются быстрее. Тот факт, что в Java по умолчанию используется позднее связывание, тогда как в C++ стандартом является раннее связывание, – явный признак разного подхода языков: C++ временами жертвует объектно-ориентированной моделью в пользу эффективности, тогда как Java – наоборот.

Полиморфизм через динамическое определение типов (RTTI)

Java позволяет узнать точный тип объекта, когда у вас есть ссылка только на базовый тип. Для этого в Java встроено безопасное преобразование типов (type-safe downcast). Cинтаксис безопасного преобразования типов:

Dog MyDog = (Dog) myAnimal;

В случае ошибки выбрасывается исключение.

Полиморфизм представлений Известно, что в ряде ситуаций полезен “полиморфизм представлений”, когда один объект имеет несколько представлений, оптимизированных для выполнения специфических операций. В идеале эти представления должны поддерживаться на протяжении всего жизненного цикла объекта. Авторы Java предложили частичное решение проблемы полиморфизма представлений, введя “копирующие” конструкторы, создающие новый экземпляр коллекции из элементов существующего набора, быть может, отличающегося реализацией. Например, конструктор TreeSet(Collection c) позволяет представить коллекцию c в виде экземпляра класса TreeSet.

40. Обработка событий в языке Java

Несмотря на существенные изменения механизма обработки событий в AWT, Java1.1 поддерживает обратную совместимость с моделью обработки событий, принятой в Java 1.0. Однако такая совместимость относится к типу “все или ничего”—эти две модели настолько отличаются друг от друга, что их невозможно использовать в одном приложении одновременно.

Модель обработки событий Java 1.0

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

Каждый компонент может обрабатывать события, заместив определенные методы, вызываемые используемой по умолчанию реализацией метода handleEvents класса Component. Этот метод вызывается с объектом класса Event, описывающего все возможные типы событий. Наиболее часто используемые события, например, те, что связаны с мышью и клавиатурой, диспетчеризируются другим методам класса Component.

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

mouseEnter вызывается в том случае, когда мышь входит в компонент.

mouseExit вызывается при выходе мыши из области компонента.

mouseMove вызывается при перемещении мыши в области компонента.

mouseDown вызывается при нажатии кнопки мыши.

mouseDrag вызывается при перемещении мыши с нажатой кнопкой.

mouseUp вызывается при отпускании кнопки мыши.

Аналогично, keyDown и keyUp вызываются при каждом нажатии и отпускании клавиши. Событие передается методу вместе с кодом нажатой клавиши. Событие можно проверить, чтобы посмотреть, нажаты ли в данный момент какие либо клавиши-модификаторы, для этой цели можно также пользоваться методами shiftDown, controlDown и metaDown. В классе Event определены десятки констант, позволяющих использовать символические имена, например, PGUP и HOME.

Наконец, для работы со специальными событиями, например, с обратными вызовами (callback) из компонентов Button, Scrollbar и Menu, вам придется замещать метод action. Этот метод вызывается с исходным событием и со вторым параметром, который представляет собой компонент пользовательского интерфейса, создавший это событие. Вы должны проверить этот объект, разобраться, какой из компонентов послал вам событие, после чего передать управление соответствующему данному компоненту обработчику. Для того, чтобы перед приведением типа проверить, принадлежит ли объект к определенному классу, например, к классу Button, вы можете использовать оператор instanceof.

Модель обработки событий Java 1.1

Новая модель обработки событий представляет собой, по существу, модель обратных вызовов (callback). При создании GUI-элемента ему сообщается, какой метод или методы он должен вызывать при возникновении в нем определенного события (нажатия кнопки, мыши и т.п.). Эту модель очень легко использовать в C++, поскольку этот язык позволяет оперировать указателями на методы (чтобы определить обратный вызов, необходимо всего лишь передать указатель на функцию). Однако в Java это недопустимо (методы не являются объектами). Поэтому для реализации новой модели необходимо определить класс, реализующий некоторый специальный интерфейс. Затем можно передать экземпляр такого класса GUI-элементу, обеспечивая таким образом обратный вызов. Когда наступит ожидаемое событие, GUI-элемент вызовет соответствующий метод объекта, определенного ранее.

Модель обработки событий Java 1.1 используется как в пакете AWT, так и в JavaBeans API. В этой модели разным типам событий соответствуют различные классы Java. Каждое событие является подклассом класса java.util.EventObject. События пакета AWT, которые и рассматриваются в данной главе, являются подклассом java.awt.AWTEvent. Для удобства события различных типов пакета AWT (например, MouseEvent или АсtionEvent) помещены в новый пакет java.awt.event.

Для каждого события существует порождающий его объект, который можно получить с помощью метода getSource(), и каждому событию пакета AWT соответствует определенный идентификатор, который позволяет получить метод getid(). Это значение используется для того, чтобы отличать события различных типов, которые могут описываться одним и тем же классом событий. Например, для класса FocusEvent возможны два типа событий: FocusEvent.FOCUS_GAINED и FocusEvent.FOCUS_LOST. Подклассы событий содержат информацию, связанную с данным типом события. Например, в классе MouseEvent существуют методы getX(), getY() и getClickCount (). Этот класс наследует, в числе прочих, и методы getModifiers() и getWhen().

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

Источник события оповещает объект слушателя путем вызова специального метода и передачи ему объекта события (экземпляра подкласса EventObject). Для того чтобы источник мог вызвать данный метод, он должен быть реализован для каждого слушателя. Это объясняется тем, что все слушатели событий определенного типа должны реализовывать соответствующий интерфейс. Например, объекты слушателей событий ActionEvent должны реализовывать интерфейс ActionListener. В пакете Java.awt.event определены интерфейсы слушателей для каждого из определенных в нем типов событий (например, для событий MouseEvent здесь определено два интерфейса слушателей: MouseListener и MouseMotionListener). Все интерфейсы слушателей событий являются расширениями интерфейса java.util.EventListener. В этом интерфейсе не определяется ни один из методов, но он играет роль интерфейса-метки, в котором однозначно определены все слушатели событий как таковые.

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


41. Шаблоны проектирования и их использование при OOAD

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

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

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

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

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


Pin It on Pinterest

Привет! Меня зовут Дамир
me_mark5
и это мой сайт.
Чтобы он работал, ему необходима денежка, поэтому понажимайте на рекламу на этой странице – буду вам очень благодарен

Яндекс.Метрика