авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |

«УДК 002.52/.54(075.8) ББК 32.973.202я73 МИНОБРНАУКИ РОССИИ ...»

-- [ Страница 3 ] --

В соответствии с приведенными определениями для оценки количества информации, содержащейся в источнике необходимо измерять количество информации, содержащейся в единственном выходе источника (“0” или ”1”), т. е. нужно научиться сопоставлять некоторое количество информации произвольной случайной величине.

Энтропия является мерой количества неопределенности, содержащейся в этой случайной величине до ее наблюдения.

1 g Рош Рош 0 g Рис. 2.32 Модель двоичного симметричного дискретного канала без помех Проблемы передачи информации Синтаксические - правила построения и сочетания слов, выражений, сообщений в процессе преобразований I и II.

Семантические - смысловые содержания информации, сообщения, сигнала.

Прагматические - потребительское содержание и ценность информации, сообщения, сигнала.

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

До получения сведений о состоянии системы имеется ап¬риорная неопределенность ее состояния. Поэтому количество информации можно определить как меру снятой неопределенности, которая растет с ростом числа состояний системы.

Количественная мера информации устанавливается сле¬дующими аксиомами.

Аксиома 1. Количество информации, необходимое для снятия неопределенности состояния системы, представляет собой монотонно возрастающую функцию числа состояний системы.

В качестве количественной меры информации можно выбрать непосредственно число состояний системы mx, которое является единственной характеристикой множества X.

Однако такое определение неудобно с точки зрения его практического применения.

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

Аксиома 2. Неопределенность состояния сложной системы, состоящей из двух подсистем, равна сумме неопределенностей подсистем.

Если для снятия неопределенности первой подсистемы необходимо количество информации, равное I(т1), а для второй подсистемы количество информации, равное I(m2), то для снятия неопределенности сложной системы необходимо количество информации, равное I(m1m2) = I(m1) + I(m2), где т1 — число состояний первой подсистемы;

т2 — число состояний второй подсистемы;

т1 т2—число состояний сложной системы.

Единственным решением полученного функционального уравнения является логарифмическая функция I(т)=К logа т, которая определяет количество информации как логарифм числа состояний системы. Произвольный коэффициент К выбирается равным единице, а основание логарифма а определяет единицу измерения количества информации.

В зависимости от значения а единицы измерения называются двоичными (а=2), троичными (а=3) и в общем случае а-ичными. В дальнейшем под символом log будем понимать двоичный логарифм. Двоичная единица иногда обозначается bit (от английского binary digit - двоичный знак).

Каждое передаваемое слово из п букв, записанное в алфавите, содержащем т букв, можно рассматривать как отдельное «укрупненное» состояние источника сообщений.

Всего таких состояний (слов) будет тn.

Тогда количество информации, которое несет слово из п букв, равно I=logamn=nlogam.

Отсюда следует, что одна буква несет logam а-ичных единиц информации. Если единица измерения информации а=т, то количество информации в слове (I=п) измеряется количеством содержащихся в нем букв, а единица измерения информации определяется размером алфавита т. Таким образом, одна a-ичная единица содержит logam a-ичных единиц информации.

Определение количества информации по К. Шеннону Допустим, некоторое устройство вырабатывает (генерирует) число как независимую последовательность из единиц и нулей, которые появляются соответственно с вероятностя ми, равными p и q=1— р. В этом случае при неограниченном возрастании длины последовательности п с вероятностью, равной единице, появляются последовательности, количество единиц в которых незначительно отличается от среднего значения, равного пр.

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

