Проектування програмного продукту із застосуванням систем візуального моделювання

Рисунок 4.28 - Моделювання простих кооперацій

В описану систему, звичайно, входить значно більше класів, але увага на діаграмі загострюється тільки на таких абстракціях, які безпосередньо беруть участь в русі робота. Деякі зазначені класи можуть бути присутні і на інших діаграмах. Наприклад, хоча тут це не показано, «Агент Траєкторії» співпрацює принаймні ще з двома класами («Оточення» і «Агент Цілі») в механізмі більш високого рівня, керуючому поведінкою робота при наявності конфліктуючих цілей. «Датчик Сутичок» і «Привід», а також їх частини співпрацюють з іншим, не показаним на діаграмі класом «Агент Відмови» в механізмі, що відповідає за постійний контроль апаратних збоїв. Описуючи кожну з цих кооперацій в окремих діаграмах, ви зможете створити просте для сприйняття уявлення системи з різних точок зору.

Моделювання логічної схеми бази даних

Багато модельований системи містять стійкі об'єкти, тобто такі, які можна зберігати в базі даних і згодом отримувати при необхідності.

Для цього найчастіше використовують реляційні, об'єктно-орієнтовані або гібридні об'єктно-реляційні бази даних. UML дозволяє моделювати логічні схеми баз даних, так само як і самі фізичні бази.

Діаграми класів UML включають в себе, як окремий випадок, діаграми «сутність-зв'язок» (ER діаграми), які часто використовуються для логічного проектування баз даних. Але якщо в класичних ER діаграмах увага зосереджена тільки на даних, діаграми класів - це крок вперед: вони дозволяють моделювати також і поведінку. У реальному базі даних подібні логічні операції зазвичай трансформуються в тригери або збережені процедури.

Моделювання схеми проводиться таким чином:

1. ідентифікуйте класи вашої моделі, стан яких повинно зберігатися і після завершення роботи створив їх застосування;

2. створіть містить ці класи діаграму класів і характеризує їх як стійкі за допомогою стандартного поміченого значення persistent (стійкий). Для роботи зі специфічними деталями бази даних ви можете визначити і свої власні помічені значення;

3. розкрийте структурні особливості класів. У загальному випадку це означає, що треба детально специфікувати їх атрибути і звернути особливу увагу на асоціації і їх кратності;

4. пошукайте типові структурні зразки, що ускладнюють проектування фізичної бази даних, наприклад циклічні асоціації, асоціації «один до одного» і n-арні асоціації. При необхідності створіть проміжні абстракції для спрощення логічної структури;

5. розгляньте поведінку цих класів, розкриваючи операції, важливі для доступу до даних і підтримки їх цілісності. У загальному випадку для кращого поділу обов'язків бізнес-правила, що відповідають за маніпуляції наборами об'єктів, повинні бути інкапсульовані в шарі, що знаходиться над цими стійкими класами;

6. намагайтеся використовувати в своїй роботі інструментальні засоби, що дозволяють перетворити логічний проект у фізичний

На рисунку 4.29 показана сукупність класів, взятих з інформаційної системи вузу. Цей малюнок є розширенням наведеної раніше діаграми класів і містить достатню кількість деталей для конструювання фізичної бази даних. У лівій нижній частині діаграми розташовані класи «Студент», «Курс» та «Викладач». Між класами «Студент» і «Курс» є асоціація, що показує, що студенти можуть відвідувати курси. Більше того, кожен студент може відвідувати будь-яку кількість курсів і на кожен курс може записатися будь-яке число студентів.

Рисунок 4.29 - Моделювання схеми БД

Всі шість класів на діаграмі позначені як стійкі (persistent), тобто їх примірники повинні міститися в базі даних або якомусь іншому сховищі.

Наведено також атрибути всіх шести класів. Зверніть увагу, що всі атрибути є примітивними типами. Моделюючи схему, відносини з непрімітівнимі типами найкраще представляти за допомогою явного агрегування, а не за допомогою атрибутів.

