Б С Бусигін - Прикладна інформатика - страница 22

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 

Саме цей варіант UML 1.1 у листопаді 1997 року було затверджено як стандарт її галузі.

Тоді ж OMG прийняла UML як головну специфікацію для OMA (Object Modeling Architecture - Архітектури Моделювання Об'єктів), ""надаючи (рос.-предоставляя) розробникам, що працюють с аби якими мовами програмування і на аби яких платформах, загальну мову моделювання для побудови розподілених і бізнес додатків у інформаційних системах, що повинно вносити необхідну погодженість (рос.-согласованность) у розвиток цієї складної дисципліни " (так наголосив Річард Солі, голова і виконавчій директор OMG).

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

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

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

О Користувачам дається готова до використання, могутня мова моделювання.

© Забезпечені для використання мовні механізми розширення і спеціалізації

для різних предметних областей потрібних засобів моделювання, так як при подальшому розвитку ЦМЬ небажано перевизначати його ядро кожного разу знов і знов. Тому концепції ЦМЬ припускають її розширення для нестандартних ситуацій, а також містять засоби урахування спеціалізації задач у конкретних предметних областях (наприклад, системи реального часу, \УеЬ-технології, \УеЬ-сервіси, геоінформаційні системи і т.д.).

© Забезпечена незалежність процесу розробки інформаційних систем від мов програмування і моделей цього процесу, бо ЦМЬ підтримує усі розумні мови програмування і моделі процесів розробки ПЗ, які прийняті при розробці програмного забезпечення на конкретному підприємстві (рис.7.15).

© Створене обґрунтування мови Автори наголосили формалізація мови повинна бути присутньою у розумних границях, щоб не заважати легкості сприйняття та простоті застосування

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

4GL, 4th Dimension, ABAP/4, ActiveX, Ada, adb, ALGOL, Apl, ASM, ASN.1, ASP (Active Server Pages), Assembler, ATL (Class Library), awk, AWT Library, bash, Basic, Bourne-Shell, C, C++, CA-EARL, CA-SORT, Centura Team Developer, CFE, CGI, Chill, CL/400, Clarion, Clipper, CLIST, CLOS, CLP, Cobol, CORBA IDL, C-Shell, CSP, DCL, DEC C, Delphi, Delta, Designer/2000, Developer/2000, DeveloperStudio, DHTML, DirectX, Drive (Siemens), Easy for Turbo Databank, Easytrieve Plus, Eiffel, Emacs, ESQL/C, EXEC, FOCUS, Forth, Fortran, Foxpro, GINO-F, GNU-make, GRIT, HASKELL, HP Basic, HP PCL, HP VEE, HPGL, HPSG, HTML, HyperTalk, ILE/400, Imake, IMSL, Informix 4GL, Informix ESQL/C, Java, JavaScript, JCL, JSP (JavaServerPages), KBV, Korn-Shell, Ksh, K-Shell, LabView, Libraries, Lingo, LISP, Lotus Notes Script, M4, Macro Programing, MAGUS, make, Make-Maker, Mantis, Maschinensprachen, Mbed, MFC (Class Library), ML, Modula-2, Motif, MPGS, Mumps, Natural, Nexpert, Oberon, Objective, Object-PAL, Occam, OCL, OjectView, Open-GL, Optima++, OQL, Oracle Forms, Oracle Reports, Oracle SQL Plus, OWL (Class Library), Paisy, Pascal, Perl, PFC, Phigs, PHP, PIC, PL/1, PL/SQL, PL/Z, PLDS, PLM, Power++, PowerBasic, PowerBuilder, PowerHouse Cognos, PROGRESS-4GL, Prolog, Psion OPL, Python, QMF, Qt, RAMIS II (4GL), Rational Rose, rcs, ReXX, RPG, SAL, SAPIENS, SAS, sccs, Scheme, Script Languages, S-Designor, SDL, sed, SESAM, sh, Shell, Simula, Simula67, Siron, Smalltalk, SmartWare, SML, Softedit, S-Plus, SPS, SQL/Windows, STEP-5 (Siemens SPS), STL (Class Library), Superbase unter Windows, Swing, System Builder Plus, TAL, Tcl/Tk, tclsh/wish, tcsh, Tex/LaTeX, Textedit, TK-Library, ToolBook (OpenScript), tools.h++ (Class Library), UIL, UNIFACE, UNIX Shells, UTM, VBA (Excel, Access, u.a.), VBScript, vi, Visual Age, Visual Basic, Visual C++, Visual Cafe, Visual J++, Visual Objects, Visual SourceSafe, Vocal, VRML, Windows API, WSH (Windows Scripting Host), xedit, XML, yacc/lex, zApp (Class Library), ZINC

Рис. 7.15. Звісні сучасні мови програмування

формальне моделювання.

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

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

У концептуальному плані нова мова характеризується наступними відмітними ознаками.

З точки зору змісту UML наслідує принципи і механізми техніки Booch і методів OMT і OOSE. По-друге, він перевершує їх. По-третє, слід відмітити, що UML - це стандарт мови, а не стандарт процесів аналізу, проектування і розробки. UML є квінтесенцією концепцій моделювання, згідно яких було досягнуто консенсусу у середовищі провідних компаній-виробників ОО програмного забезпечення, а конкретно у питаннях:

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

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

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

У інфраструктурі UML важливе місце займають засоби проектування і реалізації. До них відносяться:

О мови програмування. UML - мова візуального моделювання, яка не призначена для візуального програмування, хоча інструментальний засіб, що підтримує нотації UML, може реалізовувати кодогенерацію у конкретну мову програмування (C++, Delphi, Java та ін.) на основі побудованих моделей;

в інструментальні засоби. UML не є специфікацією для розробки інструментальних середовищ. В UML визначена тільки модель семантики, але не визначені моделі інтерфейсу, зберігання і підтримки часу виконання. Зараз вже є декілька CASE - засобів, виробники котрих підтримують моделювання засобами UML. Серед них можна виділити: Rational Rose, Select Enterprise, Platinum і Visual Modeler (рис. 7.16).

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

Рисунок 7.16. Застосування моделей UML при розробці бізнес додатків за допомогою CASE-засобів системи фірми Select

Enterprise

7.3 Структура і склад мови UML

Розглянемо структуру мови з точки зору компонент, що складають його опис. Визначення (рос.-определение) UML, є самодостатнім і включає наступні документи (у версії 1.3 1999 року випуску):

О Семантика UML;

в Нотація UML;

© Стандартні шаблони;

О Визначення засобів CORBA-інтерфейсів;

в Специфікації UML XMI DTD (для обміну моделями за допомогою мови

XML);

© Специфікації мови OCL (Object Constraint Language).

Опис  семантики UML  дається на рівні метамоделі і уявляється

наступними погодженими способами та включеними трьома наступними елементами.

О Абстрактний синтаксис включає метамодель UML, яка розбита на 9 взаємопов'язаних пакетів, кожний з котрих описується 9-ю діаграмами класів UML (рис. 7.17). Метамодель вміщує у себе коло 50-ти класів, більш ніж 100 асоціацій та 1000 обмежень (рос.-ограничений).

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

І   Оіадгат І

5

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Component

 

 

□ ass

 

 

Sequence

 

Actiwty

 

 

Object

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Deployment

 

Use case

 

Statechart

 

Collaboration

 

 

 

 

 

 

 

 

 

Рис. 7.17. Класи 9-ти діаграм ЦМЬ, які уявлені у термінах самої мови

© Присутній опис елементів нотації моделювання (семантики), котрий також виконано у англійській прозі.

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

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

© Теговані значення - дозволяють визначати нові властивості елементів моделювання, що дає можливість прив'язати до моделі цілком довільну (рос-произвольную) інформацію.

© Обмеження (рос. -ограничения) дозволяють визначити підмножину елементів моделювання, наділене визначеними властивостями (наприклад, упорядженість). Вказані умови можуть бути описані за допомогою мови OCL.

7.4. Типи діаграм UML та їх використання

Моделювання складної системи засобами UML приводить до її опису у різних проекціях (рис. 7.18). Кожна проекція описує деякий визначений аспект системи, що розробляється, а усі разом вони визначають систему з належною ступінню (рос.-степенью) повноти, правильності та адекватності. У UML для опису системи при аналізі і проектуванні передбачені наступні 9 графічних діаграм:

Рис. 7.18.

Висвітлення різних проєкцій (аспектів)

системи

Діаграми, які описують статичний стан системи:

О Діаграми прецедентів (варіантів використання (рос.-использования)) (Use case diagrams).

в Діаграми класів (Class diagrams). © Діаграми об'єктів (Object diagrams). Діаграми, які описують поведінку системи:

О Діаграми становищ (рос. -состояний) (State diagrams).

в Діаграми diagrams).

