Заключение

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

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

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

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

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

Третье отличие двух подходов заключается в структурной организации внутри модулей системы. В структурном подходе модуль состоит из функций, иерархически связанных между собой отношением композиции (англ. part-of – часть-целое), т. е. функция состоит из подфункций, подфункция из подподфункций и т.д. В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования (англ. is-a – это есть). При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры.

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

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

Наиболее существенное различие между разно­видностями структурного анализа заключается в их функциональности.

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

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

IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени.

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

2. В настоящее время объектный подход стал особенно популярен и характеризуется разработчиками как универсальное средство проектирования. Однако методология применения UML на этапах анализа и проектирования описана достаточно слабо (т.е. можно найти описание диаграмм, но логика их использования регламентируется слабо), поэтому рано говорить о UML как о действительно полноценной замене всем другим подходам.

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

• use case diagram (диаграммы прецедентов);

• activity diagram (диаграммы описаний технологий, процессов, функций);

• sequence diagram (диаграммы последовательностей действий);

• collaboration diagram (диаграммы взаимодействий).

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

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

Плюсом диаграммы является ее простота, наглядность и читабельность неспециалистами. Фактически является некоторым аналогом нотации IDEF0 (прецедент – работа, актер – один из механизмов).

Activity diagram – представляют собой схемы потоков управления в системе от действия к действию, а также параллельные и альтернативные потоки, с является неким аналогом нотаций IDEF0 и IDEF3. Т.е. понятие «перекресток» заменяется элементами «линия синхронизации» и «выбор», а «работа» - «действием». Диаграмма не очень приспособлена для отображения сложной логики, но возможно ее использование в качестве доступного для понимания аналога заказчику.

Дуги Use Case и Activity диаграмм не имеют смысловых типов, которые указаны для дуг IDEF0. Использование данных диаграмм требует установления дополнительных синтаксических соглашений, т.к. UML нежесткий язык и допускает построение синтаксически корректных Activity-диаграмм, не имеющих смысла или не поддающихся объяснению. Например, чтобы определить тип входящей стрелки, различать документы, можно их выделять цветом, использовать пунктирные и сплошные стрелки и т.п.

Sequence diagram – иллюстрирует события, инициирован­ные в системе исполнителями. Если изобразить диаграмму на абстрактном уровне в терминах предметной области, а систему рассматриваются как "черный ящик", то она является достаточно удобным инструментом для построения общей информационной модели. Т.е. входное сообщение является входной информацией в терминах IDEF0, а отклик системы (объекта) – выходной информацией.

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

Для этапа проектирования однозначно определены:

• State diagram (диаграммы состояний);

• Class diagram (диаграммы классов).

• Component diagram (диаграммы компонент);

• Deployment diagram (диаграммы развертывания).

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

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

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

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

6. В случае принятия решения о качественной необходимости использования методологии необходимо иметь ввиду, что ARIS нельзя отнести к интуитивно понятным, она требует времени на изучение, на осмысленное применение (вопрос хотя бы в том, что методология содержит больше 100 моделей!). Для успешного применения должны быть разработаны внутренние соглашения о моделировании и документировании