Главная

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

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

С₀ → С₁ → . . .→ С_i → . . .→ С_n

Каждое состояние проекта характеризуется некоторой совокупностью параметров

i = 0, n.

по значению которых можно судить о степени завершенности проекта, или, другими словами, о степени близости к конечной цели разработки. Для простоты будем предполагать, что каждому промежуточному состоянию С₁ соответствуют две интегральные оценки р_i и q_i которые исчерпывающе характеризуют степень завершенности проекта соответственно с количественной и качественной сторон. Характеристики р и q должны монотонно возрастать на упорядоченном множестве состояний C_i , =0, i = 0, n.

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

Процесс разработки разбивается на отдельные подпроцессы (шаги разработки), каждому из которых соответствует определенное промежуточное состояние разработки, однозначно характеризуемое значениями р и q. Обозначим характеристики проекта, достигнутые после выполнения i шагов, черезр р_i и q_i, а их приращение на i-м шаге - через Δр_i и Δq_i.

Процесс разработки АИС состоит в том, что на каждом шаге задается управляющее воздействие u ( i ), которое определяет значения Δр_i и Δq_i и переводит разработку проекта из состояния (р_i-1 , q_i-1) ^в состояние (p_i , q_i). Воздействие u ( i ) интерпретируется как выбор одного из альтернативно возможных способов осуществления разработки. Любой способ перевода проекта в новое состояние реализуется посредством выполнения определенного множества проектных процедур.

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

u ( i ) ∈ u ( i )

В начале процесса разработки, как правило, р_o = 0, q_o = 0. Значения характеристик на последующих шагах определяются следующим образом:

p_i = φ ( u ( k ), р_i-1 );
q_i = γ ( u ( k ), q_i-1 );
( p_i , q_i ) = ƒ ( u ( i ), ( р_i-1 , q_i-1 )), i = 1, n.

Обозначим через (Р_i , Q_i ) множество всех состояний проекта, в которое его можно перевести из начального состояния ( р_o , q_o ) за i шагов, пользуясь управляющими воздействиями u (k) ∈ U(k), k = 1, i. Такое множество назовем множеством достижимости. (Р_i , Q_i ) определяется с помощью рекуррентных соотношений вида:

( Р_i , Q_i ) = F ( u ( k )), ( р_k-1 , q_k-1 ));
u( k ) ∈ U( k ), k = 1, i, i = 1, n.

В задании на проектирование указываются требования, которым должен удовлетворять проект после окончания его разработки. Исходя из этого можно определить показатели р_n и q_n , характеризующие конечное состояние проекта, которое должно принадлежать некоторой области допустимых состояний (Р'_n , Q'_n ), т.е.

( p_n , q_n ) ∈ ( Р'_n , Q'_n )

Разработка U = (u(1); u (2);...; u (i);... ; u(n)), состоящая из совокупности пошаговых воздействий, будет допустимой, если она переводит проект из заданного начального состояния (р_o, q_o) в конечное (р_n, q_n), удовлетворяющее приведенному выше условию.

Для успешного достижения цели создания АИС необходимо выполнение условия:

(Р_i , Q_i ) ∩ ( Р'_i , Q'_i ) ≠ Ø , i = 1, n.

Условие означает, что множество всех состояний проекта должно находиться во множестве допустимых состояний проекта в соответствии с предъявляемыми требованиями. В противном случае следует либо изменить техническое задание на проект, изменив тем самым (Р'_i , Q'_i), i = 1, n, либо расширить область возможных управляющих воздействий u (i), i = 1, n.

Пусть в результате выполнения ( i - 1) шагов проект перешел в состояние (р_i-1, q_i-1). Тогда множество допустимых управляющих воздействий на i-м шаге определяется следующим образом:

U' ( i ) = { u ( i ): ( p_i , q_i ) = ƒ ( u ( i ), ( р_i-1 , q_i-1 )),
( p_i , q_i ) ∈ ( Р'_i , Q'_i ) , i = 1, n.

Теперь, объединив, можно записать в окончательном виде условие успешной разработки АИС:

u ( i ) ∈ U( i ) ∩ U'( i ), i = l, n.

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

Условию на каждом шаге разработки, как правило, может удовлетворить несколько управляющих воздействий u (i). Следовательно, процесс разработки АИС является альтернативным. Возникает задача выбора технологического процесса из альтернативно возможных.

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

Методология разработки

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

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

Методология представляет собой:

• тесно связанные, предписанные конкретные последовательности шагов разработки;
• конкретные данные, подлежащие накоплению на каждой стадии;
• критерии завершения работ в контрольных точках;
• решения, которые нужно принять перед выбором между альтернативами разработки;
• конкретные поименованные стандарты и другие детали, которые могут появиться при построении приложений.

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

1. Структурные методологии. Реализуют принцип алгоритмической декомпозиции: АИС делится на модули, каждый из которых реализует некоторую часть общего технологического процесса. Наиболее известны и распространены:

• методология структурного анализа и проектирования SADT (Structured Analysis and Design Technique);
• методологии, использующие в качестве центрального метода моделирование потоков данных: Гейн/Сарсон (Gane/ Sarson), ДеМарко (DeMarco), Йордон (Yourdon);
• методологии моделирования данных: Варнье/Орр (Warnier/ Orr), ER-моделирование Чена (Chen).

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

