Внедрение ИС Практическая работа №6-7

Тема: Сравнительный анализ методологий проектирования

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

Оборудование и материал: Персональный компьютер, сеть интернет.

Разработка программного обеспечения (англ. software engineering, software development) — это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, ис- пользуя технологии, методологию и практики из информатики, управления проектами, математики, инженерии и других областей знания.

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

Рациональный выбор возможен при понимании нескольких аспектов: 1 Целей проекта;

2 Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта;

1. Возможностей подхода с учетом требо- ваний п. 2;

2. Особенностей разрабатывае- мой/внедряемой информационной системы.

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

Важнейшими из подходов являются:

-структурный (функциональный),

-объектно-ориентированный.

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

дого из подходов в отдельности.

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

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

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

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

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

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

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

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

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

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

Применение универсальных графических языков моделирования IDEF0, IDEF3 и

DFD

Обеспечивает логическую целостность и полноту описания, необходимую для до-

стижения точных и непротиворечивых результатов на этапе анализа.

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

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

Каждый объект системы обладает своим собственным поведением, моделирующим поведение Рис. 1 Модель в нотации IDEF0 объекта реального мира.

Понятие "объект" впервые было использовано около 30 лет назад в технических средствах, при попытках отойти от традиционной архитектуры фон Неймана.

Следует заметить, что определений понятия "объект" существует несколько. Дадим определение объекта, придерживаясь мнения Гради Буча: "

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

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

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

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

структурная методология.

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

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

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

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

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

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

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

• collaboration diagram (диаграммы взаимодействий). Для этапа проектирования однозначно определены:

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

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

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

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

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

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

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

Сравнение подходов должно дать ответы на следующие вопросы:

1. На сколько сам подход и его нотации применимы для того или иного этапа проек- тирования ИС.

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

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

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

Оригинальное проектирование – все проектные решения разрабатываются «с нуля» в соответствии с требованиями к ИС. Типовое проектирование - предполагают создание системы из готовых типовых элементов (проектных решений)

Типовое проектирование – этап анализа сводится к сбору информации и утвержде- нии ее полноты и адекватности у Заказчика для настройки системы, для этого замечатель- но подходят средства объектно-ориентированного подхода. Благодаря наглядности моде- лей сотрудники Заказчика понимают модели и могут участвовать в их обсуждении (до- биться таких результатов при использование нотация структурного подхода практически невозможно).

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

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

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

Оригинальное проектирование – этап анализа имеет классический вид, необходи- мокачественное и полное построение

бизнес-процессов

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

1. Потребностями и целями проекта (либо это комплексное обследование и модели- рование с масштабными преобразованиями, либо качественный сбор информации и не- большие изменения), аспектами анализа и требованиями к информации;

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

Смешанное проектирование – новые модули разрабатываются по схеме оригиналь- ного проектирования, в остальном – типового проектирования.

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

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

Используя рассмотренные выше методы проектирования,разработчики выделили сам про- цесс разработки продукта как цикличный и окре- стили его моделью "водоворота" или "возвратной" моделью (рис.3).

Так же эту модель можно представить в виде спирали (рис.4).

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

ного процесса этапах проектирования, разработки и разра-

ботки анализа продук- та.

Наиболее гибким и динамичным методом разработки является метод экстре- мального программирования SCRUM.

Основателем и главным идеологом XP (eXtreme Programming) является Кент Бек (Kent Beck) - всемирно из-

вестный эксперт по языку Smalltalk и разработке объект-

но-ориентированных систем.

Другим видным пропагандистом XP является Мартин

Фаулер (Martin Fowler) - тожевсемирно признанный ученый-

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

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

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

В ХР конечный результат разработки не известен, точку поставить невозможно, по- этому итерационный метод разработки дает возможность отслеживать этапы развития продукта, аттестовать работу разработчиков, проводить анализ продукта и его тестирова- ние.

Спринт имеет вид (рис. 5):