Два класу («Вуз» і «Факультет») містять кілька операцій, що дозволяють маніпулювати їх частинами. Ці операції включені через їх важливості для підтримки цілісності даних (наприклад, додавання або видалення «Факультету» зачіпає цілий ряд інших об'єктів).

Існує багато інших операцій, які варто було б розглянути при проектуванні цих та інших класів, наприклад, запит про необхідні попередніх знаннях перед зарахуванням студента на курс. Але це, скоріше, бізнес-правила, а не операції з підтримання цілісності даних, тому краще розташовувати їх на більш високому рівні абстракції.

Моделювання словника системи

За допомогою класів зазвичай моделюють абстракції, витягнуті з розв'язуваної задачі або технології, що застосовується для її вирішення. Такі абстракції є складовою частиною словника вашої системи, тобто представляють сутності, важливі для користувачів і розробників.

Для користувачів не складає труднощів ідентифікувати велику частину абстракцій, оскільки вони створені на основі тих сутностей, які вже використовувалися для опису системи. Для розробників же абстракції є зазвичай просто елементами технології, яка була задіяна при вирішенні задачі.

Моделювання словника системи включає в себе наступні етапи:

1. визначте, які елементи користувачі та розробники застосовують для опису задачі або її розв'язання. Для відшукання правильних абстракцій використовуйте аналіз прецедентів;

2. виявите для кожної абстракції відповідне їй безліч обов'язків. Прослідкуйте, щоб кожен клас був чітко визначений, а розподіл обов'язків між ними добре збалансовано;

3. розробіть атрибути та операції, необхідні для виконання класами своїх обов'язків.

На рисунку 4.30 показаний набір класів для системи роздрібної торгівлі: «Customer» (Клієнт), «Order» (Замовлення) і «Product» (Товар). Представлено кілька співвіднесених з ними абстракцій, взятих із словника проблемної області: «Shipment» (Відвантаження), «Invoice» (Накладна) і «Warehouse» (Склад). Одна абстракція, а саме «Transaction» (Транзакція), що застосовується до замовлень і відвантажень, пов'язана з технологією виконання завдання.

Рисунок 4.30 - Моделювання словника системи

У міру того як ви будете будувати все більш складні моделі, виявиться, що багато класи природним чином поєднуються в концептуально і семантично споріднені групи. У мові UML для моделювання таких груп класів використовуються пакети. Як правило, моделі не бувають статичними. Навпаки, більшість абстракцій зі словника системи динамічно взаємодіє один з одним. В UML існує кілька способів моделювання такого динамічного поведінки, які будуть розглянуті пізніше.

Приклад виконання лабораторної роботи.

Після запуску програми VP-UML, для початку побудови діаграми класів, необхідно обрати діаграму class diagram (рисунок 4.31).

Рисунок 4.31 - Діаграма класів.

На панелі інструментів для даної діаграми присутні всі необхідні умовні позначення об'єктів діаграми (таблиця 4.3).

Таблиця 4.3 - Умовні позначення на спеціальній панелі інструментів



обудова діаграми класів починається з нанесення на діаграму умовних позначень класів системи (рисунок 4.32).

Рисунок 4.32 - Нанесення класів на діаграму

Для кожного створеного класу визначаються необхідні атрибути і операції.

Новий атрибут класу створюється послідовністю дій:

1. в браузері виділяється клас;

2. натисканням правої кнопки миші викликається контекстне меню;

3. вибирається пункт меню Attribute.

Нова операція класу створюється послідовністю дій:

1. в браузері виділяється клас;

2. натисканням правої кнопки миші викликається контекстне меню;

3. вибирається пункт меню Operation.

При створенні операцій і атрибутів необхідно враховувати:

1. видимість атрибута;

2. тип операції;

3. тип атрибута.

Дані параметри настроюються в специфікації необхідного параметра кожного класу (рисунок 4.33).

Рисунок 4.33 - Параметри атрибута

Після створення всіх необхідних атрибутів і операцій у класів діаграма виглядає, як показано на рисунку 4.34.



Рисунок 4.34 - Класи з створеними атрибутами і операціями

Наступним кроком для створення діаграми є визначення зв'язків між класами та їх множинності. Зв'язок створюється за допомогою кнопки «Unidirectional Association» на панелі інструментів.

Для визначення множинності виконується наступна послідовність дій:

1. на діаграмі вибирається клас, з боку якого виставляється множинність;

2. правою кнопкою миші викликається контекстне меню;

3. в пункті multiplicity вибирається потрібне значення множинності (рисунок 4.35).

Рисунок 4.35 - Установка множинності

Діаграма зі зв'язками та відповідними типами множинності показана на рисунку 4.36.

Рисунок 4.36 - Зв'язки з означеної множинністю

Діаграма після поділу класів на категорії показана на рисунку 4.37. Належність класу до потрібної категорії визначається настройками в специфікації класу (рисунок 4.37).

Рисунок 4.37 - Вибір категорії класу



Рисунок 4.38 - Діаграма класів

Готова діаграма класів для варіанту використання «Зняти гроші» показана на рисунку 4.38. На цій діаграмі класів показані зв'язки між класами, що реалізують варіант використання «Зняти гроші». У цьому процесі задіяні чотири класи: Card Reader (пристрій для читання карток), Account (рахунок), ATM Screen (екран АТМ) та Cash Dispenser (касовий апарат). Кожен клас на діаграмі виглядає у вигляді спеціального об'єкта, розділеного на три частини. У першій міститься ім'я класу, у другій - його атрибути. В останній частині містяться операції класу, що відображають його поведінку (дії, що виконуються класом).

Зв'язують класи лінії відображають взаємодію між класами. Так, клас Account пов'язаний з класом ATM Screen (екран АТМ), тому що вони безпосередньо повідомляються і взаємодіють один з одним. Клас Card Reader (пристрій для читання карток) не пов'язаний з класом Cash Dispenser (касовий апарат), оскільки вони не повідомляються один з одним безпосередньо.

4.5.3 Лабораторна робота № 3 «Діаграма послідовності»

Мета роботи: освоїти прийоми розробки і побудови діаграми послідовності.

Зміст роботи:

1. створення і підготовка бланка діаграми;

2. виділення з виданого завдання прецеденту використання;

3. створення на діаграмі об'єктів, задіяних у прецеденті використання;

4. створення повідомлень між об'єктами;

5. збереження побудованої діаграми.

Теоретична частина

Діаграмою послідовностей (Sequence diagram) називається діаграма взаємодій, що акцентує увагу на тимчасовій впорядкованості повідомлень. Графічно така діаграма являє собою таблицю, об'єкти в якій розташовуються уздовж осі X, а повідомлення в порядку зростання часу - уздовж осі Y.

На діаграмах послідовностей увага акцентується, перш за все, на тимчасовій впорядкованості повідомлень. На рисунку 4.39 показано, що для створення такої діаграми треба, перш за все, розташувати об'єкти, які беруть участь у взаємодії, у верхній її частині уздовж осі X. Зазвичай ініціює взаємодію об'єкт розміщують ліворуч, а інші - праворуч (тим далі, чим більш підлеглим є об'єкт). Потім уздовж осі Y розміщуються повідомлення, які об'єкти посилають і приймають, причому більш пізні виявляються нижче. Це дає читачеві наочну картину, що дозволяє зрозуміти розвиток потоку керування в часі.

Діаграми послідовностей характеризуються двома особливостями, що відрізняють їх від діаграм комунікацій.

По-перше, на них показана лінія життя об'єкта. Це вертикальна пунктирна лінія, що відображає існування об'єкта в часі. Велика частина об'єктів, представлених на діаграмі взаємодій, існує протягом усього взаємодії, тому їх зображують у верхній частині діаграми, а їх лінії життя промальовані зверху до низу. Об'єкти можуть створюватися і під час взаємодій. Лінії життя таких об'єктів починаються з отримання повідомлення зі стереотипом create. Об'єкти можуть також знищуватися під час взаємодій; в такому разі їх лінії життя закінчуються одержанням повідомлення зі стереотипом destroy, а в якості візуального образу використовується велика буква X, що позначає кінець життя об'єкта (обставини життєвого циклу об'єкта можна вказувати за допомогою обмежень new, destroyed і transient ).

Рисунок 4.39 - Діаграма послідовностей

Друга особливість цих діаграм - фокус управління. Він зображується у вигляді витягнутого прямокутника, що показує проміжок часу, протягом якого об'єкт виконує будь-яку дію, безпосередньо або за допомогою підлеглої процедури. Верхня грань прямокутника вирівнюється з тимчасової осі з моментом початку дії, нижня - з моментом його завершення (і може бути позначена повідомленням про повернення). Вкладеність фокуса управління, викликану рекурсією (тобто зверненням до власної операції) або зворотним викликом з боку іншого об'єкта, можна показати, розташувавши інший фокус управління трохи правіше свого батька (допускається вкладеність довільної глибини). Якщо місце розташування фокуса управління потрібно вказати з максимальною точністю, можна заштрихувати область прямокутника, відповідну часу, протягом якого метод дійсно працює і не передає управління іншому об'єкту.

Як правило, діаграма взаємодії охоплює поведінку об'єктів в рамках тільки одного варіанту використання. На такий діаграмі відображається ряд об'єктів, які обмінюються між собою повідомленнями. Повідомлення можуть бути наступними:

* повідомлення (message) - це засіб, за допомогою якого об'єкт-відправник запитує в об'єкта одержувача виконання однієї з його операцій;

* інформаційне (informative) повідомлення - це повідомлення, постачає об'єкт-одержувач деякою інформацією для поновлення його стану;

* повідомлення-запит (interrogative) - це повідомлення, що запитує видачу деякою інформацією про об'єкт-одержувача;

* імперативне (imperative) повідомлення - це повідомлення, запитуюча в об'єкта-одержувача виконання деяких дій.

Розглянемо ще один приклад діаграми послідовності (рисунок 4.40).

Діаграма відображає потік подій, що відбуваються в рамках варіанту використання. На діаграмі послідовності об'єкт зображується у вигляді прямокутника, від якого вниз проведена пунктирна вертикальна лінія. Ця лінія називається лінією життя (lifeline) об'єкта. Вона являє собою фрагмент життєвого циклу об'єкта в процесі взаємодії.



Рисунок 4.40 - Діаграма послідовності для зняття клієнтом грошей з рахунку

Кожне повідомлення представляється у вигляді стрілки між лініями життя двох об'єктів. Повідомлення з'являються в тому порядку, як вони показані на сторінці зверху вниз. Кожне повідомлення позначається як мінімум ім'ям повідомлення; при бажанні можна додати також аргументи і деяку керуючу інформацію, і, крім того, можна показати само-делегування (self-delegation) - повідомлення, яке об'єкт посилає самому собі, при цьому стрілка повідомлення вказує на ту ж саму лінію життя.

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

Не всі об'єкти з'являються в потоці подій. Там, наприклад, може не бути форм для заповнення, але їх необхідно показати на діаграмі, щоб дозволити дійовій особі ввести нову інформацію в систему або переглянути її. У потоці подій, швидше за все, також не буде і керуючих об'єктів (control objects). Ці об'єкти керують послідовністю потоку у варіанті використання.

Приклад виконання лабораторної роботи.

Після запуску програми VP-UML, для початку побудови діаграми послідовності, необхідно розкрити в лівій частині робочого інтерфейсу під стандартною панеллю інструментів ієрархічну структуру і вибрати діаграму sequence diagram (рисунок 4.41).

Рисунок 4.41 - Бланк діаграми послідовності

На панелі інструментів для даної діаграми присутні всі необхідні умовні позначення об'єктів діаграми (таблиця 4.4).

Таблиця 4.4 - Кнопки спеціальної панелі інструментів діаграми послідовності

Для нанесення на діаграму нового об'єкта діаграми на панелі інструментів вибирається кнопка об'єкта діаграми. Після натискання необхідної кнопки, необхідно перемістити покажчик миші до тієї області, де буде розташовуватися новий об'єкт діаграми, і натиснути ліву кнопку миші. Тепер необхідно ввести назву нового об'єкта.

Після того, як створені всі необхідні об'єкти, створюються сполучення між об'єктами (рисунок 4.42).

Рисунок 4.24 - Створення повідомлень між об'єктами діаграми

Після завершення всі необхідні дії, готова діаграма показана на рисунку 4.43.

Рисунок 4.43 - Створення діаграми послідовності

В якості завершального етапу розробки діаграми послідовності виконується вказівка стереотипів об'єктів (рисунок 4.44).

Рисунок 4.44 - Розстановка стереотипів об'єктів

4.5.4 Лабораторна робота № 4 «Діаграма комунікацій»

Мета роботи: освоїти прийоми розробки і побудови діаграми комунікацій.

Зміст роботи:

1. створення і підготовка бланка діаграми;

2. виділення з виданого завдання прецеденту використання;

3. нанесення на діаграму об'єктів, задіяних у прецеденті використання;

4. створення комунікацій між об'єктами;

5. додавання повідомлень на комунікації;

6. збереження побудованої діаграми.

Теоретична частина

Діаграмою комунікацій (Communication diagram) називається діаграма взаємодій, основна увага в якій приділяється структурної організації об'єктів, які приймають і відправляють повідомлення. Графічно така діаграма являє собою граф з вершин і ребер.

Діаграма комунікацій акцентує увагу на організації об'єктів, що приймають участь у взаємодії. Як показано на рисунку 4.45, для створення діаграми кооперації потрібно розташувати беруть участь у взаємодії об'єкти у вигляді вершин графа. Потім зв'язку, що з'єднують ці об'єкти, зображуються в вид дуг цього графа. Нарешті, зв'язку доповнюються повідомленнями, які об'єкти приймають і посилають. Це дає користувачеві ясне візуальне уявлення про потік управління в контексті структурної організації кооперуються об'єктів.

Рисунок 4.45 - Діаграма комунікацій

У діаграм комунікацій є дві властивості, які відрізняють їх від діаграм послідовностей. Перше - це шлях. Для опису зв'язку одного об'єкта з іншим до далекої кінцевий точці цьому зв'язку можна приєднати стереотип шляху (наприклад, local показує, що позначений об'єкт є локальним стосовно від правителю повідомлення).

