WWW.LIB.KNIGI-X.RU
Ѕ≈—ѕЋј“Ќјя  »Ќ“≈–Ќ≈“  Ѕ»ЅЋ»ќ“≈ ј - Ёлектронные матриалы
 


Pages:   || 2 |

Ђ—одержание 1. ћ≈—“ќ ƒ»—÷»ѕЋ»Ќџ ¬ —“–” “”–≈ ќЅ–ј«ќ¬ј“≈Ћ№Ќќ… ѕ–ќ√–јћћџ 3 2. ѕ≈–≈„≈Ќ№ –≈«”Ћ№“ј“ќ¬ ќЅ”„≈Ќ»я 4 3. —ќƒ≈–∆јЌ»≈ » —“–” “”–ј ƒ»—÷»ѕЋ»Ќџ (ћќƒ”Ћя) 5 4. ...ї

-- [ —траница 1 ] --

—одержание

1. ћ≈—“ќ ƒ»—÷»ѕЋ»Ќџ ¬ —“–” “”–≈ ќЅ–ј«ќ¬ј“≈Ћ№Ќќ… ѕ–ќ√–јћћџ 3

2. ѕ≈–≈„≈Ќ№ –≈«”Ћ№“ј“ќ¬ ќЅ”„≈Ќ»я 4

3. —ќƒ≈–∆јЌ»≈ » —“–” “”–ј ƒ»—÷»ѕЋ»Ќџ (ћќƒ”Ћя) 5

4. ”„≈ЅЌќ-ћ≈“ќƒ»„≈— ќ≈ ќЅ≈—ѕ≈„≈Ќ»≈ —јћќ—“ќя“≈Ћ№Ќќ… –јЅќ“џ

—“”ƒ≈Ќ“ќ¬ 9

5. ‘ќЌƒ ќ÷≈Ќќ„Ќџ’ —–≈ƒ—“¬ 10

5.1 “»ѕќ¬џ≈ ќ÷≈Ќќ„Ќџ≈ ћј“≈–»јЋџ 17

5.2 ћ≈“ќƒ»„≈— »≈ ћј“≈–»јЋџ, ќѕ–≈ƒ≈Ћяёў»≈ ѕ–ќ÷≈ƒ”–џ

ќ÷≈Ќ»¬јЌ»я –≈«”Ћ№“ј“ќ¬ ќЅ”„≈Ќ»я («ЌјЌ»…, ”ћ≈Ќ»…,

¬Ћјƒ≈Ќ»…), ’ј–ј “≈–»«”ёў»’ Ё“јѕџ ‘ќ–ћ»–ќ¬јЌ»я

 ќћѕ≈“≈Ќ÷»… 108

6. ”„≈ЅЌќ-ћ≈“ќƒ»„≈— ќ≈ » »Ќ‘ќ–ћј÷»ќЌЌќ≈ ќЅ≈—ѕ≈„≈Ќ»≈

ƒ»—÷»ѕЋ»Ќџ (ћќƒ”Ћя) 112

7. ќЅ–ј«ќ¬ј“≈Ћ№Ќџ≈ “≈’ЌќЋќ√»» 113

8. ћ≈“ќƒ»„≈— »≈ ” ј«јЌ»я ѕќ ќ—¬ќ≈Ќ»ё ƒ»—÷»ѕЋ»Ќџ 113

9. ћј“≈–»јЋ№Ќќ-“≈’Ќ»„≈— ќ≈ ќЅ≈—ѕ≈„≈Ќ»≈ ƒ»—÷»ѕЋ»Ќџ 115

10. јƒјѕ“ј÷»я –јЅќ„≈… ѕ–ќ√–јћћџ ƒЋя Ћ»÷ — ќ¬« 115 ћесто дисциплины в структуре образовательной 1.

программы ƒисциплина —истемна€ инженери€ (пороговый уровень) €вл€етс€ дисциплиной вариативной части ќѕќѕ по направлению подготовки 09.04.02 »нформационные системы и технологии. явл€етс€ дисциплиной по выбору обучающихс€.

–абоча€ программа составлена в соответствии с требовани€ми ‘едерального государственного образовательного стандарта высшего образовани€ по направлению подготовки магистров 09.04.02 »нформационные системы и технологии, утвержденного приказом ћинистерства образовани€ и науки –оссийской ‘едерации от "30" окт€бр€ 2014 г. є 1420. явл€етс€ неотъемлемой частью основной образовательной профессиональной программы (ќѕќѕ).

÷елью освоени€ дисциплины €вл€етс€ формирование у будущих магистров в области информационных систем и технологий теоретических знаний и практических навыков дл€ решени€ научно-исследовательских и прикладных задач св€занных с созданием (развитием) систем различного вида и назначени€.

«адачи:

овладение знани€ми и достижение понимани€:

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

- роли и места системного инженера в процессе создани€ сложных систем;

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

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

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

- характеристик и особенностей практического применени€ процессов жизненного цикла систем и программных средств на примере стандартов группы »—ќ 15288 и »—ќ 12207;

- проблемы прин€ти€ решений при создании сложных систем;

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

Ц  Ц  Ц

”чебно-методическое обеспечение самосто€тельной работы 4.

студентов –аздел 1. ¬ведение в системную инженерию.

¬опросы дл€ самосто€тельного изучени€ (подготовке к обсуждению):

ћесто системной инженерии в процессе разработки и эксплуатации 1.

информационных систем.

—в€зь системной инженерии с программной инженерии и управлени€ми 2.

проектами.

—тандарты системной инженерии.

3.

–аздел 2. јнализ заинтересованных лиц.

¬опросы дл€ самосто€тельного изучени€:

ѕон€тие требовани€.  лассификаци€ требований.

1.

2. Onion-модель.

–аздел 3. ќпределение требований.

Ц  Ц  Ц

‘онд оценочных средств 5.

ќценка уровн€ освоени€ дисциплины осуществл€етс€ в виде текущего и промежуточного контрол€ успеваемости магистрантов, и на основе критериев оценки уровн€ освоени€ дисциплины.

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

ќбъектами оценивани€ выступают:

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

степень усвоени€ теоретических знаний;

уровень овладени€ практическими умени€ми и навыками по всем видам учебной работы;

результаты самосто€тельной работы.

јктивность обучающегос€ на зан€ти€х оцениваетс€ на основе выполненных работ и заданий, предусмотренных ‘ќ— дисциплины.

ќценивание проводитс€ преподавателем независимо от наличи€ или отсутстви€ обучающегос€ (по уважительной или неуважительной причине) на зан€тии.

ќценка носит комплексный характер и учитывает достижени€ обучающегос€ по основным компонентам учебного процесса за текущий период.

Ц  Ц  Ц

ѕри реализации дисциплины используетс€ балльно-рейтингова€ оценка освоени€ компетенций.

¬иды учебной Ѕалл за конкретное „исло Ѕаллы де€тельности задание заданий ћинимальный ћаксимальный

Ц  Ц  Ц

 ритерии оценки контрольных вопросов:

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

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

 ритерии оценок привод€тс€ ниже:

Ђќтличної Ц правильные и полные ответы на теоретические вопросы билета, примеры приведены правильно и с необходимыми по€снени€ми, верный ответ на практический вопрос.

Ђ’орошої Ц правильные, но недостаточно полные ответы на теоретические вопросы билета, правильно приведены примеры и на практический вопрос ответ в основном верный.

Ђ”довлетворительної Ц получены правильные, но недостаточно полные, ответы на два теоретических вопроса билета и на практический вопрос, не приведены примеры или получены правильные ответы на теоретические вопросы билета, в примере недостаточно по€снений и нет ответа на практический вопрос.

ЂЌеудовлетворительної Ц неполные ответы с ошибками в терминологии на теоретические и практические вопросы билета, отсутствуют необходимые примеры.

5.1 “иповые оценочные материалы ќценочные материалы дл€ лабораторных работ

Ћабораторна€ работа 1 1.

–аздел (тема) дисциплины: јнализ заинтересованных лиц.

«адание выполн€етс€ на лабораторной работе є 1 Ђ–азработка описани€ и анализ информационной системыї:

÷ель работы: ќписать и проанализировать информационную систему, распределить роли в группе разработчиков.

Ћабораторна€ работа направлена на ознакомление с процессом описани€ информационной системы и получение навыков по использованию основных методов анализа »—.

“ребовани€ к результатам выполнени€ лабораторного практикума:

наличие описани€ информационной системы;

1.

проведение анализа осуществимости выполнени€ проекта;

2.

наличие заключени€ о возможности реализации проекта, содержащего 3.

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

“еоретические сведени€: ќбщие сведени€ о разработке программного обеспечени€.ѕроблемы управлени€ программными проектами впервые про€вились в 60-х - начале 70-х годов, когда провалились многие большие проекты по разработке программных продуктов. Ѕыли зафиксированы задержки в создании ѕќ, оно было ненадежным, затраты на разработку в несколько раз превосходили первоначальные оценки, созданные программные системы часто имели низкие показатели производительности. ѕричины провалов коренились в тех подходах, которые использовались в управлении проектами. ѕримен€ема€ методика была основана на опыте управлени€ техническими проектами и оказалась неэффективной при разработке программного обеспечени€.

¬ажно понимать разницу между профессиональной разработкой ѕќ и любительским программированием. Ќеобходимость управлени€ программными проектами вытекает из того факта, что процесс создани€ профессионального ѕќ всегда €вл€етс€ субъектом бюджетной политики организации, где оно разрабатываетс€, и имеет временные ограничени€. –абота руководител€ программного проекта по большому счету заключаетс€ в том, чтобы гарантировать выполнение этих бюджетных и временных ограничений с учетом бизнес-целей организации относительно разрабатываемого ѕќ.

–уководители проектов призваны спланировать все этапы разработки программного продукта. ќни также должны контролировать ход выполнени€ работ и соблюдени€ всех требуемых стандартов. ѕосто€нный контроль за ходом выполнени€ работ необходим дл€ того, чтобы процесс разработки не выходил за временные и бюджетные ограничени€. ’орошее управление не гарантирует успешного завершени€ проекта, но плохое управление об€зательно приведет к его провалу. Ёто может выразитьс€ в задержке сроков сдачи готового ѕќ, в превышении сметной стоимости проекта и в несоответствии готового ѕќ спецификации требований.

ѕроцесс разработки ѕќ существенно отличаетс€ от процессов реализации технических проектов, что порождает определенные сложности в управлении программными проектами:

ѕрограммный продукт нематериален. ѕрограммное обеспечение нематериально, его нельз€ увидеть или потрогать. –уководитель программного проекта не видит процесс "роста" разрабатываемого ѕќ. ќн может полагатьс€ только на документацию, котора€ фиксирует процесс разработки программного продукта.

Ќе существует стандартных процессов разработки ѕќ. Ќа сегодн€шний день не существует четкой зависимости между процессом создани€ ѕќ и типом создаваемого программного продукта. ƒругие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. ѕроцессы создани€ большинства технических систем хорошо изучены. »зучением же процессов создани€ ѕќ специалисты занимаютс€ только последнее врем€. ѕоэтому пока нельз€ точно предсказать, на каком этапе процесса разработки ѕќ могут возникнуть проблемы, угрожающие всему программному проекту.

Ѕольшие программные проекты - это часто "одноразовые" проекты. Ѕольшие программные проекты, как правило, значительно отличаютс€ от проектов, реализованных ранее. ѕоэтому, чтобы уменьшить неопределенность в планировании проекта, руководители проектов должны обладать очень большим практическим опытом. Ќо посто€нные технологические изменени€ в компьютерной технике и коммуникационном оборудовании обесценивают предыдущий опыт. «нани€ и навыки, накопленные опытом, могут не востребоватьс€ в новом проекте.

ѕеречисленные отличи€ могут привести к тому, что реализаци€ проекта выйдет из временного графика или превысит бюджетные ассигновани€.

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

ѕроцесс управлени€ разработкой программного обеспечени€ Ќевозможно описать и стандартизировать все работы, выполн€емые в проекте по созданию ѕќ. Ёти работы весьма существенно завис€т от организации, где выполн€етс€ разработка ѕќ, и от типа создаваемого программного продукта.

Ќо всегда можно выделить следующие:

Ќаписание предложений по созданию ѕќ.

ѕланирование и составление графика работ по созданию ѕќ.

ќценивание стоимости проекта.

ѕодбор персонала.

 онтроль за ходом выполнени€ работ.

Ќаписание отчетов и представлений.

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

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

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