В основе постановки задачи лежит идея. Для представления идеи в графическом виде используют- ся карты памяти.

Карты памяти (Mind Map). – это графический способ представления главной идеи и ее составРис.5. SCRUM спринт ляющих.

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

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

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

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

При разработке программного продукта могут возникать проблемы,решение кото- рых требует рассмотрения всех факторов, могущих создать проблему. Для рассмотрения проблем наиболее эффективным графическим методом является метод «диаграммы Иси- кавы».

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

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

В процессе выполнения ЗАДАНИЯ необходимо:

1. Подготовить исходные данные. Исходными данными для планирования являют-

ся:

1. Общее описание некоторой ИС (назначение, область применения, решаемые

задачи, технологические особенности реализации и внедрения).

1. Ограничения и условия разработки (требования заказчика, возможности ко- манды разработчиков, сроки разработки, бюджет проекта и т.д.).

1. Составить план разработки ИС с применением каскадного подхода:

   1. Составить эскизный план разработки ИС на основе каскадной модели ЖЦ.

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

   3. Для этапа «Проектирование» составить документ «Технический проект» с опи- санием проектных решений (архитектура системы, логическая структура базы данных, решения по реализации пользовательского интерфейса и т.д.).

   4. Для этапа «Тестирование» составить документ «План тестирования» с описанием методики тестирования и контрольных тестов.

   5. Для этапа «Внедрение» составить документ «План ввода ИС в эксплуатацию».

   6. Уточнить параметры календарного плана разработки ИС, учитывая ограниче- ния и условия разработки.

   7. Объединить календарный план разработки и составленные документы в еди- ный отчёт «Разработка ИС на основе каскадной модели ЖЦ».

2. Составить план разработки ИС с применением итеративного подхода:

   1. Разделить весь процесс создания и внедрения ИС на несколько итераций.

   2. На основе имеющихся документов (см. пункты 2.2 –2.5) для каждой итерации составить отдельный комплект документов.

   3. Составить календарный план итеративной разработки ИС.

   4. Объединить план итеративной разработки и составленные документы в единый отчёт «Разработка ИС на основе спиральной модели ЖЦ».

1. ИС «Телефонный справочник» (поисковая система).

2. ИС «Библиотека» (информационно-справочная система, поисковая система).

3. ИС «Издательство» (СЭДО, САБП).

4. ИС «Поликлиника» (СЭДО, информационно-справочная система).

5. ИС «Школа» (обучающая система, информационно-справочная система).

6. ИС»Ателье» (САБП).

7. ИС «Склад» (САБП).

1. ИС «Торговля» (САБП, СЭДО).

2. ИС «Автосалон» (САБП, СЭДО).

1. ИС «Продажа подержанных автомобилей» (информационно-справочная систе- ма, поисковая система).

2. ИС «Автосервис» (САБП).

3. ИС «Пассажирское автопредприятие» (САБП, СЭДО). 13 ИС «Диспетчерская служба такси» (ГИС, СЭДО).

1. ИС «Агентство по продаже авиабилетов» (информационно-справочная система, поисковая система).

2. ИС «Туристическое агентство» (информационно-справочная система, поисковая система).

3. ИС «Гостиница» (информационно-справочная система, СЭДО).

1. Перечислите основные этапы жизненного цикла программногообеспечения.

2. Какие модели жизненного цикла ПО вам известны, каковы их основные отличи- тельные особенности?

3. Что характеризует структурный подход к анализу программных систем? Какие ос- новные диаграммы описывают модель ПО при структурном анализе?

4. С какой стороны описывает программную систему DFD-диаграмма? Какие основ- ные элементы она использует?

5. Что такое ERD диаграмма? Для каких целей она включается в общую модель структурного анализ программной системы?

6. Назначение STD-диаграммы. Структура STD диаграммы.

7. Расскажите о результатах анализа программной системы из своего варианта к практического занятия.