• инкапсуляция - объекты наделяются некоторой структурой и обладают определенным набором операций, т.е. поведением. Операции, принадлежащие данному объекту, образуют его методы. Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь посредством его методов. Таким образом, благодаря инкапсуляции объекты можно рассматривать как самостоятельные сущности, отделенные от внешнего мира. Для того чтобы объект произвел некоторое действие, ему необходимо извне послать сообщение, которое инициирует выполнение нужного метода;
• наследование - возможность создавать из объектов новые объекты, которые унаследуют структуру и поведение своих предшественников, добавляя им черты, отражающие их собственную индивидуальность;
• полиморфизм - различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному в соответствии с тем, как реализованы у них методы, реагирующие на сообщения.

Наиболее известны и распространены объектные методологии следующих авторов: Шлеер/Меллор (Shlaer/Mellor), Буч (Booch), Рамбо (Rumbaugh) - методология ОМТ, Код/Йордон (Coad/Yourdon). В настоящее время последние три методологии объединены их авторами в языке UML - Unified Modeling Language - унифицированный язык моделирования. UML представляет собой язык визуального моделирования для разработки объектно-ориентированных и компонентных систем, выбранный в качестве стандарта объектно-ориентированного анализа и проектирования систем международным консорциумом Object Managing Group (OMG) в 1997 г.

Язык UML использует графическую нотацию и предназначен для спецификации, визуализации, конструирования и документирования систем программного обеспечения, разрабатываемых на основе объектно-ориентированных технологий и компонентного подхода. Этот язык не зависит от конкретных языков программирования, используемых при реализации разрабатываемых систем.

Как и любой другой язык моделирования, UML включает:

• модельные элементы - фундаментальные концепции моделирования понятий предметной области и их семантику;
• нотацию - визуальное представление модельных элементов;
• руководящие указания - правила использования модельных элементов при описании системы.

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

Диаграммы использования (use case diagrams) описывают пользователей системы, предоставляемые системой сервисы и взаимосвязи между ними. Взаимосвязи показывают, с одной стороны, какие сервисы использует пользователь, а с другой стороны, - из каких процедур состоят сами сервисы.

Диаграммы классов (class diagrams) описывают статическую структуру системы, состоящую из сущностей (классов) системы, наделенных свойствами: поведением, абстрактностью, стереотипом, - и связей между сущностями, которые могут отражать наследование свойств, агрегацию и др. Классы могут объединяться в пакеты.

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

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

Диаграммы деятельности (activity diagrams) описывают последовательности выполнения действий сущностью, которые реализуются процедурами соответствующего класса.

Диаграммы взаимодействия (collaboration diagrams) описывают взаимодействия сущностей и их связи друг с другом, при этом отражаются отношения между ними.

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

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

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

Диаграммы развертывания (deployment diagrams) описывают структуру исполняемого программного обеспечения.

Результатом использования этих методологий на каждом этапе является построение набора моделей - Графических спецификаций, которые содержат наглядные описания различных аспектов разрабатываемых прикладных систем. Например, в рамках описания налоговой системы России с помощью вышеперечисленных диаграмм строятся модели технологических процессов решения функциональных задач, порядка исчисления налогов и принятия решений, порядка определения налогооблагаемой базы налогоплательщиков по информации из внешних источников, структуры и взаимодействия компонентов информационной системы налоговых органов и т.п.

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

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

CASE-СРЕДСТВА

Для автоматизированной поддержки всех этапов разработки АИС используются CASE-средства (CASE - Computer Aided System/Software Engineering). Целесообразность применения CASE-средств определяется возможностью концентрации сложности на начальных этапах разработки при относительно невысокой сложности и трудоемкости последующих этапов. Это достигается за счет более точного учета требований к создаваемой АИС, значительного снижения уровня системных ошибок в проекте до начала реализации и тем самым снижения общей трудоемкости разработки.

Применение CASE-средств при разработке ИС дает следующие преимущества:

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

К ключевым характеристикам CASE-средств можно отнести следующие.

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

Поддержка визуальных методов разработки. В основе CASE-средств лежат методологии, которые дают строгое и наглядное описание системы, начиная с первых шагов ее проектирования. Различные группы специалистов (аналитиков, проектировщиков, программистов и т.п.) получают единый язык для описания системы -строгий и наглядный. Широко используется графика - исчерпывающие и согласованные диаграммы, поддерживаемые детальными текстовыми материалами, которые в большинстве являются ссылками, а не основной частью спецификаций. Обеспечивается адекватная и согласованная структуризация АИС. Отдельные части спецификаций могут получаться независимо от других частей.

Автоматизация кодирования. Значительная доля затрат при разработке ИС связана с кодированием, т.е. с написанием текстов программ, компиляцией и отладкой. Если считать, что все принципиальные вопросы решены при проектировании до написания программ, то большая часть кодирования связана с рутинными операциями. CASE-технология предусматривает автоматизацию такого рутинного кодирования (автоматическая ко-догенерация) на базе спецификаций и проектных описаний будущей системы, также получаемых с помощью CASE-средств. В результате автоматической кодогенерации получают скелетные коды, содержащие описания данных и основную логику обработки, схемы баз данных, файлы - описания интерфейсов и др. Такие коды получают в виде текстов исходного языка, требующих уточнений, связанных, как правило, с особенностями среды реализации, либо в виде модулей, готовых к комплекси-рованию и исполнению. В некоторых случаях автоматическая кодогенерация дает до 90% кодов.

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

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

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

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

CASE-средства делятся на два класса:

• отдельные инструментальные средства предназначены для автоматизации разработки АИС на отдельных этапах: CASE-средства верхнего уровня поддерживают этапы анализа и проектирования, CASE-средства нижнего уровня - этапы кодирования и тестирования;
• интегрированные системы поддерживают разработку АИС на всех этапах.

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