Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 18.06.2023

Просмотров: 39

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

Диаграммы деятельности - это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают блок-схемы, но принципиальная разница между диаграммами деятельности и нотацией блок-схем заключается в том, что первые поддерживают параллельное процессы (Фаулер M. UML Основы, 3 е издание. – Пер. с англ. – СПб: Символ Плюс, 2004. – С. 139).

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

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

Для моделирования работы склада создадим диаграмму деятельности материально ответственного лица. На рисунке 2 приведена диаграмма приема/поставки товара, а на рисунке 3 – выдачи/получения.

Рисунок 2

Рисунок 3

Из описаний выше составляем диаграмму классов для нашей модели, рисунок 4.

Классами называются базовые элементы любой объектно-ориентированной системы. Класс — это множество объектов, связанных общностью свойств, поведения, связей и семантики (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2006 - С. 167).

В рамках модели каждому классу присваивается уникальное имя, отличающее его от других классов.

Графически класс представляет собой прямоугольник, разделенный на три части: имя класса, его атрибуты и операции.

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

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


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

Диаграмма классов описывает типы объектов системы и различного рода статические отношения, которые существуют между ними. На диаграммах классов отображаются также свойства классов, операции классов и ограничения, которые накладываются на связи между объектами (Фаулер M. UML Основы, 3 е издание. – Пер. с англ. – СПб: Символ Плюс, 2004. – С. 62).

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

Мощность показывает, как много объектов участвует в связи. Мощность - это число объектов одного класса, связанных с одним объектом другого класса. Для каждой связи можно обозначить два показателя мощности - по одному на каждом конце связи. В языке UML приняты следующие нотации для обозначения мощности (Вендров А. М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2006 - С. 173 - 174).

Значения мощности:

  • * - много;
  • О - нуль;
  • 1 - один;
  • 0..* - нуль или больше;
  • 1..* - один или больше;
  • 0..1 – нуль или один;
  • 1..1 – ровно один.

В большинстве случаев мощности определяются своими нижней и верхней границами. Нижняя граница может быть нулем или положительным числом, верхняя граница представляет собой положительное число или * (без ограничений). Если нижняя и верхняя границы совпадают, то можно указать одно число; поэтому 1 эквивалентно 1..1, а * является сокращением 0..*.

В рассматриваемом примере классами являются: поставщик, получатель материально-ответственное лицо, карточка складского учёта, приходный и расходный ордера, справочник товаров. В каждом классе есть свои атрибуты и операции. Например, у класса поставщик имеются атрибуты: наименование организации, юридический адрес, телефон/факс, расчётный счёт; операции: AddSuplier() – добавление поставщика, RemoveSuplier() – удаление поставщика, GetSuplier() – получение информации о поставщике, GetAllSuplier() – получении списка поставщиков.


Материально-ответственное лицо при получении товара добавляет приходный ордер (операция AddOrder()) и на основании ордера принимает на склад товар от поставщика. В каждом приходном ордере есть информация о поставщике. При добавлении приходного ордера в карточку складского учёта заносится информация о полученном товаре.

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

Рисунок 4

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

ГЛАВА 4. ОБЗОР CASE-СРЕДСТВ

CASE-средства (Computer Aided Software Engineering) - это программные средства моделирования, позволяющие графически проектировать систему, рас­пространять дизайн проекта для широкой аудитории, публиковать модели и отчеты, а также генерировать рабочий код прило­жений и баз данных. Вместе с тем, большинство средств по­зволяет генерировать модели из готового кода, что дает возможность проводить рефакторинг приложений на более высоком уровне.