Последовательность назовем типичной для заданного источника, если количество единиц п1 в ней удовлетворяет неравенству n1 p или n1 np n, (1) n и нетипичной в противном случае, то есть когда [n1 np[ n. (2) Вероятность появления нетипичной последовательности равна вероятности, с которой п1 удовлетворяет неравенству (2). Для оценки этой вероятности воспользуемся неравенством Чебышева, которое для произвольной случайной величины имеющей конечную дисперсию, при каждом b0 записывается в виде P{ - b}, b где и — соответственно математическое ожидание и дисперсия случайной b = n, 2 = n21 = npq,. Полaгая = n, = n = np, величины (q=(1-p)) получим 1 аналогичное неравенство для случайного числа единиц n1:

P{n1 np n } 2n.

pq Следовательно, вероятность появления нетипичной последовательности pq PTH 2, n а вероятность появления типичной последовательности pq PT = 1 PHT 1 2.

n Вероятность РHT стремится к нулю, а вероятность РT стремится к единице при любом сколь угодно малом значении и неограниченном возрастании длины последовательности п. Интервал [ n, n ]. которому принадлежит количество единиц в типичной последовательности, неограниченно увеличивается ( n ), хотя относительная n np всегда меньше значения. Докажем, что одновременно с величина интервалa n неограниченным увеличением длины последовательности п можно уменьшать значение = (n) с такой скоростью, при которой относительная величина интервала будет стремиться к нулю, а вероятность появления типичной последовательности—к единице.

При этом абсолютная величина интервала по-прежнему неограниченно возрастает.

Вероятность РT стремится к единице, если величина 2 (n)n неограниченно увеличивается с ростом n. Пусть 2 (n)n = n 2, где 0 некоторый параметр, определяющий скорость роста величины 2 (n)n.

Oтсюда (n) = n 0,5+ (0 0,5) Величина (n) стремится к нулю с ростом п при 0,5. При этом абсолютная величина интервала n (n) не может быть постоянной или стремиться к нулю одновременно с неограниченным увеличением величины 2 (n)n, стремлением (n) к нулю.

Определим количество типичных последовательностей Q. Вероятность появления произвольной последовательности Bk равна P ( B ) = P n1 q nn1.

k В результате тождественных преобразований P( Bk ) = p np + ( n1 np ) q nq +( n n1 nq ) = ( n1 np ) I p =p q np nq.

q Прологарифмировав последнее равенство, получим logmP(Bk)=nplogmp+nqlogmq+ p + (n1 np) log m = n[ p log m p q log m q q n np p 1 log m ] = n[ H ( x) O(n)], n q где величина H(x)=-plogmp-qlogmq является характеристикой источника сообщений и называется энтропией.

Свойства Энтропии mX 1. Неотрицательность: H ( X ) = pi log pi 0.

i = 2. Ограниченность:

, что вытекает из неравенства Йенсена для вогнутой функции и.

Если все элементов из равновероятны, то.

3. Если независимы, то.

4. Энтропия — выпуклая вверх функция распределения вероятностей элементов.

5. Если имеют одинаковое распределение вероятностей элементов, то.

Поскольку pi удовлетворяет неравенству 0 pi 1. Энтропия H(Х)=0, когда система находится в одном из состояний с вероятностью, равной единице, и во всех остальных—с вероятностью, равной нулю. При этом имеется в виду, что lim pi log pi = 0.

pi При равномерном распределении pi = энтропия mX (X)=log mx Есть доказательство, что это максимальное значение энтропии.

Литература: [1];

[5].

2.6 Лекция: Методология проектирования информационных систем Обобщим ряд положений системного анализа в набор аксиом существования сложных систем:

Аксиома целостности (эмерджентность). Свойства сложной системы не есть простая сумма свойств подсистем.

Аксиома автономности. Сложная система подчиняется своему частному закону (метрике) не зависящему от внешней среды. Частные законы имеют модельный характер и действуют только при адекватности модели.

Аксиома дополнительности. Сложная система во взаимодействии со средой может проявлять различные свойства в различных ситуациях.

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

Аксиома неопределенности (инертности). Чем точнее измерение, тем больше затраты времени, тем больше изменений в самой системе, тем больше ошибки измерения.

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

На основе анализа существующих аксиом можно сказать следующее:

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

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

Наиболее существенными чертами сложных систем являются:

наличие общей задачи и единой цели функционирования для всей системы;

большое количество взаимодействующих частей или элементов, составляющих систему;

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

иерархическую структуру связей подсистем и иерархию критериев качества функционирования всей системы;

сложность поведения системы, связанную со случайным характером внешних воздействий и большим количеством обратных связей внутри системы;

устойчивость по отношению к внешним и внутренним помехам и наличие самоорганизации и адаптации к различным возмущениям;

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

Постановка задачи разработки ИС.

На этом этапе специалист руководствуется вопросами Что, Где, Когда, Как и Почему.

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

Структуризация системы..

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

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

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

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

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

Завершающим этапом системного анализа является исследование модели. Основным назначением этого этапа является выяснение поведения моделируемого объекта в различных условиях, при разных состояниях самого объекта и внешней среды Две парадигмы процесса разработки информационных систем.

Прагматическая (как разрабатывать) и апрагматическая (что разрабатывать):

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

1. Апрагматическая методология – конструктивная часть методологии разработки ПС, которая отвечает на вопрос «что проектируется?» или «что моделируется?». Она описывает продукты проектирования как особого рода системотехнические артефакты. В рамках данной методологии решаются задачи параметрического синтеза и анализ.

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

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

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

Прагматическая парадигма уходит в другую крайность – область теоретических концепций построения системы «идеальных» планов действий. Основной системой исследования является «система технологических действий», при этом объект разработки рассматривается как инертный выходной продукт процесса разработки.

Апрагматическую методологию моделирования можно описать как отображение M на множество оценок среза произведения бинарных отношений: множества целей C и множества признаков P, множества признаков и множества технических решений X. Тогда целевая функция проектирования запишется как:

(M: (G*J(C))-E)-opt, где E - множество оценок, J(CxP), G (PxX).

Системологические факторы в апрагматической методологии учтем посредством формального определения сложной системы.

Сложная системы S – это комбинация множества Sm={sm1.. smj} первичных элементов, выделенных из универсального множества элементов Sa={s1.. sg} в соответствие с основанием A={a1.. ae}, взятых в отношениях R={r1.. rh} и объединенных по композиционным законам Z={z1.. zd}.

Каждый элемент siSa, обладает некоторым общетехническими свойствами Koi и функциональными свойствами Kfi, которые могут выполняться на некотором качественном уровне Kqi. Именно способность выполнять некоторые локальные функции и является признаком выделения первичных элементов smв универсальном множестве Sa. Таким образом основание А можно представить как подмножество объединения всех свойств всех элементов из Sa.

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

Исходя из вышеизложенного, задача модельного представления системы может быть представлена следующим образом: определить композицию первичных элементов S, выделенных из универсального множества Sa на основании A, взятых в отношении R и объединенных по композиционным правилам Z так, что в результате этого объединения появляются системообразующие свойства Ksc, а также общетехнические свойства Kso, следствием чего является возникновение интеграционных свойств Ksp, не адекватных свойствам первичных элементов и не являющихся линейной комбинацией системообразующих свойств системы Ksc. При этом оператор Q отражает соответствие данному набору интеграционных и системообразующих свойств определенной количественной мере Kq потребительского качества синтезируемой системы.

Выбор оптимальной организации моделируемой системы осуществляется на основе оценки принятых свойств системы Ks=KsoKscKspKsq (общетехнических свойств Kso, системообразующих свойств Ksc, интеграционных потребительских свойств Ksp и свойств качества Ksq).

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

Em=Ksp-Ksm, где Ksp– выходные характеристики реального объекта, Ksm– выходные характеристики модели.

Прагматическая методология.

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

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

Рис. 2.33 Схемы подходов к прагматическому проектированию.

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы решить эти задачи, используют ряд представлений архитектуры: например, логическое, физическое, представление данных, представление процессов. Чтобы определить и выразить различные аспекты процесса разработки, применяются такие методики, как сети Петри (помогают определить параллельность и синхронизацию), машины с конечным числом состояний (состояния и режимы), структурный анализ (потоки данных) и PSL/PSA (Problem Statement Language/Problem Statement Analysis), чтобы описать работу системы.

В рамках разработки программ объектно-ориентированный анализ обеспечивает инкрементальный подход к определению требований, проектированию и разработке систем, интенсивно использующих программное обеспечение. Для определения и представления этих требований служит язык Unified Modeling Language. UML допускает создание спецификации продукта, не зависящей от языка программирования или конкретного процесса разработки.

Метод OOSE (Object-Oriented Software Engineering) - это систематизированный метод промышленной разработки программного обеспечения (ПО), разработанный Иваром Якобсоном. Он основывается на проектировании, управляемом видами использования подходе, центральным звеном которого является понимание того, как фактически используется система.

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

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

Ошибочная основа будет иметь серьёзные последствия. для цикла жизни системы.

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

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

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

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

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

Рис. 2.36 Процессы взаимодействуют при разработке новой версии системы.

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

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

Анализ Цель процесса анализа - проанализировать, определить и описать систему, которая должна быть построена. Разрабатываемые модели будут описывать что должна делать система. Основа моделирования - требования заказчика или конечного пользователя к системе, выраженные в некоторой форме. Поэтому важно провести диалог с клиентами и предполагаемыми пользователями, чтобы убедиться в том, что строящаяся система именно та, которая требуется. На фазе анализа мы строим модели, которые облегчат нам понимание системы.

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

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

В конечном счёте, система должна быть адаптирована к среде реализации: это делается на этапе конструирования.

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

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

Конструирование Какова же цель процесса конструирования? Разве нельзя написать текст программы прямо из модели анализа, которая уже описывает и объекты системы, и как они относятся друг к другу? Есть три главные причины необходимости процесса конструирования.

Модель анализа недостаточно формальна, чтобы плавно перейти к тексту программы.

Мы должны уточнить объекты: какие следует предложить операции, как в точности должна выглядеть связь между различными объектами, какие посылать сообщения и т. д.

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

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

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

Компонентное тестирование выполняется на специальном компоненте, который может быть разного размера, от класса до целой подсистемы. Первоначально компонент тестируется структурно (т. е. как "белый ящик"). Это означает, что мы используем наши знания о внутреннем устройстве компонента.

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

Модели Модель требований Модель требований состоит из модели видов использования, описаний интерфейса пользователя и объектной модели проблемной области.

Модель видов использования основывается на актёрах и видах использования. Эти понятия помогают определить, что существует вне системы (актёры) и что система должна уметь делать.

Рис. 2.37 Пример модели вида использования: система управления полётами Актёры представляют нечто, взаимодействующее с системой, т. е. все, что нуждается в обмене информацией с ней. Актер - не пользователь, а роль, которую пользователь может играть по отношению к системе. Пользователь - это человек (или, иногда, устройство), который использует систему.

Мы рассматриваем актёры как классы, а пользователей - как экземпляры этих классов. Такие экземпляры существуют только когда пользователь что-то делает в системе.

Один и тот же человек может, следовательно, появится в виде экземпляров нескольких актёров.

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

Примером вида использования может быть "подтверждение полёта, которое должен сделать пилот". Точно как и в случае с актёрами, мы рассматриваем вид использования как класс. Когда выполняется вид использования, мы рассматриваем это как порождение экземпляра класса. Экземпляр существует, пока действует вид использования. Модель видов использования структурируется различными отношениями между видами использования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сигнал посылается от одного блока к другому для запуска некоторого действия в этом объекте. Это действие может послать новые сигналы другим блокам.

Блоки прямо соответствуют модулям в целевом языке. Например, в Cи++ типичный блок будет отображаться в один файл (фактически в два, с расширениями. h и. с), включающий один или несколько классов. В Аде естественно отображать блок в пакет. На целевой модуль ссылаются как на объектный модуль. Например, в Cи++ объектный модуль - класс, в Аде - пакет. Интерфейсы блоков будут отображаться в объектные модули конкретного языка и служить как интерфейсы этих модулей (файл. h в Cи++, часть спецификации в пакете Ады). Блок может поэтому быть реализован одним или несколькими объектными модулями.

В течение процесса конструирования сложность возрастает очень сильно. Мы группируем объекты в подсистемы, которые могут быть использованы в моделях как анализа, так и проектирования. Они рекурсивным образом могут включать другие подсистемы. Таким образом, мы иерархически структурируем систему, чтобы справиться с её сложностью.

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

Обычно, внешняя среда системы, её граница, представляется самой левой колонкой.

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

Диаграммы взаимодействий управляются событиями. Новое событие приводит к возникновению новой операции. Эти события - сигналы, которые посылаются от одного объекта другому и инициируют операцию. Рис. 2.39 даёт пример диаграммы взаимодействий.

Рис. 2.39 Пример диаграммы взаимодействий в системе утилизации мусора На диаграмме вид использования начинается, когда клиент нажимает кнопку старта.

После этого блок customer panel (панель клиента) активизирует внешние по отношению к системе сенсоры. Теперь клиент может начать загрузку пустых бутылок, консервных банок и упаковочных корзин. Это решается оператором DO... WHILE, который заканчивается, когда клиент запрашивает квитанцию. Сдаваемые предметы проверяются этим циклом;

если предмет принят, мы увеличиваем число предметов этого типа, загруженного клиентом и общее число за день. Заметим, что увеличение общего числа за день поручается блоку Receipt Basis (База приёмки).

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

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

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

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

Анализ требований На основе спецификаций требований и дискуссий с предполагаемыми пользователями разрабатываются две различные модели: модель требований и модель анализа. Модель требований задаёт границы системы и определяет, какие функции предлагает система. Эта точка зрения разработчика на то, что хочет заказчик, и она служит в качестве контракта между разработчиком и клиентом. Модель требований обычно состоит из трёх частей: модели видов использования, объектной модели предметной области и описания пользовательского интерфейса. Модель видов использования определяет функциональность, которую система предлагает с точки зрения пользователя и определяет, что должно происходить внутри системы. Она использует актёры для представления ролей, которые могут играть пользователи, и виды использования для представления того, что пользователи могут делать в системе. Каждый вид использования завершённый круг событий в системе с точки зрения пользователя. Если необходимо, может также быть разработано описание интерфейса пользователя. Оно определяет в деталях, как должен выглядеть интерфейс пользователя, когда выполняется заданный вид использования.

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

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

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

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

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

Каковы главные задачи каждого актёра?

Должен ли актёр читать/писать/изменять некоторую системную информацию?

Должен ли актёр информировать систему об изменениях, происшедших вне её?

Желает ли актёр быть проинформирован о непредусмотренных изменениях?

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

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

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

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

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


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

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

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

Анализ прочности Разработка модели анализа в действительности влечёт за собой распределение определённого видами использования поведения среди объектов модели. Объект может быть общим для нескольких различных видов использования, и мы должны определить, какой объект отвечает за представление какого поведения в каждом виде использования.

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

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

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

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

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

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

Найти необходимые объекты обычно легко;

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

После того, как будут определены все объекты анализа, система может содержать большое число объектов: от 30 до 100 для проекта среднего размера. Объекты нужно сгруппировать в один или более уровней, в зависимости от размера системы. Группы объектов называются подсистемами. Подсистемы могут содержать подсистемы.

Подсистемы самого низкого уровня, называемые сервисными пакетами, рассматриваются как единицы изменения. Они считаются неразделяемыми, или атомами:

клиент берет или всю единицу или ничего.

Конструирование На этапе конструирования система строится на основе моделей анализа и требований.

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

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

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

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

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

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

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

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

Модели MRP/ERP Исторически, методология Enterprise Requirement Planning (ERP), то есть планирование ресурсов предприятия, является результатом последовательного развития, начавшегося с концепции Material Resource Planning (MRP), обеспечивавшей планирование потребностей предприятий в материалах. Преимущества, даваемые MRP, состоят в минимизации издержек, связанных со складскими запасами сырья, комплектующих, полуфабрикатов и прочего, а также с аналогичными запасами, находящимися на различных участках непосредственно в производстве.

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

На основании плана выпуска продукции, BOM и технологической цепочки в MRP системе осуществляется расчет потребностей в материалах в зависимости от конкретных сроков выполнения тех или иных технологических операций.

Однако у методологии MRP есть серьезный недостаток. При расчете потребности в материалах не учитываются загрузка и амортизация производственных мощностей, стоимость рабочей силы, потребляемой энергии и т. д. Поэтому в качестве логического развития MRP была разработана концепция Manufacturing Resource Planning (планирование производственных ресурсов), сокращенно называемая MRP II. В рамках MRP II можно уже планировать все производственные ресурсы предприятия: сырье, материалы, оборудование, людские ресурсы, все виды потребляемой энергии и пр.

Далее концепция MRP II развивалась в соответствии с тенденциями изменения рынка и порождаемыми ими новыми потребностями в управлении предприятиями. К MRP II постепенно добавлялись возможности по учету и управлению другими затратами предприятия. Так появилась концепция ERP, называемая иногда также Enterprise-wide Resource Planning (планированием ресурсов в масштабе предприятия). В основе методологии ERP лежит принцип единого хранилища данных (repository), содержащего всю деловую информацию, накопленную организацией в процессе ведения бизнеса, включая финансовую информацию, данные, связанные с производством, управлением персоналом, или любые другие сведения. Это устраняет необходимость в передаче данных от одной информационной системы к другой и создает дополнительные возможности для анализа, моделирования и планирования. Кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями.


Начиная с середины 90-х годов, концепция ERP стала очень популярной в производственном секторе, поскольку ее использование для планирования ресурсов позволило существенно сократить время выпуска продукции, снизить уровень товарно материальных запасов.

Итак:

1. MRP (Material Requirement Planning) - это планирование потребности в материалах;

2. MRP II (Manufacturing Resource Planning) - это планирование производственных ресурсов;

3. ERP (Enterprise Resource Planning) - это планирование ресурсов всего предприятия.

Стандарты MRP/ERP поддерживаются Американским обществом по контролю за производственными запасами APICS (American Production and Inventory Control Society).

MRP/ERP - это набор проверенных на практике разумных принципов, моделей и процедур управления и контроля, предназначенных для повышения показателей экономической деятельности предприятия. Изданный APICS в 1989 г. стандарт «MRP II Standard System», содержит 16 групп функций:

Планирование продаж и производства (Sales and Operation Planning);

Управление спросом (Demand Management);

Составление плана производства (Master Production Scheduling);

Планирование материальных потребностей (MRP - Material Requirement Planning);

Спецификацияпродуктов (Bill of Materials);

Управлениезапасами (Inventory Transaction Subsystem);

Управление плановыми поставками (Scheduled Receipts Subsystem);

Управление на уровне производственного цеха (Shop Flow Control);

Планирование производственных мощностей (CRP - Capacity Requirement Planning);

Контроль входа/выхода рабочих потоков (Input/output control);

Материально техническое снабжение (Purchasing);

Планирование ресурсов для распределения (DRP - Distribution Resource Planning);

Планирование и контроль производственных операций (Tooling Planning and Control);

Управление финансами (Financial Planning);

Моделирование для производственной программы (Simulation);

Оценка результатов деятельности (Performance Measurement).

Сегодня модель MRP/ERP включает в себя следующие подсистемы, которые часто называют также блоками или сериями:

1. управление запасами;

2. управление снабжением;

3. управление сбытом;

4. управление производством;

5. планирование;

6. управление сервисным обслуживанием;

7. управление цепочками поставок;

8. управление финансами.

Управление запасами Эта подсистема обеспечивает реализацию следующих функций:

1) Inventory Control - мониторингзапасов;

2) Physical Inventory - регулирование и инвентаризация складских остатков.

