Сравнение структурного и объектно-ориентированного подходов к проектированию ИС

Государственное Общеобразовательное Учреждение Высшего  Профессионального Образования 

Московский  Государственный Технологический  Университет

«Станкин» 
 
 

Факультет «Информационных  Технологий»

Кафедра «Информационные  системы»

Дисциплина  «Проектирование Информационных систем» 
 
 

курсовая  работа

на  тему:

«Сравнение структурного и объектно-ориентированного подходов к проектированию ИС» 
 
 
 

Выполнил:

Проверил: Косульников Ю.А. 
 
 
 

МОСКВА, 2011г. 
 
 

     Содержание: 
 
 
 
 

1. Введение в проблему……………………………………………………………………….3 
 

2. Подходы к проектированию ИС…………………………………………………………..4 
 

2.1  Структурный (функциональный) подход……………………………………………....4 
 

2.2   Объектно-ориентированный подход…………………………………………………..6 
 

3.   Сравнительный анализ подходов к проектированию ИС……………………………..9 

4.  Позиционирование подходов относительно типов проектов………………………...13 

5.   Заключение………………………………………………………………………………13 

6.    Список используемой литературы…………………………………………………….14                          
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

ВВЕДЕНИЕ  В ПРОБЛЕМУ  

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

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

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

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

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

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

ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ИС 

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

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

1.                  Структурный (функциональный) подход  

   Сущность  подхода

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

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

   ·        SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF0) применяется для  определения требований (функций) для разработки системы, реализующей выделенные функции. Для уже существующих - IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм (рис.1). Вершина этой древовидной структуры, представляющая собой самое общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция). 
 
 
 
 
 
 
 
 
 
 

 

Рис.1 Модель в нотации IDEF0  
 

   ·        DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

   ·        IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций.

   ·        ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).  

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

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

   Выводы  по диаграммам:

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

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

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

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

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

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

2.                  Объектно-ориентированный подход  

   Сущность  подхода  

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

   

Рис. 2  Сравнительный анализ объектно-ориентированной и функционально-ориентированной декомпозиций   

   В 90-е годы появилось большое количество различных методологий с собственными наборами нотаций. Самые популярные – ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсону).

     UML (Unified Modeling Language) –стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) в 1997г.

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

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

      Общие выводы: в настоящее время объектный подход стал особенно популярен и характеризуется разработчиками как универсальное средство проектирования. Однако методология применения 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-диаграмм, не имеющих смысла или не поддающихся объяснению. Например, чтобы определить тип входящей стрелки, различать документы, можно их выделять цветом, использовать пунктирные и сплошные стрелки и т.п.