Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (ПОНЯТИЕ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ И ЕЕ ОСОБЕННОСТЕЙ).pdf
Добавлен: 27.06.2023
Просмотров: 67
Скачиваний: 2
Механизм состояния определяет набор понятий, которые могут быть использованы для моделирования дискретного поведения с использованием конечных систем переходного состояния. Экземпляры событий генерируются в результате определенного действия внутри системы или ее среды. Затем мероприятие фокусируется на одной или нескольких целях. Средства, с помощью которых события переносятся в пункт назначения, зависят от типа действия, цели, свойств среды связи и многих других факторов.
В некоторых случаях это происходит в любое время практически сразу же, однако в других случаях возможны задержки передачи, потеря событий, переупорядочивание или дублирование. Полная гибкость поддерживается при моделировании различных типов коммуникационных возможностей. Событие принимается, если оно находится в очереди событий по назначению. Событие отправляется, если оно извлекается из очереди событий и доставляется в механизм состояния для обработки. С этой точки зрения это называется текущим событием. Наконец, событие расходуется, если его обработка завершена. Поглощенное событие становится недоступным для обработки. Никакие требования не предъявляются к временным интервалам между получением события, отправкой и поглощением.
Состояние становится активным, если оно вводится в результате перехода и неактивно, если оно завершается в результате перехода. Состояние может быть завершено и начато в результате одного и того же перехода. Диаграммы состояний представляют объекты, способные к динамическому поведению, указывая соответствующий ответ на прием экземпляров событий. Обычно они используются для описания поведения классов. Состояние является условием в течение жизни объекта или взаимодействие, в течение которого оно удовлетворяет условию, выполняет определенное действие или ожидает определенное событие.
Средства анализа и проектирования ЭИС созданы для поддержки моделирования систем на этапах жизненного цикла программного обеспечения. Они поддерживают создание, редактирование и анализ графических обозначений, используемых в структурных методах. Инструменты анализа и проектирования часто поддерживают только определенные методы проектирования и анализа, например такие как объектно-ориентированные. Другими инструментами являются универсальные системы редактирования для многих типов диаграмм, которые используются различными методами проектирования и анализа. Инструментально-ориентированные методы обычно автоматически поддерживают правила и основные принципы этих методов, которые позволяют автоматически контролировать графики.
Инструменты обычно объединяются через общий репозиторий, структура которого является собственностью разработчика пакета инструментов. Центральный репозиторий позволяет дизайнеру найти нужный проект, компонент и соответствующую информацию о проекте. Как правило, системы баз данных, такие как Sybase или Oracle, используются для создания общего хранилища инструментов. Эти инструментальные средства содержат большое количество инструментов языка программирования четвертого поколения, предназначенных для создания программного кода на основе архитектуры системы, а также могут создавать базы данных. Пакеты инструментальных средств обычно закрыты, т.е. не рассчитаны на добавление пользователями собственных инструментов или на изменение средств пакета, в который входят:
- редакторы диаграмм, предназначенные для создания диаграмм потоков данных, иерархий объектов, диаграмм "сущность-связь", эти редакторы не только имеют средства рисования, но и поддерживают различные типы объектов, используемых в диаграммах;
- средства проектирования, анализа и проверки выполняют проектирование ПС и создают отчеты об ошибках и дефектах в системной архитектуре, они могут работать совместно с системой редактирования, поэтому обнаруженные ошибки можно устранять на ранней стадии процесса проектирования;
- словарь данных хранит информацию об объектах, которые используются в структуре системы;
- средства генерирования отчетов на основе информации из центрального репозитория автоматически генерируют системную документацию;
- средства создания форм определяют форматы документов и экранных форм;
- средства импортирования и экспортирования позволяют обмениваться информацией из центрального репозитория различным инструментальным средствам;
- генераторы программного кода автоматически генерируют программы на основе проектов компонентов, хранящихся в центральном репозитории.
В некоторых случаях возможно генерировать программы или фрагменты программ на основе информации, представленной в системной модели. Поскольку в моделях не предусмотрена детализация низкого уровня, генератор программного кода не в состоянии сгенерировать законченный комплекс программ. Обычно необходимы программисты для завершения автоматически сгенерированных программ [9,10].
Средства автоматизации проектирования приложений (CASEтехнологии) предназначены для анализа предметной области, проектирования и генерации программных реализаций. Новые тенденции в реализации приложений связаны с промышленным характером разработки программного обеспечения.
Среди существующих инструментальных средств такого типа целесообразно выделить следующие:
-
- технологический комплекс разработки программного обеспечения RUP (RationalUnifiedProcess) фирмы RationalSoftware;
- технология разработки программного обеспечения ExtremeProgramming (XP);
- комплектспециальныхинструментальныхсредствразработки динамических систем – DSDM (DynamicSystemDevelopmentMethod).
Один из способов проектированияэкономической информационной системы - RUP (Rational Unified Process), разработанный Rational Corporation на базе унифицированного языка моделирования UML. Это итеративный метод для объектно-ориентированных систем, который использует сценарии для моделирования требований и построения основы системы.
Жизненный цикл разработки ЭИС по методологии RUP делится на четыре этапа: начало, проектирование, построение и переход (внедрение) (рис.2.2). Затем каждая фаза делится на итерации. Каждая итерация имеет цель создать неотъемлемую часть программного обеспечения. Время, необходимое для каждой итерации, может составлять от двух до 26 недель .
Рисунок 2.2. Жизненный цикл разработки ПО ЭИС RUP
Рассмотрим чуть более подробно процессы, которые происходят на каждой фазе разработки программного обеспечения для ЭИС по данной методологии:
1. Начальная фаза (фаза анализа предметной области, процесса или системы и планирования требований которые она должна будет удовлетворять после реализации ПО).Это первоначальный этап на котором в первую очередь происходит знакомство с экономической информационной системой, другими словами определяется и изучается ее текущее состояние, функции и задачи, которые она выполняет на этом этапе рассмотрения. Осуществляется определение наиболее важных вариантов использования системы, которые необходимо будет реализовать дополнительно, каким сделать реорганизацию, а какие возможно вообще исключить из системы из-за их не востребованности или отсутствии их необходимости в перспективе. После чего производиться первоначальный расчет общей стоимость проекта по планируемым изменениям, более конкретно формулируются и определяются его цели, задачи и осуществляется корректноеобоснование разработки проекта как такового. Так же в первоначальном варианте определяются возможные, необходимые ресурсы для проектирования и разработки.
2. Фаза проектирования (развития, уточнения). На этом этапе уже разработчики внимательно изучают систему, первоначально ознакомившись с существующим описанием текущего состояния, изучают и оценивают сложность предполагаемых изменений, варианты их реализации, после чего определяют системную архитектуру и определяют системную плоскость. Это достаточно важный этап для RUP, потому что уже на данном этапе осуществляют определение и анализ рисков которые могут возникнуть в процессе реализации системы или после ее внедрения.
3. Фаза построения (разработки). На этом этапе завершаются все работы по разработке, все части интегрированы. Происходит выпуск предварительных версий ПО ЭИС.
4. Фаза внедрения (перехода). На этом этапе программное обеспечение является полностью работоспособным.Изменения могут вноситься, если пользователи ЭИС дают какую-либо обратную связь, и если все еще существует какая-либо критическая проблема. Проводятся бета-тесты ПО, обучения и тренинги для пользователей, а также подготавливается техническая документация для пользователей [11].
Рассмотрим плюсы и минусы использования такого подхода при проектировании и создании ЭИС (табл.2.1):
Таблица 2.1. Плюсы/минусы методологии RUP:
|
Плюсы использования RUP |
Минусы использования RUP |
|
|
В качестве графической нотации в RUP используется Unified Modeling Language (UML), являющийся стандартом для представления объектных моделей. В UML артефакты разработки представляются диаграммами, описывающими структуру программы и ее поведение. В рамках данного средства существует большое количество вариантов нотаций диаграмм, которые позволяют достаточно детально описать компоненты, состав и процессы программ.
Экстремальное программирование − это один из дисциплинированных способовпроектирования и разработки программного обеспечения ЭИС, который упрощает проект и документацию по нему, создает акцент на коммуникации больше чем на документировании процессов, дает быструю обратную связь, и именно поэтому создает благоприятные условия для создания ПО. Такой способ объединяет всю команду разработчиков с простой практикой, где они получают достаточную обратную связь, и могут определить на каком они сейчас уровне и как достичь цели.Возникновение экстремального программирования вызвано некоторыми проблемами, которые возникали в традиционных методах, имеющих длительный жизненный цикл разработки.
Жизненный цикл проектирования и разработки ПО ЭИС в рамках экстремального программирования состоит из следующих фаз (рис. 2.3):
Рисунок 2.3. Жизненный цикл проекта в соответствии с методологией Экстремального программирования
Рассмотрим более подробнее данные фазы:
1. Стадия исследования. На этом этапе клиент записывает требованиям к разрабатываемой системе, создается так называемая карта пользовательских историй. Команда разработчиков решает, какие инструменты и технологии будут использованы и какие свойства системы будут реализованы в ближайшее время. Таким образом, технологии тестируются и система визуализируется путем создания прототипа. В зависимости от размера проекта эта фаза может занять от нескольких недель до нескольких месяцев, зависит от ситуации в проекте и технологии.
2. Стадия планирования. Как и на этапе исследования, пользователь записывает истории требований, в соответствии с которыми эти истории распределяются по приоритетам в соответствии с требованиями системы и содержанием исходного выпуска. Затем команда разработчика оценивает требование и работает для первого выпуска и управляет расписанием времени и ресурсов. Эта фаза занимает пару дней, и первый релиз ПО ЭИС выходит через примерно два месяца.
3. Стадия реализации. На этом этапе расписание разработки ПО делится на несколько итераций. И в первой итерации создается архитектура системы, и это будет результат выбранных пользовательских историй, которые фокусируют разработчиков на структуре требуемой системы. Клиент решает, какие истории должны быть включены в каждую итерацию и какие необходимые тесты стоит разработать и применить к коду после каждой итерации. Каждая итерация занимает примерно 3-4 недели, и ЭИС будет готова к использованию в конце последней итерации.
4. Стадия продуцирования.На этом этаперазрабатываемая система готова к первому выпуску, но перед выпуском тестируется.При возникновении новых идей и предложений, происходит их фиксация для позднейшей реализации. Команда разработчиков XP проводит работу с обеих сторон: на стороне поддержки клиентов, а также на стороне разработки и внедрения новых итераций. Это может снизить скорость работы разработчиков и, как следствие, привести к расширению команды и ее реструктурированию.По окончанию этапа происходит документирование всех результатов, завершение всех работ по дизайну, архитектуре и коду ПО ЭИС [12].
Рассмотрим преимущества и недостатки XP методологии разработки ПО ЭИС(табл. 2.2):
Таблица 2.2 . Плюсы/минусы рассматриваемой методологии XP