Має сенс явно зображати шлях зв'язку тільки відносно шляхів типу local, parameter, global і self (але не associations).

Друга властивість - це порядковий номер повідомлення. Для позначення часовій послідовності перед повідомленням можна поставити номер (нумерація починається з одиниці), який повинен поступово зростати для кожного нового повідомлення (2, 3 і т.д.). Для позначення вкладеності використовується десяткова нотація Дьюї (1 - перше повідомлення; 1.1 - перше повідомлення, вкладене в повідомлення 1; 1.2-друге повідомлення, вкладене в повідомлення 1 і т.д.). Рівень вкладеності не обмежений. Для кожного зв'язку можна показати кілька повідомлень (ймовірно, що посилаються різними відправниками), і кожне з них повинно мати унікальний порядковий номер. Найчастіше вам доведеться моделювати нерозгалужені послідовні потоки управління. Однак можна моделювати і складніші потоки, які містять ітерації і розгалуження (для цього більш зручна діаграма діяльності). Ітерація являє собою повторювану послідовність повідомлень. Для її моделювання перед номером повідомлення в послідовності ставиться вираз ітерації, наприклад * [i: = 1 .. n] (або просто *, якщо треба позначити ітерацію без подальшої деталізації). Ітерація показує, що повідомлення (і всі вкладені в нього повідомлення) буде повторюватися у відповідності зі значенням заданого виразу.

