Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления

Подождите немного. Документ загружается.

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

экземпляром всех его предков, т.е. обладает значениями всех атрибутов всех классов-

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

Не следует создавать слишком глубокую иерархию классов, поскольку это затруднит

восприятие модели – иерархия с количеством уровней не превышающих 3, как правило,

всегда приемлема; 5-6 уровней иерархии может быть как приемлемо, так и нет в зависимости

от особенностей проектируемой системы.

Кроме того, обобщение следует использовать только там, где по крайней мере один из

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

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

одинаковые по своей сигнатуре и поведению с суперклассом (масть карты <- трефи,

бубны…, работники мужского и женского полов не являются подклассами).

Таким образом, ассоциации типа «обобщение» позволяют обеспечить полиморфизм:

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

новый подкласс не нарушает работу существующего класса.

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

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

нескольких классов одновременно.

На рис. 1 показано дерево классов, в котором SubClass является подклассом

(дочерним классом) по отношению к двум суперклассам (базовым классам) – SuperClass1 и

SuperClass2

. Object1 и Object2 – экземпляры класса SubClass, наследующие атрибуты класса

SubClass (x и y). В свою очередь SubClass наследует атрибуты z и w классов SuperClass1 и

SuperClass2, переопределяет

атрибут x и добавляет атрибут y.

Таким образом, при вызове, например Object1.x или Object2.x будет использоваться атрибут

SubClass.x, находящийся на один уровень выше в иерархии наследования; при вызове

Object1.z или Object2.z будет использоваться атрибут SuperClass1.z, поскольку класс

SuperClass1 находится левее в дереве по сравнению с SuperClass2, то SubClass будет

наследовать атрибуты SuperClass1 в первую очередь. Таким образом, при использовании

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

строке заголовка инструкции class наследующего класса, определяет порядок наследования

атрибутов.

Рисунок 34 – Множественное наследование

>>> class SuperClass1:

x = 1

z = 2

>>> class SuperClass2:

w = 3

z = 4

>>> class SubClass (SuperClass1, SuperClass2):

x = 5

y = 6

>>> Object1 = SubClass ()

>>> Object2 = SubClass ()

>>> Object1.x

>>> Object1.z

Рисунок 35 – Листинг кода,

демонстрирующий множественное

наследование

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

модели на этапе проектирования или с помощью механизма реализации «делегирование».

Наследование одним классом (SubClass) атрибутов нескольких классов (SuperClass1 и SuperClass2) называется

множественным наследованием.

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

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

Один класс может «видеть» другой, если тот находится в области действия первого и между

ними существует явное или неявное отношение. В языке UML определены три уровня

видимости:

• public (общий) – любой внешний класс, который «видит» данный, может пользоваться

его общими свойствами. Обозначаются знаком «+» перед именем атрибута или

операции;

• protected (защищенный) – только класс или потомок данного класса может пользоваться

его защищенными свойствами. Обозначаются знаком «#»;

• private (закрытый) – только данный класс может пользоваться закрытыми атрибутами.

Обозначаются символом «-»;

• package or implementation (пакетный) – атрибут является общим в пределах пакета в

котором расположен класс. Обозначаются символом «~».

При определении видимости для той или иной составляющей необходимо

руководствоваться следующими соображениями:

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

закрытые, защищенные и пакетные вводятся для удобства реализации;

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

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

значения) может разрушить согласованность всей модели. Поскольку защищенные,

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

изменения обходятся дешевле.

Еще одной важной характеристикой атрибутов и операций классов является область

действия (scope), которая определяет к чему относится данная составляющая: к объекту или

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

операций. Область действия этих атрибутов и операций instance (экземпляр) – у каждого

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

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

значение. Аналогично нужны операции, не относящиеся ни к одному конкретному

экземпляру класса (например, операция создания объекта - конструктор). Такие атрибуты и

операции имеют область действия classifier (классификатор) – все экземпляры совместно

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

В этом случае оно называется статическим.

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

являются средством организации модели

в процессе разработки, повышения ее

