1.3 Методы и алгоритмы решения задачи
1.3.1 Краткое описание методологии UML
UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — в разработке программного обеспечения это отраслевой стандарт визуального языка моделирования 3-го поколения[2], который служит в основном для моделирования программных систем. Однако использование UML не ограничивается моделированием программного обеспечения. Он может быть использован для моделирования технических средств; кроме того, этот язык употребляется для моделирования бизнес-процессов и организационных структур.
История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из компании Rational Software Corporation начали работу по унификации методов Booch и OMT. Несмотря на то, что сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекобсон, главный технолог компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.
В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group), который был образован еще в 1989 году с целью разработки предложений по стандартизации объектных и компонентных технологий CORBA. В то время язык UML приобрел статус второго стратегического направления в работе OMG. Именно в OMG создается команда разработчиков под руководством Р. Соли, которая обеспечила дальнейшую работу по унификации и стандартизации языка UML. Усилия группы разработчиков, в которую входили также Г. Буч, Дж. Румбах и А. Джекобсон, привели к появлению первых документов, содержащих собственно описание языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.).
Тогда же некоторые компании и организации увидели в языке UML стратегический интерес для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие фирмы, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному определению нотации.
В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность, предполагала решение широкого класса задач. В результате работы инициативной группы в составе OMG была предложена пересмотренная версия 1.1 языка UML. Основное внимание при разработке языка UML 1.1 было уделено достижению большей ясности семантики по сравнению с UML 1.0, а также учету предложений новых партнеров. Эта версия языка была представлена на рассмотрение OMG, затем одобрена и принята в качестве стандарта OMG в ноябре 1997 года. История разработки и последующего развития языка UML графически представлена на рисунке 1.1.
В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG. При этом статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо, хотя указанный выше документ защищен законом об авторском праве. В тоже время аббревиатура UML, как и некоторые другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев, о чем следует упомянуть в данном контексте.
На рынке CASE-средств представлены десятки программных инструментов, поддерживающих нотацию языка UML 1.4-1.5 и обеспечивающих интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk.
С каждым годом интерес к языку UML со стороны специалистов неуклонно возрастает. Язык UML повсеместно становится не только основой для разработки и реализации во многих перспективных инструментальных RAD-средcтвах, но и в CASE–средствах визуального и имитационного моделирования. Более того, заложенные в языке UML потенциальные возможности широко используются как для объектно-ориентированного моделирования систем, так и для документирования бизнес-процессов, а в более широком контексте – для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические комплексы.
Рисунок 2 – История развития языка UML
Для разработки программного комплекса функционально-ресурсного анализа технических систем в методологии UML выбрана программа SoftwareIdeasModeller.
1.3.2 Краткое описание средства разработки проекта SoftwareIdeasModeller
SoftwareIdeasModeller – программная платформа моделирования, которая поддерживает UML (Унифицированный Язык Моделирования). Она основана на версии UML 1.4 и поддерживает нотацию UML версии 2.0 и одиннадцать различных типов диаграмм. Она активно поддерживает подход MDA (Архитектура Управляемая Моделью) и концепцию профилей UML. StarUML превосходен в отношении настройки окружения пользователя и имеет высокую степень расширяемости в том, что касается его функциональных возможностей.
StarUML предоставляет максимальные возможности адаптации к требованиям пользователя, предлагая настройку параметров, которые определяют методологию создания программного обеспечения, проектную платформу и язык разработки.
StarUML обладает превосходной расширяемостью и гибкостью. Он поддерживает использование аддинов, позволяющих расширять его функциональные возможности. При их разработке предоставляется доступ ко всем функциям модели/метамодели и другому инструментарию через COM, включая расширение меню и набора опций конфигурации. Также, пользователи могут создавать свои собственные подходы и фреймворки, соответствующие специальным методологиям. StarUML может также быть интегрирован с любыми внешними инструментальными средствами.
StarUML - платформа моделирования программ. Преимущества расширяемой платформы:
• Конечные пользователи хотят иметь настраиваемые инструментальные средства. Обеспечение возможности настройки параметров, учитывающее все требования к операционной среде, может гарантировать высокую производительность и качество разработок.
• Никакой инструмент моделирования не предоставляет абсолютно исчерпывающий набор всех возможных функций. Поэтому, хороший инструмент должен предусматривать необходимость расширения своих функций в будущем, оправдывая тем самым инвестиционные затраты пользователя, сделанные при его покупке.
Технология MDA (Управляемая моделью архитектура) требует не только платформенной независимости, но и мультиплатформенных функциональных возможностей. Инструментальные средства моделирования, ограниченные специфическими средами разработки, не подходят для технологии MDA. Инструмент моделирования сам должен являться платформой моделирования, предоставляющей функциональные возможности, настраиваемые на различные технологии, среды разработки и инструментальные средства.
• Интеграция с другими инструментальными средствами жизненно важна для максимизации эффективности использования инструмента. Инструмент должен предоставлять высокий уровень расширяемости и позволять интегрироваться с существующими инструментальными средствами, которые находятся в распоряжении пользователя.
1.3.3 Краткое описание теории решения изобретательских задач
ТРИЗ — теория решения изобретательских задач — область знаний, исследующая механизмы развития технических систем с целью создания практических методов решения изобретательских задач. "Цель ТРИЗ: опираясь на изучение объективных закономерностей развития технических систем, дать правила организации мышления по многоэкранной схеме" Автор ТРИЗ — Генрих Саулович Альтшуллер.
Появление ТРИЗ было вызвано потребностью ускорить изобретательский процесс, исключив из него элементы случайности: внезапное и непредсказуемое озарение, слепой перебор и отбрасывание вариантов, зависимость от настроения и т. п. Кроме того, целью ТРИЗ является улучшение качества и увеличение уровня изобретений за счёт снятия психологической инерции и усиления творческого воображения.
Основные функции и области применения ТРИЗ:
решение изобретательских задач любой сложности и направленности;
прогнозирование развития технических систем;
пробуждение, тренировка и грамотное использование природных способностей человека в изобретательской деятельности (прежде всего образного воображения и системного мышления);
совершенствование коллективов (в том числе творческих) по направлению к их идеалу (когда задачи выполняются, но на это не требуется никаких затрат).
ТРИЗ не является строгой научной теорией. ТРИЗ представляет собой обобщённый опыт изобретательства и изучения законов развития науки и техники.
В результате своего развития ТРИЗ вышла за рамки решения изобретательских задач в технической области, и сегодня используется также в нетехнических областях (бизнес, искусство, литература, педагогика, политика и др.).
Когда техническая проблема встаёт перед изобретателем впервые, она обычно сформулирована расплывчато и не содержит в себе указаний на пути решения. В ТРИЗ такая форма постановки называется изобретательской ситуацией. Главный её недостаток в том, что перед инженером оказывается чересчур много путей и методов решения. Перебирать их все трудоёмко и дорого, а выбор путей наудачу приводит к малоэффективному методу проб и ошибок.
Поэтому первый шаг на пути к изобретению — переформулировать ситуацию таким образом, чтобы сама формулировка отсекала бесперспективные и неэффективные пути решения
На практике идеальный конечный результат редко достижим полностью, однако он служит ориентиром для изобретательской мысли. Чем ближе решение к ИКР, тем оно лучше.
Получив инструмент отсечения неэффективных решений, можно переформулировать изобретательскую ситуацию в стандартную мини-задачу: «согласно ИКР, всё должно остаться так, как было, но либо должно исчезнуть вредное, ненужное качество, либо появиться новое, полезное качество». Основная идея мини-задачи в том, чтобы избегать существенных (и дорогих) изменений и рассматривать в первую очередь простейшие решения.
Формулировка мини-задачи способствует более точному описанию задачи:
Из каких частей состоит система, как они взаимодействуют?
Какие связи являются вредными, мешающими, какие — нейтральными, и какие — полезными?
Какие части и связи можно изменять, и какие — нельзя?
Какие изменения приводят к улучшению системы, и какие — к ухудшению?
После того, как мини-задача сформулирована и система проанализирована, обычно быстро обнаруживается, что попытки изменений с целью улучшения одних параметров системы приводят к ухудшению других параметров. Например, увеличение прочности крыла самолёта может приводить к увеличению его веса, и наоборот — облегчение крыла приводит к снижению его прочности. В системе возникает конфликт, противоречие.
ТРИЗ выделяет 3 вида противоречий (в порядке возрастания сложности разрешения):
административное противоречие: «надо улучшить систему, но я не знаю как (не умею, не имею права) сделать это». Это противоречие является самым слабым и может быть снято либо изучением дополнительных материалов, либо принятием/снятием административных решений.
техническое противоречие: «улучшение одного параметра системы приводит к ухудшению другого параметра». Техническое противоречие — это и есть постановка изобретательской задачи. Переход от административного противоречия к техническому резко понижает размерность задачи, сужает поле поиска решений и позволяет перейти от метода проб и ошибок к алгоритму решения изобретательской задачи, который либо предлагает применить один или несколько стандартных технических приёмов, либо (в случае сложных задач) указывает на одно или несколько физических противоречий.
физическое противоречие: «для улучшения системы, какая-то её часть должна находиться в разных физических состояниях одновременно, что невозможно». Физическое противоречие является наиболее фундаментальным, потому что изобретатель упирается в ограничения, обусловленные физическими законами природы. Для решения задачи изобретатель должен воспользоваться справочником физических эффектов и таблицей их применения.