Логическое представление
Логическое представление (см. рис. 41) концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей системы и описывает их взаимодействие. Логическое представление включает в себя, помимо прочего, конкретные требуемые классы, диаграммы Классов и диаграммы Состояний. С их помощью разработчики могут сконструировать детальный проект создаваемой системы. Рисунок 41 - Логическое представление системы Логическое представление содержит:
Часто разработка Логического представления осуществляется в два этапа. Сначала определяются классы анализа (analysis classes). Они не зависят от языка программирования. Создавая их в первую очередь, разработчики MOiyr увидеть структуру системы, не углубляясь в специфические особенности конкретного языка. В языке UML для изображения классов анализа используют следующие пиктограммы: Граничный класс (boundary)
Управляющий класс (control)
Сущность (entity)
Классы анализа могут появляться также на диаграммах Взаимодействия в представлении Вариантов Использования. После определения всех классов анализа каждый из них может быть преобразован в класс проекта (design class). Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с другой системой. Нас пока не интересует, на каком языке он будет написан, мы уделяем внимание только его данным и поведению. Но преобразуя его в класс проекта, нам придется коснуться специфических для языка деталей. Допустим, что это будет класс Java. Тогда для реализации того, что мы заложили в класс анализа, нам могут понадобиться два класса Java. Это значит, что отсутствует строгое соответствие между классами того и другого типа. Классы проекта изображают на диаграммах Взаимодействия Логического представления системы. Классы анализа могут появляться также на диаграммах Взаимодействия в представлении Вариантов Использования. После определения всех классов анализа каждый из них может быть преобразован в класс проекта (design class). Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с другой системой. Нас пока не интересует, на каком языке он будет написан, мы уделяем внимание только его данным и поведению. Но преобразуя его в класс проекта, нам придется коснуться специфических для языка деталей. Допустим, что это будет класс Java. Тогда для реализации того, что мы заложили в класс анализа, нам могут понадобиться два класса Java. Это значит, что отсутствует строгое соответствие между классами того и другого типа. Классы проекта изображают на диаграммах Взаимодействия Логического представления системы. В этом представлении основное внимание уделяется логической структуре системы. Мы изучаем данные и поведение системы, определяем ее составные части и исследуем взаимодействие между ними. Одной из ключевых особенностей здесь является возможность повторного использования (reuse). Тщательно соотнося данные и поведение классов, группируя классы вместе и исследуя взаимодействие между классами и пакетами, можно определить, какие из них допускают повторное использование. Завершая новые и новые проекты, вы будете постепенно увеличивать вашу библиотеку повторно используемых классов и пакетов. В результате выполнение будущих проектов будет все более и более становиться процессом сборки целого из имеющихся у вас составных частей, а не разработки "с чистого листа". Почти все участники команды должны изучить Логическое представление системы, однако более всего оно полезно для разработчиков и архитекторов. Взглянув на классы и их диаграммы, аналитики смогут убедиться, что все бизнес-требования будут реализованы в коде. Изучая классы, пакеты и диаграммы Классов, специалисты по контролю качества поймут, из каких элементов состоит система и какие нуждаются в тестировании, а с помощью диаграмм Состояний увидят, как должны вести себя конкретные классы. Менеджер проекта из тех же элементов представления сможет уяснить, хорошо ли структурирована система, а также получить оценку степени ее сложности. Однако больше всего этим представлением пользуются разработчики и архитекторы. Первые выясняют, какие классы надо создавать, а также какие данные и поведение должен иметь каждый класс. Для вторых важнее всего структура системы в целом. Их задача — добиться того, чтобы архитектура системы была стабильна, но в то же время гибка настолько, чтобы адаптироваться к изменениям в требованиях. Другая задача — рассмотреть возможность повторного использования. Определив классы системы и нанеся их на диаграммы, можно приступить к работе с представлением Компонентов, имеющим дело с физической структурой системы.
Популярное: Генезис конфликтологии как науки в древней Греции: Для уяснения предыстории конфликтологии существенное значение имеет обращение к античной... Как вы ведете себя при стрессе?: Вы можете самостоятельно управлять стрессом! Каждый из нас имеет право и возможность уменьшить его воздействие на нас... Как распознать напряжение: Говоря о мышечном напряжении, мы в первую очередь имеем в виду мускулы, прикрепленные к костям ... ©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (789)
|
Почему 1285321 студент выбрали МегаОбучалку... Система поиска информации Мобильная версия сайта Удобная навигация Нет шокирующей рекламы |