Управления снабжением Подсистема реализует следующие функции:

1) Purchase Orders - заказыназакупку;

2) Supplier Schedules - графикпоставок;

3) MRP - планирование потребности в материалах, понимаемое как управление заявками на закупку.

Управление сбытом Базовыми функциями этой подсистемы являются:

1) Sales Quotations - квотирование продаж;

2) Sales Orders / Invoices - заказы на продажу (счета фактуры);

3) Customer Schedules - график продаж потребителям;

4) Configured Products - конфигурирование продуктов;

5) Sales Analysis - анализ продаж;

6) Distributed Resource Planning (DRP) - управления ресурсами распределения.

Управления производством В этой подсистеме реализуются следующие функции, соответствующие различными типам производственных процессов:

1) Product Structures - спецификация изделий, определяющая, какие материалы и комплектующие используются в производимом изделии;

2) Routings / Work Centers - операции/центры переработки, включает в себя описание цехов, участков, рабочих мест;

3) Formula / Process - технологические процессы производства продукции с маршрутизацией по рабочим центрам для объемного (процессного) производства.

4) Work Orders - наряд-задание (сменное задание) на производство работ для позаказного и мелкосерийного производства;

5) Shop Floor Control - управление трудозатратами (диспетчирование);

6) Repetitive - поточное производство (для серийного и массового производства).