Аналогічно умова являє собою повідомлення, виконання якого залежить від результатів обчислення деякого булевського вираження. Для моделювання умови перед порядковим номером повідомлення ставиться вираз, наприклад [х> 0]. У всіх альтернативних гілок буде один і той же порядковий номер, але умови на кожній гілці повинні бути задані так, щоб два з них не виконувалися одночасно (не перекривалися). UML не визначає ніякого особливого формату для виразів у квадратних дужках при описі ітерацій і розгалужень ; можна використовувати псевдокод або синтаксис-якого конкретного мови програмування.

Як правило, діаграма комунікацій охоплює поведінку об'єктів в рамках тільки одного варіанту використання. На такий діаграмі відображається ряд об'єктів і ті повідомлення, якими вони обмінюються між собою:

* Повідомлення (message) - це засіб, за допомогою якого об'єкт-відправник запитує в об'єкта одержувача виконання однієї з його операцій.

* Інформаційне (informative) повідомлення - це повідомлення, постачає об'єкт-одержувач деякою інформацією для поновлення його стану.

* Повідомлення-запит (interrogative) - це повідомлення, що запитує видачу деякою інформацією про об'єкт-одержувача.

* Імперативне (imperative) повідомлення - це повідомлення, запитуюча в об'єкта-одержувача виконання деяких дій.

