UML и процесс разработки

 UML и процесс разработки

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

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


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

Рассмотрим элементы UML и выясним, как моделируются основные аспекты и понятия реального мира. Это позволит сформировать основу для списка терминов проекта.
Объекты
 
Класс—это набор объектов, имеющих одинаковые характеристики. Сравним объект на основе особенностей, выделенных в предыдущем разделе.
 Класс можно идентифицировать по имени, понятному человеку, и это имя уникально в определенном контексте (например, Кредитная Карта или Банковский Счет). Имя объекта, если оно задано в понятной человеку форме, может включать в себя имя класса, которому принадлежит объект. (Имена объектов обсуждаются далее в этой статье)
 Класс, в отличие от объекта, не имеет состояния. Но, в то же время, в классе определены атрибуты каждого объекта класса.
 Он определяет поведение в терминах операций, а не методов. Операция представляет собой службу, которая может быть запрошена объектом для изменения поведения. Метод является реализацией этой службы. Каждой операции в данном классе соответствует, как минимум, один метод объекта, принадлежащего этому классу.
Объект, принадлежащий определенному классу, часто называют экземпляром этого класса. Его можно воспринимать как абстракцию, а объект — как конкретное проявление этой абстракции.
 Но иногда можно использовать изображение класса без операций или атрибутов или даже только имя класса без остальных секций.  
Альтернативные обозначения класса
Пришло время поговорить о книжном магазине в Internet. С этого момента большая часть диаграмм будет связана с различными аспектами моделей, которые могли бы появиться в процессе разработки книжного магазина.
показаны некоторые классы, связанные с таким магазином.
 
Стоит заметить, что атрибут title (название) класса Book (статья) имеет определенный тип данных (String), а остальные три атрибута не связаны с определенными типами данных. Обратите внимание, что каждая из трех операций имеет свое представление. В статье б описаны различные детали, связанные с атрибутами и операциями.


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

Сами по себе классы практически бесполезны. Основу структуры новой системы составляют отношения между классами. В следующих подразделах рассказывается о том, как можно использовать UML для иллюстрации трех типов отношений между классами.
Ассоциация
Ассоциация — это структурная связь между классами. Ассоциация между двумя классами изображается соединяющей их прямой линией.
иллюстрирует ассоциации между классами для модели Internet-магазина.
Предполагается, что ассоциация двунаправлена, а это значит, что можно перемещаться от одного класса к другому и наоборот. Иначе говоря, оба класса знают друг о друге. Направление связи можно указать, используя стрелку. Язык UML позволяет моделировать так называемые N-арные ассоциации— отношения, включающие три или более классов. Подобные конструкции чаще всего применяются в таких областях, как моделирование данных. Так как это не относится к объектно-ориентированному моделированию, N-арные ассоциации в этой статье рассматриваться не будут.

К обозначению отношения ассоциации допускается добавлять различные детали.
 Ассоциация может иметь имя, указывающее на природу отношения. Если имя существует, изобразите треугольник, указывающий, в каком направлении это имя должно читаться. Ассоциация может отражать роли класса при его взаимодействии с другими классами. Агрегация— это специальный вид ассоциации, обозначающий отношение целоечасть, при котором один или несколько классов являются частями одного целого.
В UML агрегация показывается с помощью линии с незаштрихованным ромбом на конце.
Обобщение указывает на отношение между более общим классом (суперклассом или родительским классом) и уточняющей версией этого класса (подклассом или потомком). 
Подкласс наследует атрибуты и операции своего суперкласса (одиночное наследование) или нескольких суперклассов (множественное наследование).
Пример агрегации
Наследование — одно из ключевых свойств объектно-ориентированной парадигмы. Двумя другими важными принципами обобщения являются следующие.
 Принцип заменяемости, утверждающий, что объект подкласса может быть использован везде вместо объекта суперкласса.
 Принцип полиморфизма, утверждающий, что объект подкласса может переопределить любую операцию, унаследованную от суперкласса (или суперклассов).
Любой объект, принадлежащий подклассу, может добавлять атрибуты и операции к унаследованным от суперкласса.
В UML обобщение обозначается линией с полым треугольником на конце. 
Обобщение нескольких классов демонстрирует обобщения, существующие в модели Internet-магазина. 
Эта конструкция также бывает полезной, когда возникает необходимость разбить одно отношение многие ко многим на несколько один ко многим.
 


 
Диаграмма классов показывает классы и отношения между ними. Диаграммы классов — основной способ отображения структуры разрабатываемой системы.
представлена диаграмма классов Internet-магазина, содержащая большую часть рассмотренных на данный момент классов и отношений между ними. Эта диаграмма содержит не все существующие на данном этапе логические ассоциации. Например, классы Customer и Order должны быть связанными, так как только покупатель может разместить заказ. Также логично ожидать наличия ассоциации между классами Customer и Reviewer, так как покупатель может выступать и в роли критика.
Эти ассоциации специально не были включены в диаграмму. С одной стороны, это объясняется тем, что диаграмма и так достаточно сложна, а с другой стороны, диаграмма классов не должна показывать все связи между классами. данном случае видно, что   Customer связан с классами Reviewer и Order через другие классы, и этого достаточно для целей моделирования.

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





Главная | Готовые дипломные работы | Готовые курсовые работы | Технические дисциплины |
© DIPLOM-IQ.RU Все права защищены © 2007-2013

    Rambler's Top100     Союз образовательных
сайтов