41410

ТИПОВОЕ ПРОЕКТИРОВАНИЕ ИС

Лекция

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

В качестве примеров широко распространенных функциональных ППП можно назвать: 1С Предприятие автоматизация бухгалтерского учета расчета заработной платы складского учета Фолио Склад автоматизация складских операций Project Expert бизнеспланирование ИНЭК финансовый анализ и др. Таким образом вместе с программным продуктом пользователи приобретают базу знаний knowhow об эффективных методах организации и управления бизнеспроцессами которые можно адаптировать в соответствии со спецификой конкретного экономического...

Русский

2013-10-23

250.5 KB

53 чел.

Лекция ПИС

ТИПОВОЕ ПРОЕКТИРОВАНИЕ ИС

14/12/01

1. Основные понятия и классификация методов типового проектирования

Методы типового проектирования ЭИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемая ЭИС должна быть декомпозируема на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.), для которых подбираются и закупаются имеющиеся на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области.

Под типовым проектным решением (ТПР) будем понимать представленное в виде проектной документации, включая программные модули, проектное решение, пригодное к многократному использованию.

В качестве проектного решения может выступать реализация как отдельных компонентов ЭИС (программных модулей, функциональных задач, автоматизированных рабочих мест, локальных баз данных, локальных вычислительных сетей), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ЭИС в целом). Типовые проектные решения также называют тиражируемыми продуктами.

В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования (рис. 1).

Рис. 1. Классификация типовых методов проектирования

При элементном методе типового проектирования ЭИС в качестве типового элемента системы используется типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному) (рис. 2).

Рис. 2. ТПР уровня Задача

Сущность применения ТПР при элементном методе заключается в комплектации ЭИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. Достоинство элементного метода типового проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС.

К недостаткам применения метода относятся большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости ТПР, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия.

Следствием перечисленных недостатков являются большие затраты времени на доработку и комплексирование ТПР отдельных элементов, сопоставимые со временем ручного оригинального проектирования ЭИС. В настоящее время элементные ТПР в основном применяются в качестве библиотек методо-ориентированных программ (библиотек классов объектов), например, при разработке графических интерфейсов, применении вычислительных и служебных функций. В силу ограниченного характера применения в дальнейшем метод элементного типового проектирования ЭИС не рассматривается.

При использовании подсистемного метода типового проектирования ЭИС в качестве элементов типизации выступают отдельные подсистемы, которые обеспечивают функциональную полноту, минимизацию внешних информационных связей, параметрическую настраиваемость, альтернативность схем в пределах значений входных параметров. При этом достигается более высокая степень интеграции типовых элементов ЭИС.

Типовые проектные решения для функциональных подсистем реализуются в виде пакетов прикладных программ (ППП), которые позволяют осуществлять:

• модульное проектирование;

•параметрическую настройку программных компонентов на различные объекты управления;

•сокращение затрат на проектирование и программирование взаимосвязанных компонентов;

• хорошее документирование отображаемых процессов обработки информации.

Вместе с тем адаптивность типовых проектных решений в виде функциональных ППП недостаточна с позиции непрерывного инжиниринга деловых процессов. Также возникают проблемы в комплексировании ППП разных функциональных подсистем, особенно в случае использования ППП нескольких производителей программного обеспечения, для которых, как правило, характерна их информационная, программная и техническая несовместимость между собой при построении единой, корпоративной ЭИС.

В качестве примеров широко распространенных функциональных ППП можно назвать: 1С «Предприятие» (автоматизация бухгалтерского учета, расчета заработной платы, складского учета), «Фолио - Склад» (автоматизация складских операций), Project Expert (бизнес-планирование), ИНЭК (финансовый анализ) и др.

При объектном методе типового проектирования ЭИС в качестве типового элемента используется типовой проект для объектов управления определенной отрасли, который включает полный набор функциональных и обеспечивающих подсистем ЭИС. Современные типовые проекты отличаются:

• открытостью архитектуры, позволяющей устанавливать проекты на разных программно-технических платформах;

• масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест;

•конфигурируемостью, позволяющей выбирать подмножество компонентов, которые необходимы для конкретной проблемной области и параметрически настраиваемы на особенности объекта управления.

