Разработка модели информационной системы с помощью StarUML

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление 09.03.02 Информационные системы и технологии

Кафедра Информационных систем и технологий

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

Разработка модели информационной системы с помощью StarUML

Разработал Е.Н. Французова

Самара 2017

Введение

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

Современные организации постоянно вынуждены заниматься оптимизацией своей деятельности, если хотят оставаться конкурентно способными. Для этого применяются различные методики стратегии, технологии и т. д. Одним из примеров перечисленных подходов является привлечение консалтинговых организаций для выработки рекомендаций относительно приоритетных направлений развития компании. Чтобы оказывать качественные консалтинговые услуги помимо квалифицированных сотрудников необходимо наличие специализированной информационной системы. Подобные ИС являются сложными программными продуктами, следовательно, чтобы упростить процесс разработки и повысить эффективность создаваемой ИС, целесообразно построить её модель и только после этого приступать к написанию программного кода. Самым популярным языком для реализации таких моделей является UML 2.x. Таким образом тема дипломной работы «Разработка модели информационной системы с помощью StarUML» является актуальной.

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

Для достижения поставленной цели необходимо решить следующие основные задачи:

1. Изучить предметную область и выявить основные процессы подлежащие автоматизации.

2. Изучить основные подходы моделирования информационных систем.

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

4. Построить модель ИС для консалтинговой организации.

5. Сгенерировать заготовку программного кода для классов.

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

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

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

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

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

1. Обзор предметной области

1.1 Понятие консалтинга и консалтинговой компании

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

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

Понятие консалтинга присутствует в нескольких фундаментальных науках - экономике, социологии и психологии, и каждая из них даёт своё уникальное определение, которое, тем не менее, так или иначе имеет своего рода «скелет» - ту неизменяемую основу, общую для всех классических определений термина. Чтобы выявить эту общую часть, следует внимательно присмотреться к корню данного слова. Слово «консалтинг» английского происхождения (consulting) и происходит от глагола to consult, который, согласно словарю Уэбстера [1], означает, в широком смысле, сообщение заинтересованному лицу некоторой информации, знания. С этой точки зрения консалтинг определяется как предоставление экспертных знаний третьей стороне за определённую плату [2]. Далее следует уточнение: к консалтингу чаще всего прибегают, когда предприятие нуждается во внешней экспертной оценке относительно некоторого бизнес-решения. Например, компания, организующая экспорт производимой ей продукции, может обратиться за помощью к консультанту, знакомого с деловой практикой государства-импортёра. Специалист в этом случае ознакомит компанию с правилами внешней торговли данной страны, даст рекомендации по методам сотрудничества и определит базовые векторы стратегии работы с клиентами.

В российском опыте консалтинг, с одной стороны, признается все ещё непривычным и не очень понятным явлением, а с другой - появился в нормативных и ведомственных документах Российской Федерации ещё в 90-е гг. [3]. Однако суть упоминаемого термина при этом не раскрывается, что свидетельствует об общеизвестном статусе данного понятия. Но в действительности ситуация обстоит иначе: существует множество трактовок и определений консалтинга, от самых общих до сугубо специализированных. В современной отечественной практике под консалтингом понимают особый вид интеллектуальных услуг, связанный с решением сложных проблем компании в контексте управления и организационного развития. При этом основными задачами консультирующей компании являются анализ и оценка текущего состояния проблемной области, прогнозирование перспектив её развития, подбор целесообразных научно-технологических и организационно-экономических внедрений, а также конструктивные предложения и рекомендации по улучшению деятельности организации и/или её структурных подразделений [4]. Глобальная цель консалтинга состоит в повышении качества управления и эффективности функционирования предприятия в целом и каждого сотрудника в частности. Важной особенностью консалтинга, на которую необходимо обратить внимание, является следующее обстоятельство: консультант разрабатывает рекомендации и стратегии, но, как правило, не реализует их.

