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

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

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

Відповімо на запитання, навіщо будують моделі? Моделі будують для того, щоб краще зрозуміти досліджувану систему.

Класики проклассифицировать завдання і принципи моделювання. Наведемо тут цю, поза сумнівом, важливу, класифікацію.

Завдання моделювання [3]:

- Візуалізація системи в її деякому стані.

- Визначення структури і поведінки системи.

- Отримання шаблону для створення системи.

- Документування прийнятих рішень.

Принципи моделювання [3]:

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

- Кожна модель може бути втілена з різним ступенем абстракції.

- Кращі моделі - ті, що ближче до реальності.

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

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

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

Це і означає необхідність візуального моделювання.

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

- Візуалізація спрощує розуміння проекту в цілому.

- Візуалізація допомагає узгодити термінологію і переконатися, що всі однаково розуміють терміни.

- Візуалізація робить обговорення конструктивним і зрозумілим.

Для візуального моделювання потрібна спеціальна нотація або мову.

UML (unified modeling language) - це мова для візуалізації, специфицирования, конструювання, документування елементів програмних систем [3]. UML - мова загального призначення, призначений для об'єктного моделювання.

Розглянемо коротко історію мови UML. До 1994 року існувало кілька нотацій для візуального відображення прийнятих проектних рішень і кілька методів аналізу і проектування. У 1994 році відбулася знакова подія - Grady Booch і James Rumbaugh, співробітники фірми Rational Software, об'єднали свої методи проектування та аналізу, створивши так званий Unified method. З цього моменту процес стандартизації домовленостей увійшов в робочий ритм. Наведемо важливі віхи цього шляху:

- 1994: Grady Booch & James Rumbaugh (Rational Software) об'єднали методи Booch (проектування) і OMT (аналіз) -> Unified method.

- 1995: приєднався Ivar Jacobson (автор методу OOSE). Згодом група авторів Booch, Rumbaugh і Jacobson разом випустила не одну книгу, що стала бестселером (наприклад, див список літератури). Цю трійцю жартівливо називали «three amigos», натякаючи на те, як жарко вони сперечалися з приводу прийнятих рішень.

- 1996 - Ідея про Unified Modeling Language (three amigos).

- 1996 - створено консорціум UML Partners під керівництвом three amigos.

- Червень, Жовтень 1996 - UML 0.9 & UML 0.91.

- Січень 1997 - специфікації UML 1.0 запропоновані OMG (Object Management Group).

- Серпень 1997 - специфікації UML 1.1 запропоновані OMG.

- Листопад 1997 - UML 1.2 - результат адаптації OMG.

- Червень 1999 - UML 1.3.

- Вересень 2001 - UML 1.4.

- Березень 2003 - UML 1.5.

Прийнятий стандарт:

- ISO / IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2.

- Жовтень 2004 - UML 2.0.