–еализаци€ этого плана приведет к достижению целей проекта. ќпределение стоимости проекта напр€мую св€зано с его планированием, поскольку здесь оцениваютс€ ресурсы, требующиес€ дл€ выполнени€ плана.

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

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

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

¬ течение реализации проекта обычно происходит несколько формальных контрольных проверок хода выполнени€ работ по созданию ѕќ. “акие проверки должны дать общую картину хода реализации проекта в целом и показать, насколько уже разработанна€ часть ѕќ соответствует цел€м проекта.

¬рем€ выполнени€ больших программных проектов может занимать несколько лет. ¬ течение этого времени цели и намерени€ организации, заказавшей программный проект, могут существенно изменитьс€. ћожет оказатьс€, что разрабатываемый программный продукт стал уже ненужным либо исходные требовани€ к создаваемому ѕќ просто устарели и их необходимо кардинально мен€ть. ¬ такой ситуации руководство организации-разработчика может прин€ть решение о прекращении разработки ѕќ или об изменении проекта в целом с тем, чтобы учесть изменившиес€ цели и намерени€ организации-заказчика.

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

“ака€ ситуаци€ может быть вызвана следующими причинами:

Ѕюджет проекта не позвол€ет привлечь высококвалифицированный персонал.

¬ таком случае за меньшую плату привлекаютс€ менее квалифицированные специалисты.

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

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

“аким образом, почти всегда подбор специалистов дл€ выполнени€ проекта имеет определенные ограничени€ и не €вл€етс€ свободным. ¬месте с тем необходимо, чтобы хот€ бы несколько членов группы разработчиков имели квалификацию и опыт, достаточные дл€ работы над данным проектом. ¬ противном случае невозможно избежать ошибок в разработке ѕќ.

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

¬ рамках курса Ђ—истемна€ инженери€ї выделены следующие роли в группе по разработке ѕќ:

–уководитель Ц общее руководство проектом, написание документации, общение с заказчиком ѕќ —истемный аналитик Ц разработка требований (составление технического задани€, проекта программного обеспечени€) “естер Ц составление плана тестировани€ и аттестации готового ѕќ (продукта), составление сценари€ тестировани€, базовый пример, проведение меропри€тий по плану тестировани€ –азработчик Ц моделирование компонент программного обеспечени€, кодирование ѕланирование проекта разработки программного обеспечени€ Ёффективное управление программным проектом напр€мую зависит от правильного планировани€ работ, необходимых дл€ его выполнени€. ѕлан помогает руководителю предвидеть проблемы, которые могут возникнуть на каких-либо этапах создани€ ѕќ, и разработать превентивные меры дл€ их предупреждени€ или решени€. ѕлан, разработанный на начальном этапе проекта, рассматриваетс€ всеми его участниками как руковод€щий документ, выполнение которого должно привести к успешному завершению проекта. Ётот первоначальный план должен максимально подробно описывать все этапы реализации проекта.

ѕроцесс планировани€ начинаетс€, исход€ из описани€ системы, с определени€ проектных ограничений (временные ограничени€, возможности наличного персонала, бюджетные ограничени€ и т.д.). Ёти ограничени€ должны определ€тьс€ параллельно с оцениванием проектных параметров, таких как структура и размер проекта, а также распределением функций среди исполнителей. «атем определ€ютс€ этапы разработки и то, какие результаты документаци€, прототипы, подсистемы или версии программного продукта) должны быть получены по окончании этих этапов. ƒалее начинаетс€ циклическа€ часть планировани€. —начала разрабатываетс€ график работ по выполнению проекта или даетс€ разрешение на продолжение использовани€ ранее созданного графика. ѕосле этого проводитс€ контроль выполнени€ работ и отмечаютс€ расхождени€ между реальным и плановым ходом работ.

ƒалее, по мере поступлени€ новой информации о ходе выполнени€ проекта, возможен пересмотр первоначальных оценок параметров проекта. Ёто, в свою очередь, может привести к изменению графика работ. ≈сли в результате этих изменений нарушаютс€ сроки завершени€ проекта, должны быть пересмотрены (и согласованы с заказчиком ѕќ) проектные ограничени€.

 онечно, большинство руководителей проектов не думают, что реализаци€ их проектов пройдет гладко, без вс€ких проблем. ∆елательно описать возможные проблемы еще до того, как они про€в€т себ€ в ходе выполнени€ проекта. ѕоэтому лучше составл€ть "пессимистические" графики работ, чем "оптимистические". Ќо, конечно, невозможно построить план, учитывающий все, в том числе случайные, проблемы и задержки выполнени€ проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создани€ программного продукта.

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

ƒетализаци€ планов проектов очень разнитс€ в зависимости от типа разрабатываемого программного продукта и организации-разработчика. Ќо в любом случае большинство планов содержат следующие разделы.

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

ќрганизаци€ выполнени€ проекта. ќписание способа подбора команды разработчиков и распределение об€занностей между членами команды.

јнализ рисков. ќписание возможных проектных рисков, веро€тности их про€влени€ и стратегий, направленных на их уменьшение.

јппаратные и программные ресурсы, необходимые дл€ реализации проекта.

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

–азбиение работ на этапы. ѕроцесс реализации проекта разбиваетс€ на отдельные процессы, определ€ютс€ этапы выполнени€ проекта, приводитс€ описание результатов ("выходов") каждого этапа и контрольные отметки.

√рафик работ. ¬ этом графике отображаютс€ зависимости между отдельными процессами (этапами) разработки ѕќ, оценки времени их выполнени€ и распределение членов команды разработчиков по отдельным этапам.

ћеханизмы мониторинга и контрол€ за ходом выполнени€ проекта.

ќписываютс€ предоставл€емые руководителем отчеты о ходе выполнени€ работ, сроки их предоставлени€, а также механизмы мониторинга всего проекта.

ѕлан должен регул€рно пересматриватьс€ в процессе реализации проекта.

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

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

“ребовани€ подраздел€ютс€ на пользовательские и системные.

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

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

ќтвечает ли система общим и бизнес-цел€м организации-заказчика и организации-разработчика?

ћожно ли реализовать систему, использу€ существующие на данный момент технологии и не выход€ за пределы заданной стоимости?

ћожно ли объединить систему с другими системами, которые уже эксплуатируютс€?

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

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

Ќапример, эту информацию можно получить, ответив на следующее:

„то произойдет с организацией, если система не будет введена в эксплуатацию?

 акие текущие проблемы существуют в организации и как нова€ система поможет их решить?

 аким образом система будет способствовать цел€м бизнеса?

“ребует ли разработка системы технологии, котора€ до этого не использовалась в организации?

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

ѕосле обработки собранной информации готовитс€ отчет по анализу осуществимости создани€ системы. ¬ нем должны быть даны рекомендации относительно продолжени€ разработки системы. ћогут быть предложены изменени€ бюджета и графика работ по созданию системы или предъ€влены более высокие требовани€ к системе.

ѕор€док выполнени€ работы »зучить предлагаемый теоретический материал.

1.

—оставить подробное описание информационной системы.

2.

Ќа основании описани€ системы провести анализ осуществимости. ¬ 3.

ходе анализа ответить на вопросы:

„то произойдет с организацией, если система не будет введена в эксплуатацию?

 акие текущие проблемы существуют в организации и как нова€ система поможет их решить?

 аким образом система будет способствовать цел€м бизнеса?

“ребует ли разработка системы технологии, котора€ до этого не использовалась в организации?

–езультатом анализа должно €витьс€ заключение о возможности реализации проекта.

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

«аполнить разделы плана:

¬ведение ќрганизаци€ выполнени€ проекта јнализ рисков –азделы должны содержать рекомендации относительно разработки системы, базовые предложени€ по объму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению.

5. —оставить отчет о проделанной работе.

–езультатом выполнени€ лабораторной работы 1 €вл€етс€ отчет по лабораторной работе є 1.

  отчету предъ€вл€ютс€ следующие требовани€:

¬ отчете следует указать:

÷ель работы ¬ведение.  раткое описание целей проекта и проектных ограничений (бюджетных, временных и т.д.), которые важны дл€ управлени€ проектом ќписание информационной системы (ѕќ) - наличие заключени€ о возможности реализации проекта, содержащего рекомендации относительно разработки системы, базовые предложени€ по объму требуемого бюджета, числу разработчиков, времени и требуемому программному обеспечению јнализ осуществимости (согласно требовани€м к результатам выполнени€ лабораторного практикума п.2), указать возможные проблемы и пути их решени€.

–оли участников группы разработки ѕќ.

ѕрограммно-аппаратные средства, используемые при выполнении работы.

«аключение (выводы) —писок используемой литературы

 ритерии оценки:

- оценка Ђзачтеної выставл€етс€ магистранту, если он выполнил все пункты задани€ на лабораторную работу, оформил отчет в соответствии с требовани€ми и ответил на контрольные вопросы.

- оценка Ђне зачтеної выставл€етс€ магистранту, если он полностью не справилс€ с заданием.

Ћабораторна€ работа 2 2.

–аздел (тема) дисциплины: ќпределение требований.

«адание выполн€етс€ на лабораторной работе є 2 Ђ–азработка требований к информационной системеї

÷ель работы: —оставить и проанализировать требовани€ к информационной системе, оформить техническое задание на разработку программного обеспечени€.

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

“ребовани€ к результатам выполнени€ лабораторного практикума:

наличие диаграммы идентификации точек зрени€ и диаграммы иерархии точек зрени€;

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

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

наличие составленного технического задани€.

“еоретические сведени€: ќбщие сведени€ о требовани€х к информационным системам ѕроблемы, которые приходитс€ решать специалистам в процессе создани€ программного обеспечени€, очень сложны. ѕрирода этих проблем не всегда €сна, особенно если разрабатываема€ программна€ система инновационна€. ¬ частности, трудно чтко описать те действи€, которые должна выполн€ть система. ќписание функциональных возможностей и ограничений, накладываемых на систему, называетс€ требовани€ми к этой системе, а сам процесс формировани€, анализа, документировани€ и проверки этих функциональных возможностей и ограничений Ц разработкой требований.

“ребовани€ подраздел€ютс€ на пользовательские и системные.

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

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

–азличают четыре основных этапа процесса разработки требований:

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

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

–ис. 1. ѕроцесс разработки требований Ќо поскольку в процессе разработки системы в силу разнообразных причин требовани€ могут мен€тьс€, управление требовани€ми, т.е. процесс управлени€ изменени€ми системных требований, €вл€етс€ необходимой составной частью де€тельности по их разработке.

‘ормирование и анализ требований —ледующим этапом процесса разработки требований €вл€етс€ формирование (определение) и анализ требований.

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

–ис. 2. ѕроцесс формировани€ и анализа требований

ѕроцесс формировани€ и анализа требований проходит через р€д этапов.

јнализ предметной области. јналитики должны изучить предметную 1.

область, где будет эксплуатироватьс€ система.

—бор требований. Ёто процесс взаимодействи€ с лицами, 2.

формирующими требовани€. ¬о врем€ этого процесса продолжаетс€ анализ предметной области.

 лассификаци€ требований. Ќа этом этапе бесформенный набор 3.

требований преобразуетс€ в логически св€занные группы требований.

–азрешение противоречий. Ѕез сомнени€, требовани€ многочисленных 4.

лиц, зан€тых в процессе формировани€ требований, будут противоречивыми. Ќа этом этапе определ€ютс€ и разрешаютс€ противоречи€ различного рода.

Ќазначение приоритетов. ¬ любом наборе требований одни из них 5.

будут более важны, чем другие. Ќа этом этапе совместно с лицами, формирующими требовани€, определ€ютс€ наиболее важные требовани€.

ѕроверка требований. Ќа этом этапе определ€етс€ их полнота, 6.

последовательность и непротиворечивость.

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

–ассмотрим три основных подхода к формированию требований: метод, основанный на множестве опорных точек зрени€, сценарии и этнографический метод.

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

–азличные методы предлагают разные трактовки выражени€ "точка зрени€".

“очки зрени€ можно трактовать следующим образом.

 ак источник информации о системных данных. ¬ этом случае на основе опорных точек зрени€ строитс€ модель создани€ и использовани€ данных в системе.

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

 ак структура представлений. ¬ этом случае точки зрени€ рассматриваютс€ как особа€ часть модели системы. Ќапример, на основе различных точек зрени€ могут разрабатыватьс€ модели "сущность-св€зь", модели конечного автомата и т.д.

 ак получатели системных сервисов. ¬ этом случае точки зрени€ €вл€ютс€ внешними (относительно системы) получател€ми системных сервисов. “очки зрени€ помогают определить данные, необходимые дл€ выполнени€ системных сервисов или их управлени€.

