Основи програмної інженерії

Содержание

Слайд 2

Основи програмної інженерії Зміст Поняття програмної інженерії. SWEBOK – простір знань

Основи програмної інженерії

Зміст

Поняття програмної інженерії. SWEBOK – простір знань програмної інженерії
Моделювання

у програмній інженерії
Життєвий цикл ПС. Моделі життєвого циклу ПС
Ітеративно-інкрементні моделі життєвого циклу
Керування ризиками
Поняття програмної архітектури
Слайд 3

Основи програмної інженерії Поняття програмної інженерії Термін програмна інженерія (Software Engineering)

Основи програмної інженерії

Поняття програмної інженерії

Термін програмна інженерія (Software Engineering) почав вживатись

з 1968 року, що засвідчило перехід до розробки програмного забезпечення (ПЗ) чи програмних систем (ПС) на інженерній основі.
Програмна інженерія
вивчає питання, пов'язані з розробкою та використанням ПЗ на інженерній основі (систематичність, дисциплінованість, можливість деталізації), охоплюючи всі етапи життєвого циклу;
узагальнює дослідження й досвід у вигляді комплексів знань та правил, що регламентують діяльність по створенню ПС.
____________________________________________________________
Naur, P. Randell, B, Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968, Naur, P., Randell, B., eds., 1969.

Інженерний підхід + знання

Слайд 4

Основи програмної інженерії SWEBOK – простір знань програмної інженерії SWEBOK -

Основи програмної інженерії

SWEBOK – простір знань програмної інженерії

SWEBOK - Software Engineering