© Діаграми diagrams).

в Діаграми сотрудничества) (Collaboration diagrams).

Діаграми,   які описують системи:

© Діаграми компонент (Component diagrams).

© Діаграми   розгортання   (рос.-развёртывания) (Deployment

видів   діяльностей (Activity послідовностей (Sequence

співробітництва (кооперації,

(рос.-

взаємодії)

фізичну реалізацію

diagrams) (рис. 7.19).

Рис. 7.19. Комплекс діаграм, які описують повну модель системи

Таким чином, мова UML дозволяє:

О формалізувати функціональні вимоги до системи за допомогою апарату use case діаграм;

в деталізувати вимоги до системи шляхом побудови діаграм технологічних сценаріїв;

© розбити складну систему на складові частини з мінімумом взаємних зв'язків шляхом виділення пакетів;

О виділити класи даних, побудував концептуальну модель даних у вигляді діаграми класів;

© виділити класи, які описують інтерфейс користувача, та створити схему навигації екранів;

© описати процеси взаємодії об'єктів при виконанні системних функцій;

© описати поведінку об'єктів у вигляді діаграм станів (рос.-состояний);

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

системи, з точки зору розробника (рис. 7.20).

Уявлення системи прецедентами

(вариантами використання системи)

Уявлення реалізації системи

Уявлення розгортання системи

Рис. 7.20. П'ять різних поглядів на систему, які отримуються за допомогою дев'яти діаграм иМЬ.

І так як мова ЦМЬ велика (рос.-обширная) і складна у плані термінології і нотації, слід коротко описати діаграми кожного з вищенаведених типів.

Техніка Прецедентів (Варіантів Використання - ЦБеСаБе) - була вперше запропонована Айваром Якобсоном у 1992 році і швидко завоювала загальне визнання за рахунок простоти і легкості сприйняття (рос.-восприятия) та застосування. Суть її полягає (рос. -состоит) у наступному. Система, що проектується уявляється у вигляді наборів актантів (акторів), які взаємодіють з системою за допомогою так званих прецедентів (рис. 7.21). Актантом є будь яка сутність, що взаємодіє з системою зовні.

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

Рис. 7.21. Діаграми прецедентів (Цбє саБе)

ryC

Рис. 7.22.

Діаграми класів (classes)

Рис. 7.23.

Діаграми об'єктів (objects)

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

Діаграма класів показує статичну структуру різних частин системи (рис. 7.22). Таким образом, складовими (елементами) даного типу діаграм є класи, об'єкти і відношення поміж ними. Нотація класів і об'єктів проста та інтуїтивно зрозуміла усім, хто колись мав досвід роботи з різного роду САБЕ-інструментаріями (рис. 7.22, 7.23). Клас представлено прямокутником з трьома розділами (рис.7.22), у котрих відповідно розміщуються: ім'я класу, атрибути і операції. Схожа нотація застосовується і для об'єктів - екземплярів класу, з тією різницею, що до імені класу додається ім'я об'єкту і весь надпис підкреслюється. Нотація ЦМЬ надає широкі можливості для відображення додаткової (і як правило дуже важливої) інформації, до котрої можна віднести абстрактні операції і класи, стереотипи, загальні і приватні (рос.-частные) методи, інтерфейси, параметризовані класи і т.д. Важливішими елементами діаграм класів і об'єктів є асоціації, тобто статичні зв'язки поміж класами, які зображуються у вигляді пов'язаних ліній, на котрих може вказуватися потужність (рос.-мощность) асоціації, її направлення, назву, і можливе обмеження, що реалізує механізм розширення ЦМЬ (рис. 7.24).

Цей клас асоціюється з

 

цим класом.

Цей клас залежить від

 

цього класу.

Цей клас спадкоємець (рос.-наследник)

->

цього класу.

Цей клас має

цей інтерфейс.

Цей клас є реалізацією

--~г>

цього класу.

Ви можете управляти з цього класу

—>

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83 


Похожие статьи

Б С Бусигін - Прикладна інформатика