Ќаиболее эффективным подходом к анализу таких систем €вл€етс€ использование внешних опорных точек зрени€. Ќа основе этого подхода разработан метод VORD (Viewpoint-Oriented Requirements Definition Ч определение требований на основе точек зрени€) дл€ формировани€ и анализа требований. ќсновные этапы метода VORD показаны на рис.

3.:

»дентификаци€ точек зрени€, получающих системные сервисы, и идентификаци€ сервисов, соответствующих каждой точке зрени€.

—труктурирование точек зрени€ Ч создание иерархии сгруппированных 2.

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

ƒокументирование опорных точек зрени€, которое заключаетс€ в точном описании идентифицированных точек зрени€ и сервисов.

ќтображение системы точек зрени€, котора€ показывает системные объекты, определенные на основе информации, заключенной в опорных точках зрени€.

–ис. 3. ћетод VORD

ѕример. –ассмотрим использование метода VORD на первых трех шагах анализа требований дл€ системы системы поддержки заказа и учета товаров в бакалейной лавке. ¬ бакалейной лавке дл€ каждого товара фиксируетс€ место хранени€ (определенна€ полка), количество товара и его поставщик. —истема поддержки заказа и учета товаров должна обеспечивать добавление информации о новом товаре, изменение или удаление информации об имеющемс€ товаре, хранение (добавление, изменение и удаление) информации о поставщиках, включающей в себ€ название фирмы, ее адрес и телефон. ѕри помощи системы составл€ютс€ заказы поставщикам.  аждый заказ может содержать несколько позиций, в каждой позиции указываютс€ наименование товара и его количество в заказе.

—истема по требованию пользовател€ формирует и выдает на печать следующую справочную информацию:

список всех товаров;

список товаров, имеющихс€ в наличии;

список товаров, количество которых необходимо пополнить;

список товаров, поставл€емых данным поставщиком.

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

ќдин из подходов к идентификации точек зрени€ Ч метод "мозговой атаки", когда определ€ютс€ потенциальные системные сервисы и организации, взаимодействующие с системой. ќрганизуетс€ встреча лиц, участвующих в формировании требований, которые предлагают свои точки зрени€. Ёти точки зрени€ представл€ютс€ в виде диаграммы, состо€щей из р€да круговых областей, отображающих возможные точки зрени€ (рис. 4). ¬о врем€ "мозговой атаки" необходимо идентифицировать потенциальные опорные точки зрени€, системные сервисы, входные данные, нефункциональные требовани€, управл€ющие событи€ и исключительные ситуации.

—ледующей стадией процесса формировани€ требований будет идентификаци€ опорных точек зрени€ (на рис. 4 показаны в виде темных круговых областей) и сервисов (показаны в виде затененных областей). —ервисы должны соответствовать опорным точкам зрени€. Ќо могут быть сервисы, которые не поставлены им в соответствие. Ёто означает, что на начальном этапе "мозговой атаки" некоторые опорные точки зрени€ не были идентифицированы.

Ц  Ц  Ц

¬ таблице показано распределение сервисов дл€ некоторых идентифицированных на рис. 4 точек зрени€. ќдин и тот же сервис может быть соотнесен с несколькими точками зрени€.

“аблица 1 - —ервисы, соотнесенные с точками зрени€

Ц  Ц  Ц

»нформаци€, извлеченна€ из точек зрени€, используетс€ дл€ заполнени€ форм шаблонов точек зрени€ и организации точек зрени€ в иерархию наследовани€. Ёто позвол€ет увидеть общие точки зрени€ и повторно использовать информацию в иерархии наследовани€. —ервисы, данные и управл€юща€ информаци€ наследуютс€ подмножеством точек зрени€. Ќа рис. 5 показана часть иерархии точек зрени€ дл€ системы поддержки заказа и учета товаров.

Ц  Ц  Ц

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

¬о врем€ процесса аттестации должны быть выполнены различные типы проверок требований.

ѕроверка правильности требований. ѕользователь может считать, что 1.

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

ѕроверка на непротиворечивость. —пецификаци€ требований не должна 2.

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

ѕроверка на полноту. —пецификаци€ требований должна содержать 3.

требовани€, которые определ€ют все системные функции и ограничени€, налагаемые на систему.

ѕроверка на выполнимость. Ќа основе знани€ существующих технологий требовани€ должны быть проверены на возможность их реального выполнени€.

«десь также провер€ютс€ возможности финансировани€ и график разработки системы.

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

ќбзор требований. “ребовани€ системно анализируютс€ рецензентами.

1.

ѕрототипирование. Ќа этом этапе прототип системы демонстрируетс€ 2.

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

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

јвтоматизированный анализ непротиворечивости. ≈сли требовани€ 4.

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

јнализатор требований готовит отчет обо всех обнаруженных противоречи€х.

ѕользовательские и системные требовани€ Ќа основании полученных моделей стро€тс€ пользовательские требовани€, т.е.

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

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

ƒалее составл€ютс€ системные требовани€. ќни включат в себ€:

“ребовани€ к архитектуре системы. Ќапример, число и размещение 1.

хранилищ и серверов приложений.

“ребовани€ к параметрам оборудовани€. Ќапример, частота процессоров серверов и клиентов, объм хранилищ, размер оперативной и видео пам€ти, пропускна€ способность канала и т.д.

“ребовани€ к параметрам системы. Ќапример, врем€ отклика на действие пользовател€, максимальный размер передаваемого файла, максимальна€ скорость передачи данных, максимальное число одновременно работающих пользователей и т.д.

“ребовани€ к программному интерфейсу.

4.

“ребовани€ к структуре системы. Ќапример, ћасштабируемость, распределнность, модульность, открытость.

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

распределенность - система должна поддерживать распределнное хранение данных.

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

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

“ребовани€ по взаимодействию и интеграции с другими системами.

6.

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

ѕор€док выполнени€ работы »зучить предлагаемый теоретический материал.

1.

ѕостроить опорные точки зрени€ на основании метода VORD дл€ 2.

формировани€ и анализа требований. –езультатом должны €витьс€ две диаграммы:

диаграмма идентификации точек зрени€ и диаграмма иерархии точек зрени€.

—оставить информационную модель будущей системы, включающую в 3.

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

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

Ќа основании описани€ системы (Ћабораторна€ работа є1), информационной модели, пользовательских и системных требований составить техническое задание на создание программного обеспечени€. “« должно содержать основные разделы, описанные в √ќ—“ 34.602-89 ѕостроить отчт, включающий все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов.

–езультатом выполнени€ лабораторной работы 2 €вл€етс€ отчет по лабораторной работе є 2.

  отчету предъ€вл€ютс€ следующие требовани€:

¬ отчете следует указать:

÷ель работы ¬ведение.

ѕрограммно-аппаратные средства, используемые при выполнении работы.

ќсновна€ часть (описание самой работы), выполненна€ согласно требовани€м к результатам выполнени€ лабораторного практикума (п.2).

«аключение (выводы) —писок используемой литературы

 ритерии оценки:

- оценка Ђзачтеної выставл€етс€ магистранту, если он выполнил все пункты задани€ на лабораторную работу, оформил отчет в соответствии с требовани€ми и ответил на контрольные вопросы.

- оценка Ђне зачтеної выставл€етс€ магистранту, если он полностью не справилс€ с заданием.

Ћабораторна€ работа 3 3.

–аздел (тема) дисциплины: Ђћетодологи€ функционального моделировани€ї

«адание выполн€етс€ на лабораторной работе є 3 Ђћетодологи€ функционального моделировани€ї:

÷ель работы: »зучить методологии функционального моделировани€ IDEF0 и IDEF3.

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

“ребовани€ к результатам выполнени€ лабораторного практикума:

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

наличие в модели не менее трх уровней;

не менее двух уровней декомпозиции в стандарте IDEF0 (контекстна€ диаграмма + диаграммы A0);

на диаграмме 1-го уровн€ (A0) не менее 4-х функциональных блоков;

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

“еоретические сведени€: IDEF0 (Integrated Definition Function Modeling) методологи€ функционального моделировани€. ¬ основе IDEF0 методологии лежит пон€тие блока, который отображает некоторую бизнес-функцию. „етыре стороны блока имеют разную роль: лева€ сторона имеет значение "входа", права€ - "выхода", верхн€€ - "управлени€", нижн€€ - "механизма" (рис. 1).

¬заимодействие между функци€ми в IDEF0 представл€етс€ в виде дуги, котора€ отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. ¬ зависимости от того, с какой стороной блока св€зан поток, его называют соответственно "входным", "выходным", "управл€ющим".

–ис. 1. ‘ункциональный блок

ѕринципы моделировани€ в IDEF0

¬ IDEF0 реализованы три базовых принципа моделировани€ процессов:

принцип функциональной декомпозиции;

принцип ограничени€ сложности;

принцип контекста.

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

ƒругими словами, сложна€ бизнес-функци€ может быть представлена в виде совокупности элементарных функций. ѕредставл€€ функции графически, в виде блоков, можно как бы загл€нуть внутрь блока и детально рассмотреть ее структуру и состав (рис. 2).

–ис. 2. ƒекомпозици€ функционального блока ѕринцип ограничени€ сложности. ѕри работе с IDEF0 диаграммами существенным €вл€етс€ условие их разборчивости и удобочитаемости. —уть принципа ограничени€ сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. ѕрактика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, пон€тны и легко поддаютс€ анализу.

ѕринцип контекстной диаграммы. ћоделирование делового процесса начинаетс€ с построени€ контекстной диаграммы. Ќа этой диаграмме отображаетс€ только один блок - главна€ бизнес-функци€ моделируемой системы. ≈сли речь идет о моделировании целого предпри€ти€ или даже крупного подразделени€, главна€ бизнес-функци€ не может быть сформулирована как, например, "продавать продукцию". √лавна€ бизнес-функци€ системы - это "мисси€" системы, ее значение в окружающем мире. Ќельз€ правильно сформулировать главную функцию предпри€ти€, не име€ представлени€ о его стратегии.

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

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

Ќа рис. 3 и рис. 4 представлен пример построени€ функциональной диаграммы, описывающей изготовление издели€. –ис. 3 - контекстна€ диаграмма.

–ис. 4 Ц первый уровень декомпозиции.

Ц  Ц  Ц

ѕрименение IDEF0

—уществует два ключевых подхода к построению функциональной модели:

построение как есть и построение как будет.

ѕостроение модели Укак естьФ. ќбследование предпри€ти€ €вл€етс€ об€зательной частью любого проекта создани€ или развити€ корпоративной информационной системы.

ѕостроение функциональной модели как есть позвол€ет четко зафиксировать, какие деловые процессы осуществл€ютс€ на предпри€тии, какие информационные объекты используютс€ при выполнении деловых процессов и отдельных операций. ‘ункциональна€ модель как есть €вл€етс€ отправной точкой дл€ анализа потребностей предпри€ти€, вы€влени€ проблем и "узких" мест и разработки проекта совершенствовани€ деловых процессов.

ѕостроение модели Укак будетФ. —оздание и внедрение корпоративной информационной системы приводит к изменению условий выполнени€ отдельных операций, структуры деловых процессов и предпри€ти€ в целом. Ёто приводит к необходимости изменени€ системы бизнес-правил, используемых на предпри€тии, модификации должностных инструкций сотрудников. ‘ункциональна€ модель как будет позвол€ет уже на стадии проектировани€ будущей информационной системы определить эти изменени€. ѕрименение функциональной модели как будет позвол€ет не только сократить сроки внедрени€ информационной системы, но также снизить риски, св€занные с невосприимчивостью персонала к информационным технологи€м.

IDEF3. ћетод описани€ процессов IDEF3 ƒл€ описани€ логики взаимодействи€ информационных потоков наиболее подходит IDEF3, называема€ также workflow diagramming - методологией моделировани€, использующа€ графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, €вл€ющихс€ частью этих процессов.

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

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

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

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

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

“очка зрени€ на модель должна быть задокументирована. ќбычно это точка зрени€ человека, ответственного за работу в целом. “акже необходимо задокументировать цель модели - те вопросы, на которые призвана ответить модель.

ƒиаграммы. ƒиаграмма €вл€етс€ основной единицей описани€ в IDEF3.

