Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Необходимость интеграции объектного и системного подходов




В настоящее время компонентная методология разработки ИС является базовой методологией создания программного инструментария информационно-аналитического сопровождения деятельности организационных систем. При этом, являясь развитием объектно-ориентированного подхода, данная методология использует все его понятия и принципы. Однако, объектно-ориентированный анализ и проектирование (OOAD) не располагают какими-либо собственными методами анализа и моделирования предметной области, для которой разрабатывается программное приложение, так как изначально предназначены для моделирования ПО. Отсутствуют даже методы простого выявления необходимых для моделирования классов и объектов. Использование же широко рекламируемого языка UML не изменяет ситуации, так как, по справедливому замечанию специалистов (например, М. Фаулера), это только язык, а не метод [81].

Одним из оснований для подобных высказываний является определение понятия «метод», предложенное, например, в работе [91]. Кратко оно может быть представлено в следующем виде: «Метод – есть система правил и приемов достижения определенных результатов, исходящая из знания закономерностей исследуемого предмета, помогающая исследователю выбрать существенное, наметить путь восхождения от известного к неизвестному». Данное определение позволяет утверждать, например, что карточки CRC (Класс – Ответственность – Кооперация) не могут рассматриваться как метод выявления классов предметной области. Подобные карточки являются способом представления информации, который призван облегчить ее последующий анализ. Никакой связи с закономерностями предметной области или каких-либо подходов к выявлению в предметной области существенного они не имеют. Это то же самое, что библиотечная картотека. Сама по себе она есть только удобный способ хранения информации. Для анализа и классификации этой информации применяются совершенно другие методы.

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

Кажущееся естественным применение методов системного анализа, изначально предназначенных для моделирования производства, в рамках OOAD оказывается малоэффективным. Данное обстоятельство обусловлено тем, что методы традиционного системного анализа (именуемого в литературе также структурным или системно-структурным) «полностью ортогональны принципам объектно-ориентированного проектирования» [13, с. 161]. Специалисты по системному анализу приходят к однозначному выводу, что при использовании традиционных системных методов для проведения OOAD все равно приходится выходить за их рамки и использовать дополнительные средства, так как современные методы такого анализа «не позволяют, тем не менее, идентифицировать подходящее множество объектов для разрабатываемой системы. Процесс обнаружения объектов все еще управляется мнениями, интуицией и инсайтом» [32, с. 26].

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

К сожалению, в литературе по OOAD также, кроме сетований на то, что «рецептов для поиска классов не существует», не предлагается путей решения задачи ККМ, хотя и утверждается, что это основная задача OOAD [например, 13 и 78]. Например, вся литература от Rational Software (под редакцией «трех друзей») ограничивается только рекомендациями общего характера. При этом подчеркивается, что они не знают ни методик построения классификаций, ни даже самого понятия «хорошая классификация». Попытки строить классификации имеются, но они осуществляются на уровне интуиции и экспертных знаний специалистов конкретной предметной области без привлечения какого-либо методического обеспечения, представленного, например, в работах [91 или 93].

Кроме того, традиционные методы системного (или системно-структурного) анализа не поддерживают объектно-ориентированную концепцию инкапсуляции (отделение интерфейса объекта от его реализации). Последнее обстоятельство, в свою очередь, обусловлено тем, что система в традиционном системном анализе и системном подходе (как уже было отмечено выше) всегда рассматривается как множество или элементов, или свойств, или состояний и т.д. В концепции же множества изначально заложена первичность элемента (части) по отношению к множеству (целому). Множество существует тогда и только тогда, когда тем или другим образом заданы его элементы. Теоретико-множественное понимание системы, собственно, и не позволяет обеспечить в ходе традиционного системного анализа инкапсуляцию выявляемых объектов (необходимую при OOAD), так как множество есть явление, внутреннее содержание которого не может быть скрыто. Сущностью же действительно системной концепции («pure system»), на самом деле, является выделение в первую очередь целого, которое уже потом будет (а может и не будет) представлено в виде совокупности взаимодействующих частей (подсистем). На это давно уже обращали внимание ведущие методологи системных исследований [например, 6], однако до сих пор это не нашло практического воплощения в технологиях и инструментах системного анализа (см. далее).

Необходимо подчеркнуть также, что методы традиционного системного анализа и объектно-ориентированный анализ направлены на выявление различных структур исследуемой системы. В системном (системно-структурном) анализе речь идет о функциональной структуре (вход, процесс, выход, связующие потоки) без внимания к реализующим эти функции объектам (субстанции). В OOAD речь идет о структуре объектов (и классов) системы. Функциональность (поведение) этих объектов рассматривается с точки зрения ответственности компонент ПО, так как объектный подход есть результат развития технологии программирования, а не анализа и моделирования действительности. Потеря при этом способности адекватно отображать соотношения вход-выход и потоковые процессы является его (объектного подхода) большим недостатком, резко снижающим эффективность моделирования реальных (а не программных) явлений [37]. Дело в том, что реальная (не виртуальная) действительность целиком и полностью состоит из проточных объектов, постоянно преобразующих входные потоки в выходные. Например, реальный сервер для своего существования должен поддерживаться не только потоками входящей энергии и запасных частей, но и потоками данных, которые кто-то как-то должен периодически туда добавлять, и потоками исполняемого кода, необходимого для обеспечения его функционирования в постоянно меняющихся условиях. Только тогда в ответ на запрос он сможет удовлетворить клиента. Иначе, его просто выключат и выбросят.

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

 




Поделиться с друзьями:


Дата добавления: 2014-12-27; Просмотров: 501; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.012 сек.