Проведение предпроектного обследования

Проведение предпроектного обследования

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

Проектирование данных

Создание ER-модели

Разработка приложений, тестирование и написание документации

Внедрение созданной ИС, обучение пользователей

Эксплуатация и сопровождение

При сопровождении часть работы отделяют на аутсорсинг, передача на сторону «неважных» функции

Выведение из эксплуатации и утилизация

Виды модернизации ИС

Информационная система состоит из:

– Сетевого оборудования;

– Сети коммуникаций.

Что касается сетевого оборудования, то модернизация информационных систем позволяет:

– уменьшить вероятность сбоев в работе и поломки оборудования;

– увеличить скорость работы сети;

– обезопасить утечку информации;

Реинжиниринг является одним из основных видов модернизации систем. Реинжиниринг информационных сетей – это совмещения старых и новых информационных сетей, анализ их многоструктурности, а также динамики изменения структур.

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

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

– расширение сети;

– закупка и замена оборудования;

– создание систем безопасности;

– использование легального ПО и многое другое;

Модернизация ИСособенно актуальна в случае:

-изменении требований к информационной системе;

-неудовлетворённости работой существующей информационной системы;

-усложнении бизнес-процессов;

-реорганизации компании;

-необходимости провести сертификацию предприятия под стандарт ISO 9000.

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

Решаемые задачи:

-выявление противоречий и ошибок в работе информационной системы;

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

 

Унифицированныйпроцесс Rational (Rational Unified Process, RUP)

RUPоснован на 3 ключевых идеях:

1.весь ход работ направлен итоговыми целями проекта, которые выражены в виде вариантов использования(сценария);

2.основным решением является архитектура результативной системы;

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

RUP является итерационной моделью разработки.

R выделяют 4 итерации(фазы):

1.Фаза начала: цель-достичь компромисса между всеми заинтересованными лицами относ.задач и ресурсов.Уход времени 10% трудоемкости 5%

2.Фаза проектирования: цель-разработать стабильную архитектуру системы.30% времени и 20% трудоемкости.

3.Фаза построения: цель-в результате получается готовая система в режиме опытной эксплуатации.50% времени и 65% трудоемкости.

4.Фаза внедрения: цель-предоставить продукт конечного польвателя.10% времени 10% трудоемкости.

 

Экстремальное программирование (ExtremeProgramming, XP)

К легким методом относят метод экстремального програминрования.Появилось в 2000 году.

Приемы:

1.метафора системы(концепция)-техническая концепция системы в виде одного двух предложений.

2.разработка на основе тестирования

3.программирование парами

4.коллективное владение кодом

5.40-часовая рабочая неделя

6.включение заказ.в команду

7.открытое рабочее пространство

 

 

Принципы создания ИС.

Принцип системности.

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

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

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

^ Принцип развития (открытости)

Принцип новых задач (развития) - возможность постоянного пополнения и обновления ИС. Число решаемых задач постоянно увеличивается и меняется методика их решения.

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

^ Принцип совместимости

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

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

^Принцип стандартизации (унификации)

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

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

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

^ Принцип эффективности

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

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

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

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

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

 

Содержание и методы проектирования ИС. Предпроектная стадия.

 

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

Сбор материалов обследования .

Основными целями являются:

− выявление основных параметров предметной области (напри­мер, предприятия или его части);

− установление условий, в которых будет функционировать про­ект ИС;

− выявление стоимостных и временных ограничений на процесс проектирования.

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

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

Выбор метода проведения обследования. Все методы можно объединить в группы по следующим признакам (Рисунок 4):

− по цели обследования выделяют метод организации локаль­ного проведения обследования, используемый для разработ­ки проекта отдельной задачи или для комплекса задач, и ме­тод системного обследования объекта, применяемый для изу­чения всего объекта с целью разработки для него проекта ИС в целом;

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

− по степени охвата предметной области применяют метод сплошного обследования, охватывающего все подразделения экономической системы, и выборочное, применяемое при на­личии типовых по структуре подразделений (например, це­хов или складов);

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

 

Рисунок 4. Схема классификации методов проведения обследования

 

 

Выбор метода сбора материалов обследования.

Выполнение работ по обследованию предметной области в каком-либо подразделении и сбору материалов можно проводить на основе предварительного проведения выбора методов сбора материалов обследования, которые мож­но разделить на две группы ( Рисунок 5):

 

Рисунок 5. Схема классификации методов сбора материалов обследования

При выборе метода следует учитывать следующие критерии:

- степень личного участия проектировщика в сборе материала;

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

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

 

 

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

Обследование проводится по заранее разработанной програм­ме, составленной по форме, представленной в Таблица 3, содержащей перечень вопро­сов, ответы на которые дадут полное представление о деятельно­сти изучаемого объекта и будут учтены при создании проекта ИС. Вопросы можно систематизировать по трем основным на­правлениям исследования объекта.

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

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

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

Таблица 3. Программа обследования

