Структурное и модульное программирование

Структурное и модульное программирование

Весь текст с википедии, статьи:

Структурное программирование

Модульное программирование

Структу́рное программи́ рование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 1970-х годах Э. Дейкстрой и др.

В соответствии с данной методологией любая программа строится без использования оператора goto из трёх базовых управляющих структур: последовательность, ветвление, цикл; кроме того, используются подпрограммы. При этом разработка программы ведётся пошагово, методом «сверху вниз».

Методология структурного программирования появилась как следствие возрастания сложности решаемых на компьютерах задач, и соответственно, усложнения программного обеспечения. В 1970-е годы объёмы и сложность программ достигли такого уровня, что традиционная (неструктурированная) разработка программ перестала удовлетворять потребностям практики. Программы становились слишком сложными, чтобы их можно было нормально сопровождать. Поэтому потребовалась систематизация процесса разработки и структуры программ.

Методология структурной разработки программного обеспечения была признана «самой сильной формализацией 70-х годов».

По мнению Бертрана Мейера, «Революция во взглядах на программирование, начатая Дейкстрой, привела к движению, известному как структурное программирование, которое предложило систематический, рациональный подход к конструированию программ. Структурное программирование стало основой всего, что сделано в методологии программирования, включая и объектное программирование».

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

Теорема о структурном программировании

Теорему сформулировали и доказали итальянские математики Коррадо Бём (Corrado Böhm) и Джузеппе Якопини (Giuseppe Jacopini). Они опубликовали её в 1965 году на итальянском языке и в 1966 году на английском. Наряду с теоремой, в статье Бёма и Якопини описывались методы преобразования неструктурных алгоритмов в структурные на примере созданного Бёмом языка программирования P′′. Язык P′′ — первый полный по Тьюрингу язык программирования без оператора goto.

Теорема Бёма-Якопини написана сложным языком и в непривычных обозначениях. Если использовать современную терминологию и обозначения, она примет вид:

Любая программа, заданная в виде блок-схемы, может быть представлена с помощью трех управляющих структур:

	последовательность — обозначается: f THEN g,
	ветвление — обозначается: IF p THEN f ELSE g,
	цикл — обозначается: WHILE p DO f,

где f, g — блок-схемы с одним входом и одним выходом,

р — условие,

THEN, IF, ELSE, WHILE, DO — ключевые слова.

Пояснение. Формула f THEN g означает следующее: сначала выполняется программа f, затем выполняется программа g.

Модульная система модулей

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

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

Реализация Лероя сама построена посредством языка модулей ML, а именно в виде функтора, параметризованного данными о ядре языка и описанием его механизма проверки согласования типов. Это значит, что при написании компилятора некоторого языка достаточно описать ядро языка и передать его данному функтору (как библиотечной функции) — в результате получится компилятор расширения известного языка системой модулей ML.

Основные понятия

Абстракция данных

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

Инкапсуляция

Инкапсуляция — свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе. Некоторые языки (например, С++) отождествляют инкапсуляцию с сокрытием, но большинство (Smalltalk, Eiffel, OCaml) различают эти понятия.

Наследование

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

Полиморфизм подтипов

Полиморфизм подтипов (в ООП называемый просто «полиморфизмом») — свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. Другой вид полиморфизма — параметрический — в ООП называют обобщённым программированием.

Класс

Класс является описываемой на языке терминологии исходного кода моделью ещё не существующей сущности (объекта). Фактически он описывает устройство объекта, являясь своего рода чертежом. Говорят, что объект — это экземпляр класса. При этом в некоторых исполняющих системах класс также может представляться некоторым объектом при выполнении программы посредством динамической идентификации типа данных. Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области.

Объект

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

 

Концепции

Появление в ООП отдельного понятия класса закономерно вытекает из желания иметь множество объектов со сходным поведением. Класс в ООП — это в чистом виде абстрактный тип данных, создаваемый программистом. С этой точки зрения объекты являются значениями данного абстрактного типа, а определение класса задаёт внутреннюю структуру значений и набор операций, которые над этими значениями могут быть выполнены. Желательность иерархии классов (а значит, наследования) вытекает из требований к повторному использованию кода — если несколько классов имеют сходное поведение, нет смысла дублировать их описание, лучше выделить общую часть в общий родительский класс, а в описании самих этих классов оставить только различающиеся элементы.

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

Особенности реализации

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

 

Поля данных

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

Методы

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

Классы могут наследоваться друг от друга. Класс-потомок получает все поля и методы класса-родителя, но может дополнять их собственными либо переопределять уже имеющиеся. Большинство языков программирования поддерживает только единичное наследование (класс может иметь только один класс-родитель), лишь в некоторых допускается множественное наследование — порождение класса от двух или более классов-родителей. Множественное наследование создаёт целый ряд проблем, как логических, так и чисто реализационных, поэтому в полном объёме его поддержка не распространена. Вместо этого в 1990-е годы появилось и стало активно вводиться в объектноориентированные языки понятие интерфейса. Интерфейс — это класс без полей и без реализации, включающий только заголовки методов. Если некий класс наследует (или, как говорят, реализует) интерфейс, он должен реализовать все входящие в него методы. Использование интерфейсов предоставляет относительно дешёвую альтернативу множественному наследованию.

