Component diagram (диаграммы компонентов)

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей. Диаграмма компонентов отображена на рисунку 7.8.

Рисунок 7.8 - Диаграмма компонентов

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

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

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

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

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

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

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

диаграмма прецедентов,

диаграмма классов,

диаграмма объектов,

диаграмма последовательностей,

диаграмма кооперации,

диаграмма состояний,

диаграмма активности,

диаграмма развертывания.

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

И напоследок еще несколько советов относительно использования UML.

Хорошее и полезное упражнение - строить модели классов и отношений между ними для уже написанного вами кода на С++ или Java.

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

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

Обратите особое внимание на средства UML для моделирования компонентов, параллельности, распределенности, паттернов проектирования. Большинство из этих вопросов мы рассмотрим далее.

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

Кроме прочего, важным моментом здесь является выбор пакета UML моделирования (CASE-средства), что тоже может повлиять на ваш индивидуальный стиль проектирования. Более подробно мы поговорим об этом в одной из последующих лекций, пока же отметим, что все диаграммы, виденные вами в этой лекции, построены с помощью TAU G2 от Telelogic [12].

КОНТРОЛЬНЫЕ ВОПРОСЫ:

1. Что такое Rational Rose?

2. Для чего предназначается Rational Rose?

3. Что позволяет проектировать среда Rational Rose?

4. Для чего используются диаграммы классов?

5. Для чего используются диаграммы компонентов?

6. Что такое модель Rose?

7. Что содержит модель Rose?

8. Какие достоинства Rational Rose?

9. Что такое состояние (state)?

10. Что такое алгоритм?

11. Перечислите типы диаграмм доступных в Rational Rose.

12. Дайте характеристику Use case diagram (диаграммы прецедентов).

13. Дайте характеристику Deployment diagram (диаграммы топологии).

14. Дайте характеристику Statechart diagram (диаграммы состояний).

15. Дайте характеристику Activity diagram (диаграммы активности).

16. Дайте характеристику Interaction diagram (диаграммы взаимодействия).

17. Дайте характеристику Sequence diagram (диаграммы последовательностей действий).

18. Дайте характеристику Collaboration diagram (диаграммы сотрудничества).

19. Дайте характеристику Collaboration diagram (диаграммы сотрудничества).

20. Дайте характеристику Class diagram (диаграммы классов).

21. В каких целях используется диаграмма классов?

22. Какие, согласно Мартину Фаулеру, существуют три различные точки зрения на построение диаграмм классов?

23. Дайте характеристику каждой из точек зрения.

24. Дайте характеристику Component diagram (диаграммы компонент).

25. В каких случаях целесообразно применять диаграммы состояний?

26. Какое отличие диаграмм состояний от других диаграмм?

27. Какие обозначение используются в диаграмме состояний?

28. Дайте объяснение обозначениям в диаграмме состояний.

29. Почему нужно строить разные диаграммы при моделировании системы?

30. Какие диаграммы соответствуют статическому представлению о системе?

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

СПИСОК ЛИТЕРАТУРЫ:

1. Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2;

2. Steve McConnell. Rapid Development;

3. Кобёрн А. Современные методы описания функциональных требований к системам. — М.: Лори, 2002. — ISBN 0-201-70225-8, ISBN 5-85582-152-8;

4. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. — М.: Вильямс, 2002. — ISBN ISBN 5-8459-0275-4;

5. Лешек А. Мацяшек. Анализ требований и проектирование систем. – Вильямс, 2002. 432стр.;

6. Трофимов С.А. CASE-технологии: практическая работа в Rational Rose. Изд. 2-е. – М.: Бином-Пресс, 2002 г. - 288 с.: ил.;

7. Фаулер М., Скотт К. UML. Оснвы. – Пер. с англ. – СПб:Символ-Плюс,2002. – 192с.,ил.;

8. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. — СПб.:Питер, 2002. — 496 с: ил.;

9. Г. Буч, Д. Рамбо, А. Джекобсон, Язык UML. Руководство пользователя. Перевод с английского.;

10. http://ru.wikipedia.org;

11. www.all-eBooks.com;

12. www.intuit.ru/department/se/intuml/2/5.html