№ п/п	Наименование вопроса	Источник информации	Получатель информации
1	Цель функциониро­вания объекта	Руководитель предприятия	Руководитель проекта
2	Основные параметры объекта	Руководитель предприятия	Руководитель проекта
3	Организационная структура объекта	Секретарь руководителя	Зам. руководителя проекта
...	...	…	…

 

Разработка плана-графика сбора материалов обследо­вания.

Необходима для организации труда проектировщиков во время выполне­ния сбора материалов обследования и его последующего анали­за. Фрагмент плана-графика представлен вТаблица 4.

 

Таблица 4. План-график выполнения работ на стадии сбора материалов обследования

№ п/п	Наименование работы	Код работы	Исполнитель	Дата начала	Длитель­ность выпол­нения	Дата оконча­ния
1	Определение целей и параметров предприятия	001	Руководитель проекта Серов М.Р.	01.03.99	2	02.03.99
2	Определение организацион­ной структуры предприятия	002	Заместитель руководителя проекта Иванов И.П.	03.03.99	1	03.03.99
	…….
	…….

 

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

 

Сбор и формализация материалов обследования.  

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

Сбор материалов обследования следует проводить с помощью стандартных форм и таблиц, которые удобно читать и обраба­тывать (Рисунок 6).

 

Рисунок 6. Формы документов для формализации материалов обследования

 

Анализ матери­алов обследования и разработка технико-экономического обосно­вания (ТЭО) и технического задания (ТЗ).

Цели:

- сопоставление всей собранной об объекте информации с теми требованиями, которые предъявляются к объекту, определе­ние недостатков функционирования объекта обследования;

- выработка основных направлений совершенствования рабо­ты объекта обследования на базе внедрения проекта ИС, выбор направлений проектирования (выбор инструментария) и оценка эффективности применения выбранного инструментария;

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

Анализ и определение состава объектов автоматизации.

Содержание и методы проектирования ИС. Техно-рабочее проектирование.

 

Содержание и методы проектирования ИС. Внедрение проекта.

На третьей стадии «Внедрение проекта» проводятся подготовка и по­степенное освоение разработанной проектной документации ИС заказчиками системы. В процессе выполнения работ на этой стадии осуществляется выявление частных и системных принци­пиальных недоработок в предлагаемом для внедрения проектном решении.

Внедрение проекта осуществляется в течение трех этапов:

1.2. Подготовка объекта к внедрению проекта . На этом этапе осуществляются следующие операции:

1.2.1. изменяется организационная структура объекта (предприя­тия);

1.2.2. набираются кадры соответствующей квалификации в облас­ти обработки информации и эксплуатации системы и сопро­вождения проектной документации;

1.2.3. оборудуется здание под установку вычислительной техники;

1.2.4. выполняются закупка и установка вычислительной техники с периферией;

1.2.5. в цехах, отделах устанавливаются средства сбора, регистра­ции первичной информации и передачи по каналам связи;

1.2.6. осуществляется установка каналов связи; проводится разра­ботка новых документов и классификаторов;

1.2.7. осуществляется создание файлов информационной базы с нор­мативно-справочной информацией.

На вход этого этапа поступают компоненты «Технического проекта» в части «Плана мероприятий по внедрению», решения по техническому и информационному обеспечению, техноло­гические и инструкционные материалы «Рабочего проекта». В результате выполнения этапа составляется «Акт готовности объекта к внедрению» проекта ИС. Затем формируется состав приемной комиссии, разрабатывается «Программа проведения опытного внедрения» и издается «Приказ о начале опытного вне­дрения».

На этапе « Опытное внедре­ние » вне­дряются проекты нескольких задач в нескольких подсистемах. В процессе опытного внедрения выполняются следующие работы:

1.2.8. подготовка исходных оперативных данных для задач, кото­рые проходят опытную эксплуатацию;

1.2.9. ввод исходных данных в ЭВМ и выполнение запланирован­ного числа реализации;

1.2.10. анализ результатных данных на предмет наличия ошибок.

После устранения ошибок получают «Акт о проведении опыт­ного внедрения», который служит сигналом для начала выпол­нения следующего этапа.

На этапе « Сда­ча проекта в промышленную эксплуатацию » используют следующие документы: договорная документация; «Приказ на разработку ИС»; ТЭО и ТЗ; исправленный «Техно-рабочий проект»; «Приказ о начале промышленного внедрения»; «Программа проведения испытаний»; «Требования к научно-техническому уровню проекта системы».

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

3.3.1. проверка соответствия выполненной работы договорной до­кументации по времени выполнения, объему проделанной ра­боты и затратам денежных средств;

3.3.2. проверка соответствия проектных решений по ИС требова­ниям ТЗ;

3.3.3. проверка соответствия проектной документации гостам и ос­там;

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

3.3.5. проверка качества функционирования информационной базы, оперативности и полноты ответов на запросы;

3.3.6. выявление локальных и системных ошибок и их исправление.

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

 

Содержание и методы проектирования ИС. Эксплуатация и сопровождение проекта.

Четвертая стадия «Эксплуатация и сопровождение проекта». На этой стадии решается вопрос о том, чьими силами (персо­налом объекта-заказчика или организации-разработчика) будут осуществляться эксплуатация и сопровождение проекта, и в слу­чае выбора второго варианта заключается «Договор о сопровож­дении проекта».

