JavaBeans проти EJB

Через схожість назв часто путаються між моделлю компонент JavaBeans і специфікацією Enterprise JavaBeans. JavaBeans і специфікацією Enterprise JavaBeans поділяють однакові цілі: впровадження повторного використання, компактність Java коду при розробці і інструменти розробки з використанням стандартних шаблонів, але мотиви специфікації більш підходять для розв’язання різних проблем.

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

Специфікація Enterprise JavaBeans визначає модель компонентів для розробки Java коду сторони сервера. Оскільки EJB можуть запускатися потенційно на різних серверних платформах – включаючи центральні машини, які не мають візуальних дисплеїв – EJB не може використовувати графічні бібліотеки, типу AWT або Swing.

Специфікація EJB

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

Роль Відповідальність
Постачальник EJB Розробник відповідає за створення EJB компонент повторного використання. Ці компоненти упаковані в спеціальний jar файл (ejb-jar файл).
Збиральник програми Створює і збирає програму із набору ejb-jar файлів. Це включає написання програм, які утилізують набір EJB (наприклад, сервлетів, JSP, Swing і т.д..).
Установник Бере набір ejb-jar файлів від Збиральника і/або Постачальника і розгортає їх в середовищі часу виконання: один або декілька EJB контейнерів.
EJB Контейнер/Постачальник сервера Надає середовище часу виконання і інструменти, що використовуються для розгортання, адміністрування і запуску EJB компонент.
Системний адміністратор Керує різними компонентами і службами, щоб вони були сконфігурованими і правильно взаємодіяли, також слідкує, щоб система працювала правильно.

 

Лекція 17-18. Уніфікована мова моделювання. Основи UML.

Дерева наслідування, приклади діаграм класів.

 

1. Загальна характеристика UML.

2. Архітектурний базис UML.

3. Відношення.

4. Діаграми UML.

5. Правила і загальні механізми мови UML.

6. Представлення моделі.

 

1. Загальна характеристика UML

Уніфікована мова моделювання (Unified Modeling Language, UML) – це графічна мова для специфікації, візуалізації, конструю-вання і документування програмних систем. За допомогою UML можна розробити детальний план такої системи, який відобража-тиме і концептуальні елементи системи (системні функції та біз-нес-процеси), і особливості її реалізації (класи, схеми баз даних, програмні компоненти багаторазового використання тощо).

Авторами мови є Грейді Буч (Grady Booch), Джеймс Рамбо (James Rumbaugh) і Айвар Якобсон (Ivar Jacobson). У січні 1997 ро-ку внаслідок об’єднання розробок цих авторів випущено версію UML 1.0, а в листопаді 1997 року – версію UML 1.1. Наступні вер-сії: UML 1.3 – квітень 1999 року; UML 1.4 – жовтень 2001 року.

Зауважимо, що базові ідеї та конструкції мови практично не змінювалися з версії UML 1.1. У наступних версіях уточнювали визначення, добавляли розділи, регламентували зв’язки UML з ін-шими технологіями тощо. Паралельно розвивалися інструменталь-ні засоби, які підтримували UML (Rational Rose Enterprise, Objec-teering, Magic Draw UML, MS Visio, Visual UML та ін.).

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

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

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

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

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

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

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

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

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

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

UML – це обєктно-орієнтована мова, яку найефективніше можна застосовувати саме в контексті об’єктно-орієнтованих методів аналізу та проектування.

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

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

UML – це стандартна мова, яка гарантує вільне розуміння та поширення UML-моделей між різними розробниками.

UML – це універсальна мова, яка з однаковим успіхом придатна для моделювання як великих, так і малих програмних систем.

UML – це незалежна мова, яка не накладає обмежень на мови програмування для реалізації моделей і може бути сумісною з будь-якою об’єктно-орієнтованою мовою.

 

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

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

Зазначимо ще одну область, у якій активно застосовують гра-фічну нотацію – це виконання робіт з приведення системи менедж-менту якості у відповідність зі стандартом ISO 9001:2000 у рамках сертифікації підприємств і компаній. У цій області мову UML зас-тосовують для візуального моделювання та документування бізнес-процесів. Розроблені діаграми і пояснення до них надсилають між-народним сертифікаційним органам для отримання відповідного сертифікату.

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

 

