24.Диаграммы классов. N-арные ассоциации.

Ранее мы рассматривали только о бинарные ассоциации. Однако иногда вам могут встретиться и n-арные ассоциации(ассоциации между тремя и более классами). Рекомендуется избегать использования n-арных ассоциаций в моделях: большинство из них могут быть разбиты на бинарные ассоциации с квалификаторами и атрибутами.

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

25.Диаграммы классов. Агрегация. Композиция.

Агрегация (aggregation) – это частный случай ассоциации, описывающий объекты, состоящие из

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

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

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

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

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

26.Диаграммы классов. Абстрактные классы. Множественное наследование – особенности, недостатки.

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

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

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

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

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

28.Конвенции программирования – качественные классы (модули).

29.Конвенции программирования – цели создания методов.

30.Конвенции программирования – именование методов.

31.Конвенции программирования – особенности параметров методов.

32.Конвенции программирования – именование переменных (типов и констант).

33.Сборка ПО.

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

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

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

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

Ошибки и дефекты отдельных подсистем и системы в целом часто проявляются именно на этапе сборки.

34.Аттестация программных систем. Процесс тестирования систем. Альфа и бета тестирование.

Аттестация ПО, или более обобщенно – верификация и аттестация, предназначена показать соответствие системы ее спецификации, а также ожиданиям и требованиям заказчика и пользователей.

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

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

Процесс тестирования состоит из нескольких этапов.

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

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

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

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

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

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

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

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