Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Логическое представление




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

Логическое представление содержит [82]:

- Классы.

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

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

- Диаграммы состояний.

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

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

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

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

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

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

 




Поделиться с друзьями:


Дата добавления: 2014-12-27; Просмотров: 815; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.012 сек.