7) Quality Management - управление качеством, то есть описание различных проверок изделий во время производственного процесса.

Планирование Подсистема планирования реализует следующие функции:

1. Product Line Planning (PLP) - финансовое планирование товарно - номенклатурных групп (ТНГ);

2. Master Scheduling Planning (MSP) - главный календарный график или объемно календарное планирование;

3. Distribution Resource Planning (DRP) - планирование распределения ресурсов (RCP);

4. Materials Requirements Planning (MRP) - планирование потребности материалов;

5. Capacity Requirements Planning (CRP)- планирование потребления мощностей.

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

Управление цепочками поставок Эта подсистема предназначена для обеспечения эффективного управления материальными и соответствующими им информационными потоками: от поставщика через производство к потребителю.

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

В подсистеме реализована функциональность:

General Ledger - главная бухгалтерская книга, предназначенная для отражения финансовых транзакций и ведения бухгалтерского учета;

Multiple Currency - мультивалютность, для ведения учета в разных валютах;

Accounts Receivable - дебиторская задолженность;

Accounts Payable - кредиторская задолженность;

Payroll - заработная плата;

Cost Management - управление себестоимостью;

Cash Management - управление платежами;

Fixed Assets - учет основных средств.

Модели PLM.

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

1. Анализ требований рынка. Осознание и понимание того, насколько востребован рынком новый продукт.

