• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Програми як системи

В контексті інженерії програмного забезпечення комп’ютерну програму доцільно розглядати конструктивно. Це можна робити зокрема за допомогою системного аналізу [56].

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

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

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

Властивість наявність зв’язків полягає в існування двох типів зв’язків: стійких зв’язків між компонентами програми (перший тип), які за своєю силою переважають зв’язки цих компонентів з компонентами, що не входять до даної програми (другий тип). Зв’язки першого типу називають зв’язувальними (cohesion). Такими зв’язками поєднуються компоненти, що містяться всередині іншого компоненту або програми. Зв’язки другого типу називають сполученими (coupling). Зв’язками останнього типу поєднуються компоненти даної програми з іншими компонентами та програмами. Мета, якої потрібно досягати під час створення програми, полягає в тому, щоб мінімізувати кількість сполучених зв’язків і зробити якомога „сильнішими” зв’язувальні зв’язки. Наявність зв’язувальних зв’язків дає підстави говорити про межу компоненту або програми (там де вони послаблюються), а отже, і про зовнішнє середовище компоненту або програми – сукупність компонентів, які не належать компоненту або програмі, але пов’язані з ними і чинять на них певний вплив. Цей вплив інтерпретується як надходження у компонент або програму вхідних значень (впливів) і отримання з компоненту або програми вихідних значень (результату) (рис. 1.2). Частину межі, скрізь яку здійснюється передача впливу і отримання результату називають інтерфейсом компоненту або програми.

Рис.1.2 Програма (компонент) і зв’язки

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

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

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

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

1.5. Класифікація програм

Існує підхід запропонований М. Леманом згідно з яким усі комп’ютерні програми можна поділити на три типи: S (Specification), P (Problem) і E (Еnvironment) [14].

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

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

Рис. 1.3 Місце S-програми в реальному світі

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

Рис. 1.4. Місце Р-програми в реальному світі

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

Е-програма – це програма, яка розв’язує таку задачу, що потребує її присутності в контексті реального світу. У процесі використання Е-програми в реальному світі становлення до неї зазвичай змінюється і постає потреба змінити програму. При цьому змінена Е-програма, так само як і Р-програма, не буде новою програмою. Прикладом такої програми являється програма керування тренажером для реального об’єкту. Місце Е-програми в реальному світи ілюструє рис. 1.5.

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

Рис. 1.5 Місце Е-програми в реальному світі

Зазвичай Рі Е програми називають програмами-застосуваннями, або комп’ютерними застосуваннями, або програмними системами.

1.6. Питання для самоперевірки

1. Поясніть загальні принципи роботи сучасної ЕОМ і наведіть структурну схему ЕОМ за Нейманом.

2. Дайте визначення програми, комп’ютерної програми.

3. Які властивості притаманні комп’ютерній програмі.

4. Що таке програмування? Хто такий програміст?

5. Дайте визначення мови програмування.

6. Які властивості має програма як система?

7. Наведіть класифікацію програм. Дайте характеристику S - P - та E-програм.

8. Що таке інтерфейс програми?

9. Як утворюється межа програми?

10. Поясність особливості двох типів зв’язків, які притаманні програмі.

11. Назвіть англійського вченого який вперше запропонував обчислювальну машину.

12. Назвіть першого програміста у світі.

13. Наведіть коли, де, і ким було створено першу ЕОМ в Європі.

14. Наведіть коли, де, і ким було створено першу ЕОМ в континентальній Європі.

15. Наведіть положення класифікування операторів О. А. Ляпуновим.

16. Назвіть першого програміста в колишньому СРСР.

17. Наведіть приклад алгоритму.

1.7. Завдання для самостійної роботи

1. Дослідить біографію Ч. Бєббіфра.

2. Дослідить біографію Ади Лівлейс.

3. Дослідить біографію Е. Ющенко.

4. Дослідить біографію К. Цузе.

5. Дослідить біографію Дж. Неймана.

6. Дослідить біографіюМ. Уилкса.

7. Дослідить біографію В. Глушкова

