23. Особенности моделирования программного обеспечения. История развития ПО, особенности документирования и спецификации.

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

Под моделью понимается полное описание системы ПО с определённой точки зрения. Моделирование можно считать центральным звеном всей деятельности по создания качественного ПО.

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

Язык моделирования должен включать: элементы модели – фундаментальные концепции моделирования и их семантику; нотацию – визуальное представление элементов моделирования; руководство по использованию – правила применения элементов в рамках построения тех или иных типов моделей ПО.

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

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

В 70-80-х гг. при разработке ПО достаточно широко применялись структурные методы, базирующиеся на строгих формализованных методах описания ПО и принимаемых технических решений (в настоящее время такое же распространение получают объектно-ориентированные методы). Эти методы основаны на использовании графических моделей для описания архитектуры ПО в различных аспектах (как статической структуры, так и динамики поведения системы) используются схемы и диаграммы. Наглядность и строгость средств структурного и объектно-ориентированного анализа позволяют разработчикам и будущим пользователям системы с самого начала неформально участвовать в её создании, обсуждать и закреплять понимание основных технических решений.

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

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

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

Таким образом, к концу 80-х гг. назрела необходимость в CASE-технологиях и CASE-средствах и возникли предпосылки для их появления: было проведено много исследований в области программирования (разработка и внедрение языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и не формальных языков описания системных требований и спецификации и т.д.).

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

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