управляемости и читаемости. Диаграмма пакетов – диаграмма, содержащая пакеты классов и

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

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

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

Рисунок 36 – Диаграмма пакетов

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

из других пакетов. Если один элемент пакета зависит от элемента другого пакета, то эту

зависимость можно отобразить с помощью связи.

Рисунок 37 – Сопоставление пакетов проектным слоям

Каждый пакет представляет пространство имен (namespace), следовательно каждый

класс внутри собственного пакета должен иметь уникальное имя. Чтобы отличить один класс

от другого, можно использовать полностью определенное имя (fully qualified name), то есть

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

используются двойные двоеточия, поэтому классы дат могут иметь имена System::Date.

Можно показывать только имя пакета или имя вместе с его содержимым.

Согласно концепции UML классы в пакетах могут быть открытыми (public) или

закрытыми (private). Открытые классы представляют часть интерфейса пакета и могут быть

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

сделать это, присвоив всем классам модификатор видимости private (закрытый), так чтобы

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

открытые классы для внешнего использования. Эти дополнительные классы, называемые

Facades (Фасады) [21], делегируют открытые операции другим классам пакета.

3.2.2.5. Диаграмма компонент (Component Diagram)

Component Diagram (диаграмма компонентов) позволяет создать физическое

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

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

файлах.

В связи с тем, что система может состоять из модулей различного типа, пользователь

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

изменение стереотипа часто ведет к изменению графического отображения компонента на

диаграмме:

• Package (пакет) - объединяет группу компонентов в модели;

• Main program (главная программа);

• Subprogram body (тело подпрограммы);

• Package specification/body (определение/тело пакета).

Рисунок 38 – Диаграмма компонент

3.2.2.6. Диаграмма размещения (Deployment Diagram)

Диаграмма размещения отражает физические взаимосвязи между программными и

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

показать размещение объектов и компонентов в распределенной системе.

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

вычислительного устройства – в большинстве случаев, часть аппаратуры. Эта аппаратура

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

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

компонентов.

Рисунок 39 – Диаграмма размещения

4. ИНСТРУМЕНТАЛЬНЫЕ СИСТЕМЫ ПОДДЕРЖКИ ЖИЗНЕННОГО ЦИКЛА

Системные программы облегчают

процесс написания прикладных

программ и их ошибок.

Теория ошибок В. Тихонова

Современное производство сложных высокотехнологичных изделий подразумевает

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

предприятий, участвующих в проектировании, производстве, реализации и эксплуатации

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

цикла изделий, которая получила название CALS (Continuous Acquisition and Lifecycle

Support). CALS – это глобальная стратегия повышения эффективности бизнес-процессов,

выполняемых в ходе жизненного цикла изделий, за

счет информационной интеграции и

преемственности информации, порождаемой на всех этапах ЖЦ. Концепция CALS состоит в

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

протяжении ЖЦ, посредством организации и поддержания интегрированной

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

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

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

формы, так и содержания информации о

конкретных изделиях на различных этапах их ЖЦ.

Реализация CALS-концепции осуществляется посредством применения CALS-систем

– это АСУ, которые интегрируют информационные процессы в единое информационное

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

ЖЦ изделия.

Рисунок 40 – Инструментальные пакеты CALS

• CAE (Computer Aided Engineering) — автоматизированные расчеты и анализ;

• CAD (Computer Aided Design) — автоматизированное проектирование;

• САМ (Computer Aided Manufacturing) — автоматизированная технологическая

подготовка производства;

• PDM (Product Data Management) — управление проектными данными;

• ERP (Enterprise Resource Planning) — планирование и управление предприятием;

• MRP II (Manufacturing Requirement Planning) — планирование производства;

• MES (Manufacturing Execution System) — производственная исполнительная система;

• SCM (Supply Chain Management) — управление цепочками поставок;

• CRM (Customer Relationship Management) — управление взаимоотношениями с

заказчиками;

• SCADA (Supervisory Control And Data Acquisition) — диспетчерское управление

производственными процессами;

• CNC (Computer Numerical Control) — компьютерное числовое управление;