8. Дослідить біографію С. Лебедева

9. Опишить дії, які треба виконувати при переході вулиці на нерегулюємому перехресті.

10. Наведіть приклади S, P та E – програм.

11. На прикладі об’екту з Вашого оточення покажіть його системні властивості.

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

Як наведено раніше, перші комп’ютери, що працюють під керуванням програм, які зберігаються в пам’яті, з’явились наприкінці 1940-х – на початку 1950-х років [19,55]. Разом із ними постало нове завдання, сутність якого полягає у створенні програм, за допомогою комп’ютерів, і, відповідно, був запропонований процес, спрямований на виконання цього завдання, відомий нині як програмування. Подальший розвиток обчислювальної техніки пов'язаний не лише з удосконаленням комп’ютерів та їх розповсюдженням, а й із розвитком програмування.

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

До першого типу (прикладні програмісти) відійшли фахівці з прикладних галузей, або, як тепер кажуть, доменів (математика, фізика, економіка, освіта, інженерії), котрі писали програми мовами програмування високого рівня (FORTRAN, COBOL, PL/1), для розв’язування за допомогою комп’ютера задач, які виникали у відповідних галузях. Їх діяльність дістала назву прикладного програмування.

До другого типу (системні програмісти) відійшли фахівці, від яких не вимагалося знання доменів. Вони опікувалися автоматизацією процесів розробки програм. Системні програмісти, як правило, писали програми в машинному коді або мовою асемблера. Їхню діяльність було названо системним програмуванням.

Наприкінці 1960-х на початку 1970-х років було створено високопродуктивні (здатні виконувати близько 1 млн. операцій за секунду) обчислювальні машини, такі як БЭСМ-6 у колишньому СРСР та СТРЕТЧ у США. Із їх появою уможливилось розв’язання великих і складних задач. А це, у свою чергу, потребувало розробки великих програм, які містили від 100 тис. до 1 млн. рядків. Великі програми, що цілком природно, призвели до появи великих проблем, пов’язаних із їх створенням і використанням.

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

– супроводження програм;

– непорозуміння між розробником програм і замовником.

У 1960-ті роки внаслідок стрімкого поширення комп’ютерів дедалі більшої вимови почало набувати створення не окремих програм, а їх сукупності - програмного забезпечення. Цьому сприяло й те, що почало з’являтись багато програм (проектів), завдань з розробки, які характеризувались наступним:

– наявність замовника або ринкові ниші;

– значними розмірами та витратами;

– жорсткими вимогами до процесів реалізації та результатів;

– мілітаризацією.

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

– розроблялось дуже велике програмне забезпечення, представником якого була тоді операційна система OS360 для ЕОМ серії ІВМ. Це програмне забезпечення охоплювало понад 500 тис. операторів і створювалось значним для того часу колективом розробників (до 1000 фахівців);

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

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

– досвід розробки програмного забезпечення, який було накопичено до того часу, показував, що дедалі рідше доводилось розробляти принципово нове програмне забезпечення. Тільки 15% з усіх проектів потребували розробки „з нуля”. Решту 85% можна було віднести до повторюваних проектів. Тому актуальним стає використання досвіду, накопиченого в програмному забезпеченні. При цьому поступово ставало зрозумілим, що має використовуватися досвід не лише безпосередньо програмування у вигляді елементів програм, а й досвід щодо результатів виконання інших процесів, наприклад, проектування. Для розв’язання цієї проблеми в 1984 році було широко розгорнуто роботи з дослідження програмного забезпечення в аспекті повторного використання (reuse);

– техніки програмування та процеси, які були ефективними в 1950-х на початку 1960-х років („програмування в малому”) для розробки невеликих програм малими колективами, стали неефективними при розробці великого й складного програмного забезпечення, що містить мільйони рядків коду й потребує кількох років роботи сотень фахівців різних спеціальностей. Знадобилися нові техніки, які стали відносити до „програмування у великому”. Почали з’являтися нові процеси, що потребували певної організації (див. Таблицю 1.1).