Наконец, после того как сформулировано понятие консалтинга, можно говорить о консалтинговой компании и особенностях её деятельности. В качестве профессиональной деятельности консалтинг оформился в конце XIX века вследствие промышленной революции [4, с. 20], что можно считать началом отсчёта истории развития сферы консалтинговых услуг как сегмента бизнеса. Понятие консалтинговой компании расширяет границы определённого выше консалтинга и описывает предприятие, осуществляющее непосредственно консалтинг, а также сопровождающие услуги и реализацию предлагаемых решений [3, с. 9]. В настоящее время российский рынок услуг богат консультационными организациями различной отраслевой направленности, отличающихся многообразием организационно-правовых форм, наборов предоставляемых услуг, методов консультирования. Наиболее востребованным оказывается так называемое управленческое консультирование (УК), связанное так или иначе с проблемами управления организации-клиента. В эту область входит поддержка по вопросам общего управления, администрирования, финансового управления, управления персоналом и производством. Исследователи сферы консалтинга с точки зрения экономики и социологии выделяют пять типов консалтинговых компаний [5]:

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

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

· Лидерские организации. Данный тип консалтинговой компании выделен по признаку внутренней структуры и идеологии организации. Группа специалистов-консультантов сплочена вокруг одного лидера - высококвалифицированного эксперта в своей области.

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

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

Следует отметить, что в последнее время предпочтение отдаётся комбинированному консалтингу - ввиду недостатков каждого из типов в отдельности. Комбинирование предполагает распределение задач между членами группы консультантов, как внутренних, так и внешних, выполняющих каждый свою часть общей работы с целью достижения максимально эффективного результата в наиболее короткие сроки. В рамках данной бакалаврской работы будет рассмотрена гипотетическая многопрофильная консалтинговая компания, предлагающая своим клиентам услуги консультирования и сопровождения разрабатываемых решений в различных сферах производственной деятельности. Данная компания основывается на парадигме «бизнес для бизнеса»: её функционирование направлено на потребности не одиночного клиента, а некоторой организации в целом. Это обстоятельство обуславливает ряд особенностей, таких как профессиональность клиентов, тесная взаимосвязь между производителем услуги и её потребителем, долгосрочный характер сотрудничества, уникальность оказываемых услуг, особое значение фактора конфиденциальности и т.д. [6].

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

1.2 Информационные системы и их проектирование

Удовлетворение информационных потребностей предприятия является важной задачей корпоративного менеджмента. Этой цели служит активное применение современных информационных технологий и применение интеллектуального подхода к управлению организацией [7]. Совмещение этих двух аспектов - технологического и интеллектуального - выражено в парадигме искусственного интеллекта. Достижения в области «интеллектуализации» машинного поведения позволяют автоматизировать процесс принятия решений, особенно важный в контексте деятельности консалтинговой компании, и многократно повысить его результативность. Объективно целесообразно внедрить новые технологии в информационную среду компании, а именно - интегрировать их с её функциональным центром - информационной системой. В настоящее время трудно представить крупное предприятие, в информационной среде которого отсутствует информационная система. Но что же представляет собой информационная система, каковы её основные функции, возможности и особенности? Попытаемся дать на этот вопрос исчерпывающий ответ.

В наиболее широком смысле, информационная система (ИС) есть не что иное как вся инфраструктура организации в целом, участвующая в управлении информационно-документальными потоками и включающая в себя следующие обязательные компоненты [8]:

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

· Кадровые ресурсы, в чью компетенцию входит развитие и совершенствование ИС, в том числе консультанты;

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

· Регламент корректировки конфигурации ПО и кадровые ресурсы, отвечающие за исполнение регламента;

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

· Персонал, обслуживающий аппаратно-технический комплекс;

· Инструкции пользователей, порядок обучения и сертификации пользователей ИС.

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

Ключевое понятие системного подхода - система, определяется как совокупность объектов, взаимосвязи между которыми (топология) определяют её свойства в целом. Здесь следует говорить о свойстве эмерджентности, согласно которому системе присущи черты и признаки, отсутствующие у объектов в отдельности. Благодаря этому свойству, возможна иерархическая декомпозиция системы, а значит, дробление сложной задачи (например, создание ИС) на ряд более простых, элементарных задач. Системный подход предлагает двухуровневый алгоритм, описывающий последовательность действий, связанный с той или иной стадией жизненного цикла ИС [8]. Первый уровень ориентирован на создание ИС и содержит, в общем случае, следующие этапы: выявление целей ИС, глобальной и менее масштабных целей, которые вместе приводят к достижению общей, глобальной цели; описание, как правило, математическое, элементов системы и ожидаемых свойств; определение топологии - взаимосвязей и отношений между структурными элементами системы; решение частных задач и агрегирование системы. В случае ошибки или неточности конечного результата, следует вернуться в начало уровня и внести необходимые корректировки. Второй уровень алгоритма подразумевает работу с готовой ИС и включает в себя анализ показателей качества и чувствительности полученной системы, а также её стабильности и устойчивости.