Несомненное преимущество объектного метода типового проектирования ЭИС перед подсистемным методом заключается в комплексируемости всех компонентов за счет методологического единства и информационной, программной и технической совместимости компонентов.

Адаптивность объектного метода проектирования зависит от используемого подхода. При параметрической настройке типовых информационных систем, таких, например, как ППП «Галактика», «Парус», «БОСС» и другие, возникают проблемы привязки типового проекта к конкретному объекту управления так же, как и при подсистемном подходе. Обычным способом решения проблемы адаптации является изменение структуры организационно-экономической системы объекта внедрения в соответствии с требованиями типового проекта либо существенная доработка типового проекта с помощью специальных инструментальных средств типовой системы.

В настоящее время развивается модельно-ориентированный подход реализации объектного метода типового проектирования ЭИС, известный по применению типовых информационных систем ВУЗ (SAP) и BAAN IV (BAAN). Особенность этого подхода заключается в настройке типового проекта на особенности объекта управления путем привязки модели проблемной области к модели типовой системы. Поддержание при этом модели проблемной области в репозитории системы сближает метод типового проектирования с методом автоматизированного проектирования как в части более точного определения и модификации требований к информационной системе, так и в части корректности параметрической настройки и автоматизированной доработки проектных решений.

В силу отличий параметрически -ориентированного и модельно-ориентированного подходов к реализации методов типового проектирования ЭИС каждый из перечисленных подходов рассматривается в отдельном параграфе.

2. Параметрически- ориентированное проектирование ЭИС

При проектировании ЭИС на основе параметрической настройки пакета прикладных программ (ППП) последний рассматривается как «черный ящик» (рис. 3). На вход ППП подаются параметрический (ПП) и информационный (ИП) потоки, а выходом служит результат работы пакета (РП). ППП включает следующие блоки: функционирования, обработки параметров, адаптации.

Рис. 3. Представление ППП в виде «черного ящика»

Рассмотрим взаимосвязь основных потоков и компонентов пакета прикладных программ.

Информационный поток представляет собой исходные данные, которые обрабатываются и необходимы для получения результатов работы пакета. Исходные данные для функционирования пакета могут быть представлены в виде различных документов, причем как бумажных, так и электронных.

Результаты работы пакета могут быть представлены в виде отчетов, графиков, электронных документов, которые могут накапливаться или направляться во внешнюю среду.

Блок функционирования обрабатывает исходные данные и формирует результаты работы пакета. Графически блок функционирования представляется деревом программных модулей, которые автоматизируют функции обработки данных.

Параметрический поток - информация, необходимая для настройки пакета на конкретные условия функционирования. Параметрический поток включает информацию, которая задается один раз при установке (инсталляции) этого пакета. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на режим их работы. Для архитектуры «клиент-сервер» в параметрическом потоке описываются пользователи и их уровни доступа к программным модулям и ко всему пакету в целом.

Параметрическая информация предоставляется:

• в справочниках (классификаторах с задаваемым числом уровней классификации, например, в справочниках номенклатуры изделий и услуг, видов расчетов, валют и т.д.);

• в таблицах описаний конфигурации программных модулей (например, условия включения (выключения) модуля, режимы ручного или автоматического обновления полей данных, методы расчетов показателей и т.д.). Блок обработки параметров представляет собой совокупность специальных модулей по интерпретации значений параметров. В частности, блок обработки параметров переносит установки пользователя непосредственно в прикладные программы и в используемую базу данных. Проводимая настройка ППП позволяет использовать его для широкого класса объектов управления.

Блок адаптации взаимодействует с блоком функционирования и может добавлять модули или модифицировать их. Необходимость применения блока адаптации связана с потребностями доработки программных модулей ППП под воздействием внешних условий функционирования. Поэтому в состав ППП включается инструментарий адаптации существующих типовых проектных решений.

В качестве таких инструментов, доступных квалифицированному пользователю (непрограммисту), используются:

генераторы программ ЭИС на основе языковых средств RAD-технологии (4GL);

макроязыки проектирования и настройки типовых модулей.

