Сравнительный анализ графических методов проектирования информационных систем
This article represents a graphical methods for structural and object- oriented approach, the software analyzed. Given their comparative analysis. Recommended for software develop, analyze and restructuring.
Saved in:
| Published in: | Збірник наукових праць Інституту проблем моделювання в енергетиці ім.Г.Є.Пухова НАН України |
|---|---|
| Date: | 2009 |
| Main Authors: | , , |
| Format: | Article |
| Language: | Russian |
| Published: |
Інститут проблем моделювання в енергетиці ім. Г.Є. Пухова НАН України
2009
|
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/26516 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Сравнительный анализ графических методов проектирования информационных систем / Ю.Р. Валькман, А.В. Ланбина, Е.В. Потапчук // Збірник наукових праць Інституту проблем моделювання в енергетиці ім.Г.Є.Пухова НАН України. — К.: ІПМЕ ім. Г.Є.Пухова НАН України, 2009. — Вип. 52. — Бібліогр.: 13 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
nasplib_isofts_kiev_ua-123456789-26516 |
|---|---|
| record_format |
dspace |
| spelling |
Валькман, Ю.Р. Ланбина, А.В. Потапчук, Е.В. 2011-09-02T11:49:58Z 2011-09-02T11:49:58Z 2009 Сравнительный анализ графических методов проектирования информационных систем / Ю.Р. Валькман, А.В. Ланбина, Е.В. Потапчук // Збірник наукових праць Інституту проблем моделювання в енергетиці ім.Г.Є.Пухова НАН України. — К.: ІПМЕ ім. Г.Є.Пухова НАН України, 2009. — Вип. 52. — Бібліогр.: 13 назв. — рос. XXXX-0067 https://nasplib.isofts.kiev.ua/handle/123456789/26516 004.514 This article represents a graphical methods for structural and object- oriented approach, the software analyzed. Given their comparative analysis. Recommended for software develop, analyze and restructuring. ru Інститут проблем моделювання в енергетиці ім. Г.Є. Пухова НАН України Збірник наукових праць Інституту проблем моделювання в енергетиці ім.Г.Є.Пухова НАН України Сравнительный анализ графических методов проектирования информационных систем Article published earlier |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| title |
Сравнительный анализ графических методов проектирования информационных систем |
| spellingShingle |
Сравнительный анализ графических методов проектирования информационных систем Валькман, Ю.Р. Ланбина, А.В. Потапчук, Е.В. |
| title_short |
Сравнительный анализ графических методов проектирования информационных систем |
| title_full |
Сравнительный анализ графических методов проектирования информационных систем |
| title_fullStr |
Сравнительный анализ графических методов проектирования информационных систем |
| title_full_unstemmed |
Сравнительный анализ графических методов проектирования информационных систем |
| title_sort |
сравнительный анализ графических методов проектирования информационных систем |
| author |
Валькман, Ю.Р. Ланбина, А.В. Потапчук, Е.В. |
| author_facet |
Валькман, Ю.Р. Ланбина, А.В. Потапчук, Е.В. |
| publishDate |
2009 |
| language |
Russian |
| container_title |
Збірник наукових праць Інституту проблем моделювання в енергетиці ім.Г.Є.Пухова НАН України |
| publisher |
Інститут проблем моделювання в енергетиці ім. Г.Є. Пухова НАН України |
| format |
Article |
| description |
This article represents a graphical methods for structural and object-
oriented approach, the software analyzed. Given their comparative analysis.
Recommended for software develop, analyze and restructuring.
|
| issn |
XXXX-0067 |
| url |
https://nasplib.isofts.kiev.ua/handle/123456789/26516 |
| citation_txt |
Сравнительный анализ графических методов проектирования информационных систем / Ю.Р. Валькман, А.В. Ланбина, Е.В. Потапчук // Збірник наукових праць Інституту проблем моделювання в енергетиці ім.Г.Є.Пухова НАН України. — К.: ІПМЕ ім. Г.Є.Пухова НАН України, 2009. — Вип. 52. — Бібліогр.: 13 назв. — рос. |
| work_keys_str_mv |
AT valʹkmanûr sravnitelʹnyianalizgrafičeskihmetodovproektirovaniâinformacionnyhsistem AT lanbinaav sravnitelʹnyianalizgrafičeskihmetodovproektirovaniâinformacionnyhsistem AT potapčukev sravnitelʹnyianalizgrafičeskihmetodovproektirovaniâinformacionnyhsistem |
| first_indexed |
2025-11-26T04:08:17Z |
| last_indexed |
2025-11-26T04:08:17Z |
| _version_ |
1850611080483569664 |
| fulltext |
УДК 004.514
Ю. Р. Валькман, д.т.н., зав. отд., А. В. Ланбина, аспирант, Е. В. Потапчук,
аспирант, Международный научно-учебного центр информационных
технологий и систем НАН и МОН Украины
СРАВНИТЕЛЬНЫЙ АНАЛИЗ ГРАФИЧЕСКИХ МЕТОДОВ
ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ
This article represents a graphical methods for structural and object-
oriented approach, the software analyzed. Given their comparative analysis.
Recommended for software develop, analyze and restructuring.
Введение. Данная работа представляет собой краткое изложение
исследования и классификации методов графического представления знаний
в компьютерных технологиях.
Объектом исследования является графическое представление знаний в
компьютерных технологиях. Предмет исследования – методы графического
представления знаний при проектировании информационных систем в
компьютерных технологиях. Цель исследования – Классифицировать методы
графического представления знаний на примере процесса разработки
программного продукта украинской компанией. Ожидаемые результаты –
таблица областей применения на практике методов графического
представления знаний, выявление преимуществ и недостатков различных
методов на этапах разработки.
На сегодняшний день в украинских компаниях – разработчиках ПО
происходят серьезные изменения в подходе как к процессу разработки, так и
к самой разработке. Сегодня для того, чтобы сохранить
конкурентоспособность на рынке и удержать своих клиентов, необходимо
соответствовать ряду требований: четко и однозначно понимать задачу (это
касается как разработчика, так и клиента), предоставлять клиенту понятный
отчет о стадиях и этапах разработки, укладываться в поставленные сроки,
иметь возможность рассчитать производительность своей команды
разработчиков, моделировать реакцию системы на изменения и рассчитывать
сроки реализации изменений. Список можно продолжать и дальше, но
основной проблемой, из которой произрастают все остальные, все же
является отсутствие моделирования. Возможно, исследование методов
графического представления знаний позволит классифицировать методы,
используемые на разных стадиях моделирования.
1. Понятие разработки программного обеспечения
Разработка программного обеспечения (англ. software engineering,
software development) — это род деятельности (профессия) и процесс,
направленный на создание и поддержание работоспособности, качества и
надежности программного обеспечения, используя технологии, методологию
и практики из информатики, управления проектами, математики, инженерии
и других областей знания. [1]
В разработке программного обеспечения выбор методов определяется
целями проекта и в значительной мере влияет на весь его дальнейший ход.
Рациональный выбор возможен при понимании нескольких аспектов:
1. Целей проекта;
2. Требований к информации необходимой для анализа и принятия
решений в рамках конкретного проекта;
3. Возможностей подхода с учетом требований п. 2;
4. Особенностей разрабатываемой/внедряемой информационной
системы.
В настоящее время используется большое количество методов
(подходов), которые позволяют, так или иначе, создавать модели бизнес-
процессов предприятий. Как бы то ни было, их использование гарантирует
стандартизированный подход к описанию, позволяет накапливать опыт и
практические навыки и на протяжении длительного времени обеспечивать
понимание созданных моделей другими сотрудниками.
Важнейшими из подходов являются:
структурный (функциональный),
объектно-ориентированный.
Т.к. каждый подход регламентируется разработчиками как методология,
подходящая для анализа и проектирования, то имеет смысл подробнее
остановиться на рассмотрении каждого из подходов в отдельности.
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.Объектно-ориентированный
подход
Принципиальное различие
между структурным и объектно-
ориентированным подходом за-
ключается в способе декомпози-
ции системы. Объектно-ориен-
тированный подход использует
объектную декомпозицию, при
этом статическая структура
системы описывается в
терминах объектов и связей
между ними, а поведение
системы описывается в
терминах обмена сообщениями
между объектами. Каждый
объект системы обладает своим
собственным поведением,
моделирующим поведение
объекта реального мира.
Понятие "объект" впервые
было использовано около 30 лет назад в технических средствах, при
попытках отойти от традиционной архитектуры фон Неймана.
Следует заметить, что определений понятия "объект" существует
несколько. Дадим определение объекта, придерживаясь мнения Гради Буча: "
Объект – осязаемая сущность, которая четко проявляет свое поведение"
По определению признанного авторитета в области объектно-
ориентированных методов разработки программ Гради Буча "объектно-
Рис. 1 Модель в нотации IDEF0
ориентированное программирование (ООП) — это методология
программирования, которая основана на представлении программы в виде
совокупности объектов, каждый из которых является реализацией
определенного класса (типа особого вида), а классы образуют иерархию на
принципах наследуемости".
Объектно-ориентированная методология (ООМ) так же, как и
структурная методология, была создана с целью, дисциплинировать процесс
разработки больших программных комплексов и тем самым снизить их
сложность и стоимость.
ООМ преследует те же цели, что и структурная, но решает их с другой
отправной точки и в большинстве случаев позволяет управлять более
сложными проектами, чем структурная методология.
UML (Unified Modeling Language) –стандартная нотация визуального
моделирования программных систем, принятая консорциумом Object
Managing Group (OMG) в 1997г.
UML предоставляет средства для создания визуальных моделей,
которые единообразно понимаются всеми разработчиками, вовлеченными в
проект, и являются средством коммуникации в рамках проекта. Диаграмма в
UML (рис.2) - это графическое представление набора элементов. Диаграммы
рисуют для визуализации системы с разных точек зрения. При визуальном
моделировании на UML используются восемь видов диаграмм, каждая из
которых может содержать элементы определенного типа.
В языке UML для этапов анализа предназначены следующие виды
диаграмм:
· use case diagram (диаграммы прецедентов);
· activity diagram (диаграммы описаний технологий, процессов,
функций);
Рис. 2. UML диаграмма классов
· sequence diagram (диаграммы последовательностей действий);
· collaboration diagram (диаграммы взаимодействий).
Для этапа проектирования однозначно определены:
· state diagram (диаграммы состояний);
· class diagram (диаграммы классов).
· component diagram (диаграммы компонент);
· deployment diagram (диаграммы развертывания).
В настоящее время объектный подход стал особенно популярен и
характеризуется разработчиками как универсальное средство
проектирования. Однако методология применения UML на этапах анализа и
проектирования описана достаточно слабо (т.е. можно найти описание
диаграмм, но логика их использования регламентируется слабо), поэтому
рано говорить о UML как о действительно полноценной замене всем другим
подходам.
Основной диаграммой UML является Class diagram, которая является
основой для генерации кода и основной целью проектирования. Является
визуальным представлением идеи объектно-ориентированного
проектирования и программирования. Действительно плюсом является
легкость исправления проектного решения в соответствии с изменившейся
бизнес-логикой, т.к. в динамически построенной модели нет необходимости
полной перестройки, присущей нотациям структурного подхода. В частности,
изменение отдельных классов и связей между ними не затронет общей
концепции модели.
4. Сравнительный анализ подходов к проектированию программного
обеспечения
Сравнение подходов должно дать ответы на следующие вопросы:
1. На сколько сам подход и его нотации применимы для того или иного
этапа проектирования ИС.
2. Что является критерием для выбора подхода в случае, когда возможно
применение более одного подхода (какой подход применить лучше).
Т.к. каждый подход регламентируется разработчиками как методология,
подходящая для анализа и проектирования, то имеет смысл подробнее
остановиться на нотациях. В Таблице 1 представлено сравнение нотаций,
применяемых для анализа ИС.
Табл. 1. Сравнительный анализ нотаций IDEF, Sequence и Activity diagram
№ Критерии
сравнения
IDEF0 IDEF3 Sequence
diagram
Activity diagram
1 Принцип
построения
диаграммы
Принцип
иерархической
упорядоченно-
сти
Последовате-
льность
выполнения
Последовате-
льность
выполнения
Последователь-
ность выполне-
ния
2 Описание
процедуры
Объект на
диаграмме
Объект на
диаграмме
Объект на
диаграмме
Объект на
диаграмме
процесса
3 Входящий
документ
Стрелка
слева, стрелка
сверху
Нет (может
быть отражен
привязкой
объекта)
В
зависимости
от принятого
соглашения
может быть
объектом или
стрелкой
Может быть
объектом или
стрелкой
4 Входящая
информация
Стрелка
слева, стрелка
сверху
Нет (может
быть отражен
привязкой
объекта)
Может быть
объектом или
стрелкой
Может быть
объектом или
стрелкой
5 Исходящий
документ,
информация
Стрелка
справа
Нет (может
быть отражен
привязкой
объекта)
Может быть
объектом или
стрелкой
Может быть
объектом или
стрелкой
7 Исполнитель
процедуры
Стрелка
снизу
Нет (может
быть отражен
в модели
только
привязкой
объекта-
комментария)
Используется
отдельный
объект
«Actor»
Разграничение
зон на диаграмме
8 Используемое
оборудование
Стрелка
снизу
Нет (может
быть отражен
привязкой
объекта)
- -
9 Управление
процедурой
Стрелка
сверху
Только
логика
процесса
Только
логика
процесса
Только логика
процесса
10 Контроль
выполнения
процедуры
Стрелка
сверху
Нет Нет. Может
быть отражен
указанием
входящих
документов
Нет. Может быть
отражен
указанием
документов
11 Обратная
связь по
управлению/к
онтролю
Стрелка
сверху
Нет Нет. Может
быть отражен
указанием
входящих
документов
Нет. Может быть
отражен
указанием
входящих
документов
12 Наглядность
модели
Модель
нечитабельна
неспециалиста
ми
Модель
нечитабельна
неспециалист
ами
Модель
наглядна, но
несколько
громоздка
Модель очень
наглядна
Позиционирование подходов можно провести по отношению к решению
задачи моделирования бизнес-процессов на этапе анализа и проектирования
(в соответствии с проведенным выше анализом) следующим образом (табл.
2).
Табл. 2. Позиционирование подходов относительно типов проектов
Подход
Тип проекта *
Структурный
подход
Объектно-
ориентированный
подход
Типовое
проектирование
▼ ∆
Оригинальное
проектирование
▼ ∆
Смешанное
проектирование
▼ ▼ ∆
▼ – анализ ∆ - проектирование
* Оригинальное проектирование – все проектные решения
разрабатываются «с нуля» в соответствии с требованиями к ИС. Типовое
проектирование - предполагают создание системы из готовых типовых
элементов (проектных решений)
Типовое проектирование – этап анализа сводится к сбору информации и
утверждении ее полноты и адекватности у Заказчика для настройки системы,
для этого замечательно подходят средства объектно-ориентированного
подхода. Благодаря наглядности моделей сотрудники Заказчика понимают
модели и могут участвовать в их обсуждении (добиться таких результатов
при использование нотация структурного подхода практически невозможно).
Выбор обуславливается еще и тем, что легко перейти к этапу
проектирования и инструмент будет единый. Проектирование -
непосредственно проработка настроек системы, т.е. реализация бизнес-
процессов Заказчика в рамках внедряемой системы. Использование
структурных нотаций нецелесообразно и избыточно. Примером такого
проекта может служить внедрение системы «1С».
Оригинальное проектирование – этап анализа имеет классический вид,
необходимо качественное и полное построение бизнес-процессов
организации с проведением их реинжиниринга. Для правильного и точного
выявления и формализации требований хорошо подходят нотации
структурного подхода. Выбор будет обуславливаться:
1. Потребностями и целями проекта (либо это комплексное обследование
и моделирование с масштабными преобразованиями, либо качественный сбор
информации и небольшие изменения), аспектами анализа и требованиями к
информации;
2. Предпочтениями аналитиков и наличием инструментальных средств.
Главной целью формирования моделей ИС является обеспечение
перехода от моделей описания организации к системе моделей, описывающих
конкретные компоненты проекта, такие как приложения, базы данных, при
котором обеспечивается отображение задач организации в функции и
компоненты ИС (этап проектирования ИС). Этап проектирования в обоих
случаях основан на использовании языка UML и наиболее удачной методики
Лармана.
Смешанное проектирование – новые модули разрабатываются по схеме
оригинального про-
ектирования, в ос-
тальном - типового
проектирования.
Проведенный
анализ сильных и
слабых сторон стру-
ктурного, объектно-
ориентированного
подходов является
основой технологии
проектирования ИС с использованием CASE – технологий.
Предложенная схема использования подходов к проектированию ИС
обеспечивает снижение сложности процесса создания ИС, существенно
повышает эффективность проекта и помогает избежать ненужных,
избыточных действий благодаря
оптимальному выбору инструментов в
зависимости от типа проекта.
Используя рассмотренные выше
методы проектирования, разработчики
выделили сам процесс разработки продукта
как цикличный и окрестили его моделью
"водоворота" или "возвратной" моделью
(рис.3).
Так же эту модель можно представить
в виде спирали (рис.4).
Такой подход к разработке
программного обеспечения требует
максимальной гибкости на всех стадиях и
этапах проектирования, разработки и
анализа продукта.
Наиболее гибким и динамичным методом разработки является метод
экстремального программирования SCRUM.
Основателем и главным идеологом XP (eXtreme Programming) является
Кент Бек (Kent Beck) - всемирно известный эксперт по языку Smalltalk и
разработке объектно-ориентированных систем. Другим видным
пропагандистом XP является Мартин Фаулер (Martin Fowler) - тоже
всемирно признанный ученый-исследователь и автор многочисленных
Рис.4. Модель
спирального процесса
разработки
Рис.3. Модель возвратного процесса разработки.
публикаций на темы ОО систем, паттернов, UML и реструктуризации
программ.
XP - это настоящая методология, и она имеет определенный набор
действий, которые должны выполняться соответствующим образом. В
отличие от других методологий XP требует дисциплину и самоотдачу,
сравнимую со спартанской, потому что нет никаких формальных процедур,
регламентирующих процесс.
Суть метода заключается в разбивке процесса разработки программного
продукта на итерации с четко поставленной задачей – спринты. Иными
словами, спринт – это «забег» в разработке на 2-3 недели для реализации
поставленных на время спринта задач.
В ХР конечный результат разработки не известен, точку поставить
невозможно, поэтому итерационный метод разработки дает возможность
отслеживать этапы развития продукта, аттестовать работу команды
разработчиков, проводить анализ продукта и его тестирование.
Спринт имеет вид (рис. 5):
В основе постановки
задачи лежит идея.
Для представления
идеи в графическом
виде используются
карты памяти.
Карты памяти
(Mind Map). – это
графический способ
представления глав-
ной идеи и ее состав-
ляющих. Каждому
процессу разработки
предшествует Идея, которая может быть представлена в графическом виде
карт памяти.
Используя такой метод графического представления можно представить
будущую структуру программного продукта и приступать к его
формализованному представлению.
В качестве примера карт памяти автором была представлена идея
создания всеукраинского портала 212.ua (рис.6):
Рис.5. SCRUM спринт
При разработке программного продукта могут возникать проблемы,
решение которых требует рассмотрения всех факторов, могущих создать
проблему. Для рассмотрения проблем наиболее эффективным графическим
методом является метод «диаграммы Исикавы».
В данном случае на низкую скорость БД могут влиять семь основных
факторов, которые, в свою очередь, состоят из двух и более причин.
Заключение. Используя различные методы графического
представления знаний на разных этапах разработки программного
обеспечения, можно составить сравнительную таблицу методов для всех
этапов разработки:
MindMap Когнитивные
карты
UML Схемы
Исикавы
IDEF0
(SADT)
Scrum
Идея + + - - - -
Декомпозиция цели
(идеи)
+ + - - - -
Рис.6. Карта памяти идеи создания портала 212.ua
Рис.7. Схема Исикавы
Отношеия между
обьектами системы
- + + + + -
Модель разработки
(бизнес-модель)
+ + + - - -
Модель разработки
ПО
- - + - + -
Разработка ПО - - + - + +
Атестация - - + - + +
Анализ + + + - - -
Модернизация ПО + + + - + +
В настоящей работе мы рассмотрели применение подходов
проектирования, которые позволяют, так или иначе, создавать модели
бизнес-процессов предприятий. Как бы то ни было, их использование
гарантирует стандартизированный подход к описанию, позволяет
накапливать опыт и практические навыки и на протяжении длительного
времени обеспечивать понимание созданных моделей другими
сотрудниками.
Так же отдельно хочется выделить не относящуюся к CASE
технологиям методику Mind Map, которая позволяет на ранних этапах
проектирования четко спланировать последовательность проектирования и
этапы. В сравнительном анализе мы не рассматриваем Mind Map, т.к.
технология не имеет четкой документации и жесткого синтаксиса, хотя
решает многие задачи проектирования не хуже прочих CASE технологий.
1. Иан Соммервилл Инженерия программного обеспечения = Software Engineering. –
6-е изд. – М.: «Вильямс», 2002. – С. 642.
2. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и
приложений. "СУБД", 1995, №3.
3. Вендеров А.М. CASE-технологии. Современные методы и средства
проектирования информационных систем [Текст] / А.М. Вендеров ─ М.: Финансы
и статистика, 1998.
4. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования.
Учебное пособие. М., Центр Информационных Технологий, 1996
5. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и
применение). М., "Лори", 1996.
6. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М.,
"МетаТехнология", 1993.
7. Международные стандарты, поддерживающие жизненный цикл программных
средств. М., МП "Экономика", 1996
8. Создание информационной системы предприятия. "Computer Direct", 1996, N2
9. Сравнительный анализ подходов к проектированию ИС Рябышева И.В.
10. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в
состояниях. Киев, "Диалектика", 1993.
11. Сравнительный анализ известных инструментов организационного
проектирования, Сергей Рубцов, 2005
12. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование
бизнес-процессов, 2004
13. Воробович Н.П. Основы создания прикладных систем обработки данных.
Лабораторный практикум [Текст] / Н.П.Воробович ─ Красноярск: СибГТУ; 2003.
|