2. Архітектурний базис UML

Архітектурний базис UML визначає базові поняття, якими оперує мова: сутності, відношення та діаграми.

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

Структурні сутності – це статичні поняття, які відповідають концептуальним, логічним чи фізичним елементам системи. Струк-турні сутності, зазвичай, позначають іменниками. Розрізняють п’ять головних структурних сутностей: актори, класи, інтерфейси, компоненти, вузли. Кожна з сутностей може мати свої підвиди.

Актор (Actor) – це суб’єкт, який перебуває поза системою, що моделюється, і безпосередньо з нею взаємодіє. Графічно акто-рів зображають значком “худа людина”, під яким вказують ім’я актора (рис. 2.1).

 

Адміністратор

 
 

 


Рис. 2.1. Зображення актора

Клас (Class) – це сукупність однотипних сутностей предмет-ної області (обєктів) зі спільними атрибутами, операціями, відно-шеннями та семантикою.

В UML класи зображають прямокутником, розділеним на три секції, в яких записують назву класу, атрибути та операції, відпо-відно (рис. 2.2). Назву абстрактного класу позначають курсивом. Атрибути та операції мають чітко визначені формати запису, які відображають їхні найважливіші характеристики (назви, типи тощо). За необхідності секції атрибутів і/або операцій опускають.

Window
length : int width : int
open() close()

 

Рис. 2.2. Зображення класу

Обєкти (Objects) – це екземпляри класів з конкретними зна-ченнями атрибутів. Об’єкт має зображення, подібне до зображення класу, проте назву об’єкта підкреслюють і записують у вигляді: <назва об’єкта>:<назва класу>. Якщо ідентифікація об’єкта неваж-лива, то вказують лише назву класу, до якого належить об’єкт: :<назва класу>. При зображенні об’єктів секції атрибутів та операцій, здебільшого, опускають.

Інтерфейс (Interface) – це сукупність операцій, що формують деякий сервіс, який надає клас чи компонент. Інтерфейс лише де-кларує операції, а реалізація операцій покладається на клас або компонент, який підтримує цей інтерфейс. Інтерфейси зображають колом, під яким вказують назву інтерфейсу (рис. 2.3).

 

Visible

 

Рис. 2.3. Зображення інтерфейсу

Компонент (Component) – це фізично заміщувана частина системи, яка відповідає певному набору інтерфейсів і/або забезпе-чує реалізацію іншого набору інтерфейсів. Компоненти фізично існують під час виконання програми. Графічне зображення ком-понента – прямокутник з двома виступами з лівого боку і назвою усередині (рис. 2.4).

 

 

Компілятор

     
   
 
 

 

 


Рис. 2.4. Зображення компонента

В означенні компонента цілковито викладено його семантику:

• компонент має фізичну природу – він існує в реальному світі бітів, а не у світі концепцій;

• компонент заміщуваний – замість одного компонента можна підставити інший, якщо він відповідає тому ж самому набору інтерфейсів;

• компонент – це частина системи.

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

• класи – логічна абстракція, а компоненти – фізичні сутності (можуть розміщуватися у вузлах);

 

• компоненти слугують фізичною упаковкою логічних сутностей (класів, кооперацій тощо), отож є на іншому рівні абстракції порівняно з класами;

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

1. Компоненти розгортання (Deployment components): динамічно під’єднувані бібліотеки (DLL) і програми виконання (ЕХЕ).

2. Компоненти робочі продукти (Work product components): файли з вихідними текстами програм чи даними; бази даних або таблиці баз даних; документи; виконавчі модулі із закрити-ми механізмами комунікації тощо.

3. Компоненти виконання (Ехесution components) – наслідок ро-боти системи (прикладом є об’єкт СОМ+, екземпляр якого створюється з DLL).

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

 

 

Рис. 2.5. Зображення вузла

