11675

Створення діаграми класів

Лабораторная работа

Информатика, кибернетика и программирование

Тема: Створення діаграми класів. Мета роботи: отримати навички побудови діаграм класів створення пакетів і угруповання класів у пакети. Завдання: створити діаграму класів. Для одного зі сценаріїв діаграми прецедентів створеної в попередній лабораторній робот...

Украинкский

2013-04-10

65.38 KB

24 чел.

Тема: Створення діаграми класів.

Мета роботи: отримати навички побудови діаграм класів, створення пакетів і угруповання класів у пакети.

Завдання:

  1.  створити діаграму класів. Для одного зі сценаріїв діаграми прецедентів, створеної в попередній лабораторній роботі. Для кожного класу необхідно задати атрибути та операції. Кожен клас повинен бути детально задокументовано - необхідно задати текстовий опис самого класу, опису його атрибутів і операцій;
  2.  створити пакети для угруповання класів, створених в пункті 1;
  3.  згрупувати класи з пункту 1 в пакети;
  4.  для кожного пакета створити свою діаграму класів.
  5.  розробити головну діаграму класів.

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

Зміст звіту:

  1.  створені діаграми класів (для діаграми класів з пункту 2 завдання повинен бути вказаний сценарій, для якого ця діаграма побудована);
  2.  короткий опис кожного створеного класу і відносин між класами.

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

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

Згідно Мартіну Фаулеру існують три різні точки зору на побудову діаграм класів або будь-який інший моделі:

  1.  концептуальна точка зору - діаграми класів служать для представлення понять досліджуваної предметної області. Ці поняття будуть відповідати реалізують їх класам, але пряме відповідність може бути відсутнім. Концептуальна модель може мати слабке відношення або взагалі не мати ніякого відношення до реалізує її програмному забезпеченню, тому її можна розглядати без прив'язки до якогось мови програмування;
  2.  точка зору специфікації - розглядається програмна система, при цьому розглядається лише її інтерфейси, але не реалізація;
  3.  точка зору реалізації - класи діаграми відповідають реальним класам програмної системи.

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

1. Створення діаграми класів для сценарію "Додати нове замовлення" прецеденту "Робота із замовленням"

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

Створимо в Логічному поданні браузера нову діаграму класів і назвемо її "Add New Order". В поле документації запишемо для неї наступний текст: "Діаграма класів для сценарію" Додати нове замовлення "прецеденту" Робота із замовленням "".

Заповнення діаграми почнемо з визначення класів-сутностей. Розглянутий сценарій складається з:

  1.  самого замовлення;
  2.  клієнта, який робить замовлення;
  3.  комплектуючих виробів, які входять до замовлення.

Створимо класи-сутності Order (Замовлення), Client (Клієнт) і ComponentPart (комплектуючий виріб). Оскільки в одне замовлення може входити багато різних комплектуючих виробів, і одне комплектуючий виріб може входити в багато замовлень, то введемо ще один клас-сутність OrderItem (Склад замовлення).

Додамо відносини між класами:

  1.  клас клієнта і замовлення - відношення асоціації, оскільки дані два класи просто пов'язані один з одним і ніякі інші типи зв'язків тут застосувати не можна. Один клієнт може зробити кілька замовлень, кожне замовлення надходить тільки від одного клієнта, тому кратність зв'язку з боку класу клієнта - 1, з боку замовлення - 1 .. N;
  2.  клас порядку і OrderItem - відношення композиції, оскільки рядок замовлення є частиною замовлення, і без нього існувати не може. В одне замовлення може входити кілька рядків замовлення, рядок замовлення відноситься тільки до одного замовлення, тому кратність зв'язку з боку замовлення - 1, з боку OrderItem - 1 .. N;
  3.  клас OrderItem і ComponentPart - відношення агрегації, оскільки комплектуючі вироби є частинами рядка замовлення, а й ті, й інші, явлю самостійними класами. Одне комплектуючий виріб може входити у багато рядків замовлення, в один рядок замовлення входить тільки одне комплектуючий виріб, тому кратність зв'язку з боку ComponentPart - 1, з боку OrderItem - 1 .. N.

