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

Лекционный комплекс Лекция 1. Введение План: 1. Предмет изучения и структура дисциплины. Цель и задача инструментальных средств. 2. Краткая история развития инструментальных средств. 3. Основные понятия. 1 Предмет изучения и структура дисциплины. Цель и задача инструментальных средств Дисциплина «Инструментальные средства разработки программ» является обязательной профильной дисциплиной. Данная дисциплина формирует профессиональные знания и умения при освоении специальности программных инструментальных средств, используемых для проектирования программных систем и обеспечения жизненного цикла программ. Пререквизиты: Информатика; Языки и технологии программирования; Объектно-ориентированное программирование. Постреквизиты: Интернет – технологии; системное программирование; основы информационной безопасности. Цель дисциплины: Целью дисциплины «Инструментальные средства разработки программ» является ознакомление студентов с вопросами проектирования программных систем и обеспечение жизненного цикла программ, освоение ими основ моделирования бизнес-процессов и приобретение практических навыков применения современных технологии проектирования (Computer-Aided Software/System Engineering (CASE) -технологии). Задачи: В результате изучения дисциплины студенты должны: Знать: • технологию проектирования программных систем; • основные направлений в области проектирования, разработки программных продуктов и набора инструментальных средств, обеспечивающих их жизненный цикл; • теоретические основы построения инструментального программного обеспечения; • международные и отечественные стандарты, используемые при разработке программных продуктов; • классические и современные подходы к построению интерфейса и информационной структуры инструментария. Уметь: • использовать унифицированный язык моделирования UML и применять CASE-средства (BPwin, Erwin, Aris, ModelMart, Rational Rose, Microsoft Office Visio 2007) при проектировании программных систем; • выбора инструментального средства, обеспечивающего этапы жизненного цикла программ, при практическом использовании - разработке и реализации программных продуктов; • Использования стандартов построения программного инструментария; • анализа характеристик качества и оценки эффективности использования инструментария: • оценки экономической эффективности внедрения инструментального программного средства; • реализации структурного и объектно-ориентированного подхода в работе с инструментарием. Иметь: • представление о современных технологиях проектирования программных систем (CASE-технологии). - анализа характеристик качества и оценки эффективности использования инструментария; - оценки экономической эффективности внедрения инструментального программного средства; - реализации структурного и объектно-ориентированного подхода в работе с инструментарием. Владеть навыками - проектирования программных систем и обеспечения жизненного цикла программ; - моделирования бизнес-процессов. Быть компетентными - в современных технологиях проектирования (Computer-Aided Software/System Engineering (CASE) -технологии). Содержание дисциплины Введение. Предмет изучения и структура дисциплины. Цель и задача инструментальных средств. Краткая история развития инструментальных средств. Основные понятия. Комплекс вопросов, связанных с моделированием бизнес-процессов. Обзор технологий проектирования. CASE-системы структурного типа BPWin, ERWin, ModelMart. Проектирование систем на языке UML в среде Rational Rose. Aris. Microsoft Office Visio 2007. 1 Классификация инструментальных средств Определение понятий: программа, уровни и категории (направления) программирования, инструмент и разработка программ. Порядок разработки. История развития инструментальных средств разработки программ. Классификация и основные особенности современных инструментальных средств. Описание функциональности разработки. Требования к содержанию и документам. Выработка требований. Техническое задание. Методы и инструменты проектирования. 2 Методы и инструменты Современные CASE-технологии. Технология освоения и внедрения CASE-средств. Оценка CASE-средств. Характеристика современных CASE- средств. Классификация CASE-средств. CASE-системы структурного типа (BPWin, ERWin). Графические и текстовые средства описания и документирования предметной области - данных и функций. Моделирование бизнес-процессов средствами BPwin. Функциональная модель организации работы - AS-IS. Модель ТО-BE и ее функционально-стоимостной анализ. ERwin - средство разработки структуры базы данных (БД). Отображение логического и физического уровня модели данных в ERwin. Model Mart - система управления моделями для групповой разработки при создании приложений для архитектуры "клиент-сервер", хранилищ данных, Web. 3 Методы проектирования и жизненный цикл программ Документы международного и государственного стандарта, определяющие состав разработки RUP. Процессы жизненного цикла ПО. Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями. Модели жизненного цикла ПО. Методы проектирования и обеспечение жизненного цикла программ основанные на международных стандартах, структурный и объектно-ориентированный подходы к проектированию и их взаимосвязь. Практические рекомендации по освоению и внедрению CASE- средств, включая критерии их выбора и сравнительный анализ. 4 Унифицированный язык моделирования (UML) Язык UML. Введение в язык UML. Унифицированный язык моделирования (UML). Ключевые аспекты языка. Диаграмма и конструкция UML. Применение диаграмм каждого типа для структурного моделирования и моделирования поведения. Использование UML для решения разнообразных проблем моделирования. Объектно-ориентированные CASE-системы (Rational Rose. Aris. -Vlicrosoft Office Visio 2007). Рекомендации по применению CASE- систем. Проектирование систем на языке UML в среде Rational Rose, Aris, Microsoft Otfice Visio 2007. Rational Rose - среда моделирования, которая поддерживает генерацию кода из моделей, написанных на языке Ada. ANSI C++, C++. CORBA. Java/J2EE. Visual C++ и Visual Basic. ARIS (IDS Scheer) - инструмент коллективной работы над совокупностью взаимосвязанных моделей различных типов, предназначенных для описания бизнес-процессов, данных и информационных систем, деятельности компаний, Microsoft Office Visio 2007 (Microsoft) - средство создания различных типов моделей бизнес- процессов и данных, позволяющее создавать диаграммы и .модели с применением различных методологий 2 Краткая история развития инструментальных средств Чтобы разобраться в существующих технологиях программирования и определить основные тенденции их развития, целесообразно рассматривать эти технологии в историческом контексте, выделяя основные этапы развития программирования как науки. Первый этап — «стихийное» программирование. Этот этап охватывает период от момента появления первых вычислительных машин до середины 60-х годов XX в. В этот период практически отсутствовали сформулированные технологии и программирование фактически было искусством. Первые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных. В начале 60-х годов XX в. разразился «кризис программирования». Он выражался в том, что фирмы, взявшиеся за разработку сложного программного обеспечения, такого как операционные системы, срывали все сроки завершения проектов. Проект устаревал раньше, чем был готов к внедрению, увеличивалась его стоимость, и в результате многие проекты так никогда и не были завершены. Объективно все это было вызвано несовершенством технологии программирования. Прежде всего стихийно использовалась разработка «снизу—вверх» — подход, при котором вначале проектировали и реализовывали сравнительно простые подпрограммы, из которых затем пытались построить сложную программу. Анализ причин возникновения большинства ошибок позволил сформулировать новый подход к программированию, который был назван «структурным». Второй этап — структурный подход к программированию (60—70-е годы XX в.). Структурный подход к программированию представляет собой совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки программного обеспечения. В основе структурного подхода лежит декомпозиция (разбиение на части) сложных систем с целью последующей реализации в виде отдельных небольших (до 40—50 операторов) подпрограмм. С появлением других принципов декомпозиции (объектного, логического и т. д.) данный способ получил название процедурной декомпозиции. В отличие от используемого ранее процедурного подхода к декомпозиции, структурный подход требовал представления задачи в виде иерархии подзадач простейшей структуры. Проектирование, таким образом, осуществлялось «сверху—вниз» и подразумевало реализацию общей идеи, обеспечивая проработку интерфейсов подпрограмм. Одновременно вводились ограничения на конструкции алгоритмов, рекомендовались формальные модели их описания, а также специальный метод проектирования алгоритмов — метод пошаговой детализации. Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Как следствие этого в языках появляется возможность определения пользовательских типов данных. Одновременно усилилось стремление разграничить доступ к глобальным данным программы, чтобы уменьшить количество ошибок, возникающих при работе с глобальными данными. В результате появилась и начала развиваться технология модульного программирования. Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные в отдельно компилируемые модули (библиотеки подпрограмм), например модуль графических ресурсов, модуль подпрограмм вывода на принтер. Связи между модулями при использовании данной технологии осуществляются через специальный интерфейс, в то время как доступ к реализации модуля (телам подпрограмм и некоторым «внутренним» переменным) запрещен. Эту технологию поддерживают современные версии языков Pascal и С (C++). Использование модульного программирования существенно упростило разработку программного обеспечения несколькими программистами. Теперь каждый из них мог разрабатывать свои модули независимо, обеспечивая взаимодействие модулей через специально оговоренные межмодульные интерфейсы. Кроме того, модули в дальнейшем без изменений можно было использовать в других разработках, что повысило производительность труда программистов. Практика показала, что структурный подход в сочетании с модульным программированием позволяет получать достаточно надежные программы, размер которых не превышает 100 000 операторов. Узким местом модульного программирования является то, что ошибка в интерфейсе при вызове подпрограммы выявляется только при выполнении программы (из-за раздельной компиляции модулей обнаружить эти ошибки раньше невозможно). При увеличении размера программы обычно возрастает сложность межмодульных интерфейсов, и с некоторого момента предусмотреть взаимовлияние отдельных частей программы становится практически невозможно. Для разработки программного обеспечения большого объема было предложено использовать объектный подход. Третий этап — объектный подход к программированию (с середины 80-х до конца 90-х годов XX в.). Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа {класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений. Объектная структура программы впервые была использована в языке имитационного моделирования сложных систем Simula, появившемся еще в 60-х годах XX в. Основным достоинством объектно-ориентированного программирования по сравнению с модульным программированием является «более естественная» декомпозиция программного обеспечения, которая существенно облегчает его разработку. Это приводит к более полной локализации данных и интегрированию их с подпрограммами обработки, что позволяет вести практически независимую разработку отдельных частей (объектов) программы. Кроме этого, объектный подход предлагает новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения. Эти механизмы позволяют конструировать сложные объекты из сравнительно простых. В результате существенно увеличивается показатель повторного использования кодов и появляется возможность создания библиотек классов для различных применений. Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так, были созданы среды, поддерживающие визуальное программирование, например Delphi, C++ Builder, Visual C++ и т. д. При использовании визуальной среды у программиста появляется возможность проектировать некоторую часть, например интерфейсы будущего продукта, с применением визуальных средств добавления и настройки специальных библиотечных компонентов. Результатом визуального проектирования является заготовка будущей программы, в которую уже внесены соответствующие коды. Использование объектного подхода имеет много преимуществ, однако его конкретная реализация в объектно-ориентированных языках программирования, таких как Pascal и C++, имеет существенные недостатки: 1) фактически отсутствуют стандарты компоновки двоичных результатов компиляции объектов в единое целое даже в пределах одного языка программирования. Компоновка объектов, полученных разными компиляторами C++, в лучшем случае проблематична, что приводит к необходимости разработки программного обеспечения с использованием средств и возможностей одного языка программирования высокого уровня и одного компилятора, а значит, требует наличия исходных кодов используемых библиотек классов; 2) изменение реализации одного из программных объектов, как минимум, связано с перекомпиляцией соответствующего модуля и перекомпоновкой всего программного обеспечения, использующего данный объект. Таким образом, при использовании этих языков программирования сохраняется зависимость модулей программного обеспечения от адресов экспортируемых полей и методов, а также структур и форматов данных. Эта зависимость объективна, так как модули должны взаимодействовать между собой, обращаясь к ресурсам друг друга. Связи модулей нельзя разорвать, но можно попробовать стандартизировать их взаимодействие, на чем и основан компонентный подход к программированию. Четвертый этап — компонентный подход и CASE-технологии (с середины 90-х годов XX в. до нашего времени). Компонентный подход предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. На сегодня рынок объектов стал реальностью, так, в Интернете существуют узлы, предоставляющие большое количество компонентов, рекламой компонентов забиты журналы. Это позволяет программистам создавать продукты, хотя бы частично состоящие из повторно использованных частей, т. е. использовать технологию, хорошо зарекомендовавшую себя в области проектирования аппаратуры. Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model — компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture — общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями их реализации. Технология СОМ фирмы Microsoft является развитием технологии OLE I (Object Linking and Embedding — связывание и внедрение объектов), которая использовалась в ранних версиях Windows для создания составных документов. Технология СОМ определяет общую парадигму взаимодействия программ любых типов: библиотек, приложений, операционной системы, т. е. позволяет одной части программного обеспечения использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах. Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM — распределенная СОМ). 3 Основные понятия и определения Технология программирования — совокупность методов и средств, применяемых в процессе разработки программного обеспечения. Программа (program, routine) — упорядоченная последовательность команд (инструкций) компьютера для решения задачи. Программное обеспечение (software) — совокупность программ обработки данных и необходимых для их эксплуатации документов. Задача (problem, task) — проблема, подлежащая решению. Приложение (application) — программная реализация на компьютере решения 1 задачи. Термин «задача» в программировании означает единицу работы вычислительной системы, требующую выделения вычислительных ресурсов (процессорного времени, памяти). Процесс создания программ можно представить как последовательность следующих действий: 1. постановка задачи; 2. алгоритмизация решения задачи; 3. программирование. Постановка задачи (problem definition) — это точная формулировка решения задачи на компьютере с описанием входной и выходной информации. Алгоритм — система точно сформулированных правил, определяющая процесс преобразования допустимых исходных данных (выходной информации) в желаемый результат (выходную информацию) за конечное число шагов. Программирование (programming) — теоретическая и практическая деятельность, связанная с созданием программ. По отношению к программному обеспечению компьютерные пользователи делятся на следующие группы: 1. системные программисты. Занимаются разработкой, эксплуатацией и сопровождением системного программного обеспечения; 2. прикладные программисты. Осуществляют разработку и отладку программ для решения различных прикладных задач; 3. конечные пользователи. Имеют элементарные навыки работы с компьютером и используемыми ими прикладными программами; 4. администраторы сети. Отвечают за работу вычислительных сетей; 5. администраторы баз данных. Обеспечивают организационную поддержку базы данных. Сопровождение программы — поддержка работоспособности программы, переход на ее новые версии, внесения изменений, исправление ошибок и т. д. Основные характеристики программ: 1. алгоритмическая сложность; 2. состав функций обработки информации; 3. объем файлов, используемых программой; 4. требования к операционной системе (ОС) и техническим средствам обработки, в том числе объем дисковой памяти, размер оперативной памяти для запуска программы, тип процессора, версия ОС, наличие вычислительной сети и т. д. Показатели качества программы: 1. мобильность (многоплатформенность) — независимость от технического комплекса системы обработки данных, ОС, сетевых возможностей, специфики предметной области задачи и т. д.; 2. надежность — устойчивость, точность выполнения предписанных функций обработки, возможность диагностики возникающих ошибок в работе программы; 3. эффективность как с точки зрения требований пользователя, так и расхода вычислительных ресурсов; 4. учет человеческого фактора — дружественный интерфейс, контекстно-зависимая подсказка, хорошая документация; 5. модифицируемость — способность к внесению изменений, например, расширение функций обработки, переход на другую техническую базу обработки и т. п. 6. коммуникативность — максимально возможная интеграция с другими программами, обеспечение обмена данными между программами. Все программы по характеру использования и категориям пользователей можно разделить на два класса — утилитарные программы и программные продукты. Утилитарные программы («программы для себя») предназначены для удовлетворения нужд их разработчиков. Чаще всего такие программы выполняют роль отладочных приложений, являются программами решения задач, не предназначенных для широкого распространения. Программные продукты (изделия) используются для удовлетворения потребностей пользователей, широкого распространения и продажи. В настоящее время существуют и другие варианты легального распространения программных продуктов, которые появились с использованием глобальных телекоммуникаций: • freeware — бесплатные программы, свободно распространяемые, поддерживаются самим пользователем, который правомочен вносить в них необходимые изменения; • shareware некоммерческие (условно-бесплатные) программы, которые могут использоваться, как правило, бесплатно. Ряд производителей использует OEM-программы (Original Equipment Manufacturer), т. е. встроенные программы, устанавливаемые на компьютеры или поставляемые вместе с компьютерами. Программный продукт должен быть соответствующим образом подготовлен к эксплуатации (отлажен), иметь необходимую техническую документацию, предоставлять сервис и гарантию надежной работы программы, иметь товарный знак изготовителя, а также наличие кода государственной регистрации. Лекция 2. Методы и инструменты Современные CASE-технологии. Технология освоения и внедрения CASE-средств. Оценка CASE-средств. Характеристика современных CASE- средств. Современные CASE-технологии Многие организации-разработчики программного обеспечения информационных систем (ПО ИС), пытаясь внести усовершенствования в процесс разработки, обращаются к CASE-технологии. Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:  CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;  • реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;  • CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения. Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-либо безоговорочные утверждения относительно реального удовлетворения тех или иных ожиданий от их внедрения. Доступная информация о реальных внедрениях крайне ограничена и противоречива. Она зависит от типа средств, характеристик проектов, уровня сопровождения и опыта пользователей. Некоторые аналитики полагают, что реальная выгода от использования некоторых типов CASE-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические улучшения могут привести к снижению эксплуатационных затрат.  Ключом к успешному внедрению CASE-средств является готовность организации, которая включает следующие аспекты:  • Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;  • Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;  • Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.  В случае отсутствия готовности по данным аспектам внедрение CASE-средств скорее всего закончится неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.  Пользователи CASE-средств должны быть готовы к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых версий и возможному быстрому моральному старению средств, а также постоянным затратам на обучение нового персонала и повышение квалификации действующего персонала. Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:  • высокий уровень технологической поддержки процессов разработки и сопровождения ПО;  • положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;  • приемлемый уровень отдачи от инвестиций в CASE-средства. повышение внимания к планированию деятельности, связанной с информационной технологией;  • улучшение коммуникации между пользователями и разработчиками.  Технология освоения и внедрения CASE-средств  Современная технология освоения и внедрения CASE-средств базируется в основном на стандартах-рекомендациях IEEE (IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools и IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools). Процесс внедрения CASE-средств состоит из следующих этапов:  • определение потребностей в CASE-средствах;  • оценка и выбор CASE-средств;  • выполнение пилотного проекта;  • практическое внедрение CASE-средств. С внедрением CASE-средств обычно связывают большие ожидания. В ряде случаев эти ожидания оказываются нереалистичными и приводят к неудаче при внедрении. К таким ожиданиям можно отнести следующие:  • понимание проектных спецификаций неподготовленными пользователями;  • сокращение персонала, связанного с информационной технологией;  • уменьшение степени участия в проектах высшего руководства и менеджеров, а также экспертов предметной области, уменьшение степени участия пользователей в процессе разработки приложений;  • немедленное повышение продуктивности деятельности организации;  • достижение абсолютной полноты и непротиворечивости спецификаций;  • автоматическая генерация прикладных систем из проектных спецификаций;  • немедленное снижение затрат, связанных с информационной технологией;  • снижение затрат на обучение. Реализм в оценке ожидаемых затрат имеет особенно важное значение, поскольку он позволяет правильно оценить отдачу от инвестиций. Затраты на внедрение CASE-средств обычно недооцениваются. Среди конкретных статей затрат на внедрение можно выделить следующие:  • специалисты по планированию внедрения CASE-средств;  • выбор и установка;  • учет специфических требований персонала;  • приобретение CASE-средств и обучение;  • настройка;  • подготовка документации, стандартов и процедур использования средств;  • интеграция с другими средствами и существующими данными;  • освоение средств разработчиками;  • технические средства;  • обновление версий. Важно также осознавать, что улучшение деятельности организации, являющееся следствием использования CASE-технологии, может быть неочевидным в течение самого первого проекта, использующего новую технологию. Продуктивность и другие характеристики деятельности организации могут первоначально даже ухудшиться, поскольку на освоение новых средств и внесение необходимых изменений в процесс разработки требуется некоторое время. Таким образом, ожидаемые результаты должны рассматриваться с учетом вероятной отсрочки в улучшении проектных характеристик.  Потребности организации в CASE-средствах должны соразмеряться с реальной ситуацией на рынке или собственными возможностями разработки. В процессе обзора рынка важным является приобретение опыта работы с литературой по CASE-средствам, посещение конференций и семинаров, проводимых поставщиками (их перечень приведен в конце пособия) и пользователями CASE-средств. Возможность интеграции CASE-средства с другими средствами, используемыми (или планируемыми к использованию) организацией, может являться важным фактором при выполнении данного обзора. Кроме того, важно получить достоверную информацию о средствах, основанную на реальном пользовательском опыте и сведениях от пользовательских групп.  Оценка CASE-средств производится для определения их функциональности и качества и последующего выбора. Оценка выполняется в соответствии с конкретными критериями, ее результаты включают как объективные, так и субъективные данные по каждому средству.  Список CASE-средств - возможных кандидатов формируется из различных источников: обзоров рынка ПО, информации поставщиков, обзоров CASE-средств и других подобных публикаций.  Оценка и накопление соответствующих данных может выполняться следующими способами:  • анализ CASE-средств и документации поставщика;  • опрос реальных пользователей;  • анализ результатов проектов, использовавших данные CASE-средства;  • просмотр демонстраций и опрос демонстраторов;  • выполнение тестовых примеров;  • применение CASE-средств в пилотных проектах;  • анализ любых доступных результатов предыдущих оценок.  Процессы оценки и выбора тесно взаимосвязаны друг с другом. По результатам оценки цели выбора и/или критерии выбора и их веса могут потребовать модификации. В таких случаях может потребоваться повторная оценка. Когда анализируются окончательные результаты оценки и к ним применяются критерии выбора, может быть рекомендовано приобретение CASE-средства или набора CASE-средств. Альтернативой может быть отсутствие адекватных CASE-средств, в этом случае рекомендуется разработать новое CASE-средство, модифицировать существующее или отказаться от внедрения.  Типичный процесс оценки и/или выбора может использовать набор критериев различных типов. Структура набора критериев приведена на рисунке. Каждый критерий должен быть выбран и адаптирован экспертом с учетом особенностей конкретного процесса. В большинстве случаев только некоторые из множества критериев оказываются приемлемыми для использования, при этом также добавляются дополнительные критерии. Так, например, в качестве основных критериев выбора CASE-средств для крупных проектов ИС могут быть приняты следующие критерии:  1. Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития.  2. Обеспечение целостности проекта и контроля за его состоянием.  3. Независимость от программно-аппаратной платформы и СУБД.  4. Открытая архитектура  5. Качество технической поддержки в России, стоимость приобретения и поддержки, опыт успешного использования  6. Простота освоения и использования В результате выполненного анализа может оказаться, что ни одно доступное средство не удовлетворяет в нужной мере всем основным критериям и не покрывает все потребности проекта. В этом случае может применяться набор средств, позволяющий построить на их базе единую технологическую среду.  Перед полномасштабным внедрением выбранного CASE-средства в организации выполняется пилотный проект, целью которого является экспериментальная проверка правильности решений, принятых на предыдущих этапах, и подготовка к внедрению.  Пилотный проект представляет собой первоначальное реальное использование CASE-средства в предназначенной для этого среде и обычно подразумевает более широкий масштаб использования CASE-средства по отношению к тому, который был достигнут во время оценки. Пилотный проект должен обладать многими из характеристик реальных проектов, для которых предназначено данное средство. Он преследует следующие цели:  • подтвердить достоверность результатов оценки и выбора;  • определить, действительно ли CASE-средство годится для использования в данной организации, и если да, то определить наиболее подходящую область его применения;  • собрать информацию, необходимую для разработки плана практического внедрения;  • приобрести собственный опыт использования CASE-средства.  Важной функцией пилотного проекта является принятие решения относительно приобретения или отказа от использования CASE-средства. Провал пилотного проекта позволяет избежать более значительных и дорогостоящих неудач в дальнейшем, поскольку пилотный проект обычно связан с приобретением относительно небольшого количества лицензий и обучением узкого круга специалистов.  После того, как CASE-средство выбрано, оно должно быть приобретено, интегрировано в проектную среду и настроено в соответствии с требованиями пилотного проекта. Границы этой деятельности зависят от тех действий, которые имели место в процессе оценки и выбора, а также от степени модификации средства, необходимой для его использования в проекте.  Может оказаться, что в рамках пилотного проекта средства не оправдали тех ожиданий, которые на них возлагались, или же в пилотном проекте они использовались удовлетворительно, однако опыт показал, что дальнейшие вложения в средства не гарантируют успеха. Возможным решением о внедрении должно быть одно из следующих:  • Внедрить средство. В этом случае рекомендуемый масштаб внедрения должен быть определен в терминах структурных подразделений и предметной области.  • Выполнить дополнительный пилотный проект. Такой вариант должен рассматриваться только в том случае, если остались конкретные неразрешенные вопросы относительно внедрения CASE-средства в организации. Новый пилотный проект должен быть таким, чтобы ответить на эти вопросы.  • Отказаться от средства. В этом случае причины отказа от конкретного средства должны быть определены в терминах потребностей организации или критериев, которые остались неудовлетворенными. Перед тем, как продолжить деятельность по внедрению CASE-средств, потребности организации должны быть пересмотрены на предмет своей обоснованности.  • Отказаться от использования CASE-средств вообще. Пилотный проект может показать, что организация либо не готова к внедрению CASE-средств, либо автоматизация данного аспекта процесса создания и сопровождения ПО не дает никакого эффекта для организации. В этом случае причины отказа от CASE-средств должны быть также определены в терминах потребностей организации или критериев, которые остались неудовлетворенными. При этом необходимо понимать отличие этого варианта от предыдущего, связанного с недостатками конкретного средства.  В конечном счете, опыт, полученный при внедрении CASE-средств, может отчасти изменить цели организации и ожидания, возлагаемые на CASE-средства. Например, организация может сделать вывод, что средства целесообразно использовать для большего или меньшего круга пользователей и процессов в цикле создания и сопровождения ПО. Такие изменения в ожиданиях зачастую могут дать положительные результаты, но могут также привести к внесению соответствующих корректив в определение степени успешного внедрения CASE-средств в данной организации.  Характеристика современных CASE-средств  Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.  В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.  Полный комплекс CASE-средств, обеспечивающий поддержку жизненного цикла ПО, содержит следующие компоненты;  • репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;  • графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (потоков данных, "сущность-связь" и др.), образующих модели ИС;  • средства разработки приложений, включая языки 4GL и генераторы кодов;  • средства конфигурационного управления;  • средства документирования;  • средства тестирования;  • средства управления проектом;  • средства реинжиниринга.  Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:  • применяемым методологиям и моделям систем и БД;  • степени интегрированности с СУБД;  • доступным платформам.  Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, CASE.Аналитик). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;  • средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;  • средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team). Вспомогательные типы включают: средства планирования и управления проектом (SE Companion, Microsoft Project и др.);  • средства конфигурационного управления (PVCS, SCCS и др.);  • средства тестирования (Quality Works и др.).  На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:  • Vantage Team Builder (Westmount I-CASE);  • Designer/2000;  • Silverrun;  • ERwin+BPwin;  • S-Designor;  • CASE.Аналитик;  • Rational Rose. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы, так и новые версии и модификации перечисленных систем.  CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").  Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из которых является самостоятельным продуктом.  Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. Модуль концептуального моделирования данных (ERX- Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.  Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели ЖЦ ПО.  Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL.  Система Silverrun реализована на трех платформах - MS Windows, Macintosh и OS/2 Presentation Manager - с возможностью обмена проектными данными между ними.  Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО. Vantage Team Builder обеспечивает выполнение следующих функций:  • проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;  • проектирование диаграмм архитектуры системы - SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);  • генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;  • программирование на языке C со встроенным SQL;  • управление версиями и конфигурацией проекта;  • многопользовательский доступ к репозиторию проекта;  • генерация проектной документации по стандартным и индивидуальным шаблонам;  • экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).  Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования, предоставляемых Uniface. Для описания проекта ИС используется достаточно большой набор диаграмм. При построении всех типов диаграмм обеспечивается контроль соответствия моделей синтаксису используемых методов, а также соответствия одноименных элементов и их типов на различных типах диаграмм.  Конфигурация Vantage Team Builder for Uniface обеспечивает совместное использование двух систем в рамках единой технологической среды проектирования, при этом схемы БД (SQL-модели) переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface, могут быть перенесены в репозиторий Vantage Team Builder. Возможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты. Разработка экранных форм в среде Uniface выполняется на базе диаграмм последовательностей форм (FSD) после импорта SQL-модели.  Структура репозитория (хранящегося непосредственно в целевой СУБД) и интерфейсы Vantage Team Builder является открытыми, что в принципе позволяет интегрировать его с любыми другими средствами.  Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.  CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.  Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла ИС.  Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:  • Repository Administrator - средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);  • Repository Object Navigator - средство доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;  • Process Modeller - средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR - Business Process Reengineering) и глобальной системы управления качеством (TQM - Total Quality Management);  • Systems Modeller - набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм "сущность-связь" (Entity Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);  • Systems Designer - набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);  • Server Generator - генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;  • Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;  • Repository Reports - генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.  Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.  Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.  Среда функционирования Designer/2000 - Windows 3.x, Windows 95, Windows NT.  ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.  Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.  Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе.  BPwin - средство функционального моделирования, реализующее методологию IDEF0.  S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству Erwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.  S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется прямая генерация шаблонов приложений.  CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией, описанной в подразделе 2.3. Его основные функции:  • построение и редактирование DFD;  • анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;  • получение разнообразных отчетов по проекту;  • генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.  Среда функционирования: процессор - 386 и выше, основная память - 4 Мб, дисковая память - 5 Мб, MS Windows 3.x или Windows 95.  С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством Erwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.  Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах. В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов. В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ. Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA. Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX). Сравнительная характеристика CASE-средств В заключение приведем сравнительную характеристику CASE-средств по некоторым основным критериям, приведенным выше. Здесь хотелось бы еще раз отметить нецелесообразность сравнения отдельно взятых CASE-средств, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков. По мнению автора, на сегодняшний день наиболее развитым из всех поставляемых в России комплексов такого рода является комплекс технологий и инструментальных средств создания ИС, поддерживаемый фирмой "Аргуссофт Компани". В его основе лежит методология и технология DATARUN фирмы CSA. В состав комплекса входят следующие инструментальные средства:  • CASE-средство Silverrun;  • средство разработки приложений JAM;  • мост Silverrun-RDM <-> JAM;  • комплекс средств тестирования QA;  • менеджер транзакций Tuxedo;  • комплекс средств планирования и управления проектом SE Companion;  • комплекс средств конфигурационного управления PVCS;  • объектно-ориентированное CASE-средство Rational Rose;  • средство документирования SoDA.  Примерами других подобных комплексов являются:  • Vantage Team Builder for Uniface + Uniface (фирмы "DataX/Florin" и "ЛАНИТ");  • комплекс средств, поставляемых и используемых фирмой "ФОРС": • - CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернативные); • - средства разработки приложений Developer/2000, ORACLE Power Objects (основные) и Usoft Developer (альтернативное); • - средство настройки и оптимизации ExplainSQL (Platinum); • - cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy, TSReorg и др. (Platinum); • - средство документирования ORACLE Book. • комплекс средств на основе продуктов фирмы CENTURA: • - CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ);  • - средства разработки приложений SQLWindows и TeamWindows;  • - средство тестирования и оптимизации приложений "клиент-сервер" SQLBench (ARC);  • - cредства эксплуатации и сопровождения Quest и Crystal Reports.  Все перечисленные комплексы так или иначе решают проблему поддержки полного ЖЦ ПО. Что же касается остальных важных критериев, то здесь можно отметить следующее:  Обеспечение целостности проекта и контроля за его состоянием  Наилучшими показателями по данному критерию обладают комплексы Vantage Team Builder for Uniface + Uniface и комплекс "ФОРС". Это достигается за счет развитых средств контроля проектных спецификаций и высокой степени интегрированности отдельных средств, входящих в комплексы. В остальных вариантах недостаток возможностей самих средств может компенсироваться организационными мерами.  Независимость от платформы и СУБД  Наибольшей степенью независимости обладает комплекс "Аргуссофт Компани", поскольку его средства в принципе не ориентированы ни на какую конкретную платформу. Достаточно высокой степенью независимости обладает также комплекс Vantage Team Builder for Uniface + Uniface, остальные комплексы достаточно жестко ориентированы на конкретные СУБД (ORACLE и SQLBase).  Открытая архитектура  Наибольшей степенью открытости и количеством интерфейсов с продуктами других фирм также обладают комплексы "Аргуссофт Компани" и Vantage Team Builder for Uniface + Uniface.  Качество технической поддержки  Данный критерий является скорее оценкой работы конкретной фирмы-поставщика, чем комплекса инструментальных средств. На сегодняшний день наилучший уровень технической и методической поддержки поставляемых средств и обучения их использованию имеет фирма "Аргуссофт Компани".  Простота освоения и использования  Наилучшие показатели по данному критерию у комплекса "Аргуссофт Компани" и комплекса средств на основе продуктов фирмы CENTURA. Остальные комплексы достаточно сложны в освоении и трудоемки в использовании.  Приведенная выше сравнительная характеристика комплексов средств позволяет сделать следующие выводы относительно наиболее целесообразных областей их применения:  • крупные многоплатформенные проекты, ориентированные на спиральную модель ЖЦ: комплекс средств, поставляемых фирмой "Аргуссофт Компани";  • крупные многоплатформенные проекты, ориентированные на каскадную модель ЖЦ: комплекс Vantage Team Builder for Uniface + Uniface;  • крупные проекты, ориентированные на использование СУБД ORACLE: комплекс "ФОРС" - средства фирмы ORACLE;  • средние и небольшие проекты: комплекс "Аргуссофт Компани" и комплексы, включающие локальные CASE-средства (ERwin, BPwin, S-Designor, CASE.Аналитик) в сочетании со средствами быстрой разработки приложений (PowerBuilder, Delphi, SQLWindows и др.);  • проекты, использующие объектно-ориентированный подход: комплекс "Аргуссофт Компани" (при этом в качестве CASE-средства следует использовать Rational Rose, а в качестве средств разработки приложений одно из тех средств, с которыми взаимодействует Rational Rose. Лекция 3. Методы проектирования и жизненный цикл программ Документы международного и государственного стандарта, определяющие состав разработки RUP. Жизненный цикл ПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Среди наиболее известных стандартов можно выделить следующие:  ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.  ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.  Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.  Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.  Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.  Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов. Основные процессы жизненного цикла ISO/IEC 12207 . В таблице 1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами. Для поддержки практического применения стандарта ISO/IEC 12207 разработан ряд технологических документов: Руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207) и Руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management). Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем. Виды нормативных документов Согласно определению стандарта ИСО-МЭК-2 стандартизация — это дея­тельность, направленная на достижение оптимальной степени упорядочения в определенной области посредством установления положений для всеобще­го и многократного исследования в отношении реально существующих или потенциальных задач. В соответствии с определением этого понятия формируются основные понятия стандартизации: • нормативный документ — документ, устанавливающий правила, общие принципы или характеристики, касающиеся различных видов деятель­ности или их результатов; • на основе согласия по существенным вопросам заинтересованных сторон и Международная организация по стандартизации (ИСО) Международная организация по стандартизации создана в 1946 г. двадцатью пятью национальными организациями по стан­дартизации. При создании организации и выборе ее названия учитыва­лась необходимость того, чтобы аббревиатура наименования звучала одинаково на всех языках. Для этого было решено ис­пользовать греческое слово «isos» — равный. Вот почему на всех языках мира Международная организация по стандартизации имеет краткое название ISO (ИСО). Сфера деятельности ИСО касается стандартизации во всех областях, кроме электротехники и электроники, относящихся к компетенции Международной электротехнической комиссии (МЭК). Некоторые виды работ выполняются совместными уси­лиями этих организаций. Кроме стандартизации ИСО занимает­ся и проблемами сертификации. ИСО определяет свои задачи следующим образом: содействие развитию стандартизации и смежных видов деятельности в мире с целью обеспечения международного обмена товарами и услуга­ми, а также развития сотрудничества в интеллектуальной, науч­но-технической и экономической областях. Особенности процесса стандартизации в Интернете В Глобальной сети уже давно существует целый ряд комитетов, которые занимаются стандартизацией всех интернет-технологий. Эти организации, составляющие основную часть Рабочей группы инженеров Интернета (Internet Engineering Task Force, IETF), уже стандартизировали нескольких важных протоколов, тем самым ускорив их внедрение в сети. Семейство протоколов для передачи данных TCP/IP, SMTP и POP для электронной почты, а так же SNMP (Simple Network Management Protocol) для управления сетью - результаты деятельности IETF. За несколько последних лет сетевой рынок стал свидетелем так называемого фрагментированного влияния на формирование стандартов. По мере того, как Интернет ширился и обретал черты потребительского и коммерческого рынка, некоторые фирмы стали искать пути влияния на стандартизацию, создав подобие конкурентной борьбы. Давление почувствовали даже неформальные органы, такие как IETF. По мере развития рынков, связанных с Интернетом, предприниматели начали объединяться в специальные группы или консорциумы для продвижения своих собственных стандартов. В качестве примеров можно упомянуть OMG (Object Management Group), VRML (Virtual Reality Markup Language) Forum и Java Development Connection. Порой стандарты де-факто задают своими покупками или заказами серьезные потребители интернет-услуг. Одна из причин появления различных групп по стандартизации состоит в противоречии между постоянно возрастающими темпами развития технологий и длительным циклом создания стандартов. Стандарты безопасности в Интернете В качестве средств обеспечения безопасности в сети Интернет популярны протоколы защищенной передачи данных, а именно SSL (TLS), SET, IP v. 6. Они появились сравнительно недавно, и сразу стали стандартами де-факто. SSL (TLS) Наиболее популярный сейчас сетевой протокол шифрования данных для безопасной передачи по сети представляет собой набор криптографических алгоритмов, методов и правил их применения. Позволяет устанавливать защищенное соединение, производить контроль целостности данных и решать различные сопутствующие задачи. SET SET (Security Electronics Transaction) - перспективный протокол, обеспечивающий безопасные электронные транзакции в Интернете. Он основан на использовании цифровых сертификатов по стандарту Х.509 и предназначен для организации электронной торговли через сеть. Данный протокол является стандартом, разработанным компаниями "MasterCard" и "Visa" при участии "IBM", "GlobeSet" и других партнеров. С его помощью покупатели могут приобретать товары через Интернет, используя самый защищенный на сегодняшний день механизм выполнения платежей. SET - это открытый стандартный многосторонний протокол для проведения платежей в Интернете с использованием пластиковых карточек. Он обеспечивает кросс-аутентификацию счета держателя карты, продавца и банка продавца для проверки готовности оплаты, а также целостность и секретность сообщения, шифрование ценных и уязвимых данных. SET можно считать стандартной технологией или системой протоколов выполнения безопасных платежей на основе пластиковых карт через Интернет. IPSec Спецификация IPSec входит в стандарт IP v. 6 и является дополнительной по отношению к текущей версии протоколов TCP/IP. Она разрабатывается Рабочей группой IP Security IETF. В настоящее время IPSec включает три алгоритмо-независимых базовых спецификации, представляющих соответствующие RFC-стандарты. Протокол IPSec обеспечивает стандартный способ шифрования трафика на сетевом (третьем) уровне IP и защищает информацию на основе сквозного шифрования: независимо от работающего приложения, шифруется каждый пакет данных, проходящий по каналу. Это позволяет организациям создавать в Интернете виртуальные частные сети. IPSec работает поверх обычных протоколов связи, поддерживая DES, MD5 и ряд других криптографических алгоритмов. Обеспечение информационной безопасности на сетевом уровне с помощью IPSec включает: • поддержку немодифицированных конечных систем; • поддержку транспортных протоколов, отличных от ТСР; • поддержку виртуальных сетей в незащищенных сетях; • защиту заголовка транспортного уровня от перехвата (предохранение от несанкционированного анализа трафика); • защиту от атак типа "отказ в обслуживании". Кроме того, IPSec имеет два важных преимущества: 1. его применение не требует изменений в промежуточных устройствах сети; 2. рабочие места и серверы не обязательно должны поддерживать IPSec. Лекция 4. Унифицированный язык моделирования (UML) Введение в язык UML. Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или full life-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой — проблемой организации взаимодействия между различными командами, реализующими проект. Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков. Мощный толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980-х — начале 1990-х годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE — Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, OMT-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки. Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software Corporation Айвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML. В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology. UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками: • является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС; • содержит механизмы расширения и специализации базовых концепций языка. UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами. UML включает внутренний набор средств моделирования (модулей?) («ядро»), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой части каждого приложения. Пользователям языка предоставлены возможности: • строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений; • добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей. Синтаксис и семантика основных объектов UML Классы Классы — это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой. В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Если используется составное имя (в начале имени добавляется имя пакета, куда входит класс), то имя класса должно быть уникальным в пакете. Атрибут — это свойство класса, которое может принимать множество значений. Множество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов. Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта. На рис. 1 приведено графическое изображение класса «Заказ» в нотации UML. Рисунок 1 - Изображение класса в UML Синтаксис UML для свойств классов (в отдельных программных средствах, например, в IBM UML Modeler, порядок записи параметров может быть иным): < признак видимости> <имя атрибута> : <тип данных> = <значение по умолчанию> <признак видимости> <имя операции> <(список аргументов)> Видимость свойства указывает на возможность его использования другими классами. Один класс может «видеть» другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости: • public (общий) — любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции; • protected (защищенный) — только любой потомок данного класса может пользоваться его защищнными свойствами. Обозначаются знаком «#»; • private (закрытый) — только данный класс может пользоваться этими свойствами. Обозначаются символом «-» . Еще одной важной характеристикой атрибутов и операций классов является область действия. Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами: • instance (экземпляр) — у каждого экземпляра класса есть собственное значение данного свойства; • classifier (классификатор) — все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием). Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов: • не содержащие ни одного экземпляра — тогда класс становится служебным (Abstract); • содержащие ровно один экземпляр (Singleton); • содержащие заданное число экземпляров; • содержащие произвольное число экземпляров. Принципиальное назначение классов характеризуют стереотипы. Это, фактически, классификация объектов на высоком уровне, позволяющая определить некоторые основные свойства объекта (пример стереотипа — класс «действующее лицо»). Механизм стереотипов является также средством расширения словаря UML за счет создания на основе существующих блоков языка новых, специфичных для решения конкретной проблемы. Диаграммы классов Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними. Классы отображают типы объектов системы. Между классами возможны различные отношения, представленные на рис. 11.2: • зависимости, которые описывают существующие между классами отношения использования; • обобщения, связывающие обобщенные классы со специализированными; • ассоциации, отражающие структурные отношения между объектами классов. Рисунок 2 - Отображение связей между классами Зависимостью называется отношение использования, согласно которому изменение в спецификации одного элемента (например, класса «товар») может повлиять на использующий его элемент (класс «строка заказа»). Часто зависимости показывают, что один класс использует другой в качестве аргумента. Обобщение — это отношение между общей сущностью (родителем — класс «клиент») и ее конкретным воплощением (потомком — классы «корпоративный клиент» или «частный клиент»). Объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот. При этом он наследует свойства родителя (его атрибуты и операции). Операция потомка с той же сигнатурой, что и у(?) родителя, замещает(?) операцию родителя; это свойство называют полиморфизмом. Класс, у которого нет родителей, но есть потомки, называется корневым. Класс, у которого нет потомков, называется листовым. Ассоциация — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме (рисунок 3). Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи. Рисунок 3 - Свойства ассоциации Рисунок 3 иллюстрирует модель формирования заказа. Каждый заказ может быть создан единственным клиентом (множественность роли 1). Каждый клиент может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть «привязан» к определенному клиенту. Такого рода ассоциация является простой и отражает отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Если приходится моделировать отношение типа «часть-целое», то используется специальный тип ассоциации — агрегирование. В такой ассоциации один из классов имеет более высокий ранг (целое — класс «заказ», рисунок 2) и состоит из нескольких меньших по рангу классов (частей — класс «строка заказа»). В UML используется и более сильная разновидность агрегации — композиция, в которой объект-часть может принадлежать только единственному целому. В композиции жизненный цикл частей и целого совпадают, любое удаление целого обязательно захватывает и его части. Для ассоциаций можно задавать атрибуты и операции, создавая по обычным правилам UML классы ассоциаций. Диаграммы использования Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом: • описывает видимую пользователем функцию, • может представлять различные уровни детализации, • обеспечивает достижение конкретной цели, важной для пользователя. Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актерами, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы. На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рисунок 4). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания. На рисунке 4 показано, что при исполнении прецедента «формирование заказа» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие — рассчитать стоимость заказа. Рисунок 4 - Связи на диаграммах прецедентов Динамические аспекты поведения системы отражаются приведенными ниже диаграммами. В отличие от некоторых подходов объектного моделирования, когда и состояние, и поведение системы отображаются на диаграммах классов, UML отделяет описание поведения в диаграммы взаимодействия. В UML диаграммы классов не содержат сообщений, которые усложняют их чтение. Поток сообщений между объектами выносится на диаграммы взаимодействия. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках одного варианта использования. Прямоугольники на диаграмме представляют различные объекты и роли, которые они имеют в системе, а линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения. Существуют два вида диаграмм взаимодействия: диаграммы последовательностей и кооперативные диаграммы. Диаграммы последовательностей Этот вид диаграмм используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Прямоугольники на вертикальных линиях показывают «время жизни» объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта. Рисунок 5 - Диаграмма последовательности обработки заказа • вводятся строки заказа; • по каждой строке проверяется наличие товара; • если запас достаточен — инициируется поставка; • если запас недостаточен — инициируется дозаказ (повторный заказ). Рисунок 6 - Кооперативная диаграмма прохождения заказа Сообщения появляются в той последовательности, как они показаны на диаграмме — сверху вниз. Если предусматривается отправка сообщения объектом самому себе (самоделегирование), то стрелка начинается и заканчивается на одной «линии жизни». На диаграммы может быть добавлена управляющая информация: описание условий, при которых посылается сообщение; признак многократной отправки сообщения (маркер итерации); признак возврата сообщения. Кооперативные диаграммы На кооперативных диаграммах объекты (или классы) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках одного варианта использования. Временная последовательность сообщений отражается их нумерацией. Диаграммы состояний Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий.Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах. Прямоугольниками представляются состояния, через которые проходит объект во время своего поведения. Состояниям соответствуют определенные значения атрибутов объектов. Стрелки представляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта. Имеется также два вида псевдо-состояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел. Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (рисунок 7): Рисунок 7 - Диаграмма состояний объекта «заказ» < Событие> <[Условие]> < / Действие>. На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии. Синтаксис метки деятельности: выполнить/< деятельность >. Диаграммы деятельности Диаграмма деятельности — это частный случай диаграммы состояний. На диаграмме деятельности представлены переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов. Основными элементами диаграмм деятельности являются (рисунок 8): Рисунок 8 - Диаграмма деятельности — обработка заказа • овалы, изображающие действия объекта; • линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия «И»); • ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия «ИЛИ»); • стрелки — отражают последовательность действий, могут иметь метки условий. На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных точек, поскольку они отражают теперь реакцию системы на множество внешних событий. Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы. Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания). Диаграммы компонентов Диаграммы компонентов позволяют изобразить модель системы на физическом уровне. Элементами диаграммы являются компоненты — физические замещаемые модули системы. Каждый компонент является полностью независимым элементом системы. Разновидностью компонентов являются узлы. Узел — это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки. Узлы делятся на два типа: • устройства — узлы системы, в которых данные не обрабатываются. • процессоры — узлы системы, осуществляющие обработку данных. Для различных типов компонентов предусмотрены соответствующие стереотипы в языке UML. Компонентом может быть любой достаточно крупный модульный объект, такой как таблица или экстент базы данных, подсистема, бинарный исполняемый файл, готовая к использованию система или приложение. Таким образом, диаграмму компонентов можно рассматривать как диаграмму классов в более крупном (менее детальном) масштабе. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Основное назначение диаграмм компонентов — разделение системы на элементы, которые имеют стабильный интерфейс и образуют единое целое. Это позволяет создать ядро системы, которое не будет меняться в ответ на изменения, происходящие на уровне подсистем. На рисунке 9 показана упрощенная схема элементов фрагмента корпоративной системы. «Коробки» представляют собой компоненты — приложения или внутренние подсистемы. Пунктирные линии отражают зависимости между компонентами. Рисунок 9 - Диаграмма компонентов фрагмента КИС Каждый компонент диаграммы при необходимости документируется с помощью более детальной диаграммы компонентов, диаграммы сценариев или диаграммы классов. Пакеты UML Пакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить диаграммы различного типа и назначения. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки. Изображается пакет в виде папки с закладкой, содержащей, как правило, только имя и иногда — описание содержимого. Диаграмма пакетов содержит пакеты классов и зависимости между ними. Зависимость между двумя пакетами имеет место в том случае, если изменения в определении одного элемента влекут за собой изменения в другом. По отношению к пакетам можно использовать механизм обобщения.