2. Выработка концепции проекта. На основе анализа требований рынка формируется общая идея нового продукта.

3. Проектирование. Создается проект новой продукции.

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

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

6. Дистрибуция. Готовый продукт поставляется либо дистрибутору, либо непосредственно заказчику.

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

Product Lifecycle Management PLM (Product Lifecycle Management - управление жизненным циклом продукта). PLM - это набор программных компонентов обеспечения коммуникаций, интеграции модулей автоматизированного проектирования и визуализации, а также других решений, охватывающих полный жизненный цикл продукта. Решения класса PLM призваны объединить всех участников, обеспечивающих жизненный цикл как внутри предприятия производителя, так и вне его, в том числе поставщиков, клиентов и сервисных центров.

Хранилище PLM позволяет производителю сохранить опыт, накопленный на предыдущих проектах, значительно упростить контроль за актуальностью информации, идентифицировать ошибки и избежать перепроектирования (по оценкам компании Aberdeen, не менее 70 % затрат на производство и сопровождение продукции приходится на этап проектирования).

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

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

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

Системы PLM появились примерно 20 лет назад, но вскоре возникла необходимость отделить автоматизацию процессов проектирования и подготовки производства (CAD/САМ) от управления информацией, сопровождающей изделия. Тогда появилось самостоятельное от CAD/САМ направление Product Data Management (PDM), т. е.

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