Body of Knowledge (Last Version 2007) - Проект IEEE Computer Society www.swebok.org
WHAT IS SOFTWARE ENGINEERING?
The IEEE Computer Society defines software engineering as
“ (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
(2) The study of approaches as in (1).”
The Body of Knowledge is subdivided into ten software engineering Knowledge Areas (KA) plus an additional chapter providing an overview of the KAs of strongly related disciplines.

Institute of Electrical and Electronics Engineers - IEEE (read eye-triple-e) is an international non-profit, professional organization for the advancement of technology

Слайд 5

Основи програмної інженерії SWEBOK – простір знань програмної інженерії www.swebok.org

Основи програмної інженерії

SWEBOK – простір знань програмної інженерії

www.swebok.org

Слайд 6

Основи програмної інженерії Wikipedia - the free encyclopedia that anyone can edit

Основи програмної інженерії

Wikipedia - the free encyclopedia that anyone can edit

Слайд 7

Основи програмної інженерії Википедия - свободная энциклопедия, которую может редактировать каждый

Основи програмної інженерії

Википедия - свободная энциклопедия, которую может редактировать каждый

Слайд 8

Основи програмної інженерії The SWEBOK Knowledge Areas (KAs) Software requirements Software

Основи програмної інженерії

The SWEBOK Knowledge Areas (KAs)

Software requirements
Software design
Software construction
Software testing
Software

maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering tools and methods
Software quality
Слайд 9

Основи програмної інженерії Related disciplines Computer engineering Computer science Management Mathematics

Основи програмної інженерії

Related disciplines

Computer engineering
Computer science
Management
Mathematics
Project management
Quality management
Software

ergonomics
Systems engineering
Слайд 10

Основи програмної інженерії Guide to the SWEBOK

Основи програмної інженерії

Guide to the SWEBOK

Слайд 11

Основи програмної інженерії Приклад Knowledge Area - Software design

Основи програмної інженерії

Приклад Knowledge Area - Software design

Слайд 12

Основи програмної інженерії Architectural styles (macroarchitectural patterns) An architectural style is

Основи програмної інженерії

Architectural styles (macroarchitectural patterns)

An architectural style is “a set

of constraints on an architecture [that] defines a set or family of architectures that satisfies them” [Bas03:c2]. An architectural style can thus be seen as a meta-model which can provide software’s high-level organization (its macroarchitecture). Various authors have identified a number of major architectural styles. [Bas03:c5; Boo99:c28; Bos00:c6; Bus96:c1,c6; Pfl01:c5]
General structure (for example, layers, pipes, and filters, blackboard)
Distributed systems (for example, client-server, three-tiers, broker)
Interactive systems (for example, Model-View-Controller, Presentation-Abstraction-Control)
Adaptable systems (for example, micro-kernel, reflection)
Others (for example, batch, interpreters, process control, rule-based).
Слайд 13

Основи програмної інженерії Design Patterns (microarchitectural patterns) Succinctly described, a pattern

Основи програмної інженерії

Design Patterns (microarchitectural patterns)

Succinctly described, a pattern is “a

common solution to a common problem in a given context.” (Jac99) While architectural styles can be viewed as patterns describing the high-level organization of software (their macroarchitecture), other design patterns can be used to describe details at a lower, more local level (their microarchitecture). [Bas98:c13; Boo99:c28; Bus96:c1; Mar02:DP]
Creational patterns (for example, builder, factory, prototype, and singleton)
Structural patterns (for example, adapter, bridge, composite, decorator, façade, flyweight, and proxy)
Behavioral patterns (for example, command, inter-preter, iterator, mediator, memento, observer, state, strategy, template, visitor)
Слайд 14

Основи програмної інженерії edX

Основи програмної інженерії

edX

Слайд 15

Основи програмної інженерії edX

Основи програмної інженерії

edX

Слайд 16

Основи програмної інженерії edX

Основи програмної інженерії

edX

Слайд 17

Основи програмної інженерії edX

Основи програмної інженерії

edX

Слайд 18

Основи програмної інженерії Udacity

Основи програмної інженерії

Udacity

Слайд 19

Основи програмної інженерії Habrahabr: Coursera vs Udacity

Основи програмної інженерії

Habrahabr: Coursera vs Udacity

Слайд 20

Основи програмної інженерії YouTube. Edu

Основи програмної інженерії

YouTube. Edu

Слайд 21

Основи програмної інженерії Techdays

Основи програмної інженерії

Techdays

Слайд 22

Основи програмної інженерії Intuit.ru

Основи програмної інженерії

Intuit.ru

Слайд 23

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

Основи програмної інженерії

Моделювання у програмній інженерії

Існує багато аспектів, пов'язаних з

успішною розробкою програмних проектів, і одним з головних є моделювання. І не випадково, загалом, моделювання – загальноприйнята в інженерії методика.
Модель – це спрощене відображення дійсності, при цьому важливо, щоб модель M надавала певну уяву про об’єкт моделювання A:
"M моделює A, якщо M дозволяє отримувати відповіді на питання стосовно різноманітних властивостей A".
Чим більша й складніша система, тим важче її "охопити" у цілому, а, отже, тим важливіше моделювання.
Розвиток засобів CASE (Computer Aided Software Engineering), що підтримують моделювання ПС.
Моделі
програмних систем;
архітектури ПС;
життєвого циклу.
Слайд 24

Основи програмної інженерії Основні принципи моделювання ПС Принцип абстрагування. Система представляється

Основи програмної інженерії

Основні принципи моделювання ПС

Принцип абстрагування. Система представляється моделлю, що

відповідає певному рівню абстракції. Вибір моделі (вибір певного рівня абстракції) визначає те, як будуть осмислюватися проблеми реалізації і які рішення будуть прийматися;
Принцип візуальності. Моделі повинні забезпечувати можливість одержувати візуалізоване відображення системи (“одна діаграма може замінити 100 сторінок тексту”);
Принцип багатомодельності. Не слід обмежуватися єдиною моделлю, якщо система досить нетривіальна. Найкраще використовувати сукупність моделей, що незалежні одна від одної або, іншими словами, що задають різні подання системи.
Принцип ієрархічності (ієрархічної побудови моделей). Цей принцип обумовлює можливість розробляти моделі у відповідності до різних рівнів конкретизації (абстрагування).
Принцип еволюційності. Як правило, якісна модель системи не є результатом одного акту створення, а отримується шляхом послідовних (еволюційних) уточнень.
Слайд 25

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

Основи програмної інженерії

У цілому, модель розробляється для того, щоб краще зрозуміти,

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

Призначення моделей ПС

Слайд 26

Основи програмної інженерії Життєвий цикл ПС Неоднорідність (та повторюваність із проекту

Основи програмної інженерії

Життєвий цикл ПС

Неоднорідність (та повторюваність із проекту в проект)

робіт, виконуваних при розробці ПС, залежність цих робіт одна від одної, нарешті, колективний характер їх виконання — ось підстави для поетапної організації розвитку ПС, а отже, підстави для виділення окремих етапів у життєвому циклі (ЖЦ) ПС.
Термін життєвий цикл ПС є фактично запозиченим із традиційних галузей промислового виробництва, де давно використовується поняття життєвого циклу матеріального продукту (не даремно фермери віддають перевагу більш дорогим канадським комбайнам).
Життєвий цикл — це проекція поняття користувача “час життя” на поняття розробника “технологічний цикл (цикл розробки)”. Саме комбінацією цих понять пояснюється походження самого терміну “життєвий цикл”.
Розвиток концепцій життєвого циклу пов'язаний із пошуком адекватних моделей для нього. Багатогранність призначень моделювання визначає різноманітність моделей.
Слайд 27

Основи програмної інженерії Моделі життєвого циклу ПС Найчастіше виділяють наступні п'ять

Основи програмної інженерії

Моделі життєвого циклу ПС

Найчастіше виділяють наступні п'ять основних етапів

ЖЦ:
аналіз і формалізація вимог замовника;
проектування;
реалізація й тестування;
упровадження;
супровід.
Іноді виділяють як етапи:
аналіз вимог,
проектування,
кодування (програмування),
тестування й налагодження,
експлуатація й супровід.
Часто можна зустріти виділену окремим етапом інтеграцію.
Головна особливість індустрії ПЗ складається в концентрації уваги на початкових етапах ЖЦ (аналіз, проектування): невирішені питання й помилки, допущені на етапах аналізу й проектування, породжують на наступних етапах важкі, часто нерозв'язні проблеми і, у кінцевому рахунку, призводять до невдачі всього проекту.
Слайд 28

Основи програмної інженерії Модель послідовного типу (каскадна, водоспад)

Основи програмної інженерії

Модель послідовного типу (каскадна, водоспад)

Слайд 29

Основи програмної інженерії Модель послідовного типу (каскадна, водоспад)

Основи програмної інженерії

Модель послідовного типу (каскадна, водоспад)

Слайд 30

Основи програмної інженерії Абстрактна схема ЖЦ Microsoft Solution Framework

Основи програмної інженерії

Абстрактна схема ЖЦ Microsoft Solution Framework

Слайд 31

Основи програмної інженерії Умови застосування послідовної моделі життєвого циклу Послідовна модель

Основи програмної інженерії

Умови застосування послідовної моделі життєвого циклу

Послідовна модель може застосовуватись,

коли:
вимоги до ПС
(1) чітко визначені;
(2) надалі не змінюються;
є досить великий досвід реалізації подібного роду систем.
Реалізація проекту за даним типом моделі ЖЦ легко планується й контролюється.
Програмістський фольклор про вимоги до ПС:
(1) Теза-жарт: “Замовник щось хоче, але точно не знає, що саме він хоче”.
(2) У житті є лише три речі, які людині не підвладні:
неминучість смерті;
необхідність сплачувати податки;
змінюваність вимог до ПС.
Слайд 32

Основи програмної інженерії Реалії розробки більшості ПС

Основи програмної інженерії

Реалії розробки більшості ПС

Слайд 33

Основи програмної інженерії Реалії розробки більшості ПС (каскадна модель)

Основи програмної інженерії

Реалії розробки більшості ПС (каскадна модель)

Слайд 34

Основи програмної інженерії Модифікована каскадна модель За рахунок жорсткості перевірок можна

Основи програмної інженерії

Модифікована каскадна модель

За рахунок жорсткості перевірок можна позбавитись прямих

відкатів на кілька етапів.
Слайд 35

Основи програмної інженерії Календарний план (КП) як модель життєвого циклу ПС

Основи програмної інженерії

Календарний план (КП) як модель життєвого циклу ПС

КП —

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

Основи програмної інженерії Модель Гантера “фази — функції” Надзвичайно важливим мотивом

Основи програмної інженерії

Модель Гантера “фази — функції”

Надзвичайно важливим мотивом розвитку моделей

життєвого циклу програмного забезпечення є потреба в придатному засобі для керування проектом (зокрема, для підтримки функцій менеджера).
Для цього використовується накладення на модель не тільки контрольних точок (вони задають організаційно-часові рамки проекту), але і так званих виробничих функцій, виконуваних протягом розвитку проекту.
Найбільше послідовно таке доповнення класичної схеми реалізовано в моделі Гантера (1981) у вигляді двох вимірів (або, якще кажуть, у вигляді матриці) “фази - функції”:
фазовий вимір, що відображає етапи виконання проекту і супутні їм події;
функціональний вимір, що показує, які виробничі функції виконуються в ході розвитку проекту та яка їх інтенсивність на кожному з етапів.
Слайд 37

Основи програмної інженерії Фазовий вимір моделі “фази – функції”

Основи програмної інженерії

Фазовий вимір моделі “фази – функції”

Слайд 38

Основи програмної інженерії Функціональний вимір моделі “фази – функції” Перелік (варіантний!)

Основи програмної інженерії

Функціональний вимір моделі “фази – функції”

Перелік (варіантний!) функцій:
Планування
Розробка
Обслуговування


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

Основи програмної інженерії Модель Гантера “фази — функції”

Основи програмної інженерії

Модель Гантера “фази — функції”

Слайд 40

Основи програмної інженерії “Розробляйте ітеративно!”- одна з порад Г.Буча. Переваги такого

Основи програмної інженерії

“Розробляйте ітеративно!”- одна з порад Г.Буча. Переваги такого підходу (1/2)

Урахування

змінюваності вимог. (Зміни, “повзучість”, “дрейф” вимог є першоджерелами невдач проектів, оскільки призводять до порушень планів, запізнень і навіть повного “провалу” проектів.)
Використання зворотного зв’язку із користувачами та замовниками з метою виявлення справжніх вимог.
Неперервна інтеграція, а не “вибух” проблем інтеграції як при “водоспаді”.
Пом’якшення наслідків від реалізації ризиків.
Можливість розробникам накопичувати досвід, навчатись.
Слайд 41

Основи програмної інженерії Сприяння виробленню стійкої архітектури (слабкі місця виявляються вже

Основи програмної інженерії

Сприяння виробленню стійкої архітектури (слабкі місця виявляються вже на

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

“Розробляйте ітеративно!”- одна з порад Г.Буча. Переваги такого підходу (2/2)

Слайд 42

Основи програмної інженерії Перехід до ітеративних (ітеративно-інкрементних) моделей ЖЦ Ілюстрація проста,

Основи програмної інженерії

Перехід до ітеративних (ітеративно-інкрементних) моделей ЖЦ

Ілюстрація проста, але з'являються

нові питання:
Як визначати, що саме має реалізовуватись у кожній з ітерацій?
Як гарантувати цілеспрямованість та, зокрема, завершуваність процесу створення ПС?
Слайд 43

Основи програмної інженерії До проблеми ризиків інтеграції

Основи програмної інженерії

До проблеми ризиків інтеграції

Слайд 44

Основи програмної інженерії Ітеративна модель ЖЦ

Основи програмної інженерії

Ітеративна модель ЖЦ

Слайд 45

Основи програмної інженерії Ітеративна модель ЖЦ

Основи програмної інженерії

Ітеративна модель ЖЦ

Слайд 46

Основи програмної інженерії Ітеративна модель ЖЦ

Основи програмної інженерії

Ітеративна модель ЖЦ

Слайд 47

Основи програмної інженерії Моделі еволюційного типу. Інкрементність та ітераційність моделей ЖЦ (“спіраль охоплення предметної області” )

Основи програмної інженерії

Моделі еволюційного типу. Інкрементність та ітераційність моделей ЖЦ (“спіраль

охоплення предметної області” )
Слайд 48

Основи програмної інженерії Інструментальна спіраль Боема

Основи програмної інженерії

Інструментальна спіраль Боема

Слайд 49

Основи програмної інженерії “Модифікована” модель фази-функції

Основи програмної інженерії

“Модифікована” модель фази-функції

Слайд 50

Основи програмної інженерії Технологічні аспекти у моделях ЖЦ (можливість одночасного виконання різних ітерацій)

Основи програмної інженерії

Технологічні аспекти у моделях ЖЦ (можливість одночасного виконання різних

ітерацій)
Слайд 51

Основи програмної інженерії Технологічні аспекти у моделях ЖЦ (можливість одно-часного виконання різних ітерацій). Спіраль розвитку

Основи програмної інженерії

Технологічні аспекти у моделях ЖЦ (можливість одно-часного виконання різних

ітерацій). Спіраль розвитку
Слайд 52

Основи програмної інженерії Застосування еволюційних моделей ЖЦ Цей тип моделей ЖЦ

Основи програмної інженерії

Застосування еволюційних моделей ЖЦ

Цей тип моделей ЖЦ може

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

Основи програмної інженерії Зрушення графіка постачання – у день передбачуваного постачання

Основи програмної інженерії
Зрушення графіка постачання – у день передбачуваного постачання ви

повідомляєте замовника, що програмне забезпечення буде готовим не раніше ніж через 6 місяців.
Проект закрито – після численних зрушень проект закривається, навіть не передаючи його у виробництво.
Система “прокисла” - програмне забезпечення було успішно передане у виробництво, але через пару років вартість змін і кількість помилок настільки зросли, що система повинна бути заміщена.
Інтенсивність дефектів – систему передано у виробництво, але кількість дефектів настільки велика, що систему не можливо використовувати.
Нерозуміння вимог бізнесу – програмне забезпечення передане у виробництво, але воно не вирішує тих задач, що були поставлені спочатку.
Зміни вимог бізнесу – програмне забезпечення було передане у виробництво, але вимоги, заради яких воно розроблялось, 6 місяців тому замінили іншими, більш актуальними.
Наявність неактуальних можливостей – програмне забезпечення має цілий ряд цікавих можливостей, не потрібних замовнику (не приносять йому грошей).
Плинність кадрів – через два роки роботи над проектом усі досвідчені програмісти починають ненавидіти розроблювану програму і йдуть із фірми.

Деякі приклади ризиків

Слайд 54

Основи програмної інженерії Два виміри процесу розробки ПС із позицій Rational

Основи програмної інженерії

Два виміри процесу розробки ПС із позицій Rational Unified

Process

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

Слайд 55

Основи програмної інженерії Два виміри процесу розробки ПС із позицій Rational Unified Process

Основи програмної інженерії

Два виміри процесу розробки ПС із позицій Rational Unified

Process
Слайд 56

Основи програмної інженерії Динамічний аспект RUP. Чотири стадії (фази), чотири віхи

Основи програмної інженерії

Динамічний аспект RUP. Чотири стадії (фази), чотири віхи RUP

Перша

фаза – фаза задуму (або початку) – завершується віхою “Вимоги життєвого циклу”. (Віха LCO – lifecycle objective).
Друга фаза – фаза уточнення завершується віхою “Архітектура життєвого циклу”. (Віха LCA – lifecycle architecture).
Третя фаза – фаза конструювання (або реалізації) завершується віхою “Початкова працездатність”. (Віха IOC – initial operational capabiliny).
Четверта фаза – фаза переходу (або передачі, розгортання) завершується віхою “Випуск продукту”. (Віха PR – product release).
Слайд 57

Основи програмної інженерії Два виміри процесу розробки ПС із позицій Rational Unified Process

Основи програмної інженерії

Два виміри процесу розробки ПС із позицій Rational Unified

Process
Слайд 58

Основи програмної інженерії Два виміри процесу розробки ПС із позицій Rational Unified Process

Основи програмної інженерії

Два виміри процесу розробки ПС із позицій Rational Unified

Process
Слайд 59

Основи програмної інженерії Підтримка потоків робіт CASE-засобами IBM Rational Software

Основи програмної інженерії

Підтримка потоків робіт CASE-засобами IBM Rational Software

Слайд 60

Основи програмної інженерії Програмна архітектура (ПА) Архітектура – мистецький характер будівлі.

Основи програмної інженерії

Програмна архітектура (ПА)

Архітектура – мистецький характер будівлі.
Усі розуміють важливість

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

Основи програмної інженерії Поняття програмної архітектури Припустимо, треба описати систему таким

Основи програмної інженерії

Поняття програмної архітектури

Припустимо, треба описати систему таким чином, щоб

зацікавлені особи (розробники, програмісти, користувачі, замовники) змогли б:
зрозуміти, що робить система;
зрозуміти, як працює система;
попрацювати з частиною системи, зокрема, використати повторно;
розширити систему.
Якщо все це займає не більше 60 сторінок, то це і є опис ПА.
Грубо – відповідний опис (ПА) робить систему зрозумілою (стає зрозумілим, що і як ПС реалізує).
Іноді з опису вилучають частини. Архітектура – це коли вилучити більше нічого не можна, щоб система лишалася зрозумілою.
Модель – не архітектура (моделі складних систем можуть бути дуже великими).
Слайд 62

Основи програмної інженерії Термінологія ПА Більшість означень ПА ґрунтуються на поняттях:

Основи програмної інженерії

Термінологія ПА

Більшість означень ПА ґрунтуються на поняттях:
статична структура ПС

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

Основи програмної інженерії Архітектурно значимі елементи Архітектурно значимий елемент має значний

Основи програмної інженерії

Архітектурно значимі елементи

Архітектурно значимий елемент має значний вплив на

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

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

Основи програмної інженерії

Означення архітектури, що використовується в RUP

Архітектура об'єднує значимі рішення

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

Основи програмної інженерії Відображення архітектури. Що дає архітектура? Наведені різні означення

Основи програмної інженерії

Відображення архітектури. Що дає архітектура?

Наведені різні означення ПА відображають

складність та багатовимірність поняття ПА.
Зрозуміло, що для різних зацікавлених сторін важливими є різні аспекти ПА. Як наслідок, використовуються різні представлення однієї й тієї ж ПА.
Архітектура:
спрощує розуміння ПС;
дозволяє отримати повний інтелектуальний контроль на всіх етапах ЖЦ ПС, забезпечуючи гнучкість та адаптивність ПС, спрощуючи розробку та супровід;
надає ефективну основу широкомасштабного повторного використання;
надає можливість управління проектом (наприклад, організовувати планування, кадрове забезпечення – за рівнями, підсистемами).
Слайд 66

Основи програмної інженерії Модель архітектури “4+1” Подання системи з точки зору

Основи програмної інженерії

Модель архітектури “4+1”

Подання системи з точки зору проектування
(структурні

відношення, функціональність, словник)
кінцевий користувач

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

Логічна складова

Фізична складова

Динамічна складова

Статична складова

Подання системи з точки зору реалізації
(складання, відношення між компонентами)
програміст

Подання системи з точки зору преце-дентів (функціональні можливості)

Слайд 67

Основи програмної інженерії Модель архітектури “4+1”

Основи програмної інженерії

Модель архітектури “4+1”

- Предыдущая
My group
Следующая -
Портфолио

Похожие презентации

Иерархическая и сетевая модели данных
Разработка анитивирусной защиты на предприятии
Информационные процессы (Информатика 7 Урок 2)
Информационное общество и информационная безопасность
Socket
Компьютерные презентации. Урок информатики в 10 классе
NET Development
Народная программистская мудрость
C#. Базовый курс
Интерфейс дегеніміз не
Компьютерные сети. Технические устройства. Техника безопасности
Память компьютера
Кодирование и обработка звуковой информации
Windows Hello for Everyone
Измерение информации. Содержательный подход
Дистрибутивы Linux
Серверные элементы управления
Оператор повторения Цикл for…to…do Цикл for…downto…do
Мультимедийные среды и цифровые инструменты в междисциплинарной проектной деятельности в предметной области
Система оптического распознавания текстов
Презентация "Биологические модели" - скачать презентации по Информатике
Презентация на тему "Магистрально-модульный принцип построения компьютера"
БЕЗОПАСНОСТЬ ДЕТЕЙ В ИНТЕРНЕТЕ
Управление памятью
Структура базы данных
Структурированные типы данных
Информатика до нашей эры
КОМПЬЮТЕРНАЯ ПРЕЗЕНТАЦИЯ: ОСНОВНЫЕ ТРЕБОВАНИЯ
Вы можете прислать нам Вашу презентацию и мы опубликуем ее на сайте.
Обратная связь
Для правообладателей
Email: Нажмите что бы посмотреть