Табл. 1.1. Техніки програмування в часі

Кроком до виходу із ситуації, що склалась, стало обговорення на конференції НАТО 1968 року (В. Ренделл, П. Наур) нової дисципліни, яку назвали інженерією програмного забезпечення (software engineering, програмна інженерія) [13]. При цьому вперше акценти в методах, засобах і процесах розробки програмного забезпечення було посунуто, по-перше, із кодування програм на інші процеси їх розробки, по-друге, із якісних аспектів у бік кількісних, інженерних. Окрім того, додаткового стимулу набули праці економічного напряму та менеджменту проектів програмного забезпечення.

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

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

Основоположною для інженерії програмного забезпечення слід вважати працю У.Ройса (Managing He Development of Large Sonle Software Systems, 1970 р.), в якій було поширено поняття життєвого циклу програмного забезпечення. Завдяки цьому стало можливим розділяти процеси, досліджувати окремі процеси, розробляти ресурси фаз життєвого циклу, а продукти фаз будувати як відповідні результати. У цій праці поряд з відомими на той час двома етапами – аналізом і кодуванням, вводяться нові, „понаднормативні” етапи. Зазначається, що лише на етапі тестування з’ясовується реальний час роботи системи, обсяг пам’яті, швидкість вводу/виводу та інші кількісні параметри. Наголошується на первинності проектних рішень і необхідність документування проекту.

2.1. Продукти, продукція та програмне забезпечення

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

2.1.1. Продукти інженерії програмного забезпечення

Стандарт ISO/IEC 14598-1 визначає продукт інженерії програмного забезпечення (продукт програмного забезпечення, програмний продукт, software product), як множину комп’ютерних програм, процедур і пов’язаних із ними документації та даних. При цьому наголошується, що продукти можуть бути таких типів:

– призначені для поставляння користувачеві;

– інтегральні частини інших продуктів;

– призначені для розробників і тих, хто забезпечує супроводження.

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

– користувач (user) – особа (фізична чи юридична), яка застосовує продукт для виконання своїх специфічних функцій у тому чи іншому домені;

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

– супроводжувач (maintainer) – особа (фізична чи юридична), яка виконує специфічні дії, пов’язані із супроводженням продукту.

Український стандарт ДСТУ 2844-94 визначає продукт інженерії програмного забезпечення як програмний засіб (програмне забезпечення, software), призначений для поставляння користувачеві. Якщо розглядати користувачів зазначених трьох типів (користувач, розробник, супроводжувач), то це визначення збігається з визначенням ISO/IEC.

Отже, термін „продукт програмного забезпечення” вживається для позначення двох типів об’єктів:

– по-перше, так називають комп’ютерні програми, які задовольняють додаткові вимоги, пов’язані з їх тривалим застосуванням користувачами, які не належать до розробників та супроводжувачів комп’ютерних програм. Ці вимоги задовольняються, наприклад, завдяки створенню додаткових описів, інструкцій і даних. Продуктами цього типу, наприклад, є програмне забезпечення Windows 7, MS Office 2007, або IBM Rationale;

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

2.1.2. Продукція інженерії програмного забезпечення

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

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

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

Читайте також:

1. I. Органи і системи, що забезпечують функцію виділення
2. I. Особливості аферентних і еферентних шляхів вегетативного і соматичного відділів нервової системи
3. II. Анатомічний склад лімфатичної системи
4. II. Вимоги до складання паспорта бюджетної програми
5. IV. Розподіл нервової системи
6. IV. Система зв’язків всередині центральної нервової системи
7. IV. Філогенез кровоносної системи
8. POS-системи
9. VI. Філогенез нервової системи
10. Автокореляційна характеристика системи
11. АВТОМАТИЗОВАНІ СИСТЕМИ ДИСПЕТЧЕРСЬКОГО УПРАВЛІННЯ
12. АВТОМАТИЗОВАНІ СИСТЕМИ УПРАВЛІННЯ ДОРОЖНІМ РУХОМ

Переглядів: 2170