Проектирование информационных систем

Лекции по дисциплине «Проектирование информационных систем», 2 семестр ГЛАВА 1. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД 1.1 Сущность объектно-ориентированного подхода Принципиальное различие между структурным и объектноориентированным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются: Абстрагирование (abstraction) – это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относительно дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования. Инкапсуляция (encapsulation) – это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого класса, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта, а инкапсуляция (или, иначе, ограничение доступа) не позволяет объектам-пользователям различать внутреннее устройство объекта. Модульность (modularity) – это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями. Иерархия (hierarchy) – это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов - агрегация. Кроме основных имеются еще три дополнительных элемента, не являю- щихся в отличие от основных строго обязательными: Типизация (typing) – это ограничение, накладываемое на класс объектов и препятствующее взаимозаменяемости различных классов (или сильно сужающее ее возможность). Типизация позволяет защититься от использования объектов одного класса вместо другого или по крайней мере управлять таким использованием. Параллелизм (concurrency) – свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой. Устойчивость (persistence) – свойство объекта существовать во времени (вне зависимости от процесса, породившего данный объект) и/или в пространстве (при перемещении объекта из адресного пространства, в котором он был создан). Основные понятия объектно-ориентированного подхода – объект и класс. Объект определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины "экземпляр класса" и "объект" являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот Относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность – это свойства объекта, отличающие его от всех других объектов. Определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию называется операцией. Как правило, в объектных и объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и являются составной частью определения класса. Класс – это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Определение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизма может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Объектно-ориентированная система изначально строится с учетом ее эволюции. Наследование и полиморфизм обеспечивают возможность определения новой функциональности классов с помощью создания производных классов – потомков базовых классов. Потомки наследуют характеристики родительских классов без изменения их первоначального описания и добавляют 2 при необходимости собственные структуры данных и методы. Определение производных классов, при котором задаются только различия или уточнения, в огромной степени экономит время и усилия при производстве и использовании спецификаций и программного кода. Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой системы от стадии формирования требований до стадии реализации. Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки; Модели ранних стадий могут быть непосредственно подвергнуты сравнению с моделями реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы. 1.2 Унифицированный язык моделирования UML Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. Унифицированный язык моделирования UML (Unified Modeling Language) - это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же, в 1995 г., к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели: − предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими; − предусмотреть механизмы расширяемости и специализации для расширения базовых концепций; − обеспечить независимость от конкретных языков программирования и процессов разработки; − обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма); − стимулировать рост рынка объектно-ориентированных инструменталь3 ных средств; − интегрировать лучший практический опыт. Стандарт UML предлагает следующий набор диаграмм для моделирования: − диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации (требований к системе); − диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними; − диаграммы поведения системы (behavior diagrams); − диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия: o диаграммы последовательности (sequence diagrams); o кооперативные диаграммы (collaboration diagrams); − диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое; − диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей; − диаграммы реализации (implementation diagrams): − диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы; диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы. Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML. При этом диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является, по своей сути, логической моделью, отражающей статические аспекты структурного построения сложной системы. Диаграммы поведения также являются разновидностями логической модели, которые отражают динамические аспекты функционирования сложной системы. И, наконец, диаграммы реализации служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели (Рисунок 1). 4 Диаграммы компонентов Диаграммы вариантов использования Диаграммы развертывания Диаграммы классов Диаграммы состояний Диаграммы деятельностей Диаграммы последовательности Диаграммы коопераций Рисунок 1. Интегрированная модель сложной системы в нотации UML 1.3 Диаграммы вариантов использования Диаграммы вариантов использования описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Основные графические примитивы представлены в Рисунок 2. Конкретная цель диаграмм вариантов использования – это документирование вариантов использования (все, входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними. Разрабатывая диаграммы вариантов использования, придерживаются следующих правил: − между действующими лицами связи не моделируют. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции; − не соединяют стрелкой два варианта использования непосредственно. Диаграмма данного типа описывает только, какие варианты использования доступны системе, а не порядок их выполнения; − каждый вариант использования должен быть инициирован актером. Это означает, что всегда имеется стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. 5 Рисунок 2. Графические примитивы диаграммы вариантов использования Обозначение Оформить договор Название Актер, действующее лицо Вариант использования Отношение ассоциации Отношение включения «include» Отношение расширения «extend» Отношение обобщения Описание Роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Действующие лица делятся на три основных типа пользователи системы, другие системы, взаимодействующие с данной. Последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Служит для обозначения специфической роли актера в отдельном варианте использования Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования (отношение определяется стрелкой от включающего к включаемому) Определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров (отношение определяется стрелкой от расширяющего к расширяемому) Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В (отношение определяется стрелкой от потомка к предку) На диаграмме вариантов использования показывается взаимодействие между вариантами использования и действующими лицами. Таким образом, варианты использования - это функции, выполняемые системой, а действующие лица - это заинтересованные лица по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необ6 ходимо реагировать, помогает идентифицировать варианты использования. Варианты использования применяются для получения обобщенного представления о том, что должна будет делать система. Для того чтобы фактически разработать систему, потребуются более конкретные детали. Эта детали описываются в документе, называемом «поток событий» (flow of events). Этот документ подробно описывает, что будут делать пользователи системы и что сама система. Цель - описать то, что будет делать система, а не как она будет делать это. Обычно поток событий включает: − краткое описание; − предусловия (pre-conditions); − основной поток событий; − альтернативный поток событий; − постусловия (post-conditions). Варианты использования являются необходимым средством на стадии формирования требований к ПО. Краткое описание Каждый вариант использования должен иметь краткое описание того, что он будет делать. Например, вариант использования «Осуществить прием пациента» может содержать следующее описание: Вариант использования «Осуществить прием пациента» позволяет врачу поставить диагноз осматриваемому пациенту, определить и назначить лечение, выписать в случае необходимости рецепт и/или листок по потере трудоспособности; медсестре занести информацию приема в личную карточку пациента; пациенту посетить в назначенное время врача. Предусловия Предусловия варианта использования - это такие условия, которые должны быть выполнены, прежде чем вариант использования начнет выполняться сам. Например, таким условием может быть выполнение другого варианта использования или наличие у пользователя прав доступа, требуемых для запуска данного. Не у всех вариантов использования бывают предусловия. С помощью предусловий можно документировать порядок выполнения диаграмм использования. Так, предусловием одного варианта использования может быть то, что в это время должен выполняться другой. Предусловием варианта использования «Осуществить прием пациента» является выполнение вариантов использования «Оформить карточку пациента», «Зарегистрировать страховой полис» и «Оформить талон на прием к врачу». 7 8 Рисунок 3. Диаграмма вариантов использования «Поликлиники» Основной и альтернативный потоки событий Конкретные детали вариантов использования описываются в основном и альтернативных потоках событий. Поток событий поэтапно описывает, что должно происходить во время выполнения заложенной в варианты использования функциональности. Поток событий уделяет внимание тому, что будет делать система, а не как она будет делать это, причем описывает все это с точки зрения пользователя. Основной и альтернативный потоки событий включают следующее описание: − − − − каким образом запускается вариант использования; различные пути выполнения варианта использования; нормальный, или основной, поток событий варианта использования; отклонения от основного потока событий (так называемые альтернативные потоки); − потоки ошибок; − каким образом завершается вариант использования. Например, поток событий варианта использования «Осуществить прием пациента» может выглядеть следующим образом: Основной поток 1. Вариант использования начинается, когда пациент приходит на прием к врачу. 2. Пациент должен передать врачу талон на прием. Если талон отсутствует, то выполняется альтернативный поток событий А1. 3. Врач уточняет у пациента, является ли прием первым. Если прием повторный, то врач просматривает результаты проведенных анализов. 4. Врач выслушивает жалобы пациента. 5. Врач/медсестра вносит сведения в личную карточку пациента. 6. Полученных сведений достаточно для постановки диагноза. Если информации недостаточно, то альтернативный поток событий А2. 7. Врач ставит диагноз пациенту. 8. Врач определяет вид лечения для пациента. 9. Врач назначает лекарство пациенту. Если на лекарство требуется рецепт, то выполняется альтернативный поток событий А3. 10.Врач уточняет необходимость открытия листка потери трудоспособности. Если такая необходимость существует, то выполняется альтернативный поток событий А4. 11.Вариант использования завершается. Альтернативный поток А1. Пациент не оформил талон на прием к врачу 9 1. Врач информирует пациента о том, что обязательным условием посещения врача является наличие талона амбулаторного пациента, оформляемого в регистратуре. 2. Врач возвращает пациенту медицинскую карточку. 3. Вариант использования завершается. Альтернативный поток А2. Информации для постановки диагноза недостаточно 1. Врач выписывает направления на анализы. 2. Медицинская карточка пациента остается у лечащего врача. 3. Вариант использования завершается. Альтернативный поток А3. Требуется рецепт на лекарство 1. На специальном бланке за подписью и печатью врача, с указанием даты, выписывается рецепт на требуемое лекарство. 2. Вариант использования завершается. Альтернативный поток A4. Врач открывает листок по потере трудоспособности 1. На бланке строгой отчетности врач указывает дату открытия документа. 2. На основании поставленного диагноза определяется срок потери трудоспособности. 3. Листок потери трудоспособности регистрируется в регистратуре. 4. Вариант использования завершается. Постусловия Постусловиями называются такие условия, которые, если они существуют в потоке событий, всегда должны быть выполнены после завершения варианта использования. Например, в конце варианта использования можно пометить флажком какой-нибудь переключатель. Информация такого типа вводит в состав постусловий. Как и для предусловий, с помощью постусловий можно вводить информацию о порядке выполнения вариантов использования системы. Если, например, после одного из вариантов использования должен всегда выполняться другой, это можно описать как постусловие. Такие условия имеются не у каждого варианта использования. Постусловием варианта использования «Осуществить прием пациента» является выполнение варианта использования «Пройти назначенное лечение». 10 1.4 Диаграммы классов Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами (Рисунок 4). На данной диаграмме не указывается информация о временных аспектах функционирования системы. Рисунок 4. Графические примитивы диаграммы классов Обозначение Название Класс Описание Служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Описание класса состоит в определении атрибутов (свойств) и методов (операций или сервисов) Отношение зависимости Указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, выраженное в том, что некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели Соответствует наличию некоторого отношения между классами Отношение ассоциации Отношение агрегации Отношение композиции Отношение обобщения Частный случай ассоциации. Имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. Частный случай ассоциации. Служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части. Является отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). Данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. 11 Диаграмма классов предметной области «Поликлиника» показана на рисунке 5. Рисунок 5. Диаграмма классов предметной области «Поликлиника» Класс «Пациенты» предназначен для хранения в нем информации о пациентах, прикрепленных к поликлинике. В нижней части класса содержатся операции, выполняемые над его объектами (атрибутами), в данном случае - над сведениями о пациентах. Класс «Врачи» содержит информацию о врачах поликлиники. В классе «Лечение» содержатся сведения о лечении каждого конкретного пациента. Классы «Вид лечения» и «Тип врача» имеют стереотип «Enumeration» (перечисление). Класс «Отделения» служит для хранения в нем справочной информации об отделениях поликлиники. Класс «Участок» предназначен для хранения в нем справочной информации об участках города, об12 служиваемых поликлиникой. Классы «Больничные листы», «Талоны» и «Рецепты» связаны связью агрегации с классом «Прием пациентов». Класс «Тумба» является граничным классом. Класс «Платные услуги» является дочерним класса «Услуги». 1.5 Диаграммы состояний Диаграммы состояний определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. Таким образом, диаграмма состояний используется для моделирования поведения объектов системы при переходе из одного состояния в другое. В отличие от других диаграмм диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее – одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Основные графические примитивы представлены в Рисунок 6. Рисунок 6. Графические примитивы диаграммы состояний Обозначение Название Состояние Начальное состояние Конечное состояние Переход Событие [Сторожевое условие] Описание Абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние определяется именем и списком внутренних действий (деятельностей), которые выполняются в процессе нахождения моделируемого элемента в данном состоянии и характеризуются меткой действия (entry, exit, do, include). Частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояний). В этом состоянии находится объект по умолчанию в начальный момент времени. Частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояний). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени Отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии По своему назначению диаграмма состояний не является обязательным представлением в модели. Наличие у системы нескольких состояний, отличающихся от простой дихотомии "исправен - неисправен", "активен - неакти13 вен", "ожидание - реакция на внешние действия", уже служит признаком необходимости построения диаграммы состояний. На Рисунок 7 показана диаграмма состояний для класса «Врач». На Рисунок 8 приводится пример диаграммы состояний для пациента, на которой можно наблюдать процесс перехода пациента из одного состояния в другое. Рисунок 7. Диаграмма состояний для класса «Врач» Рисунок 8. Диаграмма состояний для класса «Пациент» На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). На диаграмме состояний может быть одно и только одно начальное состояние. В тоже время может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии; могут выполняться различные процессы. Процессы, происходящие в момент, когда объект находится в определенном со14 стоянии, называются действиями (actions). Заключенное в квадратных скобках условие (сторожевое условие, guard condition) определяет, когда может произойти переход из одного состояния в другое. 1.6 Диаграммы деятельностей Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому. Основные графические примитивы представлены в Рисунок 9. Рисунок 9. Графические примитивы диаграммы деятельностей Обозначение Название Действие Начальное состояние Конечное состояние Ветвление Разделение и слияние Переход Описание Является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом. Частный случай состояния, в этом состоянии находится объект по умолчанию в начальный момент времени. Частный случай состояния, в этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени. Встречается, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. Используется для описания условных переходов. Используются для разделения и слияния параллельных вычислений или потоков управления. Используются только нетриггерные переходы, т. е. такие, которые срабатывают сразу после завершения деятельности или выполнения соответствующего действия. Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. На Рисунок 10 представлена диаграмма деятельностей для сотрудника регистратуры. Деятельность сотрудника начинается, когда пациент впервые приходит в поликлинику для прохождения медицинского обслуживания. Пациент обращается в регистратуру. Сотрудник регистратуры уточняет, зарегистриро15 ван ли пациент в поликлинике. Если нет, то необходимо оформить пациенту новый бланк и внести в него паспортные сведения и данные страхового полиса. Затем сотрудник регистратуры по адресу прописки гражданина определяет номер участка пациента, тем самым, прикрепляя его за определенными врачами. Деятельность регистратора по оформлению пациента на прием к врачу начинается, когда пациент обращается в регистратуру с просьбой о приеме у определенного специалиста. Регистратор определяет время работы нужного врача. Затем формирует пациенту талон амбулаторного больного. На этом деятельность завершается. Рисунок 10. Диаграмма деятельностей сотрудника регистратуры Диаграммы деятельностей предпочтительнее использовать в следующих ситуациях: − анализ варианта использования. На этой стадии нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия; 16 − анализ потоков работ в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения. 1.7 Диаграммы взаимодействия Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Во-первых, взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Во-вторых, можно рассматривать структурные особенности взаимодействия объектов. Для представления структурных особенностей передачи и приема сообщений между объектами используется диаграмма кооперации. 3.7.1 Диаграммы последовательности Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Диаграмма последовательности применяется для рассмотрения взаимодействия объектов во времени. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Основные графические примитивы представлены в Рисунок 11. Рисунок 11. Графические примитивы диаграммы последовательности Обозначение Название Объект Описание Предмет или явление, имеющие четко определяемое поведение Линия жизни объекта Служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях 17 Обозначение Название Фокус управления Описание В процессе функционирования одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, применяется фокус управления Сообщение Представляет собой законченный фрагмент информации, который отправляется одним объектом другому. При этом прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Можно показать самоделегирование – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни. Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы Символ разрушения объекта Построение диаграммы последовательности целесообразно начинать с выделения из всей совокупности тех и только тех классов, объекты которых участвуют в моделируемом взаимодействии. После этого все объекты наносятся на диаграмму с соблюдением некоторого порядка инициализации сообщений. Здесь необходимо установить, какие объекты будут существовать постоянно, а какие временно - только на период выполнения ими требуемых действий. Рисунок 12. Фрагмент диаграммы последовательности 3.7.2 Кооперативные диаграммы Кооперативные диаграммы отображают поток событий через конкретный сценарий варианта использования и заостряют внимание на связях между объектами. В отличие от диаграммы последовательности, на диаграмме коопера18 ции изображаются только отношения между объектами, играющими определенные роли во взаимодействии. С другой стороны, на этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров. Следовательно, если необходимо явно специфицировать взаимосвязи между объектами в реальном времени, лучше это делать на диаграмме последовательности. Рисунок 13. Структура взаимодействия объектов системы Кооперация может быть представлена на двух уровнях: − Диаграмма кооперации уровня спецификации показывает роли, которые играют участвующие во взаимодействии элементы. Элементами кооперации на этом уровне являются классы и ассоциации, которые обозначают отдельные роли классификаторов и ассоциации между участниками кооперации. − Диаграмма кооперации уровня примеров представляется совокупностью объектов (экземпляры классов) и связей (экземпляры ассоциаций). При этом связи дополняются стрелками сообщений. На данном уровне показываются только релевантные объекты 1.8 Диаграммы компонентов Диаграммы компонентов показывают, как выглядит модель на физическом уровне. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Диаграмма компонентов разрабатывается для следующих целей: − визуализации общей структуры исходного кода программной системы; − спецификации исполнимого варианта программной системы; 19 − обеспечения многократного использования отдельных фрагментов программного кода; − представления концептуальной и физической схем баз данных. Основные графические примитивы представлены в Рисунок 14. Рисунок 14. Графические примитивы диаграммы компонентов Обозначение ISensor Название Описание Компоненты Реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели Интерфейс Служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры Зависимость Не является ассоциацией, а служит для представления только факта наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Отношение зависимости на диаграмме компонентов изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к источнику (независимому элементу) Разработка диаграммы компонентов предполагает использование информации как о логическом представлении модели системы, так и об особенностях ее физической реализации. До начала разработки необходимо принять решения о выборе вычислительных платформ и операционных систем, на которых предполагается реализовывать систему, а также о выборе конкретных баз данных и языков программирования. После этого можно приступать к общей структуризации диаграммы компонентов. В первую очередь, необходимо решить, из каких физических частей (файлов) будет состоять программная система. После общей структуризации физического представления системы необходимо дополнить модель интерфейсами и схемами базы данных. При разработке интерфейсов следует обращать внимание на согласование (стыковку) различных частей программной системы. Включение в модель схемы базы данных предполагает спецификацию отдельных таблиц и установление информационных связей между таблицами. Наконец, завершающий этап построения диаграммы компонентов связан с установлением и нанесением на диаграмму взаимосвязей между компонентами, а также отношений реализации. Эти отношения должны иллюстрировать все важнейшие аспекты физической реализации системы. На Рисунок 15 изображен пример диаграммы компонентов для поликлиники. В данном случае, в зависимости от роли пользователя осуществляется вы20 зов одной из подсистем: АРМ сотрудника регистратуры или АРМ врача. Сотрудник регистратуры работает с подсистемой, обрабатывающей информацию из двух баз данных: БД врачей и БД услуг. Кроме того, на диаграмме показано, что терминал для выписывания талонов на прием является интерфейсом. Рисунок 15. Диаграмма компонентов 1.9 Диаграммы размещения Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она показывает размещение объектов и компонентов в распределенной системе. Применяется для представления общей конфигурации и топологии распределенной программной системы и содержит распределение компонентов по отдельным узлам системы. Кроме того, диаграмма развертывания показывает наличие физических соединений - маршрутов передачи информации между аппаратными устройствами, задействованными в реализации системы. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются. Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отли21 чие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Основные графические примитивы представлены в Рисунок 16. Рисунок 16. Графические примитивы диаграммы развертывания Обозначение Название Узел Описание Некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом Соединение Является разновидностью ассоциации. Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением Диаграмма размещения для информационной системы поликлиники показана на Рисунок 17. В нашем примере система поликлиники состоит из АРМ сотрудника регистратуры, АРМ врачей и терминала для выписки талонов на посещение, то есть из отдельных физических устройств, или узлов (node). Рисунок 17. Диаграмма размещения для системы «Поликлиника» 1.10 Сопоставление и взаимосвязь структурного и объектноориентированного подходов У большинства людей понятие "проектирование" ассоциируется со структурным проектированием по методу "сверху-вниз" на основе функциональной декомпозиции, согласно которой вся система в целом представляется как одна большая функция и разбивается на подфункции, которые, в свою оче22 редь, разбиваются на подфункции и т.д. Эти функции подобны вариантам использования в объектно-ориентированной системе, которые соответствуют действиям, выполняемым системой в целом. Главный недостаток структурного подхода заключается в следующем: процессы и данные существуют отдельно друг от друга (как в модели деятельности организации, так и в модели программной системы), причем проектирование ведется от процессов к данным. Таким образом, помимо функциональной декомпозиции, существует также структура данных, находящая на втором плане. В объектно-ориентированном подходе основная категория объектной модели - класс - объединяет в себе на элементарном уровне как данные, так и операции, которые над ними выполняются (методы). Именно с этой точки зрения изменения, связанные с переходом от структурного к объектноориентированному подходу, являются наиболее заметными. Разделение процессов и данных преодолено, однако остается проблема преодоления сложности системы, которая решается путем использования механизма компонентов. Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, так как их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований. Буч отмечает также ориентированного подхода: ряд следующих преимуществ объектно- 1. Объектная декомпозиция дает возможность создавать программные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что в конце концов ведет к созданию среды разработки и переходу к сборочному созданию ПО. Системы зачастую получаются более компактными, чем их структурные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования предыдущих разработок. 2. Объектная декомпозиция уменьшает риск создания сложных систем ПО, так как она предполагает эволюционный путь развития системы на базе относительно небольших подсистем. Процесс интеграции системы растягивается на все время разработки, а не превращается в единовременное событие. 23 3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию 4. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования. К недостаткам объектно-ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан с преодолением психологических трудностей, так и с дополнительными финансовыми затратами. При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть и расходы на обучение (овладение методом, инструментальными средствами и языком программирования). Для некоторых предприятий эти обстоятельства могут стать серьезными препятствиями. Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области. Переход организации на объектноориентированную технологию - это смена мировоззрения, а не просто изучение новых case- средств и языков программирования. Таким образом, структурный подход по-прежнему сохраняет свою значимость и достаточно широко используется на практике. В конкретном проекте декомпозировать сложную систему одновременно двумя способами невозможно. Можно начать декомпозицию каким-либо одним способом, а потом, используя полученные результаты, попытаться рассмотреть систему с другой точки зрения. Теперь перейдем к рассмотрению взаимосвязи между структурным и объектно-ориентированным подходом. Основой взаимосвязи является общность ряда категорий и понятий обоих подходов (процесс и вариант использования, сущность и класс и т.д.) эта взаимосвязь может проявляться в различных формах. Так, одним из возможных подходов является использование структурного анализа как основы для объектно-ориентированного проектирования. Такой подход целесообразен ввиду широкого распространения Case-средств, поддерживающих структурный анализа. его можно считать слишком прагматическим, но в некоторых ситуациях иной подход невозможен. При этом структурный анализ следует прекращать, как только диаграммы потоков данных начнут отражать не только деятельность организации (предметную область), а и систему ПО. 24 После выполнения структурного анализа и построения диаграмм потоков данных вместе со структурами данных и другими продуктами анализа можно различными способами приступить к определению классов и объектов. Так, если взять какую-либо отдельную диаграмму, то кандидатами в объекты могут быть внешние сущности и накопители данных, а кандидатами в классы - потоки данных. Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных БД и хранилищ данных. Причины этого очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектнореляционных системах. Объектно-ориентированное проектирование имеет точки соприкосновения с реляционным проектированием. Например, как было отмечено выше, классы в объектной модели могут некоторым образом соответствовать сущностям. Как правило, такое соответствие имеет место только на ранней стадии разработки системы - стадии формирования требований. В дальнейшем, разумеется, цели объектно-ориентированного проектирования (адекватное моделирование предметной области в терминах взаимодействия объектов) и разработки реляционной БД (нормализации данных) расходятся. Таким образом, единственно возможным средством преодоления данного разрыва является построение отображения между объектно-ориентированной и реляционной технологиями, которое в основном сводится к отображению между диаграммами классов и реляционной моделью. 25 ГЛАВА 2. CASE-СРЕДСТВА 2.1 Понятие case-средства Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Следовательно, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Такими образом, CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимосвязанных средств автоматизации, которые позволяют в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС. Наибольшая потребность в использовании CASEсистем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ИС. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки. Основная цель CASE состоит в том, чтобы отделить начальные этапы (анализ и проектирование) от последующих этапов разработки, а также не обременять разработчиков всеми деталями среды разработки и функционирования системы. Чем больший объем работ будет вынесен на этапы анализа и проектирования, тем лучше. Помимо автоматизации методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE обладают следующими основными достоинствами − улучшают качество создаваемой системы за счет средств автоматического контроля (прежде всего контроля проекта); 26 − позволяют за короткое время создавать прототип будущей системы, что позволяет на ранних этапах оценить ожидаемый результат; − ускоряют процесс проектирования и разработки; − освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки; − поддерживают развитие и сопровождение разработки; − поддерживают технологии повторного использования компонент разработки. Ниже кратко характеризуются основные функциональные возможности CASE-средств. 1) Общий графический язык. CASE снабжает всех участников проекта (в том числе и заказчиков) общим языком, наглядным, строгим и интуитивно понятным. Это позволяет вовлекать заказчика в процесс разработки, общаться с экспертами предметной области, защищать проект перед руководством, разделить деятельность системных аналитиков, проектировщиков и программистов, а также обеспечивает легкость сопровождения и внесения изменений в целевую систему. 2) Общая БД проекта. Основа CASE - использование БД проекта (репозитария) для хранения всей информации о проекте, которая может разделяться между разработчиками в соответствии с их правами доступа. Содержимое репозитария включает не только объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонент. Репозитарий может хранить свыше 100 типов объектов, примерами которых являются диаграммы, определения экранов и меню, проекты отчетов, описания данных, логика обработки, модели данных, модели предприятия, модели обработки, исходные коды, элементы данных и т.п. Каждый информационный объект в репозитарии описывается перечислением его свойств: идентификатор, имена-синонимы, тип, текстовое описание, компоненты, файл-хранилище, область значений. 3) Интеграция средств. На основе репозитария осуществляются интеграция CASE-средств и разделение системной информации между разработчиками. При этом возможности репозитария обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представлений фаз ЖЦ, передачу данных и средств между аппаратурными платформами. 4) Поддержка коллективной разработки и управления проектом. CASE поддерживает групповую работу над проектом за счет средств работы в сети, экспорта-импорта любых фрагментов проекта для развития и/или модификации, а также планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов. Эти функции также реализуются на основе репозитария. 27 5) Прототипирование. CASE позволяет строить быстрые прототипы системы, что позволяет на ранних этапах разработки оценить, насколько будущая система устраивает заказчика и насколько дружественна она будущему пользователю. Соответствующие средства используются для определения системных требований и ответа на вопросы об ожидаемом поведении системы. Созданные таким образом прототипы позволяют определять, является ли проектируемая система полной и корректной. 6) Генерация документации. Вся документация по проекту генерируется автоматически на базе репозитария. Несомненное достоинство CASE заключается в том, что документация всегда соответствует текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитарии. 7) Верификация проекта. CASE обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом. 8) Автоматическая кодогенерация. Кодогенерация осуществляется на основе репозитария и позволяет автоматически построить до 80-90% объектных кодов или текстов программ на языках высокого уровня. 9) Сопровождение и реинжиниринг. Сопровождение системы в рамках CASE характеризуется тем, что сопровождается проект, а не программные коды. Средства реинжиниринга и реверсного инжиниринга позволяют продуцировать схемы системы из ее кодов и интегрировать полученные схемы в проект, автоматически обновлять документацию при изменении кодов, автоматически изменять спецификации при редактировании кодов и т.п. 2.2 Классификация case-средств Современные CASE-системы классифицируются по следующим признакам: 1) по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексноориентированные (набор методологий проектирования); 2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями; 3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием); 4) по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа; 5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов; 28 6) по типу операционной системы (ОС): работающие под управлением WINDOWS; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNDO, OS/2 и др.). 2.3 Содержание RAD-технологии прототипного создания приложений Rapid Application Development (RAD, быстрая разработка приложений) – это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях – обследование организации, выработка требований к системе. Причины популярности RAD вытекают из тех преимуществ, которые обеспечивает эта технология. Наиболее существенными из них являются: − высокая скорость разработки; − низкая стоимость; − высокое качество. Последнее из указанных свойств подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учетом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается. Применение технологии RAD целесообразно, когда: − требуется выполнение проекта в сжатые сроки (90 дней). Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то весьма высока вероятность, что за это время существенно изменятся фундаментальные положения, регламентирующие деятельность организации, то есть, система морально устареет еще до завершения ее проектирования. − нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения. − проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD группами в короткие сроки, что обеспечивает минимум 29 трудозатрат и позволяет вписаться в бюджетные ограничения. − интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта. − проект большой, но поддается разделению на более мелкие функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы ее можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD групп). − ПО не обладает большой вычислительной сложностью. RAD-технология не является универсальной, то есть ее применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик. Принципы RAD технологии направлены на обеспечение трех основных ее преимуществ – высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному. Главная идея RAD технологии состоит в том, чтобы как можно быстрее донести до заказчика результаты разработки, пусть и не в полном виде. Например, реализация только пользовательского интерфейса и предъявление его заказчику позволяет уже на ранней стадии разработки получить замечания по экранным и отчетным формам и внести необходимые коррективы. В этом случае значительно возрастает вероятность успеха проекта, то есть возникает уверенность в том, что конечный продукт будет делать именно то, что ожидает заказчик. Кроме того, не следует забывать и тот факт, что разница стоимости ошибки определения требований в начале проекта и в конце равна 1:200. Основные принципы RAD можно сформулировать следующим образом: − Работа ведется группами. Типичный состав группы – руководитель, аналитик, два программиста, технический писатель. Если проект сложный, то для него может быть выделено несколько RAD-групп. Разработка проекта выполняется в условиях тесного взаимодействия между разработчиками и Заказчиком. − Разработка базируется на моделях. Моделирование позволяет оценить проект и выполнить его декомпозицию на составные части, каждая из которых может разрабатываться отдельной RAD-группой. − Итерационное прототипирование. Разработка системы и предъявление ее заказчику осуществляется в виде последовательности развиваемых прототи30 пов. Любой из прототипов реализует определенную часть функциональности, требуемой от конечного продукта. При этом каждый последующий прототип включает всю функциональность, реализованную в предыдущем прототипе, с добавлением новой. Число прототипов определяется на основе учета разных параметров – размера проекта, анализа рисков, пожеланий заказчика и т. д. Традиционно для проектов ПО средней сложности разрабатываются три прототипа. Первый содержит весь пользовательский интерфейс с нулевой функциональностью. Он дает возможность собрать замечания заказчика и после их устранения утвердить у него экранные и отчетные формы. Второй прототип содержит реализованную на 70-80% функциональность системы, третий – полностью реализованную функциональность. Основаниями для очередной итерации являются: 1) Замечания заказчика. Привлечение заказчика и конечного пользователя к оценке выходных результатов прототипа с эффективной обратной связью с командой разработчиков является гарантией того, что созданная система будет делать то, что требуется заказчику. Если замечания носят характер исправлений, они учитываются в следующем прототипе, если же изменяются требования, то выполняется переоценка проекта и корректируются сроки и стоимость проекта. 2) Детализация. Выполняется программирование нереализованной части системы в соответствии с составленным планом. 3) Анализ результатов программирования. Исправляются ошибки, повышается эффективность программного кода и т. д. − RAD группа всегда работает только над одним прототипом. Это обеспечивает единство целей, лучшую наблюдаемость и управляемость процессом разработки, что в итоге повышает качество конечного продукта. Соответственно используемые инструментальные средства должны обеспечивать групповую разработку и конфигурационное управление проектом. − Если проект сложный, то для него может быть выделено несколько RAD групп. Большие системы разбиваются на подсистемы. Каждая подсистема разрабатывается независимой группой. Ключ успеха – правильное разбиение системы на подсистемы. Команды должны использовать общие стандарты. Обязательно финальное тестирование полной системы. − Обязательное использование инструментальных средств, автоматизирующих процесс разработки, и методик их использования, следствием чего является сокращение сроков разработки и повышение качества конечного продукта. Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн. Технология RAD обеспечивает: − быстроту продвижения программного продукта на рынок; − интерфейс, устраивающий пользователя; − легкую адаптируемость проекта к изменяющимся требованиям; 31 − простоту развития функциональности системы. Жизненный цикл создания ЭИС на основе RAD-технологии предполагает после формирования технического задания и декомпозиции системы независимую разработку подсистем с последующей сборкой, тестированием и внедрением комплексной ЭИС (Рисунок 18). Рисунок 18. Жизненный цикл создания ЭИС на основе RAD-технологии Накопленный опыт использования RAD-технологии показывает, что существуют два базовых варианта организации технологического процесса проектирования с использованием систем-прототипов. 1) В первом варианте создание системы-прототипа используется для лучшей спецификации требований к разработке ЭИС, после разработки которых сам прототип оказывается ненужным. В этом случае традиционно разрабатывается «Постановка задачи», документация которой является спецификацией системы-прототипа. После демонстрации пользователю и доработки прототипа разрабатывается новая «Постановка задачи», которая служит основой создания действующей ЭИС. Основным недостатком первого варианта использования прототипирования является неэффективное использование системы-прототипа, а именно: прототипы не используются в дальнейшей разработке ЭИС после того, как выполнили свою первую задачу - устранили неясности в проекте. 2) Второй вариант предполагает итерационное развитие системы-прототипа в готовый для эксплуатации программный продукт. Итерации разработки системы-прототипа включают создание/модификацию системы-прототипа, ее демонстрацию пользователю и согласование, разработку новых спецификаций-требований к системе, новую модификацию и т.д., пока не будет создано готовое приложение. Документацию компонентов системы-прототипа непосредственно составляют спецификации, которые являются требованиями к программной реализации системы и определяют характер взаимоотношений с заказчиком на этапе сдачи готовой системы. 32 ГЛАВА 3. ТИПОВОЕ ПРОЕКТИРОВАНИЕ ЭИС 3.1 Основные понятия и классификация методов типового проектирования Методы типового проектирования ЭИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемая ЭИС должна быть декомпозируема на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.), для которых подбираются и закупаются имеющиеся на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области. Под типовым проектным решением (ТПР) будем понимать представленное в виде проектной документации, включая программные модули, проектное решение, пригодное к многократному использованию. В качестве проектного решения может выступать реализация как отдельных компонентов ЭИС (программных модулей, функциональных задач, автоматизированных рабочих мест, локальных баз данных, локальных вычислительных сетей), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ЭИС в целом). Типовые проектные решения также называют тиражируемыми продуктами. В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования. При элементном методе типового проектирования ЭИС в качестве типового элемента системы используется типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному). Сущность применения ТПР при элементном методе заключается в комплектации ЭИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. Достоинство элементного метода типового проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС. К недостаткам применения метода относятся большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости ТПР, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия. Следствием перечисленных недостатков являются большие затраты времени на доработку и комплексирование ТПР отдельных элементов, сопоставимые со временем ручного оригинального проектирования ЭИС. В настоящее время элементные ТПР в основном применяются в качестве библиотек методо33 ориентированных программ (библиотек классов объектов), например, при разработке графических интерфейсов, применении вычислительных и служебных функций. При использовании подсистемного метода типового проектирования ЭИС в качестве элементов типизации выступают отдельные подсистемы, которые обеспечивают функциональную полноту, минимизацию внешних информационных связей, параметрическую настраиваемость, альтернативность схем в пределах значений входных параметров. При этом достигается более высокая степень интеграции типовых элементов ЭИС. Типовые проектные решения для функциональных подсистем реализуются в виде пакетов прикладных программ (ППП), которые позволяют осуществлять: − модульное проектирование; − параметрическую настройку программных компонентов на различные объекты управления; − сокращение затрат на проектирование и программирование взаимосвязанных компонентов; − хорошее документирование отображаемых процессов обработки информации. Вместе с тем адаптивность типовых проектных решений в виде функциональных ППП недостаточна с позиции непрерывного инжиниринга деловых процессов. Также возникают проблемы в комплексировании ППП разных функциональных подсистем, особенно в случае использования ППП нескольких производителей программного обеспечения, для которых, как правило, характерна их информационная, программная и техническая несовместимость между собой при построении единой, корпоративной ЭИС. В качестве примеров широко распространенных функциональных ППП можно назвать: 1C «Предприятие» (автоматизация бухгалтерского учета, расчета заработной платы, складского учета), «Фолио - Склад» (автоматизация складских операций), Project Expert (бизнес-планирование), ИНЭК (финансовый анализ) и др. При объектном методе типового проектирования ЭИС в качестве типового элемента используется типовой проект для объектов управления определенной отрасли, который включает полный набор функциональных и обеспечивающих подсистем ЭИС. Современные типовые проекты отличаются: − открытостью архитектуры, позволяющей устанавливать проекты на разных программно-технических платформах; − масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест; − конфигурируемостью, позволяющей выбирать подмножество компо34 нентов, которые необходимы для конкретной проблемной области и параметрически настраиваются на особенности объекта управления. Несомненное преимущество объектного метода типового проектирования ЭИС перед подсистемным методом заключается в комплексируемости всех компонентов за счет методологического единства и информационной, программной и технической совместимости компонентов. Адаптивность объектного метода проектирования зависит от используемого подхода. При параметрической настройке типовых информационных систем, таких, например, как ППП «Галактика», «Парус», «БОСС» и другие, возникают проблемы привязки типового проекта к конкретному объекту управления так же, как и при подсистемном подходе. Обычным способом решения проблемы адаптации является изменение структуры организационноэкономической системы объекта внедрения в соответствии с требованиями типового проекта либо существенная доработка типового проекта с помощью специальных инструментальных средств типовой системы. В настоящее время развивается модельно-ориентированный подход реализации объектного метода типового проектирования ЭИС, известный по применению типовых информационных систем R/3 (SAP) и BAAN IV (BAAN). Особенность этого подхода заключается в настройке типового проекта на особенности объекта управления путем привязки модели проблемной области к модели типовой системы. Поддержание при этом модели проблемной области в репозитории системы сближает метод типового проектирования с методом автоматизированного проектирования как в части более точного определения и модификации требований к информационной системе, так и в части корректности параметрической настройки и автоматизированной доработки проектных решений. В силу отличий параметрически-ориентированного и модельноориентированного подходов к реализации методов типового проектирования ЭИС каждый из перечисленных подходов рассматривается в отдельном параграфе. 3.2 Параметрически-ориентированное проектирование ЭИС При проектировании ЭИС на основе параметрической настройки пакета прикладных программ (ППП) последний рассматривается как «черный ящик» (Рисунок 19). На вход ППП подаются параметрический (ПП) и информационный (ИП) потоки, а выходом служит результат работы пакета (РП). ППП включает следующие блоки: функционирования, обработки параметров, адаптации. 35 Исходные данные (информационный поток) Параметры (параметрический поток) Блок функционирования Блок обработки параметров Блок адаптации Результаты работы Генератор отчетов Генератор форм Встроенный макроязык Рисунок 19. Представление ППП в виде «черного ящика» Рассмотрим взаимосвязь основных потоков и компонентов пакета прикладных программ. Информационный поток представляет собой исходные данные, которые обрабатываются и необходимы для получения результатов работы пакета. Исходные данные для функционирования пакета могут быть представлены в виде различных документов, причем как бумажных, так и электронных. Результаты работы пакета могут быть представлены в виде отчетов, графиков, электронных документов, которые могут накапливаться или направляться во внешнюю среду. Блок функционирования обрабатывает исходные данные и формирует результаты работы пакета. Графически блок функционирования представляется деревом программных модулей, которые автоматизируют функции обработки данных. Параметрический поток - информация, необходимая для настройки пакета на конкретные условия функционирования. Параметрический поток включает информацию, которая задается один раз при установке (инсталляции) этого пакета. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на режим их работы. Для архитектуры «клиент-сервер» в параметрическом потоке описываются пользователи и их уровни доступа к программным модулям и ко всему пакету в целом. Параметрическая информация предоставляется: − в справочниках (классификаторах с задаваемым числом уровней классификации, например, в справочниках номенклатуры изделий и услуг, видов расчетов, валют и т.д.); − в таблицах описаний конфигурации программных модулей (например, условия включения (выключения) модуля, режимы ручного или автоматического обновления полей данных, методы расчетов показателей и т.д.). Блок обработки параметров представляет собой совокупность специальных модулей по интерпретации значений параметров. В частности, блок обработки параметров переносит установки пользователя непосредственно в прикладные программы и в используемую базу данных. Проводимая настройка ППП позволяет использовать его для широкого класса объектов управления. Блок адаптации взаимодействует с блоком функционирования и может добавлять модули или модифицировать их. Необходимость применения блока 36 адаптации связана с потребностями доработки программных модулей ППП под воздействием внешних условий функционирования. Поэтому в состав ППП включается инструментарий адаптации существующих типовых проектных решений. Сущность применения метода типового проектирования ЭИС на основе параметрической настройки ППП заключается в определении критериев оценки ППП, оценке множества ППП-претендентов по сформулированным критериям, выбору и закупке ППП с наивысшей интегральной оценкой, а далее - собственно настройке параметров и возможной доработке закупленного ППП. Параметрически-ориентированное проектирование ЭИС на основе использования ППП по сравнению с оригинальным проектированием дает возможность более быстрого и гибкого внедрения информационной системы. Однако существует ряд проблем, сдерживающих распространение данной технологии. К ним можно отнести следующее: − психологические и организационные трудности внедрения ППП; − достаточно высокую стоимость приобретения ППП и обучения персонала; − отсутствие глобальной модели объекта управления, что ведет к затратам по увязке различных ППП в рамках корпоративной ЭИС. 3.3 Модельно-ориентированное проектирование ЭИС Сущность модельно-ориентированного проектирования ЭИС сводится к адаптации компонентов типовой ЭИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ЭИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними. Ядром типовой ЭИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специальной базе метаинформации - репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ЭИС сводятся прежде всего к построению модели проблемной области и ее периодической корректировке. Для моделирования проблемной области и последующих конфигураций информационной системы из отдельных компонентов (программных модулей) используется специальный программный инструментарий. Несомненным достоинством применения модельно-ориентированных компонентных систем перед CASE-технологиями является накапливание опыта проектирования информационных систем для различных отраслей и типов производства в виде типовых моделей, которые поставляются вместе с программным продуктом в форме наполненного репозитория. Таким образом, вместе с программным продуктом пользователи приобретают базу знаний «know-how» об эффективных методах организации и управления бизнес-процессами, которые можно адапти37 ровать в соответствии со спецификой конкретного экономического объекта. Репозитории корпоративной ЭИС, использующей модельноориентированную технологию проектирования, в общем случае содержит метаинформацию базовой модели функциональности типовой системы (ссылочной модели в терминологии R/3), типовых моделей определенных классов ЭИС (референтных моделей в терминологии BAAN) и модели предприятий, получаемой на основе базовой или типовых моделей. Базовая модель репозитория содержит описание бизнес-функций, бизнеспроцессов, бизнес-объектов, организационной структуры, которые используются в программных модулях типовой ЭИС. При этом большое значение в базовой модели имеет задание бизнес-правил поддержания целостности информационной системы, определяющих условия проверки корректности совместного применения различных компонентов ЭИС. Таким образом, многообразие и гибкость определения бизнес-процессов и соответствующих конфигураций информационной системы задаются с помощью набора бизнес-правил. Типовые модели описывают конфигурации информационной системы для определенных отраслей (автомобильной, электронной, нефтегазовой и др.) или типов производства (единичного, серийного, массового, непрерывного и др.). Модель предприятия (проблемной области) строится либо путем привязки фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия, например как в инструментальном средстве BAAN Enterprise Modeler, либо в результате просмотра этих моделей и экспертного опроса, как в инструментальном средстве SAP Business Engineering Workbench. Причем в последнем случае пользователю предлагается определить значения не всех параметров, а только тех, которые связаны между собой в контексте диалога и описаны бизнес-правилами. Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. Далее по модели предприятия автоматически осуществляется конфигурация информационной системы, в ходе которой выполняется семантический контроль по бизнесправилам. В обобщенном виде конфигурация корпоративных информационных систем на основе модельно-ориентированной технологии представлена на Рисунок 20. 38 Рисунок 20. Конфигурация ЭИС на основе модельно-ориентированной технологии 39 ГЛАВА 4. ВИДЫ АВТОМАТИЗАЦИИ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ Кусочная автоматизация Кусочная (или как её ещё называют хаотичная) автоматизация является одним из наиболее неэффективных видов инвестирования средств в развитие предприятия. Под хаотичностью в данном случае понимается отсутствие стратегического плана, как правило, при таком подходе процесс внедрение ИС определяется сиюминутными локальными задачами, а не реальными потребностями бизнеса. В качестве критериев принятия решений в подобных случаях могут выступать: уровень знаний и предпочтений лиц, принимающих решения, возможность купить сейчас с эксклюзивной скидкой какую-либо технику или ПО и т.п. В результате предприятие в лучшем случае получает разрозненные прикладные системы, стоимость интеграции которых может быть сравнима с общей стоимостью комплексного решения; в худшем случае создаются незаконченные фрагменты информационной инфраструктуры и прикладных систем, которые не могут применяться в практической деятельности предприятия. При этом предприятие несет дополнительные затраты на дублирование функций, которые должна была выполнять ИС, и обслуживание созданных незаконченных прикладных систем. Автоматизация по участкам Автоматизация по участкам подразумевает процесс автоматизации отдельных производственных или управленческих подразделений предприятия, объединенных по функциональному признаку. Например, участок упаковки и маркировки, бухгалтерия и т.д. Подобный путь автоматизации выбирается в следующих случаях: − инвестиционные ресурсы предприятия недостаточны для решения задачи автоматизации в полном объеме; − существуют участки, где применение автоматизированных систем дает значительный экономический эффект, например за счет сокращения персонала; − технология производства или иные условия не позволяют обходиться без использования автоматизированных систем. Наиболее часто такой подход применяется для автоматизации производственных участков. Применение принципа автоматизации предприятия по участкам для ряда предприятий единственно возможный способ повысить экономические показатели в условиях ограниченных инвестиционных ресурсов. Чтобы автоматизация по участкам была эффективна, необходимы стратегический и оперативный планы автоматизации. При этом стратегический план автоматизации, если выбрана стратегия автоматизации по участкам, должен периодически, не реже одного раза в год, пересматриваться. 40 Автоматизация по направлениям Автоматизация по направлениям подразумевает автоматизацию отдельных направлений деятельности предприятия, таких, как производство, сбыт, управление финансами. От автоматизации по участкам этот подход отличается следующим. Автоматизация по направлениям деятельности предполагает участие в этом процессе всех организационных подразделений, функционирование которых связано с автоматизируемым направлением. Обычно любое направление деятельности охватывает практически все подразделения предприятия, например, процесс снабжения. В этом процессе принимают участие все подразделения от производственных (в части формирования планов закупки сырья, комплектующих и оборудования) до управленческих (канцтовары, мебель) и непосредственно сам отдел снабжения и транспортные службы. Поэтому подход, связанный с автоматизацией по направлениям, в принципе нельзя рассматривать как локальный. Его реализация связана с созданием как минимум телекоммуникационной инфраструктуры предприятия. В большинстве случаев автоматизация по направлениям связаны с реинжинирингом бизнес-процессов и требует создания модели всего предприятия. Для повышения эффективности также необходимы стратегический и тактический планы автоматизации. Ревизия стратегического плана автоматизации должна производиться после окончания автоматизации какого-либо направления и оценки полученных результатов. Полная автоматизация управления предприятием Автоматизированная система управления предприятием как система состоит из большого количества элементов различных уровней и различного назначения. К ним относятся подсистемы, модули, блоки управления, задачи, управленческие процедуры, функции, операции и т.п. Интеграция предполагает такое объединение и согласование управленческих функций и процедур. Чтобы в ходе процесса управления предприятием обеспечивалась оптимизация его поведения. Интеграция проявляется во всех без исключения функциональный и обеспечивающих подсистемах. В подсистеме технического обеспечения – это локальные вычислительные сети и обеспечение связи предприятия с внешней средой через глобальные сети. В подсистеме информационного обеспечения – это ведение баз данных под управлением СУБД. Интеграция математического обеспечения проявляется прежде всего в согласовании входов и выходов математических моделей, комплексировании различных моделей (например, прогнозирования и планирования), целостности и непротиворечивости системы математических моделей. Интеграция программного обеспечения проявляется в том, что оно строится в виде сложного и вместе с тем гибкого программного комплекса, позволяющего выполнять программы в требуемой последовательности и требуемых сочетаниях. Интегрированные ИС выводят предприятие на новый уровень интеграции организационного обеспечения благодаря унифика41 ции пользовательского интерфейса. Особенно ощутим этот эффект в больших автоматизированных системах управления, где новая ИС приходит на смену сотням старых локальных систем. Практическим результатом перехода к новой системе становится единый для всего предприятия стандарт на способы взаимодействия пользователей с системой. Но основное, ради чего создаются на предприятиях интегрированные ИС, - это функциональная интеграция. Единая компьютерная система позволяет обеспечить взаимную прозрачность систем. Например, уже на стадии проектирования можно моделировать возможное влияние конструкторских и технических решений на ход производства. Интегрированная ИС строится с ориентацией на управление производственным процессом как единым целым, а не автоматизацию деятельности отдельных подразделений, занимающихся управлением. Таким образом, комплексная автоматизация управления способствует преодолению барьеров между различными службами управления. Одним из проявлений этого процесса является использование в разных службах одним и тех же функций, требуемых для подготовки различных управленческих решений. Можно отменить следующие особенности комплексного подхода к автоматизации управления предприятием: − повышенная экономическая эффективность этого подхода по сравнению с другими (по участкам и по направлениям); − чрезвычайно высокие требования к качеству управления процессом внедрения системы. 42