• S&SM (Sales and Service Management) — управление продажами и обслуживанием;

• СРС (Collaborative Product Commerce) — совместный электронный бизнес.

По данным специалистов, показатели эффективности внедрения CALS-технологий в

промышленности США в целом составляют:

• прямое уменьшение затрат на проектирование от 10 до 30 %;

• сокращение времени разработки изделий в 1,5 — 2 раза;

• сокращение времени вывода новых изделий на рынок от 25 до 75%;

• уменьшение доли брака и объема конструктивных изменений от 23 до 73 %;

• сокращение затрат на подготовку технической документации до 40 %;

• сокращение затрат на разработку эксплуатационной документации до 30 %.

В настоящее время имеется достаточно большое количество интегрированных систем

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

Однако наиболее популярной на российском и мировом рынках считается система R/3

немецкой фирмы SAP.

Система SAP R/3 состоит из набора прикладных модулей, которые поддерживают

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

функционирования в реальном времени: финансы (FI); контроллинг (CO); управление

основными средствами (AM); управление проектами (PS); производственное планирование

(PP); управление материальными потоками (MM); сбыт (SD); управление качеством (QM);

техобслуживание и ремонт оборудования (PM); управление персоналом (HR); управление

информационными потоками (WF); отраслевые решения (IS).

Базисная система служит основой системы SAP R/3 и гарантирует интеграцию всех

прикладных модулей и независимость от аппаратной платформы. Базисная система

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

сервер. Система SAP R/3 функционирует на серверах UNIX, AS/400, Windows NT, S/390 и с

различными СУБД (Informix, Oracle, Microsoft SQL Server, DB2). Пользователи могут

работать в среде Windows, OSF/Motif, OS/2 или Macintosh.

Среди рассмотренных выше CALS-систем в контексте данного курса внимание будет

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

который получил название CASE (Computer Aided Software Engineering) набор

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

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

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

совокупность моделей на всех стадиях разработки и сопровождения ПО.

Все современные CASE-средства могут быть классифицированы в основном по типам

и категориям. Классификация по типам отражает функциональную ориентацию CASE-

средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень

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

решающие небольшие автономные задачи (tools), набор частично интегрированных средств,

охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью

интегрированные средства, поддерживающие весь ЖЦ ИС.

Классификация по типам включает следующие основные группы CASE-средств:

• средства анализа (Upper CASE), предназначенные для построения и анализа моделей

предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

• средства анализа и проектирования (Middle CASE), поддерживающие наиболее

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

проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE),

Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Аналитик (МакроПроджект)).

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

архитектуры системы, алгоритмов и структур данных;

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

генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных

СУБД. К ним относятся ERwin (Logic Works), S-Designer (SDP) и DataBase Designer

(ORACLE). Средства проектирования баз данных имеются также в составе CASE-

средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

• средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware),

JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix),

SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав

Vantage Team Builder, PRO-IV и частично – в Silverrun;

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

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

Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder,

PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных

кодов наибольшее распространение получают объектно-ориентированные CASE-

средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose

(Rational Software), Object Team (Cayenne)).

Вспомогательные типы CASE-средств включают:

• средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

• средства конфигурационного управления (PVCS (Intersolv));

• средства тестирования (Quality Works (Segue Software));

• средства документирования (SoDA (Rational Software)).

В качестве примера рассмотрим комплект CASE-средств, предоставляемых тремя

наиболее известными компаниями, работающими в области создания ПО: IBM (Rational

Software), Oracle и Borland.

Одна из наиболее совершенных технологий, претендующих на роль мирового

корпоративного стандарта – Rational Unified Process (RUP). RUP представляет собой

программный продукт, разработанный компанией Rational Software (www.rational.com),

которая в настоящее время входит в состав IBM. В рамках RUP определены шесть основных

процессов создания ИС: построение бизнес-моделей; определение требований; анализ и

проектирование; реализация; тестирование; развертывание; и три вспомогательных процесса:

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

инфраструктуры.