Вузли надають засоби фізичного розгортання компонентів. Найпоширеніший приклад використання вузлів – це моделювання процесорів і пристроїв, які утворюють топологію автономної, вбу-дованої, клієнт-серверної чи розподіленої комп’ютерної системи.

Сутності поведінки (преценденти, діяльності, стани і повідом-лення) розглядатимемо під час вивчення відповідних діаграм.

Сутності групування пакети (packages) можуть містити структурні сутності, сутності поведінки та інші сутності групуван-ня. На відміну від компонентів, які реально існують під час роботи програми, пакети мають чисто концептуальний характер (існують тільки під час процесу розробки).

Пакет зображають прямокутником із “закладкою” – меншим прямокутником, приєднаним до верхнього лівого кута (рис. 2.6).

 

 
 

 


 

Рис. 2.6. Зображення пакета

Анотаційна сутність – це коментар для пояснення чи заува-ження до будь-якого елемента моделі. Є тільки один тип анотацій-ної сутності – примітка (note). Графічно примітку зображають прямокутником із загнутим правим верхнім кутом (рис. 2.7).

 

 
 


 

Рис. 2.7. Зображення примітки

2.3. Відношення

Відношення – це відображення семантичного зв’язку між су-тностями. У мові UML визначено чотири основні типи відношення: залежності, асоціації, узагальнення та реалізації.

Залежність (dependency) – це відношення використання, за якого зміна однієї сутності (незалежної) може вплинути на іншу сутність, яка її використовує, причому зворотне використання, за-звичай, неприпустиме. Для зображення залежності використовують пунктирну лінію зі стрілкою (рис. 2.8), спрямованою у бік незалежної сутності.

 

 


Рис. 2.8. Зображення залежності

 

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

Асоціація (assocіatіon) – це структурне відношення, що опи-сує множину зв’язків (з’єднань) між об’єктами. Різновид асоціації – агрегування (aggregatіon) – це структурне відношення між цілим і його частинами. Графічно асоціацію зображають у вигляді лінії (іноді завершується стрілкою), поруч з якою можуть бути додаткові позначення (кратність, назви ролей тощо). На рис. 2.9 зображено приклад відношення цього вигляду.

 

 
 

 

 


Рис. 2.9. Приклад асоціації

Узагальнення (generalіzatіon) – це відношення типу “спеціа-лізація/узагальнення”, за якого об’єкт спеціалізованого елемента (нащадок) може бути підставлений замість об’єкта узагальненого елемента (батька, предка), проте не навпаки. За принципом об’єктно-орієнтованого програмування, нащадок (chіld) успадковує структуру і поведінку свого предка (parent). Графічно відношення узагальнення зображають лінією з незафарбованою стрілкою, яка вказує на предка (рис. 2.10).

 

Parent  
Child  

       
   
 
 

 


Рис. 2.10. Приклад узагальнення

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

Найчастіше узагальнення використовують при моделюванні класів. Клас може мати одного (Single inheritance) або декілька предків (Multiple inheritance), чи не мати їх зовсім. Клас, у якого не-має предків, а є нащадки, називають базовим (або кореневим). Клас, у якого немає нащадків, називають листковим.

Узагальнення використовують також з метою відображення наслідування між класами та інтерфейсами або з метою відобра-ження наслідування між пакетами тощо.

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

• між інтерфейсами і класами/компонентами, що їх реалізують;

• між прецедентами і коопераціями, що їх реалізують.

Відношення реалізації зображають у вигляді пунктирної лінії з незафарбованою стрілкою, як щось середнє між відношенням узагальнення і залежності (рис. 2.11):

                       
   
         
 

 

 


Рис. 2.11. Зображення реалізації

Ми розглянули чотири типи відношень, які є базовими у моделях UML. Існують також їхні варіанти: уточнення (refіnement), трасування (trace), долучення і розширення для залежностей тощо.

2.4. Діаграми UML

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

Діаграми класів (class dіagram) – зображають класи, інтерфейси, об’єкти і кооперації, а також відношення між ними. Ці діаграми відображають статичні аспекти системи.