Сущность применения метода типового проектирования ЭИС на основе параметрической настройки ППП заключается в определении критериев оценки ППП, оценке множества ППП-претендентов по сформулированным критериям, выбору и закупке ППП с наивысшей интегральной оценкой, а далее - собственно настройке параметров и возможной доработке закупленного ППП.

Таким образом, параметрически- ориентированное проектирование ЭИС на основе использования ППП по сравнению с оригинальным проектированием дает возможность более быстрого и гибкого внедрения информационной системы.

Однако существует рад проблем, сдерживающих распространение данной технологии. К ним можно отнести следующее:

• психологические и организационные трудности внедрения ППП;

• достаточно высокую стоимость приобретения ППП и обучения персонала;

• отсутствие глобальной модели объекта управления, что ведет к затратам по увязке различных ППП в рамках корпоративной ЭИС.

3. Модельно-ориентированное проектирование ЭИС

Сущность модельно-ориентированного проектирования ЭИС сводится к адаптации компонентов типовой ЭИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ЭИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними.

Ядром типовой ЭИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специальной базе метаинформации - репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ЭИС сводятся, прежде всего, к построению модели проблемной области и ее периодической корректировке.

Для моделирования проблемной области и последующих конфигураций информационной системы из отдельных компонентов (программных модулей) используется специальный программный инструментарий, например SAP Business Engineering Workbench (BEW) [52] и BAAN Enterprise Modeler [70]. Несомненным достоинством применения модельно-ориентированных компонентных систем, таких, как R73 или BAAN IV, перед CASE-технологиями является накапливание опыта проектирования информационных систем для различных отраслей и типов производства в виде типовых моделей, которые поставляются вместе с программным продуктом в форме наполненного репозитория. Таким образом, вместе с программным продуктом пользователи приобретают базу знаний «know-how» об эффективных методах организации и управления бизнес-процессами, которые можно адаптировать в соответствии со спецификой конкретного экономического объекта.

Репозитории корпоративной ЭИС, использующей модельно-ориентированную технологию проектирования, в общем случае содержит метаинформацию базовой модели функциональности типовой системы (ссылочной модели в терминологии R/3), типовых моделей определенных классов ЭИС (референтных моделей в терминологии BAAN) и модели предприятий, получаемой на основе базовой или типовых моделей.

Базовая модель репозитория содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, организационной структуры, которые используются в программных модулях типовой ЭИС. При этом большое значение в базовой модели имеет задание бизнес-правил поддержания целостности информационной системы, определяющих условия проверки корректности совместного применения различных компонентов ЭИС. Таким образом, многообразие и гибкость определения бизнес-процессов и соответствующих конфигураций информационной системы задаются с помощью набора бизнес-правил.

Типовые модели описывают конфигурации информационной системы для определенных отраслей (автомобильной, электронной, нефтегазовой и др.) или типов производства (единичного, серийного, массового, непрерывного и др.).

Модель предприятия (проблемной области) строится либо путем привязки фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия, например как в инструментальном средстве BAAN Enterprise Modeler, либо в результате просмотра этих моделей и экспертного опроса, как в инструментальном средстве SAP Business Engineering Workbench. Причем в последнем случае пользователю предлагается определить значения не всех параметров, а только тех, которые связаны между собой в контексте диалога и описаны бизнес-правилами.

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

В обобщенном виде конфигурация корпоративных информационных систем на основе модельно-ориентированной технологии [83] представлена на рис. 4.

Рис. 4. Конфигурация ЭИС на основе модельно-ориентированной технологии

Рассмотрим компоненты модели предприятия более детально.

Модель функций

Модель функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия. На первом уровне иерархии обычно указываются основные виды функциональных подсистем: сбыт, производство, логистика, сервис, финансы, персонал и т.д. На следующем уровне иерархии для каждой функциональной подсистемы показываются функциональные модули, например, подсистема «Логистика» включает в себя функциональные модули: планирование потребности в материалах, закупки, управление запасами, управление складами, проверка платежей и т.д. Для функциональных модулей задаются наборы бизнес-функций, для каждой из которых в дальнейшем определяются бизнес-процессы. Например, для функционального модуля «закупки» определяются бизнес-функции: оформление договоров, оформление заказов, выписка счетов и т.д.

