Методологические основы

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

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

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

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

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