1.3. Эксплуатация проекта. В процессе выполнения этапа «Эксплуатация проекта» осуще­ствляются исправления в работе всех частей системы при возник­новении сбоев, регистрация этих случаев в журналах, отслежива­ние технико-экономических характеристик работы системы и на­копление статистики о качестве работы всех компонентов системы.

1.4. На этапе « Сопровождение и модернизация проекта » выполня­ется анализ собранного статистического материала, а также ана­лиз соответствия параметров работы системы требованиям ок­ружающей среды.

 

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

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

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

 

SADT.

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана, в частности, известная методология IDEF0 (IcamDEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

 

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

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

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

ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

связность диаграмм (номера блоков);

уникальность меток и наименований (отсутствие повторяющихся имен);

синтаксические правила для графики (блоков и дуг);

разделение входов и управлений (правило определения роли данных).

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

 

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

 

Существует 5 связей:

1.Управление-выход блока с большим доменом является управлением для блока с меньшим доменом

2..Вход- выход блока с большим доменом является входом с меньшим доменом

3.Обратная связь по управлению

4.Обратная связь по входу

5.Выход- механизм.

При построении SADT необходимо соблюдение 2 правил:

1.правило нумерации

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

Любая работа в SADT-модели обязательно должна иметь все 4 типа стрелок.

 

Моделирование потоков данных. Основные понятия.

 

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

 • внешние сущности;

 • системы и подсистемы;

 • процессы;

 • накопители данных;

• потоки данных.

 

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

 

 Физически процесс может быть реализован различными способами:

 

 это может быть подразделение организации (отдел), выполняющее

 

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

 

 Каждый поток данных имеет имя, отражающее его содержание.

 

 

Принципы построения DFD

Принципы построения DFD.

Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:

-Размещать на каждой диаграмме от 3 до 6-7 процессов.

-Не загромождать диаграммы несущественными на данном уровне деталями

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

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

-Однократно определять функционально идентичные процессы на самом верхнем уровне

-Пользоваться простейшими диаграммными техниками

-Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры

 

Процесс построения DFD.

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

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

2) Идентификация внешних объектов, с которыми система должна быть связана.

3) Идентификация основных видов информации, циркулирующей между системой и внешними объектами.

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

5) Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие вопросы по всем ее частям.

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

7) Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.

8) Проверка основных требований по DFD первого уровня.

9) Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

10) Проверка основных требований по DFD соответствующего уровня.

11) Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.

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

13) После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели.

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

 

Словарь данных. БНФ-нотация

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

Ниже приведен пример описания потока данных с помощью БНФ:

@ИМЯ = ВОСЬМЕРИЧНАЯ ЦИФРА

@ТИП = дискретный поток

@БНФ = [" 0"! " 2"! " 3"! " 4"! " 5"! " 6"! " 7" ]

БНФ-нотация позволяет формально описать расщепление/объединение потоков. Поток может расщепляться на собственные отдельные ветви, на компоненты потока-предка или на то и другое одновременно.

Точные определения потоков содержатся в словаре данных, а не на диаграммах.

Такие определения хранятся в словаре данных в так называемой БНФ-статье. БНФ-статья используется для описания компонентов данных в потоках данных и в хранилищах.

Ее синтаксис: @БНФ=< простой оператор>! < БНФ-выражение>

< простой оператор> есть текстовое описание, заключенное в " /", а < БНФ-выражение> есть выражение в форме Бэкуса-Нуара, допускающее следующие операции отношений:

=  означает " композиция из"

+  означает " И"

[! ] означает " ИЛИ"

( ) означает, что компонент в скобках необязателен

{} означает итерацию компонента в скобках

" " означает литерал.

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

3{болт}7 - от 3 до 7

1{болт} - 1 и более итераций

{шайба}3 - не более трех итераций.

 

20. Методы задания спецификация процессов.

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

Спецификация процесса должна начинаться с ключевого слова (например, @СПЕЦПРОЦ ). Требуемые входные и выходные данные должны быть специфицированы следующим образом:

@ВХОД = < имя символа данных>

@ВЫХОД = < имя символа данных>

@ВХОДВЫХОД = < имя символа данных>, где имя символа данных - соответствующее имя словаря данных.

Ситуация, когда символ данных является одновременно входными и выходными данными, может быть описана двумя способами: либо символ описывается два раза с помощью @ВХОД и @ВЫХОД, либо один раз с помощью @ВХОДВЫХОД.

Методы задания спецификаций:

q текстовое описание

q структурированный естественный язык

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

- последовательная конструкция:

    ВЫПОЛНИТЬ функция1

    ВЫПОЛНИТЬ функция2

    ВЫПОЛНИТЬ функция3

- конструкция выбора:

    ЕСЛИ < условие> ТО

              ВЫПОЛНИТЬ функция1

    ИНАЧЕ

              ВЫПОЛНИТЬ функция2

    КОНЕЦЕСЛИ