Рис. 5. Фрагмент модели функции в системе R/3

В системе R/3 просмотр функциональности типовой ЭИС осуществляется с помощью программы-навигатора рспозитория. Пример навигации на фрагменте модели функций показан на рис. 5. В процессе навигации по дереву можно перейти к документации, описывающей соответствующую функцию, и определению подфункций. Для функций последнего уровня по желанию специалиста-конфигуратора открывается просмотр схемы бизнес-процесса с используемыми входными-выходными данными и участвующими организационными единицами или схемы бизнес-объектов в вице ER-модели.

В системе BAAN IV с помощью инструмента Enterprise Modeler можно построить четырехуровневое дерево декомпозиции функций (рис. 6).

Рис. 6. Модель функций системы BAAN IV

В отличие от R/3 бизнес-функции могут называться именами, характерными для конкретного предприятия. Кроме того, для функций могут быть заданы показатели оценки эффективности их выполнения, произвольное текстовое описание (например, инструкции для выполнения), а для функций последнего уровня указываются варианты реализации (оптимизации) по мере внедрения ЭИС (например, функция с интерактивным и автоматическим выполнением).

Модель процессов

Модель бизнес-процесса отражает последовательность выполнения работ (операций) для функций самого нижнего уровня модели бизнес-функций, которая позволяет провести конфигурацию программных модулей информационной системы в соответствии с характерными особенностями конкретной проблемной области.

Как в системе R/3, так и в системе BAAN IV для представления бизнес-процессов используется аппарат сетей Петри, позволяющий отображать управление процессами в зависимости от событий: работа выполняется в том случае, если на входе известно состояние системы.

В системе R/3 для отображения процессов используется модель управления событиями (ЕРС - event-driven process chain), реализованная в ARIS Toolset (рис. 7). В соответствии с этим методом переходы между операциями осуществляются в зависимости от событий, которые могут связываться логическими связками AND, OR, XOR. Кроме того, по требованию пользователей в модели процесса могут быть показаны входные-выходные данные, участвующие организационные единицы, указывается тип обработки (интерактивный, пакетный). Операции бизнес-процесса, как и процесс в целом, документируются.

Рис. 7. Модель управления событиями бизнес-процесса в системе R/3

Модель бизнес-процесса, построенная с помощью BAAN Enterprise Modeler (рис. 8), позволяет в качестве операций использовать не только программные модули BAAN IV, но и ручные процедуры, приложения, разработанные в другой программной среде.

Рис. 8. Модель бизнес-процесса в среде BAAN Enterprise Modeler

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

Модели объектов (данных)

В модельно-ориентированной технологии проектирования ЭИС интегрирование различных бизнес-процессов (приложений) осуществляется на основе бизнес-объектов. Согласно определению комитета Business Object Task Force OMG [72] бизнес-объекты - компоненты уровня проблемной области, которые используются в различных приложениях в произвольных комбинациях и не зависят от них. При этом «приложение обеспечивает среду для функционирования бизнес-объектов». OMG разрабатывает спецификации программных оболочек, которые предоставляют готовые объекты для следующих приложений: производства, электронной коммерции, транспортировки, телекоммуникаций, здравоохранения, финансов и др.

С одной стороны, бизнес-объекты - это объекты-сущности в нотации UML, например заказы, счета, материалы, поставщики и т.д. С другой стороны, в отличие от обычных объектов-сущностей бизнес-объекты являются самодостаточными, т. е. имеют стандартный интерфейс, написанный на языке описания интерфейсов IDL (Interface Definition Language), с помощью которого бизнес-объекты могут взаимодействовать друг с другом через объектную шину - брокер объектных запросов (Object Request Broker). Таким образом, бизнес- объекты обладают более сложной внутренней структурой по сравнению с простыми объектами. Например, структура бизнес- объектов R/3 включает ограничения целостности в виде допустимых типов связей с другими объектами и бизнес-правила по связям с внешней средой, интерфейсы в виде входных-выходных событий и спецификации доступа к объектам.