Одним из наиболее популярных CASE-средств, поддерживающих методологию структурного проектирования, является пакет AllFusion Modeling Suite, выпущенный компанией Computer Associates. Входящий в этот пакет продукт, а именно AllFusion Component Modeler (Paradigm Plus) является средством для проектирования, визуализации и поддержки качественных информационных систем. Обеспечивая расширенную поддержку совместного проектирования и многократного использования компонентов модели, существенно увеличивает производительность команды разработчиков. Обеспечивает полную поддержку UML, языка объектного моделирования для документирования, специфицикации и проектирования приложений. Визуальное моделирование помогает управлять большими проектами и анализировать влияние изменений, а так же гарантирует, что получившийся в итоге продукт сможет удовлетворить потребности конечного пользователя. Продукт обеспечивает синхронизацию проектов приложений и их программных реализаций при любом числе изменений в коде и независимо от количества итераций проекта без применения маркеров кода или потери данных, включает функцию "Интеллектуальные связи", которая существенно упрощает создание крупномасштабных моделей за счет уменьшения числа действий, которые нужно совершать при рисовании связей.


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

  • AllFusion Process Modeler - является инструментом визуального моделирования бизнес-процессов, поддерживающий три нотации моделирования: IDEF0, IDEF3 и DFD.
  • 2.  AllFusion ERwin Data Modeler - инструмент проектирования, документирования и сопровождения базы данных, хранилища данных и витрины данных.
  • 3.  AllFusion Data Model Validator – инструмент для проверки структуры баз данных и создоваемых моделей в Erwin, позволяющий выявлять недочеты проектирования.
  • 4.  AllFusion Model Manager – средство для совместной работы группы проектировщиков.

Интегрированный целиком комплекс Case-средств, обеспечивает все потребности компаний-разработчиков.

Одним из наиболее применимых case-средств, помогающий преобразовать технические и бизнес-концепции в визуальную форму, является Microsoft Visio. К сожалению это не полноценное средство моделирования, а пакет, предназначенный исключительно для рисования UML-диаграмм. Но и этот пакет не лишен своих плюсов, например таких как: интеграция с другими приложениями MS Office; идет с семнадцатью языковыми пакетами, включая поддержку азиатских языков и двунаправленного текста; помогает повысить производительность, за счет вращения фигур без переключения в специальный режим вращения, выбор и вращение группы фигур, печать выбранной части диаграммы, функция поиска фигуры и других; возможность использовать для генерации и структурирования идей в виде диаграмм во время сессий мозгового штурма, которые можно экспортировать в Microsoft Word, Microsoft Excel или XML, положив таким образом начало созданию других бизнес-файлов; располагает встроенным средство рецензирования, которое можно использовать для отслеживания фигур и примечаний, оставленных другими соразработчиками и многое другое. Внешне Microsoft Visio похож на другие программы Microsoft Office, что дает ему фору перед другими программными средствами, так как не надо осваивать интерфейс с нуля, ведь он уже знаком большинству пользователей PC.

Теперь рассмотрим пакет с открытым программным кодом, написанный на Delphi. StarUML - это пакет для разработки быстрых, гибких, расширяемых, функциональных и распространяемых бесплатно платформ UML/MDA для систем Windows. Сам проект StartUML создан с целью разработки универсальной бесплатной платформы для моделирования. StarUML имеет мощную, но в тоже время простую архитектуру с поддержкой возможности подключения плагинов, поэтому любой разработчик имеет возможность принять участие в расширении функций утилиты, разработав и подключив собственный модуль, используя совместимые языки. Это дает платформе много большие перспективы развития пред коммерческими аналогами.


Интерфейс средства очень удобен и интуитивно понятен, так как напоминает Microsoft Visual. Базовый пакет StarUML способен создавать документацию в виде текстовых файлов, файлов MS Excel и MS PowerPoint, а так же доступен ряд модулей, добавляющих поддержку ER-диаграмм, некоторых профайлов UML, например SPEM, WAE и др.

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Семенов М.И., Трубилин А.И.; Под ред. Лойко В.И. Информационные системы и технологии в экономике - М.: Финансы и статистика, 2005. - 416 с.

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2006 - 544 с.

3. Фаулер M. UML Основы, 3-е издание. - Пер. с англ. - СПб: Символ Плюс, 2004. - 192 с.