- итерация:

    ДЛЯ < условие>                 ПОКА < условие>

    ВЫПОЛНИТЬ функция или ВЫПОЛНИТЬ функция

    КОНЕЦДЛЯ                             КОНЕЦПОКА

q таблица решений

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

ТР состоит из двух частей. Верхняя часть таблицы используется для определения условий. Обычно условие является ЕСЛИ -частью оператора ЕСЛИ-ТО и требует ответа " да-нет".

Нижняя часть ТР используется для определения действий, т.е. ТО -части оператора ЕСЛИ - ТО. ЕСЛИ ИДЕТ ДОЖДЬ, ТО РАСКРЫТЬ ЗОНТ

ИДЕТ ДОЖДЬ является условием, а РАСКРЫТЬ ЗОНТ - действием.

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

Пример таблицы решений:

УСЛОВИЯ		1	2	3	4	5	6	7	8
С1	isctrl(c)	Д	Д	Д	Д	Н	Н	Н	Н
С2	I> max_lenght	Д	Д	Н	Н	Д	Д	Н	Н
С3	out_of_range(c)	Д	Н	Д	Н	Д	Н	Д	Н
ДЕЙСТВИЯ
D1	beep( )	1	1	1	1	1	1	1
D2	return(ERROR)	2	2	2	2	2	2	2
D3	return(++i)								2
D4	putchar(c)								1

 

q дерево решений

q визуальный язык

q язык программирования

 

 

ER -модель Чена

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

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

 

СУЩНОСТЬ представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

 

ОТНОШЕНИЕ в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).

 

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

обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);

использование этой информации различными приложениями.

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

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

Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.

ЗНАЧЕНИЕ связи характеризует ее тип и, как правило, выбирается из следующего множества:

{" O или 1", " 0 или более", " 1", " 1 или более", " p: q" ( диапазон )}.

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

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

1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.

n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).

 

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

 

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

 

ER-модель Баркера

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

 

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

 

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

Читается связь отдельно для каждого конца, показывая, как сущность КЛИЕНТ связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова " должен (быть)" или " может (быть)".

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

 

25. Методология IDEF1 (ERD)

 

Разработка ERD включает следующие основные этапы:

 

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

 Идентификация отношений между сущностями и указание типов отношений.

 Разрешение неспецифических отношений (отношений n*m).

 

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

Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На данном этапе некоторые отношения могут быть неспецифическими (n*m - многие-ко-многим). Такие отношения потребуют дальнейшей детализации на этапе 3.

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

 

 

26. Спецификации управления (STD)

 

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

 

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

 

STD состоит из следующих объектов:

 

СОСТОЯНИЕ - может рассматриваться как условие устойчивости для системы. Находясь в определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п.

 

НАЧАЛЬНОЕ СОСТОЯНИЕ - узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет ровно одно начальное состояние, соответствующее состоянию системы после ее инсталляции, но перед началом реальной обработки, а также любое (конечное) число завершающих состояний.

 

ПЕРЕХОД определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия (например, СЧЕТЧИК=999 или КНОПКА НАЖАТА). Следует отметить, что, вообще говоря, не все события необходимо вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.

 

Таким образом УСЛОВИЕ представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например, " ПАРОЛЬ" =666, где ПАРОЛЬ - входной поток.

 

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

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

 

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

При построении STD рекомендуется следовать нижеперечисленным правилам:

строить STD на как можно более высоком уровне детализации DFD;

строить как можно более простые STD;

по возможности детализировать STD;

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

 

27. Средства структурного проектирования. Структурные карты Константайна

 

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

 

Структурные карты Константайна

 

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

модуль состоит из множества операторов языка программирования, записанных последовательно;

модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту;

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

 

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

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

Собственно МОДУЛЬ. Используется для представления обрабатывающего фрагмента для его локализации на диаграмме.

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

БИБЛИОТЕКА. Отличается от подсистемы тем, что определена вне проекта данной системы.

ОБЛАСТЬ ДАННЫХ. Используется для указания модулей, содержащих исключительно области глобальных/распределенных данных.

 

28. Средства структурного проектирования. Структурные карты Джексона

 

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

 

По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов:

СТРУКТУРНЫЙ блок (базовая компонента методологии) представляет частную функцию или блок кодов с одним входом и одним выходом.

ПРОЦЕДУРНЫЙ блок является специальным видом структурного блока, представляющим вызов ранее определенной процедуры.

БИБЛИОТЕЧНЫЙ блок аналогичен процедурному и представляет вызов библиотечного модуля.

 

Для взаимоувязывания блоков используются связи следующих типов:

последовательная связь, обеспечивающая последовательное выполнение слева направо;

параллельная связь, обеспечивающая одновременное выполнение блоков;

условная связь, обеспечивающая выбор одной из альтернатив;

итерационная связь, обеспечивающая выполнение блока в цикле.

 

UML.Диаграмма классов.

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

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

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

< Имя_пакета>:: < Имя_класса>

Например: «Банк:: Счет».

Атрибуты класса: < квантор видимости> < имя атрибута> [кратность]: < тип атрибута> = < исходное значение> {строка-свойство}