RUP тесно интегрирован с инструментальным комплексом Rational Suite, в котором

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

инструментальным средством.

Rational Suite существует в нескольких вариантах:

• Rational Suite AnalystStudio – предназначен для определения и управления полным

набором требований к разрабатываемой системе;

• Rational Suite DevelopmentStudio – предназначен для проектирования и реализации ПО;

• Rational Suite TestStudio –набор продуктов, предназначенных для автоматического

тестирования приложений;

• Rational Suite Enterprise – обеспечивает поддержку полного жизненного цикла ПО. В

состав Rational Suite входят следующие компоненты:

o Rational Rose – средство визуального моделирования (анализа и

проектирования), использующее язык UML; включает в свой состав:

репозиторий, средства просмотра проекта (браузер), средства сбора

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

программирования;

o Rational XDE – средство анализа и проектирования, интегрируемое с

платформами MS Visual Studio .NET и IBM WebSphere Studio Application

Developer, и, предназначенное для обеспечения синхронизации между кодом и

моделью;

o Rational Requisite Pro – средство управления требованиями, предназначенное

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

команде разработчиков создавать, структурировать, устанавливать

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

возникающих на любом этапе разработки компонентов приложения;

o Rational Rapid Developer – средство быстрой разработки приложений на

платформе Java 2 Enterprise Edition;

o Rational ClearCase – средство управления конфигурацией ПО;

o Rational SoDA – средство автоматической генерации проектной документации;

o Rational ClearQuest – средство для управления изменениями и отслеживания

дефектов в проекте на основе средств e-mail и Web;

o Rational Quantify – средство количественного определения узких мест,

влияющих на общую эффективность работы программы;

o Rational Purify – средство для локализации трудно обнаруживаемых ошибок

времени выполнения программы;

o Rational PureCoverage – средство идентификации участков кода, пропущенных

при тестировании;

o Rational TestManager – средство планирования функционального и

нагрузочного тестирования;

o Rational Robot – средство записи и воспроизведения тестовых сценариев;

o Rational TestFactory – средство тестирования надежности;

o Rational Quality Architect – средство генерации кода для тестирования.

Методическую основу технологии создания ПО корпорации Oracle (www.oracle.com)

составляет метод Oracle (Oracle Method) – комплекс методов, охватывающий большинство

процессов ЖЦ ПО. В состав комплекса входят:

• CDM (Custom Development Method) – разработка прикладного ПО;

• PJM (Project Management Method) – управление проектом;

• AIM (Application Implementation Method) – внедрение прикладного ПО;

• BPR (Business Process Reengineering) – реинжиниринг бизнес-процессов;

• OCM (Organizational Change Management) – управление изменениями, и др.

Комплекс Oracle Developer Suite содержит набор интегрированных средств разработки

для быстрого создания приложений. Oracle Developer Suite интегрирован с Oracle Database и

Oracle Application Server, образуя единую платформу для создания и установки приложений.

Oracle Developer Suite поддерживает стандарты J2EE: Enterprise Java Beans (EJB), сервлеты и

страницы JavaServer (JSP). В него также входят анализатор XML, процессор XSLT,

процессор схем XML и XSQL-сервлет для разработки XML-приложений.

В Oracle Developer Suite встроена поддержка языка UML для разработки приложений

на основе моделей. Модели хранятся в общем репозиторий Oracle, который предназначен

для поддержки больших коллективов разработчиков.

Oracle Developer Suite включает в себя:

• Oracle Designer – средство моделирования и генерации приложений;

• Oracle Forms – средство быстрой разработки приложений;

• Oracle Reports – визуальное средство разработки отчетов;

• Oracle JDeveloper – средство визуального программирования на языке Java;

• Oracle Discoverer – средство для разработки аналитических приложений;

• Oracle Warehouse Builder – система для построения хранилищ данных;

• Oracle Portal – средство разработки информационного портала организации.

CASE-средство Oracle Designer является интегрированным средством,

обеспечивающим в совокупности со средствами разработки приложений поддержку ЖЦ ПО.