≈диницы работы - Unit of Work (UOW). UOW, также называемые работами (activity), €вл€ютс€ центральными компонентами модели. ¬ IDEF3 работы изображаютс€ пр€моугольниками с пр€мыми углами и имеют им€, выраженное отглагольным существительным, обозначающим процесс действи€, одиночным или в составе фразы, и номер (идентификатор); другое им€ существительное в составе той же фразы обычно отображает основной выход (результат) работы, например, "»зготовление издели€".

—в€зи. —в€зи показывают взаимоотношени€ работ. ¬се св€зи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараютс€ построить так, чтобы св€зи были направлены слева направо.

¬ IDEF3 различают три типа стрелок, изображающих св€зи, стиль которых устанавливаетс€ через меню Edit/Arrow Style:

—тарша€ (Precedence) - сплошна€ лини€, св€зывающа€ единицы работ (UOW), –исуетс€ слева направо или сверху вниз. ѕоказывает, что работа-источник должна закончитьс€ прежде, чем работа-цель начнетс€.

ќтношени€ (Relational Link) - пунктирна€ лини€, использующа€с€ дл€ изображени€ св€зей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

ѕотоки объектов (Object Flow) - стрелка с двум€ наконечниками, примен€етс€ дл€ описани€ того факта, что объект используетс€ в двух или более единицах работы, например, когда объект порождаетс€ в одной работе и используетс€ в другой.

—тарша€ св€зь и поток объектов. —тарша€ св€зь показывает, что работа-источник заканчиваетс€ ранее, чем начинаетс€ работа-цель. „асто результатом работы-источника становитс€ объект, необходимый дл€ запуска работы-цели. ¬ этом случае стрелку, обозначающую объект, изображают с двойным наконечником. »м€ стрелки должно €сно идентифицировать отображаемый объект. ѕоток объектов имеет ту же семантику, что и старша€ стрелка.

ѕерекрестки (Junction). ќкончание одной работы может служить сигналом к началу нескольких работ, или же одна работа дл€ своего запуска может ожидать окончани€ нескольких работ. ѕерекрестки используютс€ дл€ отображени€ логики взаимодействи€ стрелок при сли€нии и разветвлении или дл€ отображени€ множества событий, которые могут или должны быть завершены перед началом следующей работы. –азличают перекрестки дл€ сли€ни€ (Fan-in Junction) и разветвлени€ (Fan-out Junction) стрелок. ѕерекресток не может использоватьс€

Ц  Ц  Ц

ѕор€док выполнени€ работы –езультатом выполнени€ лабораторной работы 3 €вл€етс€ отчет по лабораторной работе є 3.

  отчету предъ€вл€ютс€ следующие требовани€:

¬ отчете следует указать:

÷ель работы ¬ведение.

ѕрограммно-аппаратные средства, используемые при выполнении работы.

ќсновна€ часть (описание самой работы), выполненна€ согласно требовани€м к результатам выполнени€ лабораторного практикума (п.2).

«аключение (выводы) —писок используемой литературы

 ритерии оценки:

- оценка Ђзачтеної выставл€етс€ магистранту, если он выполнил все пункты задани€ на лабораторную работу, оформил отчет в соответствии с требовани€ми и ответил на контрольные вопросы.

- оценка Ђне зачтеної выставл€етс€ магистранту, если он полностью не справилс€ с заданием.

Ћабораторна€ работа 4 4.

–аздел (тема) дисциплины: Ђћетодологи€ объектно-ориентированного моделировани€ї

«адание выполн€етс€ на лабораторной работе є4 Ђћетодологи€ объектно-ориентированного моделировани€ї

÷ель работы: ќзнакомление с основными элементами определени€, представлени€, проектировани€ и моделировани€ программных систем с помощью €зыка UML.

Ћабораторна€ работа направлена на ознакомление с основными элементами определени€, представлени€, проектировани€ и моделировани€ программных систем с помощью €зыка UML, получение навыков по применению данных элементов дл€ построени€ объектно-ориентированных моделей »— на основании требований.

“ребовани€ к результатам выполнени€ лабораторного практикума:

модель системы должна содержать: диаграмму вариантов использовани€;

диаграммы взаимодействи€ дл€ каждого варианта использовани€; диаграмму классов, позвол€юща€ реализовать весь описанный функционал »—; объединенную диаграмму компонентов и размещени€ дл€ классов указать стереотипы;

в зависимости от варианта задани€ диаграмма размещени€ должна показывать расположение компонентов в распределенном приложении или св€зи между встроенным процессором и устройствами.

“еоретические сведени€: —уществует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект »—, начина€ с этапа анализа и заканчива€ созданием программного кода системы. ¬ большинстве случаев эти технологии предъ€вл€ют весьма жесткие требовани€ к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываютс€ безуспешными.

Ёти технологии представлены CASE-средствами верхнего уровн€ или CASEсредствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). ќни не позвол€ют оптимизировать де€тельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровн€ (lower CASE tools). ќднако они столкнулись с новой проблемой Ч проблемой организации взаимодействи€ между различными командами, реализующими проект.

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

—оздание UML началось в окт€бре 1994 г., когда ƒжим –амбо и √ради Ѕуч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. ¬ насто€щее врем€ консорциум пользователей UML Partners включает в себ€ представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

UML представл€ет собой объектно-ориентированный €зык моделировани€, обладающий следующими основными характеристиками:

€вл€етс€ €зыком визуального моделировани€, который обеспечивает разработку репрезентативных моделей дл€ организации взаимодействи€ заказчика и разработчика »—, различных групп разработчиков »—;

содержит механизмы расширени€ и специализации базовых концепций €зыка.

UML Ч это стандартна€ нотаци€ визуального моделировани€ программных систем, прин€та€ консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодн€шний день она поддерживаетс€ многими объектно-ориентированными CASEпродуктами.

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

ѕользовател€м €зыка предоставлены возможности:

строить модели на основе средств €дра, без использовани€ механизмов расширени€ дл€ большинства типовых приложений;

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

—тандарт UML предлагает следующий набор диаграмм дл€ моделировани€ (рис.

1):

диаграммы вариантов использовани€ (use case diagrams) Ц дл€ моделировани€ бизнес-процессов организации и требований к создаваемой системе);

диаграммы классов (class diagrams) Ц дл€ моделировани€ статической структуры классов системы и св€зей между ними;

диаграммы поведени€ системы (behavior diagrams):

o диаграммы взаимодействи€ (interaction diagrams);

диаграммы последовательности (sequence diagrams);

кооперативные диаграммы (collaboration diagrams) Ц дл€ моделировани€ процесса обмена сообщени€ми между объектами;

Ц  Ц  Ц

ƒиаграммы вариантов использовани€ ѕон€тие варианта использовани€ (use case) впервые ввел »вар якобсон и придал ему такую значимость, что в насто€щее врем€ вариант использовани€ превратилс€ в основной элемент разработки и планировани€ проекта.

¬ариант использовани€ представл€ет собой последовательность действий (транзакций), выполн€емых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). ¬ариант использовани€ описывает типичное взаимодействие между пользователем и системой. ¬ простейшем случае вариант использовани€ определ€етс€ в процессе обсуждени€ с пользователем тех функций, которые он хотел бы реализовать. Ќа €зыке UML вариант использовани€ изображают следующим образом (рис.

2):

Ц  Ц  Ц

ƒействующее лицо (actor) Ц это роль, которую пользователь играет по отношению к системе. ƒействующие лица представл€ют собой роли, а не конкретных людей или наименовани€ работ. Ќесмотр€ на то, что на диаграммах вариантов использовани€ они изображаютс€ в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некотора€ информаци€ от данной системы.

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

UML действующие лица представл€ют в виде фигур (рис. 3):

Ц  Ц  Ц

—в€зи между вариантами использовани€ и действующими лицами ¬ €зыке UML на диаграммах вариантов использовани€ поддерживаетс€ несколько типов св€зей между элементами диаграммы. Ёто св€зи коммуникации (communication), включени€ (include), расширени€ (extend) и обобщени€ (generalization).

—в€зь коммуникации Ц это св€зь между вариантом использовани€ и действующим лицом. Ќа €зыке UML св€зи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии) (рис. 4).

–ис.4. ѕример св€зи коммуникации —в€зь включени€ примен€етс€ в тех ситуаци€х, когда имеетс€ какойлибо фрагмент поведени€ системы, который повтор€етс€ более чем в одном варианте использовани€. — помощью таких св€зей обычно моделируют многократно используемую функциональность.

—в€зь расширени€ примен€етс€ при описании изменений в нормальном поведении системы. ќна позвол€ет варианту использовани€ только при необходимости использовать функциональные возможности другого (рис. 5).

Ц  Ц  Ц

ƒиаграммы взаимодействи€ (interaction diagrams) ƒиаграммы взаимодействи€ (interaction diagrams) описывают поведение взаимодействующих групп объектов.  ак правило, диаграмма взаимодействи€ охватывает поведение объектов в рамках только одного варианта использовани€. Ќа такой диаграмме отображаетс€ р€д объектов и те сообщени€, которыми они обмениваютс€ между собой.

—ообщение (message) Ц это средство, с помощью которого объектотправитель запрашивает у объекта получател€ выполнение одной из его операций.

»нформационное (informative) сообщение Ц это сообщение, снабжающее объект-получатель некоторой информацией дл€ обновлени€ его состо€ни€.

—ообщение-запрос (interrogative) Ц это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

»мперативное (imperative) сообщение Ц это сообщение, запрашивающее у объекта-получател€ выполнение некоторых действий.

—уществует два вида диаграмм взаимодействи€: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

ƒиаграмма последовательности (sequence diagrams) ƒиаграмма последовательности отражает поток событий, происход€щих в рамках варианта использовани€.

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

Ќа диаграмме последовательности объект изображаетс€ в виде пр€моугольника, от которого вниз проведена пунктирна€ вертикальна€ лини€.

Ёта лини€ называетс€ линией жизни (lifeline) объекта. ќна представл€ет собой фрагмент жизненного цикла объекта в процессе взаимодействи€.

 аждое сообщение представл€етс€ в виде стрелки между лини€ми жизни двух объектов. —ообщени€ по€вл€ютс€ в том пор€дке, как они показаны на странице сверху вниз.  аждое сообщение помечаетс€ как минимум именем сообщени€. ѕри желании можно добавить также аргументы и некоторую управл€ющую информацию. ћожно показать самоделегирование (selfdelegation) Ц сообщение, которое объект посылает самому себе, при этом стрелка сообщени€ указывает на ту же самую линию жизни (рис. 7).

–ис. 7. ѕример диаграммы последовательности

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

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

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

–ис. 8. ѕример диаграммы кооперации

ƒиаграммы классов ќбщие сведени€ ƒиаграмма классов определ€ет типы классов системы и различного рода статические св€зи, которые существуют между ними. Ќа диаграммах классов изображаютс€ также атрибуты классов, операции классов и ограничени€, которые накладываютс€ на св€зи между классами.

ƒиаграмма классов UML - это граф, узлами которого €вл€ютс€ элементы статической структуры проекта (классы, интерфейсы), а дугами - отношени€ между узлами (ассоциации, наследование, зависимости).

Ќа диаграмме классов изображаютс€ следующие элементы:

ѕакет (package) - набор элементов модели, логически св€занных между собой;

 ласс (class) - описание общих свойств группы сходных объектов;

»нтерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, св€занного с данным интерфейсом, предоставл€ет другим объектам.

 ласс  ласс - это группа сущностей (объектов), обладающих сходными свойствами, а именно, данными и поведением. ќтдельный представитель некоторого класса называетс€ объектом класса или просто объектом.

ѕод поведением объекта в UML понимаютс€ любые правила взаимодействи€ объекта с внешним миром и с данными самого объекта.

Ќа диаграммах класс изображаетс€ в виде пр€моугольника со сплошной границей, разделенного горизонтальными лини€ми на 3 секции (рис.

9):

¬ерхн€€ секци€ (секци€ имени) содержит им€ класса и другие общие свойства (в частности, стереотип).

¬ средней секции содержитс€ список атрибутов ¬ нижней - список операций класса, отражающих его поведение (действи€, выполн€емые классом).

Ћюба€ из секций атрибутов и операций может не изображатьс€ (а также обе сразу). ƒл€ отсутствующей секции не нужно рисовать разделительную линию и каклибо указывать на наличие или отсутствие элементов в ней.

Ќа усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключени€ (Exceptions).