Квантор видимости может принимать одно из трех возможных значений и отображается при помощи соответствующих специальных символов:

· « + » обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма;

· « # » обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса;

· « - » обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

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

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

[нижняя_граница1.. верхняя_граница1, нижняя_граница2.. верхняя_грашца2, ..., нuжняя_гpaнuцak.. верхняя_границаk],

Например: [0..1]-кратность атрибута может принимать значение 0 или 1.

[1..3, 5, 7] – кратность атрибута может принимать любое значение из чисел 1, 2, 3, 5, 7.

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

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

Например: цвет: Color =(255, 0, 0)

имя_сотрудника [1..2]: String=Иван Иванович.

Строка-свойство служит для указания значений атрибута, которые не могут быть изменены в программе при работе с данным типом объектов. ( в {} скобках).

Пример: «заработная_плата: Currency = $500» означает, что при создании нового экземпляра «Сотрудник» (например, прием на работу нового сотрудника) для него устанавливается по умолчанию заработная плата в $500.

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

< квантор видимости> < имя операции> (список параметров): < выражение типа возвращаемого значения> {строка-свойство}

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

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

< вид параметра> < имя параметра>: < выражение типа> =< значение параметра по умолчанию>.

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

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

Например: +создать()

+нарисовать(форма: Многоугольник=прямоугольник, цвет, цвет_заливки: Color =(0, 0, 255))

 

Отношения между классами

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

· зависимости (dependency relationship);

· ассоциации (association relationship);

· обобщения (generalization relationship)

· реализации ( практически не используется)

Отношения зависимости

Показывает, что при изменении в одном классе (источник) происходит изменение в другом классе (клиент).

Клиент                                  Источник

 

Класс С-объект, Классы А и Б – источники.

Ключевые слова отнош.зависимости (стереотипы):

• «access» - служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
• «bind» - класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
• «derive» - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника; «import» — открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
• «refine» - указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

2.Отношения ассоциации. Показывает существование связи между двумя классами.

Бинарная связь

Тренарная связь

Исключающая ассоциация между 3 классами

Отношения ассоциации имеют 2 разновидности:

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

 

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

 

3.Отношения обобщения.

 

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

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

o {complete} - означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может;

 

o {disjoint} - означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов;

 

o {incomplete}- означает случай, противоположный первому, то есть, что на диаграмме указаны не все классы-потомки. В дальнейшем возможно восполнить их перечень не изменяя уже построенную диаграмму;

 

 

o {overlapping} - означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

 

 

 

UML. Диаграмма состояний.

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

Диаграмма состояний основана на теории автоматов:

1. Автомат не запоминает историю перемещения из состояния в состояние. Другими словами, автомат «забывает» все состояния, которые предшествовали текущему в данный момент времени. Образно говоря, существует непрозрачная стена, отделяющая текущее состояние от прошлого поведения объекта.

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

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

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

5. Граф автомата не должен содержать изолированных состояний и переходов. Это условие означает, что для каждого из состояний, кроме начального, должно быть определено предшествующее состояние. Каждый переход должен обязательно соединять два состояния автомата. Допускается переход из состояния в себя, такой переход еще называют «петлей».

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

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

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

Имя состояния представляет собой строку текста, которая раскрывает содержательный смысл данного состояния. Имя всегда записывается с заглавной буквы. 9Глагол или причастие). Имя может и отсутствовать.

Список внутренних действий

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

< метка-дёйствия '/' выражение-действия>

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

Если список выражений действия пустой, то разделитель в виде наклонной черты '/' может не указываться.

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

• entry — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);
• exit — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);
• do — эта метка специфицирует выполняющуюся деятельность (" doactivity" ), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия.

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

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

Состояние бывает 2 типов:

· Начальное – представляет собой процесс инициации. На одной диаграмме только 1 состояние.

· Конечное – может быть несколько штук. Не содержит последействий.

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

< сигнатура события> '['< сторожевое условие> ']' < выражение действия>.

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

Если вся стрелка (переход) подписана, то он называется триггерным, в противном случае – нетригеррным.

Сторожевое условие (guardcondition), всегда записывается в прямых скобках, представляет собой некоторое булевское выражение (1/0, да/нет).

Состояния бывают 2 видов:

· Составное (имеет внутреннее состояние)

· подсоставное

Принято выделять последовательное и параллельное подсостояние.

Последовательное

Параллельное

Диаграмма деятельности

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

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

Основными элементами являются:

1.состояние действия – специальный случай состояния.

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

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

Кооперация

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

Кооперация может быть представлена на двух уровнях:

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

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

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

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

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

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

Строка текста в прямоугольнике должна иметь следующий формат:

'/' < Имя роли классификатора> ': ' < Имя классификатора>

[': ' < Имя классификатора > ]*

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

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

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

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

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

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

Объекты

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

< Имя объекта> '/' < Имя роли классификатора> ': ' < Имя классификатора>

[': ' < Имя классификатора > ]*

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

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