В состав Oracle Designer входят следующие компоненты:

• Repository Administrator – средства управления репозиторием (создание и удаление

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

экспорт и импорт данных);

• Repository Object Navigator – средство доступа к репозиторию, обеспечивающее

многооконный объектно-ориентированный интерфейс доступа ко всем элементам

репозитория;

• Process Modeler – средство анализа и моделирования бизнес-процессов;

• Systems Modeler – набор средств построения функциональных и информационных

моделей проектируемой системы;

• Systems Designer – набор средств проектирования ПО, включающий средство построения

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

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

реализуемую хранимыми процедурами на языке PL/SQL;

• Server Generator – генератор описаний объектов БД Oracle (таблиц, индексов, ключей,

последовательностей и т.д.);

• Forms Generator – генератор приложений для Oracle Forms. Генерируемые приложения

включают в себя различные экранные формы, средства контроля данных, проверки

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

• Repository Reports – генератор стандартных отчетов, интегрированный с Oracle Reports.

Компания Borland (www.borland.com) в результате развития собственных разработок и

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

средств, реализующих управление полным жизненным циклом приложений (Application Life

Cycle Management, ALM). В состав инструментальных средств, поддерживаемых компанией

Borland, входят:

• CaliberRM – система управления требованиями CaliberRM. CaliberRM сохраняет

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

механизма генерации документов MS Word на базе заданных шаблонов. CaliberRM

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

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

случае изменения того или иного требования.

• Together ControlCenter – интегрированная среда проектирования и разработки,

поддерживающая визуальное моделирование на UML с последующим написанием

приложений для платформ J2EE (Java) и .Net (С#, С++ и Visual Basic). В системе

реализована технология LiveSource, которая обеспечивает синхронизацию между

проектом приложения и изменениями – при внесении изменений в исходные тексты

меняется модель программы, а при изменении модели надлежащим образом изменяется

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

• Контроль версий осуществляется благодаря функциональной интеграции Together и

системы StarTeam. Поддерживается также интеграция с системой управления

конфигурацией Rational ClearCase.

• Optimizeit Suite 5, Optimizeit Profiler for .NET – позволяют выявить потенциальные

проблемы использования аппаратных ресурсов – памяти и процессорных мощностей на

платформах J2EE и .Net соответственно. Интеграция Optimizeit Suite 5 в среду

разработки Jbuilder, a Optimizeit Profiler – в C#Builder и Visual Basic .Net позволяет

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

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

• Optimizeit ServerTrace – предназначена для управления производительностью серверных

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

контрольных данных по виртуальным Java-машинам.

• StarTeam – объединяет основные фазы ЖЦ ПО. Выполняет функции контроля версий,

управления изменениями, отслеживания дефектов, управления требованиями (в

интеграции с CaliberRM), управления потоком задач и управления проектом. StarTeam

совместима с интерфейсом Microsoft Source Code Control и интегрируется с любой

системой разработки, которая поддерживает этот API. Кроме того, в системе

реализованы средства интеграции со средствами разработки и моделирования Together,

JBuilder, Delphi, C++Builder и C#Builder.

Компания Computer Associates (www.ca.com) предлагает комплексы

инструментальных средств поддержки различных процессов ЖЦ ПО:

1. AllFusion Modeling Suite – интегрированный комплекс CASE-средств, включающий

следующие продукты:

• AllFusion Process Modeler (BPwin) – функциональное моделирование;

• AllFusion ERwin Data Modeler (ERwin) – моделирование данных;

• AllFusion Component Modeler (Paradigm Plus) – объектно-ориентированный анализ и

проектирование с использованием UML и возможностью генерации кода;

• AllFusion Model Manager (Model Mart) – организация совместной работы команды

разработчиков;

• AllFusion Data Model Validator (ERwin Examiner) – проверка структуры и качества

моделей данных.

• AllFusion Change Management Suite – комплекс средств управления конфигурацией и

изменениями.

2. AllFusion Process Management Suite – средства управления процессами и проектами для

различных типов приложений.