Додамо тепер на діаграму граничні та керуючі класи. Розглянутий сценарій - це тільки одна з дій, які забезпечує прецедент "Робота із замовленням". Прецедент також дозволяє переглянути, відредагувати або видалити замовлення. Це означає, що необхідно передбачити механізм, який дозволяє вибирати необхідну дію. Створимо для цього граничний клас OrderOptions (Параметри роботи із замовленням) з коментарем "Клас, що забезпечує механізм роботи із замовленнями". Також створимо граничний клас AddNewOrder (Додавання нового замовлення), який буде служити для додавання нових замовлень (коментар - "Клас служить для додавання нових замовлень" Відношення між цими класами -. Агрегація, оскільки в даному випадку клас AddNewOrder розглядається як частина класу OrderOptions, частинами якого також будуть класи для перегляду, редагування і видалення замовлень. Кратність зв'язку 1 до 1, оскільки до складу класу OrderOptions входить тільки один клас AddNewOrder.

Перейдемо тепер до керуючих класам. Додамо керуючий клас OrderManager (Менеджер по роботі з замовленнями) з коментарем "Керуючий клас для обробки потоку подій прецеденту" Робота з замовленнями "", який буде забезпечувати обробку потоку подій для розглянутого прецеденту. Даний клас буде пов'язаний з класами AddNewOrder та Order. Відношення між класами AddNewOrder і OrderManager - односпрямована асоціація з кратністю зв'язку 1 до 1, оскільки один примірник класу AddNewOrder взаємодіє тільки з одним екземпляром класу OrderManager. Відношення між класами і OrderManager замовлення - односпрямована асоціація з кратністю зв'язку 1 до 1 .. п, оскільки один клас OrderManager може взаємодіяти з кількома класами замовлення.

2. Створення пакетів

Пакети призначені для групування елементів у групи за певними критеріями. У простому випадку класи можна групувати по їх стереотипам. Створимо три пакети: Entities (класи-сутності), Boundaries (граничні класи) та Control (керуючі класи). Для цього необхідно натиснути правою кнопкою миші на Логічному поданні браузера (Logical View), в контекстному меню вибрати пункт New> Package (Створити> Пакет), і ввести ім'я пакета.

В поле документації (документації) для кожного пакета задамо коментар:

  1.  для пакета Entities коментар: пакет містить класи-сутності;
  2.  для пакета Boundary коментар: пакет містить граничні класи;
  3.  для пакета Control коментар: пакет містить керуючі класи.

3. Угрупування класів у пакети

Угрупування класів у пакети здійснюється шляхом перетягування в Логіческоі поданні Брауер відповідного класу до відповідного пакет. Групувати створені класи будемо наступним чином:

  1.  класи клієнта, замовлення, OrderItem і ComponentPart перенесемо в пакет Entities;
  2.  класи OrderOptions і AddNewOrder перенесемо в пакет Boundary;

клас OrderManager перенесемо в пакет Control.

4. Додавання діаграми класів для кожного пакета

Для додавання діаграми до пакету слід натиснути правою кнопкою миші по пакету, в контекстному меню вибрати пункт New> Class Diagram (Створити> Діаграма Класів), ввести ім'я класу Main (Головна), далі відкрити діаграму, двічі клацнувши по ній, і перенести на неї потрібні класи. Відносини між класами, що належать одному пакету, будуть перенесені автоматично.

Висновок: виконавши лабораторну роботу, я отримав навички побудови діаграм класів, створення пакетів і угруповання класів у пакети.


 

А также другие работы, которые могут Вас заинтересовать

71600. ОСОБЕННОСТИ ПОРЯДКА ВЗАИМОДЕЙСТВИЯ ФИНАНСОВЫХ ОРГАНОВ РЕГУЛИРОВАНИЯ РЫНКА ЦЕННЫХ БУМАГ С ОТДЕЛЬНЫМИ СУБЪЕКТАМИ ФИНАНСОВОГО ПРАВА В ПРОЦЕССЕ ФИНАНСОВОЙ ДЕЯТЕЛЬНОСТИ 79.5 KB
  В процессе государственной финансовой деятельности при осуществлении полномочий по регулированию рынка ценных бумаг федеральные финансовые органы такого регулирования в частности Федеральная служба по финансовым рынкам далее ФСФР взаимодействует с другими субъектами...
71601. ОСОБЕННОСТИ НОРМАТИВНО-ПРАВОВОГО РЕГУЛИРОВАНИЯ ПОРЯДКА ФУНКЦИОНИРОВАНИЯ ФЕДЕРАЛЬНОГО ФОНДА ОБЯЗАТЕЛЬНОГО МЕДИЦИНСКОГО СТРАХОВАНИЯ 70 KB
  Особенности нормативно-правового регулирования порядка функционирования Федерального фонда обязательного медицинского страхования установлены положениями Закона РФ от 28 июня 1991 г. № 729 Вопросы Федерального Фонда обязательного медицинского страхования...
71602. РОЛЬ КОНСТИТУЦИИ РОССИЙСКОЙ ФЕДЕРАЦИИ В ПРОЦЕССЕ ФОРМИРОВАНИЯ И РЕАЛИЗАЦИИ ЗАКОНОДАТЕЛЬСТВА, РЕГЛАМЕНТИРУЮЩЕГО ПРЕДПРИНИМАТЕЛЬСКУЮ ДЕЯТЕЛЬНОСТЬ 186 KB
  Согласно статье 2 Конституции России человек его права и свободы являются высшей ценностью. С конституционным провозглашением прав и свобод человека как высшей ценности государство признало требования демократического международного сообщества выраженные в таких...
71603. ОБЪЕКТ И СУБЪЕКТ В СОДЕРЖАНИИ ПРАВООТНОШЕНИЯ ПО УСЫНОВЛЕНИЮ РЕБЕНКА 114.5 KB
  Как известно участниками правоотношений являются субъекты права под которыми понимаются лица и их объединения выступающие в качестве носителей предусмотренных законом прав и обязанностей. Таким образом рассматривая институт усыновления отметим что субъектом является...
71604. ПУТИ СОКРАЩЕНИЯ ФОРМ ЛИЦЕНЗИРУЕМОЙ ДЕЯТЕЛЬНОСТИ 154 KB
  Уменьшение лицензируемых видов деятельности следует связывать с пониманием ограничительной роли лицензионной системы и выявлением в ходе правоприменительной деятельности отсутствия необходимости в столь жестком регулятивном механизме в отношении большинства видов деятельности.
71605. ЮРИДИКО-ТЕХНИЧЕСКИЕ АСПЕКТЫ ПРЕЗУМПЦИИ ВИНОВНОСТИ В ГРАЖДАНСКОМ ПРАВЕ 67.5 KB
  Проблемам юридической техники в отечественной правовой науке традиционно не уделялось должного внимания а проводившиеся исследования почти исключали сферу частного права поскольку его существование не признавалось официальной политико-правовой доктриной.
71606. ИЗМЕНЕНИЕ ФУНКЦИЙ РОССИЙСКОЙ ТАМОЖНИ В УСЛОВИЯХ РАЗВИТИЯ РЫНОЧНОЙ ЭКОНОМИКИ КАК ОДНА ИЗ ЦЕЛЕЙ АДМИНИСТРАТИВНОЙ РЕФОРМЫ В РОССИИ 77 KB
  Указом Президента России от 23 июля 2003 г. Понятие функция федерального органа исполнительной власти означает нормативно установленный вид властной деятельности органа государства постоянно осуществляемый им в масштабах Российской Федерации.
71607. ОРГАНЫ МЕСТНОГО САМОУПРАВЛЕНИЯ КАК ОРГАНЫ ОПЕКИ И ПОПЕЧИТЕЛЬСТВА: ПРОБЛЕМЫ РЕГИОНАЛЬНОГО ЗАКОНОДАТЕЛЬСТВА 81 KB
  Еще в период существования советского государства законодатель наделил местные администрации в РСФСР полномочиями на осуществление функций опеки и попечительства установив их компетенцию в Положении об органах опеки и попечительства в РСФСР от 30 апреля 1986 г.
71608. ПРОЕКТИРОВАНИЕ ТЯГОВОЙ ПОДСТАНЦИИ ПЕРЕМЕННОГО ТОКА 1.4 MB
  Электрическая тяга является основным потребителем электроэнергии на железнодорожном транспорте. Удовлетворение потребностей железнодорожного транспорта в электроэнергии осуществляется в основном путем присоединения железнодорожных установок к районным сетям энергосистемы.