Главная Партнеры Контакты  
Юридическая компания — «Основной закон», консультации и помощь в возвращении депозитов, защита по кредиту

ЮК
"ОСНОВНОЙ ЗАКОН"  

г. Киев, бул. Пушкина, 2а                
тел.: (044) 334-99-77                               
         (095) 407-407-3
         (096) 703-11-82

график работы: пн.- пт. с 9:00 до 18:00
          
                           

 












Рассматривается вопрос о предоставление нотариусам права выдачи извлечения из Реестра прав на недвижимое имущество.
Министерством юстиции был разработан проект Закона «О внесении изменений в некоторые Законы Украины относительно предоставления информации о государст...


Держреєстрація речових прав на нерухоме майно та їх обтяжень у 2014 році буде здійснюватись за новою - удосконаленою та спрощеною - процедурою.
Постанова Кабінету Міністрів "Про затвердження порядку державної реєстрації прав на нерухоме майно та їх обтяжень і Порядку надання інформації з Держа...




Система Orphus


Діаграма компонентів UML | Планерка: онлайн-школа креативності

  1. Діаграма компонентів UML Для чого використовується метод проектування
  2. План дій
  3. Як застосовувати метод проектування
  4. приклад використання

Діаграма компонентів UML

Для чого використовується метод проектування

Показати розбиття програмної системи на структурні компоненти та зв'язку (залежності) між компонентами.

Як фізичних компонент можуть виступати файли, бібліотеки, модулі, виконувані файли, пакети і т. П.

План дій

Після ознайомлення з розділами ( «Приклад», «Застосування») ви можете спробувати свої сили в самостійному складанні діаграм компонентів.

Як застосовувати метод проектування

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

приклад використання

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

В UML 1 був окремий символ для компонента (рис. 14.1). В UML 2 цього значка немає, але можна позначити прямокутник класу схожим значком. Або можна скористатися ключовим словом «component» (компонент).

Або можна скористатися ключовим словом «component» (компонент)

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

На рис. 14.2 показаний приклад простий діаграми компонентів. У цьому прикладі компонент Till (Каса) може взаємодіяти з компонентом Sales Server (Сервер продажів) за допомогою інтерфейсу sales message (Повідомлення про продажі). Оскільки мережа ненадійна, то компонент Message Queue (Черга повідомлень) встановлено так, щоб каса могла спілкуватися з сервером, коли мережа працює, і розмовляти з чергою повідомлень, коли мережа відключена. Тоді чергу повідомлень зможе поговорити з сервером, коли мережу знову стане доступною. В результаті чергу повідомлень надає інтерфейс для розмови з касою, і вимагає такої ж інтерфейс для розмови з сервером. Сервер розділений на два основних компоненти: Transaction Processor (Процесор транзакцій) реалізує інтерфейс повідомлень, а Accounting Driver (Драйвер рахунків) спілкується з Accounting System (Система ведення рахунків).

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

Компоненти - це не технологія. Технічні фахівці вважають їх важкими для розуміння. Компоненти - це скоріше стиль ставлення клієнтів до програмного забезпечення. Вони хочуть мати можливість купувати необхідне їм програмне забезпечення частинами, а також мати можливість оновлювати його, як вони оновлюють свою стереосистему. Вони хочуть, щоб нові компоненти працювали так само, як і попередні, і оновлювати їх відповідно до своїх планів, а не за вказівкою виробників. Вони хочуть, щоб системи різних виробників могли працювати разом і були взаємозамінними. Це дуже розумні вимоги. Одна заковика: їх важко виконати.
Ральф Джонсон (Ralph Johnson), http://www.c2.com/cgi/wiki?DoComponentsExist

Важливим є те, що компоненти представляють елементи, які можна незалежно один від одного купити і оновити. В результаті розділення системи на компоненти є в більшій мірі маркетинговим рішенням, ніж технічним. Прекрасне керівництво по даному питанню представляє книга Хохмана [23]. Вона також нагадує про те, що слід остерігатися поділу системи на занадто дрібні компоненти, оскільки дуже великою кількістю компонентів важко керувати, особливо коли виробництво версій піднімає свою потворну голову; звідси пішов вислів «пекло DLL» або «dll hell». У ранніх версіях мови UML компоненти застосовувалися для подання фізичних структур, таких як DLL. Тепер це не актуально; в даний час ця задача вирішується за допомогою артефактів (artifacts).

Підписуйтесь на новини сайту, форму підписки ви можете знайти в правій колонці сайту.

Якщо ви хочете навчитися працювати на фрілансі професійно, запрошуємо на курс « Як заробляти на фрілансі ».

Перейти на сторінку курсу
Перейти на сторінку курсу

Якщо вам сподобалася стаття - поділіться посиланням з друзями!

2.com/cgi/wiki?
Главная Партнеры Контакты    
Cистема управления сайта от студии «АртДизайн»