Методология объектно-ориентированного программирования. Объектно-ориентированный анализ

ВОРОНЕЖСКИЙ ИНСТИТУТ ВЫСОКИХ ТЕХНОЛОГИЙ – АНОО ВПО КУРС ЛЕКЦИЙ По дисциплине «Методы и средства проектирования информационных систем и технологий» 1. МЕТОДОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ. Методология объектно-ориентированного программирования появилась, так как методы процедурного программирования не способны были справиться ни с растущей сложностью программ и их разработки, ни с необходимостью повышения их надежности. Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. В данном определении можно выделить три части: 1) OOP использует в качестве базовых элементов объекты, а не алгоритмы; 2) каждый объект является экземпляром какого-либо определенного класса; 3) классы организованы иерархически. Таки образом, фундаментальными понятиями ООП являются понятия класса и объекта. При этом под классом понимают некоторую абстракцию совокупности объектов, которые имеют общий набор свойств и обладают одинаковым поведением. Каждый объект в этом случае рассматривается как экземпляр соответствующего класса. Объекты, которые не имеют полностью одинаковых свойств или не обладают одинаковым поведением, по определению, не могут быть отнесены к одному классу. Основными принципами ООП являются наследование, инкапсуляция и полиморфизм. Принцип, в соответствии с которым знание о более общей категории разрешается применять для более узкой категории, называется наследованием. Наследование тесно связано с иерархией классов, которая определяет, какие классы следует считать наиболее абстрактными и общими по отношению к другим классам. При этом, если некоторый более общий или родительский класс (предок) обладает фиксированным набором свойств и поведением, то производный от него класс (потомок) должен содержать этот же набор свойств и поведение, а также дополнительные, которые будут характеризовать уникальность полученного таким образом класса. В этом случае говорят, что производный класс наследует свойства и поведение родительского класса.  Class Circle extend Point { // создаем новый объект "окружность", //наследующий свойства объекта "точка"  Radius : int; // добавляем новое поле "радиус", поля X и Y наследуются 1 // от родительского объекта   ............. Circle(X:int,Y:int,Radius:int); // конструктор нового объекта ............. Draw(); // переопределяем некоторые методы Hide(); // родительского объекта, метод Move наследуется ............. ChangeRadius(Radius); // вводим новый метод "изменить радиус" ............. GetRadius(); // вводим новый метод "получить значение радиуса" // методы GetX и GetY наследуются от родительского // объекта           } Следующий принцип ООП — инкапсуляция. Этот термин характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. Действительно, взаимодействующему с классом субъекту или клиенту нет необходимости знать, каким образом реализован тот или иной метод класса, услугами которого он решил воспользоваться. Конкретная реализация присущих классу свойств и методов, которые определяют поведение этого класса, является собственным делом данного класса. Более того, отдельные свойства и методы класса вообще могут быть невидимы за пределами этого класса, что является базовой идеей введения различных категорий видимости для компонентов класса. Третьим принципом ООП является полиморфизм. Под полиморфизмом (греч. Poly— много, morfos — форма) понимают свойство некоторых объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов относится тот или иной метод. Т.е различные объекты могут по разному реагировать на одинаковые внешние события в зависимости от того, как реализованы их методы. Пример:  Begin  Point A(100,100);  Circle B(200,200,50);  A.Draw();  B.Draw(); End.  // рисует точку // рисует окружность 2 2. МЕТОДОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ СЛОЖНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ. 2.1 ОСНОВНЫЕ ПРИНЦИПЫ Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности. Объектная модель имеет четыре главных элемента:  абстрагирование;  инкапсуляция;  модульность;  иерархия. Эти элементы являются главными в том смысле, что без любого из них модель не будет объектно-ориентированной. Кроме главных, имеются еще три дополнительных элемента:  типизация;  параллелизм;  сохраняемость. Называя их дополнительными, мы имеем в виду, что они полезны в объектной модели, но не обязательны. Абстрагирование. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. И предусматривает Выделение таких существенных характеристик объектов, которые отличают его ото всех других объектов и которые четко определяют особенности данного объекта с точки зрения дальнейшего рассмотрения и анализа. Минимальной единицей абстракции в ОО Моделировании является класс. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования. Инкапсуляция Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством. Чаще всего инкапсуляция выполняется посредством скрытия информации, то есть маскировкой всех внутренних деталей, не влияющих на внешнее поведение. Обычно скрываются и внутренняя структура объекта и реализация его методов. Модульность модульность - это разделение (декомпозиция ) системы на ряд связанных частей (модулей), которые компилируются по отдельности, но могут устанавливать связи с другими модулями. Это 3 свойство становится особенно полезным, когда система состоит из многих сотен классов. Иерархия Иерархия - это упорядочение абстракций, расположение их по уровням. Типизация Будем считать, что термины тип и класс взаимозаменяемы Параллелизм Свойство системы обрабатывать много событий одновременно. Параллелизм позволяет различным объектам действовать одновременно. Сохраняемость Сохраняемость способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства. (например в объектно-ориентированных базах данных) Объектно-ориентированный анализ и проектирование принципиально отличаются от традиционных подходов структурного проектирования: здесь нужно по-другому представлять себе процесс декомпозиции, а архитектура получающегося программного продукта в значительной степени выходит за рамки представлений, традиционных для структурного программирования. Отличия обусловлены тем, что структурное проектирование основано на структурном программировании, тогда как в основе объектноориентированного проектирования лежит методология объектноориентированного программирования 2.2 ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ. Традиционная техника структурного анализа основана на потоках данных в системе. Объектно-ориентированный анализ (или OOA, objectoriented analysis) направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения. Таким образом: Объектно-ориентированный анализ - это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области. Границы между стадиями анализа и проектирования размыты, но решаемые ими задачи определяются достаточно четко. В процессе анализа мы моделируем проблему, обнаруживая классы и объекты, которые составляют словарь проблемной области. При объектно-ориентированном проектировании мы изобретаем абстракции и механизмы, обеспечивающие поведение, требуемое моделью Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. В общем виде ЖЦ программы состоит из следующих этапов: 4  Анализа предметной области и формулировки требований к программе Проектирования структуры программы  Реализации программы в кодах (собственно программирования)  Внедрения программы  Сопровождения программы  Отказа от использования программы Процесс проектирования информационных систем охватывает первые 2 этапа. На этапе анализа предметной области и формулировки требований осуществляется определение функций, которые должна выполнять разрабатываемая программа, а также концептуализация предметной области. Эту работу выполняют аналитики совместно со специалистами предметной области. Результатом данного этапа должна являться некоторая концептуальная схема (техническое задание), содержащая описание основных компонентов и тех функций, которые они должны выполнять. Основная цель написания ТЗ — устранение двусмысленностей о том, что именно будет являться конечным продуктом. Юридически техническое задание оформляется как приложение к договору оказания услуг по разработке и подписывается обеими сторонами. Техническое задание — исходный документ для разработки программного продукта, содержащий основные технические требования, предъявляемые к продукту и исходные данные для разработки. В ТЗ указываются назначение продукта, область его применения, целевая аудитория, стадии разработки проектной и программной документации, её состав, сроки исполнения и т.д., а также особые требования, обусловленные спецификой программного продукта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования. Техническое задание ‐ это плод совместной работы, компромисс между желаниями заказчика и возможностями исполнителя. Структура технического задания Объем технического задания зависит от сложности разрабатываемого продукта и может колебаться от одной до сотни страниц. В Российской Федерации действует ГОСТ 34.602‐89 “Техническое задание на создание автоматизированной системы”, который рекомендует такую структуру ТЗ: � общие сведения; включает:  полное наименование системы и ее условное обозначение;  шифр темы или шифр (номер) договора;  наименование компаний разработчика и заказчика (пользователя) системы и их реквизиты;  перечень документов, на основании которых создается система, кем и когда утверждены эти документы;  5  плановые сроки начала и окончания работы по созданию системы;  сведения об источниках и порядке финансирования работ; порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программнотехнических (программно-методических) комплексов системы. � назначение и цели создания (развития) системы; � характеристика объектов автоматизации; � требования к системе; включает:  требования к системе в целом;  требования к функциям (задачам), выполняемым системой;  требования к видам обеспечения. � состав и содержание работ по созданию системы; включает:  перечень документов предъявляемых по окончании соответствующих стадий и этапов работ; � порядок контроля и приемки системы; � требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; � требования к документированию; � источники разработки. Включает: документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ Рассмотрим основные этапы подготовки технического задания: ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ • Краткое введение в предметную область • Выделить элементы предметной области, их взаимосвязи • Определить особенности и ограничения предметной области • Используемые термины и сокращения ЦЕЛЬ СОЗДАНИЯ СИСТЕМЫ • Сформулировать цель создания системы – как ответ на вопрос что за процесс в предметной области будет автоматизирован • Назначение системы, существующие аналоги • целевая аудитория, ожидаемый уровень использования ДЕТАЛИЗАЦИЯ ФУНКЦИЙ • Изучение потребностей заказчика • Подготовить описание функций системы АНАЛИЗ КАТЕГОРИЙ ПОЛЬЗОВАТЕЛЕЙ • Выделение категорий пользователей  6 • Определение функциональных требований пользователей каждой категории ОПРЕДЕЛЕНИЕ ОГРАНИЧЕНИЙ •Анализ аппаратных особенностей и ограничений •Анализ топологии и особенностей развертывания •Определение технологических ограничений ФОРМИРОВАНИЕ И УТВЕРЖДЕНИЕ СОВОКУПНОГО СПИСКА ТРЕБОВАНИЙ К СИСТЕМЕ •Если система предполагает интерактивность в общении с пользователем, то определить функциональные требования (описывают в динамике сценарии взаимодействия посетителя с системой) и структуру данных. •Выделить специфические требования (например, многоязычность, требования к дизайну экранов оператора) •Прочие требования (например, какая документация должна быть предоставлена разработчиком) •Сформировать список требований ВЫБОРКА АРХИТЕКТУРНОГО РЕШЕНИЯ •Выбор технологической платформы •Если система должна реализовывать специфическую бизнес‐логику, в которой обычно хорошо разбирается заказчик и плохо ‐ исполнитель, эта логика должна быть задокументирована в техническом задании максимально подробно. •Подготовка модульной структуры системы •Подготовка детализированного описания 2.3 ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ. Программирование прежде всего подразумевает правильное и эффективное использование механизмов конкретных языков программирования. Проектирование, напротив, основное внимание уделяет правильному и эффективному структурированию сложных систем. Таким образом: Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы. В данном определении содержатся две важные части: 1) объектноориентированное проектирование основывается на объектноориентированной декомпозиции; 2) объектно-ориентированное проектирование использует многообразие приемов представления моделей, отражающих логическую (классы и объекты) и физическую (модули и процессы) структуру системы, а также ее статические и динамические аспекты. 7 Именно объектно-ориентированная декомпозиция отличает объектноориентированное проектирование от структурного; в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами На этапе проектирования осуществляется преобразовании требований, изложенных в ТЗ, в детальные спецификации информационной системы. Этап ОО проектирования структуры программы заключается в разработке детальной схемы будущей программы, на которой указываются классы, их свойства и методы, а также различные взаимосвязи между ними. Как правило, на этом этапе могут участвовать в работе аналитики, архитекторы и отдельные квалифицированные программисты. Результатом данного этапа должна стать детализированная схема программы, на которой указываются все классы и взаимосвязи между ними в процессе функционирования программы. Согласно методологии ООАП, именно данная схема должна "служить исходной информацией для написания программного кода. В процессе выполнения работ устраняются неясности и неоднозначности, детально прорабатываются функциональные модели и задачи каждой подсистемы, определяются структуры информационных массивов и баз данных, разрабатываются интерфейсы и прототипы экранов, строится общая информационная модель информационной системы. Вносятся необходимые уточнения и дополнения в перечень требований к отдельным компонентам разрабатываемой системы, уточняются формы входных и выходных документов, детально описываются технологические процессы переработки информации. При необходимости, для каждого элементарного процесса разрабатываются прототипы экранных форм, интерфейсов, отчетов, и т.п. Конкретизируются требования к обеспечению целостности и непротиворечивости данных, полномочия различных групп пользователей по доступу к данным, и др. Собственно процесс проектирования может базироваться на различных подходах. В частности, последние годы получили распространение структурный и объектно-ориентированный подходы к проектированию ИС. Однако независимо от используемых подходов, моделей и методов проектирования основными результатами проектирования являются: - функциональные модели ИС в целом и подсистем; - общая информационная модель ИС; детально проработанные интерфейсы между автономно разрабатываемыми подсистемами; прототипы экранных и отчетных форм, диагностических сообщений, и т.п. Набор документов, представляемых по завершении этапа, включает: - описание проекта ИС; 8 - детальное описание бизнес-процессов ("как есть") с точки зрения функциональной структуры, информационной структуры, потоков данных; - детальное описание бизнес-процессов ("как должно быть") с точки зрения функциональной структуры, информационной структуры, потоков данных; описание архитектуры обеспечивающих подсистем (информационное, лингвистическое, организационное, техническое и др. виды обеспечения); - набор функциональных спецификаций (внешняя и внутренняя спецификации). Функциональные внешние спецификации описывают реализацию информационной системы с применением конкретных инструментов разработки. Функциональные внутренние спецификации включают требуемые программисту описания форматов данных, алгоритмов, интерфейсов ИС, и т.п. Решение о составе и наполнении проектных документов принимает руководитель проекта. При этом он должен руководствоваться существующими стандартами и другими нормативными документами. Этап программирования вряд ли нуждается в уточнении, поскольку является наиболее традиционным для программистов. Появление инструментариев быстрой разработки приложений (Rapid Application Development, RAD) позволило существенно сократить время, и затраты на выполнение этого этапа. Результатом данного этапа является программное приложение, которое обладает требуемой функциональностью и способно решать нужные задачи в конкретной предметной области. Этапы внедрения и сопровождения программы связаны с необходимостью настройки и конфигурирования среды программы, а также с устранением возникших в процессе ее использования ошибок. Иногда в качестве отдельного этапа выделяют тестирование программы, под которым понимают проверку работоспособности программы на некоторой совокупности исходных данных или при некоторых специальных режимах эксплуатации. Результатом этих этапов является повышение надежности Программного приложения, исключающего возникновение критических ситуаций или нанесение ущерба компании, использующей данное приложение. Рассматривая различные этапы ЖЦ программы, следует отметить одно важное обстоятельство. А именно, если появление RAD-инструментариев позволило существенно сократить сроки этапа программирования, то отсутствие соответствующих средств для первых двух этапов долгое время сдерживало процесс разработки приложений. Развитие методологии ООАП было направлено на автоматизацию второго, а затем и первого этапов ЖЦ программы. 9 Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE), которая направлена как раз на автоматизацию первых двух этапов ЖЦ. CASE-технология (Computer-Aided Software/System Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации. Под CASE средствами понимается программное средство (инструментарий для системных аналитиков, разработчиков и программистов), поддерживающие основные процессы жизненного цикла ПО, включая анализ требований к системе, проектирования прикладного ПО и БД, генерацию кода, тестирование, документирование, обеспечение качества, управление конфигурацией ПО и управление проектом и другие процессы. Характерные особенности: 1) Единый графический язык. 2) Единая БД (репозиторий) проекта - хранит всю информацию о проекте, может использоваться разными разработчиками с правами доступа. Может содержать: структурные диаграммы, определение экранов и меню, проекты отчетов, описание данных, логику обработки, исходные коды и т.д. 3) Интеграция средств. Сюда входит общий пользовательский интерфейс, передача данных и интеграция этапов разработки через единую систему. 4) Поддержка коллективной работы и управления проектом. CASE- технология поддерживает групповую работу над проектом, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, т. е. функции, необходимые в процессе разработки и сопровождения проектов 5) Макетирование – CASE-технология дает возможность быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на ранних этапах разработки оценить, насколько она приемлема для будущих пользователей и устраивает его. 6) Генерация документации – автоматически получается на базе репозитория. 7) Верификация проекта – автоматическая поддержка различных версий. CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом 8) Автоматическая генерация программного кода. 9) Сопровождение и реинженеринг. Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга и обратного инжиниринга 10 позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов и т. п. Появилось несколько подходов визуального представления концептуальных схем. На этом фоне особенно заметно появление унифицированного языка моделирования (Unified Modeling Language, UML), который ориентирован на решение задач первых двух этапов ЖЦ программ. 3. МЕТОДОЛОГИЯ СИСТЕМНОГО АНАЛИЗА И СИСТЕМНОГО МОДЕЛИРОВАНИЯ Системный анализ как научное направление имеет более давнюю историю, чем ООП и ООАП, и собственный предмет исследования. Центральным понятием системного анализа является понятие системы, под которой понимается совокупность объектов, компонентов или элементов произвольной природы, образующих некоторую целостность. Определяющей предпосылкой выделения некоторой совокупности как системы является возникновение у нее новых свойств, которых не имеют составляющие ее элементы. Примеров систем можно привести достаточно много — это персональный компьютер, автомобиль, человек, биосфера, программа и др. Более ортодоксальная точка зрения предполагает, что все окружающие нас предметы являются системами. Важнейшими характеристиками любой системы являются ее структура и процесс функционирования. Под структурой системы понимают устойчивую во времени совокупность взаимосвязей между ее элементами или компонентами. Именно структура связывает воедино все элементы и препятствует распаду системы на отдельные компоненты. Структура системы может отражать самые различные взаимосвязи, в том числе и вложенность элементов одной системы в другую. В этом случае принято называть более мелкую или вложенную систему подсистемой, а более крупную — метасистемой. Процесс функционирования системы тесно связан с изменением ее свойств или поведения во времени. При этом важной характеристикой системы является ее состояние, под которым понимается совокупность свойств или признаков, которые в каждый момент времени отражают наиболее существенные особенности поведения системы. Методология системного анализа служит концептуальной основой системно-ориентированной декомпозиции предметной области. В этом случае исходными компонентами концептуализации являются системы и взаимосвязи между ними. При этом понятие системы является более общим, чем понятия классов и объектов в ООАП. Результатом системного анализа является построение некоторой модели системы или предметной области. 11 Процесс разработки адекватных моделей и их последующего конструктивного применения требует не только знания общей методологии системного анализа, но и наличия соответствующих изобразительных средств или языков для фиксации результатов моделирования и их документирования. Для построения моделей были разработаны достаточно серьезные теоретические методы, основанные на развитии математических и логических средств моделирования, а также предложены различные формальные и графические нотации, отражающие специфику решаемых задач. Унификация любого языка моделирования тесно связана с методологией системного моделирования, т. е. с системой воззрений и принципов рассмотрения сложных явлений и объектов как моделей сложных систем. Среди методов системного моделирования широкое распространение получила методология структурного анализа и проектирования SADT (Structured Analysis and Design Technique, англ.) 4. СТРУКТУРНЫЙ ПОДХОД К ПРОЕКТИРОВАНИЮ ИС. Структурный анализ. Вторая альтернатива классической технике объектно-ориентированного анализа использует структурный анализ как основу для объектно-ориентированного проектирования. Такой подход привлекателен потому, что много аналитиков применяют этот подход и имеется большое число программных CASE-средств, поддерживающих автоматизацию этих методов 4.1. СУЩНОСТЬ СТРУКТУРНОГО ПОДХОДА. Существует два основных способа проектирования программных систем - структурное проектирование, основанное на алгоритмической декомпозиции, и объектно-ориентированное проектирование, основанное на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение объектам действия. Алгоритмическую декомпозицию можно представить как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. При объектно-ориентированной декомпозиции каждый объект обладает своим собственным поведением и каждый из них моделирует некоторый объект реального мира. Объектная декомпозиция имеет несколько преимуществ перед алгоритмической. • Объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов. • Объектно-ориентированные системы более гибки и проще эволюционируют со временем. 12 В объектно-ориентированном анализе существует четыре основных типа моделей: динамическая, статическая, логическая и физическая. Через них можно выразить результаты анализа и проектирования, выполненные в рамках любого проекта. Эти модели в совокупности семантически достаточно универсальны, чтобы разработчик мог выразить все заслуживающие внимания стратегические и тактические решения, которые он должен принять при анализе системы и формировании ее архитектуры. Кроме того, эти модели достаточно полны, чтобы служить техническим проектом реализации практически на любом объектно-ориентированном языке программирования. Фактически все сложные системы можно представить одной и той же канонической формой - в виде двух ортогональных иерархий одной системы: классов и объектов. Каждая иерархия является многоуровневой, причем в ней классы и объекты более высокого уровня построены из более простых. Какой класс или объект выбран в качестве элементарного, зависит от рассматриваемой задачи. Объекты одного уровня имеют четко выраженные связи, особенно это касается компонентов структуры объектов. Внутри любого рассматриваемого уровня находится следующий уровень сложности. Структуры классов и объектов не являются независимыми: каждый элемент структуры объектов представляет специфический экземпляр определенного класса. Объектов в сложной системе обычно гораздо больше, чем классов. С введением структуры классов в ней размещаются общие свойства экземпляров классов. Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Общая модель системы строится в виде некоторой иерархической структуры, которая отражает различные уровни абстракции с ограниченным числом компонентов на каждом из уровней. Одним из главных принципов структурного системного анализа является выделение на каждом из уровней абстракции только наиболее существенных компонентов или элементов системы. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:  принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; 13 принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:  принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;  принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;  принцип непротиворечивости - заключается в обоснованности и согласованности элементов;  принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы. В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:  SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;  DFD (Data Flow Diagrams) диаграммы потоков данных;  ERD (Entity-Relationship Diagrams) диаграммы "сущностьсвязь". (эти диаграммы рассмотрим на следующих лекциях) На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.  4.2 СТРУКТУРНАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ В основе проектирования ИС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы. При этом под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной 14 области и отвечающая основному требованию – быть адекватной этой области. Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы. Вследствие этого все современные технологии проектирования ИС основываются на использовании методологии моделирования предметной области. К моделям предметных областей предъявляются следующие требования:  формализация, обеспечивающая однозначное описание структуры предметной области;  понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;  реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;  обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых показателей. Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области. Структурный аспект предполагает построение:  объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;  функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;  структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;  организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;  технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств. Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования — простота. Графические методы должны обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации и согласований описаний на смежных уровнях декомпозиции. 15 С моделированием непосредственно связана проблема выбора языка представления проектных решений, позволяющего как можно больше привлекать будущих пользователей системы к ее разработке. Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения. Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию. Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС. Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:  время решения задач;  стоимостные затраты на обработку данных;  надежность процессов;  косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д. Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования. В основе различных методологий моделирования предметной области ИС лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определении требований), на концептуальном уровне (спецификации требований) и внутреннем уровне (реализации требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного 16 и разных типов. На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе? С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования. Рассмотрим особенности построения моделей предметной области на трех уровнях детализации. Объектная структура Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства, например, оборудование, персонал, запасы материалов. На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.). На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. Таким образом, строится обобщенное представление структуры предметной области. Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах. На внутреннем уровне уточняется программные средства реализации Функциональная структура Функция (операция) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс. Функция бизнеспроцесса может порождать объекты любой природы (материальные, денежные, информационные). Причем бизнес-процессы и информационные процессы, как правило, неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Например, отгрузка готовой продукции осуществляется на основе документа 17 "Заказ", который, в свою очередь, порождает документ "Накладная", сопровождающий партию отгруженного товара. Функция может быть представлена одним действием или некоторой совокупностью действий. В последнем случае каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы, и т.д., пока каждая из подфункций не будет представлять некоторую недекомпозируемую последовательность действий. На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20. На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций. На внутреннем уровне отображается структура информационного процесса в компьютере: определяются иерархические структуры программных модулей, реализующих автоматизируемые функции. Структура управления В совокупности функций бизнес-процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса. Эти условия связаны с происходящими событиями во внешней среде или в самих процессах и с образованием определенных состояний объектов (например, заказ принят, отвергнут, отправлен на корректировку). События вызывают выполнение функций, которые, в свою очередь, изменяют состояния объектов и формируют новые события, и т.д., пока не будет завершен некоторый бизнес-процесс. Тогда последовательность событий составляет конкретную реализацию бизнеспроцесса. Каждое событие описывается с двух точек зрения: информационной и процедурной. Информационно событие отражается в виде некоторого сообщения, фиксирующего факт выполнения некоторой функции изменения состояния или появления нового. Процедурно событие вызывает выполнение новой функции, и поэтому для каждого состояния объекта должны быть заданы описания этих вызовов. На внешнем уровне определяются список внешних событий, вызываемых взаимодействием предприятия с внешней средой (платежи налогов, процентов по кредитам, поставки по контрактам и т.д.), и список целевых установок, которым должны соответствовать бизнес-процессы (регламент выполнения процессов, поддержка уровня материальных запасов, уровень качества продукции и т.д.). На концептуальном уровне устанавливаются бизнес-правила, определяющие условия вызова функций при возникновении событий и достижении состояний объектов. На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей. 18 Организационная структура Организационная структура представляет собой совокупность организационных единиц, как правило, связанных иерархическими и процессными отношениями. Организационная единица — это подразделение, представляющее собой объединение людей (персонала) для выполнения совокупности общих функций или бизнес-процессов. В функциональноориентированной организационной структуре организационная единица выполняет набор функций, относящихся к одной функции управления и входящих в различные процессы. В процессно-ориентированной структуре организационная единица выполняет набор функций, входящих в один тип процесса и относящихся к разным функциям управления. На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений. На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала). На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы. Техническая структура Топология определяет территориальное размещение технических средств по структурным подразделениям предприятия, а коммуникация — технический способ реализации взаимодействия структурных подразделений. На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям. На концептуальном уровне определяются способы коммуникаций между техническими комплексами структурных подразделений: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т.д. На внутреннем уровне строится модель "клиент-серверной" архитектуры вычислительной сети. Описанные модели предметной области нацелены на проектирование отдельных компонентов ИС: данных, функциональных программных модулей, управляющих программных модулей, программных модулей интерфейсов пользователей, структуры технического комплекса. Для более качественного проектирования указанных компонентов требуется построение моделей, увязывающих различные компоненты ИС между собой. В простейшем случае в качестве таких моделей взаимодействия могут использоваться матрицы перекрестных ссылок: "объекты-функции", "функции-события", "организационные единицы — функции", "организационные единицы — объекты", "организационные единицы — технические средства" и т д. Такие матрицы не наглядны и не отражают особенности реализации взаимодействий. 19 Для правильного отображения взаимодействий компонентов ИС важно осуществлять совместное моделирование таких компонентов, особенно с содержательной точки зрения объектов и функций. Методология структурного системного анализа существенно помогает в решении таких задач. Существуют различные методологии структурного моделирования предметной области, среди которых следует выделить функциональноориентированные и объектно-ориентированные методологии. 4.3 ФУНКЦИОНАЛЬНО-ОРИЕНТИРОВАННЫЕ И ОБЪЕКТНООРИЕНТИРОВАННЫЕ МЕТОДОЛОГИИ ОПИСАНИЯ ПРЕДМЕТНОЙ ОБЛАСТИ Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные). Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц (например методики UML). Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных. С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе. 4.4 МОДЕЛИРОВАНИЕ ДАННЫХ. 4.4.1 ERWIN ERwin - средство разработки структуры базы данных (БД). ERwin сочетает инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и поддержку ведущих 20 реляционных БД. С помощью ERwin можно создавать БД или проводить обратное проектирование (реинжиниринг) баз данных. Возможны две точки зрения на информационную модель и, соответственно, два уровня модели. Первый - логический (точка зрения пользователя) - описывает данные, задействованные в бизнесе предприятия. Второй - физический - определяет представление информации в БД. ERwin позволяет создавать как логические так и физические модели. Таким образом, ERwin - это не просто мощное средство проектирования, но и инструмент разработки, способный автоматически создавать таблицы и генерировать текст хранимых процедур для всех популярных СУБД. Наибольшее распространение при построении ER-диаграмм получили следующие нотации: нотация Чена, нотация Мартина, нотация DEF1X, нотация Баркера. Данная нотация была предложена П. Ченом (P. Chen) в его известной работе 1976 года [17] и получила дальнейшее развитие в работах Р. Баркера [16] (R. Barker). Диаграммы "сущность-связь" (ERD) предназначены для графического представления моделей данных разрабатываемой программной системы и предлагают некоторый набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними, имеющих важное значение для разрабатываемой системы. Существует несколько методологий визуального моделирования данных. Наиболее распространенными из них являются две. 1. IDEF1X (Integration Definition for Information Modeling – интегрированное описание информационных моделей). 2. IE (Information Engineering – информационная инженерия). Case-средство ERWin поддерживает методологию IDEF1X. Методология IDEFIX подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Три уровня моделей, объединяющие в себе логические модели, состоят из Entity Relationship Diagram (Диаграмма сущность-связь), the KeyBased (KB Model) (Модель данных, основанная на ключах) и the Fully Attributed model (Полная атрибутивная модель) (FA Model) (Fully Attributed). Диаграмма сущность-связь Диаграмма сушность-связь является самым высоким уровнем в модели данных и определяет набор сущностей и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего взгляда на систему для ее дальнейшей детализации. Модель данных, основанная на ключах (KB модели ) 21 Этот тип модели описывает структуру данных системы, в которую включены все сущности и атрибуты, в том числе ключевые. Целью этой модели является детализация модели сущность-связь, после чего модель данных может начать реализовываться. Модель данных, основанная на ключах, дает более подробное представление данных. Она включает описание всех сущностей и первичных ключей, которые соответствуют предметной области. Полная атрибутивная модель (FA модели) Эта модель включает в себя все сущности, атрибуты и является наиболее детальным представлением структуры данных. Полная атрибутивная модель представляет данные в третьей нормальной форме. Т.е это модель в которой все атрибуты атомарны (1НФ), все неключевые атрибуты функционально зависит от всего первичного ключа в целом (если он составной), а не находится в функциональной зависимости от его части (2НФ) и каждый неключевой атрибут нетранзитивно зависит от первичного ключа (3НФ). Физические модели Физические модели содержат информацию, необходимую системным разработчикам для понимания механизма реализации логической модели в СУБД. ERWin поддерживает автоматическую генерацию физической модели данных для конкретной СУБД. При этом логическая модель трансформируется в физическую по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключи становятся индексами. Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами. ERD-диаграммы Как известно основным компонентом реляционных БД является таблица. Таблица используется для структуризации и хранения информации. В реляционных БД каждая ячейка таблицы содержит одно значение. Кроме того, внутри одной БД существуют взаимосвязи между таблицами, каждая из которых задает совместное пользование данными таблицы. ERD-диаграмма графически представляет структуру данных проектируемой информационной системы. Сущности отображаются при помощи прямоугольников, содержащих имя. Имена принято выражать существительными в единственном числе, взаимосвязи - при помощи линий, соединяющих отдельные сущности. Взаимосвязь показывает, что данные одной сущности ссылаются или связаны с данными другой. 22 4.4.2 ДИАГРАММЫ СУЩНОСТЬ-СВЯЗЬ (ERD) ENTITY RELATIONAL DIAGRAM Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных. ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации. ERD-диаграммы можно подразделить на отдельные части, соответствующие отдельным задачам, решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных возможностей, делая процесс проектирования управляемым. Основными понятиями построения ERD диаграмм являются понятия сущности и связи. При этом под сущностью (entity) понимается произвольное множество реальных или абстрактных объектов, каждый из которых обладает одинаковыми свойствами и характеристиками. В этом случае каждый рассматриваемый объект может являться экземпляром одной и только одной сущности, должен иметь уникальное имя или идентификатор, а также отличаться от других экземпляров данной сущности. Примерами сущностей могут быть: банк, клиент банка, счет клиента, аэропорт, пассажир, рейс, компьютер, терминал, автомобиль, водитель. Каждая из сущностей может рассматриваться с различной степенью детализации и на различном уровне абстракции, что определяется конкретной постановкой задачи. Для графического представления сущностей используются специальные обозначения, обычно сущности отображаются при помощи прямоугольников, содержащих имя. Рис. 2.8. Графические изображения для обозначения сущностей Связь (relationship) определяется как отношение между отдельными сущностями. Примерами связей могут являться родственные отношения типа "отец-сын" или производственные отношения типа "начальник23 подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Графическая модель данных строится таким образом, чтобы связи между отдельными сущностями отражали не только семантический характер соответствующего отношения, а также кратность участвующих в данных отношениях экземпляров сущностей. В этом плане различают несколько типов связей. Взаимосвязи отражают взаимодействие между двумя сущностями «один-ко-многим» означает, что один экземпляр первой сущности взаимодействует с несколькими экземплярами другой сущности. Кроме взаимосвязи «один-комногим» существует еще один тип – это «многие-ко-многим». Этот тип связи описывает ситуацию, при которой экземпляры сущностей могут взаимодействовать с несколькими экземплярами других сущностей. Различные типы связей в разнах нотациях изображаются по разному: Ниже приведено сопоставление обозначений связей, принятых в нотациях IDEF1X и IE. Взаимосвязи отображаются линиями, соединяющими две сущности с точкой на одном конце и глаголом, располагаемым над линией В нотации Чена связи графически изображаются в форме ромба с соответствующим именем данной связи (рис. 2.9). 24 Рис. 2.9. Графические изображения для обозначения связей в нотации Чена Примеры связей: Рассмотрим в качестве простого примера ситуацию, которая описывается двумя сущностями: "Сотрудник" и "Компания". При этом в качестве связи естественно. использовать отношение принадлежности сотрудника данной компании. Если учесть соображения о том, что в компании работают несколько сотрудников, и эти сотрудники не могут быть работниками других компаний, то данная информация может быть представлена графически в виде следующей диаграммы "сущность-связь" (рис. 2.10). На данном рисунке буква "N" около связи означает тот факт, что в компании могут работать более одного сотрудника, при этом значение N заранее не фиксируется. Цифра "1" на другом конце связи означает, что сотрудник может работать только в одной конкретной компании, т. е. не допускается прием на работу сотрудников по совместительству из других компаний или учреждений. 25 Рис. 2.10. Диаграмма "сущность-связь" для примера сотрудников некоторой компании Несколько иная ситуация складывается в случае рассмотрения сущностей "сотрудник" и "проект", и связи "участвует в работе над проектом" (рис. 2.11). Поскольку в общем случае один сотрудник может участвовать в разработке нескольких проектов, а в разработке одного проекта могут принимать участие несколько сотрудников, то данная связь является многозначной. Данный факт специально отражается на диаграмме указанием букв "N" и "М" около соответствующих сущностей, при этом выбор конкретных букв не является принципиальным. Рис. 2.11. Диаграмма "сущность-связь" для примера сотрудников, участвующих в работе над проектами Рассмотренные две диаграммы могут быть объединены в одну, на которой будет представлена информация о сотрудниках компании, участвующих в разработке проектов данной компании (рис. 2.12). При этом может быть введена дополнительная связь, характеризующая проекты данной компании. Рис. 2.12. Диаграмма "сущность-связь" для общего примера компании Нотация Баркера Дальнейшее развитие ER-подход получил в работах Баркера, предложившего оригинальную нотацию, которая позволила на верхнем уровне интегрировать предложенные Ченом средства описания моделей. 26 В нотации Баркера используется только один тип диаграмм - ERD. Сущность на ERD представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак "#" перед именем атрибута). Все связи являются бинарными и представляются линиями с двумя концами (соединяющими сущности), для которых должно быть определено имя, степень множественности (один или много объектов участвуют в связи) и степень обязательности (т.е. обязательная или необязательная связь между сущностями). Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи - в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной - пунктирная линия. На рис. 5.6 приведен фрагмент ERD для банковской задачи в нотации Баркера. Рис. 5.6. Нотация Баркера. Читается связь отдельно для каждого конца, показывая, как сущность КЛИЕНТ связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова "должен (быть)" или "может (быть)". Так, диаграмма, приведенная на рис. 5.6, читается следующим образом: Каждый КЛИЕНТ может ВЛАДЕТЬ одной или более КРЕДИТНОЙ КАРТОЙ или Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ ровно одному КЛИЕНТУ. 27 Рис. 13. Фрагмент концептуальной схемы в нотации Чена При создании сущности необходимо выделить группу атрибутов, которые потенциально могут стать первичным ключом (потенциальные ключи), затем произвести отбор атрибутов для включения в состав первичного Ключа. При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Атрибуты внешнего ключа обозначаются символами (FK) после своего имени. При создании связи задается ее характер – идентифицирующая или неидентифицирующая. В первом случае первичный ключ родительской таблицы входит составной частью в первичный ключ дочерней таблицы, во втором случае – не входит. Если связь задана неидентифицирующая, можно дополнительно указать допустимость пустых значений (NULL values). 28 Рассмотрим процесс построения логической модели на примере БД студентов. Первым этапом является определение сущностей и атрибутов. Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 6.4). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим». Следующим этапом при построении логической модели является определение ключевых атрибутов и типов атрибутов. Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Студент» это будет уникальный номер, для сущности «Опыт работы» все поля являются ключевыми, так как по разным специальностям студент может иметь разный опыт работы в разных фирмах. Сущность «Тест» определяется названием, так как студент по одному тесту может иметь только одну оценку. Оценка по экзамену определяется только названием предмета, экспертная оценка зависит от преподавателя, который ее составил, поэтому в качестве ключевых атрибутов выберем «Дисциплину» и «Ф.И.О. преподавателя». У сущности «Иностранный язык» уровень владения зависит только от наименования языка, следовательно, это и будет являться ключевым атрибутом. Получим новую диаграмму, изображенную на рис. 6.5, где все ключевые атрибуты будут находиться над горизонтальной чертой внутри рамки, изображающей сущность. 29 Нормализуем полученную в предыдущей лабораторной работе БД до третьей нормальной формы. Для приведения БД в первую нормальную форму необходимо выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим атрибуты сущности «Студент». Студент молсет иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой нормальной формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 7.1). Проверим соответствие БД второй нормальной форме. Все неключевые атрибуты полностью должны зависеть от первичного ключа. Нетрудно заметить, что это условие выполняется для всех сущностей БД; 30 следовательно, можно сделать вывод о том, что она находится во второй нормальной форме. Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость наблюдается у атрибутов «Специальность» и «Специализация » у сущности «Студент»: специализация зависит от специальности сущность «Специальность», перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа», являющийся ключевым и определяющий атрибуты «Специальность» и «Специализация». Проведем неидентифицирующую связь от сущности «Специальность» к сущности «Студент», при этом ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так как других транзитивных зависимостей неключевых атрибутов нет (рис. 7.2). После построения логической модели перейдем к построению физической модели. Перед построением физической модели выбрать сервер, после чего можно автоматически получить физическую модель, сгенерированную средой ERWin. В полученной модели необходимо скорректировать типы и размеры полей. Кроме того, на этапе создания физической модели данных вводятся правила определяющие списки допустимых значений и значения по умолчанию. 4.5 ДИАГРАММЫ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ. (SADT) Методология SADT (Structured Analysis and Design Technique) разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0. Методологию IDEF0 можно считать 31 следующим этапом развития графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:  графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;  строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:  ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);  связность диаграмм (номера блоков);  уникальность меток и наименований (отсутствие повторяющихся имен);  синтаксические правила для графики (блоков и дуг);  разделение входов и управлений (правило определения роли данных).  отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. Разработку SADT-модели начинают с формулировки вопросов, на которые модель должна давать ответы, т.е. формулируют цель моделирования. Далее строят иерархическую совокупность диаграмм с лаконичным описанием функций. Недостатки SADT-моделей — их слабая формализованность для автоматического выполнения проектных процедур на их основе. Однако 32 наличие графического языка диаграмм, удобного для восприятия человеком, обусловливает полезность и применимость методики SADT. В рамках развития методологии SADT было разработано несколько графических языков моделирования, которые получили следующие названия:  Нотация IDEF0 — для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем. (методология функционального моделирования) IDEF0 — это более четкое представление методики SADT. Описание объектов и процессов в SADT (IDEF0) выполняется в виде совокупности взаимосвязанных блоков  Нотация IDEF1 — для документирования информации о производственном окружении систем. (моделирование информационных потоков внутри системы)  Нотация IDEF1X — методология построения реляционных структур (БД).  Нотация IDEF2 — для документирования поведения системы во времени.  Нотация IDEF3 — специально для моделирования бизнеспроцессов. Методика IDEF3 отражает поведенческие аспекты приложений.Поведенческое моделирование сложных систем используют для исследования динамики их функционирования. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопросы “Что делает система?”, то в IDEF3 детализируются и конкретизируются IDEF0-функции, IDEF3-модель отвечает на вопросы “Как система это делает?” Язык IDEF3 — язык диаграмм, помогающий разработчику моделей наглядно представить моделируемые процессы. В IDEF3 входят два типа описаний: 1) процесс-ориентированные в виде последовательности операций; 2) объект-ориентированные, выражаемые диаграммами перехода состояний. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Рис. 2.1. Функциональный блок и интерфейсные дуги 33 Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 2.1). Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Механизм – те, кто выполняет функцию, с помощью чего. Управление – стандарты, правила, время, бюджет. Входы – задачи Выходы - результат !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Обзор других методик IDEF. Методика IDEF4 реализует объектноориентированное проектирование больших систем. Другим вариантом графического языка поддержки объектно-ориентированного проектирования ПО является язык UML (Unified Modeling Language), О нем позже – в следующих лекциях. Методика IDEF4 содержит графический язык для изображения взаимосвязей классов, атрибутов, методов в виде ряда диаграмм: типов, наследования, протоколов, клиентов, таксономии методов. 4.5.1 BPWin BPWin поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область более комплексно. Применение данных методологий в ходе построения моделей бизнеспроцессов в виде иерархии диаграмм, обеспечивает наглядность и полноту их отображения, позволяет анализировать деятельность предприятия в трех информационных разрезах: 4.5.2 IDEF0, DED, IDEF3 IDEF0 Первый информационный разрез — функциональность системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, обмениваясь информационными и материальными потоками с помощью людских и производственных ресурсов, потребляемых каждой работой. С помощью функционального моделирования можно провести системный анализ бизнеса, сосредоточившись на регулярно решаемых задачах или функциях, на 34 показателях их правильного выполнения, необходимых для этого ресурсах, результатах и исходных материалах (сырье). В терминах IDEF0 система представляется в виде комбинации блоков и дуг. В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий. Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). На диаграмме функциональный блок изображается прямоугольником (рис. 6.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:  верхняя сторона имеет значение "Управление" (Control);  левая сторона имеет значение "Вход" (Input);  правая сторона имеет значение "Выход" (Output);  нижняя сторона имеет значение "Механизм" (Mechanism). Рис. 6.1. Функциональный блок Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей". Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей 35 дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. Рис. 7.6. Пример контекстной диаграммы 36 В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). (т.е с точки зрения Директора) Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели. После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием, или как ее еще называют — декомпозицией, одной из работ на вышестоящей диаграмме Рис. 7.9. Пример диаграммы декомпозиции В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней 37 (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели. Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. Тоннелирование может быть применено для изображения малозначимых стрелок. Для помещения на диаграмму верхнего уровня необходимо щелкнуть правой кнопкой мыши по стрелке внутри квадратных скобок и в открывшемся контекстном меню выбрать пункт «Arrow tunnel» -> «Resolve it to border arrow». При этом стрелка мигрирует на диаграмму верхнего уровня. Если выбрать пункт «Change it to resolved rounded tunnel», то стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце. Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности. Рекомендуется представлять на диаграмме от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех. BPwin автоматически синхронизирует изменения объектов диаграмм на всех уровнях детализации, тем самым освобождая пользователя от ручного ведения словаря объектов модели. Так если мы исправим на верхнем уровне название объекта, то получим изменение на всех уровнях, где данный объект встречается. Также невозможным является случайное дублирование 38 наименований работ. При появлении такой ситуации BPwin генерирует предупреждающее сообщение. Кроме основных видов диаграмм модель нотации IDEF0 в BPwin может включать следующие элементы: Диаграмма дерева узлов имеет вид традиционного иерархического дерева, где верхний прямоугольник соответствует работе с контекстной диаграммы, а последующие нижние узлы представляют собой дочерние уровни декомпозиции Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами Диаграмм деревьев узлов в модели может быть сколько угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня. Чаще всего FEO диаграммы строятся, чтобы показать модель с других точек зрения, вырезать важный кусок из сложной диаграммы, рассмотреть вариации модели или проблемной области, проанализировать их, не внося изменений в основную модель. В IDEF0 различают пять типов связей работ. 1. Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее – просто выход) направляется на вход нижестоящей, например, на рис.29 стрелка «Доставленный товар» связывает работы «Закупка товара» и «Хранение». 39 2. Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по входу показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис.29 стрелка «Документы на закупленный товар» связывает работы «Закупка товара» и «Хранение», при этом «Документы на закупленный товар» не претерпевают изменений в процессе изготовления деталей. 3. Обратная связь по входу (output-input feedback), когда выход ниже стоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис.30 стрелка «Информация о выписанных счетах» связывает работы «Закупка товара» и «Продажа». 40 4. Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка «Рекомендации», рис.31). Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса. На рис.31 качество изделия может быть повышено путем непосредственного регулирования процессами изготовления деталей и сборки изделия в зависимости от результата (выхода) работы «Контроль качества». Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рис.32). Диаграммы потоков данных. (DFD) Второй информационный разрез — потоки информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией как 41 внутри системы между бизнес-функциями, так и системы в целом с внешней информационной средой. Для усиления функциональности в данной нотации диаграмм предусмотрены специфические элементы, предназначенные для описания информационных и документопотоков, такие как внешние сущности и хранилища данных. Без объекта "внешняя сущность" аналитику бывает иногда сложно определить, откуда пришли в компанию данные документы. Или какие документы еще приходят от, такой внешней сущности как, например, "клиент". Объект "хранилище данных" является уникальным обозначением длительного хранения, очередности обработки, резерва документов. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов, хранение объектов, поставка и распространение объектов. Основой данной методологии графического моделирования информационных систем является специальная технология построения диаграмм потоков данных DFD. В разработке методологии DFD приняли участие многие аналитики, среди которых следует отметить Э. Йордона (Е. Yourdon). Он является автором одной из первых графических нотаций DFD [10]. В настоящее время наиболее распространенной является так называемая нотация Гейна-Сарсона (Gene-Sarson), основные элементы которой будут рассмотрены в этом разделе. Диаграммы потоков данных (DFD – Data Flow Diagram) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Система в контексте DFD представляется в виде некоторой информационной модели, основными компонентами которой являются различные потоки данных, которые переносят информацию от одной подсистемы к другой. Каждая из подсистем выполняет определенные преобразования входного потока данных и передает результаты обработки информации в виде потоков данных для других подсистем. Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут пред варительно оговариваться. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных. Основные 42 компоненты диаграмм потоков данных изображены на рис.37. Опишем их назначение. Потоки данных являются механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Важность этого объекта очевидна: он дает название целому инструменту. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, «вычислить максимальную высоту»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Накопитель данных или хранилище представляет собой абстрактное устройство или способ хранения информации, перемещаемой между процессами. Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он 43 должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. Накопитель данных может быть физически реализован различными способами, но наиболее часто предполагается его реализация в электронном виде на магнитных носителях Рис. 2.18. Изображение накопителя на диаграмме потоков данных Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, склад товаров. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке. Примерами внешних сущностей могут служить: клиенты организации, заказчики, персонал, поставщики. Контекстная диаграмма и детализация процессов Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. Важную специфическую роль в модели играет специальный вид DFD контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализируемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса. DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме. Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одной страницы) миниспецификаций обработки (спецификаций процессов). При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, например, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощью DFD, содержащей три процесса, то их 44 номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 2.2.1, 2.2.2. и т.д. Декомпозиция данных и соответствующие расширения диаграмм потоков данных Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Например, в системе имеются потоки яблоки, апельсины и груши. Эти потоки могут быть сгруппированы с помощью введения нового потока фрукты. Для этого необходимо определить формально поток фрукты как состоящий из нескольких элементов-потомков. Такое определение задается в словаре данных. В свою очередь поток фрукты сам может содержаться в потоке-предке еда вместе с потоками овощи, мясо и др. Такие потоки, объединяющие несколько потоков, получили название групповых. Обратная операция, расщепление потоков на подпотоки, осуществляется с использованием группового узла (рис.38), позволяющего расщепить поток на любое число подпотоков. При расщеплении также необходимо формально определить подпотоки в словаре данных. Аналогичным образом осуществляется и декомпозиция потоков через границы диаграмм, позволяющая упростить детализирующую DFD. Пусть имеется поток фрукты, входящий в детализируемый процесс. На детализирующей этот процесс диаграмме потока фрукты может не быть вовсе, но вместо него могут быть потоки яблоки и апельсины (как будто бы они переданы из детализируемого процесса). В этом случае должно существовать определение потока фрукты, состоящего из подпотоков яблоки и апельсины, для целей балансирования. Применение этих операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм. Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов. 1. Групповой узел. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме). 2. Узел-предок. Позволяет увязывать входящие и выходящиепотоки между детализируемым процессом и детализирующей DFD. 3. Неиспользуемый узел. Применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока. 4. Узел изменения имени. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании 45 разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой - выходным. 5. Текст в свободном формате в любом месте диаграммы. Возможный способ изображения этих узлов приведен на рис.38. Построение модели Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями: 1. Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса. 2. Не загромождать диаграммы несущественными на данном уровне деталями. 3. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов; эти две работы должны выполняться одновременно, а не одна после завершения другой. 4. Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры. 5. Однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться на него на нижних уровнях. 46 6. Пользоваться простейшими диаграммными техниками: если чтолибо возможно описать с помощью DFD, то это и необходимо делать, а не использовать для описания более сложные объекты. 7. Отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры. В соответствии с этими рекомендациями процесс построения модели разбивается на следующие этапы: 1. Расчленение множества требований и организация их в основные функциональные группы. 2. Идентификация внешних объектов, с которыми система должна быть связана. 3. Идентификация основных видов информации, циркулирующей между системой и внешними объектами. 4. Предварительная разработка контекстнойдиаграммы, на которой основные функциональные группы представляются процессами, внешние объекты – внешними сущностями, основные виды информации – потоками данных между процессами и внешними сущностями. 5. Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям. 6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков. 7. Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы. 8. Проверка основных требований по DFD первого уровня. 9. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса. 10. Проверка основных требований по DFD соответствующего уровня. 11. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах. 12. Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям. 13. Проведение ревизии после построения двух-трех уровней с целью проверки корректности и улучшения понимаемости модели. Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов. Пример построения DFD диаграммы В качестве примера создания модели рассмотрим фрагмент проекта системы обработки заказов клиентов и их обслуживания. Организация 47 принимает от клиентов заказы на поставку товаров. Клиенту выписывается счет, после оплаты которого происходит отгрузка товара. Основными функциями системы являются выписка счета клиенту, прием оплаты от клиента, отгрузка товаров. Построим контекстную диаграмму системы. Для этого изобразим основную функцию рассматриваемой системы и внешние по отношению к ней сущности, а также взаимосвязи между внешними сущностями и функцией системы. Здесь сущность Склад является внешней по отношению к системе, т.к. рассматриваемая система не выполняет складских операций. Таким образом она лишь получает необходимую для работы информацию от Склада. Клиенты делают заказы на покупку товаров и получают товары, что изображено в виде стрелок с соответствующими наименованиями. После создания контекстной диаграммы, постараемся рассмотреть функции системы более подробно и построить в результате диаграмму детализации первого уровня. В начале рассмотрения примера было указано, что система должна выполнять три основных функции: выписка счета клиенту, прием оплаты от клиента, отгрузка товаров. Изобразим эти фукнции на диаграмме детализации, а также определим и изобразим хранилища данных и потоки данных между функциями, хранилищами и контекстной диаграммой. 48 Результат построения представлен на рис.40. диаграммы детализации первого уровня Здесь, помимо трех функций системы представлены три хранилища, предназначенные для хранения данных о заказах, счетах и клиентах. Пример 2. Рассмотрим процесс СДАТЬ ЭКЗАМЕН. У нас есть две сущности СТУДЕНТ и ПРЕПОДАВАТЕЛЬ. Опишем потоки данных, которыми обменивается наша проектируемая система с внешними объектами (рис. 2). Со стороны сущности СТУДЕНТ опишем информационные потоки. Для сдачи экзамена необходимо, чтобы у СТУДЕНТА была ЗАЧЕТКА, а также чтобы он имел ДОПУСК К ЭКЗАМЕНУ. Результатом сдачи экзамена, т.е. выходными потоками будут ОЦЕНКА ЗА ЭКЗАМЕН и ЗАЧЕТКА, в которую будет проставлена ОЦЕНКА. Со стороны сущности ПРЕПОДАВАТЕЛЬ информационные потоки следующие: ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ, согласно которой будет известно, что СТУДЕНТ допущен до экзамена, а также официальная бумага, куда будет занесен результат экзамена, т.е. ОЦЕНКА ЗА ЭКЗАМЕН, проставленная в ЭКЗАМЕНАЦИОННУЮ ВЕДОМОСТЬ. 49 Рис. 2 DFD-диаграмма процесса «Сдать экзамен» Теперь детализируем процесс СДАЧА ЭКЗАМЕНА. Этот процесс будет содержать следующие процессы (рис. 3): ВЫТЯНУТЬ БИЛЕТ {1.1}, ПОДГОТОВИТЬСЯ К ОТВЕТУ {1.2}, ОТВЕТИТЬ НА БИЛЕТ {1.3}, ПРОСТАВЛЕНИЕ ОЦЕНКИ {1.4}. Рис. 3 Декомпозиция 1-го уровня DFD-диаграммы процесса «Сдать экзамен» 50 Построим DFD-диаграмму для предприятия, строящего свою деятельность по принципу "изготовление на заказ". На основании полученных заказов формируется план выпуска продукции на определенный период. В соответствии с этим планом определяются потребность в комплектующих изделиях и материалах, а также график загрузки производственного оборудования. После изготовления продукции и проведения платежей, готовая продукция отправляется заказчику. Эта диаграмма представляет самый верхний уровень функциональной модели. Естественно, это весьма грубое описание предметной области. Уточнение модели производится путем детализации необходимых функций на DFD-диаграмме следующего уровня. Так мы можем разбить функцию "Определение потребностей и обеспечение материалами" на подфункции "Определение потребностей", "Поиск поставщиков", "Заключение и анализ договоров на поставку", "Контроль платежей", "Контроль поставок", связанные собственными потоками данных, которые будут представлены на отдельной диаграмме. Детализация модели должна производится до тех пор, 51 пока она не будет содержать всю информацию, необходимую для построения информационной системы. В ходе консалтингового проекта моделирование подсистемы проводится аналитиком совместно с экспертом предметной области. Для этого в начале консалтингового проекта, на этапе анкетирования руководителей определяются сотрудники, хорошо владеющие предметной областью подсистемы, хорошо знающие все ее функции. Они назначаются на роли экспертов. В ходе постоянного диалога "Автор-читатель" проводится построение, верификация и исправление диаграмм модели. После того как диаграмма уровня модели согласована с экспертом, определяется необходимость ее дальнейшей детализации. Если такая необходимость существует, то проводится ее детализация и цикл повторяется вновь. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. В качестве корпоративного стандарта построения моделей деятельности принят метод, при котором верхние 3-4 уровня модели строятся в нотации IDEF0, а завершающий нижний уровень — в нотации DFD. Этим достигается целостность модели без перегрузки ее излишней информацией на верхних уровнях детализации (рис.7). Проводя детализацию модели деятельности до необходимого уровня аналитик способен определить недостатки системы там, где логичность ее построения с первого взгляда не вызывает сомнения. Критериями в данном случае могут служить процессы без управления, дублирующиеся работы, неоптимальные документопотоки, отсутствие контролирующих связей между процессами и т.д. BPwin содержит в себе средства, помогающие отследить эти и другие ошибки в модели "AS IS", появляющиеся вследствие нарушения стандарта методологии. Прежде всего, речь идет о том, что BPwin указывает на синтаксические ошибки в модели, которые могут быть вызваны неправильной организацией системы. После построения и верификации модели "AS IS" аналитику необходимо провести ее качественное исследование, оптимизацию, необходимую для построения модели "TO BE". IDEF3 Третий информационный разрез — последовательность выполняемых работ. В отличие от диаграмм IDEF0 и DFD, элементы которых позволяют точно описать функциональность системы и организацию документооборота, описать с их помощью логику построения системы не удастся. Для описания логики взаимодействия информационных потоков, последовательности выполнения работ и сценариев взаимодействия модель дополняют диаграммами еще одной методологии — IDEF3, также называемой диаграммами workflow. 52 В IDEF3 включены элементы логики, что позволяет аналитику моделировать и анализировать альтернативные сценарии развития бизнеспроцесса. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов. IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать "сеть переходных состояний объекта", предлагая вниманию аналитика, последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс. С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как осуществлять оформление документов при приемке груза. Каждый такой сценарий содержит в себе описание процесса и может быть использован, чтобы наглядно показать или лучше задокументировать бизнес-функции организации. В последней версии BPwin имеется возможность использования модели Swim Lane, основанной на нотации IDEF3, что делает диаграммы данной нотации более читабельными и понятными пользователю (рис.6). Диаграммы Swim Lane представляют собой диаграмму, разделенную горизонтальными полосками на ролевые области. Название данному виду диаграмм дано по аналогии дорожек для плавания. При этом мы получаем наглядное представление потоков работ с учетом имеющихся ролей. В то же время модель не перегружается дополнительными элементами — ссылками. В качестве ролей могут быть использованы, например, названия отделов и подразделений или же модули информационной системы. Вариантов представления ролей может быть много. Перечисленные информационные разрезы по-своему уникальны. Каждый из них может быть выполнен отдельно с помощью BPwin, но их совокупность заключенная в модель дает аналитику полную картину предметной области клиента. Для описания логики в IDEF3 используются такие элементы диаграммы как перекрестки. Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. 53 В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Рассмотрим примеры, иллюстрирующие использование перекрестков. Фрагмент диаграммы, представленной на рис.57 иллюстрирует процесс выдачи наличных кассиром банка. Перекресток J1 обозначает ситуацию, когда любой из последующих процессов (А1.1 или А1.2) должны быть запущены. Перекресток J2 означает, что для продолжения выполнения работ, следующих за перекрестком необходимо завершение хотя бы одного из предшествующих процессов. 54 Рис. 57. Фрагмент диаграммы выдачи кассиром банка наличных денег Пример, приведенный на рис.58 описывает часть процесса работы противопожарной системы. С помощью перекрестка J1 описывается условие, при котором все предшествующие ему процессы должны завершиться, а все последующие начаться. В данном случае это является критическим условием, позволяющим понять, что невозможность запуска хотя бы одной работы (А1.2, А1.3 или А1.4) означает сбой в работе всей системы. В реальной ситуации эти работы могут выполняться последовательно, например, сначала включается система пожаротушения, затем звуковая сигнализация и в последнюю очередь происходит уведомление пожарной охраны, однако разница во времени между этими событиями не должна быть большой и скорее всего не будет заметна человеку – для него все эти события произойдут практически одновременно. Данная же диаграмма позволяет очень точно описать именно такую логику работы системы. Второй перекресток J2 означает, что только после того как все три работы завершатся, будет произведена запись события. Рис. 58. Фрагмент диаграммы работы противопожарной системы 55 Рассмотрим фрагмент процесса выставления оценки студенту преподавателем (рис.59). В данном случае невозможен запуск обоих процессов (А1.2 и А1.3). Они являются взаимоисключаемыми, что и отражено на диаграмме с помощью перекрестка Exclusive OR. Если в ходе проверки статуса студента будет установлено, что статус студента позволят доверять ему, то в последующем становится возможным выставление ему оценки условно, в противном случае, будет осуществлена проверка знаний курса этим студентом. Сравнение существующих методик Объектно-ориентированная методика Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы. Объектноориентированный подход использует объектную декомпозицию, при этом статическая структура описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Целью методики является построение бизнес-модели организации, позволяющей перейти от модели сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации бизнес-функций. 56 Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов:  абстрагирование;  инкапсуляция;  модульность;  иерархия;  типизация;  параллелизм;  устойчивость. Основными понятиями объектно-ориентированного подхода являются объект и класс. Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью структуры и поведения. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы. Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования. Диаграмма (Diagram) — это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы. Объектно-ориентированный подход обладает следующими преимуществами:  Объектная декомпозиция дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. 57 Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования, что ведет к созданию среды разработки и переходу к сборочному созданию моделей.  Объектная декомпозиция позволяет избежать создания сложных моделей, так как она предполагает эволюционный путь развития модели на базе относительно небольших подсистем.  Объектная модель естественна, поскольку ориентированна на человеческое восприятие мира. К недостаткам объектно-ориентированного подхода относятся высокие начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух–трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны. В функциональных моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов. Несомненным достоинством функциональных моделей является реализация структурного подхода к проектированию ИС по принципу "сверху-вниз", когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления. При функциональном подходе объектные модели данных в виде ERдиаграмм "объект — свойство — связь" разрабатываются отдельно. Для проверки корректности моделирования предметной области между функциональными и объектными моделями устанавливаются взаимно однозначные связи. Главный недостаток функциональных моделей заключается в том, что процессы и данные существуют отдельно друг от друга — помимо функциональной декомпозиции существует структура данных, находящаяся на втором плане. Кроме того, не ясны условия выполнения процессов обработки информации, которые динамически могут изменяться. Перечисленные недостатки функциональных моделей снимаются в объектно-ориентированных моделях, в которых главным структурообразующим компонентом выступает класс объектов с набором функций, которые могут обращаться к атрибутам этого класса. Для классов объектов характерна иерархия обобщения, позволяющая осуществлять наследование не только атрибутов (свойств) объектов от вышестоящего класса объектов к нижестоящему классу, но и функций (методов). 58 В случае наследования функций можно абстрагироваться от конкретной реализации процедур (абстрактные типы данных), которые отличаются для определенных подклассов ситуаций. Это дает возможность обращаться к подобным программным модулям по общим именам (полиморфизм) и осуществлять повторное использование программного кода при модификации программного обеспечения. Таким образом, адаптивность объектно-ориентированных систем к изменению предметной области по сравнению с функциональным подходом значительно выше. При объектно-ориентированном подходе изменяется и принцип проектирования ИС. Сначала выделяются классы объектов, а далее в зависимости от возможных состояний объектов (жизненного цикла объектов) определяются методы обработки (функциональные процедуры), что обеспечивает наилучшую реализацию динамического поведения информационной системы. Для объектно-ориентированного подхода разработаны графические методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Однако по наглядности представления модели пользователю-заказчику объектно-ориентированные модели явно уступают функциональным моделям. При выборе методики моделирования предметной области обычно в качестве критерия выступает степень ее динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) — объектно-ориентированные модели. Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае должны использоваться комбинированные модели предметной области. Сравнительный анализ методологий функционального моделирования. Несмотря на то, что методология IDEF0 получила широкое распространение в российских компаниях, на наш взгляд DFD гораздо больше подходит для проектирования информационных систем вообще и баз данных в частности. DFD позволяет уже на стадии функционального моделирования определить базовые требования к данным (этому способствует разделение потоков данных на материальные, информационные и управляющие). Вообще интеграция DFD и ER (entity-relationship, "сущность-связь") моделей не вызывает затруднений. Например, можно определить список атрибутов хранилищ данных, последние на стадии информационного моделирования однозначно отображаются в сущности модели "сущность- связь". В свою очередь, как уже отмечалось, IDEF0 больше подходит для решения задач, связанных с управленческим консультированием 59 (перепроектированием деловых процессов, бизнес - реинжинирингом). Этому способствует также тесная связь IDEF0 с методом функционально стоимостного анализа ABC (Activity Based Costing), позволяющим определить схему расчета стоимости выполнения той или иной деловой процедуры. Однако, существует ряд CASE - систем, предлагающих методологию IDEF0 на этапе функционального обследования предметной области. В таких системах на следующий этап передается просто список всех объектов IDEF0-модели (входы, выходы, механизмы, управление), которые затем рассматриваются на предмет включения в информационную модель. 6. ОБЗОР CASE-СИСТЕМ 6.1. DESIGN/IDEF Пакет Design/IDEF (Meta Software Corp.) – графическая среда для проектирования и моделирования сложных систем широкого назначения, поддерживающая методологии описания и моделирования системных функций (IDEF0/SADT), структур и потоков данных в системе (IDEF1, IDEF1X, E-R) и поведения системы (IDEF/CPN). Пакет Design/IDEF был использован для создания проектов сложнейших систем, связанных с автоматизацией и компьютеризацией производства, управлением и контролем, телекоммуникациями и аэрокосмонавтикой. Design/IDEF используется как составная часть в некоторых известных пакетах типа CIM (Computer Integrated Manufacturing) и САЕ (Computer Aided Engineering) и принят в качестве стандарта для проектов, финансируемых американскими и европейскими спонсорами. Рассмотрим более подробно основные возможности пакета Design/IDEF: 1. Представление графики: Design/IDEF имеет быструю и высококачественную графику, включающую создание стандартных и пользовательских объектов, выравнивание и манипулирование объектами, выбор атрибутов графических объектов и текста. Дополнительно в Design/IDEF реализованы возможности, требуемые для редактирования и моделирования данных: построение связывающих линий типа «резинка», маршрутизация и сглаживание дуг т.д. 2. Обеспечение непротиворечивости модели: Design/IDEF имеет встроенные возможности, дающие уверенность разработчику, что IDEFмодель (Integration Definition for Function Modeling) будет точной, целостной и непротиворечивой на протяжении всего цикла ее создания. Например, при модификации текста, принадлежащего функциональному блоку или дуге в какой-то одной части модели, текст будет динамически скорректирован на всех страницах модели. 3. Поддержка Словаря Данных: Design/IDEF имеет встроенный Словарь Данных, который позволяет хранить информацию и создавать 60 отчеты о функциях и потоках данных в IDEF-модели. Словарь дает возможность определять начальную информацию об объектах и предоставляет разнообразный набор функций сопровождения, восстановления и сохранения целостности файлов данных. Возможности словаря отличаются большой гибкостью и позволяют пользователю вводить неограниченное число параметров для каждого объекта. В сочетании с высококачественной печатью на лазерном принтере, это позволяет разработчику создавать документацию проекта, отвечающую самым высоким требованиям. 4. Генерация отчетов: Design/IDEF предоставляет возможность использовать пять видов отчетов для поддержки и анализа моделей: отчет о контроле полноты модели; отчет о функциях; отчет о дугах; отчет о ссылках; IDEF-отчет. Все отчеты могут быть показаны на экране компьютера, отредактированы и распечатаны с помощью текстового редактора. Design/IDEF анализирует и отбирает данные для генерации текстового файла, содержащего информацию о диаграммах и Словаре. Информация, содержащаяся в отчетах, может быть экспортирована для использования в других программах, таких как, например, электронные таблицы, настольные издательские системы и текстовые редакторы. 5. Организация коллективной работы: Design/IDEF поддерживает работу многочисленной группы разработчиков, создающих одновременно большую и сложную IDEF-модель. Подмодели легко интегрируются в одну большую модель. 6. Моделирование данных (IDEF1, IDEF1X и ER – методологии) Design/IDEF дает также возможность создавать информационные модели, которые представляют как собственно данные, так и связи между ними в системе. Информация, содержащаяся в IDEF-моделях, экспортируется в любую базу данных, а сами модели могут быть экспортированы в Design/CPN - пакет динамического моделирования и анализа сложных систем. Как CASE-пакет по разработке программного обеспечения Design/IDEF поддерживает первые стадии создания программного продукта: 1. Формулировка требований и целей проекта - определение того, что проектируемая система будет делать. 2. Разработка спецификаций – формализованное описание требований. 3. Создание проекта – определение подсистем и взаимодействий между ними. 4. Документирование проекта – создание базы данных проекта, текстуальное описание составных частей проекта. 5. Анализ проекта – проверка проекта на полноту и непротиворечивость. Результатом работы пакета Design/IDEF является проект программной 61 системы, состоящий из двух частей: 1. Проекта функциональной структуры системы, содержащего иерархически связанные страницы с IDEF0-диаграммами и описывающего все модули (вплоть до элементарных функций) системы, их взаимосвязи, входные и выходные параметры. 2. Проекта информационной структуры системы – логической модели ее базы данных, описывающей все структуры и взаимосвязи данных. Оба проекта проверяются на полноту и непротиворечивость, сопровождаются базой данных проекта и документацией. Design/IDEF работает в различных операционных средах: можно строить модели на IBM PC под MS-Windows, Macintosh или под Unix X Window System и переносить диаграммы из одной операционной среды в другую. 6.2. POWER DESIGNER КОМПАНИИ SYBASE В состав Power Designer входят следующие модули: Process Analyst – средство для функционального моделирования, поддерживает нотацию Йордона-де Марко, Гейна-Сарсона и несколько других (DFD). Имеется возможность описать элементы данных (имена, типы, форматы), связанные с потоками данных и хранилищами данных. Эти элементы передаются на следующий этап проектирования, причем хранилища данных могут быть автоматически преобразованы в сущности. Data Analyst – инструмент для построения модели «сущность-связь» автоматической генерации на ее основе реляционной структуры. Исходные данные для модели «сущность-связь» могут быть получены из DFDмоделей, созданных в модуле Process Analyst. В ER-диаграммах допускаются только бинарные связи, задание атрибутов у связей не поддерживается. Поддерживаются диалекты языка SQL примерно для 30 реляционных СУБД, при этом могут быть сгенерированы таблицы, представления, индексы, триггеры и т.д. В результате порождается SQL-сценарий (последовательность команд CREATE), выполнение которого создает спроектированную схему базы данных. Имеется также возможность установить соединение с СУБД через интерфейс ODBC. Другие возможности: автоматическая проверка правильности модели, расчет размера базы данных, реинжиниринг (построение модельных диаграмм для уже существующих баз данных) и т.д. Application Modeler – инструмент для автоматической генерации прототипов программ обработки данных на основе реляционных моделей, построенных в Data Analyst. Может быть получен код для Visual Basic, Delphi, а также для таких систем разработки в архитектуре «клиент-сервер» как PowerBuilder, Uniface, Progress и др. Генерация кода осуществляется на основе шаблонов, соответственно управлять генерацией можно за счет изменения соответствующего шаблона. 62 Ознакомительную версию Power Designer, в которой заблокированы функции сохранения построенных моделей, можно получить с российского web-сервера комании Sybase. 6.3. SILVERRUN КОМПАНИИ SILVERRUN TECHNOLOGIES LTD CASE-система Silverrun состоит из следующих инструментов: BPM – построение DFD-диаграмм. Поддерживает нотации Йордона-де Марко, Гейна-Сарсона, Уорда-Меллора и многие другие. Данный инструмент позволяет автоматически проверить целостность построенной модели, причем список критериев проверки определяется пользователем (например: отсутствие имен у элементов модели, потоки данных типа «хранилище – хранилище» или «внешняя сущность – внешняя сущность» и т.д.) ERX – построение диаграмм «сущность-связь». Поддерживаются не только бинарные связи, но и связи более высоких порядков, имеется возможность определения атрибутов у связей. Построенные ER-модели с помощью внешней утилиты могут быть сконвертированы в реляционные структуры (в той версии, с которой я работал, при этом, к сожалению, терялись атрибуты связей). RDM – инструмент реляционного моделирования, позволяет генерировать SQL-скрипты для создания таблиц и индексов примерно для 25 целевых СУБД. Следует отметить, что компания Silverrun Technologies Ltd является не только разработчиком CASE-инструментария, но также создала собственную методологию создания информационных систем, получившую название Datarun. Эта методология включает описание всех этапов жизненного цикла информационной системы, перечень и последовательность работ, требования к содержанию и оформлению документов и многое другое. Ознакомительную версию Silverrun, можно скачать с сервера комании Argussoft. В этой версии имеются ограничения на количество элементов в создаваемых моделях. 6.4. BPWIN И ERWIN КОМПАНИИ LOGICWORKS LogickWorks выпускает два взаимнодополняющих инструмента проектирования информационных систем: BPWin – функциональное моделирование на основе методологии IDEF0. Допускается также использовние нотации IDEF3 и DFD в нотации Йордона- де Марко. Имеется возможность экспорта построенных моделей в системы функционально-стоимостного анализа (ABC – Activity Based Costing) и информационного моделирования ERWin. ERWin – средство информационного моделирования, используется нотация IDEF1X. Поддерживаются свыше 20 целевых СУБД, имеется возможность генерации прототипов прикладных программ для Visual Basic, Delphi и т.д. 63 6.5. Designer/2000 компании Oracle Данный продукт компании Oracle, возможно, наиболее полно поддерживает все этапы создания приложений обработки данных. Однако, следует оговориться, что, в отличие от других средств, он поддерживает практически одну целевую СУБД – Oracle Server (имеется еще возможность генерации скриптов на ANSI SQL). То же самое касается и средств создания пользовательского интерфейса. Хотя возможна генерация прототипов программ для языков Visual Basic, C, Java, полностью все возможности Designer/2000 реализуются только при использовании его вместе со средством разработки Oracle Developer/2000. В состав Oracle Designer/2000 включены следующие модули: 1. Инструментарий анализа предметной области: – Process Modeler – средство анализа деловой активности организации. Позволяет создать модель структуры организации и привязать к этой модели функции, выполняемые в различных подразделениях, и информационные потоки между функциями. Содержит элементы бизнес-анализа. – Dataflow Diagrammer – в этом инструменте на базе DFD – диаграмм детализуются функции, описаные в Process Modeler. Используется нотация Йордона-де Марко. – Function Hierarchy Diagrammer – этот модуль автоматически выстраивает иерархии функций, определенных в двух предыдущих инструментах, имеется также возможность создавать прототипы функций. – Entity Relationships Diagrammer – инструмент моделирования данных (диаграммы «сущность-связь», которыми оперируют функции, определенные в Dataflow Diagrammer. Используется нотация Баркера). – Matrix Diagrammer – иструмент для исследования связей между функциями и данными. 2. Генераторы структур: – Database Wizard – генерирует реляционные структуры из ERдиаграмм. – Application Wizard – генерирует иерархию программных модулей конечного приложения обработки данных на основе иерархии функций. При этом может одновременно генерироваться несколько взаимосвязанных подсистем для различных подразделений одной организации. Во время генерации автоматически обнаруживаются одинаковые с точки зрения использования информационных объектов функции, которые могут быть объединены в одном модуле. 3. Инструментарий проектирования приложения: – Data Diagrammer – инструмент для доработки реляционных структур данных на основе нотации Баркера. – Module Structure Diagrammer – инструмент для управления структурой программных модулей готового приложения. Здесь определяются типы модулей (меню, экранная форма, отчет) и их иерархии вызовов. 64 – Module Data Diagrammer – средство для проектирования экранного интерфейса программного модуля на основе используемых им данных. Позволяет без программирования весьма гибко управлять внешним видом и поведением генерируемого модуля. 4. Генераторы данных и кода: – Server Generator – генерирует базу данных на основе реляционных моделей. – Генераторы кода – на основе моделей, построенных в Module Data Diagrammer, позволяют создать исходный код для Visual Basic, C, Java а также инструментов среды Oracle Developer/2000 (Oracle Forms, Oracle Reports). В последнем случае возможна циклическая доработка приложения: в сгенерированный прототип приложения в Developer/2000 вносятся изменения, которые видны для Designer/2000 и не теряются при повторной перегенерации. – Preferences Navigator – средство управления предпочтениями при генерации программных модулей. Позволяет устанавливать многочисленные опции (например, внешний вид элементов экранного интерфейса) как для проекта в целом, так и для каждого модуля в отдельности. Также в Oracle Designer/2000 имеется ряд других инструментов: утилита для интерактивного выполнения SQL-запросов, средства управления проектом и т.д. 7. УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML. Язык UML представляет собой общецелевой объектноориентированный язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. UML обеспечивает поддержку всех этапов жизненного цикла ИС. Язык UML преследует следующие цели: 1. Предоставить в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения. 2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области. 3. Описание языка UML должно поддерживать такую спецификацию моделей, которая не зависит от конкретных языков 65 программирования и инструментальных средств проектирования программных систем. 4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП. 5. Поощрять развитие рынка объектных инструментальных средств. 6. Способствовать распространению объектных технологий и соответствующих понятий ООАП. 7. Интегрировать в себя новейшие и наилучшие достижения практики ООАП. В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций (диаграмм). В терминах языка UML определены следующие виды диаграмм:  Диаграмма вариантов использования (use case diagram)  Диаграмма классов (class diagram)  Диаграммы поведения (behavior diagrams) o Диаграмма состояний (statechart diagram) o Диаграмма деятельности (activity diagram) o Диаграммы взаимодействия (interaction diagrams)  Диаграмма последовательности (sequence diagram)  Диаграмма кооперации (collaboration diagram)  Диаграммы реализации (implementation diagrams) o Диаграмма компонентов (component diagram) o Диаграмма развертывания (deployment diagram) Из перечисленных выше диаграмм некоторые служат для обозначения двух и более других подвидов диаграмм. При этом в качестве самостоятельных представлений в языке UML используются следующие диаграммы: 1. Диаграмма вариантов использования (см. главу 4). 2. Диаграмма классов (см. главу 5). 3. Диаграмма состояний (см. главу 6). 4. Диаграмма деятельности (см. главу 7). 5. Диаграмма последовательности (см. главу 8). 6. Диаграмма кооперации (см. главу 9). 7. Диаграмма компонентов (см. главу 10). 8. Диаграмма развертывания (см. главу 11). Эти диаграммы представляют собой неотъемлемую часть графической нотации языка UML. Процесс ООАП неразрывно связан с процессом построения этих диаграмм. При этом совокупность построенных таким образом диаграмм является самодостаточной в том смысле, что в них содержится вся информация, которая необходима для реализации проекта сложной системы. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. При этом 66 диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является, по своей сути, логической моделью, отражающей статические аспекты структурного построения сложной системы. Диаграммы поведения также являются разновидностями логической модели, которые отражают динамические аспекты функционирования сложной системы. И, наконец, диаграммы реализации служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели. Таким образом, интегрированная модель сложной системы в нотации UML представляется в виде совокупности указанных диаграмм. Рис. 3.10. Интегрированная модель сложной системы в нотации UML 7.1 ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (USE CASE DIAGRAM). Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы т.е то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Разработка диаграммы вариантов использования преследует цели:  Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. 67 Сформулировать общие требования к функциональному поведению проектируемой системы.  Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.  Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью, так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Т.е каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами (рис. 4.1).  Рис. 4.1. Графическое обозначение варианта использования Цель варианта использования заключается в том, чтобы определить законченный аспект или фрагмент поведения некоторой сущности без раскрытия внутренней структуры этой сущности. В качестве такой сущности может выступать исходная система или любой другой элемент модели, который обладает собственным поведением, подобно подсистеме или классу в модели системы. Каждый вариант использования соответствует отдельному сервису, который предоставляется системой по запросу пользователя (актера), т. е. определяет способ применения этой сущности. Сервис, который инициализируется по запросу пользователя, представляет собой законченную последовательность действий. Это означает, что после того как система закончит обработку запроса пользователя, она должна возвратиться в исходное состояние, в котором готова к выполнению следующих запросов. Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных 68 целей или решения частных задач. Каждый актер может рассматриваться как некая отдельная роль относительно конкретного варианта использования. Стандартным графическим обозначением актера на диаграммах является фигурка "человечка", под которой записывается конкретное имя актера (рис. 4.2). Рис. 4.2. Графическое обозначение актера Отношения на диаграмме вариантов использования Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов. Один актер может взаимодействовать с несколькими вариантами использования. В этом случае этот актер обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими актерами, предоставляя для всех них свой сервис. Следует заметить, что два варианта использования, определенные для одной и той же сущности, не могут взаимодействовать друг с другом, поскольку каждый из них самостоятельно описывает законченный вариант использования этой сущности. Более того, варианты использования всегда предусматривают некоторые сигналы или сообщения, когда взаимодействуют с актерами за пределами системы. В то же время могут быть определены другие способы для взаимодействия с элементами внутри системы. В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:  Отношение ассоциации (association relationship)  Отношение расширения (extend relationship)  Отношение обобщения (generalization relationship)  Отношение включения (include relationship) При этом общие свойства вариантов использования могут быть представлены тремя различными способами, а именно с помощью отношений расширения, обобщения и включения. Отношение ассоциации служит для обозначения специфической роли актера в отдельном варианте использования. Т.е, это отношение устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом. Один из вариантов использования может быть расширением для нескольких базовых вариантов, а также иметь в качестве собственных расширений несколько 69 других вариантов. Связь типа "расширение" применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Например: Рис. 4.8. Графическое изображение отношения расширения с примечаниями условий выполнения вариантов использования Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется родителем по отношению А, а вариант А — потомком по отношению к варианту использования В. Потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 4.9). Эта линия со стрелкой имеет специальное название — стрелка "обобщение". Рис. 4.9. Пример графического изображения отношения обобщения между вариантами использования Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом "include" ("включает"), как показано на рис. 4.11. 70 В качестве примера рассмотрим процесс моделирования системы продажи товаров по каталогу. Актерами данной системы могут выступать два субъекта, один из которых является продавцом, а другой — покупателем. Каждый из этих актеров взаимодействует с рассматриваемой системой продажи товаров по каталогу и является ее пользователем, т. е. они оба обращаются к сервису "Оформить заказ на покупку товара". Диаграмма вариантов использования будет содержать 5 вариантов использования и 2 актеров между которыми установлены отношения включения и расширения. Данная диаграмма вариантов использования, в свою очередь, может быть детализирована далее с целью более глубокого уточнения предъявляемых к системе требований Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе и возможности согласования полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов использования может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность. Рекомендуемое общее количество актеров в модели — не более 20, а вариантов использования — не более 50. В противном случае модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм. 71 Диаграмма классов (class diagram) Центральное место в ООАП занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Класс Классы — это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой. В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов. Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5.1). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы). Рис. 5.1. Графическое изображение класса на диаграмме классов Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени 72 соответствующего класса (рис. 5.1, а). По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами (рис. 5.1, б) и операциями (рис. 5.1, в). Окончательный вариант диаграммы содержит наиболее полное описание классов, которые состоят из трех разделов. Возможно, наличие четвертого раздела, в котором указываются properties (свойства) Для каждого такого класса генерируется код: public class Student { public Student() { } public int getAge(){ return age; } public void setAge(int age){ this.age = age; } public void goToHome(String adress) { } private int age; protected String adress; private int name; } Имя класса Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов (возможно, одной диаграммой). Оно указывается в первой верхней секции прямоугольника. В дополнение к общему правилу наименования элементов языка UML, имя 73 класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные по практическим соображениям без пробелов. Имена классов образуют словарь предметной области при ООАП. Атрибуты класса Атрибут — это свойство класса, которое может принимать множество значений. Атрибут имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех объектов данного класса. Класс может иметь произвольное количество атрибутов. Во второй сверху секции прямоугольника класса записываются его атрибуты (attributes) или свойства . В языке UML принят определенный стандарт записи атрибутов класса, который подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения: <квантор видимости><имя атрибута>[кратность]: <тип атрибута> = <исходное значение>{строка-свойство} Квантор видимости может принимать одно из трех возможных значений и, соответственно, отображается при помощи специальных символов:  Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.  Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.  Знак "-" обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения. Квантор видимости может быть опущен. В этом случае его отсутствие просто означает, что видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в языках программирования, когда отсутствие квантора видимости трактуется как public, private или «дружественный». Операции (методы) Операция — реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта. Операции или методы класса записываются в третьей сверху секции прямоугольника класса. Операция (operation) в UML представляет собой 74 некоторый сервис, предоставляемый по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения: <квантор видимости><имя операции>(список параметров): <выражение типа возвращаемого значения>{строка-свойство} Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений и, соответственно, отображается при помощи специального символа. Символ "+" обозначает операцию с областью видимости типа общедоступный (public). Символ "#" обозначает операцию с областью видимости типа защищенный (protected). И, наконец, символ "-" используется для обозначения операции с областью видимости типа закрытый (private). Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private. Возможно наличие четвертого раздела В котором содержатся свойства класса. Свойства класса представляют собой атрибуты и методы доступа к ним (get/set методы). Атрибуты при этом имеют спецификатор доступа private, а методы доступа public. Отношения между классами Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями или связями в языке UML являются:  Отношение зависимости (dependency relationship)  Отношение ассоциации (association relationship)  Отношение обобщения (generalization relationship) Отношение зависимости. (dependency relationship) Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели. (то есть например класс использует какой-либо метод другого класса и и соответственно изменения в этом методе на него повлияют, таким образом работа этого класса зависит от реализации метода в другом классе) Часто зависимости показывают, что один класс использует другой в качестве аргумента. (т.е. отношение типа «использует») 75 Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов ("—>" или "<—"). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от классаклиента зависимости к независимому классу или классу-источнику (рис. 5.3). На данном рисунке изображены два класса: Класс_А и Кяасс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А — клиентом этой зависимости. Рис. 5.3. Графическое изображение отношения зависимости на диаграмме классов. В коде отношение зависимости отмечается следующим образом: /** @link dependency */ /* #Db lnkDb; */ Отношение ассоциации (association relationship) Отношение ассоциации — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа ("клиент" может сделать "заказ"). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. (то есть в одном классе создается поле – ссылка на другой) 76 public class Student { … private Db lnkDb; } Специальной формой или частным случаем отношения ассоциации является отношение агрегации. Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. (т.е. отношение типа «имеет») Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой "целое". Остальные классы являются его "частями" (рис. 5.8). Рис. 5.8. Графическое изображение отношения агрегации в языке UML Примером отношения агрегации может служить деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь. Рис. 5.9. Диаграмма классов для иллюстрации отношения агрегации на примере ПК 77 Отношение композиции (частный случай отношения ассоциации) Отношение композиции является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части. (т.е. подклассы описаны внутри самого класса) Возможно, не самый лучший, но наверняка понятный всем пример этого отношения представляет собой живая клетка в биологии. Другой пример — окно интерфейса программы, которое может состоять из строки заголовка, кнопок управления размером, полос прокрутки, главного меню, рабочей области и строки состояния. Нетрудно понять, что подобное окно представляет собой класс, а его компоненты являются как классами, так и атрибутами или свойствами окна. Последнее обстоятельство весьма характерно для отношения композиции, поскольку отражает различные способы представления данного отношения. Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класскомпозицию или "целое". Остальные классы являются его "частями" (рис. 5.10). Рис. 5.10. Графическое изображение отношения композиции в языке UML В качестве дополнительных обозначений для отношений композиции и агрегации могут использоваться дополнительные обозначения, применяемые для отношения ассоциации. А именно, указание кратности класса ассоциации 78 и имени данной ассоциации, которые не являются обязательными. Применительно к описанному выше примеру класса "Окно_программы" его диаграмма классов может иметь следующий вид (рис. 5.11). Рис. 5.11. Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы Отношение обобщения (generalization relationship) Отношение обобщения является обычным отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). (т.е. отношение типа является) Данное отношение может использоваться для представления взаимосвязей между пакетами, классами, вариантами использования и другими элементами языка UML. Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка. На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов (рис. 5.12). Стрелка указывает на более общий класс (класс-предок 79 или суперкласс), а ее отсутствие — на более специальный класс (класспотомок или подкласс). Рис. 5.12. Графическое изображение отношения обобщения в языке UML public class Class2 extends Class1 { } Пример Рис. Отображение связей между классами Диаграммы использования Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом: 80 описывает видимую пользователем функцию,  может представлять различные уровни детализации,  обеспечивает достижение конкретной цели, важной для пользователя. Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актеры, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы. На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: "использование" и "расширение" (рис. 11.4). Связь типа "расширение" применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа "использование" позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания. На рис. 11.4 показано, что при исполнении прецедента "формирование заказа" возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов "оценить риск сделки" и "согласовать цену" необходимо выполнить одно и то же действие — рассчитать стоимость заказа.  Рис. 11.4. Связи на диаграммах прецедентов Динамические аспекты поведения системы отражаются приведенными ниже диаграммами. 81 В отличие от некоторых подходов объектного моделирования, когда и состояние, и поведение системы отображаются на диаграммах классов, UML отделяет описание поведения в диаграммы взаимодействия. В UML диаграммы классов не содержат сообщений, которые усложняют их чтение. Поток сообщений между объектами выносится на диаграммы взаимодействия. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках одного варианта использования. Прямоугольники на диаграмме представляют различные объекты и роли, которые они имеют в системе, а линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения. Существуют два вида диаграмм взаимодействия: диаграммы последовательностей и кооперативные диаграммы. Диаграмма деятельности При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Традиционно для этой цели использовались блок-схемы или структурные схемы алгоритмов. Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. На диаграммах деятельности присутствуют обозначения состояний и переходов. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Состояние действия Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Состояние действия не может иметь внутренних переходов, поскольку оно является элементарным. Графически состояние действия изображается фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис. 7.1). Внутри этой фигуры записывается выражение действия (actionexpression), которое должно быть уникальным в пределах одной диаграммы деятельности. Рис. 7.1. Графическое изображение состояния действия 82 Действие может быть записано на естественном языке, некотором псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Переходы На диаграмме деятельности переход изображается сплошной линией со стрелкой. Если из состояния действия выходит единственный переход, то он может быть никак не помечен. Если же таких переходов несколько, то сработать может только один из них. Именно в этом случае для каждого из таких переходов должно быть явно записано сторожевое условие в прямых скобках. Графически ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста (рис. 7.3). В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Рис. 7.3. Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения 83 Рис. 7.4. Различные варианты ветвлений на диаграмме деятельности В языке UML для обозначения параллельных вычислений используется специальный символ для разделения и слияния параллельных вычислений или потоков управления. Рис. 7.5. Графическое изображение разделения и слияния параллельных потоков управления 84 Рис. 7.6. Диаграмма деятельности для примера с приготовлением напитка Дорожки Применительно к бизнес-процессам желательно выполнение каждого действия ассоциировать с конкретным подразделением компании. В этом случае подразделение несет ответственность за реализацию отдельных действий, а сам бизнес-процесс представляется в виде переходов действий из одного подразделения к другому. Для моделирования этих особенностей в языке UML используется специальная конструкция, получившее название дорожки (swimlanes). При этом все состояния действия на диаграмме деятельности делятся на отдельные группы, которые отделяются друг от друга вертикальными линиями. Две соседние линии и образуют дорожку, а группа состояний 85 между этими линиями выполняется отдельным подразделением (отделом, группой, отделением, филиалом) компании (рис. 7.7). Названия подразделений явно указываются в верхней части дорожки. Рис. 7.8. Фрагмент диаграммы деятельности для торговой компании Объекты В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами. Для графического представления объектов используются прямоугольник класса. 86 Рис. 7.9. Фрагмент диаграммы деятельности торговой компании с объектом-заказом Диаграммы последовательностей Для моделирования взаимодействия объектов во времени в языке UML используются диаграммы последовательности. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. Диаграмма последовательности имеет как бы два измерения. Одно — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графическ и каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия, Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом. 87 Второе измерение диаграммы последовательности — вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 8.1), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона — окончание фокуса управления (окончание активности). Периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта имеются несколько фокусов управления. Получить фокус управления может только существующий объект, у которого в этот момент имеется линия жизни. Если же некоторый объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него лишь может быть создан другой экземпляр этого же класса, который уже будет являться другим объектом. В отдельных случаях инициатором взаимодействия в системе может быть актер или внешний пользователь. В этом случае актер изображается на диаграмме последовательности самым первым объектом слева со своим фокусом управления. Чаще всего актер и его фокус управления будут существовать в системе постоянно, отмечая характерную для пользователя активность в инициировании взаимодействий с системой. При этом актер может иметь собственное имя или оставаться анонимным. Рис. 8.1. Различные графические примитивы диаграммы последовательности 88 Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней. Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены, чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы «X». Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий. Не обязательно создавать все объекты диаграммы в начальный момент времени. Отдельные объекты могут создаваться по мере необходимости, экономя ресурсы системы и повышая ее производительность. В этом случае прямоугольник объекта изображается не в верхней части диаграммы последовательности, а в той части, которая соответствует моменту создания объекта. При этом прямоугольник объекта вертикально располагается в том месте диаграммы, которое по оси времени совпадает с моментом его возникновения в системе. Объект обязательно создается со своей линией жизни и, возможно, с фокусом управления. Каждое взаимодействие между объектами описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. Сообщения не только передают некоторую информацию, но и требуют или предполагают от принимающего объекта выполнения ожидаемых действий. Сообщения могут инициировать выполнение операций объектом соответствующего класса, а параметры этих операций передаются вместе с сообщением. На диаграмме последовательности все сообщения упорядочены по времени своего возникновения в моделируемой системе. Сообщения изображаются горизонтальными стрелками, соединяющими линии жизни или фокусы управления двух объектов на диаграмме последовательности. Возможна посылка сообщения объектом самому себе - самоделегирование. В этом случае линия может начинаться и заканчиваться около символа объекта. Таким образом, в языке UML каждое сообщение ассоциируется с некоторым действием, которое должно быть выполнено принявшим его объектом. При этом действие может иметь некоторые аргументы или параметры, в зависимости от конкретных значений которых может быть 89 получен различный результат. Действие будем ассоциировать с выполнением метода объекта. Сообщения могут быть следующих типов:  Асинхронные Асинхронное сообщение не блокирует работу вызывающего объекта, и он, таким образом, может продолжать свой собственный процесс. Асинхронные сообщения можно использовать для создания нового объекта или для установления связи с уже выполняемой ветвью процесса. Изображается линией с половинкой стрелки на конце.  Вызов процедуры рисуется как заполненная стрелка. Возвращение из процедуры подразумевается неявно и на диаграмме не отображается. Возможно существование дополнительных типов сообщений. Диаграмма компонентов (component diagram) Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления. Полный проект программной системы представляет собой совокупность моделей логического и физического представлений, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются так называемые диаграммы реализации (implementation diagrams), которые включают в себя две отдельные канонические диаграммы: диаграмму компонентов и диаграмму развертывания. 90 Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними. Диаграмма компонентов разрабатывается для следующих целей:  Визуализации общей структуры исходного кода программной системы.  Спецификации исполнимого варианта программной системы.  Обеспечения многократного использования отдельных фрагментов программного кода.  Представления концептуальной и физической схем баз данных. В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие — на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами Компоненты Для представления физических сущностей в языке UML применяется специальный термин — компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. В качестве имен компонентов принято использовать имена исполняемых файлов (с указанием расширения (exe, java, cpp, html, txt) ехе после точки-разделителя), имена динамических библиотек (расширение dll), имена Web-страниц (расширение html), имена текстовых файлов (расширения txt или doc) или файлов справки (hip), имена файлов баз данных (DB) или имена файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение Java для языка Java), скрипты (pi, asp) и др. В языке UML выделяют три вида компонентов.  Во-первых, компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими 91 компонентами могут быть динамически подключаемые библиотеки с расширением dll (рис. 10.2, а), Web-страницы на языке разметки гипертекста с расширением html (рис. 10.2, б) и файлы справки с расширением hlр (рис. 10.2, в).  Во-вторых, рабочие компоненты. Как правило — это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++ (рис. 10.2, г) , java.  В-третьих, компоненты исполнения, представляющие исполнимые модули — файлы с расширением ехе. Они обозначаются обычным образом. Другой способ спецификации различных видов компонентов — явное указание стереотипа компонента перед его именем. В языке UML для компонентов определены следующие стереотипы:  Библиотека (library) — определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки.  Таблица (table) — также определяет первую разновидность компонента, который представляется в форме таблицы базы данных.  Файл (file) — определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ.  Документ (document) — определяет вторую разновидность компонента, который представляется в форме документа.  Исполнимый (executable) — определяет третий вид компонента, который может исполняться в узле. Интерфейсы Следующим элементом диаграммы компонентов являются интерфейсы. В общем случае интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок 92 Зависимости Зависимость служит для представления связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу). Применительно к диаграмме компонентов зависимости могут связывать компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой. Наличие зависимости означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, компонент с именем "main.exe" зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем "image.java". Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов (рис. 10.5). Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. 93 До начала разработки диаграммы компонентов необходимо принять решения о выборе вычислительных платформ и операционных систем, на которых предполагается реализовывать систему, а также о выборе конкретных баз данных и языков программирования. После этого можно приступать к общей структуризации диаграммы компонентов. В первую очередь, необходимо решить, из каких физических частей (файлов) будет состоять программная система. После общей структуризации физического представления системы необходимо дополнить модель интерфейсами и схемами базы данных. При разработке интерфейсов следует обращать внимание на согласование (стыковку) различных частей программной системы. Включение в модель схемы базы данных предполагает спецификацию отдельных таблиц и установление информационных связей между таблицами. Завершающий этап построения диаграммы компонентов связан с установлением и нанесением на диаграмму взаимосвязей между компонентами, а также отношений реализации. Диаграмма компонентов, как правило, разрабатывается совместно с диаграммой развертывания, на которой представляется информация о физическом размещении компонентов программной системы по ее отдельным узлам. Диаграмма развертывания (deployment diagram) Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Во-первых, сложные программные системы могут реализовываться в сетевом варианте на различных вычислительных платформах и технологиях доступа к распределенным базам данных. 94 Во-вторых, интеграция программной системы с Интернетом определяет необходимость решения дополнительных вопросов при проектировании системы, таких как обеспечение безопасности, криптозащищенности и устойчивости доступа к информации для корпоративных клиентов. Кроме того, технологии доступа и манипулирования данными в рамках общей схемы "клиент-сервер" также требуют размещения больших баз данных в различных сегментах корпоративной сети, их резервного копирования, архивирования, кэширования для обеспечения необходимой производительности системы в целом Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели. Итак, перечислим цели, преследуемые при разработке диаграммы развертывания:  Определить распределение компонентов системы по ее физическим узлам.  Показать физические связи между всеми узлами реализации системы на этапе ее исполнения. Узел Узел (node) представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. В качестве узла может выступать не только вычислительные устройства (процессоры), но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы. Графически на диаграмме развертывания узел изображается в форме трехмерного куба. Узел имеет собственное имя, которое указывается внутри этого графического символа. 95 Если необходимо явно указать компоненты, которые размещаются на отдельном узле, то это можно сделать двумя способами. Первый из них позволяет разделить графический символ узла на две секции горизонтальной линией. В верхней секции записывают имя узла, а в нижней секции — размещенные на этом узле компоненты (рис. 11.3, а). Второй способ разрешает показывать на диаграмме развертывания узлы с вложенными изображениями компонентов (рис. 11.3, б). Важно помнить, что в качестве таких вложенных компонентов могут выступать только исполняемые компоненты. Соединения Кроме собственно изображений узлов на диаграмме развертывания указываются отношения между ними. В качестве отношений выступают физические соединения между узлами и зависимости между узлами и компонентами, изображения которых тоже могут присутствовать на диаграммах развертывания. Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок. Кроме соединений на диаграмме развертывания могут присутствовать отношения зависимости между узлом и развернутыми на нем компонентами. Подобный способ является альтернативой вложенному изображению компонентов внутри символа узла, что не всегда удобно, поскольку делает этот символ излишне объемным. Диаграмма развертывания с отношениями зависимости между узлом и развернутыми на нем компонентами: 96 Пример диаграммы развертывания для системы удаленного обслуживания клиентов банка: На этой диаграмме развертывания указана зависимость компонента реализации диалога "dialog.exe" на удаленном терминале от интерфейса IAuthorise, реализованного компонентом "main.exe", который, в свою очередь, развернут на анонимном узле-экземпляре "Сервер банка". Компонент "main.exe" зависит от компонента базы данных "Клиенты банка", который развернут на этом же узле. Разработка диаграммы развертывания начинается с идентификации всех аппаратных, механических и других типов устройств, которые необходимы для выполнения системой всех своих функций. В первую очередь специфицируются вычислительные узлы системы, обладающие памятью и/или процессором. Дальнейшее построение диаграммы развертывания связано с размещением всех исполняемых компонентов диаграммы по узлам системы. При разработке простых программ, которые исполняются локально на одном компьютере, необходимость в диаграмме развертывания может вообще отсутствовать. 97