Тема 3. Проектирование ИС: быстрый взгляд

План лекции

1. Предварительные замечания

2. Инвариантные составляющие жизненного цикла ИС

Предварительные замечания

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

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

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

2. Инвариантные составляющиежизненного цикла ИС

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

В описаниях моделей жизненного цикла (ЖЦ) ИС, в стандартахи методологиях используются следующие термины: этапы, стадии, процессы, задачи, работы, функции и т. д. Их определения либо«размыты», либо отсутствуют, т. е. предполагаются усваиваемымииз контекста. В текущем контексте будем предполагать, что ЖЦИС состоит из фаз. Фаза ЖЦ может состоять из стадий, стадиииз этапов, этапы – из процессов, процессы – из работ. Одновременно с этим будем предполагать необязательность промежуточных ступеней. Например, фазы могут сразу же подразделятьсяна процессы, минуя уровни стадий и этапов. Указанное отношениеусловно. В альтернативных контекстах возможно отождествлениенекоторых из перечисленных элементов и (или) изменение порядка их следования. Терминология данного подраздела соответствуеттрадиции, сформировавшейся под влиянием SADT (условно назовем ее базовой).

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

В приведенных формулах знак«→» означает чередование фази процессов ЖЦ; знак«Æ» означает получение результата, указанного справа от этого знака; знак означает объединения элементовв целостную конструкцию.

Синтез – это популярное название суперфазы, объединяющейтри важные фазы ЖЦ, суммарная трудоемкость которых составляетоколо 75 % трудоемкости всего проекта ИС.

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

Проектирование – это определение подсистем и их взаимосвязей.

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

Тестирование – это проверка правильности функционирования ИС.

Внедрение – это ввод ИС в действие (использование).

Сопровождение – это поддержка процесса использования ИС.

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

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

Существуют предметные и системные модели – модели предметной области и модели создаваемой системы (ИС). Модели предметной области отражают:

1) бизнес-процессы предприятия;

2) информацию, задействованную в бизнес-процессах;

3) участников бизнес-процессов;

4) функциональные задачи, решаемые участниками бизнес-процессов.

Модели создаваемой системы отражают:

1) информационно-вычислительные процессы внутри ИС;

2) информацию, создаваемую, хранимую и используемую в ИС;

3) пользователей ИС;

4) функциональные задачи, решаемые элементами ИС, т. е. выполняемые системой функции.

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

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

В чем заключается кардинальное различие предметных и системныхмоделей? Упрощенно можно считать, что предметные модели отражаютпроцессы решения функциональных задач предприятия на текущиймомент – до внедрения ИС, а системные модели отражают процессырешения функциональных задач с использованием создаваемой ИС.

Поэтому первые модели можно называть моделями AS-IS (как есть), а вторые – моделями TO-BE (как должно быть), но главное:

1) процедура построения модели AS-IS является средством (механизмом) синтеза модели TO-BE;

2) модель TO-BE является формализованным представлением требований к создаваемой системе (Requirementexpression).

Анализ. Анализ включает в себя следующие процессы:

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

2) обоснование целесообразности создания ИС;

3) формулировка требований к создаваемой ИС.

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

При использованиипринципов структурного анализа в качествеинструментальных средств используются методологии IDEF0, IDEF, DEF и функционально-ориентированные CASE-средства, реализующие указанные методологии. Наиболее популярными такими CASE-средствами являются пакеты BPWIN и ERWIN фирмы PLATINUM.

Модели IDEF0 (IDEF=ICAMDEFINITION, где ICAM–IntegratedComputerAidedManufacturing или IntegrationDEFINITIONforfunctionmodeling) представляют предметную область в виде совокупностивзаимодействующих работ или функций. Они достаточно нагляднои полно описывают бизнес-процессы предприятия.

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

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

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

При использовании во время анализапринципов объектно-ориентированного проектирования в качестве инструментальныхсредств используются методологии, ориентированные на использование языка UML. Наиболее популярными объектно-ориентированными инструментами являются методология RUP (RationalUnifiedProcess) и CASE-средство RationalRose фирмы RationalSoftware.

Фаза ЖЦ «Анализ», реализуемая с помощью UML, предполагаетдвукратное построение четырех видов диаграмм:

1) прецедентов (Use case diagram);

2) деятельности (Activity diagram);

3) коммуникации (Communication diagram) в UML2.0 илисотрудничества (Collaboration) в UML1.x;

4) последовательности (Sequencediagram).

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

Модели предметной области традиционно называются бизнес-моделями. Элементы бизнес-модели прецедентов называются «бизнес-актор» (бизнес-актант) и «бизнес-прецедент». Данные элементы отличаются от обычных (системных) акторов и прецедентовналичием в левой части изображения черты, направленной под углом45°, и затенением овалов, символизирующих бизнес-прецеденты.

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

При этом в спецификациях системных прецедентов выделяют тривида потоков: главный поток; подпотоки; альтернативные потоки.

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

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

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

Информационная составляющая в них представлена очень ограниченно

Для устранения указанного упущения следует завершить фазуанализа построением предварительного варианта диаграммы классов (Classdiagram).

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

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

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

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

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

К сожалению, терминология RUP не в полной мере соответствует традиции, сложившейся во времена безусловного доминированияSADT. В частности, составляющие фаз ЖЦ названыDisciplines-дисциплинами. На русский язык термин Disciplines обычно переводится как «Процессы», термин Phases часто переводится как «Этапы».

К тому же в RUP нет фазы «Анализ», ей соответствуют две фазы«Начало» (Inception) и «Уточнение» (Elaboration). Фаза RUP «Начало» содержательно соответствует базовым процессам «Структурирование» и «Обоснование целесообразности создания ИС». Стадия «Уточнение» соответствует базовому процессу «Формулировка требований» к создаваемой ИС

Проектирование. Проектирование – это определение подсистеми их взаимосвязей. Фаза проектирования состоит из двух последовательных и одного параллельного процессов:

1) предварительное (эскизное) проектирование;

2) детальное (техническое) проектирование;

3) проектирование пользовательского интерфейса (GUI).

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

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

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

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

Логическое проектирование основано на использовании особенностей конкретной модели данных, при этом специфика конкретнойСУБД не имеет никакого значения.

Терминология пакета ERWIN имеет следующие особенности:

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

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

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

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

При использовании принципов объектно-ориентированногопроектирования дорабатывается ранее созданный набор UML-диаграмм

1) прецедентов (Use case diagram);

2) деятельности (Activity diagram);

3) коммуникации (Communication diagram) в UML2.0 илисотрудничества (Collaboration) в UML1.x;

4) последовательности (Sequencediagram);

5) классов (Classdiagram)

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

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

Кодирование, или реализация. Даже при использовании принципов структурного проектирования ИС фаза кодирования (реализации) в настоящее время осуществляется с помощью объектно-ориентированных систем программирования. Программы, реализующиефункциональность ИС, пишутся на объектно-ориентированных языках C++, C#, Java, VisualBasic, Delphi, PowerBuilder.

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

1) создание физической модели базы данных;

2) задание объектов физической памяти (генерация каталога базыданных);

3) генерация кода серверной и клиентской частей.

Если проектирование осуществлялось с использованием принципов объектно-ориентированного проектирования и соответствующего CASE-средства, например RationalRose, то реализация указанных ранее важнейших процессов фазы кодирования возможнаи с помощью функционально-ориентированных CASE-средств. Например, ERWIN может с помощью ERWIN TranslationWizard загрузитьдиаграмму классов и по ней сформировать физическую модель базыданных.

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