В системе R/3 разработано более 100 стандартных интерфейсов бизнес-объектов, называемых BAPI (Business Application Programming Interface), которые позволяют осуществлять непосредственную связь между приложениями разных предприятий в среде ИНТЕРНЕТ. Например, при оформлении заказа от клиента поставщику могут использоваться следующие стандартные методы бизнес-объектов:

ProductGronp.Select - выбор группы изделий в каталоге;

Product.Description - просмотр описания изделия;

Product.Select - выбор изделия из группы;

Order.Create - создание заказа и т.д.

В системе R/3 модель бизнес-объектов описывается как статическая ER-модель, в которой каждая сущность может рассматриваться как обычный объект данных, который используется на входе или выходе операций, так и как бизнес-объект с присоединенными методами.

В инструменте BAAN Enterprise Modeler модель бизнес-объектов не отражается вследствие использования стандартной структуры базы данных, которую можно настраивать на особенности конкретного предприятия.

Модель организационной структуры

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

С помощью инструмента BEW в модели бизнес-процесса явно указывается закрепление автоматизированных функций по подразделениям (см. рис. 7).

С помощью инструмента Enterprise Modeler связь модели бизнес-процесса и модели организационной структуры задается через указатели роли, которые могут выполняться различными организационными единицами (рис. 9). Через указатели роли сотрудников устанавливается связь организационной структуры с бизнес-процессами. Указатель роли определяет тип работника, который может выполнять ту или иную работу (экономист, бухгалтер, менеджер и т.д.). Для каждой роли определяются полномочия в выполнении функций, права доступа к информации, должностные инструкции. При назначении работы конкретному работнику всегда осуществляется проверка роли, которую он может выполнять. Если при этом тип конкретного работника не соответствует роли, то последний не получает доступа к выполнению работы.

Рис. 9. Установление связи модели организационной структуры и модели бизнес-процесса

Модели бизнес-правил

Бизнес-правила - это специальные сведения в области типовой ЭИС, которые хранятся в репозитории и используются для контроля корректности построенной модели предприятия и процессов конфигурации и эксплуатации ЭИС. В системе R/3 бизнес-правила встроены в бизнес-объекты, в системе BAAN бизнес-правила выделены в самостоятельные компоненты. Рассмотрим применение бизнес-правил на примере системы BAAN.

Правила целостности модели предприятия

Правила целостности используются для проверки согласованности модели предприятия с точки зрения полноты и непротиворечивости бизнес-функций, например:

Если присутствует вариант бизнес-функции «Прямая поставка», тогда бизнес-функции «Обработка заказа на приобретение» и «Обработка заказа на сбыт» должны быть представлены в модели.

Правила преобразования моделей бизнес-функций в модели бизнес-процессов

Модель бизнес-функции может быть автоматически преобразована в модель бизнес-процесса посредством правил преобразования, которые задают соответствие бизнес-функции и бизнес-процесса, например:

Если был определен вариант бизнес-функции «Обработка заказа на приобретение с контрактами», необходимо выбрать бизнес-процесс «Обработка контрактов».

Правила конфигурации (установки параметров)

Правила конфигурации используются для присвоения значения параметру BAAN в зависимости от его наличия в бизнес-функциях, бизнес-процессах или их комбинациях. Например:

Если был определен вариант бизнес-функции «Обработка заказа на покупку в режиме ЭОД (электронный обмен данными)», значение параметра «электронный обмен данными» настраивается на «да».

Правила установки статических условий

Правила установки статических условий осуществляют выбор варианта бизнес-процесса в зависимости  от выполнения условия. Если значение условия правила ложно, то данный вариант в процессе эксплуатации не выполняется и на диаграмме процесса соответствующая неактивная ветвь дерева изображается в затемненном виде, например:

Если бизнес-функция «Оформление аккредитива» не используется в фазе внедрения, то запретить процесс оформления аккредитива.


 

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

34769. Проблема жизни и смерти в духовном опыте человека. Философия о смысле жизни, смерти и бессмертии. Право на смерть 67.5 KB
  Философия о смысле жизни смерти и бессмертии. В чем смысл жизни Постановка проблемы В жизни каждого нормального человека рано или поздно наступит момент когда он задается вопросом о конечности своего индивидуального существования. Наличием такого знания в духовном опыте человека в значительной степени и объясняется острота с которой перед ним встает вопрос о смысле и цели жизни.