Взаимодействие объектов в абсолютном большинстве случаев обеспечивается вызовом ими методов друг друга.

Инкапсуляция обеспечивается следующими средствами:

Контроль доступа

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

Методы доступа

Поля класса в общем случае не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access — доступ), а по отдельности — геттерами (англ. get — чтение) и сеттерами (англ. set — запись).

Свойства объекта

Псевдополя, доступные для чтения и/или записи. Свойства внешне выглядят как поля и используются аналогично доступным полям (с некоторыми исключениями), однако фактически при обращении к ним происходит вызов методов доступа. Таким образом, свойства можно рассматривать как «умные» поля данных, сопровождающие доступ к внутренним данным объекта какими-либо дополнительными действиями (например, когда изменение координаты объекта сопровождается его перерисовкой на новом месте). Свойства, по сути, не более чем синтаксический сахар, поскольку никаких новых возможностей они не добавляют, а лишь скрывают вызов методов доступа. Конкретная языковая реализация свойств может быть разной. Например, в C# объявление свойства непосредственно содержит код методов доступа, который вызывается только при работе со свойствами, то есть не требует отдельных методов доступа, доступных для непосредственного вызова. В Delphi объявление свойства содержит лишь имена методов доступа, которые должны вызываться при обращении к полю. Сами методы доступа представляют собой обычные методы с некоторыми дополнительными требованиями к сигнатуре.

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

Понятие распределенной системы. Требования к распределенным системам.

Требования к распределенным системам

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

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

Масштабируемость. Масштабируемость вычислительных систем имеет несколько аспектов. Наиболее важный из них для данного курса – возможность добавление в распределенную систему новых компьютеров для увеличения производительности системы, что связано с понятием балансировки нагрузки (load balancing) на серверы системы. К масштабированию относятся так же вопросы эффективного распределение ресурсов сервера, обслуживающего запросы клиентов.

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

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

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

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

Основные условия и требования к распределенной обработке данных

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

Ведущими поставщиками СУБД сформулированные следующие свойства "идеальной" системы управления распределёнными БД:

Прозрачность относительно расположения данных: СУБД должна представлять все данные так, как если бы они были локальными.

Гетерогенность системы: СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью (независимость от СУБД).

Прозрачность относительно сети: СУБД должна одинаково работать в условиях разнородных сетей.

Поддержка распределенных запросов: пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах.

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

Поддержка распределенных транзакций: СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдельных системах, так и в сети.

Безопасность: СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа.

Универсальность доступа: СУБД должна обеспечивать единую методику доступа ко всем данным.

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

Указанные причины определили на практике частичность и "этапность" введения в СУБД возможностей распределённой обработки данных. В простейшем случае пользователь по сети может обращаться к записям в БД, размещённым на других компьютерах. В других случаях СУБД производит аутентификацию удалённого клиента и устанавливает сетевые соединения.

Режимы работы с БД можно классифицировать по следующим признакам:

многозадачность - однопользовательский или многопользовательский;

правило обслуживания запросов - последовательное или параллельное;  схема размещение данных - централизованная или распределённая БД.

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

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

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

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

Распределенные базы данных, РБД (англ. "Distributed DataBase", DDB) представляют определенным образом связанные между собой БД, рассредоточенные на какой-либо территории (локально или регионально), обеспечивающие свободный обмен информацией и поиск данных в них. Такие БД могут располагаться на различных узлах компьютерной сети.

Выделяют однородные и неоднородные РБД. Часто данные размещаются в БД и СУБД по месту своего возникновения или наиболее эффективного использования в ЭВМ, удаленных друг от друга на большие расстояния, хотя каждая из этих ЭВМ управляет своими локальными СУБД. Возникает необходимость решения задач с распределенными БД путем организации между ЭВМ сети передачи данных по каналам связи, а также обеспечения технической и программной поддержки обмена данными между ними.

Для работы с распределенными данными создаются системы управления распределенными базами данных (СУРБД), оснащенные каталогами, хранящими структуру сети, информацию о локальных СУРБД и БД, а также программным обеспечением, управляющим взаимодействием прикладной программы и конкретной локальной БД сети. Управление однотипными локальными СУРБД осуществляется просто. В противном случае в сеть РБД включают различные программные и технические устройства, обеспечивающие единый интерфейс, согласование и возможность выполнения информационных процессов (промежуточную интерфейсную СУРБД, протокол Z39.50 и др.).

Распределенные банки данных

Накапливаемая в сетях разнообразная машиночитаемая информация обычно не концентрируется в какой-либо одной ЭВМ, а распределена по различным ЭВМ. Доступ в подобные РБД (банки) осуществляется специальными сетевыми СУБД, дающими возможность безадресного обращения к данным, подобно обычным БД, реализованным на одной ЭВМ. Зная логическую структуру БД сети, абонент формирует запрос к ней (на языке манипулирования данными), не заботясь о том, в каких именно ЭВМ сети расположены интересующие его данные.

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

