К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Інструментальна підтримка SSADM. Головний інструмент структурного проектування відповідно до процесів ЖЦ – комплекс програмних, методичних й організаційних засобів системи SSADM. Ця система прийнята державними органами Великобританії як основний системний засіб і використовується багатьма державними організаціями і в межах, і за межами країни. SSADM містить у собі п'ять головних модулів підтримки, як процесів ЖЦ з проектування ПП [2]: 1) вивчення можливості виконання проекту (Feasibility Study Module); 2) аналіз вимог (Requirements Analysis Module); 3) специфікація вимог (Requirements Specification Module); 4) логічна специфікація системи (Logical System Specification Module); 5) фізичне проектування (Physical Design Module). Проектування за допомогою системи SSADM передбачає сукупність заходів з розробки набору проектних документів в умовах використання відповідних ресурсів при заданих обмеженнях на вартість розробки. Для керування ходом розробки проекту розглядаються проектні роботи і документи, організація і плани розробки, заходи щодо керування проектом та забезпечення якості. Розрізняються два типи проектних робіт: – забезпечення вимог користувача до якості системи; – керування розробкою проекту. Структурна модель охоплює всі модулі й стадії технології SSADM, забезпечує одержання одних документів на підставі інших шляхом логічних перетворень. Іншими словами, одна сукупність документів перетворюється на іншу. Для встановлення послідовності робіт і заходів з забезпечення якості розробляється сітковий графік робіт. Забезпечення якості реалізується групою якості, що відповідає за підтримку цілісності проекту. В ній працюють фахівці, відповідальні за функціонування організації (плановики, економісти), користувачі системи й розробники, які беруть участь у проекті від початку до кінця. Плановики й економісти слідкують за своєчасним виконанням і фінансуванням робіт, користувачі – висувають вимоги та пропозиції, а розробники виражають їхні потреби в рамках своєї компетенції. Для керування проектом створюється служба підтримки проекту, що виконує ряд адміністративних функцій або спеціальних робіт. Вона здійснює експертизу при оцінюванні, плануванні і керуванні проектом, а також проводить заходи з керування конфігурацією, сутність яких полягає у відстеженні проектних документів і забезпеченні інформації про їхній стан у процесі розроблення. Проблема якості стосується двох основних аспектів: 1) сукупності функцій, що повинні задовольняти задані вимоги до функцій, надійності й продуктивності; 2) способу реалізації системи. Якість забезпечується шляхом перевірки зазначених у вимогах показників якості (економічність, гнучкість, здатність до зміни, модульність, правильність, надійність, переносність, ефективність). Контроль якості продукту – це перевірка відповідності заданим стандартам і вимогам. Він містить у собі дії, які дозволяють перевірити і виміряти показники якості. Висока якість продукту означає, що система конструювалася відповідно до встановлених стандартів, які полегшують процес її розроблення, супроводження та Розділ 5 105 модифікації при зміні вимог або внесенні виправлень у систему з мінімумом витрат. Ідеологія структурного проектування втілена в ряді CASE-засобів (SilverRun, Oracle Disigner, ErWin й ін.), що активно використовується на практиці. 5.1.2. Об’єктно-орієнтоване програмування У розділі 4 були розглянуті основні методи об’єктно-орієнтованого аналізу і проектування, а саме, поняття об’єкта, об’єктної та інших моделей (наприклад, інформаційної моделі, моделі станів тощо), які були запропоновані різними авторами в період бурхливого розвитку об’єктно-орієнтованої парадигми. Далі розглядаються аспекти об’єктно-орієнтованого програмування систем, а саме, операції над об’єктами та процеси ЖЦ для побудови прикладних об’єктно- орієнтованих ПС [4, 5]. Об’єктно-орієнтований метод програмування визначає стратегію побудови об’єктної системи, згідно з якою розробники системи мають мислити в термінах об'єктів, а не функцій. Об'єкт – це певна сутність, що перебуває в різних станах і має певний набір операцій. Операції, що пов’язані з об’єктом, надають іншим об’єктам послуги (сервіси) для виконання певних функцій, а їх стан залежить від значень атрибутів. Об'єкти створюються відповідно до визначення класу об’єктів, в якому описуються всі їхні атрибути й операції. Модель об’єктно-орієнтованої програмної системи можна розглядати як набір взаємодіючих об'єктів, що мають власний стан і набір операцій, які впливають на стан інших об'єктів. Об'єкти приховують інформацію про значення станів, операцій і обмежують доступ до них. Операції над об'єктами. Це такі операції: – введення, збереження, видалення об’єктів тощо, тобто це операції життєвого циклу об’єктів; – операції взаємодії об'єктів шляхом викликів методів об'єктів, визначених на множині вхідних і вихідних інтерфейсів. Інтерфейс називається вхідним, якщо об'єкт за його допомогою одержує певний сервіс, і вихідним, якщо об'єкт через нього надає цей сервіс. Кожна операція має ім'я, список вхідних параметрів і вихідних результатів, якщо вони є. Загальна форма опису операції має вигляд operation_name (param 1 ,..., param n ) returns (res 1 ,..., res m ) param i ::= parameter_name : parameter_type res i ::= result_name : result_type Іншими словами, операція являє собою структуру даних, в якій вказується набір вхідних параметрів і вихідних результатів. w: (x 1 :s 1 , x 2 :s 2 , ..., x n :s n ) (y 1 :r 1 , y 2 :r 2 , ..., y m :r m ), де w – ім'я операції; x 1 , x 2 , ..., x n – вхідні параметри, а x 1 – керуючий оператор; s 1 , s 2 , ..., s n – типи вхідних параметрів; y 1 , y 2 , ..., y m – вихідні параметри; r 1 , r 2 , ..., r m – типи вихідних параметрів. 106 Розділ 5 Основною операцією об'єкта є операція запиту, де визначені дія і список параметрів, заданих клієнтом для звернення до обслуговуючого об'єкта і отримання від нього результату. Запит виконується, якщо типи параметрів або результатів операції з ім’ям w відповідають множині вхідних і вихідних інтерфейсів. Під час виконання операції аргументи зв’язуються з формальними параметрами операції. На основі виконання операцій об'єкт здатний перебувати в різних станах. Кожний стан визначається набором атрибутів об'єкта, що задаються, і операцій, особливістю яких єполіморфізм. Операції об'єкта дозволяють одержати сервіс у об'єкта шляхом виконання певних обчислень, а потім отриманий результат надати іншим об'єктам. Зміна реалізації якого-небудь об'єкта або додавання йому нових функцій не впливає на інші об'єкти системи. Чітка відповідність між реальними об'єктами (наприклад, апаратними засобами) і керуючими об'єктами ПС полегшує розуміння і реалізацію системи за її моделлю і об'єктами. Об’єктно-орієнтована модель програмної системи створюється на таких процесах ЖЦ (рис. 5.3): Рис. 5.3. ЖЦ розробки моделі системи у середовищі ООП Етапам відповідають такі процеси: – аналіз – створення ОМ ПрО, у якій об'єкти відбивають її реальні сутності і операції над ними; – проектування – уточнення ОМ з урахуванням опису вимог для реалізації конкретних задач системи; – програмування – реалізація ОМ засобами мов програмування С++, Java та ін.; – супроводження – використання й розвиток системи шляхом внесення змін у об'єкти або в методи; – модифікація ПС в процесі її супроводження шляхом додавання нових функціональних можливостей, інтерфейсів і операцій. Наведені процеси можуть виконуватися ітераційно один за одним і з поверненням до попереднього процесу. На кожному процесі може застосовуватися та сама система нотацій. Розділ 5 107 Перехід до наступного процесу зумовлює вдосконалення результатів попереднього процесу шляхом більш детальної розробки раніше визначених класів об'єктів і додавання нових класів. Результат процесу аналізу ЖЦ – модель ПрО й набір інших моделей (модель архітектури, модель оточення й використання). Моделі відображають зв'язки між об'єктами, їхні стани та набір операцій для динамічної зміни стану інших об'єктів, а також їх відношення із навколишнім середовищем. Існує два типи моделей системної архітектури: – статична модель для опису статичної структури системи в термінах класів об'єктів і відношень між ними (узагальнення, розширення, використання, успадкування); – динамічна модель для опису динамічної структури системи і взаємодії між об'єктами (але не класами об’єктів) під час роботи системи. Об'єкти інкапсулюють інформацію про свій стан і обмежують доступ до своїх атрибутів. Моделі оточення й використання системи – це дві моделі, що взаємно доповнюючи одна одну описують зв'язок системи із середовищем. Модель оточення системи – статична модель, що описує інші підсистеми із простору розроблюваної ПС, а модель використання системи – динамічна модель, що визначає взаємодію системи зі своїм середовищем. Ця взаємодія задається послідовністю запитів до сервісів об'єктів і одержанням відповідних реакцій системи після їхнього виконання. Дані, отримані при розробці системи і визначення взаємодій з об'єктами та оточенням, використовуються при розробленні архітектури системи з об'єктів, у тому числі зі створених у попередніх підсистемах або проектах. Результат проектування у середовищі ООП – це ПС, у якій всі необхідні об'єкти створюються статично або динамічно за допомогою класів і відповідних операцій над об'єктами. Отримана об’єктно-орієнтована система перевіряється на показники якості за допомогою результатів тестування й збирання даних про помилки й відмови системи. Змінення методу створення об'єкта або додавання до нього нових операцій не впливає на інші об'єкти системи, які можуть бути повторно використані. 5.1.3. UML-метод моделювання Загальна характеристика UML (Unified Modeling Language), як підход до проектування різних систем, була дана у п. 4.2.1. Тут UML розглядається детальніше, як мова візуального моделювання систем, шляхом подання у вигляді діаграм їхніх статичних і динамічних моделей на всіх процесах ЖЦ [6, 7]. В основу методу покладено парадигму об'єктного підходу, при якій концептуальне моделювання проблеми полягає у побудові: – онтології домену, яка визначає склад та ієрархію класів об'єктів домену, їх атрибутів і взаємозв’язків, а також операцій, які можуть виконувати об'єкти класів; – моделі поведінки, яка задає можливі стани об'єктів, інцидентів, що ініціюють переходи з одного стану до іншого, а також повідомлення, якими обмінюються об'єкти; – моделі процесів, що визначає дії, які виконуються при проектуванні об'єктів як компонентів. 108 Розділ 5 Проектування в UML починається з побудови сукупності діаграм, які візуалізують основні елементи структури системи. Мова моделювання UML підтримує статичні і динамічні моделі, зокрема модель послідовностей – одну з найкорисніших і наочних моделей, в кожному вузлі якої є взаємодіючі об'єкти. Всі моделі зображаються діаграмами, коротка характеристика яких дається нижче. Діаграма класів (Class diagram) відображає онтологію домену, за змістом еквівалентна структурі інформаційної моделі методу С.Шлєєра і С.Мелора, визначає склад класів об'єктів і їх зв’язків. Діаграма задається зображенням, на якому класи позначаються поділеними на три частини прямокутниками, а зв’язки — лініями, що з’єднують прямокутники. Це відповідає візуальному зображенню понять і зв'язків між ними. Верхня частина прямокутника — обов'язкова, в ній записується ім'я класу. Друга і третя частини прямокутника визначають відповідно список операцій і атрибутів класу, що можуть мати такі специфікатори доступу: – рublic (загальний) позначає операцію або атрибут, доступ до яких здійснюється з будь-якої частини програми будь-яким об'єктом системи; – protected (захищений) позначає операцію або атрибут, доступ до яких здійснюється об'єктами того класу, в якому вони оголошені, або об’єктами класів- нащадків, – private (приватний) позначає операцію або атрибут, доступ до яких здійснюється тільки об’єктами того класу, в якому вони визначені. Користувач може визначати специфічні для нього атрибути. Під операцією розуміють сервіс, який екземпляр класу може виконувати, якщо до нього буде направлено відповідний виклик. Операція має назву і список аргументів. Для неї може також задаватися тип значення, яке вона повертає. Класи можна перебудувати в наступних відношеннях або зв'язках. Асоціація – взаємна залежність між об'єктами різних класів, кожний з яких це рівноправний її член. Вона може позначати кількість екземплярів об'єктів кожного класу, які беруть участь у зв'язку (0 – якщо жодного, 1 – якщо один, N – якщо багато). Залежність – відношення між класами, при якому клас-клієнт може використовувати певну операцію або сервіс іншого класу; класи можуть бути зв'язані відношеннями трасування, якщо один клас трансформується в іншій внаслідок виконання певного процесу ЖЦ. Екземпляризація – залежність між параметризованим абстрактним класом- шаблоном (template) і реальним класом, який ініціює параметри шаблону (наприклад, контейнерні класи мови С++). Моделювання поведінки системи. Поведінка системи визначається множиною об'єктів, що обмінюються повідомленнями, і задається діаграмами типу: послідовність, співпраця, діяльність, стан тощо. Діаграма послідовності застосовується для опису взаємодії об'єктів за допомогою сценаріїв, що відображають події, пов'язані з їх створенням і видаленням. Взаємодія об'єктів контролюється подіями, які відбуваються в сценарії і ініціюються повідомленнями до інших об'єктів. Діаграма співпраці задає поведінку сукупності об'єктів, функції яких орієнтовані на досягнення цілей системи, а також взаємозв'язку тих ролей, які Розділ 5 109 забезпечують співпрацю. Зазначимо, що діаграми послідовності та співпраці відображують одне й те саме, хоча й різними способами. Діаграма діяльностізадає поведінку системи у вигляді певних робіт, які може виконувати система або актор і ці роботи можуть залежати або від заданих умов, або від обмежень. Ця діаграма відображає функціональну структуру системи і принципи поведінки її окремих елементів під час виконання відповідної діяльності. Приклад використання діаграми діяльності UML наведено у структурі програми «Сплата послуг» (рис. 5.4). Рис. 5.4. Діаграма програми розрахунку і оплати послуг У діаграмі виконано ряд послідовних дій з розрахунку вартості послуг. Залежно від наявності боргу відбувається перехід у кінцевий стан або розділення потоків на два паралельних. У лівій гілці виконується дія «послати повідомлення про сплату» і «отримати сплату», а в правій – лише «отримати сплату». Паралельно користувач виконує роботу з виплати послуги, не чекаючи повідомлення. Паралельні потоки зливаються в один, потім знову відбувається розгалуження алгоритму – умова «сплата не отримана», «відключити послугу» і перехід в кінцевий стан. 110 Розділ 5 Діаграма станівбазується на розширеній моделі кінцевого автомата і визначає умови переходів, дії на вході й виході зі стану, а також вкладені і паралельні стани. Перехід за даними із списку ініціює деяку подію. Діаграма реалізації – це діаграма компонентів і розміщення. Діаграма компонентів слугує відображенню структури системи як композиції компонентів і зв'язків між ними. Діаграма розміщення задає склад ресурсів системи, на яких розміщуються компоненти, і відношення між ними. Побудова ПС методом UML здійснюється у наступні етапи ЖЦ (рис 5. 5.). Аналіз ПрО Визначення функцій діючих осіб Визначення об’єктів і варіантів використання Розробка специфікацій системи Проектування діаграм архітектури системи Програмування варіантів використання Розробка прототипу системи Генерація і тестування системи Готовий продукт Рис.5.5. Схема моделювання і проектування ПС в UML У UML передбачено загальний механізм організації деяких елементів системи (об'єктів, класів, підсистем і т.п.) у групи. Групування можливе починаючи від системи, далі до підсистем різного рівня деталізації і аж до класів. Результат групування називається пакетом. Пакет містить у собі назву простору імен, що займають елементи, які є його складовими, і спосіб посилання на цей простір. Це важливо для великих систем, що нараховують сотні, а іноді і тисячі елементів, і тому вимагають ієрархічного структурування. При цьому підсистема розглядається як випадок пакета, що має самостійну функцію. Пакет може складатися з інших пакетів, класів, підсистем і т.п. Об'єднання елементів у пакети може відбуватися за різними принципами, наприклад, якщо вони використовуються спільно або створені одним автором, або стосуються визначеного аспекту розгляду (наприклад, інтерфейс із користувачем, Розділ 5 111 пристрій вводу/виводу і т.п.). На стадії реалізації до одного пакета можуть бути віднесені всі підсистеми, що у діаграмі розміщення зв'язані з одним вузлом. 5.1.4. Компонентне програмування За оцінками експертів в інформаційному світі 75 % напрацювань із програмування дублюються (наприклад, програми складського обліку, нарахування зарплати, розрахунку витрат на виробництво продукції і т.п.). Більшість з цих програм типові, але кожного разу знаходяться особливості ПрО, що призводять до їх повторної розробки. Компонентне програмування дозволяє уникнути цих проблем. Воно є подальшим розвитком ООП, заснованим на повторному використанні, специфікації компонентів і їхніх інтерфейсів, композиції та конфігурації компонентів. Зв’язки між компонентами містять у собі підтипи й еквівалентність, а об'єктні зв’язки — класи і суперкласи. Сформульовано багато визначень поняття «компонент». Наведемо одне з них. Під компонентом розуміють самостійний продукт, що підтримує об'єктну парадигму, реалізує окрему предметну область і може взаємодіяти з іншими компонентами через інтерфейси. Об'єкти розглядаються на логічному рівні проектування ПС, а компоненти – це безпосередня фізична, тобто програмна реалізація об'єктів. Співвідношення між об'єктами і компонентами неоднозначне. Один компонент може бути реалізацією декількох об'єктів або навіть деякої частини системи, отриманої при проектуванні. Зворотне співвідношення, тобто компонент – об’єкт, як правило, не виконується [8–13]. Перехід до компонентів відбувався еволюційно (табл.5.1.): від підпрограм, модулів і функцій. При цьому удосконалилися елементи, методи їхньої композиції і накопичення для подальшого використання. Компоненти конструюються самостійно, як деяка абстракція, що містить у собі інформаційну частину й артефакт (специфікація, код, каркас і ін.). В інформаційній частині задаються відомості: призначення, дата виготовлення, умови застосування (ОС, середовище, платформа і т.п.). Артефакт – це реалізація (implementation), інтерфейс (interface) і схема розгортання (deployment) компонента. Реалізація – це код, що буде виконуватися при зверненні до операцій, визначених в інтерфейсах компонента. Компонент може мати кілька реалізацій залежно від операційного середовища, моделі даних, СКБД і ін. Для опису компонентів, як правило, застосовуються мови об’єктно- орієнтованого програмування, зокрем Java, у якій поняття інтерфейсу і класу – базові, використовуються в моделях Javabeans і Enterprise Javabeans і в об'єктній моделі CORBA [14]. Таблиця 5.1. Схема еволюції повторних елементів компонентного типу 112 Розділ 5 Інтерфейс відображає операції звертання до реалізації компонента, описується в мовах IDL або APL, містить у собі опис типів і операції передачі аргументів і результатів для взаємодії компонентів. Компонент, як фізична сутність, може мати множину інтерфейсів. Розгортання – це виконання фізичного файлу відповідно до конфігурації (версії), з урахуванням параметрів запуску системи. Компоненти зберігаються у вигляді класів компонентів і використовуються в компонентній моделі, композиції й у каркасі інтегрованого середовища. Керування компонентами проводиться на архітектурному або інтерфейсному рівні, між ними існує взаємний зв'язок. Компонент описується мовою програмування, не залежить від операційного середовища (наприклад, від середовища віртуальної машини Java) і від реальної платформи (наприклад, від платформ у моделі CORBA), де він буде функціонувати. |