Ниже приводятся возможные варианты записи строки текста в прямоугольнике объекта:

·: С — анонимный объект, образуемый на основе класса С;

· / R — анонимный объект, играющий роль R;

· / R: С — анонимный объект, образуемый на основе класса С и играющий роль R;

· О / R — объект с именем О, играющий роль R;

· О: С — объект с именем О, образуемый на основе класса С;

· О / R: С — объект с именем О, образуемый на основе класса С и играющий роль R;

· О или — объект с именем О;

· О: — «объект-сирота» с именем О;

· / R — роль с именем R;

·: С — анонимная роль на базе класса С;

· / R: С — роль с именем R на основе класса С.

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

В контексте языка UML все объекты делятся на две категории: пассивные и активные.

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

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

Активные объекты на канонических диаграммах обозначаются прямоугольником с более широкими границами. Иногда может быть явно указано ключевое слово {active}, чтобы выделить активный объект на диаграмме. Каждый активный объект может инициировать единственную нить или процесс управления и представлять исходную точку потока управления.

Составной объект (composite object) или объект-контейнер предназначен для представления объекта, имеющего собственную структуру и внутренние потоки (нити) управления. Составной объект является экземпляром составного класса (класса-контейнера), который связан отношением агрегации или композиции со своими частями. Аналогичные отношения связывают между собой и соответствующие объекты.

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

Связи

Связь (link) является экземпляром или примером произвольной ассоциации. Связь как элемент языка UML может иметь место между двумя и более объектами. Бинарная связь на диаграмме кооперации изображается отрезком прямой линии, соединяющей два прямоугольника объектов. На каждом из концов этой линии могут быть явно указаны имена ролей данной ассоциации. Рядом с линией в ее средней части может записываться имя соответствующей ассоциации.

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

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

• «association» - ассоциация (предполагается по умолчанию, поэтому этот стереотип можно не указывать);
• «parameter» - параметр метода. Соответствующий объект может быть только параметром некоторого метода;
• «local» - локальная переменная метода. Ее область видимости ограничена только соседним объектом;
• «global» - глобальная переменная. Ее область видимости распространяется на всю диаграмму кооперации;
• «self» - рефлексивная связь объекта с самим собой, которая допускает передачу объектом сообщения самому себе. На диаграмме кооперации рефлексивная связь изображается петлей в верхней части прямоугольника объекта.

Сообщения

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

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

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

Каждое сообщение может быть помечено строкой текста, которая имеет следующий формат:

< Предшествующие сообщения> < [Сторожевое условие] >

< Выражение последовательности>

< Возвращаемое значение— имя сообщения> < Список аргументов>

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

< Номер сообщения ', '> < Номер сообщения, '> '/'

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

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

Пример записи предшествующих сообщений:

A3, В4/ С5: ошибка записи (сектор).

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

Пример записи сторожевых условий без номеров предшествующих сообщений:

• [(х> =0)& (х< =255)] 1.2: отобразить_на_экране_цвет(х);
• [количество цифр номера = 7] 3.1: набрать_телефонный_номер();

Выражение последовательности - это разделенный точками список отдельных термов последовательностей, после которого записывается двоеточие:

< Терм последовательности'.'> < Терм последовательности'.'> ': '

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

[Целое число| Имя] [Символ рекуррентности].

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

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

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

• '*' '[' Предложение-итерация ']' для записи итеративного выполнения соответствующего выражения. Итерация представляет последовательность сообщений одного уровня вложенности. Предложение-итерация может быть опущено, если условия итерации никак не специфицируются. Наиболее часто предложение-итерация записывается на некотором псевдокоде или языке программирования. В языке UML формат записи этого предложения не определен. Например, " *[/: =/..n]", что означает последовательную передачу сообщения с параметром /, который изменяется от 1 до некоторого целого числа n с шагом 1;
• '['Предложение-условие У ']’ для записи ветвления. Это условие представляет такое сообщение, передача которого по данной ветви возможна только при истинности этого условия. Чаще всего предложение-условие записывают на некотором псевдокоде или языке программирования, поскольку в языке UML формат записи этого предложения не определен. Например, [х> у] означает, что сообщение по некоторой ветви будет передано только в том случае, если значение х больше значения у.

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

Например, сообщение

1.2.3: р: = найти_документ (спецификация_документа)

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

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

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

Так, в приведенном выше примере сообщения

1.2.3: р: = найти_документ (спецификация_документа)

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

39. Диаграмма компонентов

В языке UML для физического представления моделей систем

используются так называемые диаграммы реализации (implementation

diagrams), которые включают в себя две отдельные канонические

диаграммы: диаграмму компонентов и диаграмму развертывания.

Диаграмма компонентов позволяет определить архитектуру

разрабатываемой системы, установив зависимости между

программными компонентами, в роли которых может выступать

исходный, бинарный и исполняемый код. Во многих средах разработки

модуль или компонент соответствует файлу.

Диаграмма компонентов обеспечивает согласованный переход от

логического представления к конкретной реализации проекта в

форме программного кода. Одни компоненты могут существовать

