21294

Структурний підхід до проектування інформаційних систем

Лекция

Информатика, кибернетика и программирование

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

Украинкский

2013-08-02

477 KB

13 чел.

Лекція 1. Структурний підхід до
проектування інформаційних систем

Вступ

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

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

- Структурний підхід
- Об'єктно-орієнтований підхід

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

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

Сутність структурного підходу

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

  Усі найбільш поширені методології структурного підходу базуються на ряді загальних принципів. В якості двох базових принципів використовуються наступні:

  •  принцип «розділяй і володарюй» - принцип вирішення складних проблем шляхом їх розбиття на безліч менших незалежних задач, легких для розуміння і вирішення;
  •  принцип ієрархічного упорядкування - принцип організації складових частин проблеми в ієрархічні деревоподібні структури з додаванням нових деталей на кожному рівні.

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

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

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

  •  SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми;
  •  DFD (Data Flow Diagrams) діаграми потоків даних;
  •  ERD (Entity-Relationship Diagrams) діаграми «сутність-зв'язок».

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

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

Методологія функціонального моделювання SADT

  Методологія SADT розроблена Дугласом Россом (корпорація SoftTech, Inc.) У 1969 р. для моделювання штучних систем середньої складності.

  Ця методологія успішно використовувалася у військових, промислових і комерційних організаціях США для вирішення широкого кола завдань, таких, як довгострокове і стратегічне планування, автоматизоване виробництво та проектування, розробка складного програмного забезпечення для оборонних систем, управління фінансами та матеріально-технічним постачанням та ін

  Методологія SADT підтримується Міністерством оборони США, яке було ініціатором розробки сімейства стандартів IDEF (Icam DEFinition), що є основною частиною програми ICAM (інтегрована комп'ютеризація виробництва), що проводиться за ініціативою ВПС США. Метод SADT реалізований в одному стандартів цього сімейства - IDEF 0, який був затверджений в якості федерального стандарту США в 1993 році.

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

  •  графічне представлення блокового моделювання. Графіка блоків і дуг SADT-діаграми відображає функцію у вигляді блоку, а інтерфейси входу / виходу представляються дугами, відповідно входять у блок і виходять з нього. Взаємодія блоків один з одним описуються за допомогою інтерфейсних дуг, що виражають «обмеження», які в свою чергу визначають, коли і яким чином функції виконуються і управляються;
  •  строгість і точність. Виконання правил SADT вимагає достатньої строгості й точності, не накладаючи в той же час надмірних обмежень на дії аналітика. Правила SADT включають:
    1.  обмеження кількості блоків на кожному рівні декомпозиції (як правило 3-6 блоків);
    2.  зв'язність діаграм (номери блоків);
    3.  унікальність міток і найменувань (відсутність повторюваних імен);
    4.  синтаксичні правила для графіки (блоків і дуг);
    5.  поділ входів та управлінь (правило визначення ролі даних).
    6.  відділення організації від функції, тобто виключення впливу організаційної структури на функціональну модель.

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

  Результатом застосування методології SADT є модель, яка складається з діаграм, фрагментів текстів та глосарію, що мають посилання один на одного. Діаграми - головні компоненти моделі, всі функції ІС та інтерфейси на них представлені як блоки і дуги. Місце з'єднання дуги з блоком визначає тип інтерфейсу. Керуюча інформація входить у блок зверху, у той час як інформація, яка піддається обробці, показана з лівого боку блоку, а результати виходу показані з правого боку. Механізм (людина або автоматизована система), який здійснює операцію, представляється дугою, що входить в блок знизу (рисунок 2.1).

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

Рис. 2.1. Функціональний блок та інтерфейсні дуги

  На малюнку 2.2, де наведено чотири діаграми та їх взаємозв'язку, показана структура SADT-моделі. Кожен компонент моделі може бути декомпозирована на іншій діаграмі. Кожна діаграма ілюструє «внутрішню будову» блоку на батьківській діаграмі.

Рис. 2.2. Структура SADT-моделі. Декомпозиція діаграм

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

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

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

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

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

  На малюнках 2.3 - 2.5 представлені різні варіанти виконання функцій і з'єднання дуг з блоками.

Рис. 2.3. Одночасне виконання

Рис. 2.4. Відповідність має бути повним і несуперечливим

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

  На SADT-діаграмах не вказані явно ні послідовність, ні час. Зворотні зв'язки, ітерації, що тривають процеси і перекриваються (за часом) функції можуть бути зображені з допомогою дуг. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і т.д. (Рисунок 2.5).

Рис. 2.5. Приклад зворотного зв'язку

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

Рис. 2.6. Приклад механізму

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

  Для того, щоб вказати положення будь-якої діаграми чи блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, яка деталізує блок 1 на діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, яка є самої верхньої діаграмою моделі. На малюнку 2.7 показано типове дерево діаграм.

Рис. 2.7. Ієрархія діаграм

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

  Далі коротко визначимо і проілюструємо дані типи зв'язків на прикладі з SADT.

  (0) Тип випадкової зв'язності : найменш бажаний.

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

Рис. 2.8. Випадкова зв'язність

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

  (2) Тип тимчасової зв'язності. Зміни, пов'язані за часом елементи виникають внаслідок того, що вони представляють функції, пов'язані в часі, коли дані використовуються одночасно або функції включаються паралельно, а не послідовно.

  (3) Тип процедурної зв'язності. Процедурно-зв'язані елементи з'являються згрупованими разом внаслідок того, що вони виконуються протягом однієї і тієї ж частини циклу або процесу. Приклад процедурно-зв'язаної діаграми наведено на малюнку 2.9.

Рис. 2.9. Процедурна зв'язність

  (4) Тип комунікаційної зв'язності. Діаграми демонструють комунікаційні зв'язки, коли блоки групуються внаслідок того, що вони використовують одні і ті ж вхідні дані та / або роблять одні й ті ж вихідні дані (рисунок 2.10).

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

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

Рис. 2.10. Комунікаційна зв'язність

Рис. 2.11. Послідовна зв'язність

Рис. 2.12. Функціональна зв'язність

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

  C = g (B) = g (f (A))

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

Методологія моделювання потоків даних (процесів)

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

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

  •  зовнішні сутності;
  •  системи / підсистеми;
  •  процеси;
  •  накопичувачі даних;
  •  потоки даних.

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

  Зовнішня сутність позначається квадратом (рисунок 2.13), розташованим як би «над» діаграмою і кидають на неї тінь, для того, щоб можна було виділити цей символ серед інших позначень:

Рис. 2.13. Зовнішня сутність

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

  Підсистема (або загальна система) на контекстній діаграмі зображується наступним чином (рисунок 2.14).

Рис. 2.14. Підсистема

  Номер підсистеми служить для її ідентифікації. У центрі імені вводиться найменування підсистеми у вигляді пропозиції з підметом і відповідними визначеннями і доповненнями.

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

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

Рис. 2.15. Процес

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

  •  «Ввести відомості про клієнтів»;
  •  «Видати інформацію про поточні витрати»;
  •  «Перевірити кредитоспроможність клієнта».

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

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

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

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

Рис. 2.16. Накопичувач даних

  Накопичувач даних ідентифікується буквою «D» і довільним числом. Ім'я накопичувача вибирається з міркування найбільшою інформативності для проектувальника.

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

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

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

Рис. 2.17. Потік даних

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

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

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

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

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

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

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

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

  •  правило балансування - означає, що при деталізації підсистеми або процесу детализирующая діаграма в якості зовнішніх джерел / приймачів даних може мати тільки ті компоненти (підсистеми, процеси, зовнішні сутності, накопичувачі даних), з якими має інформаційний зв'язок деталізіруемая підсистема або процес на батьківській діаграмі ;
  •  правило нумерації - означає, що при деталізації процесів повинна підтримуватися їх ієрархічна нумерація. Наприклад, процеси, які деталізують процес з номером 12, отримують номери 12.1, 12.2, 12.3 і т.д.

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

  Миниспецификация є кінцевою вершиною ієрархії ДПД. Рішення про завершення деталізації процесу і використанні миниспецификации приймається аналітиком виходячи з наступних критеріїв:

  •  наявності у процесу відносно невеликої кількості вхідних і вихідних потоків даних (2-3 потоку);
  •  можливості опису перетворення даних процесом у вигляді послідовного алгоритму;
  •  виконання процесом єдиною логічного функції перетворення вхідної інформації у вихідну;
  •  можливості опису логіки процесу за допомогою миниспецификации невеликого обсягу (не більше 20-30 рядків).

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

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


 

А также другие работы, которые могут Вас заинтересовать

9029. Виды и строение знания. Обыденное, научное и философское знание 34.5 KB
  Виды и строение знания. Обыденное, научное и философское знание Начиная с Демокрита философы занимали себя разделением знаний, попыткой их классификации и, соответственно, установлением связей между обозначенными видами. Современная эпистемология де...
9030. Предмет и типы социальной философии 37.5 KB
  Предмет и типы социальной философии Социальная философия имеет своим объектом познания общество, т. е. занимается познанием социальной действительности. В строгом смысле слова любое познание, поскольку оно протекает в обществе, является социальным...
9031. Глобалистика и ее проблемы. Глобальные проблемы современной цивилизации 42.5 KB
  Глобалистика и ее проблемы. Глобальные проблемы современной цивилизации Исторические типы взаимосвязи природы и общества определяются переходом от присваивающего к производящему хозяйству. Существуют три основных этапа такой взаимосвязи: 1 этап...
9032. Учение Августина 14.58 KB
  Учение Августина. Черты средневековой философии: теоцентризм - единый бог в центре бытия креационизм – разделение бытия на сущее (бога) и сотворенное богом провиденциализм – Бог знает все, все наполняет смыслом традиционализм...
9033. АНТИЧНЫЙ АТОМИЗМ (ДЕМОКРИТ, ЭПИКУР, ЛУКРЕЦИЙ КАР). 16.31 KB
  Античный атомизм (Демокрит, Эпикур, Лукреций Кар). Демокрит (460-360 гг.), продолжая материалистические традиции своих предшественников, в частности Левкиппа, считал, что весь мир состоит из атомов и пустоты. Все атомы создают бытие во всей полноте,...
9034. ФИЛОСОФСКИЕ ВЗГЛЯДЫ АРИСТОТЕЛЯ 15.81 KB
  Философские взгляды Аристотеля. Аристотель (также Стогирит, 384-322 г.), один из учеников Платона, во многом заложил основы для выделения философии как самостоятельной науки. Его основные сочинения - Метафизика, О душе, Первая вторая...
9035. СПЕЦИФИКА ФИЛОСОФСКИХ РАЗМЫШЛЕНИЙ О БЫТИИ 14.23 KB
  Специфика философских размышлений о бытии. Философия - это знание всеобщего во взаимодействии мира и человека. Объединяющим началом для человека и мира является бытие. Бытие - одна из основных категорий философии, которая изучается со врем...
9036. УЧЕНИЕ ГЕРАКЛИТА. 14.05 KB
  Учение Гераклита. Взгляды Гераклита [Темного] (544-480 гг.), уроженца Эфеса, были продолжением учения представителей Милетской школы. Гераклит обращает внимание на динамизм всего сущего и считает динамизм главной характеристикой первоначала. Он пров...
9037. ДВИЖЕНИЕ, ПРОСТРАНСТВО, ВРЕМЯ - АТРИБУТЫ МАТЕРИИ. 15.54 KB
  Движение, пространство, время - атрибуты материи. Необходимым условием существования материи является взаимодействие образующих ее элементов. Оно может носить внешний и внутренний характер и приводит к изменению. Любое изменение в философии называют...