34770. Понятие истины. Объективность истины. Принципы: корреспонденции, когеренции и прагматизма. Гносеологическая, логическая и онтологическая формы истины 42.5 KB
  Объективность истины. Гносеологическая логическая и онтологическая формы истины. Абсолютные истины складываются на основе относительных.
34771. Истина как процесс. Диалектика абсолютной и относительной истины 39.5 KB
  Диалектика абсолютной и относительной истины. Конвенциональная концепция истины считает истинное знание или его логические основания результатом конвенции соглашения. Разброс мнений достаточно велик однако наибольшим авторитетом и самым широким распространением пользовалась и пользуется классическая концепция истины берущая свое начало от Аристотеля и сводящаяся к корреспонденции соответствию знания объекту. Классическая концепция истины хорошо согласуется с исходным гносеологическим тезисом диалектикоматериалистической философии о том...
34772. Истина, ложь, заблуждение. Конкретность истины. Ложь «во спасение». Проблема врачебных ошибок 41.5 KB
  Конкретность истины.В философии понятие истины совпадает с комплексом базовых концепций позволяющих различить достоверное и недостоверное знание по степени его принципиальной возможности согласовываться с действительностью по его самостоятельной противоречивости непротиворечивости а также в рамках разведения полезности и бесполезности эффективности и неэффективности. категория истины обладает двойственной характеристикой. уклонение от истины принимаемое нами за истинное суждение; основывается всегда на неверности по существу самих...
34773. Практика как критерий истины. Абсолютность и относительность практики как критерия истины 43 KB
  Абсолютность и относительность практики как критерия истины К сожалению фактически все попытки решить проблему критерия истины не увенчались успехом. следует выделить две особенности практики как критерия истины: 1. Это достигается в процессе материального воплощения мышления в человеческой практики. С его помощью невозможно доказать немедленно непосредственно истинность или ложность тех или иных научных теорий которые выходят за пределы возможностей самой практики обусловленной историческим отрезком времени.
34774. Практика как специфический способ отношения человека к миру. Формы практической деятельности. Специфика медицинской практики 34 KB
  Формы практической деятельности. Интегративные функции практики по отношению к другим формам жизнедеятельности В сфере реального отношения людей к миру к природе к обществу к другим людям формируются исходные стимулы развитии всех форм человеческой культуры. Создаваемые в культуре и в материальном производстве и в регуляции отношений между людьми в обществе и наконец в сфере науки искусства философии способы деятельности возникают но сути своей как ответ па определенные проблемы и задачи связанные с воспроизводством...
34775. Глобальные проблемы современности. Философский анализ и решение. Альтернативы будущего 42.5 KB
  Остановим внимание на названных и в первую очередь на экологической проблеме в силу тех причин что все происходящее на планете Земля с участием человека или без него протекает и в природе. Геосфера поверхность Земли как необитаемая так и пригодная для жизни человека. Ноосфера ноо разум область разумной деятельности человека онрделяемая в конечном счете уровнем человеческого интеллекта и объемом перерабатываемой его мозгом информации. С целью их разгадки все сферы взаимоотношений природы и человека были условно разделены на...
34776. Философия медицины. Антропоцентризм. Духовность и медицина. Проблема человека 42.5 KB
  Это касается и права индивида на свободный личный выбор жизни или смерти. Антропоцентризм предписывает противопоставлять феномен человека всем прочим феноменам жизни и Вселенной вообще. Лежит в основе потребительского отношения к природе оправдания уничтожения и эксплуатации других форм жизни. Понимание основ духовной жизни пациента часто включает в себя и знание его духовного развития.
34777. Этический рационализм Сократа. Учение о душе и добродетели. Переоценка ценностей. Особенности метода субъективной диалектики 30 KB
  Сократ около 470 399 до н. Универсальное основание мироздания по Сократу выступает как его всеобщая объективная родовая сущность которая может быть рациональнологически выражена в определенных закономерностях происходящего. Нравственный лучший тот кто знает что именно есть добродетель ибо по Сократу знающий благо поступает в соответствии с этим знанием.