только на этапе компиляции программного кода, другие - на этапе его

исполнения. Диаграмма компонентов отражает общие зависимости между компонентами

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

􀂉 Визуализации общей структуры исходного кода программной

системы.

􀂉 Спецификации исполнимого варианта программной системы.

􀂉 Обеспечения многократного использования отдельных

фрагментов программного кода.

􀂉 Представления концептуальной и физической схем баз

данных

Основными графическими элементами диаграммы компонентов являются

􀂉 компоненты,

􀂉 интерфейсы

􀂉 зависимости между ними

Для представления физических сущностей в языке UML применяется

специальный термин - компонент (component). Компонент реализует

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

элементов физического представления модели

Если компонент представляется на уровне типа, то в качестве его

имени записывается только имя типа с заглавной буквы.

Если же компонент представляется на уровне экземпляра, то в

качестве его имени записывается

< имя компонента ': ' имя типа>

При этом вся строка имени подчеркивается

􀂉 имена исполняемых файлов (с указанием расширения.ехе),

􀂉 имена динамических библиотек (расширение.dll),

􀂉 имена Web-страниц (расширение.html),

􀂉 имена текстовых файлов (расширения.txt или.doc) или файлов

справки (.hlp),

􀂉 имена файлов баз данных (.DB)

􀂉 и др.

В качестве простых имен принято использовать:

В языке UML выделяют три вида компонентов

􀂉 компоненты развертывания, которые обеспечивают

непосредственное выполнение системой своих функций:

динамически подключаемые библиотеки с расширением dll (а),

Web-страницы на языке разметки гипертекста с расширением

html (б) и файлы справки с расширением hlp (в).

􀂉 компоненты-рабочие продукты. Как правило - это файлы с

исходными текстами программ, например, с расширениями h или

срр для языка C++ (г).

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

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

указание стереотипа компонента перед его именем. Виды

стереотипов

􀂉 Библиотека (library) - определяет первую разновидность

компонента, который представляется в форме динамической

или статической библиотеки.

􀂉 Таблица (table) - также определяет первую разновидность

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

данных.

􀂉 Файл (file) - определяет вторую разновидность компонента,

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

программ.

􀂉 Документ (document) - определяет вторую разновидность

компонента, который представляется в форме документа.

􀂉 Исполнимый (executable) - определяет третий вид компонента,

который может исполняться в узле.

Зависимость не является ассоциацией, а служит для представления

только факта наличия такой связи, когда изменение одного элемента

модели оказывает влияние или приводит к изменению другого

элемента модели.

Другим случаем отношения зависимости на диаграмме компонентов

является отношение между различными видами компонентов. Наличие

подобной зависимости означает, что внесение изменений в исходные

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

изменениям самого компонента.

Графическое изображение отношения зависимости между компонентами

Наконец, на диаграмме компонентов могут быть представлены

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

классами. Эта информация имеет важное значение для обеспечения

согласования логического и физического представлений модели

системы.

Если требуется подчеркнуть, что некоторый компонент реализует

отдельные классы, то для обозначения компонента используется

расширенный символ прямоугольника.

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

графической нотации, такие как классы (компонент уровня типа) или

объекты (компонент уровня экземпляра)

Диаграмма развертывания

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

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

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

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

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

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

Диаграммы развертывания разрабатываются совместно системными аналитиками, сетевыми инженерами и системотехниками.

Узел

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

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

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

Например, аппаратная часть системы может состоять из нескольких компьютеров, каждый из которых соответствует отдельному узлу-экземпляру в модели. Однако все эти узлы-экземпляры относятся к одному типу узлов, а именно узлу с именем типа «Компьютер».

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

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

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

Соединения

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

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

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

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

Рекомендации по построению диаграммы развертывания

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

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

 

Управление проектом.

Основные компоненты процесса управления проекта:

· Управлениекоординацией (Project Integration Management)

· Управлениецелями (Project Scope Management)

· Управлениевременем (Project Time Management)

· Управлениестоимостью (Project Cost Management)

· Управлениекачеством (Project Quality Management)

· Управление человеческими ресурсами (ProjectHumanResourceManagement)

· Управлениекоммуникациями (Project Communication Management)

· Управлениерисками (Project Risk Management)

· Управлениепоставками (Project Procurement Management)

Группы процессов

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

· процессы инициации - принятие решения о начале выполнения проекта;

· процессы планирования - определение целей и критериев успеха проекта и

разработка рабочих схем их достижения;

· процессы исполнения - координация людей и других ресурсов для выполнения плана;

· процессы анализа - определение соответствия плана и исполнения проекта

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

применения корректирующих воздействий;

· процессы управления - определение необходимых корректирующих воздействий, их

согласование, утверждение и применение;

· процессы завершения - формализация выполнения проекта и подведение его к

упорядоченному финалу

1. Процессы инициации

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

2. Процессы планирования

Основные процессы планирования:

· планирование целей;

· декомпозиция целей;

· определение состава операций (работ) проекта;

· определение взаимосвязей операций;

· оценка длительностей или объемов работ;

· определение ресурсов (людей, оборудования, материалов) проекта;