У версії мови UML 1.x діаграми комунікації (Communication diagram) носили назву діаграм кооперації (collaboration diagram). Ще один приклад діаграми комунікацій представлений на рисунку 4.46.

Рисунок 4.46 - Діаграма комунікації, що описує процес зняття клієнтом грошей зі свого рахунку

Приклад виконання лабораторної роботи

Після запуску програми VP-UML, для початку побудови діаграми комунікації, необхідно обрати діаграму Communication diagram (рисунок 4.47).



Рисунок 4.47 - Бланк діаграми комунікації

На панелі інструментів для даної діаграми присутні всі необхідні умовні позначення об'єктів діаграми (Таблиця 4.5).

Таблиця 4.5 - Інструменти діаграми комунікації

Як приклад розглянемо побудову діаграми, показаної на рисунку 4.37.

Для нанесення на діаграму нового об'єкта діаграми на панелі інструментів вибирається кнопка із зображенням прямокутника (Object). Після натискання необхідної кнопки, необхідно перемістити покажчик миші до тієї області, де буде розташовуватися новий об'єкт діаграми, і натиснути ліву кнопку миші. Тепер необхідно ввести назву нового об'єкта.

Після того, як створені всі необхідні об'єкти, створюються сполучення між об'єктами (рисунок 4.48).