Эффективность методик

Методика устранения дефекта	Min-max, %	Сред., %
Неформальные обзоры проекта	25-40
Формальные инспеции проекта	45-65
Неформальные обзоры кода	20-35
Формальные обзоры кода	45-70
Моделирование или прототипирование	35-80
Самостоятельная проверка кода	20-60
Блочное тестирование	15-50
Тестирование новых функций	20-35
Интеграционное тестирование	25-40
Регрессионное тестирование	15-30
Тестирование системы	25-55
Ограниченное бета-тестирование (< 10)	25-40
Масштабное бета-тестирование (> 1000)	60-85

 

Закон контроля качества ПО.

Повышение качества системы снижает расходы на ее разработку

IEEE Std 730-2002 планирование контроля качества

IEEE Std 1061-1998 методологии метрик качества

IEEE Std 1028-1997 стандарт обзоров ПО

IEEE Std 1008-1987(R1993) стандарт блочного тестирования

IEEE Std 829-1998 стандарт документации тестирования ПО

 

Файл-сервер

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

Достоинства:

низкая стоимость разработки;

высокая скорость разработки;

невысокая стоимость обновления и изменения ПО.

Недостатки:

рост числа клиентов резко увеличивает объём трафика и нагрузку на сети передачи данных;

высокие затраты на модернизацию и сопровождение сервисов бизнес-логики на каждой клиентской рабочей станции;

низкая надёжность системы.

В среде файлового сервера обработка данных распределена в сети, обычно представляющей собой локальную вычислительную сеть (ЛВС). Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлами, как показано на рис. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем необходимым ей данным, которые хранятся на диске файлового сервера. Такой подход характеризуется значительным сетевым трафиком, что может привести к снижению производительности всей системы в целом. Рассмотрим, например, ситуацию, когда пользователь посылает запрос на выборку данных обо всех сотрудниках отделения компании, находящегося по адресу 163 Main St. Эту задачу можно сформулировать с помощью следующего оператора SQL (глава 5):

SELECT fName, IName

FROM Branch b, Staff s

WHERE b.branchNo = s.branchNo AND b. street = 163 Main St

Поскольку файловый сервер не воспринимает команд на языке SQL, то СУБД

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

Большой объем сетевого трафика.

На каждой рабочей станции должна находиться полная копия СУБД.

Управление параллельной работой, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.

Клиент-сервер

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

 

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

Функции, выполняемые участниками взаимодействия в среде"клиент/сервер"

 

Этот тип архитектуры обладает приведёнными ниже преимуществами.

Обеспечивается более широкий доступ к существующим базам данных.

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

Стоимость аппаратного обеспечения снижается. Достаточно мощный ком пьютер с большим устройством хранения нужен только серверу — для хранения и управления базой данных.

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

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

Эта архитектура весьма естественно отображается на архитектуру открытых систем.

 

Интранет

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

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

Интранет построен на базе тех же понятий и технологий, которые используются для Интернета, такие как архитектура клиент-сервер и стек протоколов Интернет (TCP/IP).

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

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

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

Высокая производительность при совместной работе над какими-то общими проектами

Легкий доступ персонала к данным

Гибкий уровень взаимодействия: можно менять бизнес-схемы взаимодействия как по вертикали, так и по горизонтали.

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

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

Преимущества веб-сайта в интранет перед клиентскими программами архитектуры клиентсервер

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

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

электронной почте

Кросс-платформенная совместимость — стандартный браузер на Microsoft Windows, Mac, и GNU/Linux/*NIX. Недостатки интранет

Сеть может быть взломана и использована в целях хакера

Непроверенная или неточная информация, опубликованная в интранет, приводит к путанице и недоразумениям.

В свободном интерактивном пространстве могут распространяться нелегитимные и оскорбительные материалы.

Легкий доступ к корпоративным данным может спровоцировать их утечку к конкурентам через недобросовестного работника.

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

Файл-сервер

В данном случае сервер, на котором лежит база данных, является исключительно хранилищем и не обладает каким-либо функционалом, позволяющим производить математические и/или логические вычисления. Поэтому в файл-серверной архитектуре формирование отчета выглядит так: вся таблица с продажами за весь период, какой бы большой он ни был, по сети копируется на компьютер, запросивший формирование отчета. Когда передача этого файла закончена, непосредственно компьютер пользователя приступает к первичной фильтрации таблицы и последующему суммированию нужной колонки.
Логично предположить, что файл-серверная технология применима исключительно при работе с небольшими объемами данных, поскольку если объем данных будет велик, то это грозит существенными задержками работы сети и непосредственно пользовательских компьютеров, которые, как известно, изначально не предполагают больших нагрузок, и имеют довольно таки невысокую производительность. В результате компьютеры пользователей будут банально виснуть, общая производительность труда упадет.
Технологию файл-сервер используют все программы 1С версии 7.7 и ранее, а так же некоторые версии 8.х

Клиент-сервер

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