Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (Сущность объектно-ориентированного подхода)

Содержание:

Введение

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

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

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

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

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

Задачей курсовой работы являются:

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

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

1. Исследовательский раздел

1.1. Общие понятия и определения

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

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

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

1.Планирование и анализ требований (предпроектная стадия) - системный анализ. Исследование и анализ существующей информационной системы, определение требований к создаваемой ЭИС, оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ) на разработку ЭИС.

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

3.Реализация (рабочее проектирование, физическое проектирование, программирование). Разработка и настройка программ, наполнение баз данных, создание рабочих инструкций для персонала, оформление рабочего проекта.

4.Внедрение (тестирование, опытная эксплуатация). Комплексная отладка подсистем ЭИСГ обучение персонала, поэтапное внедрение ЭИС в эксплуатацию по подразделениям экономического объекта, оформление акта о приемо-сдаточных испытаниях ЭИС.

5.Эксплуатация ЭИС (сопровождение, модернизация). Сбор рекламаций и статистики о функционировании ЭИС, исправление ошибок и недоработок, оформление требований к модернизации ЭИС и ее выполнение (повторение стадий 2 - 5).

1.2. Сущность объектно-ориентированного подхода

Термин «объект» или эквивалентные ему понятия появились практически независимо в различных областях, связанных с компьютерами, в процессе разработки:

• архитектуры компьютеров (Burroughs 5000, Plessey 250, IBM System/38, Intel 432);
• объектно-ориентированных операционных систем (Plessey/System 250, Secure UNIX, StarOS, iMax);
• объектно-ориентированных языков программирования (Simula, Smalltalk, Modula);
• теории баз данных (модели «сущность-связь»);
• систем искусственного интеллекта (фреймы).

В процесс создания программ термин «объект» впервые был введен в языке Simula 67 при определении сущностей предметной области.

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

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

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

Индивидуальность – это свойство сущности, с помощью которого ее можно отличить от других. Например, объект «преподаватель» в реальности – это мужчина или женщина, определенного роста, веса и возраста. Этот человек в назначенные рабочие дни приходит в один из вузов. С точки зрения проектирования системы абстракция этого типа объектов будет сведена к базовому набору атрибутов: фамилия, имя, отчество, дата рождения, пол. После этого, набор атрибутов зависит от сферы использования проектируемой системы. Например, для бухгалтерии становиться важной наличие информации о должности, на которой работает преподаватель, время приема на работу, так как это определяет стаж, а соответственно размер надбавки за стаж работы, наличие ученой степени и ученого звание, что тоже предполагает начисление соответствующих надбавок. Для учебного отдела интерес представляет список дисциплин и количество часов, которые читает преподаватель.

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

Класс – это  совокупность объектов, имеющих общую структуру и поведение. Фактически, класс – это шаблон, на основе которого генерируются однотипные объекты. В качестве синонима понятия «объект» часто употребляют понятие «экземпляр класса».

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

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

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

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

Полиморфизм – принцип построения определяет возможность принимать различные внешние формы или функциональность (поведение) в зависимости от контекста. Например, методы Paint() (отрисовать) или DefineS() (определить площадь), определенные в родительском классе «фигура», для классов «эллипс» и «прямоугольник» должны быть реализованы по-разному."

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

Базовыми составляющими объектно-ориентированного подхода являются:

унифицированный процесс;

унифицированный язык моделирования;

шаблоны проектирования.

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

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

На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования.

Шаблон – это пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы, которой присвоено имя. Обычно, шаблон кроме текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, кооперации и/или последовательности), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы.  Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов обеспечивает сокращение затрат и повышение качества разработки ПО.

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

1. Описание системы в виде объектов больше соответствует содержательному смыслу предметной области.
2. Сущности предметной области, как правило, обладают поведением, что в объектно-ориентированном проектировании отражается с помощью определения методов класса. В структурном подходе данные (атрибуты) и алгоритмы (методы) существуют отдельно друг от друга.
3. Объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней связности и меньшей связности между компонентами системы.
4. Объектно-ориентированный подход позволяет легче организовать параллельные вычисления, так как каждый объект обладает собственными значениями характеристик (атрибутов) и поведением, за счет чего можно добиться автономности обработки атрибутов различных экземпляров класса.
5. Case-средства, поддерживающие объектно-ориентированный подход, на основе информации об объектах позволяют достичь большей степени автоматизации генерации кода. Case-средства, поддерживающие структурный подход, хорошо справляются с генерацией структур БД. Однако следует отметить, что эта структура должна удовлетворять требованиям нормализации. В связи с чем автоматическая генерация кода (например, экранов или функций обработки данных) возможна лишь в определенных случаях.

2. Объектно-ориентированное проектирование ЭИС

2.1. Описание основ проектирования экономических информационных систем

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

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

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

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

- необходимость интеграции существующих и вновь разрабатываемых приложений;

- функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. Она основана на наглядной графической технике: для описания различного рода моделей ИС используются схемы и диаграммы. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако, широкое применение этой методологии и следование ее рекомендациям при разработке конкретных ИС встречалось достаточно редко, поскольку при неавтоматизированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:

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

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

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

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

- подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

- широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

2.2. Автоматизированное проектирование ЭИС (CASE - технология)

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

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

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

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

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

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

• репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
• графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
• средства разработки приложений, включая языки 4GL и генераторы кодов;
• средства конфигурационного управления;
• средства документирования;
• средства тестирования;
• средства управления проектом;
• средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

• применяемым методологиям и моделям систем и БД;
• степени интегрированности с СУБД;
• доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

• средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
• средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer, Silverrun и PRO-IV;
• средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
• средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

• средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
• средства конфигурационного управления (PVCS (Intersolv));
• средства тестирования (Quality Works (Segue Software));
• средства документирования (SoDA (Rational Software)).

2.3. Язык UML и его использование при проектировании ЭИС

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.

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

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования, разработанные Бучем (Booch) и Рамбо (Object-Modeling Technique — OMT).

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена.

Главными в разработке UML были следующие цели:

• предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими;

• предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;

• обеспечить независимость от конкретных языков программирования и процессов разработки;

• обеспечить формальную основу для понимания этого языка моделирования

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

При проектировании сложной информационной системы, как правило, ее делят на части. Каждую часть в дальнейшем рассматривают и разрабатывают отдельно, при этом используется либо функциональное деление системы, либоприменяется объектная декомпозиция [2,1].

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

Объекты имеют определенные свойства и методы.

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

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

Система объектно-ориентированных моделей в соответствии с языком UML включает в себя диаграммы, показанные на рисунке 1. [10].

Рисунок 1 – Виды диаграмм UML

Построение диаграммы прецедентов

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

описания бизнес-деятельности в виде моделей отдельных бизнес-прецедентов. Можно с помощью нескольких диаграмм представить модель на нескольких уровнях функционирования. На контекстной модели, представленной на рисунке 2, отображается обобщённый прецедент и участвующие классы. Класс «Преподаватели» является суперклассом.

декомпозиция представлена на рисунке 3.

Рисунок 2 – Диаграмма вариантов использования (Use Case Diagram)

Рисунок 3 – Декомпозиция класса «Преподаватели»

Рисунок 4– Детализация прецедента «Учебный процесс»

Построение диаграммы взаимодействия

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

Диаграмма последовательности – диаграмма поведения, на которой для набора объектов на единой временной оси показан жизненный цикл объекта и взаимодействие актёров ИС в рамках определённого прецедента [6].

На рисунке 5 с помощью диаграммы последовательности, детально рассмотрен прецедент «Сбор сведений о проведённых экзаменах и зачётах». Объекты, располагающиеся на одном уровне с актёром «Деканат», являются сущностями данной модели. Той же смысловой нагрузкой обладает кооперативная диаграмма, только на ней нет фиксированного порядка операций относительно времени. Кооперативная диаграмма представлена на рисунке 6.

Рисунок 5 – Диаграмма последовательностей (Sequence Diagram)

Рисунок 6 – Кооперативная диаграмма (Collaboration Diagram)

Построение диаграммы активностей

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

Диаграммы деятельности позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних действий и деятельности. Разработка диаграммы деятельности необходима:

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

Диаграмма активности представляется в виде графа деятельности, вершинами которого являются состояния деятельности, а дуги показывают переходы от одного состояния деятельности к другому [6].

Примеры диаграммы активности для прецедента «Учебный процесс» и «Прохождение ТО» представлены на рисунках 7 и 8 соответственно.

Рисунок 7 – Диаграмма активности (Activity Diagram) для прецедента

«Учебный процесс»

Рисунок 8 – Диаграмма активности для прецедента «Прохождение ТО»

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

Построение диаграммы классов

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

Условно объекты модели можно разделить на несколько пакетов, например «Сущности» и «Границы». На главной диаграмме классов, представленной на рисунке 9, отображены эти пакеты. Пример содержимого пакетов представлено на рисунке 10.

Рисунок 9 – Диаграмма классов – пакеты модели

Рисунок 10 – Диаграмма классов (Class Diagram) «Справочник аптеки»

Построение диаграммы компонентов

Диаграмма компонентов – это один из двух видов диаграмм, используемых при моделировании физических аспектов объектно-ориентированной системы. На ней изображено разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. С помощью диаграммы компонентов представляются инкапсулированные классы вместе с их интерфейсными оболочками, портами и внутренними структурами (которые тоже могут состоять из компо- нентов и коннекторов). Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом, иллюстрируются отношения клиент-источник между двумя компонентами [6].

Диаграмма компонентов, как и диаграмма классов, делится на диаграмму пакетов и собственно диаграмму компонентов. Чаще всего количество пакетов, наименование пакетов и их содержимое совпадает с диаграммой классов за исключением назначения объектов и наличия связей между пакетами. Пример содержимого пакета «Сущности» представлено на рисунке 11. Пример диаграммы компонентов приведен на рисунке 12.

Рисунок 11 – Содержимое пакета «Сущности»

Рисунок 12– Диаграмма компонентов (Component Diagram)

Построение диаграммы размещения

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

Диаграммы размещения используются для моделирования статического представления системы с точки зрения размещения. В основном под этим понимается моделирование топологии аппаратных средств, на которых работает система. По существу, диаграммы размещения – это просто диаграммы классов, сосредоточен-ные на системных узлах [6].

Пример диаграммы размещения представлен на рисунке 13.

Рисунок 13– Диаграмма размещения (Deployment Diagram)

Заключение

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

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

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

Список использованных источников

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем.– М.: Финансы и статистика, 2018.
2. Титоренко Г.А. Информационные технологии управления. - М.: ЮНИТИ-ДАНА, 2016
3. Литвак Б.Г. Разработка управленческого решения. – М.: Дело, 2017
4. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. – М.: СУБД, 2017.
5. Липаев В.В. Проектирование программных средств: Учебное пособие для вузов. – М.: Высшая школа, 2016.
6. Тихомиров В.П. Организация и экономика сопровождения программных средств вычислительной техники. – М.: Статистика и финансы, 2015.