- жизненный цикл определения изделий (интеллектуальные активы предприятия);

- жизненный цикл производства (материальные активы предприятия);

- жизненный цикл операционной поддержки.

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

Литература: [2];

[3];

[4];

[6];

[7];

[8];

[9];

[11].

2.7 Лекция: Современные подходы к разработке информационных систем Одним из наиболее известных направлений, образовавшихся в 1980-е гг., является инженерия программного обеспечения с компьютерной поддержкой (Computer-Aided Software Engineering, CASE), которая обеспечивает методы и средства разработки программного обеспечения, позволяющие разработчикам выражать свои конструкции с использование графических программных средств общего назначения, различного вида диаграмм. Одной из целей CASE-средств было обеспечение более тщательного анализа графических программ за счет их меньшей сложности, чем у программ, представленных на традиционных языках программирования (например, в графических программах невозможны ошибки, приводящие к повреждению памяти).

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

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

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

В результате в 1980-1990-е гг. подход CASE оказывал сравнительно небольшое влияние на разработку коммерческого программного обеспечения, фокусируясь на нескольких прикладных областях, например, на обработке вызовов в телекоммуникационных системах, где хорошо подходили представления в виде конечных автоматов.

Многообещающим подходом является разработка технологий инженерии, управляемой моделями, (Model-Driven Engineering, MDE). При использовании MDE разработка ведется на предметно-ориентированных языках моделирования (Domain Specific Modeling Language, DSML), в системах типов которых формализуется структура, поведения и требования приложения внутри соответствующей предметной области. DSML описываются с использованием метамоделей, в которых определяются связи между понятиями предметной области и точно специфицируется основная семантика и ограничения, ассоциируемые с этими понятиями. Разработчики применяют DSML для построения приложений, используя элементы системы типов, зафиксированной в метамодели, и выражают проектный замысел в декларативном, а не императивном стиле.