Описание прототипа будущей ИС возможно осуществлять различными способами: в виде формул, словесных формулировок, таблиц, графиков и т.п. Наиболее удобными методами при этом представляются моделирование - построение визуальной модели (в соответствии с некоторой методологией) разрабатываемой ИС и структурный анализ и проектирование. Результатом проектирования является проект - прообраз предполагаемой системы, запечатлённый в комплекте специальной документации и материалов различного качества - таблицах, графиках, диаграммах, расчётах и т.п. Создание ИС представляет собой программный проект [9]. Существует несколько подходов проектирования, среди которых, в рамках данной бакалаврской работы, будет отмечен модельно-ориентированный подход. Модельно-ориентированный подход подразумевает, главным образом, разработку модели, автоматизированной ИС предприятия с применением определённого методологического и программного инструментария. Прежде чем перейти к описанию методов моделирования ИС, остановимся на понятии и стадиях жизненного цикла ИС, поскольку в зависимости от той или иной модели жизненного цикла осуществляется выбор парадигмы модельно-ориентированного проектирования.

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

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

2. Разработка ТЗ. Здесь осуществляется детализация базовой структуры проекта, формулирование и утверждение ТЗ, составление сметы и бюджета проекта, планирование работ и разработка укрупнённых графиков.

3. Проектирование. На этапе проектирования производится декомпозиция системы на объекты и выполняется концептуальное проектирование и моделирование предметной области.

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

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

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

Моделью ЖЦ именуется структура, определяющая последовательность фаз ЖЦ и взаимосвязи между ними. Различают каскадную, спиральную и итеративную модели ЖЦ. Коротко рассмотрим каждую из них. Каскадная модель предполагает переход к следующей фазе ЖЦ только в случае полного завершения действий в предыдущей фазе, при этом по завершении деятельности на каждом этапе создаётся сопровождающая документация, необходимая для продолжения работы на следующей стадии. Создание ИС интерпретируется как однократное последовательное выполнение задач и действий каждого этапа. Схема каскадной модели ЖЦ представлена на рис. 1.1.

Рис. 1.1 - Каскадная модель ЖЦ ИС

Достоинствами каскадного подхода можно считать соответствие результатов каждой фазы ЖЦ критериям полноты и согласованности, а также простоту планирования работ и бюджета ввиду строго определённой логичной последовательности действий. Однако имеет место быт существенный недостаток: в действительности каскадная модель оказывается неприменима. В процессе проектирования или разработки ИС, впрочем, как и во время выполнения работ любого из этапов, зачастую возникает необходимость возвращения на шаг или несколько шагов назад с целью уточнения ранее принятых решений или устранения допущенных на ранних стадиях ошибок. Таким образом, каскадная модель в той или иной модификации может быть использована для создания однородных и простых ИС.

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

Рис. 1.2 - Спиральная модель ЖЦ ИС

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

Рис. 1.3 - Итеративная модель ЖЦ

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

1.3 Постановка проблемы и задач исследования

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

· модель отражает аспекты функциональности будущей ИС;

· позволяет выявить модули и блоки ИС, а также протоколы взаимодействия между ними;

· предусматривает возможные ошибки во время эксплуатации ИС и предполагает способы их своевременной обработки;

· определяет роль пользователя во взаимодействии с сервисами ИС, т.е. степень автоматизации осуществляемых процессов;

· предлагает программно-аппаратную реализацию ИС и схему распределения ресурсов по компонентам.

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

1. Изучить предметную область и выявить основные процессы подлежащие автоматизации.

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

3. Построить модель ИС для консалтинговой организации.

4. Сгенерировать заготовку программного кода для классов.

1.4 Обзор подходов моделирования ИС

Существует два глобальных подхода моделирования ИС, базирующихся на различных моделях жизненного цикла ИС. Каждый из них обладает как существенными достоинствами, так и недостатками, поэтому выбор того или иного подхода во многом зависит от целей моделирования и особенностей проектируемой ИС. Структурный подход (также структурный анализ или структурное проектирование) представляет собой развитие парадигмы структурного программирования, сформировавшейся в 70-е гг. прошлого столетия, и классического системного анализа [9]. Структурный подход ориентирован на каскадную модель ЖЦ и концептуально основан на применении метода дедукции - последовательной детализации и уточнении фактов и знаний об исследуемой системе - и представлении их в виде иерархической, многоуровневой структуры. Основные принципы структурного проектирования:

· Разбиение сложных задач на последовательность более простых для понимания и реализации;

· Иерархичное упорядочивание - детализация структуры на каждом новом уровне;

· Фокусирование внимания на существенных аспектах, имеющих непосредственное значение для моделируемой системы, определение требуемого уровня абстракции;

· Строгий методический подход к моделированию ИС;

· Тесная взаимосвязь и согласованность объектов системы.

Середина 70-х гг. ознаменована появлением метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique), а затем, в начале 80-х гг., сформировались методология IDEF0, основанная на SADT и инструментальных средствах создания диаграмм, метод структурного системного анализа и проектирования SSADM (Structured Systems Analysis and Design Method), объединённые парадигмой CASE (Computer-Aided Software Engineering).

Объектно-ориентированный подход, подобно структурному, также имеет в своей «родословной» парадигму программирования - ООП, объектно-ориентированное программирование. Такой подход оперирует понятиями классов и объектов, связанных определённого рода ассоциативными отношениями. При этом для каждого класса объектов определена возможность создавать различные модели, отражающие различные стороны проектируемой системы - статическую структуру, динамическое поведение и развёртывание в действии (run-time deployment). Класс - это множество объектов, связанных общностью структуры и поведения [9, с. 77]. К объектно-ориентированному моделированию применимы и понятия наследования и полиморфизма, составляющие основу объектного подхода как парадигмы в целом. В настоящее время известно большое количество методов в рамках объектно-ориентированного подхода, в число которых входят IDEF4 и UML 2.x, наиболее распространённые нотации моделирования ИС. В следующей главе будут рассмотрены основные методы как структурного, так и объектно-ориентированного подхода, а также произведён сравнительный анализ, позволяющий выявить метод, подходящий для решения сформулированной проблемы.

программный диаграмма код информационный

2. Обзор методик моделирования программного обеспечения

2.1 Методы моделирования бизнес-процессов

Методы моделирования бизнес-процессов основываются на двух подходах: структурным и объектно-ориентированном. Перечислим некоторые из них:

· метод функционального моделирования SADT/IDEF0;

· метод моделирования процессов IDEF3;

· моделирование потоков данных DFD;

· нотация моделирования потоков работ BPMN;

· нотация моделирования UML 2.x;

2.1.1 Метод функционального моделирования SADT/IDEF0

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

Функциональная модель с достаточной глубиной детализации отображает систему функций, которые проецируют свои взаимоотношения на объекты системы. Модели данных представляют собой подробное описание объектов системы, связанных системными функциями. Полная методология SADT обеспечивает возможность создания множества моделей для более точного описания комплексной системы. Методология SADT/IDEF0 объединяет в себе группу методов, правил и процедур, предназначенных для построения функциональной модели объекта некоторой предметной области. Функциональная модель SADT представляет функциональную структуру объекта, т.е. осуществляемые им действия и связи между этими действиями. Основные элементы методологии SADT/IDEF0 базируются на следующих принципах:

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

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

3. Блоки нумеруются специальным образом, обеспечивая тем самым связанность диаграмм;

4. Имена элементов модели должны быть уникальными, т.е. присутствие повторяющихся имён недопустимо;

5. Синтаксические правила для графических символов (блоков и стрелок);

6. Разделение входов и управлений осуществляется в соответствии с правилом определения роли данных;

7. Исключается зависимость функциональной модели от организационной структуры.

Методология SADT/IDEF0 может применяться для моделирования широкого спектра систем и определения требований и функций, а затем для разработки системы, которая отвечает этим требованиям и обеспечивает эти функции. Для уже существующих систем SADT/IDEF0 может быть использована для исследования функций системы, а также для выявления механизмов, благодаря которым они осуществляются. Укажем основные достоинства и недостатки методологии SADT.

Достоинства методологии SADT/IDEF0:

1. SADT может применятся не только для моделирования программного обеспечения (ПО), но и сложных систем любых предметной области и назначения (таких как управление и контроль, телефонные сети, учёт материально технических ресурсов и др.);

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

3. SADT имеет усовершенствованные процедуры поддержки коллективной работы;

4. В отличие от большинства прочих технологий, SADT может быть использована на ранних стадиях создания системы (на этапе предварительного проектирования);

5. SADT может быть совместима с другими структурными подходами проектирования.

Недостатки методологии SADT/IDEF0:

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

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

2.1.2 Метод моделирования процессов IDEF3

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

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

В стандарте IDEF3 есть два типа диаграмм. Эти диаграммы описывают один и тот же технологический процесс с разных сторон. Первый тип диаграммы - это диаграммы описания потока процессов (PFDD). Второй тип - диаграмма переходной сети состояния объекта (OSTN).

Достоинство методологии IDEF3:

Одним из важных достоинств является, возможность описать на диаграмме сценарий выполнения процесса, то есть описать последовательность действий «если-то-иначе»

Недостатки методологии IDEF3:

1. Слабая информативность моделей - необходимость их сочетания с моделями, описываемыми в стандарте IDEF0.

2. Для чтения и интерпретации диаграмм необходимы определённые знания стандарта.

2.1.3 Моделирование потоков данных DFD

DFD - отличный инструмент коммуникации для аналитиков для моделирования процессов и функциональных требований. Один из основных инструментов усилий по структурированному анализу в 1970-х годах был разработан и дополнен такими, как Yourdon, McMenamin, Palme, Gane и Sarson. Он по-прежнему считается одним из лучших методов моделирования для выявления и представления требований к обработке системы.

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

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

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

Области применения диаграмм потоков данных:

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

2. Моделирование существующего процесса движения информации;

3. Описание документооборота, обработки информации;

4. Дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота;

5. Проведение анализа и определения основных направлений реинжиниринга информационной системы. [11 c. 7]

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

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

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

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

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

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

2.1.4 Основные компоненты DFD

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

Достоинства нотации DFD

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

2. Способность проектирование сверху вниз.

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

Недостатки нотации DFD

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

2.1.5 Нотация моделирования потоков работ BPMN

Модель бизнес-процессов и обозначение (BPMN) - стандартизированная графическая нотация, которая используется глобально для моделирования бизнес-процессов. Это с открытым исходным кодом, что означает, что исходный код доступен любому пользователю для изменения и использования. Кроме того, смысл его символов и форм является точным. Они определены в спецификации. Группа управления объектами (OMG), консорциум некоммерческих технологических стандартов, управляет и поддерживает BPMN. Язык не принадлежит ни одному коммерческому предприятию.

В нотации BPMN выделяют пять основных категорий элементов:

1. элементы потока (события, процессы и шлюзы);

2. данные (объекты данных и базы данных);

3. соединяющие элементы (потоки управления, потоки сообщений и ассоциации);

4. зоны ответственности (пулы и дорожки);

5. артефакты (сноски).

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

Достоинства BPMN

1. Нотация использует базовый набор интуитивно понятных элементов.

2. Современный стандарт моделирования бизнес-процессов.

3. Высокая информативность получаемых диаграмм.

4. Возможность отразить на диаграмме сценарий выполнения процесса, т.е. описать последовательность действий «если-то-иначе».

Недостатки BPMN

1. Высокие требования к компетенции аналитика при использовании стандарта.

2.1.6 Нотация моделирования UML

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

Достоинства нотации UML 2.x

1. UML 2.x обеспечивает набор символов для представления в графическом виде различные компонентов и взаимосвязей внутри системы.

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

3. UML 2.x позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы.

4. UML 2.x разбивает всю систему на более маленькие части и поэтому, становится легче идентифицировать избыточные и аналогичные модули. Таким образом, увеличивается его повторное использование.

5. UML 2.x расширяет и позволяет добавление пользовательского текста и графических типов, что делает возможным использовать не только в программной инженерии.

6. Этот проект может быть доставлен в команде разработчиков на этапе реализации.

Недостатки нотации UML

UML 2.x является широко распространённым, языком моделирования, несмотря на это, выявлены некоторые недостатки данного метода.

1. Одним из недостатков некоторые разработчики могут найти при использовании UML 2.x это время, которое требуется, чтобы управлять и поддерживать UML 2.x диаграмм.Для правильной работы схема UML 2.x должна быть синхронизирована с программным кодом, который требует времени, чтобы создать и поддерживать, и добавляет работу в проект разработки программного обеспечения.Небольшие компании и независимые разработчики не могли бы быть в состоянии справиться с дополнительным объёмом работы, необходимым для синхронизации коды.

2. Невозможность проведения детального анализа процессов

3. Неполнота и незавершённость некоторых видов диаграмм, возможность их неверной интерпретации

4. При создании диаграммы UML 2.x в сочетании с разработкой программного обеспечения, схема может стать подавляющей или усложнённой, что может быть непонятными и запутанными для разработчиков. Разработчики не могут наметить каждый сценарий для программного средства на диаграмме, и даже если они пытаются, диаграмма становится беспорядочной.

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

2.1.7 Универсальный язык моделирования сложных систем UML 2.x

Диаграммы UML 2.x

Описание языка UML 2.x состоит из двух взаимодействующих частей:

1. Семантики языка UML 2.x;

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

Семантика определяется для двух видов объектных моделей:

1. структурных моделей (статических моделей), которые описывают структуру сущностей или компонентов некоторой системы;

2. моделей поведения (динамических моделей), которые описывают поведение или функционирование объектов системы.

Нотация языка UML 2.x описывает отдельные семантические элементы, которые применяются при построении диаграмм. В рамках языка UML 2.x все представления модели сложной системы формируется в виде различных диаграмм. Диаграмма - графическое представление набора элементов, чаще всего представляемых как связный граф вершин (предметов) и дуг (отношений). Мы рисуем диаграммы для визуализации системы с разных точек зрения, поэтому диаграмма - это проекция в систему. Для всех, кроме самых тривиальных систем, диаграмма представляет собой элиминированное представление элементов, составляющих систему. Один и тот же элемент может отображаться во всех диаграммах, только несколько диаграмм (наиболее часто встречающийся случай) или вообще нет диаграмм (очень редкий случай). Теоретически диаграмма может содержать любую комбинацию вещей и отношений. На практике, однако, возникает небольшое количество общих комбинаций, которые согласуются с пятью наиболее полезными представлениями, которые составляют архитектуру системы с интенсивным использованием программного обеспечения. По этой причине UML включает одиннадцать таких диаграмм:

· диаграмма вариантов использования (Use Case Diagram);

· диаграмма классов (Class Diagram);

· диаграммы поведения (Behavior Diagrams):

· диаграмма состояний (Statechart Diagram),

· диаграмма деятельности (Activity Diagram),

· диаграммы взаимодействия (Interaction Diagrams):

· диаграмма последовательности (Sequence Diagram),

· диаграмма кооперации (Collaboration Diagram);

· диаграмма компонентов (Component Diagram)

· диаграмма развёртывания (Deployment Diagram).

· ER диаграмма (ER Diagram)

Основными элементами диаграмм UML 2.x являются связи, графические символы и текст. Связи в диаграммах обозначаются в виде различных линий на плоскости. Графические символы изображаются, между теми или иными визуальными элементами диаграммы. Текст на диаграммах изображается внутри геометрических фигур, и снаружи для описания связей между элементами диаграммы.

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

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

· должны быть определены общие границы и контекст предметной области моделируемой системы;

· должны быть сформулированы общие требования к функциональному поведению проектируемой системы;

· должна быть разработана исходная концептуальная модель системы.

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

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

...