· назначение ресурсов;

· оценка стоимостей;

· составление расписания выполнения работ;

· оценка бюджета;

· разработка плана исполнения проекта;

· определение критериев успеха.

Вспомогательные процессы планирования:

· планирование качества;

· планирование организации;

· назначение персонала;

· планирование взаимодействия;

· идентификация риска;

· оценка риска;

· разработка реагирования;

· планирование поставок;

· подготовка условий.

3. Процессы исполнения и контроля

Основные процессы планирования:

· сам процесс исполнения плана проекта

Вспомогательные процессы планирования:

· учет исполнения;

· подтверждение качества;

· подготовка предложений;

· выбор поставщиков;

· контроль контрактов;

· развитие команды проекта.

4. Процессы анализа

Основные процессы планирования:

· анализ сроков;

· анализ стоимости;

· анализ качества;

· подтверждение целей

Вспомогательные процессы планирования:

· оценка исполнения;

· анализ ресурсов.

5. Процессы управления

Основные процессы планирования:

· общее управление изменениями;

· управление ресурсами;

· управление целями;

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

Вспомогательные процессы планирования:

· управление рисками;

· управление контрактами.

6. Процессы завершения:

· закрытие контрактов;

· административное завершение.

Виды деятельности, входящие в управление проектом:

· Управление содержанием проекта и качеством

· Управление ресурсами проекта

· Управление рисками

· Управление коммуникациями и информационное обеспечение проекта

· Управление конфигурациями и изменениями

· Управление проектной средой и технологиями

· Контроль и мониторинг состояния проекта

Управление содержанием проекта и качеством

Основные элементы содержания проекта следующие:

· Целевые критерии проекта

· Иерархическая структура работ (workbreakdownstructure)

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

Метрики ПО:

· размер программы в строках ее кода (linesofcode, LOC).

· функциональные точки (functionalpoints, FP)

· конструктивная модель стоимости версии II (ConstructiveCostModel II, СОСОМОII).

Размер программы в строках ее кода

Ее основное достоинство – понятность и простота вычисления.

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

Функциональные точки

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

· Для всех данных из перечисленных пяти категорий оценивается их сложность (по шкале " низкая" – " средняя" – " высокая" ).

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

COCOMOII

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

1. На самых ранних этапах, когда примерно известны только общие требования, а

проектирование еще не начиналось, используется мо-дель состава приложения

(ApplicationCompositionModel). В ее рамках трудоемкость проекта оценивается в

человеко-месяцах по формуле

Effort= A⋅ Size

· Коэффициент А учитывает возможное переиспользование части компонентов и

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

инструментов и оцениваемую числом от 4 до 50

А=(100-процент переиспользования)/производительность

· Size представляет собой оценку размера в терминах экранов, форм, отчетов,

компонентов и модулей будущей системы. Каждый такой элемент оценивается с

коэффициентом от 1 до 10 в зависимости от своей сложности.

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

начинается разработка архитектуры ПО, используется модель этапа

предварительного проектирования (EarlyDesignModel)

Для трудоемкости (в человеко-месяцах):

Effort = A * (Size)^B M_E+ трудозатраты на автоматически генерируемый код

Для времени (в месяцах): Time = T * Effort_S^{(0.28+0, 2(B-1, 01))} * Sced

· Коэффициент А считается равным 2, 45, а Т считается равным 3, 67.

· Size – оценка размера ПО в тысячах строк кода.

· В – фактор процесса разработки, который вычисляется по формуле

В=0, 91+0, 01*Σ _i=1..5 *W_i

· МЕ – произведение семи коэффициентов затрат, каждый из которых лежит в интервале от 1 до 6:

1. возможности персонала;

2. надежность и сложность продукта;

3. требуемый уровень повторного использования;

4. сложность платформы;

5. опытность персонала;

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

7. плотность графика проекта

· Efforts обозначает оценку трудоемкости без учета плотности графика, a Seed –требуемое сжатие времени выполнения проект

Управление ресурсами

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

Специфика управления персоналом:

· Производительность;

· Знания и умения;

· Мотивация персонала:

· пирамида Маслоу;

· деление людей на 3 типа:

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

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

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

· теория справедливости

· теория ожиданий

· Построение сплоченной команды;

· Конфликты;

· Лидерство и влияние.

Управление рисками:

Риски проекта, влияющие на его ход:

· технологические риски

· кадровые риски

· риски требований

· коммерческие риски

· управленческие риски

· производственные риски

Риски продукта, влияющие на результаты проекта:

· технические риски

· эксплуатационные риски

· правовые и общественные риски

Бизнес-риски:

· контрактные риски

· инвестиционные риски

· сбытовые риски

· конъюнктурные риски

Управление коммуникациями и информационным обеспечением:

· Представительские связи

· Координация работ

· Обмен информацией внутри организации-исполнителя.

· Разведка и сбор внешней информации

· Составление предложений

· Ведение переговоров

 

Проведение предпроектного обследования

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

Проектирование данных

Создание ER-модели

12345678910Следующая ⇒

Поделиться: