загрузка...
загрузка...
На головну

Об'єктний підхід до розробки програмних систем

  1. Barebone-системи
  2. C) вставте підходящого змісту слово або словосполучення
  3. C) дається приклад країни, успішно поєднати у своїй правовій системі ознаки романо-германський системи права із загальним правом.
  4. CASE-технологія створення інформаційних систем
  5. CASE-технологія створення інформаційних систем.
  6. D) тріщинуваті - дві системи тріщин з відстанню між тріщинами більше 1,5
  7. DNS - система доменних імен

Трохи історії. Термін «об'єкт» з'явився практично незалежно в різних областях, пов'язаних з комп'ютерами, і майже одночасно на початку 70-х років для позначення того, що може мати різні прояви, залишаючись цілісним. Об'єктами називалися компоненти системи або фрагменти подаються знань [38]. [11]

Об'єктно-орієнтований підхід був пов'язаний з наступними подіями:

u прогрес в області архітектури ЕОМ (створення комп'ютерів з descriptor-based і capability-based архітектурою);

u розвиток об'єктно-орієнтованих мов програмування, таких як Simula, Smalltalk, CLU, Ada;

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

Базовими принципами об'єктно-орієнтованої технологія є:

u абстрагування;

u інкапсуляція;

u модульність;

u ієрархічність.

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

u типізація;

u паралелізм;

u збереженість.

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

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

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

У ООП виділяють кілька видів абстракцій:

 абстракція суті  Об'єкт являє собою корисну модель якоїсь сутності в предметної області
 абстракція поведінки  Об'єкт складається з узагальненого безлічі операцій
 Абстракція віртуальної машини  Об'єкт групує операції, які можуть бути надіслані разом використовуються більш високим рівнем управління, або самі використовують деякий набір операцій більш низького рівня
 довільна абстракція  Об'єкт включає в себе набір операцій, які не мають між собою нічого спільного

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

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

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

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

1. Особливості системи, схильні до змін, слід приховувати в окремих модулях; як міжмодульних можна використовувати тільки ті елементи, ймовірність зміни яких мала.

2. Всі структури даних повинні бути відокремлені в модулі; доступ до них буде можливий для всіх процедур цього модуля і закритий для всіх інших. Доступ до даних з модуля повинен здійснюватися тільки через процедури даного модуля [31].

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

Таким чином, принципи абстрагування, інкапсуляції та модульності є взаємодоповнюючими.

поняття типу взято з теорії абстрактних типів даних. Типізація дозволяє захиститися від використання об'єктів одного класу замість іншого. У різних мовах програмування реалізовані різні механізми типізації, від слабкої (С ++) до сильної (Object Pascal), а в деяких такий механізм відсутній (Smalltalk).

Мови, в яких типізація відсутня, мають більшу гнучкість. Але на практиці, особливо при програмуванні «у великому», надійність мов зі строгою типізацією з лишком компенсує деяку втрату в гнучкості.

Примітка: Теслер зазначив наступні важливі переваги строго типізованих мов:

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

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

· Оголошення типів покращує документування програм.

· Багато компілятори генерують більш ефективний об'єктний код, якщо їм явно відомі типи »[37].

В об'єктно-орієнтованих мовах паралелізм досягається за рахунок механізму багатопоточності (процесів управління) і наявності переривань, при цьому головна увага приділяється абстрагування і синхронізації процесів. В даний час існує цілий клас мов, орієнтованих на паралельні обчислення (Ada, Modula-2, Occam).

І, нарешті, кілька слів про зберігання. Вона передбачає, що під час обчислень необхідно зберігати проміжні дані і / або об'єкти в часі. Більшість мов програмування не має вбудованих засобів для цього (хорошим винятком є ??лише мову Smalltalk), тому, як правило, збереженість досягається за рахунок застосування СУБД, багато з яких вбудовані в оболонку інтегрованих засобів розробки ПС.

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


Контрольні запитання до розділу 2:

1. Перерахуйте основні особливості розробки програмних систем.

2. Які корінні зміни відбулися в програмної інженерії за останній час?

3. У чому полягають принципові зміни, що відбулися в методології програмування?

4. Перерахуйте основні показники якості програмних систем.

5. Що таке надійність програмного забезпечення? Які складові частини її визначають?

6. У чому відмінність налагодження від тестування?

7. У чому полягає складність програмних систем? Перерахуйте ознаки складних програмних систем.

8. Що таке абстракція і абстрагування? Наведіть приклади абстракцій в об'єктно-орієнтованому програмуванні.

9. У чому полягає принцип покрокової деталізації?

10. Що таке декомпозиція? Де вона застосовується? Наведіть приклади.

11. У чому полягає структурний підхід до розробки програмних систем? Перерахуйте основні принципи методології структурного проектування.

12. У чому полягає об'єктний підхід до розробки програмних систем? Перерахуйте базові принципи методології об'єктно-орієнтованого проектування.


3 життєвий цикл програмних систем

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

Вперше про життєвий цикл ПО заговорили в 1968 р в Лондоні, де відбулася зустріч 22 керівників проектів з розробки ПЗ. На зустрічі аналізувалися проблеми і перспективи проектування, розробки, поширення і підтримки програм. Було відзначено, що застосовуються принципи і методи розробки ПЗ вимагали постійного вдосконалення. Саме на цій зустрічі була запропонована концепція життєвого циклу програмного забезпечення (SLC - Software Lifetime Cycle) Як послідовності кроків-стадій, які необхідно виконати в процесі створення і експлуатації ПЗ. В даний час вона стала методологічною основою промислової інженерії.

Отже, життєвий цикл промислового вироби - це послідовність етапів (фаз, стадій):

§ проектування;

§ виготовлення зразка;

§ організація виробництва;

§ серійне виробництво;

§ експлуатація;

§ ремонт;

§ виведення з експлуатації,

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

3.1 Стандарти та проблеми життєвого циклу ПО

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

Розглянемо поняття стандартизація і сертифікація більш детально, т. К. Багато початківці програмісти ці поняття змішують.

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

Наприклад: ГОСТ ЕСПД - єдина система програмної документації - документи, що описують склад і структуру документації на розробку програм для ЕОМ (загальний опис, технічне завдання, ескізний проект, технічний проект, опис застосування). Типові зразки - еталони мір і ваг (еталон метра, що зберігається в Парижі в палаті мір і ваг).

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

Сертифікація в перекладі з латині означає «зроблено вірно». Для того щоб переконатися в тому, що продукт «зроблений вірно», треба знати, яким вимогам він повинен відповідати, і яким чином можливо отримати достовірні докази цієї відповідності. Загальновизнаним способом такого докази служить сертифікація відповідності, яка передбачає обов'язкову участь третьої сторони, здійснюється за правилами певної процедури, що включає обов'язкові випробування на відповідність стандарту.

В даний час прийнято виділяти такі основні типи стандартів:

O Корпоративні стандартиразрабативаются великими фірмами (корпораціями) з метою підвищення якості своєї продукції. Такі стандарти розробляються на основі власного досвіду і з урахуванням вимог світових стандартів. Корпоративні стандарти не сертифікуються, але є обов'язковими для застосування всередині корпорації. В умовах ринкової конкуренції можуть мати закритий характер. У сфері інформаційних технологій відомі стандарти, розроблені Microsoft, Intel, IBM.

O Галузеві стандартидействуют в межах організацій деякої галузі (міністерства). Наприклад, СНИП - будівельні норми і правила. Розробляються з урахуванням вимог світового досвіду та специфіки галузі. Є, як правило, обов'язковими для галузі. Підлягають сертифікації.

O Державні стандарти (ГОСТи) приймаються державними органами, мають силу закону. Розробляються з урахуванням світового досвіду або на основі галузевих стандартів. Можуть мати як рекомендаційний, так і обов'язковий характер (стандарти безпеки). Для сертифікації створюються державні або ліцензовані органи сертифікації.

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

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

u 1985 р (Уточнений в 1988 р) DOD-STD-2167 А - Розробка програмних засобів для систем військового призначення. Перший формалізований і затверджений стандарт життєвого циклу для проектування ПС систем військового призначення на замовлення Міністерства оборони США. Цим документом регламентовано вісім фаз (етапів) при створенні складних критичних ПС і близько 250 типових обов'язкових вимог до процесів і об'єктів проектування на цих етапах.

u 1994 р MIL-STD-498. Розробка і документування програмного забезпечення. Прийнято Міністерством оборони США для заміни DOD-STD-2167 A і ряду інших стандартів. Він призначений для застосування всіма організаціями і підприємствами, які отримують замовлення Міністерства оборони США. Стандарт містить рекомендації щодо забезпечення і реалізації процесів ЖЦ складних критичних ПС високої якості і надійності, що функціонують в реальному часі (описано близько 75 процесів).

u 1995 р IEEE 1074. Процеси ЖЦ для розвитку програмного забезпечення. Охоплює повний життєвий цикл ПС, в якому виділяються шість великих базових процесів, які деталізуються 16 приватними процесами (деталізуються в сукупності 65 процесів-робіт). Зміст кожного приватного процесу починається з опису його загальних функцій і завдань та переліку дій - робіт при подальшій деталізації. Для кожного процесу в стандарті представлена вхідні і результуюча інформація про його виконання і короткий опис суті процесу. У стандарті увага зосереджена переважно на безпосередньому створенні ПС і на процесах попереднього проектування. У додатку подано варіанти адаптації максимального складу компонентів ЖЦ ПС до конкретних особливостей типових проектів.

Розробка стандартів ЖЦ і їх практичне застосування стикалися з низкою проблем:

· Впровадження стандартів вимагало вкладення значних коштів, що не завжди окупалося;

· Було неясно, чи всі необхідні процеси треба виконувати і якою мірою;

· Для різних типів ПО (інформаційні системи, системи реального часу, бізнес системи) наводилися різні вимоги;

· Висока динаміка галузі приводила до швидкого старіння стандартів;

· В різних корпоративних стандартах була термінологічна неоднозначність;

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

Вирішенням проблем стандартизації ЖЦ ПО є розробка і прийняття в 1995 р стандарту ISO / IEC 12207: «Information Technology - Software Life Cycle Processes» [12]. У 2000 р він був прийнятий в Росії як «ГОСТ 12207. Процеси життєвого циклу програмних засобів» [29].

Стандарт ISO 12207 розроблявся з урахуванням кращого світового досвіду на основі перерахованих вище стандартів. Основними результатами даного стандарту є:

§ введення єдиної термінології по розробці і застосуванню ПЗ (стандарт призначений не тільки для розробників, але і для замовників, користувачів, всіх зацікавлених осіб);

§ поділ понять життєвого циклу ПО і моделіЖЦ ПО (сам життєвий цикл визначається як повна сукупність всіх процесів і дій по створенню та застосуванню ПЗ, а модель ЖЦ - як конкретний варіант організації ЖЦ, обгрунтовано обраний для кожного конкретного випадку);

§ опис організації ЖЦ і його структури (Процесів);

§ виділення процесу адаптації стандарту для побудови конкретних моделей ЖЦ.

3.2 Життєвий цикл і етапи розробки програмного забезпечення

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

Процес (process) - набір взаємозв'язаних робіт, які перетворять вихідні дані у вихідні результати.

Стандарт ISO 12207 визначає організацію ЖЦ програмного продукту як сукупність процесів, кожний з яких розбитий на дії, що складаються з окремих завдань. Відповідно до нього всі процеси ЖЦ діляться на три групи (рисунок 14):

O основні;

O допоміжні;

O організаційні.

 
 


Окремо описаний процес адаптації стандарту, який містить основні роботи, які повинні бути виконані при адаптації цього стандарту до умов конкретного програмного проекту.

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

O замовлення. визначає роботи замовника, Тобто організації, яка набуває систему, програмний продукт або програмну послугу.

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

O Розробка. визначає роботи розробника, Тобто організації, яка проектує і розробляє програмний продукт.

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

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

допоміжними процесамиє:

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

O управління конфігурацією. визначає роботи по управлінню конфігурацією.

O Забезпечення якості. визначає роботи по об'єктивного забезпечення того, щоб програмні продукти і процеси відповідали вимогам, встановленим для них, і реалізовувалися в рамках затверджених планів. Спільні аналізи, аудиторські перевірки, верифікація та атестація можуть використовуватися в якості методів забезпечення якості.

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


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

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

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

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

O Вирішення проблем. визначає процес аналізу та усунення проблем (Включаючи невідповідності), незалежно від їх характеру і джерела, які були виявлені під час здійснення розробки, експлуатації, супроводу або інших процесів.

організаційними процесами є:

O управління. визначає основні роботи з управління, Включаючи управління проектом, при реалізації процесів життєвого циклу.

O створення інфраструктури. визначає основні роботи по створенню Основний структури процесу життєвого циклу.

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

O навчання. визначає роботи по відповідному навчання персоналу.

Примітка: Стандарт ISO 12207 розроблявся 9 років і досить швидко застарів. У 1998р. виходить новий стандарт ISO / IEC TR 15504: «Information Technology - Software Process Assessment (Оцінка процесів розробки ПЗ)». У цьому документі розглядаються питання атестації, визначення зрілості і вдосконалення процесів життєвого циклу ПЗ. Один з розділів документа містить нову класифікацію процесів життєвого циклу: базовий; розширений; новий; що становить; розширений становить, - що є розвитком стандарту ISO 12207.

Відповідно до нової класифікації в трьох групах процесів вводяться п'ять категорій процесів:

O основні процеси:

§ CUS: Споживач-постачальник (придбання, поставка, експлуатація);

§ ENG: Інженерна (розробка, супровід);

O допоміжні процеси:

§ SUP: Допоміжна (аналогічно ISO 12207);

O організаційні процеси:

§ MAN: Управлінська (адміністративне управління, управління проектами, управління якістю, управління ризиками);

§ ORG: Організаційна (організаційні установки, удосконалення (створення, атестація, удосконалення), адміністративне управління кадрами, створення інфраструктури, вимір, повторне використання).

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




Л. С. Зеленко | Каскадна модель розробки ПЗ | Спіральна модель розробки ПЗ | Інші типи моделей життєвого типу | Технологія швидкої розробки додатків RAD | ТЕХНОЛОГІЇ ПРОГРАМУВАННЯ І ПРОГРАМНА ІНЖЕНЕРІЯ |

загрузка...
© um.co.ua - учбові матеріали та реферати