–ис. 9. ѕример диаграммы классов

—тереотипы классов —тереотипы классов Ц это механизм, позвол€ющий раздел€ть классы на категории.

¬ €зыке UML определены три основных стереотипа классов:

Boundary (граница);

Entity (сущность);

Control (управление).

√раничные классы √раничными классами (boundary classes) называютс€ такие классы, которые расположены на границе системы и всей окружающей среды. Ёто экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.

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

»менно такой класс позвол€ет действующему лицу взаимодействовать с системой.

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

”правл€ющие классы ”правл€ющие классы (control classes) отвечают за координацию действий других классов. ќбычно у каждого варианта использовани€ имеетс€ один управл€ющий класс, контролирующий последовательность событий этого варианта использовани€. ”правл€ющий класс отвечает за координацию, но сам не несет в себе никакой функциональности, так как остальные классы не посылают ему большого количества сообщений. ¬место этого он сам посылает множество сообщений. ”правл€ющий класс просто делегирует ответственность другим классам, по этой причине его часто называют классом-менеджером.

¬ системе могут быть и другие управл€ющие классы, общие дл€ нескольких вариантов использовани€. Ќапример, может быть класс SecurityManager (менеджер безопасности), отвечающий за контроль событий, св€занных с безопасностью.  ласс TransactionManager (менеджер транзакций) занимаетс€ координацией сообщений, относ€щихс€ к транзакци€м с базой данных. ћогут быть и другие менеджеры дл€ работы с другими элементами функционировани€ системы, такими как разделение ресурсов, распределенна€ обработка данных или обработка ошибок.

ѕомимо упом€нутых выше стереотипов можно создавать и свои собственные.

јтрибуты јтрибут Ц это элемент информации, св€занный с классом. јтрибуты хран€т инкапсулированные данные класса.

“ак как атрибуты содержатс€ внутри класса, они скрыты от других классов.

¬ св€зи с этим может понадобитьс€ указать, какие классы имеют право читать и измен€ть атрибуты. Ёто свойство называетс€ видимостью атрибута (attribute visibility).

” атрибута можно определить четыре возможных значени€ этого параметра:

Public (общий, открытый). Ёто значение видимости предполагает, что атрибут будет виден всеми остальными классами. Ћюбой класс может просмотреть или изменить значение атрибута. ¬ соответствии с нотацией UML общему атрибуту предшествует знак Ђ + ї.

Private (закрытый, секретный). —оответствующий атрибут не виден никаким другим классом. «акрытый атрибут обозначаетс€ знаком Ђ Ц ї в соответствии с нотацией UML.

Protected (защищенный). “акой атрибут доступен только самому классу и его потомкам. Ќотаци€ UML дл€ защищенного атрибута Ц это знак Ђ # ї.

Package or Implementation (пакетный). ѕредполагает, что данный атрибут €вл€етс€ общим, но только в пределах его пакета. Ётот тип видимости не обозначаетс€ никаким специальным значком.

¬ общем случае, атрибуты рекомендуетс€ делать закрытыми или защищенными. Ёто позвол€ет лучше контролировать сам атрибут и код.

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

ќперации ќперации реализуют св€занное с классом поведение. ќпераци€ включает три части Ц им€, параметры и тип возвращаемого значени€.

ѕараметры Ц это аргументы, получаемые операцией Ђна входеї. “ип возвращаемого значени€ относитс€ к результату действи€ операции.

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

¬ €зыке UML операции имеют следующую нотацию:

»м€ ќперации (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значени€

—ледует рассмотреть четыре различных типа операций:

ќперации реализации;

ќперации управлени€;

ќперации доступа;

¬спомогательные операции.

ќперации реализации ќперации реализации (implementor operations) реализуют некоторые бизнесфункции. “акие операции можно найти, исследу€ диаграммы взаимодействи€.

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

 ажда€ операци€ реализации должна быть легко прослеживаема до соответствующего требовани€. Ёто достигаетс€ на различных этапах моделировани€. ќпераци€ выводитс€ из сообщени€ на диаграмме взаимодействи€, сообщени€ исход€т из подробного описани€ потока событий, который создаетс€ на основе варианта использовани€, а последний Ц на основе требований. ¬озможность проследить всю эту цепочку позвол€ет гарантировать, что каждое требование будет реализовано в коде, а каждый фрагмент кода реализует какое-то требование.

ќперации управлени€ ќперации управлени€ (manager operations) управл€ют созданием и уничтожением объектов. ¬ эту категорию попадают конструкторы и деструкторы классов.

ќперации доступа јтрибуты обычно бывают закрытыми или защищенными. “ем не менее, другие классы иногда должны просматривать или измен€ть их значени€. ƒл€ этого существуют операции доступа (access operations). “акой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позвол€ет осуществить к ним контролируемый доступ. —оздание операций Get и Set (получени€ и изменени€ значени€) дл€ каждого атрибута класса €вл€етс€ стандартом.

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

„тобы идентифицировать операции, выполните следующие действи€:

»зучите диаграммы последовательности и кооперативные диаграммы. Ѕольша€ часть сообщений на этих диаграммах €вл€етс€ операци€ми реализации. –ефлексивные сообщени€ будут вспомогательными операци€ми.

–ассмотрите управл€ющие операции. ћожет потребоватьс€ добавить 2.

конструкторы и деструкторы.

–ассмотрите операции доступа. ƒл€ каждого атрибута класса, с 3.

которым должны будут работать другие классы, надо создать операции Get и Set.

—в€зи —в€зь представл€ет собой семантическую взаимосв€зь между классами.

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

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

јссоциации јссоциаци€ (association) Ц это семантическа€ св€зь между классами. »х рисуют на диаграмме классов в виде обыкновенной линии (рис. 10).

–ис. 10. —в€зь ассоциаци€

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

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

≈сли хот€ бы одно сообщение отправл€етс€ в обратную сторону, ассоциаци€ должна быть двунаправленной.

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

«ависимости —в€зи зависимости (dependency) также отражают св€зь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Ќапример, класс A использует методы класса B. “огда при изменении класса B необходимо произвести соответствующие изменени€ в классе A.

«ависимость изображаетс€ пунктирной линией, проведенной между двум€ элементами диаграммы, и считаетс€, что элемент, прив€занный к концу стрелки, зависит от элемента, прив€занного к началу этой стрелки (рис. 11).

–ис. 11. —в€зь зависимость

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

јгрегации јгрегации (aggregations) представл€ют собой более тесную форму ассоциации. јгрегаци€ Ц это св€зь между целым и его частью. Ќапример, у вас может быть класс јвтомобиль, а также классы ƒвигатель, ѕокрышки и классы дл€ других частей автомобил€. ¬ результате объект класса јвтомобиль будет состо€ть из объекта класса ƒвигатель, четырех объектов ѕокрышек и т. д.

јгрегации визуализируют в виде линии с ромбиком у класса, €вл€ющегос€ целым (рис.

12):

–ис. 12. —в€зь агрегаци€

¬ дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. —огласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Ћюбое удаление целого распростран€етс€ на его части.

“акое каскадное удаление нередко рассматриваетс€ как часть определени€ агрегации, однако оно всегда подразумеваетс€ в том случае, когда множественность роли составл€ет 1..1; например, если необходимо удалить  лиента, то это удаление должно распространитьс€ и на «аказы (и, в свою очередь, на —троки заказа).

ќбобщени€ (Ќаследование) ќбобщение (наследование) - это отношение типа общее-частное между элементами модели. — помощью обобщений (generalization) показывают св€зи наследовани€ между двум€ классами. Ѕольшинство объектно-ориентированных €зыков непосредственно поддерживают концепцию наследовани€. ќна позвол€ет одному классу наследовать все атрибуты, операции и св€зи другого.

Ќаследование пакетов означает, что в пакете-наследнике все сущности пакета-предка будут видны под своими собственными именами (т.е. пространства имен объедин€ютс€). Ќаследование показываетс€ сплошной линией, идущей от классапотомка к классу-предку (в терминологии ќќѕ - от потомка к предку, от сына к отцу, или от подкласса к суперклассу). —о стороны более общего элемента рисуетс€ большой полый треугольник (рис. 13).

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

ћножественность ћножественность (multiplicity) показывает, сколько экземпл€ров одного класса взаимодействуют с помощью этой св€зи с одним экземпл€ром другого класса в данный момент времени.

Ќапример, при разработке системы регистрации курсов в университете можно определить классы Course (курс) и Student (студент). ћежду ними установлена св€зь: у курсов могут быть студенты, а у студентов Ц курсы. ¬опросы, на который должен ответить параметр множественности: Ђ—колько курсов студент может посещать в данный момент? —колько студентов может за раз посещать один курс?ї

“ак как множественность дает ответ на оба эти вопроса, е индикаторы устанавливаютс€ на обоих концах линии св€зи. ¬ примере регистрации курсов мы решили, что один студент может посещать от нул€ до четырех курсов, а один курс могут слушать от 0 до 20 студентов.

¬ €зыке UML прин€ты определенные нотации дл€ обозначени€ множественности.

“аблица 1 - ќбозначени€ множественности св€зей в UML

»мена св€зей —в€зи можно уточнить с помощью имен св€зей или ролевых имен. »м€ св€зи

Ц это обычно глагол или глагольна€ фраза, описывающа€, зачем она нужна.

Ќапример, между классом Person (человек) и классом Company (компани€) может существовать ассоциаци€. ћожно задать в св€зи с этим вопрос, €вл€етс€ ли объект класса Person клиентом компании, е сотрудником или владельцем?

„тобы определить это, ассоциацию можно назвать Ђemploysї (нанимает) (рис. 14):

–ис. 14. ѕример имен св€зей

–оли –олевые имена примен€ют в св€з€х ассоциации или агрегации вместо имен дл€ описани€ того, зачем эти св€зи нужны. ¬озвраща€сь к примеру с классами Person и Company, можно сказать, что класс Person играет роль сотрудника класса –олевые имена Ц это обычно имена существительные или Company.

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

Ц  Ц  Ц

ѕакет. ћеханизм пакетов ¬ контексте диаграмм классов, пакет - это вместилище дл€ некоторого набора классов и других пакетов. ѕакет €вл€етс€ самосто€тельным пространством имен (рис.

16).

Ц  Ц  Ц

¬ UML нет каких-либо ограничений на правила, по которым разработчики могут или должны группировать классы в пакеты. Ќо есть некоторые стандартные случаи, когда така€ группировка уместна, например, тесно взаимодействующие классы, или более общий случай - разбиение системы на подсистемы.

ѕакет физически содержит сущности, определенные в нем (говор€т, что "сущности принадлежат пакету"). Ёто означает, что если будет уничтожен пакет, то будут уничтожено и все его содержимое.

—уществует несколько наиболее распространенных подходов к группировке.

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

ƒругой подход заключаетс€ в объединении классов по их функциональности. Ќапример, в пакете Security (безопасность) содержатс€ все классы, отвечающие за безопасность приложени€. ¬ таком случае другие пакеты могут называтьс€ Employee Maintenance (–абота с сотрудниками), Reporting (ѕодготовка отчетов) и Error Handling (ќбработка ошибок). ѕреимущество этого подхода заключаетс€ в возможности повторного использовани€.

ћеханизм пакетов применим к любым элементам модели, а не только к классам. ≈сли дл€ группировки классов не использовать некоторые эвристики, то она становитс€ произвольной. ќдна из них, котора€ в основном используетс€ в UML, Ц это зависимость. «ависимость между двум€ пакетами существует в том случае, если между любыми двум€ классами в пакетах существует люба€ зависимость.

“аким образом, диаграмма пакетов представл€ет собой диаграмму, содержащую пакеты классов и зависимости между ними. —трого говор€, пакеты и зависимости €вл€ютс€ элементами диаграммы классов, то есть диаграмма пакетов Ц это форма диаграммы классов (рис. 17).

–ис. 17. ѕример диаграммы пакетов

«ависимость между двум€ элементами имеет место в том случае, если изменени€ в определении одного элемента могут повлечь за собой изменени€ в другом.

„то касаетс€ классов, то причины дл€ зависимостей могут быть самыми разными:

один класс посылает сообщение другому;

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

≈сли класс мен€ет свой интерфейс, то любое сообщение, которое он посылает, может утратить свою силу.

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

ѕакеты €вл€ютс€ жизненно необходимым средством дл€ больших проектов. »х следует использовать в тех случа€х, когда диаграмма классов, охватывающа€ всю систему в целом и размещенна€ на единственном листе бумаги формата ј4, становитс€ нечитаемой.

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

—уществует много форм диаграмм состо€ний, незначительно отличающихс€ друг от друга семантикой.

Ќа диаграмме имеютс€ два специальных состо€ни€ Ц начальное (start) и конечное (stop). Ќачальное состо€ние выделено черной точкой, оно соответствует состо€нию объекта, когда он только что был создан.

 онечное состо€ние обозначаетс€ черной точкой в белом кружке, оно соответствует состо€нию объекта непосредственно перед его уничтожением. Ќа диаграмме состо€ний может быть одно и только одно начальное состо€ние. ¬ то же врем€, может быть столько конечных состо€ний, сколько вам нужно, или их может не быть вообще.  огда объект находитс€ в каком-то конкретном состо€нии, могут выполн€тьс€ различные процессы. ѕроцессы, происход€щие, когда объект находитс€ в определенном состо€нии, называютс€ действи€ми (actions).

— состо€нием можно св€зывать данные п€ти типов: де€тельность, входное действие, выходное действие, событие и истори€ состо€ни€.

ƒе€тельность ƒе€тельностью (activity) называетс€ поведение, реализуемое объектом, пока он находитс€ в данном состо€нии. ƒе€тельность Ц это прерываемое поведение.

ќно может выполн€тьс€ до своего завершени€, пока объект находитс€ в данном состо€нии, или может быть прервано переходом объекта в другое состо€ние. ƒе€тельность изображают внутри самого состо€ни€, ей должно предшествовать слово do (делать) и двоеточие.

¬ходное действие ¬ходным действием (entry action) называетс€ поведение, которое выполн€етс€, когда объект переходит в данное состо€ние. ƒанное действие осуществл€етс€ не после того, как объект перешел в это состо€ние, а, скорее, как часть этого перехода. ¬ отличие от де€тельности, входное действие рассматриваетс€ как непрерываемое. ¬ходное действие также показывают внутри состо€ни€, ему предшествует слово entry (вход) и двоеточие.

¬ыходное действие ¬ыходное действие (exit action) подобно входному. ќднако, оно осуществл€етс€ как составна€ часть процесса выхода из данного состо€ни€.

ќно €вл€етс€ частью процесса такого перехода.  ак и входное, выходное действие €вл€етс€ непрерываемым.

¬ыходное действие изображают внутри состо€ни€, ему предшествует слово exit (выход) и двоеточие.

ѕоведение объекта во врем€ де€тельности, при входных и выходных действи€х может включать отправку событи€ другому объекту. ¬ этом случае описанию де€тельности, входного действи€ или выходного действи€ предшествует знак Ђ ^ ї.

—оответствующа€ строка на диаграмме выгл€дит как «десь ÷ель Ц это объект, получающий ^÷ель.—обытие

Do:

событие, —обытие Ц это посылаемое сообщение, а (јргументы) јргументы €вл€ютс€ параметрами посылаемого сообщени€.

ƒе€тельность может также выполн€тьс€ в результате получени€ объектом некоторого событи€. ѕри получении некоторого событи€ выполн€етс€ определенна€ де€тельность.

ѕереходом (Transition) называетс€ перемещение из одного состо€ни€ в другое.

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

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

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

—обыти€ —обытие (event) Ц это то, что вызывает переход из одного состо€ни€ в другое. —обытие размещают на диаграмме вдоль линии перехода.

Ќа диаграмме дл€ отображени€ событи€ можно использовать как им€ операции, так и обычную фразу.

Ѕольшинство переходов должны иметь событи€, так как именно они, прежде всего, заставл€ют переход осуществитьс€. “ем не менее, бывают и автоматические переходы, не имеющие событий. ѕри этом объект сам перемещаетс€ из одного состо€ни€ в другое со скоростью, позвол€ющей осуществитьс€ входным действи€м, де€тельности и выходным действи€м.

ќграждающие услови€ ќграждающие услови€ (guard conditions) определ€ют, когда переход может, а когда не может осуществитьс€. ¬ противном случае переход не осуществитс€.

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

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

ƒействие ƒействием (action), как уже говорилось, €вл€етс€ непрерываемое поведение, осуществл€ющеес€ как часть перехода. ¬ходные и выходные действи€ показывают внутри состо€ний, поскольку они определ€ют, что происходит, когда объект входит или выходит из него. Ѕольшую часть действий, однако, изображают вдоль линии перехода, так как они не должны осуществл€тьс€ при входе или выходе из состо€ни€.

ƒействие рисуют вдоль линии перехода после имени событи€, ему предшествует коса€ черта.

—обытие или действие могут быть поведением внутри объекта, а могут представл€ть собой сообщение, посылаемое другому объекту. ≈сли событие или действие посылаетс€ другому объекту, перед ним на диаграмме помещают знак Ђ ^ ї (рис. 18).

Ц  Ц  Ц

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

ƒиаграммы размещени€ ƒиаграмма размещени€ (deployment diagram) отражает физические взаимосв€зи между программными и аппаратными компонентами системы. ќна €вл€етс€ хорошим средством дл€ того, чтобы показать маршруты перемещени€ объектов и компонентов в распределенной системе.

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

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

ƒиаграмма размещени€ показывает физическое расположение сети и местонахождение в ней различных компонентов (рис. 19).

Ц  Ц  Ц

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

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

 аждый класс модели (или подсистема) преобразуетс€ в компонент исходного кода. ѕосле создани€ они сразу добавл€ютс€ к диаграмме компонентов.

ћежду отдельными компонентами изображают зависимости, соответствующие зависимост€м на этапе компил€ции или выполнени€ программы.

ƒиаграммы компонентов примен€ютс€ теми участниками проекта, кто отвечает за компил€цию системы. »з нее видно, в каком пор€дке надо компилировать компоненты, а также какие исполн€емые компоненты будут созданы системой. Ќа такой диаграмме показано соответствие классов реализованным компонентам (рис. 20). ќна нужна там, где начинаетс€ генераци€ кода.

–ис. 20. ѕример диаграммы компонентов

ќбъединение диаграмм компонентов и развертывани€ ¬ некоторых случа€х допускаетс€ размещать диаграмму компонентов на диаграмме развертывани€. Ёто позвол€ет показать какие компоненты выполн€ютс€ и на каких узлах.

ѕор€док выполнени€ работы »зучить предлагаемый теоретический материал.

1.

ѕостройте диаграмму вариантов использовани€ дл€ выбранной информационной системы.

¬ыполните реализацию вариантов использовани€ в терминах взаимодействующих объектов и представл€ющую собой набор диаграмм:

диаграмм классов, реализующих вариант использовани€;

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

–азделить классы по пакетам использую один из механизм разбиени€.

4.

ѕостройте диаграмму состо€ний дл€ конкретных объектов информационной системы.

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

–езультатом выполнени€ лабораторной работы 4 €вл€етс€ отчет по лабораторной работе є 4.

  отчету предъ€вл€ютс€ следующие требовани€:

¬ отчете следует указать:

÷ель работы ¬ведение.

ѕрограммно-аппаратные средства, используемые при выполнении работы.

ќсновна€ часть (описание самой работы), выполненна€ согласно требовани€м к результатам выполнени€ лабораторного практикума (п.2).

«аключение (выводы) —писок используемой литературы

 ритерии оценки:

- оценка Ђзачтеної выставл€етс€ магистранту, если он выполнил все пункты задани€ на лабораторную работу, оформил отчет в соответствии с требовани€ми и ответил на контрольные вопросы.

- оценка Ђне зачтеної выставл€етс€ магистранту, если он полностью не справилс€ с заданием.

Ћабораторна€ работа 5 5.

–аздел (тема) дисциплины: Ђѕрин€тие решений в услови€х неопределенностиї

«адание выполн€етс€ на лабораторной работе є 5 Ђѕрин€тие решений в услови€х неопределенностиї

÷ель работы:

»зучить:

ќсновные типы неопределенности в задачах прин€ти€ решений ѕрин€тие решений в услови€х риска ѕрин€тие решений в услови€х неопределнности ѕрин€тие решений в конфликтных ситуаци€х —тохастические задачи прин€ти€ решений ѕеред выполнением задани€ необходимо изучить теоретические вопросы прин€ти€ решений в детерминированных задачах, и задачах многокритериальной оптимизации, основанные на принципе ѕарето. –азобратьс€ в содержании методов преодолени€ неопределнностей при выборе решений из ѕарето - оптимального множества решений.

“еоретические сведени€:

¬ детерминированных однокритериальных задачах прин€ти€ решени€ выбор и оценка решени€ осуществл€ютс€ однозначно в соответствии с заданной целевой функцией. ќднако, уже в многокритериальных задачах возникает неопределнность из за необходимости согласованного выбора по множеству критериев, среди которых могут быть и противоречивые. ƒл€ устранени€ этой неопределнности примен€ют различные формальные (построение обобщнного критери€) и неформальные (определение ѕарето оптимального множества решений) процедуры.

«адачи прин€ти€ решений в услови€х неопределнности возникают при необходимости действовать в не полностью определнной ситуации (состо€нии среды) в самых разных област€х человеческой де€тельности: технике, экономике, биологии, экологии и т. д. ќсновна€ сложность этой задачи в том, что последстви€ принимаемого решени€ завис€т от неизвестной ситуации. ¬еличину опасности (неприемлемости) последствий измер€ют в условных единицах - потер€х, которые может понести Ћѕ–, и тогда выбираетс€ то решение, при котором потери наименьшие. ѕотери, которые нест Ћѕ–, принима€ решение в услови€х неопределнности, называют риском “ак как в услови€х неопределнности Ћѕ– неизвестно фактическое состо€ние среды, то возникает необходимость такого преобразовани€ задачи, когда потери завис€т только от принимаемого решени€. ƒл€ этого Ћѕ– с помощью формальных или неформальных процедур формулирует гипотезы о потер€х при реализации каждой стратегии. “акие гипотезы называют критери€ми выбора решени€ в услови€х неопределнности, они полностью определ€етс€ Ћѕ–. ¬ результате потери, сопутствующие каждой стратегии, как бы обобщаютс€ относительно некоторого гипотетического состо€ни€ среды, и выбор наиболее полезной стратегии осуществл€етс€ на основании потерь, соответствующих этому гипотетическому состо€нию среды.

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

¬ насто€щее врем€ наиболее изучены два типа неопределнностей:

неопределнность состо€ни€ внешней среды (неопределнность природы) и неопределнность целенаправленного противодействи€. Ќеопределенность состо€ни€ внешней среды (природы) имеет две версии реализации:

известно распределение веро€тности реализации возможных состо€ний 1) внешней среды;

известно только множество Y состо€ний внешней среды, из которого оно 2) может быть выбрано.

ѕервую из этих задач называют задачей прин€ти€ решени€ в услови€х риска, вторую - задачей прин€ти€ решений в услови€х неопределнности, а задачи прин€ти€ решени€ в услови€х целенаправленного противодействи€ - играми.

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

¬еро€тность состо€ни€ среды, представл€етс€ вектором p = (p1, p2, Е pm), где pi веро€тность наступлени€ состо€ни€ среды с номером i. “акие задачи называют игрой с природой.

¬ этом случае платжна€ матрица имеет вид (таблица 1):

Ц  Ц  Ц

≈сли выбрать альтернативу с номером i, то ожидаемые потери будут представлены случайной величиной с функцией распределени€ F(,&), где 0 - вектор параметров функции распределени€, и сравнение двух альтернатив эквивалентно сравнению функций распределени€ соответствующих случайных величин. ‘ункции распределени€ альтернатив завис€т только от значений параметров распределени€ и не завис€т от состо€ни€ среды.

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

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

ѕредполагаетс€, что последстви€ выбора альтернативы распределены нормально.

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

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

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

ѕусть, например, в некоторой системе возможно использование двух технологий a1, a2, среда может принимать одно из трх состо€ний - b1, b2, №3. »звестно, что состо€ние среды №1 реализуетс€ с веро€тностью 0.375, состо€ние №2 - с веро€тностью 0.5, состо€ние №3 - с веро€тностью 0.125. ѕоследстви€выбора альтернативы дл€ каждого состо€ни€ среды оцениваютс€ величинами, приведнными в таблице 2. —прашиваетс€, какую технологию следует выбрать, чтобы минимизировать ущерб от последствий выбора?

“аблица 2 ћатрица оценки последствий выбора технологии.