Рисунок 4.48 - Створення діаграми комунікацій

Для того, щоб вказати напрямок і назва повідомлення необхідно виконати наступні дії:

1. виділити потрібне повідомлення;

2. викликати спливаюче меню (натисканням правої кнопки миші);

3. в меню вибрати необхідний тип повідомлення;

4. натиснувши праву кнопку миші, вибрати необхідний напрям (рисунок 4.49).

Рисунок 4.49 - Вибір напрямку повідомлення

Після вибору напрямку повідомлення, необхідно ввести назву (рисунок 4.50).

Рисунок 4.50 - Введення назви повідомлення

Після завершення всі необхідних дій, отримана діаграма комунікацій показана на рисунку 4.51.

Рисунок 4.51 - Діаграма комунікацій

ВИСНОВОК

В даній дипломній роботі «Проектування програмного продукту із застосуванням систем візуального моделювання» виконано наступне:

Розглянуто сучасні технології об'єктно-орієнтованого аналізу та проектування інформаційних систем

Розглянуто методологію об'єктно-орієнтованого програмування

Розглянуто методології об'єктно-орієнтованого аналізу і проектування

Розглянуто особливості візуального моделювання програмного забезпечення:

Аналіз та проектування

Візуальне моделювання. Історія мови UML

Структура мови UML

Візуальний опис функціональної моделі засобами UML

Структура системи та її опис засобами UML

У практичній частині розглянуто:

· Використання UML в проектуванні ПЗ

· Характеристику CASE-засобів Visual Paradigm

· Інтерфейс програми VP-UML

· Принцип роботи в VP-UML

В лабораторному практикумі розроблені методичні рекомендації щодо виконання лабораторних робіт

Лабораторна робота № 1 «Діаграма прецедентів»

Лабораторна робота № 2 «Діаграми класів»

Лабораторна робота № 3 «Діаграма послідовності»

Лабораторна робота № 4 «Діаграма комунікацій»

ЛІТЕРАТУРА

1. К.Чернецки, У.Айзенекер. Порождающее программирование. Методы, инструменты, применение. - Издательский дом «Питер». - Москва - Санкт-Петербург … Харьков, Минск. - 2005. -730 с.

2. Орфали Р., Харки Д. Эдвардс Дж. Основы CORBA. Издательство “Малип”, М.: 1999. - 317 с.

3. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI. - М.: Мир, 2002. - 510 с.

4. Рамбо Дж., Джекобсон А., Буч Г. UML: специальный справочник. - СПб.: Питер. - 2002. - 656 с.

5. Кендалл Скотт. Унифицированный процесс. Основные концепции. - Москва - Санкт-Петербург - Киев. -2002. - 157 с.

6. Нейбург Э.Дж., Максимчук Р.А. Проектирование баз данных с помощью UML. - М.: Вильямс, 2002. - 288 с.

7. Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов - М.: ДМК Пресс, 2002. - 160 с.

8. Санблэд С., Санблэд С. Разработка масштабируемых приложений для Microsoft Windows. Мастер-класс - М.: ИТД Русская редакция, 2002. - 416 с.

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

Размещено на Allbest.ru