Діаграми обєктів (object dіagram) – зображають об’єкти і від-ношення між ними. Це статичні знімки екземплярів сутностей, зображених на діаграмах класів.

Діаграми прецедентів (use case dіagram) – зображають преце-денти й акторів, а також відношення між ними. Ці діаграми відображають статичні аспекти системи.

 

Діаграми взаємодії – зображають об’єкти та повідомлення, яки-ми об’єкти можуть обмінюватися. Зазвичай, розглядають два часткові випадки таких діаграм: діаграми послідовностей (se-quence dіagram), що відображають часову упорядкованість пові-домлень, і діаграми кооперації (collaboratіon dіagram), на яких зображають структурну організацію об’єктів, що обмінюються повідомленнями. Ці типи діаграм є ізоморфними. Діаграми взаємодії відображають динамічні аспекти системи.

Діаграми станів (statechart dіagram) – зображають автомат, що налічує стани, переходи, події і види дій. Ці діаграми відображають динамічні аспекти системи.

Діаграми діяльностей (actіvіty dіagram) – це окремий випадок діаграми станів (на діаграмі зображають переходи потоку керу-вання від одного виду діяльності до іншого усередині системи).

Діаграми компонентів (component dіagram) – зображають су-купність компонентів та існуючі між ними залежності. Ці діа-грами відображають статичні аспекти системи.

Діаграми розміщення (deployment dіagram) – зображають кон-фігурацію вузлів системи і розміщених у них компонентів. Ці діаграми відображають статичні аспекти системи. Вони зв’я-зані з діаграмами компонентів, оскільки у вузлі розміщують один чи декілька компонентів. Програмна система (або деяка інша система) – це сутність аналізу та проектування, яку розглядають з різних позицій за до-помогою моделей, які відображають діаграмами. Діаграма – гра-фічна проекція елементів системи. Один елемент можна зображати на різних діаграмах. Кожна діаграма відображатиме одне з можли-вих представлень елементів системи.

 

2.5. Правила і загальні механізми мови UML

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

назви, які можна надавати сутностям, відношенням і діаграмам;

область дії – контекст, в якому назва має певне значення;

 

видимість– контекст, в якому назва може використовуватися іншими елементами;

цілісність – узгоджена поведінка та взаємодія елементів;

виконання – правильне розуміння поведінки системи в динаміці. Моделювання спрощується і здійснюється ефективніше, як-що дотримуватися деяких угод. Роботу з UML істотно полегшує послідовне використання загальних механізмів: специфікації (specі-fіcatіons), доповнення (adornments), поділу (common dіvіsіons) і роз-ширення (extensіbіlіty mechanіsms).

Щодо кожного з елементів графічної моделі UML складаєть-ся специфікація, яка містить текстове представлення елемента.

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

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

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

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

Наприклад, базова нотація асоціації – це лінія, однак її мож-на доповнювати стрілками, кратностями і назвами ролей.

При роботі з класами, компонентами чи вузлами уточнюючу інформацію можна розмістити у додатковому розділі, який розта

шовують нижче від головних розділів. З метою однозначного розуміння додатковий розділ рекомендують називати явно.

Під час моделювання об’єктно-орієнтованих систем існує поділ на класи/обєкти та інтерфейс/реалізацію.

Клас – це абстракція, а обєкт – конкретне втілення цієї абстракції (або екземпляр класу). Наприклад, є прецеденти й екзем-пляри прецедентів, компоненти й екземпляри компонентів, вузли й екземпляри вузлів тощо. У графічному зображенні об’єкта прийня-то його назву підкреслювати.

Інтерфейс декларує зобов’язання, а реалізація представляє конкретне втілення цих зобов’язань і точно відповідає оголошеній семантиці інтерфейсу. Майже всі конструкції UML характеризу-ються дихотомією інтерфейс/реалізація. Наприклад, прецеденти реалізуються коопераціями, а операції – методами.

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

стереотипи (stereotype) – розширюють словник UML шляхом створення нових сутностей мови на основі існуючих сутностей;

позначені значення (tagged value) – розширюють властивості ос-новних елементів UML, даючи змогу долучати нову інформа-цію до специфікації елемента;

обмеження (constraіnts) – розширюють семантику елементів, даючи змогу створювати нові і скасовувати існуючі правила.

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

Стереотип – це деякий метаклас, який дає змогу вводити нові сутності. У найпростішому випадку стереотип зображають як назву в типографічних лапках (наприклад, «global»). Для наочності сте-реотипу можна призначити піктограму (розмістити її праворуч від назви) чи застосувати новий графічний символ. Усі три підходи проілюстровано на рис. 2.12.

           
 
  Business Worker
 
     
 

 

 


Рис. 2.12. Способи зображення стереотипів

 

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

Позначене значення (або позначка) – це метадане (його зна-чення застосовують щодо сутності), яке зображають так:

{ [ НазваПозначки = ] Значення }

Фігурні дужки – обов’язкові елементи позначки. Можна вказувати тільки значення, якщо воно допускає однозначну інтерпретацію. Позначки можна визначати для існуючих сутностей UML або застосовувати щодо окремих стереотипів. Позначки розташовують під назвою сутності чи стереотипу. У фігурних дужках може бути декілька позначених значень, які розділяються комами. На рис. 2.13 наведено приклад використання позначених значень у варіанті використання.

 

 

 


Рис. 2.13. Приклад використання позначених значень

 

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

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

 

 
 

                   
         

 


Рис. 2.14. Приклад використання обмеження

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

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

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

2.6. Представлення моделі

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

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

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

 

Представлення прецедентів (Use case view) – це опис поводження системи з позиції зовнішніх користувачів, аналі-тиків і тестувальників.

Логічне представлення (Logical view) – це опис системи з по-зиції проектування. Він охоплює класи, інтерфейси та коопера-ції, що формують словник предметної області та її розв’язок.

Представлення процесів (Process view) – це опис взаємодії процесів під час роботи системи. Він віддзеркалює такі аспек-ти, як паралелізм, синхронізація, продуктивність, масштабо-ваність і пропускна здатність.

Представлення компонентів (Component view) – це опис кон-фігурації системи з позиції реалізації, який охоплює ком-поненти і файли, що використовуються для збирання і випуску готового програмного продукту.

Представлення розміщення (Deployment view) віддзеркалює топологію зв’язків апаратних засобів і розміщення на них компонентів.

􀁖 Запитання для самоперевірки

1. Дайте визначення UML.

2. Перелічіть головні властивості UML.

3. Перелічіть структурні сутності UML.

4. Дайте визначення актора.

5. Дайте визначення класу й об’єкта.

6. Дайте визначення вузла й компонента.

7. Перелічіть основні типи відношень.

8. Дайте визначення стереотипу.

9. Дайте визначення позначеного значення.

10. Яким шляхом вводять обмеження у мові UML.

11. Для чого використовують представлення прецедентів?

12. Для чого використовують логічне представлення?

13. Для чого використовують представлення процесів?

14. Для чого використовують представлення компонентів?

15. Для чого використовують представлення розміщення?


Лекція 19. CASE-технології проектування та супроводження програмних засобів.

Поняття про CASE-технології.

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

Важливий напрям в розвитку технологій склали розробки інтегрованих інструментальних засобів, які базуються на концепціях життєвого циклу і управління якістю автоматизованих інформаційних технологій і систем, які являють собою комплексні технології, орієнтовані на створення складних автоматизованих управлінських систем і підтримку їх повного життєвого циклу або ряду його основних етапів. Подальший розвиток робіт в цьому напрямку привело до створення ряду концептуально цілісних, оснащених високошвидкісними засобами проектування і реалізації варіантів, доведених по якості і легкості тиражування до рівня програмних продуктів технологічних систем, які отримали назву CASE-систем або CASE-технологій (Computer-Aided Software/System Engeneering).

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

Сфера застосування CASE-технологій.

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

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

Переваги CASE-технологій.

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

Крім автоматизації структурних методологій і, як наслідок, можливості застосування сучасних методів системної і програмної інженерії, CASE-технологіям притаманні такі переваги:

· покращують якість створюваних автоматизованих інформаційних систем за рахунок засобів автоматичного контролю (перш за все, контролю проекту);

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

· прискорюють процес проектування і розробки системи;

· звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитися на творчій частині розробки;

· підтримують розвиток і супроводження розробки автоматизованої інформаційної системи;

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

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

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

Лекція 20. Загальні відомості про подійно-керовані моделі та Visual Basic.

 

Visual Basic є інтегрованим середовищем-оболонкою, що включає мову

структурного програмування і середовище для проектування завершених дода-

тків.

Процес проектування додатків засобами Visual Basic передбачає вико-

нання чотирьох основних етапів:

1 Проектування екранного інтерфейсу користувача (екранної форми).

2 Встановлення властивостей елементів керування, розміщених на формі.

3 Написання кодів програм для подій елементів керування форми.

4 Запуск, виправлення можливих помилок та перевірка правильності роботи програми на конкретних даних.

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

завантаження форми (Form_Load), клацання (Click) або подвійне клацання

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


 

Стандартний набір елементів керування екранною формою

 

 

Робота покажчиком миші;

PictureBox, вікно з рисунком;

Label, напис на формі. Головна властивість – Caption для відображення тексту;

TextBox, поле для введення/виведення даних. Головна властивість – Text;

Frame, рамка для об’єднання елементів у групу;

CommandButton, командна кнопка для ініціювання подій;

CheckBox, позначка для надавання можливості вибору певної умови;

OptionButton, перемикач для надавання права вибору двох або кількох можливостей;

ComboBox, комбінований список;

ListBox, список. Властивості Text присвоюється обраний зі списку елемент;

HScrollBar, горизонтальна смуга прокручування;

VScrollBar, вертикальна смуга прокручування;

 

Timer, таймер дозволяє запускати (завершувати) елементи додатка у певні моменти часу;

DriveListBox, список зовнішніх пристроїв – дисків;

 

DirListBox, список директорій (каталогів);

FileListBox, список файлів поточної директорії;

Shape, фігури: квадрат, овал, коло тощо;

Line, лінія;

Imige, відображення рисунка на формі;

Data, доступ до бази даних.

 

При створюванні проекту екранної форми треба обрати відповідний

інструмент на панелі елементів керування (Toolbox) і помістити його в поле

створюваної екранної форми. Кожний з елементів керування має свій набір

властивостей, які визначають зовнішній вигляд та функціонування елемента

керування і встановлюються у вікні властивостей (рис. 1.1).

Рисунок 1.1 – Вікно розробляння проекту

 

Значення властивостей для кожного елемента керування, розташованого на

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

Вікно <Свойства> можна відкрити різними способами:

1) з меню <Просмотр> – <Свойства окна> ;

2) за допомогою кнопки на панелі інструментів;

3) з контекстного меню;

4) натисненням функціональної клавіші F4 на клавіатурі.

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

то команди коду будуть виконуватися автоматично, як тільки ця подія станеться.

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

Private Sub Command1_Click()

End Sub

Тобто Visual Basic автоматично створює два рядки програми: заголовок та рядок завершення процедури. Оголошення локальних змінних і текст програми

слід розміщувати поміж цими рядками. Глобальні змінні слід описувати перед

процедурами в секції General (Declarations) стандартного модуля.

Для перемикання поміж вікнами проекту форми та редактора програмного

коду можна використовувати кнопки у вікні провідника проекту.

Запускання проекту виконується за допомогою кнопки на панелі інструментів або при натисканні клавіші F5. Також можна запускати проект командою

з підменю <Запустить> та <Начать>.

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

<Файл>: <Сохранить форму> для створення файлу з розширенням .frmта

<Сохранить проект> для створення файла з кодами процедур із розширенням .bas. Проект можна зберігати без зміни імен форми і програми при виході

із редактора Visual Basic.

Після перевірки правильності роботи програми останнім кроком роботи

з проектом є створення виконуваного файла з розширенням .ехе, для чого

обирається команда <Создать *.ехе> з меню <Файл>.

 

Лекція 21. Властивості, методи, події, основні елементи управління.

Основні елементи управління