¬ качестве критери€ сравнени€ альтернатив примем математическое ожидание Ђущербаї от аварийной ситуации, значение которой приведено в последней колонке платжной матрицы. ќчевидно, что оптимальной альтернативой (ущерб наименьший) €вл€етс€ альтернатива a2.

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

ѕоэтому при выборе альтернативы а2 мы получим не значение Ma2, а одно из практически возможных значений 8, 15 или 40 единиц ущерба. ѕотери, св€занные с выбором конкретной альтернативы, оцениваютс€ дл€ каждой альтернативы разност€ми между конкретными значени€ми ущерба и его математическим ожиданием. ¬ычислим эти потери и составим таблицу 3.

“аблица 3. ќтклонени€ реального ущерба от математического ожидани€ ѕриведнные в этой таблице результаты, показывают, что, име€ близкие значени€ ћш, альтернативы по-разному характеризуютс€ возможными потер€ми: дл€ альтернативы а} колебани€ величины потерь невелико, а дл€ альтернативы a2 более существенно.

ѕоэтому критерий выбора, основанный на величине математического ожидани€ (ожидаемого выигрыша), необходимо дополнить характеристикой отклонений случайной величины от е математического ожидани€. ¬ теории веро€тностей мерой такого отклонени€ служит дисперси€ D или среднее квадратическое отклонение а = VD. ƒл€ рассматриваемого примера аа} = 1.4, аа2 = 9.8. »спользование значени€ с удобнее, так как оно имеет размерность одинаковую с размерностью математического ожидани€.

“аким образом, в услови€х риска выбор альтернативы характеризуетс€ двум€ показател€ми: математическим ожиданием выигрыша и его средне квадратическим отклонением с. “огда фактически получаетс€ задача двухкритериальной оптимизации с частными критери€ми ћ и с и е решение основываетс€ или на определении ѕарето оптимального множества решений или на построении обобщнного критери€.

«адача прин€ти€ решений в услови€х неопределнности ќт задачи прин€ти€ решени€ в услови€х риска, данна€ задача отличаетс€ тем, что неизвестны веро€тности состо€ний среды, т. е. неизвестны функции распределени€ потерь дл€ каждой альтернативы. ƒл€ преодолени€ возникающей проблемы необходимо сформулировать гипотезы о состо€нии среды, позвол€ющие получить дл€ каждой альтернативы числовую оценку полезности решени€ (потери) и по этой информации осуществить выбор, соответствующий этому гипотетическому состо€нию. ¬ простейшем случае множество X альтернатив и множество Y состо€ний среды - конечные множества и целевую функцию можно задать таблицей (матрицей Q), строки которой соответствуют какой либо альтернативе, а столбцы - состо€нию среды. “огда элемент qij- матрицы Q оценка эффективности альтернативы с номером i соответствующа€ состо€нию среды с номером j. ћатрицу Q называют платжной матрицей или матрицей потерь.

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

 ритерий Ћапласа основан на принципе равновозможности вариантов состо€ни€ среды и примен€етс€, когда невозможно отдать предпочтение ни одному из них. ќценка альтернативы с номером i принимаетс€ равной среднему арифметическому элементов строки платжной матрицы с этим же номером.

Ћюбые две альтернативы сравнимы между собой по критерию Ћапласа: лучша€ альтернатива имеет большую (меньшую) оценку, а оптимальна€ - максимальную (минимальную) оценку. Ќедостатки этого критери€ св€заны с эффектом сглаживани€ отдельных оценок при вычислении критери€.

 ритерий ¬альда основан на принципе минимакса (максимина). ћинимакс значение функции f(x,y), которое она принимает, когда сначала выбираетс€ максимум по у из множества Y, а затем - минимум по x из множества X.

ќценка альтернативы с номером i в соответствии с критерием ¬альда выполн€етс€ по одной из формул ¬ыбор одной из этих формул зависит от цели. ѕерва€ формула позвол€ет выбрать стратегию снаименьшими максимальными потер€ми, а втора€ - с наибольшими минимальными потер€ми. Ќапример, дл€ матрицы U  ритерий √урвица учитывает только наилучший и наихудший исходы. Ёто обсто€тельство относ€т к недостаткам данного критери€, как и субъективность определени€ значени€ а.

 ритерий —эвиджа основан на вычислении максимальной утер€нной выгоды при различных вариантах действий, и выборе того варианта действий, который минимизирует максимальную утер€нную выгоду. ћатрица U преобразуетс€ в матрицу R утер€нной выгоды по правилу –ассмотрим пример. ѕусть требуетс€ из четырх вариантов (Ah A2, A3, A4) выбрать проект технологии. ѕоследстви€, св€занные с выбором, завис€т от некоторого множества неопределнных факторов, которые определ€ют состо€ние среды. ѕусть определено четыре варианта (B1, B2, B3, B4) состо€ний среды. Ёффективность выбора, какого либо варианта при различных состо€ни€х среды определ€етс€ платжной матрицей.

ќптимальные по каждому критерию варианты в таблице выделены жирным шрифтом. ƒл€ разных критериев получаем разные оптимальные решени€. Ёто обусловлено тем, что критерии основываютс€ на различных гипотезах о состо€нии среды. »спользование той или иной гипотезы снимает неопределнность, но гипотеза это лишь предположение, которое не об€зательно совпадает с истинным состо€нием среды.

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

Ц  Ц  Ц

свои намерени€. ќсновой теории игр €вл€етс€ формализаци€ пон€тий конфликта, прин€ти€ решени€ в нм и полезности (оптимальности) этого решени€.

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

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

 онкретизаци€ этих пон€тий приводит к разнообразным частным классам игр.

ѕрин€тием решени€ в теории игр считаетс€ выбор игроком своей стратегии.

¬опрос о формализации пон€ти€ полезности (оптимальности) принимаемого решени€ €вл€етс€ сложным. ≈диного представлени€ о нм нет, и поэтому рассматриваютс€ разные версии, но в основе каждой из них лежит интуитивное представление о полезности, как о чм - то устойчивом и справедливом. ‘ормализаци€ этих представлений определ€етс€ системой аксиом.

—итуации, удовлетвор€ющие в игре требовани€м полезности (оптимальности) называютс€ решени€ми игры. ќграничимс€ рассмотрением игр двух участников с пр€мо противоположными (антагонистическими) интересами. ‘ормально эта противоположность выражаетс€ в том, что при переходе от одной ситуации к другой увеличение выигрыша одного игрока влечт численно равное уменьшение выигрыша другого. —умма выигрышей игроков в любой ситуации посто€нна (е можно считать равной нулю). ƒл€ некоторых военных операций, спортивных игр, деловых решений в услови€х конкуренции и многих других €влений антагонистические игры €вл€ютс€ хорошей моделью.

јнтагонистическа€ игра задатс€ множествами A и B стратегий игроков и вещественной функцией определнной на множестве A х B и €вл€ющейс€ функцией выигрыша первого игрока (функци€ выигрыша второго игрока равна -H). ѕроцесс игры состоит в выборе игроками некоторых своих стратегий a е A, be B, после чего первый игрок получает от второго сумму H(a,b). –азумное (осторожное) поведение игроков в антагонистической игре осуществл€етс€ на основании принципа максимина. ≈сли то у каждого игрока существует оптимальна€ осторожна€ стратеги€. Ёта стратеги€ называетс€ Ђчистойї стратегией. ќднако уже в самых простых ситуаци€х принцип максимина может не выполн€тьс€.

≈сли множества A и B конечны, то антагонистическа€ игра называетс€ матричной игрой. ≈сли первый игрок имеет m стратегий, а второй - n стратегий, то матрична€ игра может быть задана m х n матрицей A = {a,}. ћатричные игры моделируют широкий круг конфликтных антагонистических ситуаций с двум€ участниками и конечным множеством возможных действий у каждого из них. »ногда под одним из игроков понимаетс€ Ђприродаї, как совокупность всех обсто€тельств, неизвестных принимающему решение другому игроку. “акие игры называют играми с природой. ќни возникают при необходимости учта природных и других неконтролируемых факторов, не наход€щихс€ в распор€жении какого либо лица. ѕри этом природе приписываетс€ роль Ђсознательного противникаї - антагониста.

ƒл€ решени€ матричной игры необходимо найти оптимальные стратегии игроков и цену игры. ѕрактическое правило дл€ решени€ матричной игры следующее.   платжной матрице A добавим один столбец справа и одну строку снизу. ¬ €чейки столбца запишем минимальное значение платежа соответствующей строки, а в €чейки строки максимальное значение соответствующего столбца.

ѕервый игрок будет выбирать стратегию, котора€ гарантирует ему максимальный выигрыш независимо от выбора стратегии второго игрока. ѕоэтому он выберет стратегию, при которой он будетиметь максимальный выигрыш из возможных минимальных выигрышей (в столбце min это элемент, соответствующий стратегии R первого игрока), т.е. гарантированный выигрыш первого игрока Ётот выигрыш V называют нижней ценой игры, а соответствующую стратегию Ц максиминной стратегией первого игрока.

¬торой игрок, стара€сь минимизировать проигрыш, выберет стратегию, гарантирующую наименьший из максимально возможных проигрышей, т.е. стратегию которую называют минимаксной стратегией. „исло V2 называют верхней ценой игры. ≈сли V = V2 = V, то число V называют ценой игры. »гры, дл€ которых V = V2 = V, называют играми с седловой точкой.

—едловых точек может быть несколько. ќднако цена игры во всех седловых точках одна и та же. ≈сли один из игроков примен€ет стратегию, соответствующую одной из седловых точек, то при этом ему обеспечен выигрыш не меньше цены игры. ≈сли и второй игрок примен€ет стратегию, соответствующую какой либо седловой точке, то и ему обеспечен проигрыш не более цены игры. ќдностороннее отклонение от седловой точки не выгодно ни одному из игроков. “акое отклонение может в лучшем случае оставить выигрыш (проигрыш) неизменным, а в худшем случае - уменьшить (увеличить) его. “аким образом, в играх с седловой точкой оптимальные стратегии обладают своеобразной устойчивостью: если один из игроков примен€ет свою оптимальную стратегию, то дл€ другого всегда невыгодно отклон€тьс€ от своей оптимальной стратегии.

  классу игр, имеющих седловую точку, относ€тс€ игры, в которых каждый игрок знает результаты всех предыдущих ходов. “акие игры называютс€ играми с полной информацией. ѕримерами игр с полной информацией служат шашки, шахматы, Ђкрестики

- ноликиї и т.д. ¬ теории игр доказано, что кажда€ игра с полной информацией имеет седловую точку, т.е. имеетс€ пара оптимальных стратегий противников, дающа€ устойчивый выигрыш, равный чистой цене игры.

Ќе вс€ка€ матрична€ игра приводит к решени€м с единственным оптимальным выбором дл€ обоих игроков. Ёто значит, что ни один из игроков не может выбрать чистую оптимальную стратегию. ¬ этом случае каждый из игроков достигает уменьшени€ риска использованием смешанных стратегий. ‘ормально смешанной стратегией называют n мерный веро€тностный вектор p, координаты которого неотрицательны и сумма их равна

1. «начени€ координат вектора интерпретируютс€ как веро€тности выбора стратегии.

—мешанные стратегии реализуютс€ случайным выбором чистых стратегий с веро€тност€ми, заданными в векторе p. Ќапример, пусть дл€ первого игрока смешанна€ стратеги€ задана вектором (xi, x2,.., xn), а дл€ второго - вектором (yi, y2,...,ym). “ак как кака€ то из —ледовательно, исходной платжной матрице A соответствует нова€ платжна€ матрица FA(x,y) игры в смешанных стратеги€х. ¬ теории игр доказано, что игра в смешанных стратеги€х всегда имеет седловую точку, т.е. така€ игра всегда имеет цену, и каждый игрок имеет оптимальную смешанную стратегию.

≈сли игра размерности m х n не имеет в чистых стратеги€х седловой точки, то при больших значени€х m и n решить е достаточно трудно. ¬ некоторых случа€х такую задачу удатс€ упростить исключением дублирующих или заведомо невыгодных стратегий. Ќапример, пусть имеем игру с матрицей (таблица 7) “аблица 7. ћатрица игры

Ц  Ц  Ц

“ребуетс€ найти оптимальную смешанную стратегию игрока A:

Ёта стратеги€ имеет свойство: при любых полезных стратеги€х противника выигрыш будет равен цене игры и. ¬ игре 2х2 обе стратегии противника - полезные, так как иначе игра имела бы решение в чистых стратеги€х (седловую точку). —ледовательно, если игрок A придерживаетс€ своей оптимальной стратегии, то игрок B может пользоватьс€ любой из своих чистых стратегий и при этом цена игры не изменитс€.

ѕоэтому можем записать систему уравнений из решени€ которой найдем ƒл€ определени€ оптимальной смешанной стратегии игрока B, при известной цене игры, достаточно двух уравнений »з решени€ которых получим –ешение игры 2х2 имеет простую геометрическую интерпретацию (рисунок 1).

ѕусть имеетс€ игра 2х2 с матрицей (таблица 11)

Ц  Ц  Ц



Pages:   || 2 |
ѕохожие работы:

Ђ ак получить чистую прибыль 1,2 млн.рублей в мес€ц при использовании лазерных технологий? ѕример финансового плана. ѕримеры изделий.  огда начинаешь свой бизнес или запускаешь новый проект, что важно знать? ÷е...ї

Ђ”чебно-методический отдел –÷ќ ќи»“. Ц 2008 ћедиатека основа информационно-образовательного пространства в школе ќдним из условий информатизации системы образовани€ €вл€етс€ высококачественна€ и высокотехнологична€ информационно-образовательна€ среда. ≈е создание и развитие представл€ет...ї

Ђ”ƒ  621.316 √ришко ј. ., Ѕаннов ¬.я. ѕензенский государственный университет ћ≈“ќƒ ѕќ—Ћ≈ƒќ¬ј“≈Ћ№Ќќ√ќ јЌјЋ»«ј ћќƒ≈Ћ≈… –јƒ»ќЋќ ј÷»ќЌЌџ’ —»—“≈ћ ¬ ѕ–ќ÷≈——≈ Ё —ѕ≈–»ћ≈Ќ“ј јннотаци€: ¬ услови€х...ї

Ђ¬ ≈ – “ ќ Ћ ≈ “ ћи-2 о двум€ двигател€ми √“ƒ-350 »Ќ—“–” ÷»я ѕќ Ё —ѕЋ”ј“ј÷»» » “≈’Ќ»„≈— ќћ” ќЅ—Ћ”∆»¬јЌ»» ј¬»ј÷»ќЌЌќ√ќ ќЅќ–”ƒќ¬јЌ»я ¬≈–“ќЋ≈“ј  ниге 5  эдааив III 19?? г. ...ї

Ђ‘≈ƒ≈–јЋ№Ќќ≈ ј√≈Ќ“—“¬ќ ѕќ “≈’Ќ»„≈— ќћ” –≈√”Ћ»–ќ¬јЌ»ё » ћ≈“–ќЋќ√»» Ќј÷»ќЌјЋ№Ќџ… —“јЌƒј–“ –ќ——»…— ќ… ‘≈ƒ≈–ј÷»» √ќ—“ – 51617-2014 ”—Ћ”√» ∆»Ћ»ўЌќ- ќћћ”ЌјЋ№Ќќ√ќ ’ќ«я…—“¬ј » ”ѕ–ј¬Ћ≈Ќ»я ћЌќ√ќ ¬ј–“»–Ќџћ» ƒќћјћ»  ќћћ”ЌјЋ№Ќџ≈ ”—Ћ”√» ќЅў»≈ “–≈Ѕќ¬јЌ»я Services of housing...ї

Ђ раткое содержание ¬ведение √лава 1 ќѕ≈–ј÷»ќЌЌјя —–≈ƒј SIMULINK √лава 2 ќЅ«ќ– ќ—Ќќ¬Ќќ… Ѕ»ЅЋ»ќ“≈ » SIMULINK. 27 √лава 3 Ѕ»ЅЋ»ќ“≈ ј ЅЋќ ќ¬ SIMPOWERSYSTEMS. 35 √лава 4 √–ј‘»„≈— »… »Ќ“≈–‘≈…— ѕќЋ№«ќ¬ј“≈Ћя POWERGUI √лава 5 —ќ«ƒјЌ»≈ ЁЋ≈ “–ќ“≈’Ќ»„≈— »’ ЅЋќ ќ¬ ѕќЋ№«ќ¬ј“≈Ћя √лав...ї

Ђћинистерство образовани€ и науки –‘ √осударственное образовательное учреждение высшего профессионального образовани€ "“ульский государственный университет" ≈стественнонаучный факультет  афедра физики ”тверждаю ƒекан ≈Ќ факультета ¬.ј. јлферов ""2011 г. –јЅќ„јя ѕ–ќ√–јћћј ƒисциплины ¬ведение...ї

Ђ∆” ќ¬ј ёЋ»я —≈–√≈≈¬Ќј ѕќЋ”„≈Ќ»≈ » »——Ћ≈ƒќ¬јЌ»≈ —¬ќ…—“¬ —¬≈–’”ѕ–”√»’ —ѕЋј¬ќ¬ Ti-Nb-Ta, Ti-Nb-Zr ћ≈ƒ»÷»Ќ— ќ√ќ Ќј«Ќј„≈Ќ»я —пециальность 05.16.09 Ц материаловедение (металлурги€) ј¬“ќ–≈‘≈–ј“ диссертации на соискание степени канд...ї

Ђ омплекты CNC дл€ оснащени€ станков малой и средней мощности  омплекты CNC Ц это компоненты технических и программных средств примен€емые дл€ автоматического (компьютерного) управлени€ металлорежущими станками малой и средней мощности. CNC —omputer numeric control или числовое програ...ї

Ђћинистерство образовани€ и науки –оссийской ‘едерации ‘едеральное государственное автономное образовательное учреждение высшего образовани€ "Ќј÷»ќЌјЋ№Ќџ… »——Ћ≈ƒќ¬ј“≈Ћ№— »… “ќћ— »… ѕќЋ»“≈’Ќ»„≈— »… ”Ќ»¬≈–—»“...ї

Ђ∆Ё“‘, том выn. стр. 458-473 1998, 114, 2(8), @1998 »——Ћ≈ƒќ¬јЌ»≈ –ќЋ» ѕќЋя–»«ј÷»ќЌЌќ√ќ ћ≈’јЌ»«ћј »«Ћ”„≈Ќ»я ј“ќћќ¬ ¬ Ў»–ќ ќћ ƒ»јѕј«ќЌ≈ „ј—“ќ“ ‘ќ“ќЌќ¬ ј. ¬.  ороль –оссийсий морсой техничесий университет 198262, —ант-ѕетербург, –осси€ r. ј. Ћ€лuн* Ќаучно-исследователы:ий институт физии —ант-ѕетербу...ї

Ђ»нструкци€ по монтажу и эксплуатации DEA CO(R) ALLG/ 09.11.2004 / Rev. 00 ”становки повышени€ давлени€ Wilo (DEA) —ерии: CO(R)-. с многоступенчатыми насосами и устройством регулировани€ 2521444/ 1104 vl ¬озможны технические изменени€! WILO GmbH Х Nortkirchenstrae 100 Х D-44263 Dortmи-Hrde Х Telefon (0231) 41 02-0 Х Telefax (023...ї

Ђ–уководство пользовател€ ExStickЃ DO600 Ѓ ѕрибор дл€ измерени€ концентрации растворенного в воде кислорода (оксиметр) ¬ведение ѕоздравл€ем с приобретением прибора дл€ измерени€ концентрации растворЄнного в в...ї

Ђ»нститут электросварки им. ≈. ќ. ѕатона ЌјЌ ”краины ”краинское общество неразрушающего контрол€ и технической диагностики ”льтразвуковой контроль дефектоскопы, нормативные документы, стандарты по ”«  —оставите...ї

Ђѕриборы оптические измерительные многофункциональные OPX-350 –уководство по эксплуатации »»“.411711.035 –Ё –уководство по эксплуатации прибора OPX-350 ќглавление 1 Ќј«Ќј„≈Ќ»≈ 2 “≈’Ќ»„≈— »≈ ’ј–ј “≈–»—“» » 2.1 “≈’Ќ»„≈— »≈ ’ј...ї

Ђћинистерство образовани€ и науки –‘ ‘едеральное государст венное бюдж ет ное образоват ельное учреж дение высшего профессионального образовани€ "Ќј÷»ќЌјЋ№Ќџ… »——Ћ≈ƒќ¬ј“≈Ћ№— »… “ќћ— »… √ќ—”ƒј–—“¬≈ЌЌџ… ”Ќ»¬≈–—»“≈“" ‘едеральное государственное автономное образовательное учреждение высшего профессионально...ї

Ђќ ѕ 43 6210 Ќј”„Ќќ-ѕ–ќ»«¬ќƒ—“¬≈ЌЌќ≈ ѕ–≈ƒѕ–»я“»≈ "ƒќ«ј" ”тверждено ‘¬ ћ.412113.039–Ё-Ћ”  ќћѕЋ≈ “џ »Ќƒ»¬»ƒ”јЋ№Ќџ’ ƒќ«»ћ≈“–ќ¬ √јћћј » –≈Ќ“√≈Ќќ¬— ќ√ќ »«Ћ”„≈Ќ»я ƒ¬√»-8ƒ –уководство по эксплуатации ‘¬ ћ.412113.039–Ё —одер...ї

Ђ√ќ—”ƒј–—“¬≈ЌЌјя »Ќ—ѕ≈ ÷»я –≈—ѕ”ЅЋ» » ”«Ѕ≈ »—“јЌ ѕќ Ќјƒ«ќ–” «ј Ѕ≈«ќѕј—Ќќ—“№ё ∆≈Ћ≈«Ќќƒќ–ќ∆Ќџ’ ѕ≈–≈¬ќ«ќ  ѕ–ј¬»Ћј “≈’Ќ»„≈— ќ… Ё —ѕЋ”ј“ј÷»» ∆≈Ћ≈«Ќџ’ ƒќ–ќ√ –≈—ѕ”ЅЋ» » ”«Ѕ≈ »—“јЌ с изменени€ми и дополнени€ми на 02 но€бр€ 2012 года (¬ведены в действие с 1 декабр€ 2001 года приказом √» "”згосжелдорнадзор" о...ї

Ђ—Ќиѕ 3.05.02-88* —“–ќ»“≈Ћ№Ќџ≈ Ќќ–ћџ » ѕ–ј¬»Ћј √ј«ќ—ЌјЅ∆≈Ќ»≈ ƒата введени€ 1988-07-01 –ј«–јЅќ“јЌџ институтом √ипрониигаз ћинжилкомхоза –—‘—– (канд. экон. наук ¬.√. √олик, канд. техн. наук ћ.—.  упри€нов; √.ѕ. „ирчинска€) с участием ћосгазниипроекта ћосгорисполкома,...ї

Ђћинистерство образовани€ и науки ”ль€новской области областное государственное бюджетное профессиональное образовательное учреждение "ƒимитровградский технический колледж" ќ√Ѕѕќ” ƒ“  ѕравила ѕравила приЄма на обучение в ќ√Ѕѕќ” ƒ“  —ћ  Ц ѕ¬– -7.4 Ц 02 006 —тр. 1 из...ї

Ђћ»Ќ»—“≈–—“¬ќ ќЅ–ј«ќ¬јЌ»я, Ќј” » » ћќЋќƒ≈∆Ќќ… ѕќЋ»“» »  –ј—Ќќƒј–— ќ√ќ  –јя √ќ—”ƒј–—“¬≈ЌЌќ≈ Ѕёƒ∆≈“Ќќ≈ ѕ–ќ‘≈——»ќЌјЋ№Ќќ≈ ќЅ–ј«ќ¬ј“≈Ћ№Ќќ≈ ”„–≈∆ƒ≈Ќ»≈  –ј—Ќќƒј–— ќ√ќ  –јя " ќ–≈Ќќ¬— »… ѕќЋ»“≈’Ќ»„≈— »… “≈’Ќ» ”ћ" ќ—Ќќ¬Ќјя ѕ–...ї

Ђhttp://profbeckman.narod.ru/InformLekc.htm 1. ≈ƒ»Ќ»÷џ »Ќ‘ќ–ћј÷»» »нформаци€ и техническа€ энтропи€ безразмерны, тем не менее, дл€ их количественного описани€ существуют специальные...ї








 
2017 www.lib.knigi-x.ru - ЂЅесплатна€ электронна€ библиотека - электронные матриалыї

ћатериалы этого сайта размещены дл€ ознакомлени€, все права принадлежат их авторам.
≈сли ¬ы не согласны с тем, что ¬аш материал размещЄн на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.