Важнейшими компонентами MDE являются трансформационные процессоры и генераторы, которые анализируют определенные аспекты моделей и синтезируют разные вида артефактов: исходный код, входные данные для имитационного моделирования, XML-описания развертывания или альтернативные представления моделей. Возможность синтеза артефактов на основе моделей помогает поддерживать согласованность между реализациями приложения и аналитической информацией о требованиях к функциональных возможностям системы и ее качества, зафиксированных в модели. Этот автоматический трансформационный процесс часто называют "правильным по построению" ("correct-by-construction") в отличие от утомительного и чреватого ошибками традиционного процесса разработки программного обеспечения вручную в стиле "построения путем коррекции" ("construct-by-correction").

Исторически методологии разработки программного обеспечения фокусируются в большей степени на совершенствовании средств разработки систем, а не на создании инструментов, помогающих конструировать и интегрировать системы. Компонентное программное обеспечение промежуточного слоя (Enterprise Java-Beans (EJB), Microsoft.

NET и CORBA Component Model (CCM)) способствуют повышению уровня повторного использования программного обеспечения на основе абстракции компонента.

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

Разработка, управляемая моделями (Model-Driven Development, MDD) - это развивающаяся парадигма, решающая многочисленные проблемы композиции и интеграции крупномасштабных систем и опирающаяся при этом на имеющиеся достижения в области технологий разработки программного обеспечения (в частности, на компонентное промежуточное программное обеспечение). MDD позволяет перевести разработку программного обеспечение на более высокий уровень абстракции по сравнению с тем, который возможен при использовании языков третьего поколения. Для представления элементов системы и их связей в подходе MDD используются модели.

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

Популярным вариантом MDD является модельно-управляемая архитектура (Model Driven Architecture, MDA), предложенная и развиваемая консорциумом Object Management Group (OMG). В подходе MDA системы представляются с использованием языка моделирования общего назначения Unified Modeling Language (UML) и его конкретных профилей. Эти модели преобразуются в артефакты, выполняемые на разнообразных платформах, в частности, на EJB,. NET и CCM.

MDA Основная цель MDA — минимизация затрат, связанных с привязкой к конкретным системным платформам и программным инфраструктурам. Для этого вводятся вышестоящие уровни описаний программной системы и предметной области, на основе которых в идеале решается или облегчается задача генерации программного кода, настроек, параметров и т. п. для различных платформ.

Ядром MDA являются несколько стандартов — UML, MOF, CWM и XMI. Язык UML (Universal Modeling Language) используется для описания всех моделей. Совокупность метамоделей CWM (Common Warehouse Model) представляет наиболее часто используемые в базах данных и инструментах бизнес-анализа метаданные. CWM содержит большое количество различных метамоделей, описывающих функционирование бизнеса. MOF (Meta Object Facility) — общий абстрактный язык для описания метамоделей;

на его основе построены формальные описания метамодели для CWM и UML. Последний стандарт, XMI (XML Metadata Interchange), играет служебную роль, описывая отображение моделей MOF и UML на стандарт XML. При этом метамодели преобразуются в DTD-структуру документа, а модели — в тело XML-документа. Это позволяет объединить модель и ее метамодель в одном документе и получить так называемый «самоописываемый» (self describing) документ, содержащий не только данные, но и информацию, необходимую для их интерпретации.

В основе MDA лежит понятие платформно-независимой модели (platform independent model, PIM). Речь идет о детальной исполняемой модели на языке действий UML (action semantics) с пред- и постусловиями, сформулированными на OCL.

Для описания PIM выбран язык UML.

Рис. 2.40 Стандарты, на которые опирается MDA Результатом первого этапа разработки в соответствии с подходом MDA является описание PIM на языке UML. Завершенная платформно-независимая модель содержит полное описание системы, однако свободна от деталей, относящихся к реализации и используемым технологиям. После того, как модель построена, ее необходимо преобразовать в платформно-зависимую модель (platform-specific model, PSM). Это преобразование производится с помощью разработанных OMG стандартных отображений, разных для каждой платформы промежуточного слоя;

при этом в модель вносится информация, относящаяся к деталям практической реализации и выбранной платформе.

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

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



Pages:     | 1 | 2 || 4 | 5 |   ...   | 6 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.